レビュー

●レビュー「概要の文章化」
  • 主語が明確にしてあるか
  • システムの機能の説明が全て書けているか
  • キーワードは統一されているか
    ⇒統一されていなかったので書き直し
  • ユースケースの目的を数行で記述できているか


●レビュー「ユースケース」
  • ユースケースの数は妥当であるか
  • ユースケースに独立性はあるか(機能分割になっていないか)
  • アクターとユースケースを続けて読んでみて、日本語として意味が通っているか
  • アクターから見てユースケース名が疑問に思うサービス名になっていないか
    ⇒科目→過去問情報、過去問→問題、科目ナンバー→過去問情報ナンバーに変更
  • ユースケース名にシステム的な“手段”が入り込んでいないか
  • アクターが抽象的すぎていないか
    ⇒学生→利用者に変更
  • ユースケースは単独で動作するか


●レビュー「イベントフロー」
  • 事前条件、メインフロー、例外フロー(該当する場合)がすべて記載されているか
(日と坪)「元に戻す」ユースケースに例外のもれがある(履歴が1つしかない場合)→例外フローとして追加
  • メインフローに分岐がある場合、全ての分岐に対してフローがあるか
  • 例外フローの戻り点がすべて記載されているか
  • 記述のあいまい性は形式的に排除できているか
 (全員)主語がない文がある→適切な主語をつける
  • 「など」、「他」などの表現を記述していないか
  • 1つの文で2つ以上のことを述べていないか
 (日)利用者とシステムの行為が1文に→2文に分けた
  • 第三者が読んでも1通りにしか解釈できないような状態であるか
 (日)「その問題の」はどの問題か?→「過去問情報に対応した問題」へ
  • 未決定事項、仮決定事項を明文化しているか
  • メインフロー、例外フロー共に設計要素が入っていないか
 (全員)「戻る」や「中止」は設計要素なので書かない
 (坪)「メニュー」は設計要素→削除
 (宇)「画面下にある」「新規画面を開く」は設計要素→削除


●レビュー「シナリオ」
  • ユースケースを使用した具体的な例になっているか
  • 例外が起きた場合のシナリオを書いているか
 (日と坪)「元に戻す」ユースケースの例外もれで追加された例外のシナリオを追加
  • 第三者が見て分かりやすい内容になっているか
 (全員)主語がない文がある→適切な主語をつける

【分析】

●レビュー「シーケンス図」
  • ユースケースとシーケンス図の数が等しいか
  • オブジェクトに独立性があるか
  • 情報の引渡ししか行っていないオブジェクトがないか
  • シーケンス図に設計要素を入れていないか

(成瀬)過去問情報の検索場所が無い→過去問情報集を作成して情報の比較をさせる
(日隈)問題の削除の流れを変更→白紙の問題を追加していく方式へ
(坪井)「元に戻す」の内容を見るオブジェクトの場所を変更
(宇津巻)画面を表示するメッセージが存在→設計要素なので排除


●レビュー「クラス図」
  • 存在意義のあるクラスになっているか
  • クラス名が名詞または形容詞+名詞で、単数形であるか
  • 「クラス名」+の+「属性名」と読んでみて、日本語として自然であるか
  • 集約と関連の使い分けが出来ているか
  • 多重度は適切であるか
  • 属性・操作に型や可視性を定義していないか
  • 巨大なクラスが1つあり、すべてのクラスが関連していないか
  • クラス図での関係線は交差していないか
  • どのクラスとも関係付けされていないクラスは存在しないか


●レビュー「整合性」
  • シーケンス図のメッセージとクラス図の操作がすべて対応付けされているか
  • 操作をメッセージの受け取る側に定義しているか
  • シーケンス図でメッセージがやりとりされているオブジェクト間と、クラス図のクラス間の関連は一致しているか


【設計】

●レビュー「シーケンス図」
  • 設計すべきシーケンス図は欠けていないか
  • メッセージに引数、引数の型、戻り値の型は定義しているか
  • オブジェクトに自立性を持たせているか
  • 自分の内部でしか使用しないオペレーションを切り分けているか
  • シーケンス図の記述レベルは、第三者がオペレーションを順番に読んでいって何をしているのかわかる状態になっているか

(成瀬)処理後の画面の表示メッセージの追加・例外の修正
(宇津巻)画面への入力に引数を入れていない→引数の追加
     表記の変更→「過去問情報」へのcreateメッセージの追加
(坪井)「更新日時を設定」メッセージでどう更新日時を設定するか分からない→「更新日時を設定」メッセージ内に「現在の日時を取得」メッセージを追加
(日隈)「問題」クラスが誤解される恐れ→「問題」オブジェクトを追加


●レビュー「クラス図」
  • 分析クラスを分割しているか
  • 型や可視性を明確にしているか
  • パブリックなオペレーション(操作)の数が3~9になっているか
  • 作らなくてもよいクラス(画面設計など)を排除しているか
  • 「BはAの一種である」と読んでみて、継承関係は妥当か
  • 引数は可能な限りオブジェクト渡しになっているか
  • 属性とオペレーションは分かりやすい名前になっているか

タグ:

+ タグ編集
  • タグ:

このサイトはreCAPTCHAによって保護されており、Googleの プライバシーポリシー利用規約 が適用されます。

最終更新:2007年11月10日 09:33