トピック

分析メカニズムの概論ページの先頭へ

分析メカニズムは、共通の問題に対する共通の解決法を構成するパターンを表します。分析メカニズムは、構造のパターンか振る舞いのパターン、またはその両方を表します。これらは分析中に使用され、複雑な振る舞いを簡略化した表現を設計者に提供することで、分析の複雑さを軽減し、一貫性を向上します。メカニズムを使用すると、分析の際に、機能要求をソフトウェア概念に置き換えることに集中でき、機能のサポートに必要だが重要ではない比較的複雑な振る舞いの仕様にとらわれずに済みます。分析メカニズムは多くの場合、1 つ以上のアーキテクチャ パターン分析パターンのインスタンス化の結果として発生します。

分析メカニズムは、アーキテクチャの中間レイヤと下位レイヤ内で複雑な技術の「プレースホルダ」を表すために主として使用されます。分析メカニズムをアーキテクチャ内の「プレースホルダ」として使用することで、アーキテクチャの構築の際にメカニズムの振る舞いの詳細に気をとられにくくなります。たとえば、オブジェクトのライフタイムが、ユース ケース、プロセスのライフタイム、システムのシャットダウンと起動の全体にわたる必要がある場合は、オブジェクトの永続性の必要を定義します。永続性は特に複雑なメカニズムであり、分析の間は、永続性を達成する方法の詳細に気をとられたくありません。このため、「永続性」分析メカニズムが発生しました。このメカニズムを使用すると、永続性メカニズムの詳細な機能や仕組みを気にせずに、永続オブジェクトについて語ることができ、永続性メカニズムでの要求を把握できます。

分析メカニズムは、(常にとは言えませんが) 通常は問題ドメインには関連がなく、「コンピュータ サイエンス」の概念です。したがって、通常はアーキテクチャの中間レイヤと下位レイヤを占めます。分析メカニズムは、ドメイン関連のクラスまたはサブシステムに特定の振る舞いを提供するか、クラスかサブシステム、またはその両方の連動の実装に対応します。分析メカニズムは、フレームワークとして実装できます。例としては、永続性、プロセス間コミュニケーション、エラーや障害の処理、通知、メッセージングなどを処理するメカニズムがあります。

ただし、さまざまなドメインでより多くの分析パターンが確立されていくにつれて、分析メカニズム内でこれらのパターンが部分的または完全にインスタンス化されるので、アーキテクチャの上位レイヤ内に分析メカニズムが現れるようになります。

分析メカニズムの例ページの先頭へ

  • 永続性

    インスタンスが永続的になる可能性があるすべてのクラスで、次の点を識別する必要があります。
    • 粒度: 永続性を保つオブジェクトのサイズの範囲
    • : 永続性を保つオブジェクトの数
    • 持続時間: オブジェクトを通常持続する必要がある時間
    • 取り出しのメカニズム: 特定のオブジェクトが一意に識別され、取り出される仕組み
    • 更新頻度: オブジェクトが更新される頻度が高いか低いか、更新が永続的であるか
    • 信頼性: プロセス、プロセッサ、システム全体のクラッシュ時にオブジェクトが破損しないようにすべきか

  • プロセス間コミュニケーション

    ほかのプロセスまたはスレッド内で実行するコンポーネントまたはサービスとコミュニケーションする必要のあるすべてのモデル要素で、次の点を識別する必要があります。
    • 遅延: プロセス相互のコミュニケーションがどのくらい速くなければならないか
    • 同期: 非同期コミュニケーション
    • メッセージのサイズ: 1 つの数より範囲のほうが適切な場合がある
    • プロトコル、フロー コントロール、バッファなど

その他の典型的なメカニズムには、次のものがあります。

  • メッセージのルーティング
  • プロセスのコントロールと同期
  • トランザクション管理
  • 情報交換
  • セキュリティ
  • 冗長性
  • エラー通知
  • 形式変換

分析メカニズムの記述ページの先頭へ

分析メカニズムを記述するプロセスは次のとおりです。

  1. リスト内のすべての分析メカニズムの収集

    ユース ケースの実現、または設計者が異なると、同じ分析メカニズムがさまざまな名前で示されることがあります。たとえば、記憶領域永続性データベースリポジトリがすべて 1 つの永続性メカニズムを指すことがあります。また、プロセス間コミュニケーションメッセージ パッシングリモート呼び出しがすべて 1 つのプロセス間コミュニケーション メカニズムを指すことがあります。

  2. 分析メカニズムへのクライアント クラスのマッピング
  3. 識別されたクラスとサブシステムは、識別された分析メカニズムにマッピングする必要があります。クラスがメカニズムを利用することを矢印で示します。1 つのクライアント クラスが複数のメカニズムのサービスを要求することも珍しくありません。

  4. 分析メカニズムの特性の識別

    広範な設計候補の中で区別するために、それぞれの分析メカニズムの限定に使用される主な特性を識別します。この特性の一部は機能、一部はサイズと性能です。

  5. コラボレーションを使用したモデリング

    分析メカニズムの識別と特定を終えたら、最終的には、「クラスの社会」のコラボレーションによってモデリングする必要があります (参考資料 [BOO98] を参照)。このクラスの中には、アプリケーションの機能を直接提供せずにサポートするためにのみ存在するものがあります。非常に多くの場合、これらの「サポート クラス」は、レイヤ化されたアーキテクチャの中間レイヤか下位レイヤ内にあるので、共通のサポート サービスをすべてのアプリケーション レベル クラスに提供します。

    識別されたメカニズムに十分に共通性がある場合、既存のクラスのバインディングと、必要な場合は新しいクラスを実装することでそのメカニズムをインスタンス化できるパターンがおそらく存在します。このようにして作成された分析メカニズムは抽象的になるので、設計と実装によって洗練する必要があります。

分析メカニズムについては、「成果物: ソフトウェア アーキテクチャ説明書」を参照してください。ソフトウェア アーキテクチャが成熟していくにつれて、「成果物: ソフトウェア アーキテクチャ説明書」には、分析メカニズムと設計メカニズムと実装メカニズムの関係 (すなわちマッピング)、そしてこれらの選択に関連する根拠が含まれます。



Rational Unified Process   2003.06.15