目的
  • 並行性要求の分析、プロセスの識別、プロセス間の通信メカニズムの明確化、プロセス間の調整リソースの割り当て、プロセスのライフサイクルの明確化、プロセス間のモデル要素の分散化を行う。
手順
入力とする成果物: 結果となる成果物:
役割: ソフトウェア アーキテクト
ツール メンター:
More Information: 

ワークフローの詳細:

アクティブ オブジェクト (アクティブ クラスのインスタンス) を使い、システム内の同時実行スレッドを表します。概念的に表現すると、各アクティブ オブジェクトには固有の制御スレッドがあり、従来の方法で表現すると、アクティブ オブジェクトは実行スタック フレームのルートになります。アクティブ オブジェクトの、実際のオペレーティング システムのスレッドやプロセスへのマッピングは、応答性に関する要求によって異なり、コンテキスト切り替えのオーバーヘッドを考慮することによっても影響を受けます。たとえば、いくつかのアクティブ オブジェクトに簡単なスケジューラを組み合わせることにより、単一のシステム スレッドを共有させ、並行して実行しているように見せかけることができます。ただし、たとえば、同期入出力を実行することによって抑止的な振る舞いを示すアクティブ オブジェクトがある場合は、グループ内のほかのアクティブ オブジェクトは、オペレーティング システムのスレッドがブロックされている間、発生するイベントに対して応答することができません。

それとは反対に、各アクティブ オブジェクトに固有のオペレーティング システムのスレッドを与えると、プロセス用のリソースがコンテキスト切り替えのオーバーヘッドの悪影響を受けないかぎり、応答性が向上します。

この作業では、アクティブ クラスとそのインスタンスの観点とそれらのオペレーティング システムのスレッドとプロセスに対する関係の観点から、システムのプロセス アーキテクチャを定義します。

推敲フェーズの初期には、このアーキテクチャはまだ準備段階にありますが、推敲フェーズの後半までにはプロセスとスレッドを十分定義しておく必要があります。

この作業の結果を設計モデル、特にプロセス ビューに取り込みます (「概念: プロセス ビュー」を参照してください)。

並行性要求の分析 ページの先頭へ

目的 タスクの並行実行がシステムに必要な度合いを定義する。この定義はアーキテクチャの形成に役立ちます。

作業: 設計要素の識別」では、問題領域で自然発生する並行性に対する需要から主に生じる並行性要求を検討しました。

その結果は、システムの論理的な制御スレッドを表す一連のアクティブ クラスでした。

このステップでは、ほかのソースを持つ並行性要求、つまり、システムの機能外要求によるものを検討します。

並行性要求を推進するのは以下のものです。

  • システム分散の必要性の度合い:複数のプロセッサやノード上に振る舞いを分散させる必要があるシステムでは、実際のところ、マルチプロセス アーキテクチャが必要です。ある種のデータベース管理システムやトランザクション マネージャを使用するシステムでは、これらの主要なサブシステムが導入するプロセスも検討する必要があります。
  • 中心となるアルゴリズムの計算の強度:適切な応答時間を提供するためには、割り当てるリソースは少なくとも、計算中心の作業群を 1 つの独自プロセスあるいはスレッドの中に入れて、計算中にユーザーの入力に応答できるようにしなければならない場合があります。
  • 環境がサポートする並行実行度:オペレーティング システムまたは環境でスレッド (軽量プロセス) をサポートしない場合は、スレッドがシステム アーキテクチャに与える影響度を考慮する必要はほとんどありません。
  • システムにおけるフォールト トレランスの必要性: バックアップ プロセッサはバックアップ プロセスを必要とし、主プロセスとバック アップ プロセスの同期を取る必要性を推進します。
  • システム内でのイベント到達パターン: 外部デバイスや外部センサーを備えたシステムでは、イベントの到達パターンはセンサーごとに異なる可能性があります。イベントには周期的なもの (一定間隔 ±α で発生) もあれば非周期的なもの (不規則な間隔で発生) もあります。異なるイベント パターンを生成するデバイスを表すアクティブ クラスは、通常、オペレーティング システムの異なるスレッドに異なるスケジューリング アルゴリズムで割り当て、イベントや処理期限が見過ごされないようにします (システムの要求の場合)。

