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

図1 ユースケースの詳細化<BR>アクターである書籍購入サイトの利用者が，書籍購入の注文を出した場合の例。利用者が書籍の購入をする動作を上のシーケンス図で，注文処理のシステム構造表現としてのドメインクラスを下のクラス図で示している。このように，ユースケースを詳細化すると，UMLではクラス図とシーケンス図の二つの図に分離した表現になる。

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

一般にシステム開発では各工程で設計図に当たる「モデル」を作成する。現在の技術では，工程ごとに作成されるモデル同士の関係が複雑にならざるを得ない。複雑さを軽減するには，モデルで定義する要素を，工程間で1対1に対応付けることが重要だ。それにはアスペクト指向の導入などが有効である。（本誌）

　前回は，ソフトウェア開発における工学的アプローチがなぜ失敗しているかを大局的な視点から検証した。さらに，開発プロセスにおける基礎的な問題点を明らかにした。今回は，モデル作成を題材に，そこに潜む問題点を見てみよう。

　一般にシステムを開発する際，まず現状分析，要求分析を実施する。このときシステム化する対象を含む実世界の現状を概念モデルで表現する。そして要求を分析してシステム化の対象を切り出し，設計，実装へと進む。

　その際に重要な役割を持つ図の一つがUML（Unified Modeling Language）のクラス図である。概念モデルでは静的な構造要素を表現する。設計，実装の段階では，それぞれに見合った構造要素に変わっていく。同じクラス図だが，開発のライフサイクルに合わせて抽象レベルを変えるのである。

　こう書くと簡単なようだが，その過程にはさまざまな課題がある。まず適切な概念モデルを作成するのが難しい。次に，概念モデルを詳細化していくと，そこに登場する構造要素（クラス）が概念モデルのそれと必ずしも1対1に対応しない。モデルを詳細化するたびに，元のモデルからかい離してしまう。

主キーを持つ概念モデル

　まず，概念モデルについて見てみよう。概念モデルとは，現実世界に存在するさまざまな概念のうちシステムに関連のある範囲を取り出して，システムでどのように扱うべきかを表現するものである。個々の概念を箱として描き，概念間の関係を線で表現する。

　箱として表現された概念には，それを見る人によって解釈にばらつきが出る危険性があることに注意しなくてはならない。ソフトウェア工学的に言えば，その人がシステムに対してどういう役割か，利害関係者（ステークホルダ）としての立場は何かによって関心が異なるので，概念のとらえ方も変わる。要求定義をする分析者，経営者，システムを利用するユーザー，アーキテクト，運用管理者などの立場によって，個々の概念が持つべき属性や振る舞いが異なる。概念モデルは，こうした違いがとりあえず問題とならない程度の抽象レベルで作成すべきである。そうして概念に対してシンボル的な概念名を与え，他の概念と明確に区別する。

　個々の概念を独立した単位として識別する際，主キーの考え方を有効に利用できる＊1。主キーはデータを特定するための識別子で，リレーショナル・データベース（RDB）に特化したものと考えられがちだが，実は概念モデルの作成時にも意識すべきである。オブジェクト指向の考え方にはインスタンスを識別する「オブジェクト識別子」はあるが，概念を区別するために実用上重要である主キーは見落とされがちだ。

　主キーを概念クラスの属性として定義しないとしても，主キーを意識して概念を識別することは重要である。核となる部分と，シナリオによって属性を変える必要がある部分を切り分けたいからだ。まず主キーを中心として概念を定義したあとに，変化し得る部分を追加の定義として付け加える。一般にロールやビューと呼ばれる部分だ＊2。こうすることで，定義の安定性と再利用性が改善できる。この点は，コンポーネントの再利用性，コンポーネント間の連携や振る舞いを決定するアーキテクチャの柔軟性などを考える前に，まず終えておきたいポイントである。

ユースケースとOOパラダイムの相性

　概念モデルと並んで重要なのが，ユースケースである。そのシステムを利用する人や他のシステムなどの「アクター」が，システムに求める要求を定義したものだ。技術の詳細に立ち入らず，ビジネス的な視点でシステムがカバーする範囲を定義し，アクターに対するシステムの振る舞いを明らかにすることを目的としている。

　ユースケースは，概念モデルを設計/実装モデルに結びつける際の方向付けに役立つ。現在の企業システム構築におけるオブジェクト指向開発では，外部イベントの処理や操作の呼び出し元になるユースケースをまず定義し，それに反応する概念モデルの設計表現（ドメインクラス）を考えていく。これにより，受動的な性格を持つドメインクラスが定義される。受動的なドメインクラスとは，自らがほとんど振る舞いを持たず，データコンテナとして機能するものである。外部からのイベントや操作の呼び出しがない限り動作を開始しない。この方法は，フレームワークが多用される現在のソフトウェア開発には適している。フレームワークを利用した開発では，アプリケーション固有の処理をフレームワークが呼び出すものとして実装する。

　またユースケースは，システムが提供する価値をエンドユーザーの視点で検証する単位となる。だからUP（Unified Process）やアジャイルな開発方法論では，エンドユーザーの視点に立って作られたユースケース（アジャイルな方法論では「ストーリー」）をプロジェクトの基本管理対象としてとらえ，進捗管理や開発リソースの割り当ての基本としている。

　しかしユースケースは元々，オブジェクト指向のパラダイムとは独立したものである。このため，オブジェクト指向パラダイムやコンポーネント・ベース開発と相性はあまり良くない。ユースケースからドメインクラスやコンポーネント・モデルへどのように対応づけてよいか理解しにくく，オブジェクト指向分析/設計（OOA/D：Object Oriented Analysis/Design）の適用を困難にしている。

　ユースケースを直接的にドメインクラスやコンポーネントに対応付けられれば，誰でも同じドメインクラスやコンポーネント定義の設計ができるはず。だが，そうはならない。ユースケースがドメインクラスの構造定義と横断的な関係にあるからだ。厳密に言えば，ドメインクラスは概念モデルで定義される主キーの意味に関連する属性を持つが，ユースケースの振る舞いに関しては複数のドメインクラスで責務を分担する＊3。一つのユースケースは複数のドメインクラスによって成り立っており，それらのクラス間の責務の連携によってシステム外部にサービスを提供する＊4。責務の連携はシーケンス図による動的モデルで表現される。つまり，ユースケースを詳細化すると，UMLではクラス図とシーケンス図の二つの図に分離した表現になる（図1[拡大表示]）。シーケンス図による動作の検証があって初めて，静的なクラス図として体系化できるのである。

　責務を分担すると，一つのドメインクラスの責務が複数のドメインクラスの責務に依存する場合も少なくない。どのドメインクラスにどの程度依存させるかは人によって判断が異なり，結果的にモデルの成果物にばらつきが生じる。ソフトウェア開発でしばしば問題になる現象だ。

　ソフトウェア開発では，人間が状況を観察し，まずインスタンスの生の現象を動的モデルとして認識する。それを体系化して客観的な表現を作るために，静的モデルで表現する。現象の認識には個人差があるし，体系化の際に表現の揺れが発生する。さらに一つのドメインクラスの責務が他のドメインクラスに依存するとなると，モデルのばらつきはより深刻なものとなる。