*begin*back*foward*end*contents

開発モデル編 -
第18章 再利用基盤モデル

18.1 再利用基盤モデルとは

再利用基盤モデルとは、再利用可能なコンポーネントを段階的に構築するための高次元モデルのことをいう。高次元モデルとは、クラスを単位とする分析では捉えることができないものを指している。

クラスという単位として構造を捉えきれないものの例を以下に示そう。

  • コンポーネント、フレームワークなどのような再利用部品の利用者から見える論理単位
  • クラスライブラリ全体における一貫した例外処理やエラー処理
  • 構築されている再利用部品の中で一貫性のあるメソッド体型や呼び出すためのルール

上記のような複数のクラス間にまたがる問題を解決し、優れた実装をするためには、クラスの単位よりも高い次元の視点で分析・設計手法が必要となる。

このような高次元分析手法は、高品質のソフトウェアを生産するというだけでなく、再利用性、保守性の高いソフトウェア構築を目指すために必要である。どんなソフトウェアでも、保守性を高めることは構築するソフトウェアが発展する限り重要なことである。また、オブジェクト指向技術を駆使して再利用性を高めることは、企業およびソフトウェア開発者の戦略として重要なものとして位置づけられなければならない。

Dropでは、このようなソフトウェア領域に対する高次元の分析手法を再利用基盤モデルと総称している。

再利用基盤モデルによる分析では、図18-1に示すように、分析対象であるソフトウェアを4つのレイアに分類することができる。

sorry this is image
図18-1 高次元分析におけるレイア構造

18.2 クラスレイアカテゴリ図

クラスレイアカテゴリ図(図18-2)は、クラスライブラリを構築する際に、「役割」と「再利用範囲」というレイアによってクラスを分類し、整理していくための図式表現である。クラスレイアカテゴリ図は、ODG中心のコンポーネント分析フェーズにおいて主に利用され、コンポーネント設計フェーズでは、再利用基盤モデルを指針として個々のクラスが設計される。また、ADG中心のシステム共通設計フェーズにおいてシステム共通コンポーネントを設計する際にも使われる。

クラスレイアカテゴリ図は、横のレイアとして役割(View、Process、DataManage)を持ち、縦のレイアとして再利用範囲(App、AppParts、Generic)を持つ。9つに分割された空間はレイアスペースと呼ばれ、そこにはクラスをグループ化したカテゴリを入れる。

カテゴリとは、クラスを意味のある単位にグループ化したものであり、2重線の矩形で記される。 カテゴリは、コンポーネント利用者がコンポーネントを探しだす手がかりとなるようなクラスグループの役割を名前として持つ。また、コンポーネント設計者にとってのカテゴリ分類は、再利用範囲と依存関係の基本指針となるものである。

たとえば、データベース関連のカテゴリはDBAccessというカテゴリになり、その中には、DBTable、DBDatabases、DBColumnといったクラスが属するだろう。また、Set、Bag、List、Stackといったオブジェクトの集合を管理するクラスはCollectionというカテゴリに属するだろう。DBAccessからCollectionに引かれている点線矢印は、DBAccessはCollectionに依存しているという線である。つまり、DBAccessカテゴリを利用するにはCollectionカテゴリも必要となるということを明示している。 小規模な開発や再利用コンポーネントが構築していない段階ではクラスをわざわざカテゴリにしなくともよい。そのような時には、レイアスペースにクラス(矩形)を直接入れることもできる。

sorry this is image
図18-2 クラスレイアカテゴリ図

それぞれのレイア分類についての詳細を表18-1に示そう。

表18-1 クラスレイアカテゴリ図の意味
意味
再利用レイア Generic システムに特化しないレイアである。このレイアのサブレイアとして、マシン依存・処理依存という分類をする場合もある。このレイアに存在するクラスは最も再利用性が高い。
AppParts システムに特化しているが、類似システムに再利用することができるレイアである。類似システムに再利用できるフレームワークなどがこのレイアに分類される。
App 基本的に再利用を考慮せずに設計するレイアである。
役割レイア View View(見せ方)の制御を行うレイアである。
Process 処理や状態などの制御を主体とするレイアである。
DataManage 永続的なデータの管理を主体とするレイアである。

クラスレイアカテゴリ図を使う意義と効果

クラスレイアカテゴリ図を使って、なぜクラスを役割別に分類しなければならないのだろうか?またそのような分析手法の効果とは何だろうか?ここではこのようなクラスレイアカテゴリを使った意義と効果について明確するために、スキューバダイビングショップの精算管理システムを例にしながら解説しよう。このシステムは、ダイビングコースの選定、レンタル機材の貸し出しなどといった予約・精算を行うものとする。

