ガイドライン
外部システムへのインターフェースの表現
システムが別のシステムと通信する場合、通信プロトコルを記述するために、
1 つ以上のバウンダリー・クラスが『作業: ユース・ケース分析』で
識別されます。
別のシステムは、現在のシステムが使用するものならば、ソフトウェアからハードウェアまで
どのようなものでもかまいません (プリンター、端末、警報装置、センサーなど)。
どの場合も、他方のシステムとの通信の仲介を目的とするバウンダリー・クラスが識別されます。
例
現金自動預払機 (ATM) は、ATM ネットワークと通信して、
預金者の銀行番号と個人識別番号が正しいかどうか、引き出しが可能なだけの十分な預金残高があるかどうかを
確認しなければなりません。
ATM ネットワークは (ATM から見れば) 外部システムなので、ユース・ケース分析でバウンダリー・クラスを
使用して表現します。
このシステムのインターフェースが単純で明確に定義される場合、1 つのクラスで十分に外部システムを
表現できることもあります。
しかし、多くの場合は、このインターフェースが複雑すぎて 1 つのクラスでは表現できず、
多数のクラスで構成される複雑なコラボレーションが必要になります。
その上、たいていは、システム間のインターフェースが、アプリケーション間で非常によく再利用できます。
その結果、多くの場合は、サブシステムを使用したほうがシステム・インターフェースを適切にモデリングできます。
サブシステムを使用すると、外部システムとのインターフェースの定義と安定化ができ、
システム・インターフェースの設計の詳細を隠しながら、その定義を発展させることができます。
設計の洗練
他のシステムまたはデバイスへのインターフェースの要件では、
(UML) インターフェースの仕様と実現を形式化する必要があります。
その場合、システムのバウンダリーとシステムが動作するコンテキストを非常に明確にしておくと便利です。
ユース・ケース・モデルはシステムの振る舞いのコンテキストを示しますが、
その環境内のシステムの論理モデルは、以下のものを示します。
- システムが実現し、提供 する
インターフェース (操作 または
単一の受信 としてシステムが提供するサービス、
サポートされる関連プロトコル、および交換される情報に関する)
- 目的のパフォーマンスを得るためにシステムで必要な インターフェース (システムと対話する
外部システムによって実現されます)。
多くの場合、外部システムがすでに存在するときは、これらの必要なインターフェースと提供されるインターフェースは、
その外部システムが課す制約を単純に反映します。なぜなら、その振る舞いを変更することはできないからです。
状況図を作成すると、システムとその他のシステムまたはデバイス間のトップレベル・コラボレーションを示すことができます。
これは、システムのユース・ケース・モデルと構造的に類似しています。
システム・サービスは、ユース・ケースをサポートするように構成されます。例えば、
外部システムと開発中のシステム間の相互作用を示す一連のシーケンス図を作成すると、
ユース・ケースの実行時に交換されるメッセージを示し、そのメッセージを操作 (または受信) にマップできます。
ただし、これはユース・ケースの実現を示すシーケンス図と同じではないことに注意してください。
なぜなら、システム内部を示しているのではないからです。
通常、ユース・ケース・シナリオのパフォーマンスには、システムの呼び出しと応答がいくつか含まれます。
システム内でのこうしたサービスの識別とその実現は、必ずしも厳密なトップダウンで進行するとは限りません。
(設計者が実行する) ユース・ケース分析では、『作業: アーキテクチャー分析』で
ソフトウェア・アーキテクトが実行する作業を考慮しながら、
実現クラス (バウンダリー・クラスを含む) とコラボレーションの初期モデルが作成されます。
この分析を反復し、後でバウンダリー・クラス、およびシステム・バウンダリーを横断するメッセージを
洗練させることができます (それを行う自由があると想定した場合)。
インターフェースが既存の外部システムに対するものであり、その変更が難しいまたは不可能な場合は、
インターフェースの詳細 (したがって、それをサポートするサービス) が基本的に最初から固定されるので、
インターフェースの実現を洗練させることのみが可能となります。
このトップレベルでは、システムはインターフェースを実現
する (UML) コンポーネント (UML 2.0 の場合は構造化クラス) と
して表現できます。このシステムは、UML で正式に定義することができ、外部システムまたはデバイスをサポートします。
また、UML 2.0 の場合、これらのインターフェースは、システム・バウンダリー上の定義済みの相互作用ポイント
またはポートに割り当てることができます。
ポートを使用すると、ソフトウェア・アーキテクトと設計者は、システムの内部コンポーネントや
クラスをどのように「結線」してインターフェースをサポートするのかを示すことができます。
これにより、分析で識別されたバウンダリー・クラスへのブリッジが自然に形成されます。
簡単なケースでは、システム・バウンダリーでポートを通じて実現するインターフェースに対してこれらを接続できます。
UML 2.0 では、プロトコルの状態マシンを通じて、
より高いレベルの精度が提供されます。プロトコルの状態マシンは、インターフェースまたはポートに関連付けることができ、
インターフェースで指定される、またはポートでサポートされる振る舞い特性の正式な呼び出しシーケンスを指定します。
上記のように、複雑なインターフェースをサポートするためにコラボレーションが必要な場合、
(最初に識別されたバウンダリー・クラスから発展する) そのコラボレーションは、
最初のセクションで説明したサブシステムとして機能するシステム内部のコンポーネント (または構造化クラス) として
それ自身をカプセル化し、必要なインターフェースをサポートするポートに接続することが可能です。
サービス指向アーキテクチャーでインターフェースを提供および実現する方法の詳細については、
ホワイト・ペーパー「サービス指向アーキテクチャーとコンポーネント・ベース開発
による Web サービス・アプリケーションの作成」を参照してください。
|