勉強日記

チラ裏

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

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

www.apress.com

ICONIX Process in Theory (つづき)

Detailed Design

  • 「システムを正しく作る」
    • 「正しいシステムを作る」はここまでに済んでいるはず
  • ここにおける関心事: 非機能要件(効率等)
    • 実行時間
    • ネットワーク負荷
    • メモリ使用量
    • コードの再利用性

Sequence Diagramming (Allocate Behavior to Classes)

  • 「システムを正しく作ること」の関心の大部分は、ふるまいを各クラスに最適に割り当てること
  • この真髄は、シーケンス図上でメッセージの矢印を引くこと
    • モデリングツールによって、メッセージ受信側クラスに自動的に操作(ふるまい)をアサインできたりする
  • シーケンス図作成の10のガイドライン
    1. なぜシーケンス図を描くのか理解することで最大限にその力を発揮する
    2. 全ユースケースに対してシーケンス図を描く
      • 基本コース、だいたいコース両方を同一の図に描く
    3. バウンダリクラス、エンティティクラス、アクター、ユースケースからシーケンス図を起こす
    4. シーケンス図を使って、ユースケースの振る舞い(=ロバストネス図のコントローラー)が、オブジェクトによりどのように実現されるか示す
    5. ユースケース記述がシーケンス図のメッセージパッシングと一致すること
    6. シーケンス図の活性区間の描き方にこだわって時間をかけすぎない
      • 【補】ライフラインに沿った縦長の長方形のこと。「実行指定」(execution specification)とも
    7. メッセージの矢印を描く中でクラスに操作(ふるまい)をアサインする
      • ほとんどのビジュアルモデリングツールがサポートしている機能
    8. 操作をアサインしながら、まめにクラス図を見直す
      • すべての操作が適切なクラスにアサインされていること
    9. コーディングの前に、シーケンス図に設計をあらかじめ織り込んでおく
    10. CDR: Critidal Design Reviewの前に静的なモデルをきれいにしておく
  • この時点で、ほぼコーディングの準備は万端
  • あとはCDR: Critidal Design Reviewのみ
  • が、ここで静的なモデルを再訪し、きれいにしておくと、あとで得をする

Cleaning Up the Static Model

  • 時間をかけて入念に設計を整理整頓する
  • CDRまでには行う必要あり
  • シーケンス図を書く前に考えておくこともできる

Milestone 3: Critical Design Review

  • 3つの重要な目的
    • 詳細設計の「どう作る」が、要件の「何を作る」とマッチしていることの保証
    • 設計の質のレビュー
    • シーケンス図上のメッセージの連続性をチェックする
      • ロジックの隔たりがないか
        • あれば、ならす
  • CDRの10のガイドライン
    1. シーケンス図がユースケース記述と一致すること
    2. 繰り返すが、各シーケンス図がユースケースの基本コースと代替コースの両方を説明していること
    3. 操作がクラスに適切に割り当てられていること
    4. クラス図上の各クラスは適切な属性と操作を持っていること
    5. デザインパターン等を適用する場合、その詳細がシーケンス図上に反映されていること
    6. 機能(・非機能)要件がユースケース、クラスによりカバーされていること
    7. プログラマによる、設計の「サニティ・チェック」
      • 実際に作れるか
      • 意図通りに動作するか
    8. 全ての属性、操作の引数・戻り値の型が正しいこと
    9. コードのヘッダを生成し、入念に検査する
    10. リリースに向けてのテスト計画をレビューする
  • ここにおいて設計は戦闘準備完了、すぐにコーディングに取り掛かれる

Implementation

  • 実装
    • コーディング
    • テスト
  • ユースケースからUMLモデルを起こし、せっかく詳細設計したのに、それを完全無視して実装するのは正気の沙汰ではない
  • テストも同様
    • UMLモデルから起こせるし、そうすべき
    • 著者ら使用のツールでは自動生成できる

Implementation (Coding)

  • 10のガイドライン
    1. 設計から直接コードを起こす
    2. コーディングの中で設計の誤りに気づいたら、設計を変更する
      • プロセスも見直す
    3. 定期的にコード検査
    4. つねにフレームワークの設計選択に疑問を投げかける
    5. フレームワークにビジネスの問題を引き取らせない
    6. コードが手に負えなくなったら、立ち止まって設計を再訪する
    7. 設計とコードとの同期を保つ
    8. コーディング中は単体テストに注力する
    9. コードコメントを書きすぎない
      • 保守性が下がる
      • 可読性が下がる
      • 【補】コメントについてはA Philosphy of Software Designがとても勉強になりました
    10. 代替フローの実装を忘れずに

