カラーUMLでラピッドな分析モデリング!

OOAD講座については前回のロバストネス分析から設計モデルを作るところまでで一応の完結ということにしたのですが、今回はその補講ということで。

第3回で取り上げたクラス導出についてですが、通常は記事に書いたとおりユースケース等から名詞を探し出す品詞技法が用いられます。

オブジェクト指向での分析に慣れないうちは品詞技法が良いとは思うのですが、ある程度慣れてくると、もう少し迅速に、質の高い分析方法はないだろうかと考えます。
そこでご紹介したいのが、カラーUMLという方法です。

カラーUMLとは

カラーUMLは、2000年頃にピーター・コードによって提案された方法で、日本ではその訳書である「Javaエンタープライズ・コンポーネント カラーUMLによるJavaモデリング」で詳しく説明されています。

Javaエンタープライズ・コンポーネント―カラーUMLによるJavaモデリング
ピーター コード ジェフ デ・ルーカ エリック レイフェイブル
ピアソンエデュケーション
売り上げランキング: 794,031

ただ、この本は今では絶版になっていて、Amazon等で中古本を買うしかないような状態です。
私は、翻訳者の依田智夫さんと短期間ですがお仕事をさせていただいたことがあって、その際にこの本を戴きました。(随分、懐かしい話ですが・・・)
それ以来、私にとってはモデリングのバイブルとなっていて、今でもカラーUMLの方法をベースにしています。

4つのアーキタイプと色

カラーUMLとは、その名のとおりクラスを色分けする技法なのですが、重要なのは、どのクラスにどの色を使うかが決まっていること。クラスをアーキタイプ(ある程度緩い決まり)で分類して、アーキタイプ毎に色が決まっていることです。

アーキタイプは4種類あります。

  • Moment-Interval(瞬間・時間間隔) ・・・ ピンク
  • Role(役割) ・・・ 黄
  • Party/Place/Thing(人・場所・物事) ・・・ 緑
  • Description(説明) ・・・ 青

色は、ピンク→黄→緑→青の順に目立つだろうということで、クラスの重要性もこの順番とされています。

問題領域に特化しないモデル

カラーUMLの真骨頂とも言えるのは、4つのアーキタイプのクラスがどのように結びつくかが定義されていることです。上図は「問題領域に特化しないモデル」と呼んでいるもので、4つのアーキタイプのクラスが、ピンク→黄→緑→青の順番でつながっています(アーキタイプの重要度の順番と同じですね!)。

Moment-Intervalは、システムの中で瞬間や時間間隔を記録する必要があるもので、例えば「売上(これは多くの場合、売上の瞬間を記録します)」や、「賃貸借(賃貸借の開始から終了まで時間間隔を記録します)」といったものです。Moment-Interval(MI)にはMI-Detailと呼ばれる明細が付くことが多いです。(例えば売上に対する売上明細です。)

Roleは、Moment-Intervalの参加者です。例えばMoment-Intervalが売上なら、Roleは「売主」と「買主」です。Moment-Intervalが何かの製造なら「製造に使われる部品」という役割もあります。

Party/Place/Thingは、Roleの実体です。例えば私こと井上さんはParty(Person)ですが、井上さんはある場面では売主になるだろうし、またある場面では買主にもなるでしょう。なので、井上さんというPartyが直接Moment-Intervalに参加するのではなく、売主や買主というRoleを挟んで参加させた方が良いだろうということです。
例えば製造業(PCの製造)であれば、ある部品(シリアルナンバー101の、Core i5というCPU)はThingです。製造の時点では「PCの製造工程で組み込まれたCPU」というRoleになりますが、調達の時点では「どこかから買ってきたCPU」というRoleになるでしょう。つまり、Roleとして見ればいろいろあったとしても、Thingとして見れば1つなわけです。

Descriptionは、Party/Place/Thingの説明とかカタログ的項目と言われます。先ほど示したCPUの例で言えば、Descriptionは「Core i5」がどんな性能を持っているといった説明です。「シリアルナンバーが101のCore i5」ならThingになります。

「問題領域に特化しない」と言うとおり、このモデルは様々なビジネスの領域に適用できます。つまり、分析対象となっている領域(ドメイン)について、このモデルに当てはまるような単語を探し出していけば、質の高いドメインモデルが出来てしまうのです。

もちろん、いざ設計・実装となると、必ずこのモデルのとおりになるわけではありません。必要に応じてクラスが取捨選択され、モデルは洗練されていく必要があります。例えば、Descriptionは要らないだろうとか、Role抜きでMoment-IntervalとParty/Place/Thingをつないでも困らないだろうとか、そういう議論は当然にあります。
しかし、一旦、このモデルに当てはめてみようと考えることで、クラスの導出漏れを防いだりすることも出来ます。

まとめ

ずいぶん駆け足な説明となってしまいましたが、冒頭で紹介した「Javaエンタープライズ・コンポーネント カラーUMLによるJavaモデリング」には、問題領域に特化しないモデルをベースにモデリングされた、様々な領域でのモデルが満載です。
今となってはなかなか入手しづらいのですが、是非、ぱらぱらとめくってみて欲しい本です。

オブジェクト指向のことを書いている時点で「今さら」と思われるかもしれませんし、カラーUMLもやっぱり古いし、それほど普及した技法でもありません。
ただ、オブジェクト指向は多くの技術の前提になっていて、カラーUMLも有用性は全く損なわれていないと私は考えています。今後も、折に触れて取り上げていきたいと思います。

※タイトルを投稿当初から変更しました。(2014/2/1)

コメントを残す