初めに
本記事は木更津高専アドベントカレンダー22日目となっております
自己紹介
ぼくは木更津高専情報工学科3年でC-Style株式会社でCTOをやらせていただいております。
前日の帰宅中に急いで書いた記事であるため、誤植など多いと思いますが温かい目で見守りください
ICONIX Processとは
ICONIX（アイコニクス） は、ラショナル統一プロセス（RUP）、エクストリーム・プログラミング（XP）、及びアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論である。RUPと同様にICONIXプロセスはUMLのユースケース駆動であるが、RUPより軽量である。XPやアジャイルのアプローチとは異なり、ICONIXは十分な要求と設計のドキュメントを作成するが、分析麻痺にはならないようにする。ICONIXプロセスは、4ステップのプロセスでただ4つのUML図を使用して、ユースケース記述を動作するコードに変換する。 1
?????
難しい言葉を並べても全然わかりませんね。。
もう少し柔らかくして説明すると
ユースケース駆動開発実践ガイドという本にて紹介されている、開発手法で要件定義から詳細設計を行う際にロバストネス分析という分析手法を用いて行い設計をしやすくした手法のことです。
メジャーな開発手法だとウォーターフォールに近く、要件定義->設計->実装->テストという流れは同じです。
ロバストネス分析
先ほど紹介したロバストネス分析について深掘りしていきましょう
ロバストネス分析とは、要件定義にてユースケースごとにシステムの要件を決めそれを軸に、オブジェクトを用いた図、ロバストネス図を作成する作業です。 ロバストネス分析を行うことによって、ユースケースを記述した文章からクラス図やシーケンス図といったUML静的モデルが作りやすくなります。
これをすることによってユースケースの曖昧さがなくなります。なぜかというとロバストネス図を作る際にユースケースを再度見直すことによって、表記揺れや要件の穴などに気づくことができるためです。
また、ロバストネス図を制作することによって、詳細設計を楽に行うことができ、もしロバストネス図がうまく作れない場合は要件定義に不備があることがほとんどなので、その出戻りの手間も省くことができます。
現場のエンジニアと要件定義者によって作られるため、現場の意見を要件定義レベルで反映させることができます。
ロバストネス図の作り方
ロバストネス図では以下の4つのオブジェクトを使って、表現していきます。
アクター
システムとの相互作用において一定の役割を果たす人、組織、外部システムのことで、線で描かれた人型によって表現される。
バウンダリオブジェクト
アクターが相互作用する画面やレポート、HTMLページ、システムインターフェースなどのソフトウェア要素を表す。
エンティティオブジェクト
システム内の情報であり、属性や振る舞いを保持するものを意味する。一般的には、データベースを用いて永続化されることが多い。
あらかじめ設計されたドメインモデル図に登場する各ドメインは、これらのエンティティに対応する必要がある。
どのドメインにも対応しないエンティティは、ドメインモデル図に追加して修正する必要がある。
図間の整合性は、互いを記述し、整合性によって互いを洗練させるための枠組みである。
コントローラ
境界と実体をつなぐ役割を果たし、様々な要素との相互作用を管理するためのロジックを実装する。
プロセスとも呼ばれる。
ユースケースで表現されたシステムとしての機能を提供する。
実際に作成した図はこちら
2
この場合
アクター
- オペレーター
バウンダリオブジェクト
- ログイン画面
- メニュー画面
エンティティオブジェクト
- 社員情報
コントローラ
- 社員情報登録検証
となる
ロバストネス図を書くにあたっては、以下のルールを遵守する必要があります。
- アクターはバウンダリのみ関連線（矢印）が引ける
- バウンダリはコントロールとアクターのみ関連線が引ける
- エンティティはコントローラのみ関連線が引ける
- コントロールはコントローラ同士とバウンダリのみ関連線が引ける
- アクターがコントローラに関連線を引いたり、バウンダリがエンティティに関連線を引いたりすることはできません
見てわかる通り、ロバストネス図は大雑把な設計になっている
しかしロバストネス図はあくまでもロバストネス分析で用いられる図であるため、このまま設計を終わらせてはならない
ワークフロー
ICONIX Processは主に4つのマイルストーンにわけて行われる
1 要求レビュー
ICONIXのプロセスを開始する前に、要求分析が行われている必要があります。この分析から、ユースケースが特定され、ドメインモデルが生成され、いくつかのプロトタイプGUI(ワイヤー)が作成されることができます。
2 予備設計レビュー
ユースケースが特定できれば、ユーザーとシステムがどのように相互作用するかをテキストで記述することができる。ユースケースの記述に潜在するエラーを検出するためにロバストネス分析を行い、それに応じてドメインモデルを更新する。ユースケース記述は、ユーザーが意図したシステムとどのように相互作用するかを特定するために重要である。また、ユースケース記述によって、開発者は顧客がどのような人なのか、要求分析の結果が正しかったのかどうかを検証することができる。
3 詳細設計レビュー
ICONIXのこのフェーズでは、予備設計で作成したドメインモデルとユースケース記述を使って、構築中のシステムを設計します。ドメインモデルからクラス図を作成し、ユースケース記述からシーケンス図を作成する。
4 実装
システムがユースケース記述とシーケンス図に合致することを検証する、ユニットテストを記述する。最後に、クラス図とシーケンス図を手引きとしてコードを記述する。
利点
なぜICONIX Processを使うのか。その利点について考える
進めやすい
単純にこれにつきます。
機械的に要件定義から設計まで行うことができるので、円滑にプロジェクトを進めることができます
見積もりが立てやすい
ユースケースが個別に明文化されることでユースケースごとに時間の見積もりをエンジニアが立てることができ、その正確さも補償されます。
ドメインモデルを育てることができる
ロバストネス分析を行うことで要件定義を見直し、修正していくことができるためドメインモデルを理論的にも文章てきにも育てることができます
終わりに
雑に書いたのでかなり誤植や主観など混じっているかもしれません。
コメントどしどし待っております
では良いクリスマスを！