勉強日記

チラ裏

Use Case Driven Object Modeling with UMLTheory and Practice ch1. Introduction to ICONIX Process (1/2)

ユースケース駆動モデリング 勉強メモ

www.apress.com

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

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

  • やりがち: 機能要件どまり
    • アナリストは顧客、エンドユーザ、様々なステークホルダと話し、機能要件を巨大なOfficeドキュメントいっぱいにまとめる
    • が、構造化されていないため、設計や正確な見積もりを出すことができない
  • 真に必要なのは、機能要件から、振る舞いの要件=ユースケースを起こすこと
    • ここにおいて、「事前設計」(preliminary design)を行えるようになる
  • ICONIXプロセスの要件定義の10のガイドライン
    1. 要件とユースケースとを紐付けて追跡できるモデリングツールを使用する
    2. 要件をユースケースにドラッグドロップで紐付ける
    3. 機能要件と振る舞いの仕様とを分けて考え、機能不全要件を避ける
    4. 各要件につき少なくとも1テストケースを
    5. 要件をモデリングにおける第一級市民として扱う
    6. 異なる種類の要件を区別する
    7. 「巨大な一枚岩ドキュメント」症候群を避ける
    8. 機能要件ではなくユースケースから見積もりを作成する
    9. 機能要件を書くときには、ためらわず実例をあげる
    10. 要件を技術的な様式で記述しない

Domain Modeling

  • プロジェクトの共通語彙集を作る作業
  • 役割
    • 問題領域の理解におけるあいまいさの回避
    • ユースケースのスコープを定義し、基礎を形作る
    • メンバー間での明確なコミュニケーションのため
  • 最初から正しいものにはならない
  • ドメインモデリングの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?)

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

Analysis/Preliminary Design

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

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

Robustness Analysis

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
    • 機能を果たしていない要件