概念 設計メカニズムと実装メカニズム
トピック
設計メカニズムは、対応する分析メカニズムを洗練したものです (「概念: 分析メカニズム」を参照)。
設計メカニズムは、概念的な分析メカニズムに具体的な詳細を追加しますが、特定の技術 (たとえば、特定のベンダーのオブジェクト指向データベース管理システムの実装) を要求するまでには至りません。
分析メカニズムと同様に、設計メカニズムは 1 つ以上のパターン (この場合はアーキテクチャー・パターンまたは設計パターン) をインスタンス化できます。
同様に、実装メカニズムは、対応する設計メカニズムを洗練したものであり、その際に、特定のプログラミング言語などの実装技術を使用します (たとえば、特定のベンダーのミドルウェア製品)。実装メカニズムは、1 つ以上のイディオムまたは実装パターンをインスタンス化できます。
たとえば、永続性のための分析メカニズムが、次のとおりだとします。
- 多数 (2,000) の小さいオブジェクト (各 200 バイト) を数秒間格納する必要があり、その後オブジェクトを保持する必要はない
- いくつかの非常に大きいオブジェクトを数か月間ディスク上に永続的に格納し、これらのオブジェクトは更新しないが、高度な取り出し方法を使用できる必要がある
これらのオブジェクトでは、異なる永続性のサポートが必要になります。永続性サポートのための設計メカニズムの特性を、たとえば次のように識別します。
- メモリ内記憶領域: 特性: 最大で合計 1MB (サイズ x 量)、読み書きと更新のアクセスが非常に速い
- フラッシュ カード: 特性: 最大で 8MB、更新と書き込みのアクセスが遅い、読み取りのアクセスは中程度
- バイナリ ファイル: 特性: 100KB ~ 200MB 用、更新が遅い、読み書きのアクセスが遅い
- データベース管理システム (DBMS): 特性: 100KB 以上 (実質的に上限なし)、更新と読み書きのアクセスがさらに遅い
速度が「遅い」となっているものは、メモリー内記憶領域を基準にしています。
当然ながら、環境によっては、キャッシュ処理の使用でアクセス時間の短縮が感じられます。

最初のうちは、設計メカニズムと実装メカニズムの間のマッピングが最適のものとは到底思えませんが、これによってプロジェクトを稼働させ、まだ目に見えないリスクを識別し、さらなる調査と評価を誘発することになります。プロジェクトが進行し、知識が増えるにつれて、このマッピングを洗練する必要が出てきます。
設計メカニズムと実装メカニズムの間のマッピングを反復的に洗練し続け、冗長なパスを取り除き、「トップダウン」と「ボトムアップ」の両方で作業します。
トップダウンでの作業。「トップダウン」で作業すると、新しい洗練されたユース・ケースの実現によって、必要な分析メカニズムを通して、必要な設計メカニズムに新しい要求が加えられます。
このような新しい要求によって、設計メカニズムに追加の特性が発見され、メカニズムが強制的に分割されることがあります。
システムの複雑さと性能の間で次のような妥協もあります。
- 設計メカニズムの種類が多すぎるために、システムが複雑になりすぎる
- 設計メカニズムが少なすぎるために、特性値が適正範囲外の一部の実装メカニズムで性能の問題が生じる可能性がある
ボトムアップでの作業。「ボトムアップ」で作業すると、使用可能な実装メカニズムの調査で、一度に複数の設計メカニズムを満たしていても、設計メカニズムになんらかの調節またはパーティション再作成が必要な製品が見つかることがあります。
使用する実装メカニズムの数を最小限にしようと思うかもしれませんが、少なすぎても性能の問題が生じる可能性があります。
DBMS を使用してクラス A のオブジェクトを格納することを一度決定すると、システム内のすべてのオブジェクトの格納に DBMS を使用したくなるかもしれません。そのようにすると、きわめて非効率的で扱いにくくなることがあります。永続性が必要なすべてのオブジェクトを DBMS に格納する必要があるとは限りません。永続的なオブジェクトであっても、そのアプリケーションからのアクセス頻度が高く、ほかのアプリケーションからのアクセス頻度は低い場合があります。オブジェクトを DBMS からメモリに読み出し、定期的に同期する複合戦略が最適です。
例
便名を高速アクセスのためにメモリに格納し、長期の永続性のために DBMS に格納することができます。ただし、1 つのメカニズムが両方に同期することが必要になります。
異なる特性の妥協として、1 つのクライアント クラスに関連する設計メカニズムが複数あることは珍しくありません。
実装メカニズムは市販のコンポーネント (オペレーティング システムやミドルウェア製品) にバンドルされることが多いので、コストまたはインピーダンスの不整合に基づいた最適化、スタイルの統一が必要になります。また、メカニズムは相互に依存することが多いので、サービスを設計メカニズムに明確に分離することが困難です。
例
推敲フェーズ全体で洗練が続けられ、洗練は常に次のものの妥協になります。
- 期待される特性に関して、設計メカニズムのクライアントの要求との完全な「適合」
- 獲得と統合が困難になるほど種類が多い実装メカニズムを持つことのコストと複雑さ
総合的な目標は常に、概念的な整合性、単純さ、簡潔さを大規模システムに与える単純明瞭なメカニズムのセットを持つことです。
永続性設計メカニズムは、次のように実装メカニズムにマッピングできます。