Unit Testing

  • 実装において単体テストは重要かつ不可欠
  • 各ユースケースで記述されるシステムの振る舞いを正しく実装できていることの証明
    • 自動
    • 再現性がある
  • 基本的に、ロバストネス分析で洗い出した全てのソフトウェア機能をテストすることになる
  • テストの10のガイドライン
    1. 「テストの思考」を取り入れよ
      • テストで不具合が見つかるのは敗北ではなく勝利である
        • エンドユーザに迷惑をかけない
    2. 異なる種類のテストを理解し、いつ・なぜそれを利用するのか理解する
    3. ロバストネス分析結果の各コントローラに対して1つ以上のテストを書く
    4. リアルタイムシステムでは、状態マシン図に基づいてテストケースを作る
    5. 要件レベルで検証せよ
    6. 要件レベルの検証を支援するためにトレーサビリティマトリックスを使う
    7. 各ユースケースにはシナリオレベルの受け入れテストを行う
    8. シナリオレベルのテストは基本コースに加え代替コースもカバーするように
    9. テストフレームワークを利用し、テストケースを蓄積・構成する
    10. 単体テストはきめ細かく保つ
  • プロジェクトの別のフェーズでは別の成果物に対して別のテストを行うもの

Expand Threads for Integration and Scenrio Testing

  • 晴れの日シナリオだけでなく雨の日シナリオもテストする
  • 例えば代替コースが3つあれば、テストは最低4つ必要
    • 晴れの日シナリオ 1つ
    • 晴れの日シナリオの一部 + 雨の日シナリオ 3つ

Code Reivew and Model Update

  • 次のイテレーションが始まる前に、コードとモデルとの同期をとる
  • コードの腐敗を防ぐ
    • 複雑なシステムに次々と機能が追加されるとおこる
  • コードレビューとモデル更新の10のガイドライン
    1. 資料を用意し、レビュアーには事前に読んでおいてもらう
    2. ユースケースに基づいた、高いレベルから俯瞰したレビュー対象リストを作る
    3. 必要ならばレビュー項目を小さなチェックリストに細分化する
    4. いくつかの異なるレベルからコードをレビューする
    5. レビュー中にデータを集め、将来のレビューのためのチェックリストを作る
      • 【補】毎度指摘されるようなことをチェックリスト化するということ
        • 時短
        • 抜け漏れの予防
    6. フォローアップする
      • 関わった全員にアクションアイテムをEメールで送る
    7. レビュー中は誤りの修正ではなく検出につとめる
      • 【補】軽微な修正でなければ別途時間をとる
    8. 統合コード/モデルブラウザを利用する
    9. チェックリストやフォローアップは形式ばりすぎない
    10. コードレビューだけではなくモデル更新の会でもあることを忘れない

Extensions to ICONIX Process

Persona Analysis

  • アクターやユースケースは抽象的すぎるとの声多数
  • personaは、より具体的でステークホルダーに理解しやすくした、典型的なユーザ像
  • もたせる情報
    • 名前
    • 仕事の簡潔な説明
    • 目標・野望
    • 能力水準
    • あなたが設計している製品にまつわるあらゆること
      • 製品をどう利用するか
      • 製品をどう思っているか
  • interaction scenarios
    • ユースケース記述の一種
    • personaがシステムを利用するモチベーション等も詳細に記述する
    • 対象ユーザーにシステムが正しくフォーカスできていることを確認する
  • ICONIXスタイルのミニマルなユースケース記述も併用する

Test-Driven Development (TDD)

  • テストを書いてソフトウェアを設計する手法
  • TDDの前に設計モデリングをしておくと大きな効果がある

Driving Test Cases from the Analysis Model

ICONIX Process in Practice: The Internet Bookstore Example

  • 次章以降、インターネット書籍店の例でモデリングを進める

英語

  • memory footpring
    • プログラムが実行中に使用または参照するメインメモリの合計量
  • pay dividends
    • 配当を支払う、(将来)利益を生む
  • tidy up
    • (もの・場所)を整理する
  • prefactor
    • あらかじめfactorする、の意か
  • factor in
    • 因数に分解する
    • 考慮に入れる、織り込む
  • iron out
    • 平らにならす