トピック

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

分析メカニズムは、共通問題に対する共通の解決策を構成するパターンを表します。分析メカニズムは構造パターン、動作パターン、またはその両方を表す場合があります。これらのパターンは、分析の複雑さを軽減するために分析時に使用され、また、複雑な動作の省略表記を設計者に提供することにより整合性を向上させるために使用されます。メカニズムによって、機能のサポートに必要ではあるが主要な要素ではない、比較的複雑な動作の仕様のために行き詰まることなく、機能要求をソフトウェアの概念に変換させることに分析作業を集中させることができます。分析メカニズムは多くの場合、1 つ以上のアーキテクチャーまたは分析パターンのインスタンス化の結果として得られます。 

分析メカニズムは、主にアーキテクチャーの中間レイヤーおよび下位レイヤーの複雑なテクノロジーの「プレースホルダー」を表すために使用します。メカニズムをアーキテクチャー内の「プレースホルダー」として使用することにより、メカニズムの動作によって生じるアーキテクチャー作業の混乱が軽減されます。例を挙げると、オブジェクトの存続時間がユース・ケース、プロセスの存続期間、またはシステムの終了および開始にまたがるようにする必要性は、オブジェクトの永続性へのニーズを定義付けます。永続性は特に複雑なメカニズムであり、分析時に、永続性をどのようにして達成するかといった詳細事項にとらわれることは好ましくありません。そこで「永続性」分析メカニズムが考案されました。この分析メカニズムによって、永続性メカニズムが何をどのように実行するかといった詳細を気にすることなく、永続オブジェクトについて検討し、それを永続性メカニズムにキャプチャーすることができます。

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

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

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

  • 永続性

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

  • プロセス間通信

    ほかのプロセスまたはスレッド内で実行するコンポーネントまたはサービスと通信する必要のあるすべてのモデル要素で、次の点を確認する必要があります。
    • 待ち時間: 必要なプロセス間通信の速度
    • 同期: 非同期通信
    • メッセージのサイズ: 単一の数値よりも範囲のほうが適切な場合があります。
    • プロトコル、フロー制御、バッファリングなど

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

  • メッセージ・ルーティング
  • プロセス制御と同期
  • トランザクション管理
  • 情報交換
  • セキュリティー
  • 冗長度
  • エラー・レポート
  • フォーマット変換

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

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

  1. すべての分析メカニズムをリストにまとめます。

    同じ分析メカニズムがいくつかの異なる名前で異なるユース・ケースの実現にまたがって表示されたり、異なる設計者によって表示される場合があります。例えば、ストレージ永続性データベース、およびリポジトリーがすべて永続性メカニズムを示すことがあります。あるいは、プロセス間通信メッセージ・パッシングリモート呼び出しはすべてプロセス間通信メカニズムを示すことがあります。

  2. 分析メカニズムへのクライアント・クラスのマッピング
  3. クラスと分析メカニズムとの関係を示す図

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

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

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

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

    分析メカニズムを識別し、指定した後、最終的に、「クラスのソサエティー」のコラボレーションによってモデル化する必要があります (「BOO98」を参照)。このクラスの中には、アプリケーションの機能を直接提供せずにサポートするためにのみ存在するものがあります。ほとんどの場合、これらの「サポート・クラス」は階層化アーキテクチャーの中間レイヤーまたは下位レイヤー内にあり、共通のサポート・サービスをすべての適用レベルのクラスに提供します。

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

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

分析メカニズムの応用ページの先頭

パターンと変換ページの先頭

バックグラウンドページの先頭

「あるコンテキストで有効であることが証明された、繰り返し発生する問題へのソリューション・テンプレート」 (用語集定義より抜粋) としてのパターンのアイデアはきわめて一般的です。このように定義されたパターンを応用 (インスタンス化) するには、解決する問題の特異性とスケールに従って、数多くのモデル変更を行う必要があります。こうした観点からのパターンの応用とそれに伴うメカニズムのインスタンス化は、モデル変換 によって実行されます。例えば、上記で定義されたメカニズムの 1 つであるセキュリティーでは、セキュリティー・メカニズムの基本となる任意のパターンはパーベイシブであり、モデル要素ごとに異なる変更が必要になります。セキュリティー・パターンの定義は UML プロファイル に記述されています。 UML プロファイルは、モデル化における特定のテクノロジー、規律、ドメイン、その他の領域を定義し、制約するステレオタイプ、タグ付き値、制約をキャプチャーする、標準化された方法です。これは基本的に、プラットフォーム (『概念: モデル駆動型開発およびモデル駆動型アーキテクチャー (Concepts: Model-Driven Development and Model Driven Architecture)』®を参照) であるため、「一般的パターン」を実装する 1 つ以上の変換のアイデアがここで適用されます。

この観点から、パターン (一般的) と変換との関係を示した図は次のようになります。

この図では、一般的パターンから派生した (一般的パターンを実装する) 変換を示しています。

ただし、多くの場合に共通するのは、パターンがより制約されたものとなる点です。この観点から、これは 1 種の変換 (ソース・モデルに適用され、その結果変更されたモデルが作成される) といえますが、入念な変更が行われてローカルに (例えば複数のステップの 1 つに)適用されます。ソース・モデルとターゲット・モデルはほぼ同じ広範囲な抽象化レベルに存在します。これら 2 つのモデルは、同一モデルとみなすことができます。例えば、あるパターンをパラメーター化されたコラボレーション形式で設計モデルに適用し、このパターンがテクノロジー固有のものでない場合は、適用結果を設計モデルと呼ぶことができます。分析パターン、設計パターン、および実装パターン (イディオム) の場合は、これを RUP にミラーリングします。この観点から、パターンと変換との関係 (ここでは抽象クラスとして示します) は、次のように視覚化されます。

