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

  • 75人登録
  • 3.50評価
    • (9)
    • (1)
    • (22)
    • (2)
    • (0)
  • 5レビュー
著者 : 荒井玲子
  • ディーアート (2005年4月1日発売)
  • Amazon.co.jp ・本 (199ページ)
  • / ISBN・EAN: 9784886487445

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を検索する」○

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

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

     ・アクターの切出し単位
      ・多くのユースケースが同一のアクター... 続きを読む

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

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


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

    つまり、

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

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


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

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


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

    ★★★

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

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

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

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

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

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

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

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

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

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

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

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

全5件中 1 - 5件を表示

UMLによるオブジェクト指向モデリングセルフレビューノートを本棚に登録しているひと

UMLによるオブジェクト指向モデリングセルフレビューノートを本棚に「読みたい」で登録しているひと

UMLによるオブジェクト指向モデリングセルフレビューノートを本棚に「いま読んでる」で登録しているひと

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

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

ツイートする