萩原正義のソフトウェア工学論（5）

図2 1対1の原則<BR>1対nの関係の例。注文処理業務をモデル化している。設計モデルはOrder，Itemクラスで表現し，それらの実装がそれぞれ三つのクラスで構築されている。モデルが前提とするパラダイム，プラットフォーム技術，OOPなどの実装技術の制約があるためだ。ここでは，Java2 Platform，Enterprise Editionのプログラミング・モデルによる制約を受けている。

[画像のクリックで拡大表示]

表 概念モデルと設計/実装モデルの複雑な関係<BR>概念モデルと，設計/実装モデルが1対1で対応していないと，さまざまな問題が生じる。左は，一つの概念モデルに対して複数の設計/実装モデルが存在する場合。右は，その逆の場合である。

[画像のクリックで拡大表示]

図3 分析レベルのBCEとMVCアーキテクチャパターン<BR>上は，コンポーネントの変更頻度をBoundary，Control，Entityに基づき分類したもの。ロバストネス分析と呼ばれる分析手法で，保守性の高いシステム分割の基準を与える。下に挙げたMVCパターンは見かけ上BCEに類似するが，その本質はUI表示を管理するアーキテクチャ・パターンとしてWebアプリケーションなどのアプリケーション構造を決めることにある。BCEの実装としてMVCパターンを適用することは可能だが，WebサービスなどUIを持たない実装や，別のアーキテクチャに適用することもできる。

[画像のクリックで拡大表示]

1対1の原則を理想とすべし

　概念モデルを定義したあとは，各工程ごとにそれを詳細化したモデルを作成する。このときに問題となるのが，元のモデルと詳細化後のモデルとの関係が複雑になることである。モデル間の関係を単純にして，概念から実装に向かって進められるモデルの具象化と詳細化を，容易に追跡できるようにしなければならない＊5。

　詳細化の度合いが異なるモデル間の関係が複雑化するのは，モデルが前提とするパラダイム，プラットフォーム技術，OOP（Object Oriented Programming）などの実装技術の制約によるところが大きい。例えば，何らかのフレームワークを利用する場合，そのフレームワークのプログラミング・モデルやコンポーネント・モデルを前提としてモデルを構成しなければならない。つまりJ2EE（Java2 Platform，Enterprise Edition）を使うのであればBeanを想定してモデル化しなければならない（図2[拡大表示]）。

　特定のコンポーネント・モデルやデザイン・パターンの適用は，セキュリティやトランザクションなどの非機能要求の実装や，性能，拡張性/保守性の考慮などの技術的な理由による。これは正当な理由のように思われるが，モデル間の関係の単純化を考慮してこなかった技術上の欠陥とも考えられる。概念モデルで表現した現実世界の要求を軽視し，設計および実装レベルの都合に合わせたモデルを考えてきただけとも言えるのだ。その結果開発者は，複雑さを回避するためにプログラミング・モデル，コンポーネント・モデル，デザイン・パターンなどの技術を習得し，適用することを強いられてきた＊6。

　モデル間の関係が複雑になると，多くの弊害が生じる（表[拡大表示]）。だから各モデルのモデル要素は，原則的には1対1の関係が理想である。言い換えれば，概念モデルによる要求/what（何を実現するか）を指向した設計モデル，実装モデルを作成すべきである＊7。現在のITは，とかくhow（いかに実現するか）を中心に考えがちだが，その点を改めるべきである。最近になって，Plain Old Java Object（POJO）によってドメインクラスを構築する手法が注目を浴びている。従来のJ2EEにおけるコンポーネント・モデルが強制するライフサイクル管理や配布管理，トランザクション処理などの非機能要求の実装を分離し，本来のビジネス・ロジックとしてwhatの表現に回帰する方向性を示す事例である。

コンポーネントの変更頻度で分類

　詳細化の過程で，ユースケースを基にシステムをコンポーネント化していくのがCBD（Component Based Development）の開発プロセスである＊8。CBDを適用するには，システムを分割する明確な基準を持たなくてはならない。

　システムの保守性から見れば，変更要求の頻度が同程度のコンポーネントをグループ化してパッケージを定義しなければ，変更を局所化しづらい。変更頻度が低いコンポーネントをグループ化したパッケージと，頻繁に変更するコンポーネントをグループ化したパッケージを分離して，変更の局所化に努めるのである。

　コンポーネントの変更頻度は，主にシステム上の役割によって決まる。システムの役割を，サービスを外部に提供する部分，サービスを実行する部分，サービスの実行に必要となるリソースの部分に分ける分類法が知られている＊9。それぞれを，Boundary，Control，Entity（BCE）と呼ぶ。分類されたBCE間に一定の制約関係を与えることで，コンポーネント化への筋道を与える。これをロバストネス分析と言う。

　現段階では，ロバストネス分析に対する認識を誤っている場面が少なからず見受けられる。例えばロバストネス分析は，一見するとMVC（Model-View-Controller）パターンに似ている。しかしMVCがアーキテクチャ・パターンとしてアーキテクチャの抽象的な骨組みを作るのに対して，BCEは分析レベルでコンポーネント化を支援するためのモデルである（図3[拡大表示]）。

　またロバストネス分析を分析レベルのコンポーネント図として形式的に利用する開発事例もよく見るが，これも正しくない。ロバストネス分析は，コンポーネントの変更頻度によってモデルの保守性を検証するプロセスとして利用すべきである。一般的には，B，C，Eの順で変更頻度は低くなる。ユースケースはこのBCEで実現され，コンポーネントの設計基盤を作る指針を与える。