1.役割レイアに分類する意義

View、Process、DataManageのレイアにオブジェクトを分類する意義は、変更や拡張、保守の容易な安定した構造のモデルを作りやすいという点にある。また、非常に基本的で現実的なオブジェクト分類手法でもある。以下に各レイアの特徴と分類方法を示す。

DataManageはViewから切り離して設計される

問題領域特有のデータ管理(DataManage)はウインドウ処理(View)と切り離して使われる。なぜなら、もしウインドウ処理の中に問題領域特有のデータ管理が組み込まれていたならば、そのデータを他のウインドウから利用することができない。

ダイブショップの精算管理システムでは、まず、お客にダイビングコースや機材貸し出し要否、精算方法等を確認し、ダイビングスケジュールをソフトウェアシステムに入力する。その後、お客がダイビングから帰ってきたら、検索画面でそのお客のダイビング情報を表示して精算処理を行う。また、このシステムには、数ヶ月前からダイビングコースや機材を予約する機能も必要だろう。

このような単純なソフトウェアシステムにおいても、図18-3のようにダイビングスケジュールデータを管理するオブジェクトは、「ダイブスケジュール入力画面」「精算画面」「機材チェックアウト画面」などといった画面を構成するオブジェクトとは別のクラスとして設計しなければならない。なぜなら、複数の画面は1つのダイビングスケジュール情報に対して参照したり更新したりするという関係にあり、共有されるダイビングスケジュール情報は永続的なデータとして切り離しておく必然性がある。

sorry this is image
図18-3 Viewから分離されたDataManage

ProcessはDataManageとViewを結びつける役割を果たす

Processは、制御中心のオブジェクトと考えてよい。ここで制御とは、ビジネスオブジェクトなど対象システム固有の制御処理や、もっとソフトウェア領域に特化した、たとえばプロセス管理のようなものでもProcessに属する。

このように、Processに属するオブジェクトは制御中心という決めごとだけであり、その範囲は非常に広いものといえる。

Processに属するオブジェクトの役割の1例として、ViewとDataManageを結びつける役割がある。たとえば、ViewがProcessを持っており、Viewにきたイベントをきっかけに、ProcessがDataManageオブジェクトにアクセスして何らかの加工を行い、Viewに渡すという関係である。

DataManageをアクセスして何らかの加工をおこなうロジック部分をProcessとして構築することで、画面に依存しない制御部分から再利用可能なコンポーネントを抽出するチャンスが生まれる。

これを、ダイブショップ精算管理システムを例に示すと、図18-4のように「ダイブスケジュール登録・変更」や「ダイブスケジュール検索」を行うDivingShopクラスを作り出すことである。Viewはこのクラスによって、取得したいDataManageに属するオブジェクトと関係を持つことができる。

sorry this is image
図18-4 DataMangeから分離されたProcess

DataManageには基本的な機能のみを割り付ける

ここまでの解説でViewとDataManageを切り離す理由は理解できるだろうが、DataManageとProcessを分類させなければならない理由が不明確に思えるだろう。ここでその理由について触れたい。それは、DataManageの役割に起因している。DataManageは、対象ソフトウェアにおける永続的なデータを管理するオブジェクトである。このような永続的なデータを管理するオブジェクトの設計で心がけなければならないことは、「永続オブジェクト自身の持つデータや自分の集約するオブジェクトを管理することだけに集中させる」ということである。もし、関連の薄い他の永続オブジェクトをアクセスするような設計にしてしまうと、そこにオブジェクト間の広域な制御機能を実現してしまうことになる。これは一見便利そうに思えるが、実は以下のような問題を抱え込むことになる。

  • 永続クラスが複数あるとき、どの機能をどのクラスに割り付けるべきか判断がつきにくい。
  • その機能を使うときには、かならずそのデータ管理インスタンスを見つけなければならない。
  • 制御機能の拡張がなされた時に、個々のデータ管理クラスに割り付けられた機能を変更しなければならない。

上記問題を、ダイブショップ精算管理システムを例に取って解説すると、図18-4のDivingShopクラスに割り付けられた「ダイブスケジュール登録・変更」や「ダイブスケジュール検索」をどのDataManageに属するクラスに割り付ければよいのか悩んでしまうということになる。結局のところ、悩んだあげくにデータ管理を行うクラスとは別のクラス(Process)を新たに作ることになるだろう。