多くのアーキテクチャ上の問題と同様、これらの要求はある程度相互に排他的です。少なくとも最初は、矛盾する要求になることがよくあります。重要性で要求のランク付けを行うと、矛盾の解消に役立ちます。

プロセスとスレッドの識別 ページの先頭へ

目的 システムに存在すると思われるプロセスとスレッドを定義する。

最も簡単な方法は、すべてのアクティブ オブジェクトを共通のスレッドまたはプロセスに割り当て、簡単なアクティブ オブジェクト スケジューラを使用する方法です。これにより、コンテキスト切り替えのオーバーヘッドが最小になるからです。ただし、場合によっては、アクティブ オブジェクトを 1 つまたは複数のスレッドまたはプロセスに分散させることが必要なこともあります。

ほかのアクティブ オブジェクトとオペレーティング システムのスレッドを共有するアクティブ オブジェクトがほかのプロセスやスレッドに対して同期呼び出しを行い、この呼び出しが、呼び出しを行ったオブジェクトが共有するオペレーティング システムのスレッドをブロックする場合は、呼び出されているプロセスにあるそのほかすべてのアクティブ オブジェクトが自動的に サスペンド状態になります。ただし、必ずしもそうとも限りません。アクティブ オブジェクトから見て同期した呼び出しを、アクティブ オブジェクトのグループを制御する簡単なスケジューラの視点から非同期的に処理できる場合があります。スケジューラが呼び出しを実行するアクティブ オブジェクトをサスペンドし (同期呼び出しの完了を待機し)、ほかのアクティブ オブジェクトの実行をスケジュールします。

元の「同期」オペレーションが完了すると、呼び出し側のアクティブ オブジェクトを再開できます。ただし、この方法は常に可能だとは限りません。ブロックを実行する前にすべての同期呼び出しを遮断するようにスケジューラを設計できない場合があるからです。オペレーティング システムの同一プロセスまたはスレッドを使用するアクティブ オブジェクト間の同期呼び出しは、通常、このようにスケジューラで処理でき、呼び出しを行うアクティブ オブジェクトから見て、事実上、手続き呼び出しに等しいことに注意してください。

これにより、スレッドをブロックする同期呼び出しと並行に実行する必要性に応じて アクティブ オブジェクトをプロセスまたはスレッドにグループ化するという結論に達します。つまり、アクティブ オブジェクトを、スレッドをブロックする同期呼び出しを使うほかのオブジェクトと同一プロセスまたはスレッド内にパッケージ化できるのは、そのオブジェクトと並行に実行する必要がなく、そのオブジェクトがブロックされている間実行を待つことが可能な場合に限ります。極端な場合、応答性が重要であると、アクティブ オブジェクトごとに個別のスレッドまたはプロセスが必要になります。

一般的には、上記の状況ではオーバーヘッドが少ないという理由から、本格的なプロセスの代わりに軽量のスレッドを使用する方が適しています。ただし、ある特別な場合には、プロセスの特殊な性質を活用したい場合もあります。スレッドは同一アドレス空間を占めるので、本来、プロセスよりも高い危険性があります。不意に上書きする可能性が心配な場合は、プロセスを使用するのが適しています。さらに、プロセスはほとんどのオペレーティング システムで独立したリカバリ単位であるため、互いに別個に回復する必要性に応じて、アクティブ オブジェクトをプロセスに割り当てることは役に立ちます。つまり、1 つのユニットとして回復する必要があるすべてのアクティブ オブジェクトは、同一プロセス内にパッケージ化できます。

システムが必要とする制御の流れごとにプロセスまたはスレッド (軽量プロセス) を 1 つ作成します。スレッドは制御の流れを入れ子にする必要性がある場合 (プロセス内で、サブタスク レベルで独立した制御の流れが必要な場合) に使用します。

