14.3.2.例：Quantitative System Performance
14.3.2. 例
ここに、この一般的方法の適用を示す単純な例がある。蓄積交換コンピュータ通信ネットワークが設計されつつある。我々の目的は、計画された使用法やソフトウェア設計やサポートするハードウェアについての情報が与えられた場合に、このネットワークの性能を予測することである。
ネットワークのトポロジー（スター）とプロトコル（ポーリング）は既知である。システムは３種類のメッセージ、STORE, FORWARD, FLASHをサポートするものとする。基本仕様から、各々のメッセージ・タイプの到着レートや優先度や応答時間の要求を得ることが出来る。個々のメッセージ・タイプはさまざまな特性を持ち作業負荷のささいでない部分を表現しているので、各々を別々の作業負荷要素とみなし、それぞれを異なるクラスに割り付けるのが自然である。意図されたプロトコルの知識が与えられると、４番目のクラスが定式化され、ポーリングのオーバヘッドを表現する。このクラス構造のさらなる改善はプロジェクトの進展の間に可能である。
個々のクラスのソフトウェア仕様は最初の段階では不明確である。ソフトウェアの機能や制御のフローや処理要求に関する高レベルの情報のみが使用可能である。個々のクラスについてのＣＰＵとＩ／Ｏのリソース要求量の全体での見積もりは得られている。ＣＰＵ要求量はそのタイプの個々のメッセージについての命令数の見積りと、論理Ｉ／Ｏ操作の回数の見積りを指定する。一例としてSTOREメッセージについてＩ／Ｏはメッセージ保管エリアを位置づけるためのインデックスへのリードとメッセージを保管するためのライトと、インデックスをアップデートするためのライトから成る。ここではファイル配置やデバイス特性に関する指示は何も与えられていない。その代わり、ソフトウェアの論理的特性が強調され、ソフトウェア設計がより成熟する時のさらなる改善のための基礎としての役割を持つ。
スピード、容量、ファイル配置などのデバイス物理特性が特定される。ＣＰＵはそのMIPSレートとそのプロセッサ数で特徴づけられる。ディスクはその容量と平均シーク時間、回転時間、転送レート、ファイルのディスクへの割付によって特徴づけられる。ソフトウェア仕様とデバイス特性の考慮からサービス要求時間を見積ることが出来る。単純な例として、あるソフトウェア設計者が STOREメッセージについて60,000 CPU命令を見積り、ハードウェア構成分析者がＣＰＵ MIPSレートを0.40と見積るとする。これはＣＰＵについてのSTOREのサービス要求時間として0.15秒を導出する。これは大ざっぱな見積りであることは認めざるを得ないが、これは基礎の役割をはたし、より詳細はそれ以降組み込むことが出来る。
この時点で、設計と、組み込むクラスとデバイスとサービス要求時間の待ち行列ネットワーク・モデルを、性能の最初の評価を与えるために構築し評価することが出来る。選択肢の性能への効果を決定するために選択肢を評価することが出来る。プロジェクトのこの早期であってさえ、潜在的なトラブルのある箇所を特定するために感度分析を用いることが出来る。
この方法の強みの一つは作業負荷やソフトウェアやハードウェアの変更を容易に扱う能力である。この例では、内部モジュールの制御フローは特定されておらず、処理要求量は全体の近似であった。設計が進むにつれて、個々のモジュールが、図１４．１に反映されるようにより細かい構造を得始める。ソフトウェア仕様を修正することでこれを反映させることが出来る。この構造は設計が成熟するにつれて複数の詳細レベルを得る。ツリーの葉でのサブモジュールは特定の操作についてのより詳細な情報を表現している。ソフトウェア設計者は、これらのタイプのモジュールについて指定されたリソース見積りにより確信を持っている。ある作業負荷の総リソース要求量は詳細なモジュール構造のさまざまなレベルでリソース要求量を適切に合計することで見い出される。よってより多くの情報が利用可能になるにつれてソフトウェア仕様は更新出来る。
- 図１４．１ ソフトウェア仕様の改良
この例で我々が示した重要な特徴は、適切な詳細レベルでの作業負荷とソフトウェアとハードウェアの特定と、これらの高レベルの要素の待ち行列ネットワーク・モデルのパラメータへの変換と、基本要素の変更を表現する能力である。