このような問題は、以下のような、オブジェクトに対する本質的な種別の違いからくるものである。

  1. DataManageに属するオブジェクトはProcessに属するオブジェクトとライフサイクルが異なる
  2. DataManageに属する複数のオブジェクトを複数使い加工することで、要求された機能を実現するため、個々のDataManageに機能を割り付けられない。
  3. DataManageの管理する永続データは、対象ソフトウェアの機能で分類されたProcessよりもソフトウェア拡張・変更といった変化が少ない部分である

ここで、「3.」について説明しよう。もしソフトウェア化すべき問題領域に永続的なデータがあるとすれば、そのデータにまず注目すべきである。なぜなら、DataManageに属するオブジェクトのような、問題領域にあるデータをグループ化したオブジェクトをモデリングによって作り出すことは、ソフトウェア化における変化の少ない箇所に着目していることに他ならないからである。

Dropでは、問題領域分析フェーズによってこれを行う。つまり、問題領域の中で変化の少ない箇所に着目し、そこを集中的に分析することで、変化に強い安定した分析の基盤を確立しようとするのである。

これについては、「DataManageはなぜ本質的なオブジェクトと呼べるのか」でもっと深く解説しよう。

ソフトウェア領域に対する依存性によって分類する

ソフトウェア依存性が低い順にレイアを並べると、DataManage、Prosess、Viewの順となる。

DataManageはソフトウェア領域に依存しないレイアである。なぜなら、DataManageに属するオブジェクトは、対象の問題領域の中の情報を永続データとして取り扱うためのものであり、このようなオブジェクト分析にはそれをどこで実現するかといったソフトウェア領域には関係ない。DataManageの次にソフトウェア領域に依存しないレイアはProcessである。Processの中には、完全にソフトウェアアーキテクチャに依存する共有メモリ管理などのコンポーネントも存在するだろうが、問題領域のビジネスロジックをカプセル化したオブジェクトも存在している。後者は、ソフトウェア領域に依存せず分析・設計が可能である。最もソフトウェア領域に依存してしまうレイアがViewである。これは、ウインドウシステムなどを使ってDataManageが管理するデータの見せ方を定義したり、ソフトウェア利用者からイベントを受け取り、そのイベントをProcessに通知するためだけにあり、ソフトウェア領域に完全に依存している。

このように依存度が異なるレイアを明確にすることも、ソフトウェア領域に依存しない部分を増やすことにつながり、再利用性が高まることになる。また、ソフトウェアに依存しにくいレイア「DataManage」「Prosessの1部分」は、問題領域分析の対象となる。一方、ソフトウェアに依存するレイア「View」「Processの1部分」はコンポーネント分析やシステム共通設計の対象となる。このようにODG開発サイクルとADG開発サイクルの対象とするオブジェクトをレイアを使って分類することで、ODGとADGによるコンカレントチームワークによる共同作業が実現しやすくなる。

変化しやすい部分とそうでない部分にわける

ソフトウェア開発途中や開発後の変更において、安定していなければならないレイアはDataManageである。なぜなら内部データの変更によってProcess、Viewに影響を及ぼす可能性が高いからである。一方、DataManageの変更が伴わないPrcoessの変更は、Viewに影響を与える可能性が高い。Viewは見た目の変更だけで、ProcessやDataManageに影響を及ぼすことは少ない。

このことから、変化しやすいレイアの順に示すと、View、Process、DataManageとなる。また、3つのレイア間で依存性が高いレイアの順は、View、Process、DataManageにならなければならない。なぜなら、DataManageが他のレイアに依存してしまうと変更が多いレイアの影響を受けてしまうからである。

このような構造から、安定しているはずのDataManageに一度変更が起こると、その影響が大きいため、問題分析フェーズでは、要求の中からDataManageに属するオブジェクトをモデル化の中心とするのである。

sorry this is image
図18-5 役割レイアの特性比較

ネットワーク対応のソフトウェア開発に馴染みやすい

ネットワークシステムの開発においては、サーバにデータベースなどを使って永続的なデータを管理し、クライアントがそれを参照するような典型的なクライアント・サーバモデルから、ビジネスプロセスをサーバ側に移した構成の3層アーキテクチャなどを設計の対象としなければならない。オブジェクトをView、Process、DataManageに分類することは、このようなネットワークシステムの設計の際にも有効となる。図18-6は、ネットワーク3層アーキテクチャにおけるView、Process、DataManageの3つのオブジェクトグループの関係を示すものである。

