ユースケースの疑問

「ドメイン駆動設計」を読みなおすうちに、ユースケースとは一体何なのか、ユースケースはどこで役立つのか、という疑問が湧いてきた。
以下ラフなメモ書き。
理解できたら後で追記していく。

【0】ユースケースは謎だ。
ユースケース記述の書き方、ユースケース図の良い書き方、などを色々読んできたし、試してみたけれど、何かしっくりこない。

結局、画面設計書やバッチ設計書、システム構成図、DB定義書などのような大量のExcelドキュメントばかり作って、システムの全体概要がすぐには理解できない。
本来、ユースケースは、ユーザ観点でシステムが提供するサービスをまとめたものであり、ユースケースを見れば、システムの機能概要が分かるはずなのに、僕の経験ではユースケースが使われる場面が少ない。

理由を考えてみると、ユースケースの使い道が分かっていない気がした。
以下、疑問をリストアップしてみる。

【1】ユースケースの粒度は？

ユースケースを書く時、粒度を揃えるのが難しい。
ユースケース記述をおおまかに書くと、その後の設計工程で使いづらい。
かと言って、ユースケース記述を詳細設計のように書くと、ユースケース記述の量が増えて読みにくくなる。

「ユースケース実践ガイド」では、ユースケース記述にユーザインターフェイスは入れない方がいいと言う。
「ユースケース駆動開発実践ガイド」では、ユースケース記述で、バウンダリとして画面などのGUIを入れて具体的に書いた方がいいと言う。
どちらが正しいのか？

「ユースケースはユーザに提供するサービスを示す」「ユースケースはアクターとシステムの相互作用を示す」ことを考えると、要件定義ではユーザの目的が分かる概略レベル、外部設計以降ではシステムとの相互作用が分かるレベルで書いた方がいいのだろうと思う。

僕は概略レベルのユースケース記述は、ユーザであるアクターと対象システムの間で相互作用を示すシーケンス図を描く場合が多い。
システムコンテキスト・レベルのシーケンス図なので内容はシンプルだが、アクターがトリガーとなり、システムが操作の結果を返すやり取りを記述しやすい。
まずは、シーケンス図レベルのユースケース記述が書けなければ話にならない。

詳細レベルのユースケース記述は、ICONIXプロセスのように、ユースケースのシナリオをロバストネス図で描けるように、具体的なバウンダリも記述して相互作用を書く方が好きだ。
その方がイメージも湧きやすい。

しかし、工程ごとにユースケースの粒度を区別した時に、工程間のユースケースのトレーサビリティをどのように保証するのか？
ユースケースを細分化していく方法はあるのか？

【2】要求とユースケースの関係は？　機能要件とユースケースの関係は？

ユースケースは、要求を詳細化した(refine)もの。
ユースケースは、機能要件をストーリーの形で表現したもの。

したがって、ユースケースから要求まで前方追跡できるし、ユースケースから機能要件へ追跡できる。
その関連を表現したダイアグラムやモデリングツールはあるか？

SysMLの要求図には、ユースケースと要求(Request)を洗練(refine)で関連付けることができる。
また、SysMLの要求が非機能要件(性能、使いやすさ、保守性など)であれば、ユースケースから非機能要件へ追跡(trace)の関係を作ることもできる。

つまり、ユースケースと要求は表裏一体の関係。

【3】ユースケースの網羅性はどこで担保するのか？

「UMLによるオブジェクト指向モデリングセルフレビューノート」では、ユースケースは20個ぐらいにした方がいいという指摘がある。
しかし、ちょっとした業務システムならば、ユースケースの数はかなり膨大になる。
だから、ユースケースとアクターの集合をパッケージ図として分けるやり方を導入して、分割しようとする。

でも、ユースケースの網羅性はどこで担保するのか？
ERPのような業務システムならば、膨大な数のユースケースが必要で、それらがすべての要求を満たし、詳細化したものになるとどのように保証するのか？

ユースケースもカテゴリ化、階層化していく手法は必要ではないのか？
ユースケースとSysMLの要求を紐づけて、XDDPのようなトレーサビリティマトリクスによって、要求と実現すべきユースケースの網羅性を担保する方法はないのか？

【4】ユースケースを機能分割していく方法はあるか？

ユースケース記述をたくさん書くと、複数のユースケースに共通のロジックがあり、その共通ロジックをまとめて切り出したくなる。
ユースケース図では、包含関係(include)で共有のユースケースを抽出して再利用できる形式にする。

しかし、「ダイアグラム別UML徹底活用」ではユースケースを機能分割するのは良くない、ユースケースの機能分割は3段階以上すべきではない、という指摘もある。
だが、共通ロジックを括り出して再利用するために、細分化するのは常套手段だ。

includeなユースケースの粒度も問題だ。
includeなユースケースはどこまで細分化すべきか？
普通は、アクターが実行できるレベルまでであり、共通関数のようなユースケースにすべきではない。
しかし、共通関数のようなユースケースを作りたくなる時もある。
どのように折り合えばいいのか？

【5】ユースケースのextendの使い道は？

