前回「分かりやすいモノ・コト方式のモデリング」は契約についてモノ・コト方式でモデリングを行いました。人と組織を一般化したパーティという概念を用いると、「契約はパーティとパーティの間に発生する事象である」と一般化することができます
コトを関連クラスとして扱った方が自然で分かりやすいと筆者は思いますが、皆さんはいかがでしょうか。関連クラスをもう少し用いた方がモデリングは行いやすいし、人の作成したモデルも理解しやすいと思います。
今回はステレオタイプを用いてモノとコトを識別し、注文から納品・請求の業務フローをサンプルとして注文の状態遷移を考えてみます。
過去2回にわたって関連クラスは使いやすいというお話しをしてきましたが、UMLのルール上の1つの問題点について触れておきたいと思います。
第13回「モノとコトによるモデリング」で注文の例を関連クラスで説明しましたが、実は問題があります。関連クラスの両側のインスタンスを固定したとき、関連クラスのインスタンスは一意に決まるというUMLのルールがあります。関連クラスに多重度の指定はできませんが、暗黙的に1に固定されていると考えることもできます。
この注文の例を関連クラスで表すと、例えば顧客のAさんが一度商品Xを注文すると二度と同じ商品を注文できないことになります(図1)。実際これでは困るので、関連クラスを通常のクラスにして、2つの2項関連で表現します。
関連クラスを用いたままでこの問題を回避する方法もあります。1つは関連を最新の注文1つに限定する方法です。もう1つは、関連クラスをリストクラスにすることも可能です。例では「注文リスト」を関連クラスにし、その下に注文を並べることもできます。
一般的にはモデリングの過程として、まずコトを関連クラスで表し(第13回 図2(a))、次のステップで関連クラスを2項関連の間にはめ込む形(第13回 図2(b))にしてしまうのが確実で分かりやすい方法です。
ここでファウラーのモデリングの原則を1つ紹介しておきます。蛇足ですが、ファウラー氏はアナリシスパターン、リファクタリング、XPなどソフトウェアの世界で先進的な活躍をされています。
つまり大切なことは「何のためにモデリングするのか」ということです。開発のモデリング作業も分析モデルから設計モデルに、それぞれ概要レベルから詳細レベルに変換していきます。一方、厳密性と分かりやすさはトレードオフであることを念頭に置くことも必要です。モデルを正しく理解できないまま詳細化していくのは危険です。
従って筆者は冒頭のUMLのルールを取りあえず横に置いておき、第1ステップは関連クラスでモデリングを行い、第2ステップで関連クラスを2項関連にはめ込んでいくスタイルが分かりやすさにおいて優れていると考えています。さらに本稿で次に述べるように、ステレオタイプを用いればさらに分かりやすくすることができます。
モノとコトをUML拡張の仕組みであるステレオタイプで表現してみましょう。クラスにステレオタイプ《mono》と《koto》を定義します。ついでにそれらを図2(a)のようなアイコンで表現することにします。
ちなみにこれらのアイコンを用いて注文の例のクラス図を図2(b)に示します。第1ステップとして《koto》は関連クラスで表し、次のステップで2つの《mono》の関連の間に《koto》をはめ込んで通常の2項関連の形にすれば冒頭のようなUML上の問題は生じません。このように一歩ずつモデリングを進めていくのが分かりやすい方法だと思います。しかもステレオタイプを用いれば図2(b)のように《mono》と《koto》が一目瞭然です。
例題として注文から納品・請求までの簡単な業務フローを考えてみましょう。この業務フローはオブジェクトの状態遷移としてとらえることができます。状態はイベントつまりコトにより遷移します。つまり状態はコトの結果を表すと考えることができます。オブジェクトの状態を表す方法は2つあります。
コトの結果が属性の値の変化で表される場合が(1)で、他オブジェクトとのリンクを張ったり切ったりが(2)です。(2)の特別ケースとしてリンク自体に属性を持つ場合があります。このリンク属性が《koto》です。
モノ・コト分析は、まず要となるモノ・コトに注目します。ここでは顧客からの受注にまつわるモノ・コトに注目します。
図2(b)のように顧客と商品の間にリンクが張られ、リンク属性として注文オブジェクトが生成されます。注文オブジェクトには注文日が記録されます。
納品の状態を表すモデルは2つ考えられます。最も単純なモデルは注文オブジェクトに納品日という属性を持たせる方法です(図3左側)。
もう1つの方法は納品という新たなオブジェクトを生成するモデルです。納品というオブジェクトに納品日を記録し、注文オブジェクトとリンクを張ります(図3右側)。
これも最も単純なモデルは注文オブジェクトに請求日という属性を持たせる方法です(図3左側)。もう1つの方法は請求という新たなオブジェクトを生成するモデルです。請求というオブジェクトに請求日を記録し、注文オブジェクトとリンクを張ります(図3右側)。
次にオブジェクト図とクラス図を段階的に作成してみましょう。図3左側はまったく単純なので、右側の方つまり納品と請求を注文とは別に作成するモデルについて考えてみましょう。
図4の上段のようにすでにモノ・コト分析で述べてきた基本形です。クラス図の誘導可能性はコトからモノに向けています。こうすることによって関連クラスを使わないモデルで《koto》がどのクラス間の関連クラスから抽出されたものであるか分かりやすくなります。つまりモデルが読みやすくなります。
納品は顧客と注文の関係ととらえます。「《mono》顧客A」と「《koto》注文1」のリンク属性として「《koto》納品1」オブジェクトを生成します。このように《koto》は必ずしも《mono》の間に生ずるとは限りません。
発注主と納品先は異なるかもしれないので顧客のロールを追加します。クラス図では顧客と注文の関連クラスを2項関連にします。誘導可能性は納品から顧客と注文の方向にします。
請求も顧客と注文の関係ととらえます。「顧客A」と「注文1」のリンク属性として「請求1」オブジェクトを生成します。請求先は発注主や納品先とは異なるかもしれないので顧客のロールを追加します。クラス図では顧客と注文の関連クラスを2項関連にします。誘導可能性は請求から顧客と注文の方向にします。
今回はモノ・コト分析のモデリングのために、クラスのステレオタイプ《mono》と《koto》を定義しました。次に注文から納品・請求までの簡単な業務フローをサンプルとして注文の状態遷移に注目し、モノ・コト分析でモデリングを行いました。ステレオタイプによりモデルはいっそう分かりやすくなったと思います。
次回はモノ・コト分析をパターン言語(第7回「パターンとパターン言語」参照)の視点でとらえてみたいと思います。お楽しみに。
河合 昭男(かわい あきお)
大阪大学理学部数学科卒業、日本ユニシス株式会社にてメインフレームのOS保守、性能評価の後、PCのGUI系基本ソフト開発、クライアント/サーバシステム開発を通してオブジェクト指向分析・設計に携わる。
オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立、理論と実践を目指し現在に至る。ビジネスモデリング、パターン言語の学習と普及を行うコミュニティ活動に参画。ホームページ:「オブジェクト指向と哲学」
Copyright © ITmedia, Inc. All Rights Reserved.