[https://www.apress.com/gp/book/9781590597743:embed:cite]

Introduction to ICONIX Process

あるプロセスは、ある者には大きすぎ、またある者には小さすぎて適さない
そしてOMGの提供するUML全仕様は、誰にも理解できない

【補】OMGのUMLへのdisり

• UMLの各側面は潜在的に有用

• だが実践上、モデリング、分析、設計に十分な時間がさかれることはない

  • ソフトウェアプロジェクトの進捗はコード量で計られがちなので、プレッシャーがかかる

• ICONIXは最小限で合理化されたプロセス

  • ユースケースからソースコードを起こすまでの間に着目

  • ライフサイクルのどの時点でなにが為される必要があるかを強調する

    • 例: ユースケースに着手開始したなら、よい分析と設計をする必要がある

WHEN TO USE A COOKBOOK

• ソフトウェア開発において「レシピ本」アプローチはうまくいかないという誤解

• ある程度は同意

  • 分析とプログラミングは、大規模で高度に複雑な分野だから
  • 同じプロジェクトはないから

• しかし、ソフトウェア設計は再現可能なステップの積み重ねであるべき

  • 変えられない厳格なものではなく、適宜調整可能なもの
  • ICONIXプロセスはこれに近いもの

• ICONIXは単純で最小限のステップを定め、概して良い結果をもたらす

  • まだ柔軟性の余地はある

    • ステートマシン図やアクティビティ図の追加等
  • 12年にわたる実績がある

ICONIX Process in Theory

• 本章ではICONIX Processを俯瞰する

  • 各活動がいかに噛み合うか

Overview: Getting from Use Cases to Source Code

• ICONIXプロセスは動的/静的なワークフローを含む

• とても反復的

  • 一度のイテレーションで数段落のユースケース数個程度を一度に扱う
  • コーディングして単体テストするまで

• ゆえにアジャイルとよくマッチする

  • 要件分析、設計、見積もりで素早いフィードバックが必要

• 要件定義フェーズの各活動はある程度並列性がある

  • 重なっていたり織り交ざったり

Requirements

• 振る舞いの要件(behavioral requirements)の定義

  • 最初のドメインモデルの作成
  • ユースケースの最初の草稿の作成

Functional Requirements (What Will the System Be Capable Of?)

• やりがち: 機能要件どまり

  • アナリストは顧客、エンドユーザ、様々なステークホルダと話し、機能要件を巨大なOfficeドキュメントいっぱいにまとめる
  • が、構造化されていないため、設計や正確な見積もりを出すことができない

• 真に必要なのは、機能要件から、振る舞いの要件=ユースケースを起こすこと

  • ここにおいて、「事前設計」(preliminary design)を行えるようになる

• ICONIXプロセスの要件定義の10のガイドライン

  1. 要件とユースケースとを紐付けて追跡できるモデリングツールを使用する

     • 【補】Enterprise Architectとか
  2. 要件をユースケースにドラッグドロップで紐付ける

  3. 機能要件と振る舞いの仕様とを分けて考え、機能不全要件を避ける

     • 【補】ユースケースを書けない事態を避けよ、ということかな
  4. 各要件につき少なくとも1テストケースを
  5. 要件をモデリングにおける第一級市民として扱う
  6. 異なる種類の要件を区別する
  7. 「巨大な一枚岩ドキュメント」症候群を避ける
  8. 機能要件ではなくユースケースから見積もりを作成する
  9. 機能要件を書くときには、ためらわず実例をあげる
  10. 要件を技術的な様式で記述しない

Domain Modeling

• プロジェクトの共通語彙集を作る作業

  • 【補】DDDにおけるユビキタス言語みたいな思想

• 役割

  • 問題領域の理解におけるあいまいさの回避
  • ユースケースのスコープを定義し、基礎を形作る
  • メンバー間での明確なコミュニケーションのため

• 最初から正しいものにはならない

  • ユースケースを書いているうちに正しく育っていく

• ドメインモデリングの10のガイドライン

  1. 実世界(問題領域)のオブジェクトに着目する
  2. is-a, has-a関係でオブジェクトの関連を示す
  3. 最初のドメインモデリングは数時間にとどめる
  4. 問題領域の主要な抽象化に関してクラス群をまとめる
  5. ドメインモデルをデータモデルと勘違いしない
  6. オブジェクト(個々の物)をDBのテーブル(物の集合)と混同しない
  7. ドメインモデルをプロジェクトの語彙として使用する
  8. ユースケースを書く前に最初のドメインモデリングを行う。名前のあいまいさ回避のため

  9. 最終的な実装クラス図はドメインモデルと正確には一致しない

     • ある程度の相似性が認められるべきではある
  10. 画面表示やGUI特化クラスをドメインモデルに含めない

Behavioral Requirements (How Will the User and the System Interact?)

• ICONIXはシナリオベースのアプローチ
• 最終目的はオブジェクト指向設計に落とし込みコードを書くこと
• したがって、シナリオをオブジェクトに紐付ける必要がある
• ドメインモデルの語彙でユースケースを記述することでこれを実現する

Storyboarding the GUI

• 振る舞い要件は、ユーザのアクションと、それに対するシステムの返答とを詳細に記述する
• ユーザとシステムとのやりとりは、画面、ウィンドウ、ページ等を介して行われる

• システム利用シナリオは物語調で記述する

  • 顧客やエンドユーザと会話して詳細に引き出す

• 脳内でシステム像を描くのは困難なので、何か絵があると良い

  • なんでもいい

    • 紙に書いた線画
    • パワポのスライドショー
    • HTMLのプロトタイプ

• ボタンやメニュー等のUIを含めることが重要

  • ないと代替フローを漏らしがち

    • 例: 「ユーザがキャンセルボタンを押したら」

Use Case Modeling

• ユーザとシステムのとのやりとりを記述

• 10のガイドライン

  1. 2段落ルールに従う
  2. ユースケースを、アクターとユースケース図とでまとめる
  3. 能動態で書く
  4. イベント/応答フローで書く、ユーザとシステムの対話の両面について記述する
  5. GUIストーリーボード、プロトタイプ、画面モック等を使用する
  6. ユースケースは実行時の振る舞いの仕様であることを心に留める

  7. オブジェクトモデルの文脈でユースケースを記述する

     • 【補】そうしないと、結局オブジェクト指向設計に落とし込めないよね、ということか
  8. 名詞-動詞-名詞の構造で書く
  9. ドメインクラスを名前で参照する
  10. バウンダリクラス(画面等)をを名前で参照する

Miletone 1: Requirements Review

• 要件の理解が十分であることの確認

  • 開発者
  • 顧客/ユーザ/ステークホルダ

• 10のガイドライン

  1. ドメインモデルが重要な抽象化(現実世界のオブジェクト)のうち少なくとも80%を、エンドユーザにもわかる言葉で記述していること

     • 技術的でない言葉
  2. ドメインモデルが、ドメインオブジェクトのis-a, has-a関連で示されていること
  3. 基本フローと代替フロー両方が、能動態で書かれていること
  4. 機能要件(「できる」スタイルの文章)は、能動態で書かれたユースケースではない
  5. ユースケースをパッケージにまとめる。各パッケージが少なくとも1つのユースケースを含むこと
  6. オブジェクトモデルの文脈でユースケースが記述されていること
  7. ユースケースをユーザインタフェースの文脈に置く
  8. ユースケース記述に、ストーリーボード、線画、画面モック、GUIプロトタイプ等を添える
  9. ユースケース、ドメインモデル、画面モック/GUIプロトタイプを、ユーザ、ステークホルダー、営業部門交えてレビューする
  10. ch.4 「よりよいユースケースのための8つのステップ」にしたがってレビューを行う

Analysis/Preliminary Design

• 分析は正しいシステムをつくることに関する
• 設計はシステムを正しくつくることに関する
• 「事前設計」はこの中間

ある程度、予備的に設計してみないことには、要件を完全に理解することはできない

• ロバストネス分析

  • 要件理解のために行う事前設計

    • 要件のあいまいさを排除する
  • 振る舞い要件(ユースケースシナリオ)とオブジェクト(ドメインモデル)とを紐付ける

Robustness Analysis

• 分析と設計との間の溝の橋渡し

  • ユースケース記述を分析し、関連するオブジェクトを洗い出す

• 10のガイドライン

  1. ロバストネス図にユースケース記述を貼り付ける
  2. ドメインモデルからエンティティクラスを持ってくる。なければ追加する
  3. ロバストネス図を書く中で、ユースケースの曖昧な部分を書き直す
  4. 各画面のバウンダリオブジェクトを作り、各画面に曖昧でない名前をつける

  5. コントローラーが実際のオブジェクトであることはめったにない

     • 大抵は論理的なソフトウェア上の機能
  6. ロバストネスの矢印の向きは気にしない
  7. 親ユースケースから子ユースケースを呼び出すのはアリ

  8. ロバストネス図は詳細設計ではない

     • ユースケースの概念の事前設計

  9. シーケンス図との関連

     • バウンダリオブジェクトとエンティティオブジェクトはシーケンス図上のオブジェクト
     • コントローラはメッセージ

  10. ロバストネス図はユースケースを「オブジェクトで書いた絵」

      • その目的は、ユースケース記述とオブジェクトモデル両方を洗練すること

• ロバストネス分析を終えた時点で

  • ユースケースの曖昧さは完全に排除される

  • ユースケースはドメインモデルの文脈で記述される

    • 名前のゆれ等がない

    • ドメインモデルの各クラスは属性をもつようになる

      • 操作はまだもたない
• 理論上はもう詳細設計にかかれるが、実践上は、ここで手短なPDR: Preliminary Design Reviewを挟むととても有用

Milestone 2: Preliminary Design Review

• ロバストネス図、ドメインモデル、ユースケース記述が一致していることの検証
• 詳細設計にかかる前の「関門」

• 10のガイドライン

  1. 蛍光ペンでユースケース記述に線を引いて、ロバストネスネス図との一致を確認する
  2. ロバストネス図上の全エンティティがドメインモデルに含まれていること
  3. エンティティクラスと画面との間でデータフローをなぞれること
  4. 代替フローを忘れない。見つけ次第、忘れずに書く
  5. 各ユースケースが、ユーザとシステムとの対話の両面をカバーしていること
  6. ロバストネス図の文法を守る
  7. 非技術者(顧客、営業チーム等)、技術者(プログラマ)両方交えてレビューする
  8. ユースケースはオブジェクトモデルとGUIの文脈で書かれていること

  9. まだ詳細設計をするな

     • シーケンス図と同じ詳細度にならぬよう
  10. ch.6の、事前設計のための「6つの簡単なステップ」に従う

• PDRを終えた時点で

  • 図とユースケース記述とが一致しているという確信が得られる
  • 両者は完全で、システムに要求される振る舞いを正しく表現している
• 次は、比較的素直な詳細設計に続く

英語

• incomprehensible

  • 理解しがたい

• streamlined

  • 流線型の
  • 能率化・スリム化・合理化された

• codify

  • (法律などを)成文化する

• set in stone

  • 石に刻まれている
  • もはや変えられない

• slick

  • 洗練されている

    • 章サブタイトルに一致する部分を赤文字で印刷していることに対して言っている

• preliminary

  • 予備の

• to the brim

  • なみなみと

• closer to the metal

  • 真実に近い、くらいの意味？

• dysfunctional requirements

  • 機能を果たしていない要件