UMLによるオブジェクト指向モデリングセルフレビューノート

著者 :
  • ディーアート
3.49
  • (9)
  • (1)
  • (23)
  • (2)
  • (0)
本棚登録 : 76
レビュー : 5
  • Amazon.co.jp ・本 (199ページ)
  • / ISBN・EAN: 9784886487445

作品紹介・あらすじ

10年以上にわたるオブジェクト指向モデリング技術を使ったプロジェクトと技術者の立上げに実績のあるノウハウをふんだんに公開。UMLでの表現と自分が表現したいことが合っているのかわからないという、UML初心者の誰もが突き当たる問題に、本書がお答えします。

感想・レビュー・書評

並び替え
表示形式
表示件数
  • 「自然言語で仕様はきっちりと語ることができる。」
    語れないのは、その言葉の使い方を間違えているのだと。
    まずは、日本語の勉強をしなければいけない。
    言語があいまいなのではなく、人が言語を使って
    あいまいに表現しているのだと。

    ■ユースケース図

     ・サービスとサービスの提供先を表す
     ・サービスは機能ではない

    ■クラス図

     ・静的モデル
     ・モデル要素の構造を表す
     ・クラスの構造、クラスどうしの関係を表す
     ・必須モデル
     ・分析のクラス図と設計のクラス図がある
     ・情報量は、分析のクラス図 < 設計のクラス図

    ■シーケンス図

     ・動的モデル
     ・モデル要素の振舞いを表す
     ・クラスではなくインスタンスが登場する
     ・分析のシーケンス図と設計のシーケンス図がある

    ■図の関係

     ・ユースケース図1:シーケンス図N
     ・ユースケース図1:VOPC(View of Participating Classes)図1
     ・ユースケース図N:全体のクラス図1

    ■図の作成順

     ユースケース図→クラス図
      1.ユースケース図
      2.ユースケースごとのクラス図(VOPC図)
      3.全体のクラス図

     ユースケース図→シーケンス図
      1.ユースケース図
      2.ユースケースごとのユースケース仕様書
      3.ユースケース仕様書のフローごとのシーケンス図

    ■開発工程と図の関係

     要件定義
      ・機能要件に対してユースケース図とユースケース仕様書を作成
      ・非機能要件に対して非機能要件仕様書を作成

     分析
      ・機能要件に対して分析のシーケンス図と分析のクラス図を作成
      ・非機能要件に対してアーキテクチャのシーケンス図とアーキテクチャのクラス図を作成

     設計
      ・設計のシーケンス図と設計のクラス図を作成 ※アーキテクチャを組込む

    ■開発工程

     要件定義
      ・焦点は仕様化
      ・要求を仕様として定義する
      ・曖昧性の排除、矛盾の解消
      ・実現性と重要度の適用
      ・機能要件と非機能要件を分けて定義

     分析
      ・焦点は問題領域の構造と振舞い
      ・要件を分析するのではなく、問題領域を分析する
      ・非機能要件から必要なメカニズムを検出して実現のための設計を行う

     設計
      ・How(どのように)を考える
      ・アーキテクチャを組込む

    ■UML以外のドキュメント

     ・UMLだけでは開発できない
     ・UML以外が適しているもの
      ・画面仕様書、画面設計書
      ・ファイル設計書
      ・データ遷移表(CRUD表)

    ■要件定義のユースケース図を検証

     ・ユースケース数は50以下
      ・多い場合は機能分割になっていないか、複数の目的を持ったシステムでないかを検証

     ・ユースケース名は動詞
      ・「アクター名」+は+「ユースケース名」で意味が通るもの
      ・「ユーザ」は「検索する」×→「ユーザ」は「書籍を検索する」○

     ・設計の思考を含まない
      ・「XML文書からお気に入りCDを検索する」×→「お気に入りCDを検索する」○

     ・アクターは役割を表す
      ・多くのアクターが同一のユースケースに関係している場合は検証(本当に必要なアクターか?)

     ・ユースケースの切出し単位
      ・多くのアクターが同一のユースケースに関係している場合は検証(ユースケースを分割するべきか?)

     ・アクターの切出し単位
      ・多くのユースケースが同一のアクターに関係している場合は検証(アクターを分割するべきか?)

    ■分析のクラス図を検証

     ・クラス名の適切さ
      ・名詞または形容詞+名詞
      ・単数形
      ・問題領域で使われる用語
      ・機能名、~制御、~管理、~情報、は責務が曖昧となるためNG

     ・属性の適切さ
      ・本当にそのクラスに必要か?

     ・設計の思考が含まれていないか
      ・~IDという属性名がないか
      ・属性、引数、戻り値に型を定義してないか
      ・属性、操作に可視性を定義してないか ※分析では属性=プライベート、操作=パブリック

     ・ロールの適切さ

     ・集約の適切さ
      ・集約は「全体」-「部分」の関係
      ・部分は独立して存在できるが、全体は部分がないと存在できない

     ・クラスの存在意義
      ・属性が0または1つの場合は機能関数でないか検証
      ・アクセサしかない場合はエンティティクラス→分析では作成されない(設計の思考が含まれている)

     ・クラスの独立性
      ・すべてのクラスが関連する巨大なクラスが存在しないか → 分割の必要性を検証
      ・関係線が複雑でないか → 小さいクラスを統合できないか検証

    ■分析のシーケンス図を検証

     ・シーケンス図の単位
      ・ユースケース仕様書の基本フロー、代替フローの数と同じことを検証
      ・オブジェクトが3つ以上、メッセージ線が4本以上であることを検証

     ・オブジェクトの独立性
      ・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 書籍の使い方

    付録 書籍リスト
     ソフトウェア工学
     論理学
     分類学

  • 本書には、UML初心者を対象に、自分が行ったモデリングが正しいのかどうかセルフレビューする方法が易しく書かれています。

    テストエンジニアが設計レビューに参加する時にも役に立つと思うのでそういった意味でも読んで欲しいと思います。


    びっくりしたのは、モデリング結果を日本語にして読んでみるという方法です。いや、それを知らなかったからびっくりしたのではなく私がいつも行っている方法だから驚いたのです(私のやり方は、普通だったんですね)。

    つまり、

    ・ユースケース図
     「アクター名」+は+「ユースケース名」

     良い例) 「ユーザ」は「郵便番号を検索する」
     悪い例) 「ユーザ」は「検索する」
     悪い例) 「ユーザ」は「DBから郵便番号を検索する」


    ・クラス図の属性の適切さ
     「クラス名」+の+「属性名」

     良い例) 「プロジェクト」の「予算」
     悪い例) 「プロジェクト」の「プロジェクト予算」


    といった具合にモデリングされた図を日本語に変換しながら読んでみる方法を勧めていて、それって自分がやってたことだなぁと。。。

    ★★★

    本書で気になったのは「言い切り」が多い点です。

     非機能要件には分析という行為はありません。

     ユースケース仕様書は、通常A4サイズの用紙で3枚から8枚のボリュームを持っています。

     パッケージの大きさが適切かどうかを検証するためには、パッケージに格納されているクラスの数を数えてみることです。

     適切なクラスの数は、「5~9クラス」です。

    このような断定は、初心者にはあるいは良い指針を与えることになるのかもしれませんが、根拠に乏しいものもあり気になりました。
    でも、全体的に良書なのでお勧めです。

  • オブジェクト指向言語やUMLの文法書、デザインパターンの解説書はあっても、UMLのモデルの読み方やレビューの仕方を扱った本はこれまでなかったように思います。

    本書は、UMLのモデルをどう読むか?良いモデルを評価するためにはどうしたら良いかを解説しています。

    モデルを描いてみたものの、どう評価したら良いか分からないという人にはオススメ。

    ちなみに書籍中に登場する評価指標は、あくまでも参考程度として、自分なりの指標を確立していくと良いと思います。

  • 手元において何度も読み返した一冊

  • OOモデリングをする時に、手元においてます。

全5件中 1 - 5件を表示

荒井玲子の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
トム デマルコ
Joel Spo...
有効な右矢印 無効な右矢印
ツイートする