UMLモデリング入門

著者 : 児玉公信

• 日経BP (2008年4月24日発売)

作品紹介・あらすじ

本書では、UMLを使い、ユーザー要求をどのようにモデルに落とし込んでいけばよいのか、その手順とポイントを基本から丁寧に解説。正解と言い切るのがむずかしいモデル作成にあって、より良いモデルへ導いていくための道筋をしっかり伝授。

感想・レビュー・書評

[sou (08thse)さんの感想 · 2023年9月16日]

古典ですね。

[isseiabeさんの感想 · 2021年5月9日]

良いモデルは正しい知識から生まれる

[横さんの感想 · 2021年4月14日]

ITの表現技法で、設計者には通らなければ道の１つ。

[しあさんの感想 · 2020年4月5日]

20191227特許の図の描き方を勉強できないかとペラペラ見た。UMLは細かすぎて片手間では難しすぎる(ドツボにはまる)ので、後ろの方に書いてあるけどパス。ただ図の概念とか起源とか参考にはなったかも。

P2 モデリングとは「対象を深く知るために、その振る舞いを観察し、それを論理的に記述し、関係者と共有する活動」と定義します。
まず、対象を、”境界を持ったシステム”として認識し、その構成要素を明らかにすること。次に、構成要素間の相互作用を明らかにすること。最後に、その相互作用がシステムの振る舞いとして、外部にどう表出されるかを明らかにすること。これに加えて、それらを関係者と共有できるようにモデルとして表現すること。

モデリングの過程では、対象を観察してはモデルを作り、モデルを作っては壊しを繰り返して、より本質的なモデルに到達しようと努力します。

P3 システムとは複数の要素が互いに影響を及ぼし合いながら、全体として複雑な振る舞いをする仕組み全体のことです。

P11 ソフトウェアシステムのモデルの定義：「ある人のある状況に関する明示された解釈」byBrian Wilson
ハードウエアシステムのモデルのモデルの定義：「関連ある現象を包括的にまとめ、そこに1つのまとまったイメージを与えるようなシステム」by印東太郎

P14 インスタンス(例示)：ひとつひとつの経験に属するものごと。概念：抽象化されたものごと

P15 概念とは類似のインスタンス集合を作り、それに命名したもの。あるいは、ものごとを類似性によって集合に分類して命名したものである。

P17 インスタンスを考えるときは、”ぎりぎりの際どい例(境界例)”を挙げて考えるようにする。誰かと概念を共有しているということは、それに含まれるインスタンスがほぼ一致しているということだと思う。際どい例を挙げることで本当に概念を共有しているかがわかりますし、互いに概念の境界を修正していくことができます。

インスタンスを集めることが基本。人間活動システムでは、すべてのメンバーが挙げられていることは稀。そのためモデリングの際には与えられたメンバーから概念を請求に絞り込むのではなく、常にいくつかの可能性を抑えておくことが重要。人間の認識の仕組みはソフトウェアとは異なり、曖昧な概念や論理的な冗長性の上に成り立っている。

P18 集合を形成するメンバーが共通に持つ性質を「属性種」、個々のメンバが持つ属性種の”値”を属性値と呼ぶ。

P19 概念を型として扱う。型は属性種と操作を持ち、オブジェクト指向ではクラスの原型にあたる。型とはインスタンスを分類して概念化したもの。概念化は分類と命名によって行われる。

P20 概念体系を再構築することが、本来的意味での「モデリング」である。モデリングではよりシンプルで頑強な概念体系を追求する。

P21 モデルという言葉には、そのある人(認識主体)が解釈し言明した概念構造をその人とは別の人が理解しようとしていることが暗に含まれる→認識主体が誰なのか、あるいは誰のモデルなのかその立場や価値観を共有する必要がある。

P22 認識主体にとって意味あることで、試行の容量に収まるものしか見えない。同じ言葉でも意味が微妙にずれる。＝すべての階層の業務を横断的かつ総合的に扱うモデルは作れない。回想をまたがるシステムを作るときは、システム間の概念の対応付け、データの集約または分解などの翻訳機能を介する必要がある。さらに階層の境界も固定的ではない(なぜならもともと対象の味方なので)ので、環境に応じて柔軟に変化する。こうした認識主体を無理やり統合ではなく、それぞれ尊重してモデルを作る。

P24-26 表1.1がよい。 システムの仕様定義には3つの観点がある。それぞれの観点から要求を分析することで、次の要素モデルを得られる。これら3つを合わせることで要求の合成モデルが出来上がる。Tom DeMarco

＃現在では()中のように呼ぶ
機能モデル(機能側面)→データフロー図
データモデル(静的側面)→ER図(Entity Relationship Diagram)
状態遷移モデル(動的側面)→状態遷移図

機能側面：システムが外部から何を受けて何を返すかを設計する。
静的側面：時間の流れを任意の時点で止めてシステムで使われる概念同士のかかわり方を設計する。
動的側面：時間の経過に沿って、あるいは事象の発生によって概念のインスタンスがどのように状態を変化させるかを設計する。

