開発者にも,オブジェクト指向の考え方は浸透しつつある。「デザイン・パターンのような設計の知識が一般的に知られるようになってきたし,フレームワークの考え方も定着してきた」(日本IBM ストラテジー&コンピテンシー ICPエグゼクティブITアーキテクトの榊原彰氏)。
一方で,オブジェクト指向開発が定着し始めているからこそ,足りない部分が明らかになってきた。「オブジェクト指向は柔軟性が高く汎用的だが,世の中のすべての事象を記述できるわけではない。オブジェクトという単位だけですべて扱おうとすると,モデルやコードに無理な表現が入り込む」(マイクロソフト エンタープライズ市場開発 アーキテクトエバンジェリストの萩原正義氏)。この結果,後述するオブジェクト指向のメリットを生かしきれなくなる。
それを補うための技術として,「アスペクト指向」や「SOA(Service Oriented Architecture)」などが出てきた(図1[拡大表示])。これらの技術に共通するキーワードは「疎」である。
システムをうまく分割する
ここで,オブジェクト指向の基本的な考え方を整理しておこう。オブジェクト指向は,手続きとデータをひとまとまりにしてシステムを分割する手法である。その一番のメリットは「大きく複雑なプログラムを,人間が理解できる形にしやすい」(東京工業大学大学院 情報理工学研究科数理・計算科学専攻の千葉滋助教授)ことにある。比較的現実に近いモノを単位に分割できるので,人間にとって管理しやすい。
システムをうまく分割できれば,さらにそれを汎用的に使えるソフトウェア部品化に発展させることが可能だ。部品化のメリットは,主に三つある(図2[拡大表示])。
まず一つ目が,再利用性の向上。同じ機能を必要とする他のソフトウェアを開発する際に,部品をそのまま使い回せる。一から開発する必要がなくなり,ソフトウェア開発の効率が向上する。
二つ目は,保守性が上がること。システムが適切な単位に分割されていれば,不具合があった場合に問題の個所を特定しやすい。さらにその部分に変更を加えても,影響を受けるのは部品内に限定できる。検証作業の手間が軽減される。
そして三つ目は,システムを柔軟に変更できるようになること。部品を少し拡張したり,そっくり別のものに入れ替えるだけで,機能拡張や仕様の変更に対処できる可能性が出てくる。
しかし実際にオブジェクト指向の枠組みだけでソフトウェアを部品化すると,期待していたほどのメリットが得られないことが分かってきた。システムをうまく部品化したつもりでも,一つの部品が他の部品に強く依存してしまうという状況が少なからず発生するのだ。
MDAはモデルと実装の関係を「疎」にする
設計と実装の間の依存性をなくすという意味では,MDA(Model Driven Architecture)も「疎」の考え方を採り入れた技術だと見ることができる。ソフトウェア開発においては,分析/設計の成果を記述するために,UMLなどで記述されたモデルが用いられる。MDAでは,実装に依存しないPIM(Platform Independent Model)というモデルを作成する。これを基に,各プラットフォームに依存したモデル(PSM:Platform Specific Model)やソースコードへと半自動的に変換していく(図[拡大表示])。 MDA的なアプローチは,1990年代初めに組み込みソフトウェア開発分野において広まりを見せ,現在に続いている。主に,MDAが持つ二つのメリットが評価されてきた。 さらに,人手によるミスも減らせる。「一つのモデルから,その何十倍ものデータ量のソースコードが生成できる。これを人手でコーディングすれば,ミスが混入する危険が高い」(東陽テクニカ ソフトウェア・システム研究部 技術主幹の二上貴夫部長)。「プログラムの細かな処理は人手で記述する必要があるが,定型的な部分がひな型として出力されていると,その枠の中で開発ができる。コーディング規約など,プログラムを均質化するための約束事を,苦労して周知徹底させる必要がない」(シナジー研究所の依田智夫代表取締役)。 もう一つは,プラットフォーム変更に対応しやすいこと。組み込み系のシステムでは,開発段階でシステムを別のプラットフォームに載せ替える手間が必ず発生する。まず評価用キットを使って開発を進め,ハードウェアができあがってから実際の機器に組み込む。このときに変換ルールを切り替えるだけで対応できる。 トレーサビリティを確保するここ数年,MDAを企業情報システムにも適用しようとする動きが活発化している。組み込み系で評価されているメリットに加えて,システムの保守作業がしやすくなると期待されている。 企業情報システムは組み込みシステムと違い,長期にわたってメンテナンスが発生する。不具合修正や仕様変更などで,システムに手を入れることもしばしばだ。こうしたとき「さまざまな抽象度でモデルが作られていれば,モデルをベースにシステムの保守ができる。変更内容が及ぼす影響を,モデルを使って特定できる」(オブジェクトテクノロジー研究所の和田周技術ディレクター)。またコードとモデルがそれぞれ別々に用意されていると,コードの修正をモデルに反映するのを忘れるなど,保守の途中で不整合が発生してしまう。MDAならコードとモデル図が半自動的に同期するので,変更の履歴をきちんと管理できる。つまり「システム開発のトレーサビリティをきちんと確保できる」(和田氏)。 |