Caprices

Unified Modelling Languageの略で統一モデリング言語と言う。

標準化を進める団体はOMG（Object Management Group）という。

モデリング（Modeling）のためのもの

モデルを作成するもの

誰にでもわかりやすい世界共通の表記法が定義されている。

追跡可能性（Traceability、トレーサビリティ）があり、工程の違うモデルが変更されても容易に反映ができる

UMLのデメリットとして具体的な開発方法を含まない点が上げられる

UMLは使用で表記方法だけ定められている。

いろいろな図（Diagram、ダイアグラム）があるが、必ずしも全て利用する必要性はない

• Grady Booch（グラディー・ブーチ）氏のBooch法
• Ivar Jacobson（イバー・ヤコブソン）氏のOOSE法
• James Rumbaugh（ジェームス・ランボー）氏のOMT法
• Sally Shlaer（サリー・シュレイアー）氏とStephen J.Mellor（スティーブ･J･メラー）氏のShlaer-Mellor法

ブーチ氏、ランボー氏、ヤコブソン氏でUML1.0を誕生させた

スリーアミーゴ:ブーチ氏、ランボー氏、ヤコブソン氏

1994

ブーチ氏、ランボー氏がモデル表記表統一を開始

OOPSLA'95

1995

Unified Method 0.8（Booch法、OMT法）

ヤコブソン氏がモデリング技法の統一作業に参加

1996

UML0.9（OOSE法、ほかの手法）

1997/ 1

UML1.0

OMG提案

1997/ 9

UML1.1

OMG標準化

1997/11

UML1.1がOMG標準となる

1998

UML1.2

1999

UML1.3

2001

UML1.4

2003

UML1.5

2005

UML2.0

2007

UML2.1

• タイミング図（timing diagram）
• コンポジット構造図（composite stracture）

が追加された。

コンポーネント同士を組立ててシステムを開発する手法。

UML2.xにおけるコンポーネントとはインターフェース（interface）を備えた論理的なソフトウェア部品。

例:ERP（Enterprise Resource Planning:企業資源計画）

プラットフォーム（フレームワーク等）に依存しないモデルに変換し、さらに特化したモデルのプラットフォームにする。

CIM:Computation Independent Model

コンピュータに依存しないモデル。

PIM:Platform Independent Model

プラットフォームに依存しないモデル

PSM:Platform Specific Model

プラットフォームに依存（特化）したモデル

ソースコードが生成できるレベルのモデル

メタモデル（Meta-model）の整理･詳細化を行っている

• シーケンス図（sequence diagram）
• アクティビティ図（activity diagram）
• ステートマシン図（state machine diagram）

などの詳細化･厳密化がされている。

オブジェクト（Object）とは「物体、対象」

人間が考える単位であるモノやコトの単位を、システム開発でも利用しようというのがオブジェクト指向の考え方です。

• 振る舞い（Behavior）
• 属性（property）
• 責任（responsibility）

オブジェクトとは、「振る舞いや属性などの特性を持ち、特定の責任を果たす」ものである。

• データ中心アプローチ（DOA:Data Oriented Approach）
• プロセス中心アプローチ（POA:Process Oriented Approach）

オブジェクトが持つ構造的特性

名前と値を持つ

属性が変化すると、オブジェクトの状態（state）が変化する

オブジェクトの状態変化を表現するダイアグラムとしてステートマシン図がある

オブジェクトが持つ動作上の特性（操作ともいう）

オブジェクトが果たすべき役割

登場するオブジェクトの振る舞いや属性の共通部分を抽出して、枠組みを定義する（これをクラスという）

オブジェクトからクラスを抽出して、一般化することを抽象化（abstraction）という

クラスから具体的なオブジェクトを作成することを、具象化もしくはインスタンス化（instantiation）という

インスタンス化で生み出された具象物はインスタンス（instance）という

あるオブジェクトに関連する操作と属性を1つのまとまりとして扱い、さらにはそれらも保護してシステムの保守性や再利用を確保しようとする考え方

一般的には、オブジェクトの状態や振る舞いを外部から自由に変えることができないように、オブジェクトを保護する必要がある。

オブジェクトを利用する側は、オブジェクトの内部構造を知る必要がなくなり、オブジェクトの内部構造が変更されても利用するオブジェクトには影響が及ばない

オブジェクトを保護するためには、なんらかの影響を与えたり、振る舞いを呼び出したりするための窓口が必要でこれをインターフェースという

いくつかのクラスからより一般的なクラスを作り出すことを汎化（generalization）という。

一般的なクラスから、性質を持ちつつ、個別の振る舞いを持つクラスを作成することを特化（specialization）という。

一般的なクラスの特徴を引き継いだ個別のクラスを作ることを継承（inheritance）という。

継承元のクラスを「親クラス」（またはスーパークラス）、継承先のクラスを「子クラス」（またはサブクラス）と呼ぶ。

複数のオブジェクトが同じシグニチャ（名前、引数など）を持つことによって、同じ振る舞いを呼び出しても異なる機能を果たすことを多態性（polymorphism）もしくは多様性という。

振る舞いを呼び出す際に行われるもの。

ＵＭＬではシーケンス図などの相互作用図によって、オブジェクト間のメッセージのやり取りを表します。

オブジェクト指向の要素（クラスやコンポーネントに対して仕様変更が加えられる場合、拡張に対しては開かれて（open）、修正については閉じられて（close）いなければならないという原則。

機能拡張が容易で、機能を追加する場合に他の部分に悪影響を与えないようになり、保守性／拡張性の面で優れたシステムを作成できるようになる。

子クラスは親クラスと置換（substitution）可能でなければならない、つまり親クラスで可能なことは全ての子クラスでも可能である必要があるという原則。

ユースケース（use case）とは、システムが外部に提供する機能のこと。

システムのユーザが認識できるレベルの機能であり、システムの内部の詳細な機能は表現しない。

ユースケース図（use case diagram）は、ユーザ視点でシステムの機能を把握するのに役立つダイアグラムで、主に要求分析で使用される。