履修コース登録システム

ソフトウェア・アーキテクチャー説明書
バージョン 1.0

改訂履歴

日付

バージョン

説明

作成者

1999 年 3 月 21 日 1.0 Rational SoDA テンプレートと Rational Rose モデルを使用して作成したソフトウェア・アーキテクチャー説明書です。 S. ジョンソン
 
 
 
 
 
 
 
 
 
 
 
 

 

 

目次ページの先頭へ

1.   はじめに

2.   アーキテクチャーの表現

3.   アーキテクチャーの目標と制約

4.   ユースケース・ビュー

5.   論理ビュー

6.   プロセス・ビュー

7.   配置ビュー

8.   サイズと性能

9.   品質

ソフトウェア・アーキテクチャー説明書

はじめにページの先頭へ

1.1 目的

    本書では、さまざまなアーキテクチャー・ビューを使用してシステムの各面を示しながら、 システムのアーキテクチャーの包括的な概要を説明します。 システムに関して行われた重要なアーキテクチャー上の決定を、 整理して伝えることを目的としています。

1.2 範囲

    このソフトウェア・アーキテクチャー説明書では、C- 登録システムの アーキテクチャーの概要について説明します。C- 登録システムは Wylie カレッジで 開発中のシステムで、オンラインによる履修コース登録をサポートします。

    本書は、Rose に実装されている C- 登録分析と設計モデルから直接作成されています。 大部分のセクションは、SoDA とソフトウェア・アーキテクチャー説明書テンプレートを使用して Rose モデルから抽出されています。

1.3 定義、頭字語、略語

    「用語集」(参考資料 [4]) を参照してください。

1.4 参考資料

    該当する参考資料は次のとおりです。

      1. 「Course Billing Interface Specification, WC93332」 1985 年、Wylie College Press
      2. 「コース・カタログ・データベース仕様書、WC93422」 1985 年、Wylie College Press
      3. 「履修コース登録システム 開発構想書 WyIT387、バージョン 1.0」 1998 年、Wylie College IT
      4. 「履修コース登録システム 用語集 WyIT406、バージョン 2.0」 1999 年、Wylie College IT
      5. 「履修コース登録システム ユースケース仕様書 - 登録の終了、WyIT403、バージョン 2.0」 1999 年、Wylie College IT
      6. 「履修コース登録システム ユースケース仕様書 - ログイン、WyIT401、バージョン 2.0」 1999 年、Wylie College IT
      7. 「履修コース登録システム ユースケース仕様書 - 教授情報の管理、WyIT407、バージョン 2.0」 1999 年、Wylie College IT
      8. 「履修コース登録システム ユースケース仕様書 - コース登録、WyIT402、バージョン 2.0」 1999 年、Wylie College IT
      9. 「履修コース登録システム ユースケース仕様書 - 担当講座の選択、WyIT405、バージョン 2.0」 1999 年、Wylie College IT
      10. 「履修コース登録システム ユースケース仕様書 - 学生情報の管理、WyIT408、バージョン 2.0」 1999 年、Wylie College IT
      11. 「履修コース登録システム ユースケース仕様書 - 成績表の提出、WyIT409、バージョン 2.0」 1999 年、Wylie College IT
      12. 「履修コース登録システム ユースケース仕様書 - 成績表の表示、WyIT410、バージョン 2.0」 1999 年、Wylie College IT
      13. 「履修コース登録システム ソフトウェア開発計画書 WyIT418、バージョン 1.0」 1999 年、Wylie College IT
      14. 「履修コース登録システム 反復計画書、推敲反復 #E1 WyIT420、バージョン 1.0」 1999 年、Wylie College IT
      15. 「履修コース登録システム 補足仕様書 WyIT400、バージョン 1.0」 1999 年、Wylie College IT
2.  アーキテクチャーの表現ページの先頭へ
    本書では、アーキテクチャーを一連のビュー、 つまりユースケース・ビュー、論理ビュー、プロセス・ビュー、配置ビューとして示します。 本書では、実装ビューについて個別の説明はありません。 これらは、Rational Rose を使用して開発された、基礎となる 統一モデリング言語 (UML) のモデルのビューです。