この図では、パターンの概念は、すでに制限したように、抽象クラスのサブクラスとして示されています。

より具体的なパターンの用途について、次に説明します。

高い抽象化レベルで継続的に作業を進めることを望むソフトウェア・アーキテクトとして、必要な分析メカニズムとそれをサポートするパターンを (大小含めて) 識別し、特徴付けました。次に自動化された変換を使用して、これらを実装します。分析と設計を進める中で、事前にモデル変換を可能な限り自動化して、最終的に、単にコードを直接反映させるのではなく、高い抽象レベルの UML モデルを使用したコード化に移行することを目標とします。

変換のアプローチページの先頭

『概念: モデル駆動型開発およびモデル駆動型アーキテクチャー (Concepts: Model-Driven Development and Model Driven Architecture)』®に、複数の変換アプローチの概要が記述されています (『変換の実行方法 (How is Transformation Performed?)』を参照)。. 具体的な例を挙げると、Rational ソフトウェア・アーキテクトは、タイプ・マッピングの組み合わせ (例えば、ソース・モデルのクラス、その属性、オペレーション、および関係がターゲット・エレメントにどのような影響を与えるかを判別する) およびソース・モデル・マーキング (いずれもプロファイルによって使用可能になります) に基づくアプローチをサポートします。

このアプローチでは、通常、ソース・モデルにはタイプ・マッピングによる変換を完全にガイドする十分な情報が含まれないことが認識されます。ソフトウェア・アーキテクトはプロファイルで定義されるステレオタイプなどのマークをソース・モデルに追加して、変換を完全に指定できます。ターゲット・プラットフォームの概念を表すこれらのマークは、ソース・モデルの一部ではありませんが、ソース・モデルをオーバーレイします。変換を駆動する規則はターゲット・プラットフォームの定義、例えば関連したプロファイルと、ソースで使用するタイプからターゲットで使用するタイプへのマッピングから導き出されます。

変換規則を設定し、ソースをマークしたため、変換を実行できます。Rational ソフトウェア・アーキテクトはさらに、例えばプロファイルや関連したマークからは導くことができない情報を指定するために、変換にパラメーターを提供できるようにします。このようにシステマティックにモデル変更をマーキングすることにより、変換レコードが生成、保存されるという追加的な利点が得られます。したがって、ソース・モデルからターゲット・モデルへの強力な追跡可能性が保持されます。

具体的な例を挙げると、Rational ソフトウェア・アーキテクトは、変換の一般的な概念を変形 およびパターン に具体化します。提案された定義は、Rational ソフトウェア・アーキテクトで使用されるものです。

変形 ページの先頭

変形は、「主に全般的なメタモデル、モデル、抽象レベルにおいて、バッチ処理のために最適化された変換です。」 通常、変形を適用した結果、例えば UML モデルに基づくテキスト・コード・モデルなどとは明らかに異なるモデルが作成されます。これは概念上の変更を伴う、大きなジャンプです。

パターン ページの先頭

パターンは、「主に単一のメタモデルで同一の抽象レベルにおいて、また多くの場合、同一のモデルにおいて、対話式の区分的推敲のために最適化された変換です。」 この定義により、UML モデルにパターンを適用した結果得られるのは同じく UML モデル で、多少推敲されている可能性がありますが、同一の抽象レベルであることは明らかです。

変換、パターン、および変形の関係によって、前の図が次のように詳細になります。

この図では、変換のサブクラスとして変形が追加されています。

より厳密なこのアプローチによって、プロファイルおよびプロファイルから派生した変形がそれぞれ重要なエンティティーになるという、もう 1 つの結果が得られます。ソフトウェア・アーキテクトは、変換の準備において行われた作業を再利用することにより有効活用することを望みます。変換のライブラリーを作成すれば、1 回限りの変換がほとんどなくなることが予想されます。このようなライブラリーは、例えばソフトウェア・アーキテクトが、識別された必要な分析メカニズムの特性に変換を簡単にマッチングできるように、変換のプロパティーによって検索可能またはブラウズ可能とすることが必要です。

Rational ソフトウェア・アーキテクトを使用した変形の実行に関する詳細は、次のようなさまざまな Rational ソフトウェア・アーキテクト・チュートリアルおよびサンプルで参照できます。

  • チュートリアル: XYZ パターンの適用 (Tutorial: Applying the XYZ Pattern)
  • チュートリアル: パターンの拡張 (Tutorial: Extending Patterns)
  • サンプル: パターン応用のモデル (Sample: Model for Pattern Application)
  • サンプル: パターン (Sample: Pattern)
  • サンプル: 拡張するパターン (Sample: Pattern to Extend)
  • チュートリアル: 設計: モデルからコードへの変換 (Tutorial: Design: Transform Model to Code)
  • チュートリアル: 設計: モデルからモデルへの変換 (Tutorial: Design: Transform Model to Model)
  • サンプル: 変形の適用 (Sample: Apply Transform)
  • サンプル: 第 1 変形の構築 (Sample: Building a First Transform)
  • サンプル: モデルからモデルへの変形の構築 (Sample: Build a Model to Model Transform)
  • サンプル: テキストを生成する変形の作成 (Sample: Create a Transform that Generates Text)
  • サンプル: 他の Rational ソフトウェア・アーキテクト・ユーザーへの変形の配置 (Sample: Deploy a Transform to other Rational Software Architect Users)

 

Rational Unified Process   2003.06.15