図のようにViewはクライアントだけに存在し、DataManageは、クライアントサーバ間を行き来する。Processは、それらをつなげるために、ViewとProcessにミドルウェアフレームワークやコンポーネントとして存在する。また、Processは、ファンクション層(中間層)に位置し、業務特化ロジックをビジネスオブジェクトとして保有している。

もしも、オブジェクトをView、Process、DataManageに分類することから分析をスタートしていないならば、ビジネスロジックをファンクション層に分類したり、ファンクション層からデータ管理部分を切り出してデータベースに保存したりするような設計を再度行わなければならなくなるだろう。

sorry this is image
図18-6 ネットワーク3層アーキテクチャとView、Process、DataManage

2.再利用レイアに分類する意義

App、AppParts、Genericのレイアにオブジェクトを分類する意義は、オブジェクトの再利用範囲を明確にし、再利用可能コンポーネントの分析・設計指針を立てやすいという点にある。以下に各レイアの特徴と分類方法を示す。

特定業務に特化しないGenericレイア

このレイアに属するコンポーネントは、特定のシステムやアプリケーションに特化しないカテゴリが対象となる。GenericとAppPartsのレイアの線引きは、企業やチームで決めるべき性質のものである。従ってDropでは、明確な切り分けがなされていない。このような分類の重要な意義は、1度GenericとAppPartsのレイア境界の切り分けがなされれば、そこに配置すべきカテゴリの再利用範囲に関する一定の秩序が生み出されるということである。たとえば、Genericに属するクラスがAppPartsに属するクラスを直接的に参照しているような設計に対して、「Genericに属するクラスがAppPartsに属するクラスを直接的に参照してはならない」というルールを作りだすことができるようになる。もし、このような分類がなされていないならば、汎用性の高いクラスが汎用性の低いクラスを参照することが問題であるということは理解できても、どちらが汎用性が高いかチームで認知されていないためルール化できないのである。

このレイアには、クラスライブラリの基盤となるカテゴリとして、汎用的なウィンドウクラスやコレクションクラス、ベーシックなデータクラス(Date、Time、String)などが対象となる。

ここで、ダイブショップ精算管理の例でGenericレイアの解説を示そう。DivingShopはデータベースからDiveSchedule(ダイビングスケジュール)情報とMaterial(器材)情報を取得するためのコンポーネントを必要とする。ここでは、これをDBAccessとDBSetという市販コンポーネントを使うことにしよう。これらのコンポーネントは、図18-7ようにGenericのProcessレイアに位置づけられる。

sorry this is image
図18-7 Genericに位置づけられたデータベースコンポーネント

再利用クラスが構築されていくとGenericレイアは、さらに分類されることとなるだろう。たとえば、OS依存、ウィンドウ系依存、特定業種依存といったような分類である。このような分類はサブレイアとしてGenericの中で破線により表される。

Genericレイアに属するクラスは、すぐれた性能と品質を持っていることを保証しなければならない。そして、再利用のためのドキュメントも充実していなければならない。これらは、ODGがGenericレイアに属するオブジェクトを保守管理することで保証されることになる。

Genericレイアに属するクラスを役割という観点で分類すると以下のようなクラスのカテゴリが対象となる。

View 汎用的なウインドウクラスや特定業務向けのフレームワークなどがここに属する。
Process 汎用性の高い、共有メモリ管理コンポーネント、印刷処理コンポーネント、ファイルアクセスコンポーネント、DBアクセスコンポーネント、通信制御コンポーネントなどがここに属する。また、Dataモデルに属するコンポーネントを管理するためのコレクションなどもここに属する。
DataManage 基本型クラス(Date、Time、String、Calendar)とぃったようなベーシックなコンポーネント。
ビジネスオブジェクトなど業務依存の汎用コンポーネントを構築するAppPartsレイア

開発対象のシステムにおいて共通利用可能なコンポーネントがここに属する。たとえば、問題領域に特化するが類似システムに再利用できるフレームワークや、システムの複雑な業務ロジックをサポートするビジネスオブジェクトなどがこのレイアに構築される。このレイアは、Drop開発サイクルのシステム共通設計フェーズによって多くのカテゴリが作りだされることになる。