たとえば、以下の目的のために別々の制御スレッドが必要になります (必ずしも重要性の順ではない)。

  • 異なるソフトウェアの分野間での懸念事項を分離します。
  • 分散システムのノードあるいは複数ノードで複数 CPU を活用します。
  • 制御スレッドがサスペンド状態になると、別の作業に CPU サイクルを割り当てて、CPU 使用率を上げます。
  • 作業に優先度を付けます。
  • 複数プロセスと複数プロセッサにわたる、負荷共有をサポートします。
  • バックアップ プロセスを用意して、システムの高い可用性を達成します。
  • DBMS、トランザクション マネージャ、あるいはそのほかの主要サブシステムをサポートします。

ATM (現金自動預払機) では、次の 3 つの異なるソースから発生する非同期イベントを処理する必要があります。システムのユーザー、ATM デバイス (キャッシュ ディスペンサが詰まった場合など)、および ATM ネットワーク (ネットワークからシャットダウン命令が出た場合など) の 3 つ です。このような非同期イベントを扱うために、次に示すように UML ではアクティブ クラスを使い、ATM 自体に 3 つの独立した実行スレッドを定義できます。

ATM 内のプロセスとスレッド

プロセスのライフサイクルの識別 ページの先頭へ

目的 プロセスとスレッドの生成および消滅時期を識別する。

各制御プロセスまたは制御スレッドを生成し、消滅させる必要があります。単一プロセス アーキテクチャの場合、アプリケーションの起動時にプロセスを生成し、アプリケーション終了時にプロセスを消滅させます。マルチプロセス アーキテクチャでは、新しいプロセス (またはスレッド) は、通常、アプリケーション起動時にオペレーティング システムが生成した最初のプロセスから派生したり、枝分かれしてできます。これらのプロセスも明示的に指定して消滅させる必要があります。

プロセスの生成および消滅だけでなく、プロセスの生成と消滅に至るイベントの流れもはっきりさせて文書化する必要があります。

ATM では、システム全体の振る舞いを調整する役割を担う主プロセスが開始されます。次に、この主プロセスが、次に示すシステムの構成部分を監視する下位の制御スレッドをいくつか派生します。つまり、システム内のデバイス、および顧客と ATM ネットワークから発生するイベントです。このようなプロセスとスレッドの生成は、UML ではアクティブ クラスとして示すことができます。また、このようなアクティブ クラスのインスタンスの生成は、次のようなシーケンス図で示すことができます。

システム立ち上げ中のプロセスとスレッドの作成

プロセス間通信メカニズムの識別 ページの先頭へ

目的 プロセスとスレッドが通信する手段を明確にする。

プロセス間通信 (IPC: Inter-Process Communication) では別プロセスで実行するオブジェクト間でのメッセージの送信を可能にします。

典型的なプロセス間通信メカニズムには次のものがあります。

  • 共有メモリ: 同期を保証するセマフォがある場合とない場合があります。
  • ランデブー: 特に Ada のような言語で直接にサポートする場合に使用します。
  • セマフォ: 共有リソースへの同時アクセスを防ぐために使います。
  • メッセージの受渡し: ポイント ツー ポイントとポイント ツー マルチポイントの両方があります。
  • メールボックス
  • RPC: 遠隔手続き呼び出し
  • イベントの送信:「ソフトウェア バス」(「メッセージ バス アーキテクチャ」) を使用します。

IPC メカニズムの選択はシステムのモデリング方法を変化させます。たとえば、「メッセージ バス アーキテクチャ」では、メッセージを送信するオブジェクト間に明確な関連は必要ありません。

プロセス間調整リソースの割り当て ページの先頭へ

目的 乏しいリソースを割り当てる。
潜在的な性能ボトルネックの予想と管理を行う。

プロセス間通信メカニズムは不十分な状態にあるのが一般的です。セマフォ、共有メモリ、およびメールボックスは、通常、大きさや数が決まっていて、相当な費用をかけないと増やせません。RPC、メッセージおよびイベントの送信は、乏しいネットワーク帯域幅をますます食いつぶしていきます。システムがリソースのしきい値を超えると、性能は非線形的に劣化していきます。乏しいリソースが枯渇した場合、それに対する要求を続けていけば好ましくない影響が出てくることが考えられます。