3.  アーキテクチャーの目標と制約ページの先頭へ

アーキテクチャーには、重要な意味を持つ要求とシステム上の制約がいくつかあります。内容を以下に示します。

    1. 現在の学期のすべてのコース情報を取得するには、Wylie カレッジの 従来のコース・カタログ・システムにアクセスする必要があります。 C- 登録システムは、従来のコース・カタログ・システム (参考資料 [2]) の データ・フォーマットと DBMS をサポートする必要があります。
    2. 学生への費用請求をサポートするには、Wylie カレッジの 従来の財務システムとのインターフェースが必要です。 このインターフェースは、「Course Billing Interface Specification」 (参考資料 [1]) で定義します。
    3. 学生、教授、登録事務局が使用するすべての機能に、ローカル・キャンパスのコンピューターからもリモート・コンピューターからもインターネット・ダイヤルアップ接続でアクセスできる必要があります。
    4. C- 登録システムは、無許可アクセスからのデータ保護が確立している必要があります。 すべてのリモート・アクセスは、ユーザー ID とパスワードで管理されます。
    5. C- 登録システムは、クライアント/サーバー・システムとして実装されます。 クライアント部分はコンピューターに存在させ、 サーバー部分は Wylie カレッジの UNIX サーバーで稼働させる必要があります。[3]
    6. 「開発構想書」 (参考資料 [3]) と「補足仕様書」 (参考資料 [15]) で説明しているように、 すべての性能とロードの要求について、アーキテクチャーが開発途中であることを考慮に入れる必要があります。

4.  ユースケース・ビューページの先頭へ

ソフトウェア・アーキテクチャーのユースケース・ビューの説明です。 ユースケース・ビューは、反復の対象となる一連のシナリオやユースケースを選択する際の重要な入力情報です。このビューには、重要な中心的な機能を表すシナリオやユースケースのセットが示されます。また、(多くのアーキテクチャー要素を含む) 十分なアーキテクチャー範囲を扱うシナリオやユースケース、またはアーキテクチャー上の特定の細かい点を強調または表現するシナリオやユースケースも示されます。

C- 登録システムのユースケースは次のとおりです。

- ログイン

- コース登録

- 学生情報の管理

- 教授情報の管理

- 担当講座の選択

- 成績表の提出

- 成績表の表示

- 登録の終了

これらのユースケースは、学生、教授、登録事務局の各アクターによって開始されます。 また、外部アクターであるコース・カタログや支払請求システムとの相互作用が発生します。

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 学生情報の管理

    概要: このユースケースでは、登録事務局が 登録システム内の学生に関する情報を管理できます。 これには、システムへの学生の追加、修正、削除が含まれます。 このユースケースのアクターは登録事務局です。

5.  論理ビューページの先頭へ

    アーキテクチャーの論理ビューの説明です。最も重要なクラス、 サービス・パッケージとサブシステムにおけるクラスの構成と、 サブシステムによるレイヤーの構成について説明します。 また、最も重要なユースケースの実現、例えば、 アーキテクチャーの動的な面についても説明します。 アーキテクチャー上重要なクラス、サブシステム、パッケージ、 レイヤー間の関係を示すのに、クラス図が含まれる場合があります。

    履修コース登録システムの論理ビューは、ユーザー・インターフェース、ビジネス・サービス、ビジネス・オブジェクトの 3 つの主要パッケージで構成されます。

    ユーザー・インターフェース・パッケージには、 アクターがシステムとやり取りするのに使用する各フォームのクラスが含まれます。 ログイン、スケジュール管理、教授情報の管理、コース選択、 成績表の提出、学生情報の管理、登録の終了、成績表の表示を サポートするために、バウンダリー・クラスが存在します。

    ビジネス・サービス・パッケージには、財務システムとのインターフェース、学生登録の管理、学生評価の管理のためのコントロール・クラスが含まれます。

    ビジネス・オブジェクト・パッケージには、大学成果物 (つまり、講座、スケジュール) のエンティティー・クラスと、コース・カタログ・システムとのインターフェースのバウンダリー・クラスが含まれます。

5.1  アーキテクチャーの概要 - パッケージとサブシステムのレイヤー

