ユースケース駆動開発実践ガイド勉強会(要求駆動勉強会)参加まとめ①

 

要求の探索

要求の探索にはトップダウン式とボトムアップ式の二つがある。

この二つを組み合わせて使わないとならない。

トップダウン

クライアントは何が欲しいか仮説思考で見つけていく。

・メリット

付加価値を感じやすい。

・デメリット

出来上がる完成の要求が人によってバラバラになる。

ボトムアップ

画面のUIなどから名詞を見つけて要求定義していく。

・デメリット

自動化するだけ。付加価値を感じづらい。

 

概念モデリング〜概念モデリングの洗練までの大まかな流れ

※注意点

エンティティは概念モデルにいる。

データを持っているのはエンティティ。

ドメインモデルで出てくるのはエンティティのみ。

ドメインモデルには、画面オブジェクトは出てこない。

 

用語メモ

ユースケース

・棒人間で書く図。ユーザーシナリオを書く。必要な機能の洗い出し。

ユースケースシナリオ

・システムとユーザーの会話のみを書く。

・詳細な部分は詳細設計図に入り込んでいる可能性がある。

・アクティビティ図で書く。

・登場人物はシステムとユーザーのみ。

・内部の処理は書かない。

・分岐処理も書く。

 

①概念モデリング

概念モデリングでラフスケッチとリレーションを考えた後に、ユースケースシナリオを考える。

概念モデリングでやること

・これから作るシステムの概念の洗い出し

ユビキタス言語を作る

1回目の概念モデリングは一度やって終わりではないと言うこと。

ここで名前のブレも無くしていく。

例として「利用者」「顧客」は何が違うのかなどを決める。

ユースケース

議論があちこちに発散しないように、なるべく早くユースケースモデリングに行く。

ユースケースのシナリオを考えて足りない名詞を見つけたら、それは重要な概念である可能性があるので、概念モデルに反映する。

ユースケースをやって見つけた名詞(画面オブジェクトのことではない)は、クラスの属性もしくは、クラスの名前になる重要な要素なので、それも概念モデルに反映する。

③概念モデリングの洗練

ユースケースのシナリオを考えた後に、モデルの見直し。

ロバストネス

モデルの見直しの後にロバストネス分析をする。

考慮不足だったオブジェクトが発見されたら、それも概念モデルに反映させる。

ユースケースの洗練

初回のユースケースモデリング時には、名前が不透明だった画面オブジェクトの名前もこのロバストネス分析によって名前が明確化されるので、それをユースケースモデリングにも反映させる。

エンティティと画面オブジェクトのリレーションを考える。

⑥概念モデリングの洗練

再度発見された概念を追加・名前の変更をする。

 

制約の素晴らしさ

方針があってこその手段。

方針を実現するための手段をまず挙げる。

挙げたものに制約をかける。

制約をかけたものの中でトレードオフ分析を行う。

そこから設計に入っていく。設計段階でそこまで決めて、制約をかけて絞った後に、

・FW

・言語

・DB

などの詳細を決めていく。

 

「つまり制約とは、便利なツールである。制約に振り回されるのではなく、制約は使いこなすものだ。」(Byせやかて駆動さん)

 

メモ

・テスト駆動

できるだけ早くテストすること

オブジェクト指向は保守性だけじゃない。

 

手続型は画面上から処理を見つけて処理を羅列していく

用語メモ

・UI

ユーザーインターフェース

・BL

ビジネスロジックドメインモデリングを考えていく。

・DA

データアクセス層。DBとの接続処理を書く。

依存性逆転の法則

永続化の機構が変わった時に、手段が方針に影響を与えないために、詳細を方針に持ち込まないこと。

DAがBLに依存するようにして欲しいよね。

方針は変化が起きにくいから安定している。

安定に依存させなくてはならないということ。

不安定なものを安定に依存させる。

安定しているということは抽象度が高い。

抽象度が高いということは、手段が沢山あるということ。

不安定なものを安定から隠してしまう。

 

例えば、DA(手段) のインターフェースを上位の概念(方針)であるBLに置くということが、依存性逆転の法則ということ。

 

このように、方針と詳細を分けることによって、後からFW・言語を変更したくなったときに、方針と詳細が分離されているので、柔軟な変更が可能になる。

 

非機能的な側面・機能的な側面

ステークホルダーとして挙げられるのは

・開発者

・PO

・顧客

 

機能的な側面と非機能的な側面の要求がごっちゃになっていると、ただ複雑なだけで分かりにくいから、一旦機能的な要求・非機能的な要求の関心を分離して考える。

 

ステークホルダーの品質的な要求(非機能的な要求)の矛盾箇所はザラにあるから、そのステークホルダーの求める要求のバランスの良い落とし所を探していき、それをステークホルダーに同意を取ることで品質の要求が定義づけられる。(非機能要件定義)

 

このための良い思考FWとして下記のようなものがある。

what

タイトルを言う

why

なぜそれを言うのか(方針)

how

そのための手段を言う(手段)

 

(監修:せやかて駆動さん)