「自然言語で仕様はきっちりと語ることができる。」
語れないのは、その言葉の使い方を間違えているのだと。
まずは、日本語の勉強をしなければいけない。
言語があいまいなのではなく、人が言語を使って
あいまいに表現しているのだと。
■ユースケース図
・サービスとサービスの提供先を表す
・サービスは機能ではない
■クラス図
・静的モデル
・モデル要素の構造を表す
・クラスの構造、クラスどうしの関係を表す
・必須モデル
・分析のクラス図と設計のクラス図がある
・情報量は、分析のクラス図 ＜ 設計のクラス図
■シーケンス図
・動的モデル
・モデル要素の振舞いを表す
・クラスではなくインスタンスが登場する
・分析のシーケンス図と設計のシーケンス図がある
■図の関係
・ユースケース図１：シーケンス図N
・ユースケース図１：VOPC(View of Participating Classes)図１
・ユースケース図N：全体のクラス図１
■図の作成順
ユースケース図→クラス図
１．ユースケース図
２．ユースケースごとのクラス図(VOPC図)
３．全体のクラス図
ユースケース図→シーケンス図
１．ユースケース図
２．ユースケースごとのユースケース仕様書
３．ユースケース仕様書のフローごとのシーケンス図
■開発工程と図の関係
要件定義
・機能要件に対してユースケース図とユースケース仕様書を作成
・非機能要件に対して非機能要件仕様書を作成
分析
・機能要件に対して分析のシーケンス図と分析のクラス図を作成
・非機能要件に対してアーキテクチャのシーケンス図とアーキテクチャのクラス図を作成
設計
・設計のシーケンス図と設計のクラス図を作成 ※アーキテクチャを組込む
■開発工程
要件定義
・焦点は仕様化
・要求を仕様として定義する
・曖昧性の排除、矛盾の解消
・実現性と重要度の適用
・機能要件と非機能要件を分けて定義
分析
・焦点は問題領域の構造と振舞い
・要件を分析するのではなく、問題領域を分析する
・非機能要件から必要なメカニズムを検出して実現のための設計を行う
設計
・How(どのように)を考える
・アーキテクチャを組込む
■UML以外のドキュメント
・UMLだけでは開発できない
・UML以外が適しているもの
・画面仕様書、画面設計書
・ファイル設計書
・データ遷移表(CRUD表)
■要件定義のユースケース図を検証
・ユースケース数は50以下
・多い場合は機能分割になっていないか、複数の目的を持ったシステムでないかを検証
・ユースケース名は動詞
・「アクター名」＋は＋「ユースケース名」で意味が通るもの
・「ユーザ」は「検索する」×→「ユーザ」は「書籍を検索する」○
・設計の思考を含まない
・「XML文書からお気に入りCDを検索する」×→「お気に入りCDを検索する」○
・アクターは役割を表す
・多くのアクターが同一のユースケースに関係している場合は検証(本当に必要なアクターか?)
・ユースケースの切出し単位
・多くのアクターが同一のユースケースに関係している場合は検証(ユースケースを分割するべきか?)
・アクターの切出し単位
・多くのユースケースが同一のアクターに関係している場合は検証(アクターを分割するべきか?)
■分析のクラス図を検証
・クラス名の適切さ
・名詞または形容詞＋名詞
・単数形
・問題領域で使われる用語
・機能名、～制御、～管理、～情報、は責務が曖昧となるためNG
・属性の適切さ
・本当にそのクラスに必要か?
・設計の思考が含まれていないか
・～IDという属性名がないか
・属性、引数、戻り値に型を定義してないか
・属性、操作に可視性を定義してないか ※分析では属性=プライベート、操作=パブリック
・ロールの適切さ
・集約の適切さ
・集約は「全体」-「部分」の関係
・部分は独立して存在できるが、全体は部分がないと存在できない
・クラスの存在意義
・属性が0または1つの場合は機能関数でないか検証
・アクセサしかない場合はエンティティクラス→分析では作成されない(設計の思考が含まれている)
・クラスの独立性
・すべてのクラスが関連する巨大なクラスが存在しないか → 分割の必要性を検証
・関係線が複雑でないか → 小さいクラスを統合できないか検証
■分析のシーケンス図を検証
・シーケンス図の単位
・ユースケース仕様書の基本フロー、代替フローの数と同じことを検証
・オブジェクトが３つ以上、メッセージ線が４本以上であることを検証
・オブジェクトの独立性
・１つのオブジェクトから多くのメッセージ線が引かれていないことを検証
・メッセージの中継しかしていないオブジェクトがないことを検証
■分析から設計のクラス図作成
・クラス図の分割単位
・オペレーション数が1～2の場合はクラスの必要性を検証
・オペレーション数が9つ以上の場合は複数の責務を負ったクラスでないか検証
・パッケージの分割単位
・クラス数が5～9でない場合はサブパッケージへの分割の必要性を検証
・パッケージのツリーの適切性を検証(その親子関係は妥当か?)
・コンポジット関連
・インスタンスの寿命が同じであること
・全体側の多重度が1であること
・メッセージの引数
・3以下であること(4つ以上の場合はオブジェクト渡しの必要性を検証)
・チェックオペレーション
・checkという単語を使用しない
・validate～(型の正当性)に修正
・verifecate～(値の妥当性)に修正
目次
第1章 開発プロセスとUMLモデル Quick Tour
1-1 よく使われる図とは？
1-1-1 必ず使う図はどれか
1-1-2 その図は何のためにあるのか
1-1-3 図どうしの関係はどうなっているのか
Column シーケンス図とクラス図はどちらを先に描く？
1-2 UMLの図はどう使われるか
1-2-1 成長するモデル要素 要件定義から設計モデルまで
1-2-2 UMLモデルの部分適用
1-2-3 UMLのモデルでは表せないもの
Column 反復開発
第2章 モデリング セルフレビューノート
2-1 モデルを検証する基本的な技
2-1-1 検証とは
2-1-2 読んでみる
2-1-3 数えてみる
2-1-4 絵として見る
Column 日本語とUML
2-2 要件定義
2-2-1 ユースケース図
2-2-2 ユースケース仕様書
Column 共通と共有
2-3 分析
2-3-1 クラス図
2-3-2 シーケンス図
2-3-3 クラス図とユースケース図、シーケンス図の関係
2-4 設計への落とし込み
2-4-1 クラス図
2-4-2 シーケンス図
Column ユースケース駆動開発の弊害
第3章 品質基準
3-1 2つの品質基準と品質特性
3-1-1 品質は最初からつくりこむもの
3-1-2 品質の構造
3-1-3 品質基準とレビュー
Column 問題領域に精通した人を見つけるには？
3-2 モデル図の正しさ
3-2-1 ユースケースモデルの正しさとは？
3-2-2 分析モデルの正しさとは？
3-2-3 設計モデルの正しさとは？
Column モデルづくりは3人、レビューは5人
第4章 さらにスキルアップするために
4-1 UMLとオブジェクト指向の学習曲線
4-1-1 仕事で使えるようになるには何ヶ月必要か
4-1-2 UMLとオブジェクト指向習得に挫折してしまう理由
4-1-3 従来の教育スタイルではなぜ効果がないのか
4-2 習得のコツ
4-2-1 今まで身につけた技術をいかそう
4-2-2 必須習得の基本技術を身につけよう
4-2-3 最低3通りの設計モデルを書こう
4-3 道具箱（リファレンス）
4-3-1 書籍の選び方
4-3-2 書籍の使い方
付録 書籍リスト
ソフトウェア工学
論理学
分類学
本棚登録 : 
感想 : 
0
