UMLダイアグラム

コンテンツ

 [йљ гЃ™пјЅ 

• 1 歴史
• 1.1 UML 1.x以前
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 デザイン
• 2.1 ソフトウェア開発手法
• 2.2 モデリング
• 3つのダイアグラム
• 3.1 構造図
• 3.2 ビヘイビアダイアグラム
• 3.2.1 インタラクション・ダイアグラム
• 4 メタ・モデリング
• 5 養子縁組
• 6 批判
• 6.1 UML 1.xへの批判

歴史[編集元｜編集］

オブジェクト指向の手法と表記法の歴史

UMLは1990年代後半から進化しており、そのルーツは1980年代後半から1990年代前半に開発されたオブジェクト指向の手法にあると言われています。年表（画像参照）には、オブジェクト指向のモデリング手法や表記法の歴史のハイライトが示されている。

元々はBooch法、OMT（Object-modeling technique）、OOSE（Object-oriented software engineering）の表記法をベースにしており、それらを1つの言語に統合したものです。 ^[5]

UML 1.x以前[編集元｜編集]。

ラショナル・ソフトウェア社は、1994年にゼネラル・エレクトリック社からジェームス・ランボー氏を採用し、その後、当時最も人気のあった2つのオブジェクト指向モデリング手法の発信源となった。^[6]ルンボーのオブジェクト・モデリング・テクニック（OMT）とグラディ・ブーシュの手法である。1995年には、オブジェクト指向ソフトウェアエンジニアリング（OOSE）の生みの親であるアイバー・ヤコブソンがRational社に加わり、彼らの活動を支援した。 ^[1]

この3人（Rumbaugh、Jacobson、Booch）の技術的なリーダーシップのもと、1996年にUMLパートナーと呼ばれるコンソーシアムが組織され、UML（Unified Modeling Language）の仕様を完成させ、OMG（Object Management Group）に提案して標準化を進めていった。また、UMLパートナーには、HP、DEC、IBM、Microsoftなどの他の関係者も参加していた。1997年1月、UML PartnersのUML 1.0ドラフトがコンソーシアムからOMGに提案された。同月、UMLパートナーは、クリス・コブリンを議長、エド・アイクホルトを管理者とする、言語構造の正確な意味を定義するためのグループを結成し、仕様を確定し、他の標準化活動と統合することにしました。この作業の結果、1997年8月にUML 1.1がOMGに提出され、1997年11月にOMGによって採択された。 ^[1][7]

UML 1.x[ソースを編集｜編集]。

最初のリリースの後、言語を改善するためのタスクフォースが結成^[1]され、1.3、1.4、1.5といくつかのマイナーリビジョンがリリースされました。 ^[8]

このようにして作られた規格は（オリジナルの規格と同様に）、曖昧で一貫性がないと指摘されています。

UML 2.x[エディットソース｜編集]。

UML 2.0メジャーリビジョンは、2005年のバージョン1.5に代わるもので、コンソーシアムを拡大して開発され、機能の使用に関する新たな経験を反映して言語をさらに改良しました。 ^[11]

UML 2.1は正式な仕様としては発表されなかったが、2007年にバージョン2.1.1と2.1.2が登場し、2009年2月にはUML 2.2が発表された。2010年5月にはUML2.3が正式にリリースされました。^[12]2011年8月にUML 2.4.1が正式にリリースされました。^[12]UML 2.5は2012年10月に「In process」バージョンとしてリリースされ、2015年6月に正式にリリースされた。 ^[12]

UML 2.xの仕様には4つの部分があります。

1. ダイアグラムとそのモデル要素の表記法とセマンティクスを定義する上部構造
2. 上部構造のベースとなるコア・メタモデルを定義するインフラストラクチャー
3. モデル要素のルールを定義するOCL（Object Constraint Language）。
4. UML 2の図のレイアウトを交換する方法を定義するUML Diagram Interchange

これらの標準の現在のバージョンは以下の通りです。UML Superstructureバージョン2.4.1、UML Infrastructureバージョン2.4.1、OCLバージョン2.3.1、UML Diagram Interchangeバージョン1.0です。^[13]UML Superstructureは、言語の問題点を解決する改訂タスクフォースによって、更新と改良が続けられています。 ^[14]

デザイン[エディットソース｜エディット]について

UML（Unified Modeling Language）は、システムのアーキテクチャ設計図を図（画像参照）で可視化する方法で、以下^[5]のような要素が含まれています。

• あらゆる活動（仕事）
• システムの個々のコンポーネント
• そして、それらが他のソフトウェアコンポーネントとどのように相互作用するか。
• システムの動作について
• エンティティが他とどのように相互作用するか（コンポーネントとインターフェース）
• 外部ユーザーインターフェース

UML（Unified Modeling Language）は、元々はオブジェクト指向の設計文書のみを対象としていましたが、上記のようなより広い範囲の設計文書をカバーするように拡張され^[15]、多くの場面で活用されています。 ^[16]

ソフトウェア開発手法[編集元｜編集］

UMLは、それ自体は開発手法ではありません^[17]が、当時の代表的なオブジェクト指向ソフトウェア開発手法（OMT、Booch法、Objectoryなど）との互換性を考慮して設計されており、特にRational Software Inc.での作業開始時に使用することを想定していたRUPとの互換性を考慮して設計されています。

モデリング[エディットソース｜編集]。

UMLモデルとシステムのダイアグラムのセットを区別することが重要です。ダイアグラムとは、システムのモデルを部分的に図示したものです。図の集合は、モデルを完全にカバーする必要はなく、図を削除してもモデルは変わりません。また、モデルには、モデル要素や図を駆動する文書（書面によるユースケースなど）が含まれることがあります。

UML図は、システム・モデル^[18]の2つの異なるビューを表します。

• 静的ビュー（構造ビュー）：オブジェクト、属性、操作、関係を用いてシステムの静的な構造を強調する。構造ビューには、クラス図や複合構造図などがある。
• ダイナミック（またはビヘイビア）ビュー：オブジェクト間のコラボレーションやオブジェクトの内部状態の変化を示すことで、システムのダイナミックな動作を強調します。このビューには、シーケンス図、アクティビティ図、ステートマシン図が含まれます。

UMLモデルは、XMI（XML Metadata Interchange）交換フォーマットを使用して、UMLツール間で交換することができます。

ダイアグラム[編集元｜編集]

UML 2には多くの種類のダイアグラムがあり、それらは2つのカテゴリーに分けられます。^[5]いくつかのタイプは構造情報を表し、残りのタイプは一般的な動作を表し、その中には相互作用のさまざまな側面を表すものもあります。これらの図は、次のクラス図^[5]に示すように、階層的に分類することができます。

これらの図には、用途、制約、意図を説明するコメントやメモが含まれていることがあります。

構造図[編集元｜編集]。

構造図は、モデル化されるシステムに必ず存在するものを強調するものです。構造図は構造を表しているので、ソフトウェア・システムのソフトウェア・アーキテクチャを文書化する際に広く使用されます。例えば、ソフトウェア・システムがどのようにコンポーネントに分割されているかを記述し、これらのコンポーネント間の依存関係を示すコンポーネント・ダイアグラムがあります。

• コンポーネント図
• クラス図

ビヘイビア・ダイアグラム[編集元｜編集]。

振る舞い図は、モデル化されたシステムで何が起こるべきかを強調するものです。振る舞い図は、システムの振る舞いを示すものであるため、ソフトウェア・システムの機能を記述するために広く使用されています。例えば、アクティビティ・ダイアグラムでは、システム内のコンポーネントのビジネスおよび運用上のステップ・バイ・ステップのアクティビティを記述します。

• アクティビティ図
• ユースケース図

インタラクション・ダイアグラム[編集元｜編集].

相互作用図は、動作図のサブセットで、モデル化されたシステム内のものの間の制御とデータの流れを強調するものです。例えば、シーケンス・ダイアグラムは、オブジェクトがどのように相互に通信するかを、メッセージのシーケンスで示します。

• シーケンス図
• 通信図

メタモデリング[編集元｜編集］

主な記事メタオブジェクト・ファシリティ

メタオブジェクト機能のイメージ

Object Management Group（OMG）は、Unified Modeling Language（UML）を定義するために、Meta-Object Facility（MOF）と呼ばれるメタモデリング・アーキテクチャを開発しました。^[19]メタオブジェクト・ファシリティは、右の図のように4層構造のアーキテクチャとして設計されています。一番上の層にはM3層と呼ばれるメタ・メタ・モデルが用意されています。このM3モデルは、メタオブジェクト・ファシリティがM2モデルと呼ばれるメタモデルを構築するために使用する言語です。

レイヤー2のメタオブジェクト・ファシリティ・モデルの最も顕著な例は、UMLメタモデル（UML自体を記述するモデル）です。これらのM2モデルは、M1層の要素を記述したものであり、したがってM1モデルである。これらは、例えば、UMLで書かれたモデルなどになります。最後の層は、M0-層またはデータ層です。これは、システムのランタイムインスタンスを記述するために使用されます。 ^[20]

メタモデルは、ステレオタイプと呼ばれるメカニズムを使って拡張することができます。これについては、Brian Henderson-SellersとCesar Gonzalez-Perezが「Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0」の中で、不十分／不可能であると批判しています。 ^[21]

採用[エディットソース｜エディット]について

UMLは、多くの設計分野で有用であることがわかっており、^[16]ITコミュニティの中ではほとんどユビキタスなものとなっています。 ^[22]

また、デザインの特効薬のように扱われることもありますが、これは使い方に問題があります。誤った使い方とは、過剰な使い方（システムコードの細かい部分までこれで設計する必要はない）や、誰でも（プログラミングをしたことがない人でも）これで何でも設計できると思い込んでしまうことです。 ^[23]

大規模な言語であり、多くの構造を持っていると考えられています。ジェイコブソンをはじめとする一部の人たちは、その数が多すぎて、学習（ひいては使用）の妨げになると感じている。 ^[24]

批判の声[編集元｜編集]をご紹介します。

産業界からのUMLに対する一般的な批判には次の^[4]ようなものがある。

• not useful:「現在の進化したやり方や表現に対する利点を提供していない」。
• 複雑すぎて、特に顧客とのコミュニケーションに支障をきたす。不必要に複雑」「UMLを使わない一番の理由は、すべての関係者にとって『読みやすい』ものではないということです。ビジネスユーザー（顧客）があなたのモデリング努力の結果を理解できないなら、UMLにどれほどの価値があるだろうか？"
• 一般的なドキュメントと同様に、UMLとコードを同期させる必要があります。

UML 1.xへの批判[編集元｜編集]。

カーディナリティの表記

データベースのChen、Bachman、ISO ER図と同様に、クラスモデルは、「look-across」カーディナリティを使用するように規定されているが、何人かの著者（Merise、^[25]Elmasri、Navathe^[26]など^[27]）は、ロールや最小および最大カーディナリティのために、同一側または「look-here」を好む。最近の研究者（Feinerer, ^[28]Dulleaなど^[29]）は、UMLやER図で使用されている「look-across」技法は、次数が2以上のn-ary関係に適用すると、効果や一貫性が低下することを示している。

Feinerer氏は「UMLのアソシエーションに使われているようなルック・アクロス・セマンティクスに基づいて操作すると問題が発生します。Hartmann^[30]はこの状況を調査し、どのように、そしてなぜ異なる変換が失敗するのかを示しています。"(ただし、3.4と3.5の2つの図は実際には同じものなので、言及されている「縮小」は偽物である)また、"次の数ページで見るように、look-acrossの解釈は、単純なメカニズムを2項のアソシエーションからn項のアソシエーションに拡張することを妨げるいくつかの困難をもたらしている "と述べている。