TEF道のねもとです。
今回は11月に実施した勉強会のレポートになります。
11月は小楠君による「オブジェクト指向分析を学ぼう～ユースケース駆動開発実践ガイド～」になります。今回はUMLを要求分析に用いるというワークです。（設計じゃないよ！）
お題はこちら。
ワークの流れ
架空の出張手配予約システムを題材にして行っていきます。
・ドメインモデリング
- まずは名詞を洗い出す。
- クラス図に載せてみる。
- 曖昧な名詞は集約する。
- 汎化、集約でドメインモデル間の関係をはっきりさせる。
・ユースケースモデリング
・ロバストネス図を記述
ドメインモデリングとは？
ドメインオブジェクトを洗い出し、クラス図で表現する作業。
集約、発散、関連、派生を考えながら表現することで、オブジェクト間の関連や曖昧さ、重複が減り、隠れていたオブジェクトが見つかる。
プロジェクトで使う用語辞典を作成する作業ともいえる。
プロジェクトメンバー間での正確なコミュニケーションを可能とする。
なるほどと思ったところ！！
ドメインモデリング
◇ドメインモデリングの作業について
ドメインモデルはDDDでいうところのユビキタス言語を作っていくのと似た作業になるな～と思いました。例えば今回の仕様書からは、"社員"、"出張者"、"予約者"などのなんとなく似たような単語が出ていて、これらは一体何を意味するのか、またどういう関係なのかを意識する必要があります。そうしないと顧客とチームのみならず、チームのメンバー内でも齟齬が起きますよね。
◇ドメインモデリングのポイント
時間をかけすぎない。「ユースケース駆動型プロセスではドメインモデルは不完全だと仮定しており、何が不足しているかを見つける仕組みを提供しています。」とのことです。
ユースケースモデリング
◇ユースケースモデルの必要性
今までユースケースモデルの必要性を感じたことがあまりなかったけど、自社の業務だとアクターが少ないし、決まってるからあまり必要なかったんだな～と思いました。アクターが増えたときなどはユースケース図あると見やすいし、図を見ることで様々なステークホルダーが認識を共有できると感じました。
ロバストネス図を記述
◇ロバストネス図の必要性
今までロバストネス図を描いたことがなかったので、結構苦戦しました。
どうやらユースケースモデルとシーケンス図をつなぐ役割をしているらしいです。なるほど。
◇ロバストネス図の注意点
バウンダリ同士を繋いではいけない。
感想
◇図で書くことのメリット
自分が思ったメリットを挙げていきます。
・人間にとって分かりやすい
・関連が分かる
・多重度が分かる
・文章より少し曖昧さが減る（気がする）
・要求にはない、ユースケースが見つかることもある
文章を書くことで思考が整理されるというのがあると思いますが、
UMLを書くとさらに曖昧性が排除されていいですね。
色々な図を描いて、まだ表現されていないオブジェクトを見つけるわけですが、
メンテナンスなどを考えると、実務でどう使うかはキチンと考える必要がありそうです。
自分としては要求を整理し、共有するという目的に絞って、図は使い捨てで描いていくのが良いと思っています。
馴染みのない人は自分が担当している身近なシステムのUML図を描いてみることから始めてみませんか？