上記の見出しで説明しています

5.1.1 アプリケーション

        レイヤー

        このアプリケーション・レイヤーには、ユーザーの目に触れる アプリケーション画面を表すすべてのバウンダリー・クラスがあります。 このレイヤーは、クライアントと中間層の区切りにまたがる プロセス・オブジェクト・レイヤーに依存しています。

5.1.2 ビジネス・サービス

        レイヤー

        ビジネス・サービス・プロセス・レイヤーには、 アプリケーションの動作を制御するユースケース・マネージャーを表す すべてのコントローラー・クラスがあります。 このレイヤーは、クライアントと中間層の境界を表します。 ビジネス・サービス・レイヤーは、クライアントと中間層の区切りにまたがる プロセス・オブジェクト・レイヤーに依存しています。

5.1.3 ミドルウェア

        レイヤー

        ミドルウェアのレイヤーは、Relational DBMS と OODBMS へのアクセスをサポートします。

5.1.4 基本再利用

    基本再利用パッケージには、リスト機能とパターンをサポートするクラスが含まれます。

     

6.  プロセス・ビューページの先頭へ

    アーキテクチャーのプロセス・ビューの説明です。 システムの実行に関係するタスク (プロセスとスレッド)、 それらの相互作用と構成について説明します。 また、オブジェクトとクラスのタスクへの割り当てについても説明します。

    プロセス・モデルは、実行可能プロセスとして構成される 履修コース登録クラスを示します。プロセスは、学生登録、教授の職務、 登録の終了、外部の財務システムやコース・カタログ・システムへのアクセスを サポートするために存在します。

6.1 プロセス

説明文は下記の本文にあります

 

      ダイアグラム名: プロセス

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 設計要素に対するプロセス

説明文は下記の本文にあります

 

      ダイアグラム名: 設計要素に対するプロセス

6.2.1 CourseCache

CourseCache スレッドは、従来のコース・カタログ・システムから非同期でアイテムを取得するのに使用します。

6.2.2 OfferingCache

OfferingCashe スレッドは、従来のコース・カタログ・システムから非同期でアイテムを取得するのに使用します。

         

6.2.3 Course

大学で提供されるクラス。

分析メカニズム:

- 永続性

- レガシー・インターフェース

 

6.2.4 CourseOffering

      曜日や時刻など、コースの具体的な内容。

      分析メカニズム:

      - 永続性

      - レガシー・インターフェース

       

6.3 設計モデル依存関係のプロセス・モデル

説明文は下記の本文にあります

ダイアグラム名: 設計モデル依存関係のプロセス・モデル

 

6.4 実装に対するプロセス

説明文は下記の本文にあります

ダイアグラム名: 実装に対するプロセス

6.4.1 Remote

        * リモート・インターフェースは、すべてのリモート・オブジェクトを 識別する役目をします。リモート・オブジェクトであるオブジェクトはすべて、 直接または間接的にこのインターフェースを実装する必要があります。 リモート・インターフェースで指定されたメソッドのみ、リモートで使用できます。

        * 実装クラスは、リモート・インターフェースをいくつでも実装でき、またその他のリモート実装クラスを拡張できます。

6.4.2 Runnable

        * インスタンスがスレッドによって実行される どのクラスも、Runnable インターフェースを実装する必要があります。 クラスは run と呼ばれる引数のないメソッドを定義する必要があります。

        * このインターフェースは、アクティブな間にコードを実行しようとする オブジェクトに対して共通プロトコルを提供するよう設計されています。 例えば、Runnable はクラス Thread によって実装されます。

        * アクティブであるというのは単に、スレッドが開始していて、まだ停止していないということです。

6.4.3 Thread

        thread はプログラムの実行のスレッドです。Java Virtual Machine によって、 アプリケーションは同時に稼働する複数の実行のスレッドを持つことができます。

        * どのスレッドにも優先順位があります。優先順位の高いスレッドは、 優先順位の低いスレッドに優先して実行されます。各スレッドは、 デーモンとしてマークされる場合とそうでない場合があります。 いずれかのスレッドで実行中のコードが新しい Thread オブジェクトを作成する場合、 新しいスレッドの優先順位は最初は作成元スレッドと同じに設定され、 また、作成元スレッドがデーモンの場合にのみ、デーモン・スレッドになります。

         