分析メカニズムと設計メカニズムとの間で可能なマッピング。
点線の矢印は「特化」を意味し、設計メカニズムの特性が分析メカニズムから継承されても特化と洗練が行われることを示します。
メカニズムの最適化を終えると、次のようなマッピングになります。

メカニズム間のマッピングに関するクライアント クラスの設計の決定。「便名」クラスには、2 つの形式の永続性が必要です。1 つは、既製のライブラリ ルーチンによって実装されるメモリ内記憶領域、もう 1 つは、市販の ObjectStorage 製品と共に実装されるデータベースへの格納です。
実装メカニズムを変更するときにクライアント クラスを簡単に決定できるように、このマップは両方向への移動が可能でなければなりません。
設計メカニズムとその使用法の詳細は、「 成果物: プロジェクト固有のガイドライン」に記述されます。分析メカニズムと設計メカニズムと実装メカニズムの関係 (またはマッピング)、これらの選択に関連する根拠は、「成果物: ソフトウェア アーキテクチャ説明書」に記述されます。
分析メカニズムと同様に、コラボレーションを使用して設計メカニズムをモデリングし、1 つ以上のアーキテクチャー・パターンまたは設計パターンをインスタンス化できます。
例: 永続性メカニズム
この例では、JDBC™ (Java Data Base Connectivity) から描画された RDBMS に基づく永続性のパターンのインスタンスを使用します。
ここでは設計を示しますが、JDBC は一部のクラスには実際のコードを提供するので、ここに示す設計から実装メカニズムへの近道になります。
次の「静的ビュー: JDBC」の図は、コラボレーション内でのクラス (厳密には分類子ロール) を示しています。
静的ビュー: JDBC
黄色で塗りつぶされたクラスは、供給されたクラスです。それ以外 (myDBClass など) は、メカニズムを作成するために設計者によってバインドされました。
JDBC では、クライアントが DBClass を操作して永続データを読み書きします。
DBClass は、DriverManager クラスを使用して JDBC データベースのアクセスを担当します。
データベース Connection が開かれると、DBClass は、Statement クラスを使用して、基礎となる RDBMS に送信されて実行される SQL ステートメントを作成できます。
Statement クラスは、データベースと「会話」します。
SQL クエリーの結果は ResultSet オブジェクトに返されます。
DBClass クラスは、別のクラスのインスタンスを永続的にします。
このクラスは OO から RDBMS へのマッピングを理解し、RDBMS とのインターフェースとして振る舞います。
DBClass はオブジェクトをフラット化して RDBMS に書き込み、RDBMS からオブジェクト・データを読み取ってオブジェクトを構築します。
永続的なクラスはすべて、対応する DBClass を持ちます。
PersistentClassList は、データベース クエリー (例: DBClass.read()) の結果として永続オブジェクトのセットを返すために使用されます。
ここで一連の動的ビューを使用して、メカニズムの実際の仕組みを説明します。
JDBC: 初期化
永続クラスをアクセスできるようにするには、まず初期化しなければなりません。
データベースへの接続を初期化するには、DBClass が URL、ユーザー、パスワードを指定して DriverManager getConnection() 操作を呼び出して、適切なドライバをロードしなければなりません。
getConnection() 操作は、指定されたデータベース URL への接続を確立しようとします。DriverManager は、登録された JDBC ドライバのセットから適切なドライバを選択しようとします。
パラメーター:
url: jdbc:subprotocol:subname 形式のデータベース URL。この URL は、実際のデータベース サーバーを見つけるために使用され、このインスタンス内では Web に関連していません。
user: このデータベース ユーザーのために Connection が確立されます。
pass: ユーザーのパスワード。
戻り値:
URL への Connection。
JDBC: 作成
新しいクラスを作成するために、永続性クライアントは作成を DBClass に依頼します。DBClass は新しいインスタンスの PersistentClass をデフォルト値で作成します。次に、DBClass は、Connection クラスの createStatement() 操作を使用して新しい Statement を作成します。この Statement が実行され、データベースにデータが挿入されます。
JDBC: 読み取り
永続クラスを読み取るために、永続性クライアントは読み取りを DBClass に依頼します。DBClass は、Connection クラスの createStatement() 操作を使用して新しい Statement を作成します。この Statement が実行され、ResultSet オブジェクトにデータが返されます。次に、DBClass は新しいインスタンスの PersistentClass を作成し、取り出されたデータを入れます。このデータは、PersistentClassList クラスのインスタンスであるコレクション オブジェクト内に返されます。
メモ: executeQuery() に渡される文字列は、read() に渡される文字列と必ずしもまったく同じではありません。DBClass は、read() に渡される基準を使用して、データベースから永続データを取り出す SQL クエリーを構築します。なぜなら、DBClass のクライアントが、有効なクエリーを作成するためにデータベースの中身の知識を必要とするようにしたくないからです。この知識は DBClass の中にカプセル化されます。
JDBC: 更新
クラスを更新するために、永続性クライアントは更新を DBClass に依頼します。DBClass は特定の PersistentClass オブジェクトからデータを取り出し、Connection クラスの createStatement() 操作を使用して新しい Statement を作成します。この Statement が一度構築されると、更新が実行され、このクラスからの新しいデータでデータベースが更新されます。
PersistentClass を「フラット化」してデータベースに書き込むのは DBClass の担当です。
このため、SQL ステートメントを作成する前に特定の PersistentClass から取り出さなければなりません。
メモ: このメカニズムでは、PersistentClass はアクセス ルーチンをすべての永続データに提供し、DBClass がアクセスできるようにしなければなりません。これにより、通常は非公開になっている特定の永続属性への外部アクセスが提供されます。データをカプセル化するクラスから永続性の知識を引き出すには、この代償を払う必要があります。
JDBC: 削除
クラスを削除するために、永続性クライアントは DBClass に PersistentClass の削除を依頼します。DBClass は、Connection クラスの createStatement() 操作を使用して新しい Statement を作成します。この Statement が実行され、データベースからデータが削除されます。
この設計の実装では、DBClass と永続クラスのマッピングについていくつかの決定をします。たとえば、永続クラスごとに 1 つの DBClass を持つようにし、適切なパッケージに割り当てます。
このパッケージは、供給される java.sql (「JDBC™ API Documentation」を参照) パッケージに依存し、このパッケージには、サポート・クラスである DriverManager、Connection、Statement、ResultSet が含まれます。
|