Language)である。最初期の版はラショナルにおいて、グラディ・ブーチ、イヴァー・ヤコブソン、ジェームズ・ランボーの3人が策定した。この3人はスリーアミーゴスと呼ばれている。管理しており、現在最も普及していると主張されている。以降では、ダイアグラム(図法)が13種類もあり(#UMLのダイアグラムを参照)、各種の図法を必要に応じて使い分けなければならない(というより、別に節を改めて説明しているが、単なる肥大化であり、単に必要ないものは無視すべきということである)。使う図としては、ユースケース図、ステートマシン図、シーケンス図、クラス図などがある。UMLはデザインパターンを説明するために良く使われている。Facility(MOF)のメタモデルを使って行っている。ソフトウェアを中心とするシステムの仕様を記述し、視覚化し、構築し、文書化するために設計された。ソフトウェアのモデリングだけに利用する訳ではない。ビジネスプロセスのモデリングやシステム工学的モデリングにも使われ、組織の構造図を表現するのにも使うことができる。プロファイルとして定義されたシステム工学用のドメイン固有モデリング言語である。いったモデル駆動型の技術が発展するきっかけとなった。クラス、コンポーネント、汎化、集約といった概念の視覚的な記法について業界の合意を得るようになったことで、ソフトウェア開発者は設計や構造(アーキテクチャ)に集中できるようになった。変換言語を使って、他の表現(Javaなど)に自動的に変換できる場合がある。UMLには拡張性があり、プロファイルやステレオタイプといった機構でカスタマイズできる。方法論[編集]UMLは言語であって方法論ではない。)いくつかの方法論で使われていた記法(言語)と似たものとすることなど互換性を考慮しつつ、GoFによるデザインパターンのそれぞれの説明に利用できる記法(言語)として設計されたものがUML(当初の)である。歴UML図は、システムの静的な構造を示す構造図と、システムの振る舞いを示す振る舞い図に分類される。振る舞い図の中で、オブジェクト間のメッセージのやり取りに着目したものを特に相互作用図と呼ぶ。diagrams)は、静的な構造の図である。クラス図システムを構成するクラス(概念)とそれらの間に存在する関連の構造を表現する。ユーザの視点から、システムを構成する物や概念を表す。複合構造図この節の加筆が望まれています。システムの構造を表現する。配置図ハードウェアとアプリケーションとの関係を図示したもの。オブジェクト図クラスを実体化して生成されたオブジェクト同士の関係を表現する。パッケージ図パッケージ同士の依存関係を描画することで論理的なグルーピングをするための図で、クラス図の一部である。パッケージは、慣例的にはディレクトリ構造のように表すことができる。パッケージ図では、システムを論理的な階層構造に分解するのに役立つ。diagrams)は、振る舞いの図である。diagram)システムの機能などを、ユーザの視点などを含めた「ユースケース」として図示するもの。これを、有効に活用することにより、システムの全体像を開発者とユーザが一緒に評価しやすくなる、であるとか、完成後のシステムがユーザの要望に合わないという問題を軽減できる、といったように主張される。diagram)フローチャートである。diagram、状態機械図)状態遷移図である。相互作用図[編集]相互作用図は、振る舞い図の一種であり、オブジェクトに間のデータ(メッセージ)の受け渡しをモデル化する。シーケンス図オブジェクト間のメッセージの流れを時系列に表す。図の中に時間の流れが存在するため、イベントの発生順序やオブジェクト間の生存時間を記述することができる。コミュニケーション図(コラボレーション図)オブジェクト間のメッセージのやり取りを示す。シーケンス図とは、異なりオブジェクトを中心に記述する。この節の加筆が望まれています。タイミング図この節の加筆が望まれています。歴史[編集]UMLの歴史1994年、ラショナルはゼネラル・エレクトリックからジェームズ・ランボーを雇った。その後同社は今日の2つのオブジェクト指向モデリング技法を生み出すこととなった。ランボーとブーチは共同で彼らの技法を統一する作業を開始した。間もなくイヴァー・ヤコブソンが加わった。オブジェクト指向ソフトウェア工学(OOSE)の開発者である。買収されたことにより、ラショナルに合流した。この3人の方法論者をスリーアミーゴスと呼ぶ。1996年、ラショナルはあまりにも多様なモデリング言語が存在しているとオブジェクト技術の採用が遅れてしまうと判断し、彼らの統合作業をオープンな統一モデリング言語の開発に方向転換した。おいてオブジェクト技術系の競合企業が集まってこれに関する話し合いが行われ、ランボーのOMT記法で使われていた四角形でクラスを表す技法がブーチの雲でクラスを表す技法に勝った[1]。対する応答として提案された。仕様ドラフト版がOMGに提案されたのは、1997年1月であった。同月、UMLパートナーズはセマンティクス・タスク・フォース[3]を結成し、仕様の意味論的側面の仕上げと他の標準化作業との整合作業を行った。してOMGに1997年8月に提出され、1997年11月に採用された[4]。モデリング記法としては、OMTの記法がほぼ踏襲された(例えば、クラスやオブジェクトを矩形で表すなど)。ブーチの「雲」記法は除外されたものの、ブーチ法に特有な低レベルな設計の詳細を記述する機能が採用されている。ユースケース図が採用され、ブーチのコンポーネント図も採用された。他のオブジェクト指向手法の概念をUMLに緩やかに統合し、ほぼあらゆるオブジェクト指向手法に対応するものとなっている。CRCカード(1989年頃、ケント・ベックとウォード・カニンガムが考案)およびオブジェクト指向役割分析法(OORam)[5]が考慮されている。他にも当時の様々なオブジェクト指向技法が寄与している。「状態図」[11]などである。このとき、彼らはリアルタイムシステム領域もカバーしようとしていた。結果として、UMLは単一プロセスのアプリケーションから分散システムまで、様々な工学的問題に使えるツールとなり、巨大な仕様を抱えることになった。以降も進化し続けている。これが現在のOMG標準である。最初の部分は、新しい図とモデリング要素を説明した高次構造(スーパーストラクチャ)であり、2004年10月にOMGにより採用された。図の関係を示したものであり、順次採用され、2005年11月に完成した。specification」最終版が使用可能であると宣言され、OMGの形式仕様ライブラリに追加されている。OCL」を採用している。ほとんどに対応している。一部、あまり使われない機能を実装していないことがある。批判[編集]UMLはモデリング標準として広く認知され使われているが、以下のような問題点をよく指摘される。言語肥大UMLは無駄に大きく複雑になっていると批判されることが多い[12]。多数の図と構成要素から成っていて、その一部は滅多に使われず、しかも冗長である。なってから委員会的妥協案が多くなったことで、このような批判が増えている。種類を利用し、2種類の図(リクワイアメント図とパラメトリック図)とアロケーションテーブルを追加している。上の批判とも関係するが、UMLの学習や採用は難しくなりつつある[14]。コードとの同期問題UMLモデリングは、それ自体の美しさよりも実際に動作するシステムのモデルでなくてはならない。これを簡潔に「コードは設計である」と表している[15]。この考え方を推し進めると、ソフトウェアの書き方の改善が必要とされていることになる。UMLは、そこからソースコードや実行コードを生成できるツールもある。チューリング完全かどうかは明らかではないため、十分とは言えない。インピーダンス不整合UMLは他の表記法と比較しても、簡潔かつ効率的にシステムを表現できる。従って、開発者にはUMLとプログラミング言語の両方で記述可能なソリューションを重視する傾向が生じる。言語が正統なオブジェクト指向言語でない場合、UMLと言語間に共通点が少ないため、この問題が特に大きくなる。場当たり的に様々な図が統合されているため、統一感がないという批判もある。八方美人UMLは汎用モデリング言語であり、様々な実装言語との互換性を達成しようとしている。個別のプロジェクトでは、目標達成のために設計チームがUMLの利用可能な機能を区別する必要がある。言えば、UMLの範囲を特定の領域に限定する方法は完全には定式化されておらず、それも批判の対象となっている。いう記事は、UMLをパロディ形式(UMLをテーマとしてその長所を書かなければならなくなった学生が書いた論文という体裁)で厳密に批判したものである。アーカイブ・サイトにある[12]。この勝利を記念してランボーがジョニ・ミッチェルの「Clouds」をア・カペラで歌ったという[要出典]。その種の問題を論じている。2005年12月28日閲覧。Genova.関連項目[編集]ウィキメディア・コモンズには、統一モデリング言語に関連するカテゴリがあります。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。