ICONIXプロセス

札幌Javaコミュニティでは「ユースケース駆動開発実践ガイド」の読書会を行っているわけですが、勉強会の成果物的な意味も含めて、とりあげられているICONIXプロセスに関して簡単にまとめておきます。

ICONIXはあまり聞き慣れないプロセスかとは思いますが、ロバストネス分析という名前はどこかで聞いたことがあるのではないでしょうか？実は、ICONIXプロセスの一部にロバストネス分析があり、ユースケースから詳細設計を駆動する為に存在しています。逆に言えば、実はロバストネス分析を実践的に使うための方法がICONIXとも言えます。ロバストネス分析はICONIXプロセス全体を通して重要な意味を持っており、ロバストネス分析といえばICONIXとも言えるわけです。

ICONIXプロセスは、小〜中規模の画面を介するソフトウェア（Webアプリなど）の開発に適したプロセスで、概要設計後の基本設計から要求テストまでの広い範囲を必要最低限のステップで実践的に行うものとされています。実践的なプロセスなので、具体的にこれを行ってからこれを行うといった手順が明確であり、ウォーターフォール的な現場であってもフェイズ毎の目的を説明することで理解されやすいのでしょう。ただし、各フェイズで完全に完結してから次のフェイズに進むわけでなく、おおよそ８割程度を完成させたならば次のフェイズに進み、前のフェイズの成果物をさらに進化させるという段階的な設計を前提としていることは（巷で行われている）ウォーターフォールとの違いになります。

具体的には、ICONIXプロセスは次のようなフェイズで進められます。

最初に行われるのがドメインモデリングであり、ここではソフトウェアが扱う問題領域に関して本当にざっくりと分析します。あまり時間をかけずにこれから作成するユースケースを作るための準備フェイズです。成果物はドメインモデル図でこれは最終的にはクラス図のベースとなるものです。
次に行われるのはユースケースモデリングです。ここではソフトウェアの振る舞いに着目し、ユーザとシステムがどのように対話することでシステムが構築されるのかを固めていきます。ここでの成果物はユースケース記述とユースケース図です。これらはソフトウェアの動的な設計の基礎となり、最終的にはシーケンス図へと落とし込まれていきます。
次に行われるのはロバストネス分析です。ロバストネス分析は概要設計と詳細設計のギャップを埋めるためにある為、ある意味で概要設計であり、ある意味で詳細設計です。ロバストネス分析を行うことで、ユースケースの矛盾が取り除かれます。この時点でおおよそのクラスがバウンダリとエンティティとして、操作（メソッド）はコントローラーとして抽出されます。これはまさに詳細設計の一部でしょう。
詳細設計に入るとシーケンス図とクラス図を作成していきます。シーケンス図はロバストネス図からある程度は機械的に出力できます。なぜならば、ロバストネス分析でシーケンス図が導けるように調整を行っているからです。後は適用したアーキテクチャの都合を考慮しながら実際に作成するクラスに責務を割り当てていきます。あわせて必要なフィールドなどがエンティティに定義されていき、詳細設計が行われます。
残るはコーディングとテストですが、単体テストはロバストネス図のコントローラー単位で行われ、要求テストはユースケース単位で行われます。したがって確実にプロセスを踏んでいる場合、機械的にほとんどのテスト項目が導き出せるわけです。コーディングもほとんどの部分を自動生成できるレベルまで設計されているはずです。

このようにICONIXプロセスでは設計、特に予備設計にしっかりとした時間と手間をかける事で後半の作業負担を軽くしている特長があります。これらのプロセスを解説したのが下記書籍です。興味のある方は勉強会に参加して一緒に学びませんか？

ユースケース駆動開発実践ガイド (OOP Foundations)