ここで、ダイブショップ精算管理を使って例を示そう。ダイブショップがダイビング器材のレンタルだけではなく販売もやっており、器材(Material)クラスやお客(Customer)クラスは、販売システムでも共通的に使えるクラスであった。よってこのクラスはAppPartsに位置付けられる。また、ダイブショップの開発者が、データベース内のテーブル情報を取り出してテーブルとオブジェクトをマッピングするコンポーネントDBMapperを開発したとしよう。これはすべてオンメモリでデータベーステーブルを保有するため、高速であるがデータベース上のデータの整合性やクライアントのメモリに依存する限定仕様であったとする。このようにある程度制約付きではあるが、その制約をクリアできれば類似システムでは再利用可能となるコンポーネントについてもAppPartsに配置する。

それ以外のクラスはAppレイアとなる。Appレイアに属するクラスはAppPartsに属するクラスを参照するが、逆にAppPartsに属するクラスがAppを属するクラスを参照することはないことに注意しよう。このようなクラス間の依存関係も再利用レイアによって見通しがよくなっている。

なお、図中のクラス名の右端の「○」は、コンポーネントを表すDrop表記であり、複数のクラスで構成されるような場合に図が複雑になることを解消するために使用する。

sorry this is image
図18-8 DBMapperとMaterial、CustomerをAppPartsレイアに配置する

App Partsレイアに属するクラスを役割という観点で分類すると以下のようなクラスのカテゴリが対象となる。

View システム共通のウインドウ表示や処理を実現するコンポーネントがここに属することとなる。このコンポーネントによって、機能を行うためのイベントを取得する。その後、このイベントの実際の処理は、Processに委譲(delegation)されることになる。委譲とは、自オブジェクトに依頼されたメッセージを、他のオブジェクトに処理を委ねることである。
Process システムに共通的な機能をコンポーネント化(またはフレームワーク化)したものや、DataManageに属する複数の受動的なオブジェクトをアクセスし制御する役割を持っているクラスなどがここに属する。ここに構築されるコンポーネントは、いわゆるビジネスオブジェクト、もしくは、ビジネスオブジェクトフレームワークといった問題領域に専門的でありながらも、汎用性があるものが位置づけられる。
DataManage システムの汎用的なデータを管理するコンポーネントがここに属する。これらのオブジェクトは、一般的にProcessに位置づけられるオブジェクトとペアでビジネスオブジェクト(フレームワーク)を実現することになる。しかし、中にはこのデータ管理オブジェクトだけで再利用可能なビジネスオブジェクトと呼ばれるものも存在する。それらは、たとえばビジネスに特化した書式付き数値型などがそうである。このように基礎データを加工して新たな抽象オブジェクトを実現するために必須となる操作については、Processに配置せず、DataManageに属するクラスに直接実装される。
再利用可能な部分を明確にするAppレイア

GenericとApp Partsに属するクラスを使って、短時間、低コストで作りあげるのがAppである。これに属するカテゴリは、基本的に再利用されないことを前提に作成される。これによって、再利用のためのドキュメントを含む作業のコスト削減が図れるという効果と、再利用を目的としない部分を強調させることで、クラス利用者に対して誤って再利用不可能なクラスを再利用させないという予防効果がある。

Dropでは、コンポーネントという言葉を再利用可能なクラス群として使用しているが、ここで1つだけ注意しなければならないことがある。それは、このレイアにもコンポーネントが存在することである。これは、「第1章 Drop構成用語集(オブジェクト指向用語編)」のコンポーネント解説で書いた、コンポーネントを切り張りしながら開発するようなビジュアル開発環境におけるコンポーネントの捉え方である。Appに属するこのようなコンポーネントについては、他のコンポーネントと差別化を図っている。その差別化とは、Appに属するコンポーネントについては、再利用に関するドキュメントを書かないことである。

Appレイアに属するクラスを役割という観点で分類すると以下のようなクラスのカテゴリが対象となる。

View アプリケーションの個々のウィンドウ単位に割りつけられるクラス
Process アプリケーション固有の機能中心となるクラス
DataManage アプリケーション固有のデータを管理するクラス
3.役割・再利用レイアに分類することによる効果のまとめ

ここまで、クラスレイアカテゴリの9つのレイアスペースにカテゴリを分類する意義について述べてきた。以下に役割・再利用レイアに分類することによる効果について整理しておこう。

  • 役割レイア・再利用レイアに問題を分割してクラスを抽出することで、クラス間の独立性を高め、依存性を低くするような設計指針を立てやすい。
  • 役割レイアの分類により、変更・拡張に耐えやすい適度なバランスを保ったモデル構造を作りやすい。
  • 役割レイアの分類により、ネットワーク3層アーキテクチャなど、ネットワーク対応ソフトウェアの設計に適合しやすい。
  • 再利用レイアに問題を分割してクラスを抽出することで、再利用コンポーネントを抽出する可能性が高まる。
  • 再利用レイアの分類を明確にすることにより、再利用範囲の大枠をコンポーネントユーザに伝えることができる。
  • 再利用レイアの分類を明確にすることにより、無駄な部分に対する再利用のためのコストをかけなくなる。

