ITパスポート試験 用語辞典
- 構造図
- システムの静的な構造をモデルで表現する。
クラス図、コンポジット構造図、コンポーネント図、配置図、オブジェクト図、パッケージ図 - 振る舞い図
- システムの振る舞いをモデルで表現する。
アクティビティ図、ユースケース図、シーケンス図、インタラクション概念図、コラボレーション図、タイミング図、ステートマシン図
- 分野：
- マネジメント系 » ソフトウェア開発管理技術 » 開発プロセス・手法
- 出題歴：
- 22年春期問29
- 重要度：
(Wikipedia 統一モデリング言語より)
統一モデリング言語（とういつモデリングげんご、UML、英: Unified Modeling Language）はソフトウェア工学におけるオブジェクトモデリングのために標準化した仕様記述言語であり、グラフィカルな記述で抽象化したシステムのモデル（UMLモデル）を生成する汎用モデリング言語である。
最初期の版はラショナルにおいて、グラディ・ブーチ、イヴァー・ヤコブソン、ジェームズ・ランボーの3人が策定した。この3人はスリーアミーゴスと呼ばれている。現在は Object Management Group（OMG） が管理している。ソフトウェア開発において、ソフトウェアを利用する汎用モデリング言語として、現在最も普及している。2013年10月現在の最新版は UML 2.4.1 であり、ISO/IEC 19501:2005 として UML 1.4.2 を、また、ISO/IEC 19505-1:2012 ならびに ISO/IEC 19505-2:2012 として UML 2.4.1 を標準化している。
UML 2.0 以降では13種類の図（ダイアグラム）を必要に応じて書き分ける。よく使う図としては、状態遷移図、シーケンス図がある。特定の言語での開発が決まった時点では、クラス図やユースケース図を使う場合がある。
概要
UMLの公式な定義は、OMG が Meta-Object Facility（MOF）のメタモデルを使って行っている。他のMOFベースの仕様と同様、UMLメタモデルとUMLモデルは XMI でシリアライズできる。UML はソフトウェアを中心とするシステムの仕様を記述し、視覚化し、構築し、文書化するために設計された。
UML はソフトウェアのモデリングだけに利用する訳ではない。ビジネスプロセスのモデリングやシステム工学的モデリングにも使われ、組織の構造図を表現するのにも使うことができる。Systems Modeling Language（SysML）は、UML 2.0 プロファイルとして定義されたシステム工学用のドメイン固有モデリング言語である。
UML は、モデル駆動工学（MDE) やモデル駆動型アーキテクチャ (MDA) といったモデル駆動型の技術が発展するきっかけとなった。クラス、コンポーネント、汎化、集約といった概念の視覚的な記法について業界の合意を得るようになったことで、ソフトウェア開発者は設計や構造（アーキテクチャ）に集中できるようになった。
UMLモデルは、OMG が対応する QVT などの変換言語を使って、他の表現（Javaなど）に自動的に変換できる場合がある。
UMLには拡張性があり、プロファイルやステレオタイプといった機構でカスタマイズできる。プロトタイプによる拡張の意味論は UML 2.0 で改善している。
歴史
1994年、ラショナルはゼネラル・エレクトリックからジェームズ・ランボーを雇った。その後同社は今日の2つのオブジェクト指向モデリング技法を生み出すこととなった。それは、ランボーのオブジェクトモデル化技法（OMT, オブジェクト指向分析 (OOA) の一種）と、グラディ・ブーチのBooch法（オブジェクト指向設計 (OOD) の一種）である。ランボーとブーチは共同で彼らの技法を統一する作業を開始した。
間もなくイヴァー・ヤコブソンが加わった。オブジェクト指向ソフトウェア工学(OOSE)の開発者である。ヤコブソンは1995年に自身の会社である Objectory AB が買収されたことにより、ラショナルに合流した。この3人の方法論者をスリーアミーゴスと呼ぶ。
1996年、ラショナルはあまりにも多様なモデリング言語が存在しているとオブジェクト技術の採用が遅れてしまうと判断し、彼らの統合作業をオープンな統一モデリング言語の開発に方向転換した。OOPSLA '96 においてオブジェクト技術系の競合企業が集まってこれに関する話し合いが行われ、ランボーのOMT記法で使われていた四角形でクラスを表す技法がブーチの雲でクラスを表す技法に勝った。
スリーアミーゴスの技術リーダーシップの下、UMLパートナーズという国際コンソーシアムが1996年に結成され、統一モデリング言語（Unified Modeling Language、UML）仕様が完成し、OMG RFP に対する応答として提案された。UMLパートナーズの UML 1.0 仕様ドラフト版がOMGに提案されたのは、1997年1月であった。同月、UMLパートナーズはセマンティクス・タスク・フォースを結成し、仕様の意味論的側面の仕上げと他の標準化作業との整合作業を行った。その結果は UML 1.1 としてOMGに1997年8月に提出され、1997年11月に採用された。
モデリング記法としては、OMTの記法がほぼ踏襲された（例えば、クラスやオブジェクトを矩形で表すなど）。ブーチの「雲」記法は除外されたものの、ブーチ法に特有な低レベルな設計の詳細を記述する機能が採用されている。ヤコブソンの Objectory からユースケース図が採用され、ブーチのーネント図も採用された。しかし、意味論的な統合という観点では UML 1.1 は弱く、その点が大きく改善されたのは UML 2.0 であった。
他のオブジェクト指向手法の概念をUMLに緩やかに統合し、ほぼあらゆるオブジェクト指向手法に対応するものとなっている。例えば、CRCカード（1989年頃、ケント・ベックとウォード・カニンガムが考案）およびオブジェクト指向役割分析法（OORam）が考慮されている。他にも当時の様々なオブジェクト指向技法が寄与している。トニー・ヴァッサーマンとペーター・ピルヒャーの「オブジェクト指向構造設計（OOSD）」記法、Ray Buhr の「Adaによるシステム設計」、アーチー・ボウウェンのユースケースとタイミング解析、Paul Ward のデータ解析、David Harel の「状態図」などである。このとき、彼らはリアルタイムシステム領域もカバーしようとしていた。結果として、UMLは単一プロセスのアプリケーションから分散システムまで、様々な工学的問題に使えるツールとなり、巨大な仕様を抱えることになった。
UML は UML 1.1 以降も進化し続けている。いくつかのマイナーバージョン（UML 1.3, 1.4, 1.5）はバグや問題点を修正したものだが、UML 2.0 では大きく進化した。これが現在のOMG標準である。
UML 2.0 の最初の部分は、新しい図とモデリング要素を説明した高次構造（スーパーストラクチャ）であり、2004年10月にOMGにより採用された。他の部分はインフラストラクチャと呼ばれ、Object Constraint Language (OCL、オブジェクト制約言語) と図の関係を示したものであり、順次採用され、2005年11月に完成した。「」最終版が使用可能であると宣言され、OMGの形式仕様ライブラリに追加されている。UML仕様の他の部分として「」、「」、「」を採用している。
よく知られているUMLツールの多くは UML 2.0 のほとんどに対応している。一部、あまり使われない機能を実装していないことがある。
方法論
UML 自体は手法（方法論）ではなく、当時主流だったオブジェクト指向ソフトウェア開発手法群（OMT、Booch法、OOSE/Objectory など）と互換になるよう設計している。その後、UMLが普及するに従って、それら技法を新たな図を利用するよう変更している。また、UMLに基づいた新たな手法も登場している。よく知られている例としてはラショナル統一プロセス (RUP) がある。他にも Abstraction Method、DSDM などがあり、それぞれ異なった目的に特化している傾向がある。
UMLのダイアグラム
UML図は、システムの静的な構造を示す構造図と、システムの振る舞いを示す振る舞い図に分類される。振る舞い図の中で、オブジェクト間のメッセージのやり取りに着目したものを特に相互作用図と呼ぶ。
- クラス図
- システムを構成するクラス（概念）とそれらの間に存在する関連の構造を表現する。ユーザの視点から、システムを構成する物や概念を表す。
- 複合構造図
- ーネント図
- 物理的な構成要素 (ファイル、ヘッダ、ライブラリ、モジュール、実行可能ファイルやパッケージなど) からシステムの構造を表現する。
- 配置図
- ハードウェアとアプリケーションとの関係を図示したもの。
- オブジェクト図
- クラスを実体化して生成されたオブジェクト同士の関係を表現する。
- パッケージ図
- パッケージ同士の依存関係を描画することで論理的なグルーピングをするための図で、クラス図の一部である。パッケージは、慣例的にはディレクトリ構造のように表すことができる。パッケージ図では、システムを論理的な階層構造に分解するのに役立つ。
振る舞い図
振る舞い図では、システムの振る舞いをモデルで表現する。
- アクティビティ図
- システムなどのフローを記述する表記法、フローチャートの一種。UMLでは表記するフローは特定されておらず、ユーザ側に近い業務のフローや、実装に近い関数のフローを示すことができる。
- ユースケース図
- システムに要求される機能を、ユーザの視点から示したもの。ユースケース図を有効に活用することにより、システムの全体像を開発者とユーザが一緒に評価しやすくなる。これにより完成後のシステムがユーザの要望に合わないという問題を軽減できる。
- ステートチャート（状態遷移図、ステートマシン図、状態機械図）
- 1つのオブジェクトの状態（ステート）に着目し、その変化を表現したもの。
相互作用図
相互作用図は、振る舞い図の一種であり、オブジェクトに間のデータ(メッセージ)の受け渡しをモデル化する。
- シーケンス図
- オブジェクト間のメッセージの流れを時系列に表す。図の中に時間の流れが存在するため、イベントの発生順序やオブジェクト間の生存時間を記述することができる。
- コミュニケーション図（コラボレーション図）
- オブジェクト間のメッセージのやり取りを示す。シーケンス図とは、異なりオブジェクトを中心に記述する。
- UML2.xから一部の表記変更と共にコラボレーション図から、コミュニケーション図に名称が変更された。
- 相互作用概要図
- タイミング図
批判
UMLはモデリング標準として広く認知され使われているが、以下のような問題点をよく指摘される。
- 言語肥大
- :UMLは無駄に大きく複雑になっていると批判されることが多い。多数の図と構成要素から成っていて、その一部は滅多に使われず、しかも冗長である。特に UML 2.0 になってから委員会的妥協案が多くなったことで、このような批判が増えている。
- 学習と採用に関する問題
- :上の批判とも関係するが、UMLの学習や採用は難しくなりつつある。
- コードとの同期問題
- :UMLモデリングは、それ自体の美しさよりも実際に動作するシステムのモデルでなくてはならない。Jack Reeves はこれを簡潔に「コードは設計である」と表している。この考え方を推し進めると、ソフトウェアの書き方の改善が必要とされていることになる。UMLは、そこからソースコードや実行コードを生成できるツールもある。しかし、UML 2.0 の Action Semantics がチューリング完全かどうかは明らかではないため、十分とは言えない。
- インピーダンス不整合
- :UMLは他の表記法と比較しても、簡潔かつ効率的にシステムを表現できる。従って、開発者にはUMLとプログラミング言語の両方で記述可能なソリューションを重視する傾向が生じる。しかし、言語が正統なオブジェクト指向言語でない場合、UMLと言語間に共通点が少ないため、この問題が特に大きくなる。
- 見た目の不統一感
- :場当たり的に様々な図が統合されているため、統一感がないという批判もある。
- 八方美人
- :UMLは汎用モデリング言語であり、様々な実装言語との互換性を達成しようとしている。個別のプロジェクトでは、目標達成のために設計チームがUMLの利用可能な機能を区別する必要がある。さらに言えば、UMLの範囲を特定の領域に限定する方法は完全には定式化されておらず、それも批判の対象となっている。
バートランド・メイヤーとエドワード・ヨードンが American Programmer 誌に書いた "UML: The Positive Spin" という記事は、UMLをパロディ形式（UMLをテーマとしてその長所を書かなければならなくなった学生が書いた論文という体裁）で厳密に批判したものである。Eiffel Software のアーカイブ・サイトにある。
- オブジェクト指向
- データ中心アプローチ
- プロセス中心アプローチ
- UML
- DevOps
- ウォータフォールモデル
- スパイラルモデル
- プロトタイピングモデル
- RAD
- リバースエンジニアリング
- アジャイル
- XP
- テスト駆動開発
- ペアプログラミング
- リファクタリング
- スクラム
- 共通フレーム
- CMMI
このページのWikipediaよりの記事は、ウィキペディアの「統一モデリング言語」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。