根本から理解するオブジェクト指向分析/設計

2006.12.07

　具体論に入る前に，まずオブジェクト指向分析/設計とは何を意味するのかを定義しておきましょう＊1。

　そもそも「分析」とはどういったことを指すのでしょうか。辞書を引いてみると，“ある事柄の内容・性質などを明らかにするため，細かな要素に分けていくこと”とあります。オブジェクト指向分析を適用する場面で明らかにしたい事柄とは，どのようなシステムを作らなければならないのかということです。つまり，オブジェクト指向分析とは，“どのようなシステムを作らなければならないのかを，オブジェクトという要素を使って解明すること”ということになります。これに対しオブジェクト指向設計とは，“分析によって明らかにしたシステムの実現手段を，オブジェクトという単位を使って明確にすること”となります。

　両者の違いがイメージできたでしょうか。では以降は，具体的なサンプルに基づいてオブジェクト指向分析/設計の仕方を見ていきましょう。題材は「図書館の図書貸し出し管理」です。システム化案件を図1のように挙げますので，皆さんも一緒に考えてみてください＊2。

図1●図書貸し出し管理システムの機能的な要件

オブジェクト指向分析

　分析作業の目的は，利用者から見てシステムが何をするべきなのかを目に見える形で表し，関係者間で合意を得ることです。この“システムが何をするべきなのかを目に見えるようにする”のが「モデリング」と呼ばれる技術です。モデリングでは，システムを“静的な側面”と“動的な側面”の両面から定義していきます。定義した結果は，一般的にUMLを使って表現します。静的な側面をモデリングするために「概念モデリング」を，動的な側面をモデリングするために「ユースケース・モデリング」を行います。

　これら二つの作業はどちらが先でも問題ありませんが，概念モデリングから着手する場合がほとんどです。実際は，両方のモデルを少しずつ洗練していくようになるはずです。

概念モデリングはシステムの静的側面を定義する

　まずは静的な側面を定義する概念モデリングの作業を見ていきましょう。概念モデリングでは，システム化の対象となる業務領域にどのような管理すべき情報が含まれているのかを洗い出し，それらの情報間の関係を明らかにします。モデリングの結果は，UMLのクラス図で表します。概念モデリングを実施することによって，(1)システムの全体像を手早く理解できる，(2)業務領域の用語を統一できる，(3)設計の準備ができる（データベース，アプリケーションの基本構造として概念モデルを利用する），といった効果が得られます。

　概念モデリングは図2のような手順で進めます。この作業は，モデリングの専門家と業務の専門家が会話をしながら進めると効率よく進みます。業務でどのような情報を扱っているのかは，開発者にはなかなかわからないからです。

図2●概念モデリングの実施手順

概念候補のグループ化をしよう

　図2に沿って説明していきましょう。まず「1.概念候補の導出」は，システム化の対象となる領域にどのような情報があるのかを抽出する作業です。とにかく思いついたものをどんどん出すのがコツです。例えば，目に見えるもの（顧客，店，商品），目には見えないが業務上管理しているもの（口座，在庫），業務上の重要なイベント（注文，売上，貸し出し）といった指針に基づいて抽出するとよいでしょう。今回の「図書館の図書貸し出し管理」というサンプルでは，「利用者，管理者，書籍，貸出，返却，書籍名，著者，カテゴリ，棚，貸出期限，出版社名，出版年月日，返却日，ISBN，督促」などの候補を洗い出してみました。


	図3●概念候補を三つにグループ化した

　次に「2.概念候補のグループ化」を行います。導出した概念候補の中で結びつきの強いものを集めてグループ化する作業です。ここで実施するグループ化は，概念モデリングを円滑に進めることを目的としたものなので，グループ化の基準をあまり気にする必要はありません＊3。どのグループにも入らない概念候補がある場合は，“その他”のようなグループを作ります。図3がサンプルをグループ化したものです。

　ここから先の作業は，各グループ別に行います。まず「3.概念の特定」では，洗い出した各概念に対して以下のような観点でチェックし，概念として適当ではないものを除外していきます。

●同じ言葉でも，二つ以上の異なる意味があれば分割を検討する

●違う言葉でも，同じ意味のものがあれば名寄せを検討する

●何らかの概念の属性となるべきものをふるい落とす

●概念として適切な名前に変更する（例：「会計伝票」→「会計取引」。伝票そのものが重要なのではなく，伝票の中の情報が重要だから）

こうして図3の三つのグループのうち書籍グループをチェックすると，カテゴリ，書籍，棚の三つが残ります。

　続く「4.主属性の定義」では，各概念が何を表すのかをわかりやすくするために，主属性を定義します。そのときの指針として，

●各概念ごとに定義する属性は三～五つぐらいまで

●属性をすべて洗い出すことが目的ではない

●属性ではなく別概念となる場合もある

●（現段階では），RDB（リレーショナル・データベース）の設計はしていないので，すべての概念に主キーを定義する必要はない

を参考にしてください。

　サンプルの書籍グループに主属性を定義してみると図4のようになります。ここで注意してほしいのは，対象となる業務領域，システムの役割に応じて属性は変わってくるということです。例えば，今回は図書館の貸し出し業務を行うという文脈なので図4のようになっています。仮に出版社で本を管理するシステムのモデル化ならページ数や印税などの情報が必要になるでしょう。つまり概念モデリングの作業では，対象となる領域次第で同じ概念でも求められる属性が違ってくるのです。