メディア

変更に耐えるシステム構造とモデルの関係（下）：保守性・拡張性に優れたシステムを作る（3）

» 2006年06月07日 12時00分公開

[野村佳弘，日立ソフトウェアエンジニアリング]

前編「変更に耐えるシステム構造とモデルの関係（上）」では、システムの分析を行ううえで知っておくべき知識の整理をしました。分析（あるいは設計）作業には、システムのモデルを構築する作業が伴います。今回は、システムの概念モデリングを行う際に注意すべき点を明らかにしながら、洗練されたモデルが変更に強いシステム構造を得る最短距離であることを解説していきます。

（1）概念モデル（概要レベル）

　目的やビジネスの要求や業務フローが明らかになった後で、概念モデルを作成します。概念モデルはシステムの全体のエンティティの構造を主に洗い出します。E-R図に似ている部分がありますが、データを分析するのではなく概念の構造を分析します。属性や振る舞い、概念間の関係などを複数の視点で分析し構造を洗い出していきます。

　概念モデルは、業務シナリオから導き出されます。業務シナリオを書いてみるか、もしくはビジネス要求や業務フロー、ユースケース定義から、概念を洗い出します。

図1 概念クラス図（概要レベル）

　概念モデルでは、抽象化をどこまで考えるかが重要なポイントになります。保守性・拡張性をどこまで考慮するかにより抽象化のレベルが決まります。例えば、「会員」という概念をもっと抽象化して「人」という概念に抽象化したい場合があるかもしれません。それは「会員」という概念のほかに、今後、レンタルだけでなく販売もしたいというときに、「会員」と「顧客」を「人」という概念で抽象化して同じように管理したい場合に起こります。そこまでビジネスを考えないのならば「会員」でよく、もし今後のビジネス展開として販売が考えられるなら「人」という概念にまで抽象化する必要があるかもしれません。

　一般に、抽象化をすれば保守性・拡張性が高まると考えられます。適度に抽象化を行えば本質をとらえることができ、モデルを理解しやすくしますが、過度に抽象化を進めるとモデルが複雑になるので必要最低限にする必要があります。

　抽象化を行い、概念間の関係を定義することにより、本質を見極めます。表面的な構造ではなく、その背後に隠された構造を明らかにすることにより、変更に強いシステムを作り上げます。

　概念モデルで考慮すべき点を以下に示します。

［1］概念はクラスで表し、概念間の関係を定義する

　クラスには、主に属性を定義します。操作は、特に定義しなくても構いません。関係は、関連、汎化、集約、コンポジションなど利用して定義します。

　主要な概念は、対象とするシステムを考えるときに、変化しない概念を洗い出します。会員やレンタル商品は、システムの中では変化しません。それに対し通常会員はゴールド会員に変更できるので、主要な概念としては挙げません。

［2］関連クラス、カテゴリ化について検討する

　関連クラスは、関連をクラスにした方が扱いやすいときに利用します。主に、履歴を取りたい場合や、多対多の多重度がある場合に使用します。貸出は関連ですが、履歴として必要であり、多対多の関係を簡単にするために関連クラスとします。

　カテゴリ化は、概念をカテゴリで整理します。例えばDVD等のレンタル商品は、映画のタイトルによりカテゴリ化できます。

［3］汎化は動的分類、種類などを検討する

　動的分類は、通常会員はゴールド会員になることができるようにサブクラス間を遷移します。また、種類は、CD、DVDなどのレンタル商品の種類を表します。

※ ここでの汎化は、分析し理解するための汎化です。そのままJavaで実装できるわけではありません。設計・実装では、分析での汎化を実装できるように修正します。

［4］クラス間の多重度を定義する

　関連の両端のインスタンス間の対応（リンク）数を定義します。

概念モデルは、ユーザーに理解してもらい、エンティティなどの静的な構造を理解するために行われます。そして抽象化などを適度に行って、実現したいシステムの本質的な構造を明確にしていきます。

（2）ユースケース分析（概要レベル）

　ユースケース分析の概要レベルは、主にユースケース図とユースケース定義書の概要レベルを作成しながら分析を進めていきます。ユースケース図は、サービスの全体像を明らかにするとともに、システム化の範囲を決めます。そしてほかのシステムやアクターとの関係を明確にします。

　ユースケース定義書は、文章で記述します。概要レベルのユースケース定義書は、利害関係者、特にユーザーやシステム部門などに理解してもらえるように記述します。視点がユーザーであり、業務的な機能や入出力を明確化するために行われます。

（3）ユースケース分析（分析レベル）

　分析レベルのユースケース分析は、ユースケース分析（概要レベル）と概念モデル（概要レベル）を基に作成していきます。分析レベルでは、クラスの振る舞いを明確化することを主に目的にします。

　概念レベルのユースケース定義を基に、基本フローや代替フローを詳細に分析します。そして、これを基にシーケンス図を作成し、クラスの操作を洗い出していきます。

