カタリシス法によるコンポーネントベース開発
カタリシス法は、ICON Computing社のDesmond D'Souza氏と、Trireme社のAlan Cameron Wills氏が提唱している方法論です。D'Souza氏は、UMLチームの一員としてOMGでのUMLの提案に参加しており、UMLのコントリビュータとして活躍しています。カタリシス法の特徴は、コンポーネント指向とフレームワークを取り入れ、エンタープライズレベルのシステムにまで対応できる点です。また、システム実装が分散オブジェクト技術のCORBAやDCOMである場合は、設計から実装へシームレスに落とし込むことができます。もちろん、UMLベースの表記を採用しているため、UMLの知識があればカタリシス法に登場するダイヤグラムを問題なく理解することができます。
コンポーネントとは
一般的にコンポーネントという言葉から連想されるのは、マイクロソフトのDCOM(Distributed Compornent Object Model)やOMGのCORBA(Common Object Request Broker Architecture)です。これらは、設計ではなく実装技術です。ここで少しだけコンポーネントとは何かを確認してみましょう。コンポーネントは、複数(1つの時もある)のオブジェクトをまとめたものや、アプリケーションなど幅広いものを指しています。利用しているアプリケーションに、パソコンのハードウエアのようにプラグ＆プレイで機能追加することを目的にしています。プラグ＆プレイでコンポーネントを差し込むためには、インタフェースが必要になります。コンポーネントによる設計・開発では、この点が非常に重要となります。
例えば図1のように、モーターというコンポーネントは、インタフェースを通して他のコンポーネントとコミュニケーションします。
モーターはメーターに対して、スピードを送り出しますが実際には単純ではなく、いくつもの命令に別れているかもしれません。それらをまとめてインタフェースとしています。また、モーターのように複数のインタフェースを持つ場合もあり得ます。もう1つ、コンポーネントの例を挙げてみましょう。エディタというコンポーネントを考えてみると、その中には内部データとしてワードなどいったオブジェクトを持っていることになります。
このエディタを他のアプリケーションに組み込む場合は、このインタフェースを通して、オペレーションを呼び出すことになります。コンポーネントとして開発しておけば、ドローソフト、Webブラウザなどあらゆるアプリケーションに組み込むことができます。また、アプリケーション側から見ると、複数のエディタ・コンポーネントの中から選択して利用することもできます。
それでは、ここで、コンポーネントを利用した実装環境である分散オブジェクトを見てみましょう。分散オブジェクトと言えば、DCOMかCORBAが代表的です。その他に、JavaのRMI(Remote Method Invocation)やHORBなどもあります。オブジェクト指向によるアプリケーション開発では、オブジェクトを呼び出す時、オブジェクトはアプリケーションに動的または静的にリンクされています。これは、1つのマシンで完結しているときは良いのですが、システムが分散システムのようにネットワーク上の複数のマシンで構成されるものでは、複雑な仕組みが要求されます。ネットワーク上のオブジェクトにリモートアクセスするわけです。
インタフェースとは
それでは、図1を例にとって、Javaのプログラムでインタフェースについて考えて見ましょう。メータークラスは次のように実装することができます。
interface SpeedMeter
{
int start();
int send(int value)
int stop();
}
class ConcreteMeter implements SpeedMeter
{
// 実装コード
}
このように、インタフェースSpeedMeterに、オペレーションstart()、send(int value)、stop()を定義します。そして、ConcreteMeterクラスにSpeedMeterをimplementsします。
また、マイクロソフトのDCOMの仕組みで簡単に確認してみましょう。図3のように、アプリケーションはオブジェクトを持っていて、そのオブジェクトが外部からのアクセスの窓口として、インタフェースを開いています。例えば、ワードを使ってエクセルの表を取り込もうとする場合には、エクセルのインタフェースをワードから呼び出すようにすれば良いわけです。
UMLによるコンポーネントの表記
さて、次にUMLの表記について触れておきます。UMLには、コンポーネントを表す実装図というものがあります。ここでは、その中のコンポーネント図を使ってみます。図4では、「データベース」コンポーネントに「テーブル検索」というインタフェースがあり、それを「CORBAサービス」が呼び出すことを表しています。
ここまでは、実装に関連していたことを説明してきましたが、コンポーネント技術は実装だけではありません。この他に分析・設計段階のコンポーネントである、ビジネスコンポーネントもあります。以前は、ビジネスオブジェクトと呼ばれてきたものですが、最近ではビジネスコンポーネントと呼ばれ重要なものとなっています。オブジェクトの数が増えるとオブジェクト単位での管理は難しくなるため、グループ化したコンポーネント単位で管理する方が良いでしょう。
図5の中の「売上」、「会計」などは、従来ではサブシステムとして扱われていた機能ですが、それらを設計段階からコンポーネントとすることで、設計としてもプラグ＆プレイが可能となります。これらコンポーネントの中身は、オブジェクト指向分析・設計を行なったモデルが含まれており、ターゲットのシステムからこれらのコンポーネントのクラスを取り込むことにより、モデルの再利用が可能となるのです。
フレームワークとは
オブジェクト技術の重要な要素である、フレームワークについてもここで触れておきます。フレームワークとは、アプリケーションの仕組みがすでに出来上がっており、部分を書きかえるだけで新しいアプリケーションが作成できるものを指します。フレームワークの例として、Javaのアプレットの例を考えてみましょう。 Javaのアプレットは、実行可能なフレームワークを持っています。その中には「init()」、「run()」、「start()」、「stop()」といったメソッドが含まれています。プログラマは、これらのメソッドの内容を書きかえるだけで、アプリケーションを簡単に作成できます。これは、実装レベルでの例ですが、設計レベルでのフレームワークは「モデルフレームワーク」と呼ばれます。
カタリシス法とは
カタリシス法とは、コンポーネントベースのアプリケーションを開発する手法です。UMLを拡張した表記法を用いています。提唱者は、Alan WillsとDesmond D'Souzaの2人です。この手法の一番の特徴は、コンポーネントの表現方法です。図6のように、インタフェースのオペレーションを下線の下に書き、コンポーネント内部をモデリングします。そして、外部とのつながりを持つタイプはコンポーネント境界へ線で接続されています。
カタリシス法は、「コラボレーション」、「タイプ」、「リファイン」、「フレームワーク」というコンセプトを持っています。コラボレーションでオブジェクトのグループの振る舞いを整理し、タイプでオブジェクトの外部に対しての振る舞いを決定し、リファインで振る舞いなどを抽象化していきます。そして、プラグイン可能なフレームワークを作成していきます。カタリシス法では、オブジェクトの抽象レベルをタイプと呼びます。そして、タイプ間にある機能をアクションと呼びます。これは、UMLで言うところのユースケースに相当します。
アクションについての例を考えてみましょう。例えば、「飼い主」と「犬」の間には、「餌を与える」というアクションがあります。これを表現すると図9のようになります。このようなタイプ間の関係を「コラボレーション」と呼びます。
タイプとは、オブジェクトやグループ化されたオブジェクトの抽象レベルを指します。それは、データ中心設計技法などではエンティティと呼ばれているものやクラスに似ています。タイプの表記はUMLのクラス図を拡張しています。図9のように、上段にタイプ名、中段に属性またはモデルの図、そして下段には当該タイプが持っているオペレーションを記述します。オペレーションとは、タイプの外部から起動される振る舞いのことです。
カタリシス法は、リファインという抽象化のレイヤを持っています。これにより、具象化したものから抽象化したものへのマッピングを明確に表現できます。図10の例では、「登録」、「変更」、「削除」を「申込み」というアクションにリファインしています。
カタリシス法によるモデリング
カタリシス法での開発過程は、図11のような3つのモデリングプロセスに分類されています。1つ目は、ビジネスプロセスなどの業務の流れを明確にしていく「ドメイン／ビジネス」。2つ目は、システム化の対象となるコンテキストを絞り込んで、それと関連する要素を分析していく「コンポーネント仕様」。そして3つ目は、コンテキストの内部を分析・設計していく「内部設計」です。
ドメイン/ビジネス
ここでは、例としてセミナー管理システムを考えてみましょう。セミナーの受講者は、セミナーを申し込みます。これをユースケース図で表すと図12のようになります。
受講者は、受付に対してセミナーを申し込んでいます。UMLでは、受講者のようなシステムの外部要因をアクターとして、人のようなシンボルで表現します。また、「セミナーを申し込む」といった機能を「ユースケース」と呼び、楕円で表します。これを問題としているビジネス全体に対して行うことで、図13のようにビジネスプロセス全体の表現が得られます。
コンポーネント仕様
ドメイン/ビジネスのモデリングフェーズで、全体の概要は整理されたら、次にシステム化の範囲を決めていきます。例えば、図14のようにシステムの範囲を決めます。ここでは、「顧客管理」は別システムとしたので、アクターとして表しています。
なお、図14をUMLのユースケース図で書き換えると、図15のようになります。
これで、システムのコンテキストが確定できました。次に、システムそのものをコンポーネントと考え、このシステムのインプット/アウトプットに注目します。これは、ユースケース図のコミュニケーションに相当します。これを確実に洗い出すために、シーケンス図を利用します。そのために、シナリオと呼ばれる具体的なケースを洗い出し、シナリオ毎にシーケンス図を作成していきます。図16のシナリオでは、「申し込み()」というオペレーションが導入されて、図17のようなコンテキストが作成されます。
内部設計
内部設計では、前のフェーズで導入されたコンテキストの中身をブレークダウンして、詳細に記述していきます。これは、制約(Constraint)を用いて表現します。この制約を記述する言語がOCL(Object Constraint Language)です。OCLはUMLの一部であり、元々は米IBM社のInsurance divisionでビジネスモデリング用の言語として開発されたものです。オペレーションに対する制約のシンタックスは、図18のようになっています。
Preとは事前条件(Pre-condition)のことで、このオペレーションを起動できる条件です。Postとは、事後条件(Post-condition)のことで、オペーレーションを起動した結果です。なお、OCLはあくまでもモデリング言語ですので、オペレーションのロジックを細かく記述することはできません。ロジックの記述については、アクション言語と呼ばれるものがOMGにて提案されています。(OCL仕様書は、OMG(Object Management Group)で入手できます。)
また、図20のように計算式での表現も可能です。@preは、このオペレーションが実行される前を意味しています。
次はデータ構造分析です。これは、データ中心設計でお馴染みのE-R図によく似ています。ただし、カタリシス法では「エンティティ」ではなく、「タイプ」になります。また、「クラス」は、この「タイプ」を実装したものとなります。完成されたタイプモデルを図21に示します。
さらにタイプの動的な部分である「状態」をモデル化します。これには、UMLの状態図を使用します。状態は、図22のように各タイプ毎に作成していきます。また、図23に状態図の例を示します。
コンポーネント設計
タイプモデルはあくまでも抽象化されたモデルであるため、実装上のことは含まれていません。コンポーネント設計フェーズで初めて実装を考慮していきます。ここでは、図24に示すように、図21の各タイプをDBコンポーネントとして設計します。「セミナー」タイプと「セミナー申込」タイプを「セミナーDB」に、「請求」タイプを「請求DB」にそれぞれマッピングしています。これらのコンポーネントはいずれも「add()」、「update()」などのDB操作に相当するオペレーションを持つことになります。通常は、コンポーネント設計を行なった結果により、内部設計フェーズに戻ってタイプモデルを洗練する必要があるでしょう。
システムアーキテクチャの決定
コンポーネント設計が完了したら、次にシステムアーキテクチャを決定します。先ほど設計したように、セミナー管理システムには「セミナーDB」、「請求DB」の2つのコンポーネントがあります。これらを図25のように、「セミナーDBサーバ」、「請求DBサーバ」として独立したアプリケーションとすることにしましょう。これらは最終的には、CORBAやDCOM、EJBなどのサーバアプリケーションとして実装されることになります。
パターンとモデリングフレームワーク
次にカタリシスのモデルフレームワークについて説明します。タイプモデル作成する際、モデリングにパターンを見つけられることがあります。ソフトウェアにおけるパターンといえば、プログラムレベルのデザインパターンや分析レベルのアナリシスパターンを思い起こす方も多いでしょうが、カタリシス法でもパターンの適用により効率の良いモデリングが可能です。
カタリシス法では、共通に利用できる分析モデルのパターンを「テンプレート」と呼びます。また、テンプレートを適用してモデル化したものを「モデルフレームワーク」と呼びます。ここでは、カタリシス法の「Resource Allocation」テンプレートを紹介します(図26)。このテンプレートを、システムエンジニアの業務に関連するモデルに適用したものが図27です。<Product>はJob Typeに、<Feature>はSkillに、<Usage>はJobに、そして<Resource>はSystem Engineerにそれぞれ置き換えられています。
このResource Allocationテンプレートは、セミナー管理システムにもうまく当てはめられます。適用した結果を図28に示します。
さらに、「講師」を追加してみましょう。(図29)
図29のモデルでは、図28のモデルに比べて、さらにもう一度パターンを利用しています。このように、モデルにパターンを適用することで、モデルフレームワークとして再利用が可能となります。また、設計、実装フェーズにおいても、「Resource Allocation」はフレームワークとしてすでに完成されたものであり多くの活用実績を持つため、再利用により生産効率が大幅に向上します。
まとめ
カタリシス法についてごく簡単に説明しましたが、いかがだったでしょうか。体系立ったモデリング手法によるコンポーネント開発の生産性の高さについて、その一片を感じ取っていただけたならば幸いです。