勉強日記

チラ裏

Use Case Driven Object Modeling with UMLTheory and Practice ch2. Domain Modeling (1/2)

ユースケース駆動モデリング 勉強メモ

www.apress.com

Domain Modeling

  • 「レビュー」
    • 編集者のレビュー？
    • 消費者が投稿するレビュー？
  • こういうミスコミュニケーションを避けるための共通の語彙
  • プロジェクトを通じてたえず更新し、問題領域のその時点での理解をつねに反映する

The 10,000-Foot View

What's Domain Model?

  • 単なる辞書よりも良いもの
    • 関連を視覚的に表現する
      • has-a
      • is-a

Why Start with the Domain Model Instead of Use Cases?

  • ドメインモデル
    • クラス図
    • モデルの静的な部分の基礎
    • 構造を記述する
  • ユースケース
    • オブジェクトについて、現実に即して書く
      • 抽象的・あいまいにしない
    • モデルの動的な部分の基礎
    • 振る舞いを記述する
  • ドメインモデルよりも先にユースケースを書くと、語彙が固まっていないので、抽象的・あいまいになってしまいがち

Domain Modeling in Theory

Top 10 Domain Modeling Guidelines

10. 現実の世界のオブジェクトに着目する

  • ソフトウェアの構造を現実世界のモノに寄せよ
  • 現実の世界のモノはソフトウェアの要件よりも変化が少ないものである

9. オブジェクトの関連を汎化(is-a)と集約(has-a)で表現する

  • 関連のうち95%はこれで表せる
    • book has a book review
    • credit card is a payment type

8. 最初のドメインモデリングは数時間程度に留める

  • 時間の枠を設けよ
    • 数時間程度
  • 完璧に仕上げる必要はない
    • 随時更新
  • むしろ、不完全であることを想定している
  • 2時間のブレストで80%完成して、問題領域の80%において語彙の曖昧さがなくなれば、それでよいのである

7. (現実の)問題領域の主要な概念を抽象化してクラスに整理する

  • 要件は、現実世界よりも頻繁に変わるもの
  • 要件ではなく、現実世界を抽象化してモデリングしたほうが変化に強くなる

6. ドメインモデルはデータモデルではない

  • クラスとテーブルを混同するな
  • TableManager 的なクラスを作ることはあるが、それはRDBMSを隠蔽するためのものであり、問題領域のオブジェクトを表現するためのものではない

5. オブジェクトはDBのテーブルではない

  • オブジェクトは単一のモノ
  • テーブルはモノのコレクション
  • テーブルの1行とオブジェクトとが1:1対応するとも限らない
    • 【補】だからこそPofEAAでいうところのDataMapperなどが必要になる

4. ドメインモデルをプロジェクトの語彙として使用する

  • 曖昧さが敵ならば、ドメインモデルは防衛の最前線

3. 名前のゆれを避けるため、ユースケースを書く前にドメインモデリングを行う

  • ユースケースを統一された語彙で記述する
    • さもないと後で大変なことになる

2. 最終的なクラス図がドメインモデルと一致すると期待せぬこと。ある程度は似る

  • ドメインモデルは意図的にシンプルに保たれる
  • シーケンス図等を書きつつ詳細にクラス設計していくと、クラスはどんどん追加され、ドメインモデルのクラスは複数の実装クラスに分割されたりする
  • が、ほとんどの実装クラスは対応するドメインモデルクラスがあるはずである

1. 画面その他のGUI-specificなクラスをドメインモデルに含めない

  • 実装の詳細にまみれ複雑化したドメインモデルが出来上がってしまう
  • ドメインモデルはあくまで問題領域に着目する
    • 解決領域ではなく

Internet Bookstore: Extracting the First-Pass Domain Model from High-Level Requirements

  • 「システムはこれをする」「システムはあれをしない」といった要件から名詞・名詞句を抽出する
  • これがドメインモデルのクラス候補になる
  • 本質的に同じものを指している類語をはじく
    • 例
      • List of Accounts と Master Account List
      • Book と Book Detail
    • 微妙な例
      • Book Catalog と Book List
      • こういうのはクライアントに確認しよう
  • 重複していないやつ
    • 例
      • Customer Account と Customer
        • Customer AccountはDB中のエンティティ
        • Customerはシステム外のアクターであり、ユースケースに現れるべき (なのでドメインモデルからは外す)
  • UI絡みだから含めないやつ
    • 例
      • Password
      • Title
      • Keyword
    • 【所感】システム化対象がCMSとかだったら含めるべきだと思う
  • 何日もかけないこと
  • 関連の間違いにを見つけるには、「is-a」「has-a」と声に出して読んでみるとよい

continuous improvement via ongoing iteration and refinement

英語

  • glean
    • 情報、知識等を苦労して少しずつ収集する
  • slivers
    • 僅かな部分
  • rampant
    • 横行している
  • vigilant
    • 気を配っていること