乏しいリソースに申し込みが殺到する場合には、以下のような検討すべき戦略がいくつかあります。

  • プロセス数を減らして乏しいリソースへのニーズを低下する。
  • 乏しいリソースの使用方法を変更する (1 つ以上のプロセスに対して、IPC メカニズム向けに使用するリソースはあまり乏しくない別のものを選択します)。
  • 乏しいリソースの量を増やす (たとえば、セマフォの数を増加します)。これは比較的小さな変更で実現できますが、副作用や決まった制約が多くなります。
  • 乏しいリソースを共有する (たとえば、必要なときにだけリソースを割り当て、終わったら解放します)。これは費用がかかる上に、リソース危機を未然に防ぐだけです。

どんな戦略を選んでも、システムは (クラッシュするより) ゆるやかに劣化すべきであり、システム管理者に適当なフィードバックを提供し、(もし可能なら) システムが導入された場合、フィールドで問題を解決できるようにすべきです。

システムが重要なリソースの可用性を増加させるために、特殊構成の実行時環境 (たとえば、オペレーティング システム カーネルの再構成による制御) を必要とする場合、システムのインストール時に自動的に行うか、あるいはシステムが運用可能となる前にシステム管理者に行わせる必要があります。たとえば、この変更が有効になる前に再起動が必要となります。

プロセスを実装環境へマッピング ページの先頭へ

目的 「制御の流れ」を実装環境がサポートする概念へマッピングする。

概念的プロセスは動作環境の個々の構成物へマッピングする必要があります。多くの環境では、プロセスのタイプに選択肢があり、最低でも、通常はプロセスとスレッドがあります。この選択は、結合度 (プロセスはスタンドアロンですが、スレッドは包括するプロセスのコンテキスト内で実行) およびシステムの性能要求 (スレッド間のプロセス間通信は通常、プロセス間の通信より高速かつ効率的) に基づいて行います。

多くのシステムでは、プロセス当たりのスレッド数、またはノード当たりのプロセス数に上限があります。このような制限は絶対ではありませんが、乏しいリソースの可用性からくる実用的な制限です。ターゲット ノードで既に実行しているスレッドやプロセスは、プロセス アーキテクチャで提案されているスレッドとプロセスと共に検討する必要があります。新たな性能上の問題を発生させないために、マッピングを行う場合は、以前のステップの結果である、「プロセス間調整リソースの割り当て」を考慮する必要があります。

設計要素を制御スレッドへマッピング ページの先頭へ

目的 どの制御クラスとサブシステムのスレッドを内部的に実行すべきかを決定する。

特定のクラスまたはサブシステムのインスタンスは、クラスまたはサブシステムの実行環境を提供する、少なくとも 1 つの制御スレッド内で実行しなければなりません。実際、そうしたインスタンスは複数の異なるプロセス内で実行することができます。

2 つの異なる戦略を同時に使うことで、「正しい」量の並行性を決定し、「正しい」プロセス群を定義します。

裏を表に

  1. 設計モデルから始め、クラスとサブシステムを、(a) 相互に密接に協力する、または (b) 同一の制御スレッドで実行する必要がある、連携要素のセットとしてグループ化します。要素を別々の制御スレッドにわける前に、メッセージ シーケンスにプロセス間通信を導入することの影響を考慮します。
  2. 逆に、相互作用のまったくないクラスとサブシステムを分離して、別々の制御スレッドに配置します。
  3. このクラスタ化処理を続けて、分散可能で物理リソースを使用可能な最小限の数までプロセス数を削減します。

表を裏に

  1. システムが応答する必要がある外部刺激を明確にします。各刺激を処理する個々の制御スレッド、および各サービスを提供する、サーバーの個々の制御スレッドを定義します。
  2. データの整合性とシリアライズの制約を検討し、初期の制御スレッドのセットを実行環境でサポート可能な数に減らします。

これは、最適なプロセス ビューにつながる直線的で決定論的なプロセスではなく、許容可能な妥協に達するまでには何回かの反復が必要です。

次に示すダイアグラムは ATM 内のクラスがシステム内のプロセスとスレッド間でどのように分散されているかを示しています。

クラスを ATM 用プロセスへマッピング



Rational Unified Process   2003.06.15