連載第17回（最終回）－１
UMLの基礎と応用

（株）NTTデータ 技術開発本部 副本部長
山本修一郎

　今回は、これまで続けてきた本連載の最終回ということで、NTTデータ技術開発本部が慶應義塾大学理工学部と東芝SI技術開発センターとで進めているMDA（Model Driven Architecture）^[１]に関する共同研究について紹介しよう^{[２][３][４]}。

　OMG^[５]が提唱するMDAは、現状では組込み制御ソフトウェア等への適用が中心だが、業務システム分野でもMDAの有効性が示されれば、ソフトウェア開発の生産性向上に大きく寄与する可能性がある。以下では、分散型業務システム開発向けのUML ProfileであるEDOC（Enterprise Distributed Object Computing）標準^[６]を対象として、我々が考案したMDA による開発プロセスについて述べる。

■MDAとは

　ソフトウェア開発過程で作成される生産物の曖昧さ、誤解、手戻り等を最小化し高品質で迅速なソフトウェア開発を実現するために、UMLの標準化を推進するOMGが2001年にUMLをベースとしたMDAを提案した。MDAによりソフトウェア開発の（中間）生産物の形式性を向上できるため、モデルからコードへの自動変換の可能性も期待できる。

　MDAでは、ビジネスプロセスやプラットフォームの変化に起因するソフトウェア変更要求の増加を抑えるため、PIM（Platform Independent Model）という概念を導入した。PIMでは、プラットフォームに依存しない抽象的な計算モデルを記述する。処理ロジックはPIMで記述する。

　MDAモデルを実行するためには、J2EEや.NETといったプラットフォームを決める必要がある。指定されたプラットフォーム上で動作するモデルをPSM（Platform Specific Model）という。PSMでは、プラットフォームに依存したステレオタイプ等を用いて、指定されたプラットフォーム上でモデルを実行するために必要な情報を追加する。MDAでは変換ルールによりPIMからPSMを生成し、モデルコンパイラ等のツールによってPSMを実行可能コードに変換する（図１） 。


図1　MDAの基本概念

■業務アプリケーション開発へのMDAの適用

　組込み制御ソフトウェア分野では、MDAの考え方としては10年以上前からの取組みが既にあり^[７]、UMLの適用法の開発が進んでいる^[８][９]。

　これに対して、会計、顧客管理、在庫管理、受発注といった業務アプリケーション領域へのMDAの適用は、まだ必ずしも十分進んでいるとはいえない。このため、最近急速に発展してきているWeb情報システム分野を対象にして、MDAの適用可能性について共同研究を進めてきた。

■EDOC Profile

　UMLでは、ステレオタイプ（stereotype）やタグ値（taggedvalue）等のモデル拡張機構を用いて分野ごとに詳細規定（profileと呼ばれる）を定めてUMLモデルの意味を拡張している。OMGが業務システム分野向けprofileとして標準化しているのがEDOCである。

　ISO/IECでRM-ODP（Reference Model for Open Distributed Processing）策定メンバの多くがEDOC profileを標準化したことから、EDOCでは図２に示すように、RM-ODPに従った５つのViewpointを採用している。


図2　EDOCの5つのViewpoint

　EDOCにはプロセス構造モデルとエンティティ構造モデルがある。プロセス・モデルはプロセス・コンポーネントから構成され、エンティティ・モデルはエンティティ・コンポーネントから構成される。

　他のコンポーネントと相互作用を行うインタフェースとして、ポートを持つことができる。コンポーネント間でポートを接続すると、その間でメッセージやイベントのやりとりが行われることを示す。EDOCでは、peer to peerで送られる情報をメッセージ、publish/subscribeで送られる情報をイベントと呼んで区別する。メッセージとイベントには同期型と非同期型がある。単一のデータフローを表すポートはフローポートと呼ばれる。コンポーネント間で対話的な一連のメッセージ交換が行われる場合は、これらのメッセージをまとめてプロトコルポートとして定義する。

　コンポーネントは階層構造（合成関係: composition）を持つことができる。エンティティ・コンポーネントの階層構造によりデータ構造を定義できる。プロセス・コンポーネントの階層構造により、プロセスの段階的な詳細化構造を定義できる。

　コンポーネントの相互作用に基づくモデリング手法をCCA（Component Collaboration Architecture）と呼ぶ。

　ポートやポート間の接続を含むコンポーネントの全体的な構造はクラス図で表す。プロセス・コンポーネントの構造を表現するためのCCA記法と呼ばれる記法が追加されている。

■ViewPoint

　PIMにはEnterprise Viewpoint,Information Viewpoint,Computational Viewpoint構成されるモデルの集合がある。またPSMにはEngineering ViewpointとTechnology Viewpointがある。

　EDOCでは、テクノロジマッピングを定めてPIMからPSMに基づく実行可能コードを導出する。

◇Enterprise Viewpoint

　Enterprise Viewpointでは、システムによって支援されるビジネスプロセスをモデル化する。ビジネスプロセスでは、performer, responsibleParty, artifact というロールを付与できる。Performerはプロセスの実行を支援する機構（通常は情報システム）である。responsible Partyはプロセスの実行責任者（performerがユーザーインタフェースを持つときにその実行を行う職務の人等）である。artifactはプロセスの実行に必要なリソース（通常はエンティティ）である。

◇Information Viewpoint

　Information Viewpointでは、Enterprise Viewpoint中に現れるエンティティの構造を、クラス図によってモデル化する。但し、モデル化するのは情報エンティティの範囲であり、人や物などの物理的なエンティティは含めない。

◇Computational Viewpoint

　Computational Viewpointでは、Enterprise Viewpoint中に現れる情報システム部分、即ち、performerの中身を詳細化する。Performerはプロセス・コンポーネントであり、階層構造を持つことができる。

◇Engineering Viewpoint

　Engineering Viewpointでは、特定のプラットフォーム製品に依存しないシステム方式上の決定を行う。例えば、オブジェクトの分散配置、トランザクション境界や非同期メッセ－ジングの使用範囲、永続オブジェクトの範囲等を定義する。

◇Technology Viewpoint

　Technology Viewpointでは、プラットフォーム製品に依存した細部を詰める。例えば、J2EE用、NET用、CORBA用などがある。

NEXT　>>