18.3 再利用基盤モデル実施プロセス

ここまでの解説でクラスレイアカテゴリの意義について理解できたと思う。次は、再利用基盤モデル全体として、クラスレイアカテゴリをどのように使っていくかという高次元モデリングのプロセスについて解説を行う。この再利用基盤モデリングのプロセスとして「問題領域主導型プロセス」「コンセプト主導型型プロセス」の2通りの進め方を紹介する。ここで書かれている流れだけが正しいという分けではない。実際には、同時並行的ににそれぞれの項目が進められれることになるだろう。

図18-9は再利用基盤モデルの実施プロセスについて、Drop開発サイクルと照らし合わせて記したものである。

問題領域主導型プロセス

このパターンは、ADGのシステム共通設計フェーズにて、問題領域の中からコンポーネントを抽出しようとする際に実践される。先に問題領域があり、その中から徐々に再利用コンポーネントを抽出していく方法。この方法は、企業内で再利用可能なフレームワークやコンポーネントを抽出するのに適している。

コンセプト主導型プロセス

このパターンは、コンポーネントやフレームワークとしてのアイデアがすでにあり、あとはソフトウェアデザインするだけといった、コンポーネント化のアイデアが先行している際に使われる。この場合、どのシステムでコンポーネントが使われるかといった問題は後回しにされ、ODGによるコンポーネント分析にすぐさま開始されることになる。

sorry this is image
図18-9 再利用基盤モデル実施プロセス

再利用基盤モデル実施プロセスの個々の項目について説明する。

  1. 要求オブジェクト抽出:
    シネマスコープモデルによりシーンから要求オブジェクトを取り出す。
  2. 要求オブジェクトのアブストラクトデザイン:
    要求オブジェクトの大まかな関係構造と制御の流れをクラス図やコラボレーション図によって示す。
  3. 要求オブジェクトクラス図のクラスレイアカテゴリ写像:
    図18-7にようにクラス図をクラスレイアカテゴリの9つのレイアスペースに透かして見てみる。
  4. コンポーネント抽出:
    要求オブジェクトを実現するコンポーネントを考察し、クラス図に加える。(図18-8参照)
  5. カテゴリ配置:
    それぞれのクラスが属するカテゴリを既存カテゴリの中から探す。もしなければ作成するかカテゴリを作らずクラスのまま図に表すか決める。
  6. カテゴリセット名の決定:
    もしコンポーネントの対象が多くのカテゴリで形成されるようなフレームワークや大きなコンポーネント群であるなら、いくつかのカテゴリを組み合わせたカテゴリセットを考える。このカテゴリセットの名前がフレームワークやコンポーネント群の名前となる。
  7. カテゴリセットにおける統一的なメソッドインタフェースの決定:
    フレームワークやコンポーネント群の単位となるカテゴリセットを単位として、統一的なメソッドインタフェースを決定する。メソッドインタフェースとは、クラスライブラリとして統一しなければならないメソッド名やパラメータ規約(これは後述する再利用基盤構築指針ドキュメントによる)に基づいて、コンポーネントユーザが使いやすい一貫した名前やメソッド呼び出し手順を決めることである。
  8. カテゴリセットにおける統一的なエラー処理の設計:
    カテゴリセットのレベルで統一的なエラー処理が実施できるようにエラー処理に対する基本指針と、どのようなエラーをどこで止めるかといったエラーデザインの基本方針を立てる。この設計は最終的に「パッケージ仕様書」にまとめられる。
  9. コンポーネントのインタフェース設計:
    コンポーネントの大まかななデザイン。View、Process、DataManage間のクラス関係を疎な結合にするためにそれぞれのコンポーネントの接合点、および開発システムとコンポーネントの接合点のデザインを、様々なデザインパターンを駆使しながら最適なコンポーネント間の関係について設計する。この設計はクラスの詳細設計に引き継がれる。
    ここで重要なことは、コンポーネントが提供するサービスのインタフェースを定めることであり、これはカテゴリセットで定めた統一的なメソッドインタフェースに準拠したものとなる。この段階になるとコラボレーション図などの動的構造モデルが多用され、オブジェクトの動的な側面をモデル化することになる。その後、コンポーネントシートというコンポーネントの大まかなインタフェースを定義した簡単なドキュメントが作成される。
  10. クラスの詳細設計:
    コンポーネントを構成するクラスの詳細なデザイン。コンポーネントを実現するために必要となるプロセス空間やスレッド空間の設計や、クラス間の関連について再度見直しをかけながら具体化する。また、インタフェースメソッドを実現するために必要とされるメソッドや新たなクラスの切り出しなども検討する。インタフェースメソッドとは、クラスの中で公開されたメソッドのうち、クラスライブラリの統一的操作またはプロトコルを提供するようなメソッドのことを呼ぶ。この段階でもデザインパターンを使って最適なデザイン構造を模索し可能なら切り出されたクラスを再利用コンポーネントとして設計する試みがなされる。

