ICONIXプロセスを導入して、ユースケース駆動開発を実践したことがあります。
それから数年、使わないと人間忘れてしまうものですね・・orz
『やべぇ、ユースケース図がほんとにコードになった!ww』という感触を思い出し、後で復習出来るようにするため、
記録をつけながらもう一度実践してみたいと思います (`・ω・´) ワッフゥー
ではまず、プロジェクト(と言っても今回一人ですがw)の用語集にあたるドメインモデルを作りたいと思います。。
要求事項から名詞を抽出
顧客などから出してもらった要求記述から、出来るだけ現実世界にある名詞(オブジェクト名)を抽出します。内容 | 例 |
---|---|
要求記述 | 書店はインターネットから注文を受け付け、書籍を売ることが出来なければなりません。 |
抽出された名詞 | 書店、インターネット、注文、書籍 |
今回、『こんなことが出来るソフトが欲しい』という気持ちを箇条書きにして、要求仕様としましたww
名詞だと思った部分を赤字にしています。
抽出した名詞をつなげる
まずは、抽出した名詞(オブジェクト)を並べてみましたwこれらのオブジェクト同士の関係を、has-a関係やis-a関係の観点から見つけていきます。
関係名 | 見つけ方 |
---|---|
has-a関係 (集約) | 『AはBを持っている』の関係がなりたつ。 |
is-a関係 (汎化) | 『AはBの1種だ』の関係がなりたつ。 |
『タスクリストはコピータスクを持っている』(has-a関係)などを見つけて、つないでみましたww
声にだして言ってみると違和感がみつけやすいです。
もうちょっと眺めてみる
- 『要求仕様』には書かれていないが、必要最低限の要求として追加した方が良いオブジェクトはないか?
- 『精算』のように、名詞に見えるだけの動詞がオブジェクトになっていないか?
- ドメインモデルのクラスにしては小さすぎる(他のクラスの属性で事足りる)オブジェクトはないか?
『コピー出来るなら、移動もしたいやん?』、『ハッシュ値って、言うても整数やん?』
という心の声に従って上図のように書き換えてみましたww
ぐるぐると考えだすといろいろ手を加えたくなりますが、
最初のドメインモデリングは2時間程度でOKらしいので、一旦これで完成とします。
きっと、このあとのユースケース図作成やロバストネス分析の際に自動的に、このモデルに修正が加わるはずです(・∀・)
参考資料
より詳細な内容は、こちらの書籍をご覧下さい。
astah* communityでドメインモデル図を描く方法は、アシアルブログさんの以下の記事が分かりやすいですw
UMLを描こう - Vol.3 ドメインモデル図
※2012-11-24:参考資料を追記しました。
2 件のコメント:
ドメインモデルから一気にクラス図書いてマス。ロバストネス分析相当の分析を暗算してマス。慣れる(?)と手抜きになってくるお…
おぉ、ロバストネス分析を暗算すかΣ(・ε・;)
まだ慣れる域には遠いけど、がんがるぉ(`・ω・´)b
コメントを投稿