作業:
|
目的
|
|
手順 | |
入力とする成果物: | 結果となる成果物: |
役割: ソフトウェア アーキテクト | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
アクティブ オブジェクト (アクティブ クラスのインスタンス) を使い、システム内の同時実行スレッドを表します。概念的に表現すると、各アクティブ オブジェクトには固有の制御スレッドがあり、従来の方法で表現すると、アクティブ オブジェクトは実行スタック フレームのルートになります。アクティブ オブジェクトの、実際のオペレーティング システムのスレッドやプロセスへのマッピングは、応答性に関する要求によって異なり、コンテキスト切り替えのオーバーヘッドを考慮することによっても影響を受けます。たとえば、いくつかのアクティブ オブジェクトに簡単なスケジューラを組み合わせることにより、単一のシステム スレッドを共有させ、並行して実行しているように見せかけることができます。ただし、たとえば、同期入出力を実行することによって抑止的な振る舞いを示すアクティブ オブジェクトがある場合は、グループ内のほかのアクティブ オブジェクトは、オペレーティング システムのスレッドがブロックされている間、発生するイベントに対して応答することができません。
それとは反対に、各アクティブ オブジェクトに固有のオペレーティング システムのスレッドを与えると、プロセス用のリソースがコンテキスト切り替えのオーバーヘッドの悪影響を受けないかぎり、応答性が向上します。
この作業では、アクティブ クラスとそのインスタンスの観点とそれらのオペレーティング システムのスレッドとプロセスに対する関係の観点から、システムのプロセス アーキテクチャを定義します。
推敲フェーズの初期には、このアーキテクチャはまだ準備段階にありますが、推敲フェーズの後半までにはプロセスとスレッドを十分定義しておく必要があります。
この作業の結果を設計モデル、特にプロセス ビューに取り込みます (「概念: プロセス ビュー」を参照してください)。
目的 | タスクの並行実行がシステムに必要な度合いを定義する。この定義はアーキテクチャの形成に役立ちます。 |
「作業: 設計要素の識別」では、問題領域で自然発生する並行性に対する需要から主に生じる並行性要求を検討しました。
その結果は、システムの論理的な制御スレッドを表す一連のアクティブ クラスでした。
このステップでは、ほかのソースを持つ並行性要求、つまり、システムの機能外要求によるものを検討します。
並行性要求を推進するのは以下のものです。
多くのアーキテクチャ上の問題と同様、これらの要求はある程度相互に排他的です。少なくとも最初は、矛盾する要求になることがよくあります。重要性で要求のランク付けを行うと、矛盾の解消に役立ちます。
目的 | システムに存在すると思われるプロセスとスレッドを定義する。 |
最も簡単な方法は、すべてのアクティブ オブジェクトを共通のスレッドまたはプロセスに割り当て、簡単なアクティブ オブジェクト スケジューラを使用する方法です。これにより、コンテキスト切り替えのオーバーヘッドが最小になるからです。ただし、場合によっては、アクティブ オブジェクトを 1 つまたは複数のスレッドまたはプロセスに分散させることが必要なこともあります。
ほかのアクティブ オブジェクトとオペレーティング システムのスレッドを共有するアクティブ オブジェクトがほかのプロセスやスレッドに対して同期呼び出しを行い、この呼び出しが、呼び出しを行ったオブジェクトが共有するオペレーティング システムのスレッドをブロックする場合は、呼び出されているプロセスにあるそのほかすべてのアクティブ オブジェクトが自動的に サスペンド状態になります。ただし、必ずしもそうとも限りません。アクティブ オブジェクトから見て同期した呼び出しを、アクティブ オブジェクトのグループを制御する簡単なスケジューラの視点から非同期的に処理できる場合があります。スケジューラが呼び出しを実行するアクティブ オブジェクトをサスペンドし (同期呼び出しの完了を待機し)、ほかのアクティブ オブジェクトの実行をスケジュールします。
元の「同期」オペレーションが完了すると、呼び出し側のアクティブ オブジェクトを再開できます。ただし、この方法は常に可能だとは限りません。ブロックを実行する前にすべての同期呼び出しを遮断するようにスケジューラを設計できない場合があるからです。オペレーティング システムの同一プロセスまたはスレッドを使用するアクティブ オブジェクト間の同期呼び出しは、通常、このようにスケジューラで処理でき、呼び出しを行うアクティブ オブジェクトから見て、事実上、手続き呼び出しに等しいことに注意してください。
これにより、スレッドをブロックする同期呼び出しと並行に実行する必要性に応じて アクティブ オブジェクトをプロセスまたはスレッドにグループ化するという結論に達します。つまり、アクティブ オブジェクトを、スレッドをブロックする同期呼び出しを使うほかのオブジェクトと同一プロセスまたはスレッド内にパッケージ化できるのは、そのオブジェクトと並行に実行する必要がなく、そのオブジェクトがブロックされている間実行を待つことが可能な場合に限ります。極端な場合、応答性が重要であると、アクティブ オブジェクトごとに個別のスレッドまたはプロセスが必要になります。
一般的には、上記の状況ではオーバーヘッドが少ないという理由から、本格的なプロセスの代わりに軽量のスレッドを使用する方が適しています。ただし、ある特別な場合には、プロセスの特殊な性質を活用したい場合もあります。スレッドは同一アドレス空間を占めるので、本来、プロセスよりも高い危険性があります。不意に上書きする可能性が心配な場合は、プロセスを使用するのが適しています。さらに、プロセスはほとんどのオペレーティング システムで独立したリカバリ単位であるため、互いに別個に回復する必要性に応じて、アクティブ オブジェクトをプロセスに割り当てることは役に立ちます。つまり、1 つのユニットとして回復する必要があるすべてのアクティブ オブジェクトは、同一プロセス内にパッケージ化できます。
システムが必要とする制御の流れごとにプロセスまたはスレッド (軽量プロセス) を 1 つ作成します。スレッドは制御の流れを入れ子にする必要性がある場合 (プロセス内で、サブタスク レベルで独立した制御の流れが必要な場合) に使用します。
たとえば、以下の目的のために別々の制御スレッドが必要になります (必ずしも重要性の順ではない)。
例
ATM (現金自動預払機) では、次の 3 つの異なるソースから発生する非同期イベントを処理する必要があります。システムのユーザー、ATM デバイス (キャッシュ ディスペンサが詰まった場合など)、および ATM ネットワーク (ネットワークからシャットダウン命令が出た場合など) の 3 つ です。このような非同期イベントを扱うために、次に示すように UML ではアクティブ クラスを使い、ATM 自体に 3 つの独立した実行スレッドを定義できます。
ATM 内のプロセスとスレッド
目的 | プロセスとスレッドの生成および消滅時期を識別する。 |
各制御プロセスまたは制御スレッドを生成し、消滅させる必要があります。単一プロセス アーキテクチャの場合、アプリケーションの起動時にプロセスを生成し、アプリケーション終了時にプロセスを消滅させます。マルチプロセス アーキテクチャでは、新しいプロセス (またはスレッド) は、通常、アプリケーション起動時にオペレーティング システムが生成した最初のプロセスから派生したり、枝分かれしてできます。これらのプロセスも明示的に指定して消滅させる必要があります。
プロセスの生成および消滅だけでなく、プロセスの生成と消滅に至るイベントの流れもはっきりさせて文書化する必要があります。
例
ATM では、システム全体の振る舞いを調整する役割を担う主プロセスが開始されます。次に、この主プロセスが、次に示すシステムの構成部分を監視する下位の制御スレッドをいくつか派生します。つまり、システム内のデバイス、および顧客と ATM ネットワークから発生するイベントです。このようなプロセスとスレッドの生成は、UML ではアクティブ クラスとして示すことができます。また、このようなアクティブ クラスのインスタンスの生成は、次のようなシーケンス図で示すことができます。
システム立ち上げ中のプロセスとスレッドの作成
目的 | プロセスとスレッドが通信する手段を明確にする。 |
プロセス間通信 (IPC: Inter-Process Communication) では別プロセスで実行するオブジェクト間でのメッセージの送信を可能にします。
典型的なプロセス間通信メカニズムには次のものがあります。
IPC メカニズムの選択はシステムのモデリング方法を変化させます。たとえば、「メッセージ バス アーキテクチャ」では、メッセージを送信するオブジェクト間に明確な関連は必要ありません。
目的 | 乏しいリソースを割り当てる。
潜在的な性能ボトルネックの予想と管理を行う。 |
プロセス間通信メカニズムは不十分な状態にあるのが一般的です。セマフォ、共有メモリ、およびメールボックスは、通常、大きさや数が決まっていて、相当な費用をかけないと増やせません。RPC、メッセージおよびイベントの送信は、乏しいネットワーク帯域幅をますます食いつぶしていきます。システムがリソースのしきい値を超えると、性能は非線形的に劣化していきます。乏しいリソースが枯渇した場合、それに対する要求を続けていけば好ましくない影響が出てくることが考えられます。
乏しいリソースに申し込みが殺到する場合には、以下のような検討すべき戦略がいくつかあります。
どんな戦略を選んでも、システムは (クラッシュするより) ゆるやかに劣化すべきであり、システム管理者に適当なフィードバックを提供し、(もし可能なら) システムが導入された場合、フィールドで問題を解決できるようにすべきです。
システムが重要なリソースの可用性を増加させるために、特殊構成の実行時環境 (たとえば、オペレーティング システム カーネルの再構成による制御) を必要とする場合、システムのインストール時に自動的に行うか、あるいはシステムが運用可能となる前にシステム管理者に行わせる必要があります。たとえば、この変更が有効になる前に再起動が必要となります。
目的 | 「制御の流れ」を実装環境がサポートする概念へマッピングする。 |
概念的プロセスは動作環境の個々の構成物へマッピングする必要があります。多くの環境では、プロセスのタイプに選択肢があり、最低でも、通常はプロセスとスレッドがあります。この選択は、結合度 (プロセスはスタンドアロンですが、スレッドは包括するプロセスのコンテキスト内で実行) およびシステムの性能要求 (スレッド間のプロセス間通信は通常、プロセス間の通信より高速かつ効率的) に基づいて行います。
多くのシステムでは、プロセス当たりのスレッド数、またはノード当たりのプロセス数に上限があります。このような制限は絶対ではありませんが、乏しいリソースの可用性からくる実用的な制限です。ターゲット ノードで既に実行しているスレッドやプロセスは、プロセス アーキテクチャで提案されているスレッドとプロセスと共に検討する必要があります。新たな性能上の問題を発生させないために、マッピングを行う場合は、以前のステップの結果である、「プロセス間調整リソースの割り当て」を考慮する必要があります。
目的 | どの制御クラスとサブシステムのスレッドを内部的に実行すべきかを決定する。 |
特定のクラスまたはサブシステムのインスタンスは、クラスまたはサブシステムの実行環境を提供する、少なくとも 1 つの制御スレッド内で実行しなければなりません。実際、そうしたインスタンスは複数の異なるプロセス内で実行することができます。
2 つの異なる戦略を同時に使うことで、「正しい」量の並行性を決定し、「正しい」プロセス群を定義します。
これは、最適なプロセス ビューにつながる直線的で決定論的なプロセスではなく、許容可能な妥協に達するまでには何回かの反復が必要です。
例
次に示すダイアグラムは ATM 内のクラスがシステム内のプロセスとスレッド間でどのように分散されているかを示しています。
クラスを ATM 用プロセスへマッピング
Rational Unified Process
|