図1●オブジェクト指向の問題点を解決する
オブジェクト指向技術が浸透するにつれ,その問題点が明らかになってきた。これを解決するキーワードが「疎」である。
図2●部品化のメリット
システムを分割してうまく部品化できれば,さまざまなメリットが生まれる。中でも重要なものは,同じ部品を他のシステムで再利用できること,変更を加えたときに影響が及ぶ範囲を部品内に限定できること,部品を別のものに入れ替えることでシステムの変更や拡張が容易になること,である。
 オブジェクト指向言語の考え方が登場してから30年余。オブジェクト指向は,ソフトウェア開発の現場にようやく定着してきた*1。システム・インテグレーションの現場では「案件のほぼすべてが,オブジェクト指向開発」(日本ユニシス・ソリューション AD CoE コンピテンスセンタ統括部長の川口真一氏)。「システムを発注する側が,設計情報をUML(Unified Modeling Language)で記述して納品してほしいと要求することも珍しくなくなった」(南山大学 数理情報学部情報通信学科の青山幹雄教授)。

 開発者にも,オブジェクト指向の考え方は浸透しつつある。「デザイン・パターンのような設計の知識が一般的に知られるようになってきたし,フレームワークの考え方も定着してきた」(日本IBM ストラテジー&コンピテンシー ICPエグゼクティブITアーキテクトの榊原彰氏)。

 一方で,オブジェクト指向開発が定着し始めているからこそ,足りない部分が明らかになってきた。「オブジェクト指向は柔軟性が高く汎用的だが,世の中のすべての事象を記述できるわけではない。オブジェクトという単位だけですべて扱おうとすると,モデルやコードに無理な表現が入り込む」(マイクロソフト エンタープライズ市場開発 アーキテクトエバンジェリストの萩原正義氏)。この結果,後述するオブジェクト指向のメリットを生かしきれなくなる。

 それを補うための技術として,「アスペクト指向」や「SOA(Service Oriented Architecture)」などが出てきた(図1[拡大表示])。これらの技術に共通するキーワードは「疎」である。

システムをうまく分割する

 ここで,オブジェクト指向の基本的な考え方を整理しておこう。オブジェクト指向は,手続きとデータをひとまとまりにしてシステムを分割する手法である。その一番のメリットは「大きく複雑なプログラムを,人間が理解できる形にしやすい」(東京工業大学大学院 情報理工学研究科数理・計算科学専攻の千葉滋助教授)ことにある。比較的現実に近いモノを単位に分割できるので,人間にとって管理しやすい。

 システムをうまく分割できれば,さらにそれを汎用的に使えるソフトウェア部品化に発展させることが可能だ。部品化のメリットは,主に三つある(図2[拡大表示])。

 まず一つ目が,再利用性の向上。同じ機能を必要とする他のソフトウェアを開発する際に,部品をそのまま使い回せる。一から開発する必要がなくなり,ソフトウェア開発の効率が向上する。

 二つ目は,保守性が上がること。システムが適切な単位に分割されていれば,不具合があった場合に問題の個所を特定しやすい。さらにその部分に変更を加えても,影響を受けるのは部品内に限定できる。検証作業の手間が軽減される。

 そして三つ目は,システムを柔軟に変更できるようになること。部品を少し拡張したり,そっくり別のものに入れ替えるだけで,機能拡張や仕様の変更に対処できる可能性が出てくる。

 しかし実際にオブジェクト指向の枠組みだけでソフトウェアを部品化すると,期待していたほどのメリットが得られないことが分かってきた。システムをうまく部品化したつもりでも,一つの部品が他の部品に強く依存してしまうという状況が少なからず発生するのだ。

MDAはモデルと実装の関係を「疎」にする

図●MDAの仕組み
まず,OSやミドルウェアなどのプラットフォームに依存しないモデル(PIM)を作成する。次に変換パターンやルールを用いて,プラットフォーム依存モデル(PSM)に変換し,最後にソースコードを生成する。モデルをベースに保守ができること,変換ルールの入れ替えによって多様なプラットフォームに対応可能なことなどがメリットだ。

 設計と実装の間の依存性をなくすという意味では,MDA(Model Driven Architecture)も「疎」の考え方を採り入れた技術だと見ることができる。ソフトウェア開発においては,分析/設計の成果を記述するために,UMLなどで記述されたモデルが用いられる。MDAでは,実装に依存しないPIM(Platform Independent Model)というモデルを作成する。これを基に,各プラットフォームに依存したモデル(PSM:Platform Specific Model)やソースコードへと半自動的に変換していく([拡大表示])。

 MDA的なアプローチは,1990年代初めに組み込みソフトウェア開発分野において広まりを見せ,現在に続いている。主に,MDAが持つ二つのメリットが評価されてきた。
一つ目が,品質の向上。MDAなら,モデルの段階でシステムの動作を検証できる。ツール上でモデルを動かし,不具合がないかをシミュレートできる。細かなソースコードを追いかける必要がないし,早い段階でバグを検出できる。

 さらに,人手によるミスも減らせる。「一つのモデルから,その何十倍ものデータ量のソースコードが生成できる。これを人手でコーディングすれば,ミスが混入する危険が高い」(東陽テクニカ ソフトウェア・システム研究部 技術主幹の二上貴夫部長)。「プログラムの細かな処理は人手で記述する必要があるが,定型的な部分がひな型として出力されていると,その枠の中で開発ができる。コーディング規約など,プログラムを均質化するための約束事を,苦労して周知徹底させる必要がない」(シナジー研究所の依田智夫代表取締役)。

 もう一つは,プラットフォーム変更に対応しやすいこと。組み込み系のシステムでは,開発段階でシステムを別のプラットフォームに載せ替える手間が必ず発生する。まず評価用キットを使って開発を進め,ハードウェアができあがってから実際の機器に組み込む。このときに変換ルールを切り替えるだけで対応できる。

トレーサビリティを確保する

 ここ数年,MDAを企業情報システムにも適用しようとする動きが活発化している。組み込み系で評価されているメリットに加えて,システムの保守作業がしやすくなると期待されている。

 企業情報システムは組み込みシステムと違い,長期にわたってメンテナンスが発生する。不具合修正や仕様変更などで,システムに手を入れることもしばしばだ。こうしたとき「さまざまな抽象度でモデルが作られていれば,モデルをベースにシステムの保守ができる。変更内容が及ぼす影響を,モデルを使って特定できる」(オブジェクトテクノロジー研究所の和田周技術ディレクター)。またコードとモデルがそれぞれ別々に用意されていると,コードの修正をモデルに反映するのを忘れるなど,保守の途中で不整合が発生してしまう。MDAならコードとモデル図が半自動的に同期するので,変更の履歴をきちんと管理できる。つまり「システム開発のトレーサビリティをきちんと確保できる」(和田氏)。