機能側面：データフロー図。
静的側面：オブジェクト図＝機能ブロック？
動的側面：状態遷移図。

P28 UMLで定義されている13の図。

[fuji70さんの感想 · 2018年10月20日]

読書メモ：UMLモデリング入門

2012/11/12(月)〜11月19日(月)　６日間200分程度

思考方法などけっこう熱く語られている。しかしこちらとしてはそこまでは必要ないな。
ざっと読んだのでもう読まなくてもよいかな。
UMLはシステムを記述するために、複数の要素の動きを説明するために用いるらしいと言うのは事前の想定と異なった視点だった。分かりやすく説明するための視座＝ビューによって図の書き方が異なるというのも、想定と異なったとらえ方だった。

・システム思考とは全体を見る態度。逆は、全体を要素に分解した上で決定論的に説明。
・モデルの視点＝ビュー
　１つのモデル（図）は１つの視点で書くようにする。

[more]

モデリングに必要な３つの側面
　機能モデル、データモデル、状態遷移モデル

　静的側面：オブジェクト図、クラス図
　機能側面：ユースケース図、シーケンス図
　動的側面：状態遷移図、タイミング図
（物理側面）：配置図、コンポーネント図

UML2.0：13種の図

ユースケース図：　人の線図＝スティックマンで表すアクターのアイコン
　シナリオはインスタンスレベル。ユースケースは型レベル。抽象度が一段上。
　シナリオは、A,Xとかではなく具体名で書いた方がよい。

XYZ公式
　ユースケース全体を「（顧客／施主が）Zするために、（システムが）YをXする」と書く。
　do X by Y in order to Z

4枚カード問題
　４枚のカードのうち、何枚あければルール徹底がわかるか？
　１：　E K 4 7　　　母音なら裏は偶数　→　E,7
　２：　ビール飲む　コーラ飲む　22歳　16歳：　ビールは20歳以上　→ビール、16歳
　人は２は正解するが１はわからない。

要求記述文書の構成として有名なテンプレート
　ボレーレアプローチによる要求文書テンプレート
　　 http://wiki.livedoor.jp/okey200808/d/%CD%D7%B5%E1%C4%EA%B5%C1

要求のモデル化の例
１：期待の整理＝インタビュー
２：リッチピクチャ＝インタビューメモから漫画的な画を描く。
３：基本定義：　合意できそうなものから１，２個の基本定義を作る
　　CATWOE（キャットゥー）: Customer, Actor, Transformation(システムの変換機能）, Weltanschauung(価値基準）, Owner（施主）, Environment
４：基本課題：現状（as-isモデル）とあるべき姿（to-beモデル）の差を課題とする

原要求の記述
　記述方法としてのIEEEテンプレート
　Concept of Operations http://www.metabolics.co.jp/SoftwareProcess/ConOps.html

[bob-taniさんの感想 · 2014年10月18日]

モデリングとはごちゃまぜを片付いたように見せることだと。
UMLを使ってのモデリング解説。

[ymuto0302さんの感想 · 2012年12月12日]

「入門」と名付けられているものの，さらに易しい本を使って UML に含まれるチャートをひと通り概観した後に手にするとよいかな，という印象。クラス図，オブジェクト図，ユースケース図といった概念モデルを中心に取り上げている点で物足りなさを感じるが，個々のチャートが指向しているものは何か，どのような点に注意してチャートを描く／読めばよいかを懇切丁寧に説明している点で良書である。

[yasu2keiさんの感想 · 2012年6月21日]

難しい。

モデリングの本を読むのはこれが初めてだが、やはり難しかった。モデリングを実際にやってみるとわかるが、結果として作るモデルにこれといった正解がない。唯一の答えがあるわけではなく、答えと思われるものが無数に考えられる。モデリングの対象は1つだろうが、それを見る視点が複数あって、経験がまったくないうちは、よいわるいの判断基準もよくわからずどの視点を選ぶべきか迷うことが多い。

第1章の「モデルが表現するもの」が、初心者には最も役に立った。

[silver-fishさんの感想 · 2012年3月31日]

システムを説明する際、的確に要件を定義し、プログラム仕様を決定するために利用するモデリング方法に関する本。
モデリングとは、ある特定の視点で整然とした動きを説明する技法である。特定の視点に限りわかりやすくモデル化することで人間が理解しやすい形にする。その代償として、他の視点からそのモデルを見ると混沌としている・ほしい情報がでない事になる。
複数の視点から特定のシステムを見る場合にはその視点の数だけモデルを作る必要がある。
本書ではそのモデリング方法でUMLに関して説明している。

[hirotoshi8さんの感想 · 2012年1月21日]

メモ

施工者の原要求、開発者の要求は区別する
機能とは、原要求を実現するための手段。
そして、これが開発者にとっての要求。

UMLの記法も分かりやすい

次のStepは、どんな開発タイミングで、どの程度の粒度で図を書くか。
開発の中で実際にどう使うかは勉強する必要があると思った。