ソフトウェア・アーキテクチャー説明書 改訂履歴
ソフトウェア・アーキテクチャー説明書 はじめに![]() 1.1 目的本書では、さまざまなアーキテクチャー・ビューを使用してシステムの各面を示しながら、 システムのアーキテクチャーの包括的な概要を説明します。 システムに関して行われた重要なアーキテクチャー上の決定を、 整理して伝えることを目的としています。 1.2 範囲このソフトウェア・アーキテクチャー説明書では、C- 登録システムの アーキテクチャーの概要について説明します。C- 登録システムは Wylie カレッジで 開発中のシステムで、オンラインによる履修コース登録をサポートします。 本書は、Rose に実装されている C- 登録分析と設計モデルから直接作成されています。 大部分のセクションは、SoDA とソフトウェア・アーキテクチャー説明書テンプレートを使用して Rose モデルから抽出されています。 1.3 定義、頭字語、略語「用語集」(参考資料 [4]) を参照してください。 1.4 参考資料
![]()
![]()
![]() 4.1 アーキテクチャー上重要なユースケース ダイアグラム名: アーキテクチャー上重要なユースケース
4.1.1 登録の終了 概要: このユースケースでは、登録事務局が登録プロセスを終了できます。 必要な学生数が集まらない講座はキャンセルされます。 講座には、少なくとも 3 名の学生が必要です。 キャンセルされない各講座の各学生には請求システムが通知され、 学生は講座の請求を受けることができます。 このユースケースの主要なアクターは登録事務局です。 請求システムは、このユースケースに関係するアクターです。 4.1.2 ログイン 概要: このユースケースは、ユーザーが履修コース登録システムにログインする方法を示します。このユースケースを開始するアクターは、学生、教授、登録事務局です。 4.1.3 教授情報の管理 概要: このユースケースでは、登録事務局が 登録システム内の教授に関する情報を管理できます。 これには、システムへの教授の追加、修正、削除が含まれます。このユースケースのアクターは登録事務局です。 4.1.4 担当講座の選択 概要: このユースケースでは、教授が、教える資格があって 次の学期で教えたいと思うコースを、講座 (日時指定のコース) として コース・カタログから選択できます。 このユースケースを開始するアクターは教授です。 コース・カタログ・システムは、このユースケース内のアクターです。 4.1.5 コース登録 概要: このユースケースでは、学生が現在の学期のコースに登録できます。 学生は、学期初めのコース追加や削除期間内であれば、選択を修正または削除できます。 すべての登録更新について、支払請求システムが通知されます。 コース・カタログには、現在の学期のすべての講座がリスト表示されます。 このユースケースの主要なアクターは学生です。 コース・カタログ・システムは、このユースケース内のアクターです。 4.1.6 成績表の表示 概要: このユースケースでは、学生が、既に終了した学期の成績表を表示できます。 このユースケースのアクターは学生です。 4.1.7 成績表の提出 概要: このユースケースでは、教授が、前の学期に終了した 1 つまたは複数のクラスの学生の成績表を提出できます。このユースケースのアクターは教授です。 4.1.8 学生情報の管理
![]() アーキテクチャーの論理ビューの説明です。最も重要なクラス、 サービス・パッケージとサブシステムにおけるクラスの構成と、 サブシステムによるレイヤーの構成について説明します。 また、最も重要なユースケースの実現、例えば、 アーキテクチャーの動的な面についても説明します。 アーキテクチャー上重要なクラス、サブシステム、パッケージ、 レイヤー間の関係を示すのに、クラス図が含まれる場合があります。 履修コース登録システムの論理ビューは、ユーザー・インターフェース、ビジネス・サービス、ビジネス・オブジェクトの 3 つの主要パッケージで構成されます。 ユーザー・インターフェース・パッケージには、 アクターがシステムとやり取りするのに使用する各フォームのクラスが含まれます。 ログイン、スケジュール管理、教授情報の管理、コース選択、 成績表の提出、学生情報の管理、登録の終了、成績表の表示を サポートするために、バウンダリー・クラスが存在します。 ビジネス・サービス・パッケージには、財務システムとのインターフェース、学生登録の管理、学生評価の管理のためのコントロール・クラスが含まれます。 ビジネス・オブジェクト・パッケージには、大学成果物 (つまり、講座、スケジュール) のエンティティー・クラスと、コース・カタログ・システムとのインターフェースのバウンダリー・クラスが含まれます。
5.1.1 アプリケーション レイヤー このアプリケーション・レイヤーには、ユーザーの目に触れる アプリケーション画面を表すすべてのバウンダリー・クラスがあります。 このレイヤーは、クライアントと中間層の区切りにまたがる プロセス・オブジェクト・レイヤーに依存しています。 5.1.2 ビジネス・サービス レイヤー ビジネス・サービス・プロセス・レイヤーには、 アプリケーションの動作を制御するユースケース・マネージャーを表す すべてのコントローラー・クラスがあります。 このレイヤーは、クライアントと中間層の境界を表します。 ビジネス・サービス・レイヤーは、クライアントと中間層の区切りにまたがる プロセス・オブジェクト・レイヤーに依存しています。
レイヤー ミドルウェアのレイヤーは、Relational DBMS と OODBMS へのアクセスをサポートします。
![]() アーキテクチャーのプロセス・ビューの説明です。 システムの実行に関係するタスク (プロセスとスレッド)、 それらの相互作用と構成について説明します。 また、オブジェクトとクラスのタスクへの割り当てについても説明します。 プロセス・モデルは、実行可能プロセスとして構成される 履修コース登録クラスを示します。プロセスは、学生登録、教授の職務、 登録の終了、外部の財務システムやコース・カタログ・システムへのアクセスを サポートするために存在します。
ダイアグラム名: プロセス 6.1.1 CourseCatalogSystemAccess このプロセスは、従来のコース・カタログ・システムへのアクセスを管理します。 このプロセスは、コースに登録する複数のユーザーが共有できます。 これによって、最近検索されたコースと講座のキャッシュの性能が向上します。 CourseCatalog プロセス内の個別のスレッドである CourseCache と OfferingCache は、レガシー・システムからアイテムを非同期で検索するのに使用します。 分析メカニズム: - レガシー・インターフェース 要求追跡可能性: - 設計の制約: システムが既存のレガシー・システム (コース・カタログ・データベース) と統合されていること。
6.1.2 CourseCatalog 前の学期からのコースと講座を含む、大学が提供するすべてのコースと講座の完全なカタログです。 このクラスは、アダプターの役目をします (Gamma パターン参照)。 このクラスは、サブシステム CourseCatalogSystem との ICourseCatalog インターフェース を通じて、CourseCatalogSystem にアクセスできるようにします。
6.1.3 CourseRegistrationProcess 現在コースに登録中の学生ごとに、このプロセスのインスタンスが 1 つあります。
6.1.4 RegistrationController 学生が現在の学期のコースに登録できるユースケースをサポートします。 学生は、学期初めのコース追加や削除期間内であれば、選択を修正または削除できます。 分析メカニズム: - 分散
6.1.5 StudentApplication ユーザー・インターフェースの処理、ビジネス・プロセスとの調整を含む、学生に関する機能を管理します。 現在コースに登録中の学生ごとに、このプロセスのインスタンスが 1 つあります。
6.1.6 MainStudentForm 学生用アプリケーションのインターフェースを管理します。 学生が使用するフォームのファミリーを管理します。
6.1.7 BillingSystemAccess このプロセスは、外部の財務 (請求) システムとやり取りして、学生への請求を開始します。
6.1.8 CloseRegistrationProcess 登録終了プロセスは、登録期間の終わりに開始されます。 このプロセスは、財務システムへのアクセスを管理するプロセスとやり取りします。
6.1.9 BillingSystem 財務システムは、学生が現在の学期に登録したコースについて、学生への請求の提出をサポートします。 分析メカニズム: - レガシー・インターフェース
6.1.10 CloseRegistrationController 登録終了コントローラーは、財務システムへのアクセスを管理します。 分析メカニズム: - 分散
ダイアグラム名: 設計要素に対するプロセス 6.2.1 CourseCache
6.2.3 Course 曜日や時刻など、コースの具体的な内容。 分析メカニズム: - 永続性 - レガシー・インターフェース
6.4 実装に対するプロセス ダイアグラム名: 実装に対するプロセス
* リモート・インターフェースは、すべてのリモート・オブジェクトを 識別する役目をします。リモート・オブジェクトであるオブジェクトはすべて、 直接または間接的にこのインターフェースを実装する必要があります。 リモート・インターフェースで指定されたメソッドのみ、リモートで使用できます。 * 実装クラスは、リモート・インターフェースをいくつでも実装でき、またその他のリモート実装クラスを拡張できます。 6.4.2 Runnable * インスタンスがスレッドによって実行される どのクラスも、Runnable インターフェースを実装する必要があります。 クラスは run と呼ばれる引数のないメソッドを定義する必要があります。 * このインターフェースは、アクティブな間にコードを実行しようとする オブジェクトに対して共通プロトコルを提供するよう設計されています。 例えば、Runnable はクラス Thread によって実装されます。 * アクティブであるというのは単に、スレッドが開始していて、まだ停止していないということです。
thread はプログラムの実行のスレッドです。Java Virtual Machine によって、 アプリケーションは同時に稼働する複数の実行のスレッドを持つことができます。 * どのスレッドにも優先順位があります。優先順位の高いスレッドは、 優先順位の低いスレッドに優先して実行されます。各スレッドは、 デーモンとしてマークされる場合とそうでない場合があります。 いずれかのスレッドで実行中のコードが新しい Thread オブジェクトを作成する場合、 新しいスレッドの優先順位は最初は作成元スレッドと同じに設定され、 また、作成元スレッドがデーモンの場合にのみ、デーモン・スレッドになります。
7. 配置ビュー アーキテクチャーの配置ビューの説明では、 最も標準的なプラットフォーム構成におけるさまざまな物理ノードについて説明します。 また、物理ノードに対する (プロセス・ビューからの) タスクの 割り当てについても説明します。 このセクションは物理ネットワーク構成によってまとめられていて、各構成は、配置図に続いて各プロセッサーへのプロセスのマッピングで示されます。 ダイアグラム名: 配置ビュー インターネット・ダイヤルアップによってカレッジ・サーバーに接続する外部のデスクトップ・コンピューターを使用した、学生のコース登録です。 LAN によってカレッジ・サーバーに直接接続する ローカルのデスクトップ・コンピューターを使用した、学生のコース登録です。 これらのローカル・コンピューターは、教授がコースを選択することや 学生の成績表を提出することにも使用します。 登録事務局は、これらのローカル・コンピューターを使用して、 学生や教授に関する情報を管理します。 登録サーバーは、メイン・キャンパスの UNIX サーバーです。 すべての教職員と学生は、キャンパス LAN を通じてこのサーバーにアクセスできます。 コース・カタログ・システムは、完全なコース・カタログを含む レガシー・システムです。このシステムへのアクセスは、 カレッジ・サーバーと LAN を通じて行うことができます。 支払請求システム (財務システムともいう) は、 学期ごとに学生への請求を作成するレガシー・システムです。
![]()
![]()
|
|