18.4 再利用基盤モデリング Q&A

クラスレイアカテゴリ図を使った分析は、その手法について、視点を変えて考察すると様々な問題が見え隠れするものだ。つまり分析に対する価値観を変えると、いままで良かれと思っていた分析がたちまち崩壊してしまうこともある。

このような現象を理解するには、クラスレイアカテゴリによるカテゴリ分類手法は、オブジェクト指向技術そのものの持つ効果を発揮し、問題点を解消させるために、非常に微妙なバランスをとりながら分析を進めていくための分類手法であると考えなければならない。よって機械的にカテゴリを分類できるような形式性などは残念ながらなく、分析者の価値観やその分析者が所属する企業やチームの価値観を定めなければ、クラスレイアカテゴリを使った分析結果の妥当性さえも検証できないのである。

このような理由から、クラスレイアカテゴリのレイア間の線引きの詳細はDropユーザ(Drop利用チームや企業)に任されることになる。と言っても、すでに、レイア間の線引きのヒントについては「クラスレイアカテゴリ図を使う意義と効果」で解説している。この解説によって、Dropユーザは、カテゴリをどのレイアスペースに位置付けるかといった基本的な指針は立てることができることを確信する。

ここからは、クラスレイアカテゴリ図を使ったモデリングについてより深く理解してもらうよう、Q&A形式で、クラスレイアカテゴリを使ったモデリングを崩壊させるような弱点を露わにする質問を浴びせ、それに対する対策を回答で示すことにしよう。

Q1.役割による分離はオブジェクト指向的ではない

そもそもView、Process、DataManageなどといった分類は、自分のことはオブジェクト自身でやるといった純粋なオブジェクト指向にはそぐわないもののような気がするが?

A1.NO

古典的なオブジェクト指向方法論には、このような役割分担は存在しなかった。そのころオブジェクト指向分析・設計を学んだ人たちは、おそらく役割分担について初めは馴染めないかもしれない。しかし、Smalltalkによって確立されたオブジェクト指向プログラミングには、Model、View、Controller といった分類がフレームワークとしてなされていたのである。これらは、DataManage、View、Processに類似している。(この違いは後ほど示す)

よって、なにが純粋であるかは別として、このように3つの役割別にオブジェクトを分類させることは、オブジェクト指向の基本ともいえる。

Q2.A1に対する質問。

もともと3つの役割に分類することがオブジェクト指向の基本ならば、それは拡張性に問題があるといえるのではないか?なぜなら、1つの問題に対する役割が3つのクラスに分類されてしまうと、問題に変更が加わった時に、1つで良かった変更箇所が3つに増えてしまうではないか?

A2.設計バランスを保つための最適解である。

役割分担は、オブジェクト指向がオブジェクトを分類することから開始されるのに対して、オブジェクトを初めからView、Process、DataManageという3つの役割に分類するということから開始する。その結果、オブジェクトの属性(これはDataMangeに属するオブジェクトの属性ということ)に何らかの変更が加えられた場合は、その変更箇所がViewやProcessに影響を及ぼすことになるという問題は確かにある。

しかしながら、もしView、Process、DataManageに分類せずにオブジェクトを抽出すると、本章でかかれたクラスレイアカテゴリによるレイア分割の効果が得られない。結局、この問題は、両問題の重要性と問題を起こす頻度の度合いによりトレードオフした結果、View、Process、DataManageに役割分類した方がよいという結論となるのである。また、この問題は、以下のような対策により問題を部分的に回避することができる。

