成果物:
|
![]() |
この成果物は、空間と時間の中でのできごと、具体的には、システムが反応しなければならない何らかのできごとの発生を仕様化します。 この成果物の目的は、発生頻度、優先度、応答上の要件など、イベントの特性を把握することです。 |
そのほかの関係: |
一部設計モデル
|
---|---|
役割: | ソフトウェア アーキテクト |
オプション度 / 使用時期: | イベントの識別と特徴づけは主に、リアクティブ (イベント駆動型) システム、並行性を利用するシステム、非同期メッセージングを使用するシステムに適用できます。 |
テンプレートとレポート: |
|
例: | |
UML の表現: |
ステートチャート図とアクティビティ図のコンテキストでは、イベントは状態遷移をトリガすることを指します。 ただしこの成果物では、シグナル、呼び出し、状態の変化、時間イベントなど、システムが応答しなければならないできごととして、より一般的な意味での「イベント」を扱います。 「成果物: シグナル」も参照してください。 |
詳細情報: | |
成果物を入力とする作業: | 成果物を出力とする作業: |
イベントは、システムが認識する、またシステムが応答しなければならない外部のできごとについての情報を識別し、把握するために使用されます。例外などの内部イベントについての情報を把握する目的にも使用できます。
イベントの重要な特徴には、次のものがあります。
一部のイベント、特にシステムが応答する必要のある外部イベントと重要な内部イベントを表すものは、推敲フェーズの早い時期に識別されます。システム内部で非同期的に伝達される必要のあるその他のイベントは、推敲フェーズの比較的遅い時期に識別されます。アーキテクチャ上重要なすべてのイベントは、推敲フェーズの終わりまで完全に識別される必要があります。
ソフトウェア アーキテクトは、イベントの適切な使用を徹底することで、すべてのイベントに責任を持ちます。
イベントの特徴は、スプレッドシート、データベース、要求管理データベースで、またはソフトウェア アーキテクチャ説明書内の表として把握できます。
それらの特徴は «event» というステレオタイプ付きのクラスとして把握することもできますが、これはイベントに関する管理情報を把握するために都合のよい手段として扱うべきものであり、イベント発生時に伝送されるデータと混同すべきではありません。呼び出しイベントによって結果的にデータの伝送が発生する場合、そのデータは呼び出される操作のシグネチャによって表現するべきです。イベントがシグナルである場合、そのデータを明示的にモデリングできます (「成果物: シグナル」を参照)。
Rational Unified Process
|