UMLモデリング入門 本質をとらえるシステム思考とモデリング心理学

児玉公信

モデリングとは、情報システムを開発する際に、ユーザーの要求やシステムの全体像を図として見える形にすることです。システム開発の最初の分析・設計作業を支える重要な技術であり、現在では、UML(統一モデリング言語)が、その表記法として定着してきています。ただ、UMLは表記ルールを定めたものであり、モデルを作成する手順や方法は決まっていません。
本書は、情報システムの設計で必須となる3つのモデル(静的・動的・機能モデル)を、UMLを使って作成する方法を、基本から丁寧に説明します。クラス図、オブジェクト図、状態機械図、活動図、ユースケース図/記述の間で整合性をとりながら、より良いモデルへと作り上げていく手順とポイントがきちんとわかります。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 言語・プログラミング
• 出版社: 日経BP
• ページ数: 289ページ
• 電子版発売日: 2013年05月10日
• コンテンツ形式: XMDF
• サイズ(目安): 6MB

[ブクログ · ★★★★★]

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

[ブクログ · ★★★★★]

ＵＭＬの学習を始めるため購入。

わかりやすい！なぜこのようになっているのかを経緯から説明してくれるので理解しやすい。

[ブクログ · ★★★★☆]

難しい。

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

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

[ブクログ · ★★★★☆]

UMLについて学ぶというよりは、物事を抽象化してモデル化することの意義とか、そーいうことをきっちり説明してくれていて、その辺りが特に勉強になった本。
すっかり分かっている人がUMLの技法的な部分をちょちょっと頭に入れるには物足りないかもしれないですが、これから開発、設計の道を歩み始める人にはすごく良いと思います。

[ブクログ · ★★★☆☆]

概念・モデリングの使い方等は非常にわかりやすく書かれいているけれども、

演習問題が初心者にはだいぶ回答するのが困難な本だと思いました。

（自分がちょうどモデリング初心者です）

実際にモデリングを行う教本と一緒に進める

(もしくは先に行うかこの本を読んだあとにやっておく)方が効果的だと思いました。

[ブクログ · ★★★★★]

メモ

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

UMLの記法も分かりやすい

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

[ブクログ · ★★★★★]

長年、UMLでシステムについて記述する指導をしてきた技術士による集大成。
本質をどうとらえて、どう記述するかを、システム思考とモデリングの際の心理から解き明かそうとしている。
著者は、システムおよびUMLのコンサルタントであり、幅広い活動をされている。

UMLを最初に勉強するのに適している。
UML(Unified Modeling Language)はモデルを作るための道具(言語)だから。

クラス図がUMLだとか、ユースケース図がUMLだと思っている人は、本書を読んで、もっと本質的な問題を理解するとよい。

特に大事だと思う部分は、次の２箇所かもしれない。

1-5 モデルには認識する人がいる。
コラム「もの」を識別するということ
モデリングとは、情報システムを開発する際に、ユーザの要求やシステムの全体像を図として見える形にすることです。

1-5 モデルには認識する人がいる。
は、
1-5 モデルには認識する人が要る。
ではどうだろう。

8-1　状態機械図(state machine)は、状態図、状態遷移図とも呼ばれている
モデルは、模型のことである。シミュレーションは日本語では模擬試験である。
UMLで模型を記述するのは、模擬試験をするためであることが分かる。

本書は、UMLの機能については万遍なく記述している。
模型の鍵が何かが伝わってくる。

モデルを作る際の鍵についての指針がほしいかもしれない。
ステートマシン図は、状態機械図あるが、ステートチャート（状態図）、状態遷移図とも呼ばれている。
状態遷移図は、模型作成の鍵の一つである。
状態とは変数で表されるもの、条件で表されるものではあるが、
対象（オブジェクト）の性質そのものである。そのため、対象の知識を、まず状態で表現するのがよい。

体系（システム）とは、入力を出力に変換するものであり、
状態とは、入力を出力に変換するために持つ内部の仕組みである。

本書を読んだら、次に状態遷移図を勉強するのとよい。

状態遷移図が分かれば、時系列図を描くとよい。
通信、組込み、リアルタイム制御では、時系列図が必須だから。
現在、ネットワークを利用しないシステムはないのだから。

物理現象を扱うのであれば、刻時図は必須。
回路設計、回路に応じた制御設計などなど。

[ブクログ · ★★★☆☆]

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の図。