　クラスの属性などは、比較的簡単に洗い出せますが、振る舞いである操作を洗い出すことは難しいことです。オブジェクト指向分析で、最初に難しいのは、クラスにどのような責務を持たせ、操作をどのように定義していくかだと思います。操作はどのようなビジネスロジックをクラスに持たせるかを考え操作名を定義していきます。

　観点は、設計者や分析者、ユーザー企業のシステム部が対象となり、主に動的な構造や機能を理解するために行われます。

図2 ユースケースに基づくクラス図（クリックすると拡大）

　まず、ユースケース分析（分析レベル）で分析されたユースケース単位にユースケースに基づくクラス図を作成します。基本的に外部とのインターフェイスを担うビュークラス、サービスのプロセスを担うコントロールクラス、ビジネスロジックの実現を担うエンティティクラスで構成されます。ビュークラス、コントロールクラスは基本的に1つになります。エンティティクラスは、概念モデルにあるクラスを利用します。もし、ユースケース分析に基づくクラスを分析しているときに、概念モデルにないクラスが必要になったら、エンティティクラスを追加します。

　クラスを洗い出したら、クラスの責務を考え操作を定義します。操作はシーケンス図を利用して分析し定義していきます。

図3 シーケンス図（クリックすると拡大）

　シーケンス図は、シナリオごとに作成します。ビジネスロジックや、制約などをコメントで追記します。コントローラにはビジネスロジックを持たず、処理の手続きを定義するプロセスを持ちます。これが固有な構造に相当します。コントローラから利用するビジネスロジックを実現しているエンティティクラスが普遍的な構造に相当します。エンティティクラスの中にもプロセス的なクラスが存在します。例えば、2つのエンティティを利用してビジネスロジックを実現するようなクラスです。これについては次回、コンポーネント化でお話ししたいと思います。

（4）概念モデル（分析レベル）

　分析レベルの概念モデルは、クラスに責務を持たせ操作を定義し、汎化の動的分類などをステートチャート図で状態変化を明確にして、モデルを洗練します。

　貸出は動的分類があるので、状態遷移図で詳細に状態を分析します。そこで貸出中と返却済の状態のほかに貸出中には延滞という状態が存在することが分かります。会員も通常会員とゴールド会員があり、ある条件で遷移します。ここでは、状態に絡むビジネスロジックを分析することができます。

図4 概念モデル（分析レベル）（クリックすると拡大）

　このように、概念モデルやユースケース分析を行いモデルの構造を定義していきます。シーケンス図を利用して「機能の視点」からモデルを洗練し、状態遷移図を利用して「動的な視点」からモデルを洗練し、クラス図を利用して「関係の視点」から洗練します。この3つの視点で相互に繰り返しモデルを洗練することにより、操作や属性、ビジネスロジックの整合性が検証され、モデルを洗練していきます。

（5）クラスを鍛える

　オブジェクト指向開発では、ユースケースごとに分析・実装までを反復しながら開発します。最初に分析・設計したユースケースの結果を基に、次のユースケースを分析、設計していきます。このとき、普遍的な構造であるエンティティを利用しながら設計し、必要であるならすでに作成したエンティティに属性や操作を追加し、足りない場合は新たなエンティティを追加しながら、エンティティクラスの構造を新しいユースケースに対応するように鍛えていきます。また、今後追加されそうなユースケースなどを洗い出し、エンティティの構造が対応できるかを検討します。このように、いろいろなユースケースに対応するエンティティクラスの構造を定義して洗練し、クラスを鍛えていきます。クラスを鍛えることによりモデルが洗練され、変更に強い構造を持つことができます。

　以上、2回にわたって、ユースケース分析と概念モデリングにより、要求からどのようにシステムの構造を明らかにしていくかをお話ししました。多面的な視点で要求を分析することにより、要求とシステム分析の結果であるモデルとの乖離を少なくし、また、システム構造の背景にある本質を明らかにします。

　良いモデルには以下のようなことが備わっています。

本質的であること（適度な抽象化、背後にある恒常的なものを明らかにしている）
モデルが変更に耐え得る構造になっている
理解しやすいシンプルな構造
機能を満たしており無駄がない

　良いモデルはクラスを鍛えモデルが洗練されることにより実現されます。1回だけの分析・設計で最適なモデルができるわけではありません。ユースケース分析や概念モデリングを繰り返し行うことによりモデルが洗練され変更に強いシステム構造を得ることができます。次回は、拡張性を中心にコンポーネント化とホットスポットについてお話ししたいと思います。

参考文献：

▼UMLに基づくオブジェクト指向分析設計実践 IBM Rational University

▼UMLモデリングの本質（日経BP社）児玉公信

▼オブジェクト指向でなぜつくるのか（日経BP社）平澤章

「保守性・拡張性に優れたシステムを作る」バックナンバー