7.  配置ビューページの先頭へ

    アーキテクチャーの配置ビューの説明では、 最も標準的なプラットフォーム構成におけるさまざまな物理ノードについて説明します。 また、物理ノードに対する (プロセス・ビューからの) タスクの 割り当てについても説明します。

    このセクションは物理ネットワーク構成によってまとめられていて、各構成は、配置図に続いて各プロセッサーへのプロセスのマッピングで示されます。

    上記の本文で説明しています

    ダイアグラム名: 配置ビュー

7.1 外部デスクトップ・コンピューター

      インターネット・ダイヤルアップによってカレッジ・サーバーに接続する外部のデスクトップ・コンピューターを使用した、学生のコース登録です。

7.2 デスクトップ・コンピューター

      LAN によってカレッジ・サーバーに直接接続する ローカルのデスクトップ・コンピューターを使用した、学生のコース登録です。 これらのローカル・コンピューターは、教授がコースを選択することや 学生の成績表を提出することにも使用します。 登録事務局は、これらのローカル・コンピューターを使用して、 学生や教授に関する情報を管理します。

7.3 登録サーバー

      登録サーバーは、メイン・キャンパスの UNIX サーバーです。 すべての教職員と学生は、キャンパス LAN を通じてこのサーバーにアクセスできます。

7.4 コース・カタログ

      コース・カタログ・システムは、完全なコース・カタログを含む レガシー・システムです。このシステムへのアクセスは、 カレッジ・サーバーと LAN を通じて行うことができます。

7.5 請求システム

    支払請求システム (財務システムともいう) は、 学期ごとに学生への請求を作成するレガシー・システムです。

     

8.  サイズと性能ページの先頭へ

    選択したソフトウェア・アーキテクチャーは、「補足仕様書」 (参考資料 [15]) に明記されたサイズとタイミングに関する主な要求をサポートします。

      1. システムは、中央データベースではいつでも最大 2000 名のユーザーまで同時に対応でき、ローカル・サーバーでは最大 500 名のユーザーまで同時に対応できるものとします。
      2. 10 秒以内の待ち時間で従来のコース・カタログ・データベースへアクセスできるものとします。
      3. システムは、すべてのトランザクションの 80% を 2 分以内に完了できること。
      4. クライアント部分に必要なディスク容量は 20 MB 未満、RAM は 32 MB 未満であること。

    選択したアーキテクチャーは、クライアント/サーバー・アーキテクチャーの 実装によって、サイズとタイミングの要求をサポートします。 クライアント部分は、ローカル・キャンパスのコンピューター またはリモートのダイヤルアップ・コンピューターに実装されます。 コンポーネントは、コンピューターのクライアント部分に必要な ディスクとメモリーの容量が最小で済むよう設計されています。

9.  品質ページの先頭へ

    ソフトウェア・アーキテクチャーは、「補足仕様書」 (参考資料 [15]) に明記された品質要求をサポートします。

      1. デスクトップのユーザー・インターフェースは、Windows 95/98 に準拠すること。
      2. C- 登録システムのユーザー・インターフェースは、使いやすく、通常のコンピューター操作ができるユーザーがシステムに関して追加のトレーニングをしないで使用できるよう設計されていること。
      3. C- 登録システムの各機能には、ユーザーが使用できる 組み込みのオンライン・ヘルプがあること。オンライン・ヘルプは、 システムの使用について順を追った説明をすること。 オンライン・ヘルプには、用語と頭字語についての定義を含むこと。
      4. C- 登録システムは、1 日 24 時間、週 7 日間使用可能であること。 ダウン時間が 4% を超えないこと。
      5. 平均故障間隔が 300 時間を超えること。
      6. C- 登録のコンピューター・クライアント部分に対するアップグレードを、 インターネットを通じて UNIX サーバーからダウンロードできること。 この機能によって、学生はシステム・アップグレードに簡単にアクセスできます。



        

 
Copyright  (c) IBM Corp. 1987, 2004. All Rights Reserved. 

履修コース登録プロジェクト Web Example
バージョン 2001.03