「UMLモデリング入門」を読んで

UMLモデリング入門を読んだので、感想を書く。

本自体について

タイトルに「UML」とあるがUMLの解説書というわけではなく、あくまで述べられている主題はモデリングに関してであり、UMLはそのための説明手段といった立ち位置だった。

「モデルとは何か」といった基礎的な部分から、3つの側面

• 静的モデリング
• 動的モデリング
• 機能モデリング

について、果ては業務分析〜要求設計までの仮想事例まで説明されてる。

感想

「もの−こと−もの」の構造

「ものごと」は「もの」と「もの」の関わりから生ずる「こと」なのです。
これが概念モデルでの意味のある最小単位と言えます。(中略)
最初の最小単位を足がかりにして他の「もの」や「こと」の構造を展開していきます。(p.127)

例としていくつか「こと」から派生して「もの」や「こと」を考えてみる。

• 「注文」: 「購入者」と「商品」
  • ギフト配送(購入者≠送り先)を考慮したいので「送り先」の概念を追加
  • 予約や受注生産の考慮が必要なので「注文タイプ」の概念を追加
• 「配送」: 「依頼主」と「送り先」
  • 「依頼主」と「送り先」のそれぞれには必ず住所があるので「住所」型を導入
    • 「住所」は郵便番号、都道府県、市区町村...からなるのでそれぞれを型として導入
  • 冷蔵や冷凍を考慮したいので「クール区分」の概念を追加
  • 梱包資材やサイズによるサービスの違いを考慮したいので「サービスタイプ」の概念を導入

こんな感じで、この考えはいざ概念モデリングをするぞとなったときに、取っ掛かりとして大変役立ちそうだと思った。

制約

モデリング作業の大半は、多重度やロールも含めて、制約を明らかにして記述すること(p.121)

ドメイン駆動設計では、エンティティや値オブジェクトの生成時に制約を課すことで、無効な状態のインスタンスの存在を許さないようにする。「軽量DDDはアンチパターンに陥りやすい」とよく言われるが、この課すべき制約が十分にモデリングされていないがために、役に立たないエンティティや値オブジェクトのクラスが作られてしまうのが所以なのかなと感じた。

抽象だけじゃだめ

静的・動的・機能モデリングのいずれにおいても、シナリオ、特にアンチシナリオを考えることでモデルのデバッグができる。
（アンチシナリオ＝モデルの問題点を鋭くえぐるテストシナリオのこと）

考えた抽象から一度具体的な事例に落とし込んで考えてみることで、抽象側がより洗練される。

７章の記載の「クリーニング店のビジネス」をモデリングする演習を実際にやってみた際にもこれは感じた。
内容としては、施主へのインタビューと業務プロセス図から概念モデルを導出し、その後で別途示されたシナリオに沿ったオブジェクト図を書く、といったものだった。一度インタビューに沿って概念モデルを書いたのだが、オブジェクト図を書く段階になって、インタビュー中には一度も現れなかった「ドライクリーニング」というシナリオが初めて現れたため、一度書いた概念モデルを修正・拡張し「クリーニング種類」という型を導入した。

著者の別著である「UMLモデリングの本質」で述べられている「モデルの揺さぶり」はこのことなのであろう（本自体は読めていないが、説明文を読む限りではそう）。

最初に考えたモデルの元になったシナリオ（施主へのインタビューなど）が全てのケース・パターンを網羅しているとは限らないし、むしろしていないほうが多そう。
ドメインエキスパート自身が当たり前にやってることというのは、言われないとそれが特筆すべき事項だと気付かないものだし、門外漢であるモデラーがきちんと引き出してあげないといけないのだろうなと感じた。

意味波

この「モデルの揺さぶり」の話に、「プログラマー脳」の13章で紹介されていた「意味波(semantic wave)」と近いものを感じた。

簡単に言うと「初心者が物事を理解する際の認知プロセスは、抽象→(アンパッキング)→具体→(リパッキング)→抽象、という流れである」といった内容なのだが、大抵のモデラーはモデリング対象のビジネスドメインにおいて初心者なので、当たらずとも遠からずかもしれない？

その他印象に残った細かい点

• モデル＝ある人のある状況に関する明示された解釈
• ある概念の意味を正確に述べるのは困難、単独の概念でなく他の概念との関わりの中で意味を述べる。
• モデリングの段階では型か属性か固定するよりも必要に応じて相互に変換するのが自然
• べき型の概念
• ビジネスプロセスには「フィードバック回路」があり、知識が蓄積・再利用・再生産される
• ユースケース記述とそれに対するユースケース図の役割（ユースケース間の関係を図示する）