DataManageに属するオブジェクトを本質的なオブジェクトと見なし、問題領域分析当初から集中的にDataManageを分析する。その結果分析漏れが少なくなり、分析漏れによる変更も少なくなる。

フレームワークのアーキテクチャによって、View、Process、DataManageの関連をフレームワークの提供する抽象クラスでカプセル化しておき、DataManageに属するクラスに一定のプロトコル(インタフェース)を設ける。たとえば、DataManageに属するオブジェクトを印刷するという時は、印刷オブジェクト(Graphics)がDataManageのprintOnメッセージのパラメータとして渡されるようにフレームワークの構造として設計しておく。このイメージを図18-10に示す。図では、AppPartsにフレームワークを構築した例である。

このようなフレームワークによって、出力デバイスを抽象化したGraphicsオブジェクトを使いDataManageに属するオブジェクトが自分自身を出力するロジックを記述することができるようになる。そのためデータに変更があっても、DataManageに属するデータ管理クラスだけを変更すればよくなる。また、出力デバイスを抽象化するProcess(図中ProcessPartsクラス)のおかげで、DataManageに属するオブジェクトは、印刷デバイスに関する細かな制御について意識しなくてよくなり、印刷制御はPrinterクラス(Process)に任せるという役割分類の恩恵はそのまま残しておける。しかし、DataManageはProcessに属するオブジェクトに部分的に依存してしまうことについて妥協しなければならない。

このようなフレームワークアーキテクチャで問題を回避できる範囲は、あくまでフレームワーク設計者が想定している範囲となり、これについても完全な対策ではない。

sorry this is image
図18-10 フレームワークアーキテクチャによって印刷オブジェクトをDataManageに渡す

Q3.CollectionなどはDataManageに属するのでは?

図18-2に書かれているCollectionカテゴリは、データを管理するためのコレクション(入れ物)であり、それはDataManageに属すべきものではないか?

A3.NO

コレクションは、データを管理するオブジェクト(DataManage)を管理するための制御(Process)と考えなければならない。これに類似する問題としてデータベースアクセスクラスやそれに付随するコレクションなどもProcessに属するものである。DataManageに属するクラスは、オブジェクト指向データベースに格納されるクラスやRDBの表に相当するクラスなど、データ構造をラップして抽象操作するためにオブジェクト化したものと考えればよい。

Q4.A3に対する質問。

もしオブジェクト指向データベースを使うのならデータ管理オブジェクトだけを永続化するような考えは必要ではない。なぜなら、制御やウインドウ処理を対象とするオブジェクトも永続化の対象となるわけで、それらを区別する必要などないのではないか?

A4.区別すべきである

オブジェクト指向データベースを使っていてもView、Process、DataManageという分類は有効なものである。なぜなら、DataManageの属するオブジェクトはできるだけ汎用的なデータ操作に対応するような構造でなければならない。もしも、永続オブジェクトに機能が多く組み込まれているならば、その保守性は極めて悪いものとなる。

これは、プログラムからデータを独立させるというデータベースの基本思想に由来する考えであるが、オブジェクト指向の思想であるデータと処理をまとめてオブジェクトにするという考えに反しているようにも思える。この点にデータストアを必要とするオブジェクト指向ソフトウェアの現実的な妥協点を探る必要がでてくる。データ独立を図れるように、データ管理に対する汎用的な操作だけを持つクラスをDataManageに属するオブジェクトとして作り、それを永続オブジェクトとしてオブジェクト指向データベースによって管理させることで、データ独立という思想とオブジェクト指向の思想をバランスよく組み合わせた折衷案とすることができる。これがオブジェクト指向データベースにおいてもDataManageの存在が必要とされる理由である。

Q5.状態管理オブジェクトはDataManageか?

システムのいくつかの状態を管理するために状態管理クラスを作成した。クラスの中には、状態をデータとして保有している。このようなクラスはDataManageに属するのか?

A5.NO

DataManageに属するオブジェクトはあくまで永続化する必要のあるデータを管理するものである。もし、状態をプログラム終了後も保管しておく必要があるならDataManageに属するよう設計することになる。

Q6.DataManageに該当するオブジェクトがない

我々の開発するツールにはDataManageに該当するオブジェクトがない。これは重要なオブジェクトを見つけていないということなのか?

A6.なくてもよい

特に問題はない。データ処理よりも制御が中心となるようなソフトウェアでは、DataManageに属するオブジェクトがないこともあり得る。その場合、要求からProcessを見つけるようにしよう。


*begin*back*foward*end*contents

この記事のトップへ