北欧勉強会第7回
北欧勉強会も第7回。でもまだまだオブ脳話にはなかなかならず。個人的にはユースケース記述もろくに使ったことがないので、そのあたりの話を読めたのは結構収穫。特にすべての関係者に通じる言語がないから、いろんな設計書が必要というあたりは自分になかった視点だな。その視点も大切だけれど、自分だったらすべての関係者に通じる言語を関係者で探ってく解決を取りそうだw。そういう巻き込み型の運営がきっとみんなをいい方向に変えていく気がする。(なかなかそうも行きませんが。)
以下検索用
北欧勉強会第7回
一言
2007/12/4
5分前集合はむずい
いつもより人がいない
さみしすぎる
ロールと責務ってなにが違うの
クラス図のあれ?
1.4を復習しよう
鬼軍曹
2.2 台本を書く:分析の記述
仕様に関する間違い
最も高コスト
言語(言葉)
すべての関係者に共通する言語は存在しない
共通語彙を発展させ、利用
2.2.1 使用法の記述
ユーザーの立場
ソフトウェア→自分のタスクをサポート
ユースケース
アクター
ユーザー
管理者
外部のプログラム・デバイス
アプリケーションの外部に存在
主導権を握り、SWに対して刺激し、相互作用する
形式
散文
シナリオ
会話
ユーザーとシステムの対話
文の中にユーザーとシステムが埋もれる
2-6がいい感じ
読み手ごとに異なる詳しさ
仕様が簡単だと使えるよね
図じゃない
詳細なユースケース
テストケースでどう?
詳細すぎることに
レビューで削る
レビューだと追加したくなる人情
ポリシー
ビジネスポリシー
アプリケーションポリシー
例:ワードプロセッサー
順序の入れ替え可能な小さなユースケース
何かに対してあるアクションを行う
散文形式→シナリオ→対話
新たな情報
その都度文書化
「分析」「設計」など区切らない
設計メモ
副筋
コバーンの本読んどけば?
海面
WhatとHowを切り替えることで詳細化
この本だけでユースケースはかけないよね
議事録はユースケースになる?
ユーザーストーリー
誰向け
2.2.2 その他の仕様書
設計上の考慮点を記述
画面レイアウト
ウィンドウ仕様
既存の規約
設計者にとって価値がなくても他の利が関係者に価値がある
ヘルプ(マニュアル)も?
2.2.3 用語集
中心部に集中する
ドメインオブジェクト・概念・プロセス
複雑なアルゴリズムを実装したオブジェクト
技術的なインフラ
アプリケーションが行うことを管理するオブジェクト
独自UI
Wikiに用意しておくだけで違う
あればみんな書いていく
OO用語集があるといいね
2.2.4 概念オブジェクト
対象ドメインの中心的な概念
利害関係者間の理解
2.3 登場人物の配役:探求的設計
オブジェクト候補を探り出す例
パーサーなんてどこから出てくるの?
単語を抽出する責務
名前づけ
2.3.1 CRCカード
アイデア
オブジェクト候補
ロール候補
候補の予備的なアイデア
Candidatre(候補)
Responsibirity(責務)
Collaboration(コラボレーション)
直感的に思い浮かばないオブジェクト
最初に出てきづらい
設計者の想像力重要
2.3.2 パターンを使用して考え出す
パターンを知っておく
自分の考えの至らなさを補う
CRCカードに責務を書いていく
2.3.3 解決策を追う
この戦略はよさそうなので、引用
1.決まった考えが何もないなら、うまくいきそうな解決策を作る
2.解決策の限界と強みを探求。リスクを回避するために代替案を必ず1つは用意し、比較する
3.設計の一貫性を助長する解決策を優遇
4.1つの解決策をあらゆるところで使おうとしない
5.基地のデザインパターンにあわせた解決策を考え出す
6.実績のある設計アイデアやアーきタイプを借りて適用する
7.うまくいかなかった場合は進んで初期の決定を修正する。
8.時間がない場合は深追いしない。抽象化や賢さは強引に生み出せない
2.3.4 アイデアと詳細の間を行き来する
継続的に設計を詳細にテスト
責務を分割
2.4 制作をチューニングする:設計の洗練
