ユースケースモデリング
ユースケースモデリングは、この本の表題になっているようにICONIXの肝の１つです（もう１つはロバストネス分析）。このプロセスではユースケース図とユースケースシナリオを作成します。
尚、このエントリはユースケース駆動開発実践ガイドのサンプル例などを参照しながら読まれる事を前提として書いています。したがって具体例などが少ないのですが、ご了承願います。
ユースケース
ユースケースとはソフトウェアの機能的な要求です。それらを文章として記述したものをユースケースシナリオとかユースケース記述と呼びます。ユースケースでは、システムとアクター（ユーザや外部システム）との対話に重点を置きます。また、ユースケース図はユースケースシナリオ間の関係を視覚化する為に利用します。
ICONIXで目指すユースケースを一言で表せば、ユーザマニュアルを作ることです。ユースケースの作成方針としては、抽象的に記述する方法を推奨するやり方もあります。しかし、ICONIXの手法ではユースケースシナリオの作成方針はユーザとシステムを具体的に記述すことです。そのようにユースケースを記述していくことで、どんな画面のどんなボタンを押すことでどんな事が行われるかを高い精度で定義できるわけです。
このようにして作成されたユースケースはユーザマニュアルとしても使えるものとなります。また、ユースケースシナリオはそのまま要求テストの項目として使用できるでしょう。
ユースケースシナリオ
ICONIXでは必要最低限な項目のみでユースケースシナリオを作成します。１つ目は簡潔に要求を表すユースケースの名前です。２つ目はそのユースケースが最も一般的なパターンで実行された時のシナリオで「基本シナリオ（晴れの日のシナリオ）」と呼ばれます。３つ目は例外的な状況や想定される問題が発生した場合を想定した「代替シナリオ」です。通常、ユースケースは１つの基本シナリオと幾つかの代替シナリオで構成されます。「前提条件」「事後条件」「成功時保証」などといった複雑でたくさんの項目を書く必要はありません。
作成時のポイントはユーザとシステムの対話を記述することです。一般的にユースケースシナリオは基本的には次のように記述していきます。
- アクターは、〜する。
- （その結果として）システムは、〜する。
- （その結果として）アクターは、〜する。
ほとんどの場合、アクターがなんらかのアクションをする事がユースケースの開始地点となります。その結果としてシステムは何らかの処理を行い、結果が反映されます。さらにアクターはさらなるアクションをして…という流れになります。この流れを物語風に記述していくのがユースケースシナリオです。
この時、ドメインモデルで定義したドメインクラスの名前を使用するように注意します。そして、ドメインモデルにないオブジェクトを発見したならば、それをドメインモデルに追加していきます。このようにして、ドメインモデリングの時には不完全であったドメインモデル図は徐々に正確になっていきます。あわせてドメインモデルの属性も追記していきましょう。
また、ユースケースシナリオで記述する文章は、名詞-動詞-名詞の構造を意識して書きます。これは、この後のプロセスであるロバストネス分析を行うときに有効になるでしょう。文章は「〜できる」といった表現ではなく「〜する」という叙述的な記述にします。例えば、「ユーザはログインできる」ではなく、「ユーザはログインボタンをクリックする」と記述します。
尚、ユースケースシナリオが長すぎると思ったならば、複数のユースケースに分割することを検討します。そのような場合は後述のユースケース図を使って整理する事が有効です。
バウンダリ（画面）
ユースケースシナリオの書き方を調べると「ユースケースシナリオに具体的な画面名などは記述してはならず、抽象度を高くする」といった指針を多く見つける事ができます。しかし、ICONIXでは全く逆のアプローチをとります。すなわち「可能な限り画面名などを具体的に書く」という事です。
どちらが優れているかという事ではありません。ICONIXでのユースケースモデリングは、画面（バウンダリ）と振る舞い（コントロール）の分析であるロバストネス分析へ繋ぐためにあります。また、ユーザガイドと要求テストが導けることを目標とする為、具体的であればあるほど良いのです。
また、実際の開発の中では、ユースケースの作成と合わせてユーザ画面のモックアップを作成します。モックアップは、設計者とクライアントがユースケースシナリオを読む手助けをしてくれます。ですが、モックアップ作成時には色合いや配置などは考慮せず、ソフトウェアの振る舞いを定義することに集中する必要があります。後からボタンの大きさを変える方がボタンを追加するよりずっと容易です。