「UMLによるオブジェクト指向モデリングセルフレビューノート」では、ユースケースは条件分岐を作らない方が良いという指摘がある。
「ユースケース駆動開発実践ガイド」では、基本フローと代替フロー、晴れのシナリオと雨のシナリオで作るべきと言われる。

しかし、シナリオに条件分岐をどうしても入れたくなる時がある。
また、設計において、例外処理を洗い出す作業はすごく重要だ。
実際の実装内容としては、基本フローよりも例外処理の実装の方がコード量が多いし、例外処理の実装に頭をかなり使う。
そのような例外処理を全て書き出していたら、ユースケース記述はすごく読みにくくなる。

ユースケースでIF文を書きたい時、拡張ポイントを定めて拡張(extend)形式を使え、というフォースがある。
例えば、注文ユースケース中に、ログイン認証の分岐ロジックが途中であれば、extendを使った方がいい。

だが、extendを使うのは難しい。
「ユースケースによるアスペクト指向ソフトウェア開発」に書かれているようなアスペクト指向の考え方が必要だから。

結局、複雑な条件分岐や例外処理をユースケース上でどのように表現すれば良いのか？

【6】ユースケースからクラス図へどのように展開していくのか？

従来のオブジェクト指向設計では、ユースケース記述から名詞を抽出してクラスに設定し、概念モデルを描く手順で進める。
しかし、このやり方はとても素朴なやり方のため、実際の詳細設計に落とす時にひどく苦労する。
概念モデルのクラス図と詳細設計のクラス図は粒度があまりにも違うからだ。

個人的には、ICONIXプロセスのように、ユースケース記述からロバストネス図でオブジェクトの絵を描く手法が最もスムーズな気がしている。
ロバストネス図が描ければ、バウンダリ→View層、エンティティ→クラス、コントローラー→クラスのメソッドに責務を割り当てることで、クラス図とシーケンス図へ詳細化できるようになる。
ロバストネス図をDFDのように描ける点も良い。

だが、他にはどんな方法があるのか？
「実践UML」ではコミュニケーション図、「オブジェクト開発の神髄」ではコンポーネント図に詳細化していくが、どんなコツがいるのか？

また、ユースケースとクラス図、シーケンス図、ステートマシン図、アクティビティ図などのモデル間のトレーサビリティはどのように保証するのか？

Enterprise Architectやastah Professionalには、モデル相互をリンクする機能がある。
相互リンクすれば、モデルからユースケースへ追跡できる。
但し、手作業なのでモデルの数が増えたり、変更箇所が多くなると面倒になる。

モデルのトレーサビリティは、UMLよりもSysMLの方がよく考えられている。
SysMLでは、モデル間のトレーサビリティを仕様に含んでいるから。
UMLでも同様に、モデル間のトレーサビリティを表現できないか？

【7】2次開発や保守におけるユースケースの使い方は？

新規開発で作ったユースケースに対し、2次開発でそのユースケースを機能拡張したり、機能修正する時がある。
システム保守では、障害修正や機能改善のために、ユースケースを修正する時がある。
その場合、ユースケースはどのように修正すれば良いのか？

ユースケース全体を修正すると、再テストの工数が増えてしまう。
できれば、ユースケース記述の一部分に拡張ポイントを置いて、extendを使って機能追加するように修正したい。
そうすれば、機能追加したロジックだけをテストするだけで良いから。

でも、全ての場面で、既存のユースケースを拡張する方法で解決できるわけではない。
機能改善や機能修正をユースケースに反映する時に、他の良いテクニックはあるのか？

【8】反復開発がユースケース修正の試行錯誤にならないようにする工夫点は？

ユースケース駆動の開発は、反復型プロセスのオブジェクト指向開発と同一だ。
だが、反復型プロセスは、ノウハウがないと非常に難しいと個人的に思う。
スコープが揺れてしまいがちなので、スコープがどんどん拡大してしまい、分析麻痺になったり、単なる手戻り修正になってしまいがちだから。

本来のあるべき姿では、ユースケースを作り、開発スコープを定めて、ユースケース記述からシナリオを細分化していき、実装しながら反復的に開発していく。
だが、ユースケース記述の品質が悪ければ、何度も手戻り作業が発生し、いつまで経ってもシステムが完成しない。

特に、代替フローや例外処理を十分に洗い出しておかないと、詳細設計と実装で痛い目にあう。
でも、要件定義や外部設計のレベルで、代替フローや例外処理を洗い出しておくのは非常に難しい。
実際に開発してみないと分からない時がある。

そのような試行錯誤で開発する時に、ユースケース記述の構成管理や変更管理も重要だ。
品質が安定しているバージョンやリリース対象のバージョンのユースケースにはタグを付ける。
もちろん、ユースケースに関連するクラス図などの設計モデルにもタグを付けて管理する。
そのような管理手法がユースケース記述にも反映されているか？

EnterpriseArchitectやAstah Professionalには、クラス図などのモデルの履歴を残し、マージできる機能がある。
しかし、モデルのマージ作業は結構、面倒な作業だ。

もっとうまいやり方はないのか？