Umlの説明。 UML図。ステートチャートの内部アクティビティ

UMLは、OOシステムを記述、視覚化、設計、および文書化するための統一されたグラフィカルモデリング言語です。 UMLは、OOアプローチに基づいてソフトウェアシステムをモデル化するプロセスをサポートし、概念とソフトウェアの概念の関係を整理し、複雑なシステムのスケーリングの問題を反映するように設計されています。 UMLのモデルは、ビジネス分析からシステムメンテナンスまで、ソフトウェアシステムのライフサイクルのすべての段階で使用されます。さまざまな組織が、問題のある領域と使用されているテクノロジーに応じて、適切と思われるUMLを適用できます。

UMLの簡単な歴史

90年代半ばまでに、数十のOOモデリング手法がさまざまな作成者によって提案され、それぞれが独自のグラフィック表記を使用していました。同時に、これらの方法にはそれぞれ長所がありましたが、十分に完全なPSモデルを構築することはできず、「すべての側面から」、つまり必要なすべての投影を示しました（記事1を参照）。さらに、オブジェクト指向モデリング標準がないため、開発者は最も適切な方法を選択することが困難であり、ソフトウェア開発へのオブジェクト指向アプローチの普及を妨げていました。

オブジェクトテクノロジーとデータベースの分野で標準の採用を担当する組織であるObjectManagement Group（OMG）の要請により、統一と標準化の緊急の問題は、最も人気のある3つのOOメソッドの作成者によって解決されました-G .Buch、D。Rambo、およびA. Jacobsonは、努力を結集してUML 1.1を作成しました。これは、1997年にOMGによって標準として承認されました。

UMLは言語です

どの言語も、意味のある構造を得るために単語を組み合わせるための語彙と規則で構成されています。したがって、特に、UMLなどのプログラミング言語が配置されています。その特徴は、言語辞書がグラフィック要素で構成されていることです。各グラフィックシンボルには特定のセマンティクスがあるため、ある開発者が作成したモデルは、UMLを解釈するソフトウェアツールだけでなく、別の開発者も明確に理解できます。このことから、特に、UMLで提示されたPSモデルは、オブジェクト指向プログラミング言語（Java、C ++、VisualBasicなど）に自動的に変換できます。つまり、UMLをサポートする優れたビジュアルモデリングツールがある場合です。、モデルを構築すると、このモデルに対応するプログラムコードの準備ができます。

UMLは言語であり、メソッドではないことを強調しておく必要があります。モデルを作成する要素とその読み方については説明していますが、どのモデルをどのような場合に開発する必要があるかについては何も述べていません。 UMLに基づくメソッドを作成するには、ソフトウェア開発プロセスの説明を補足する必要があります。このようなプロセスの例は、Rational Unified Processです。これについては、以降の記事で説明します。

UML語彙

モデルは、エンティティとそれらの間の関係の形式で表され、図に示されています。

エンティティモデルの主要な要素である抽象化です。エンティティには、構造（クラス、インターフェイス、コンポーネント、ユースケース、協調、ノード）、動作（相互作用、状態）、グループ化（パッケージ）、および注釈（コメント）の4つのタイプがあります。各タイプのエンティティには、独自のグラフィック表現があります。エンティティについては、図を調べるときに詳しく説明します。

関係エンティティ間のさまざまな関係を示します。 UMLは、次のタイプの関係を定義します。

中毒は、2つのエンティティ間のこのような接続を示しています。一方を変更すると（独立）、もう一方のエンティティに影響を与える可能性があります。依存関係は、依存エンティティから独立エンティティを指す破線の矢印で示されます。
協会あるエンティティのオブジェクトが別のエンティティのオブジェクトに関連していることを示す構造的な関係です。関連付けは、リンクされているエンティティを結ぶ線としてグラフィカルに表示されます。アソシエーションは、オブジェクト間を移動するために使用されます。たとえば、「Order」クラスと「Product」クラスの関連付けを使用して、特定の注文で指定されたすべての商品を検索したり、特定の製品が存在するすべての注文を検索したりできます。。対応するプログラムがそのようなナビゲーションのためのメカニズムを実装しなければならないことは明らかです。ナビゲートするのに1つの方向だけが必要な場合は、関連付けの最後に矢印で示されます。アソシエーションの特殊なケースは、集約-「全体」-「部分」の形式の関係です。グラフィカルに、エンティティ全体の近くの端にひし形で強調表示されます。
一般化親エンティティと子孫エンティティの間の関係です。基本的に、この関係はクラスとオブジェクトの継承プロパティを反映しています。一般化は、親エンティティを指す三角形で終わる線として表示されます。子は親の構造（属性）と動作（メソッド）を継承しますが、同時に新しい構造メンバーと新しいメソッドを持つことができます。 UMLでは、エンティティが複数の親エンティティに関連付けられている場合に多重継承が許可されます。
実装-動作の仕様を定義するエンティティ（インターフェイス）と、この動作の実装を定義するエンティティ（クラス、コンポーネント）の間の関係。この関係は、コンポーネントモデリングで一般的に使用され、以降の記事で詳しく説明します。

ダイアグラム。 UMLは、次の図を提供します。

システムの動作を説明する図：

状態図、
アクティビティ図、
オブジェクト図、
シーケンス図、
コラボレーション図

システムの物理的な実装を説明する図：

コンポーネント図
配置図

モデルコントロールビュー。パッケージ。

モデルを人がよく理解するためには、モデルを階層的に編成し、階層の各レベルに少数のエンティティを残す必要があることはすでに述べました。 UMLには、モデルの階層表現（パッケージ）を編成する手段が含まれています。すべてのモデルは、クラス、ユースケース、およびその他のエンティティと図を含むことができるパッケージのセットで構成されています。パッケージには、階層を作成するための他のパッケージを含めることができます。 UMLには個別のパッケージ図はありませんが、他の図に表示される場合があります。パッケージは、タブ付きの長方形として表示されます。

UMLが提供するもの。

パッケージを割り当てることによる複雑なシステムの階層的記述。
ユースケースの装置を使用したシステムの機能要件の形式化。
アクティビティとシナリオの図を作成して、システムの要件を詳しく説明します。
データクラスを強調表示し、クラス図の形式で概念データモデルを構築します。
ユーザーインターフェイスを説明するクラスを強調表示し、画面ナビゲーションスキームを作成します。
システム機能を実行するときのオブジェクトの相互作用のプロセスの説明。
アクティビティと状態の図の形式でのオブジェクトの動作の説明。
ソフトウェアコンポーネントとインターフェイスを介したそれらの相互作用の説明。
システムの物理アーキテクチャの説明。

そして最後の...

UMLのすべての魅力にもかかわらず、ビジュアルモデリングツールなしで実際のソフトウェアモデリングでUMLを使用することは困難です。このようなツールを使用すると、表示画面に図をすばやく表示して文書化し、さまざまなOOプログラミング言語で空白のプログラムコードを生成し、データベーススキーマを作成できます。それらのほとんどには、プログラムコードのリエンジニアリングの可能性が含まれています-プログラムのソースコードを自動的に分析することによってSSモデルの特定の予測を復元します。これは、モデルとコードの一貫性を確保し、前任者の機能を継承するシステムを設計するときに非常に重要ですシステム。

UMLは、ソフトウェアシステムの開発で作成されたすべてのアーティファクトを指定、視覚化、設計、および文書化するための汎用グラフィカルモデリング言語です。

UMLについて詳細に説明している優れた本がたくさんあります（場所によっては非常に詳細に説明されています）。図、エンティティ、およびそれらの間の接続に関する基本的な概念を1か所に集めて、チートシートのようにすばやく思い出せるようにしたいと思います。。

メモは本の資料を使用しています。 Ivanov D. Yu。、Novikov F.A.統一モデリング言語UMLと レオネンコフ。 UMLチュートリアル.

まず、エディタを決めましょう。 Linuxでは、さまざまなUMLエディターを試しました。特に、UMLetは、Javaで記述されていますが、非常に高速に移動し、ほとんどのエンティティテンプレートが含まれています。クロスプラットフォームのUMLエディターであるArgoUMLもあります。これもJavaで記述されており、機能は豊富ですが、速度がさらに低下します。

私は落ち着きました UMLet、下に設定します Arch Linuxと Ubuntu:

＃Arch Linuxの場合yaourt-S umlet＃Ubuntuの場合sudo apt-get install umlet

UMLでは、すべてのエンティティを次のタイプに分類できます。

構造;
行動;
グループ化;
注釈;

UMLで使用される関係には、主に4つのタイプがあります。

依存-独立エンティティを変更すると、依存エンティティに何らかの影響があることを示します。グラフィカルに、依存関係は、依存エンティティから独立エンティティを指す矢印の付いた破線として表されます。

協会-1つのエンティティが別のエンティティに直接関連している場合（または他のエンティティに関連している場合）に発生します-関連付けはバイナリだけではありません）。関連付けは、関連するエンティティを接続するさまざまな追加を含む実線としてグラフィカルに示されます。

一般化は2つのエンティティ間の関係であり、一方は他方の特殊な（特殊な）ケースです。グラフィカルに、一般化は、特定の（サブクラス）から一般（スーパークラス）に向けられた、最後に三角形の影のない矢印が付いた線として表されます。

実装-実装関係は、あるエンティティが別のエンティティの実装であることを示します。グラフィカルに、実装は、実現エンティティから実現可能エンティティに向けられた、最後に三角形の影のない矢印が付いた破線として示されています。

V UML 2定義されています 13 チャートの種類。標準では、各チャートの左上隅に長方形（右下隅が斜角）のボックスがあり、チャートID（タグ）とタイトルが示されています。

システムの構造を描写するための図:

コンポーネント図（タグ成分);
配置図（タグ展開);
クラス図（クラス図、タグ クラス);
オブジェクト図（タグ物体);
内部構造図（複合構造図、タグ クラス);

システムの動作を描写するための図:

相互作用図（タグ タイミング);
アクティビティ図（タグ アクティビティ);
シーケンス図（タグ SD);
コミュニケーション図（タグ通信);
ステートマシン図（タグ ステートマシン);
相互作用概要図タグ交流);

ダイアグラムは際立っています：

使用図（ユースケース図、ユースケースタグ）;
パッケージ図（タグ パッケージ);

使用図

使用図（ユースケース図）は、システムの機能目的の最も一般的な表現です。

システムのモデルとしてユースケース図を考えると、それをブラックボックスモデルに関連付けることができます。各ユースケースは、対応するアクターと対話するときに設計されたシステムによって実行される必要がある一連のアクションを定義します。

ユースダイアグラムは、ユースケースとアクターの2種類の基本エンティティを使用し、その間に次の基本的なタイプの関係が確立されます。

関係関係-この関係は、ユースケースのインスタンスと対話するときにアクターが果たす特定の役割を確立します。アソシエーション関係は、アクターとユースケースの間の実線で示されます。この行には、名前や多重度などの追加の記号を含めることができます。

膨張率-特定のユースケースのインスタンスがより一般的なユースケースにどのように関連するかを定義します。そのプロパティは、これらのインスタンスがどのように組み合わされるかに基づいて決定されます。したがって、ユースケースAからユースケースBへの拡張関係がある場合、これは、拡張ユースケースAにプロパティが存在するため、ユースケースBのインスタンスのプロパティを拡張できることを意味します。

ユースケース間の拡張関係は、元のユースケースの拡張であるユースケースから離れる方向を指す矢印（依存関係の場合）が付いた破線で示されます。

一般化関係特定のユースケースAをユースケースBに一般化できるという事実を示すのに役立ちます。この場合、オプションAはオプションBの特殊化になります。この場合、BはAに関連して祖先または親と呼ばれ、オプションAは、Vのオプション使用に関連する子孫です。

グラフィカルに、この関係は、親のユースケースを示す白抜きの三角形の矢印が付いた実線で示されます。

ユースケース間の一般化関係は、子のユースケースが親のユースケースのすべての属性と動作を持っていることに注意する必要がある場合に使用されます。

含有率 2つのユースケースの間は、一方のユースケースに指定された動作が、もう一方のユースケースの動作シーケンスに複合コンポーネントとして含まれていることを示します。

ユースケースAからユースケースBへの包含関係は、オプションAの各インスタンスにオプションBに指定された機能が含まれていることを示しています。

グラフィカルに、この関係は、基本ユースケースから含まれているユースケースを指す矢印（依存関係の場合）が付いた破線で示されます。

クラス図

クラス図（クラス図）は、システムの静的構造を説明する主な方法です。

クラス図では、エンティティの1つの主要なタイプが使用されます：クラス（クラスの多数の特殊なケースを含む：インターフェイス、プリミティブタイプ、アソシエーションクラスなど）、その間に次の基本的なタイプの関係が確立されます：依存関係、関連付け、一般化、実装。

依存関係一般に、関連付け、一般化、または実装関係ではない、2つのモデル要素またはそのような要素の2つのセット間の意味関係を示します。依存関係は、モデルの1つの要素を変更すると、モデルの別の依存要素を変更する必要がある場合に使用されます。

依存関係は、対応する要素間の点線でグラフで表され、一方の端に矢印があり、矢印は依存関係のクライアントクラスから独立したクラスまたはソースクラスを指しています。

矢印の上に特別なキーワード（ステレオタイプ）がある場合があります。

「アクセス」-パブリック属性のアクセス可能性とクライアントクラスのソースクラスの操作を示すのに役立ちます。
「バインド」-クライアントクラスは、後続のパラメーター化にテンプレートを使用できます。
「派生」-クライアントクラスの属性は、ソースクラスの属性から計算できます。
「インポート」-ソースクラスのパブリック属性と操作は、クライアントクラスで直接宣言されているかのように、クライアントクラスの一部になります。
「リファイン」-プロジェクトの作業中に追加情報が表示されたときに、クライアントクラスが履歴上の理由でソースクラスのリファインとして機能することを示します。

関係関係クラス間の何らかの関係の存在に対応します。この関係は、特定の関連付けの個々のプロパティを特徴付ける追加の特殊文字を含む実線で示されます。アソシエーションの名前、およびアソシエーションのロールクラスの名前と多重度は、追加の特殊文字として使用できます。アソシエーションの名前は、その指定のオプションの要素です。

凝集率クラスの1つが構成要素として他のエンティティを含む特定のエンティティである場合、複数のクラス間で発生します。これは、システム全体の関係を表すために使用されます。

構成関係集約関係の特殊なケースです。この関係は、ある意味で構成部分が全体の中にある、関係「部分全体」の特別な形を強調するのに役立ちます。それらの間の関係の特異性は、部品が全体から分離して機能することができないという事実にあります。つまり、全体が破壊されると、そのすべての構成部品が破壊されます。

一般化関係より一般的な要素（親または祖先）とよりプライベートまたは特別な要素（子または子孫）の間の関係です。この関係をクラス図に適用すると、クラスの階層構造と、クラスのプロパティと動作の継承が記述されます。子孫クラスには、祖先クラスのすべてのプロパティと動作があり、祖先クラスにはない独自のプロパティと動作もあると想定されています。

オートマトン図

オートマトン図（ステートマシン図）または 状態図 UML 1（状態チャート図）は、UMLの動作を詳細に説明する1つの方法です。本質的に、オートマトン図は、その名前が示すように、多くの追加の詳細と詳細がロードされた有限オートマトンの状態と遷移のグラフです。

状態図は、1つのクラスのみ、または特定のクラスの1つのインスタンスの状態を変更するプロセスを記述します。つまり、特定のオブジェクトの状態で発生する可能性のあるすべての変更をモデル化します。この場合、オブジェクトの状態の変化は、他のオブジェクトまたは外部からの外部の影響によって引き起こされる可能性があります。状態図が使用されるような外部の影響に対するオブジェクトの反応を説明することです。

オートマトン図では、1つの主要なタイプのエンティティ（状態と1つのタイプの関係）の遷移が使用されますが、両方について、多くの種類、特殊なケース、および追加の表記法が定義されています。オートマトンは、モデル化されたシステムの動的な側面を有向グラフの形式で表します。その頂点は状態に対応し、円弧は遷移に対応します。

初期状態内部アクションを含まない状態（疑似状態）の特殊なケースです。デフォルトのオブジェクトは、最初の時点ではこの状態になっています。これは、状態遷移プロセスが開始するグラフィックス領域を状態図で示すのに役立ちます。

ファイナル（ファイナル）状態は、内部アクション（疑似状態）も含まない状態の特殊なケースです。オートマトンが最後の瞬間に作業を終了した後、デフォルトのオブジェクトはこの状態になります。

アクティビティ図

設計または分析されたシステムの動作をモデル化する場合、その状態を変更するプロセスを表すだけでなく、システムによって実行される操作のアルゴリズム的および論理的実装の機能を詳細に示す必要があります。

アクティビティ図（アクティビティ図）は、アルゴリズムの古き良きフローチャートに視覚的に似ている動作を説明する別の方法です。操作を実行するプロセスをシミュレートするために使用されます。

アクティビティ図を使用する主な方向は、実行のためのアルゴリズムを提示する必要がある場合に、クラス操作の実装の特性を視覚化することです。

アクティビティ図では、1つの主要なタイプのエンティティ（アクション）と1つのタイプの関係（遷移（制御の転送））が使用されます。また、フォーク、マージ、結合、ブランチなどの構造も使用されます。簡単なアクション名として、説明的な単語を含む動詞を使用することをお勧めします。

シーケンス図

シーケンス図（シーケンス図）は、システムの動作を「例によって」説明する方法です。

実際、シーケンス図は、システム操作の特定のセッションのプロトコル（またはそのようなプロトコルのフラグメント）の記録です。オブジェクト指向プログラミングでは、最も重要なランタイムは、通信するオブジェクト間のメッセージの転送です。この図に表示されるのはメッセージの送信シーケンスであるため、この名前が付けられています。

シーケンス図では、1つの主要なタイプのエンティティ（相互作用する分類子（主にクラス、コンポーネント、およびアクター）のインスタンス）と1つのタイプの関係（メッセージが交換されるリンク）が使用されます。

考えられるメッセージタイプ（larin.inから取得した画像）：

コミュニケーション図

コミュニケーション図（コミュニケーション図）-シーケンス図と意味的に同等の動作を説明する方法。実際、これは相互作用する分類子インスタンスのメッセージ交換シーケンスの同じ説明であり、他のグラフィカルな手段でのみ表現されます。

したがって、通信図およびシーケンス図では、1つの主要なタイプのエンティティ（相互作用する分類子のインスタンスと1つのタイプの関係）のリンクが使用されます。ただし、ここでは時間ではなく、特定のインスタンス間のリンクの構造に重点を置いています。

コンポーネント図

コンポーネント図（コンポーネント図）-シミュレートされたシステムを構成するモジュール（論理または物理）間の関係を示します。

コンポーネント図のエンティティの主なタイプは、コンポーネント自体と、コンポーネント間の関係を示すためのインターフェイスです。コンポーネント図では、次の関係が適用されます。

コンポーネントとインターフェース間の実装（コンポーネントはインターフェースを実装します）。
コンポーネントとインターフェース間の依存関係（コンポーネントはインターフェースを使用します）。

配置図

配置図（配置図）は、システム要素の構成と関係を表示するとともに、実行時にコンピューティングリソース上に物理的にどのように配置されているかを示します。

配置図では、コンポーネント図と比較して、2つのタイプのエンティティが追加されます。コンポーネントとノードの実装であるアーティファクト（ノードのタイプを説明する分類子、または特定のインスタンスのいずれかです）。）、およびノード間の関連付け関係。ノードが実行時に物理的に接続されていることを示します。

オブジェクト図

オブジェクト図（オブジェクト図）-クラス図のインスタンスです。

オブジェクト図では、1つの主要なタイプのエンティティが使用されます。オブジェクト（クラスインスタンス）であり、その間に特定の関係が示されます（ほとんどの場合、関連付けインスタンス）。オブジェクト図は補助的な性質のものです。実際、オブジェクト図は、システムの機能における特定の瞬間におけるオブジェクトとその間の接続を示す例（メモリダンプと言うこともあります）です。

内部構造図（複合構造図）は、構造分類子、主にクラスとコンポーネントのより詳細な表示に使用されます。

構造分類子は長方形で表され、その上部に分類子の名前があります。中にはパーツがあります。いくつかの部分があります。パーツは相互作用できます。これは、さまざまな種類のコネクタを使用して示されます。コネクタが接続されているパーツの外縁の位置は、ポートと呼ばれます。ポートは、構造分類器の外縁にもあります。

相互作用の概要図インタラクション概要図は、構文が拡張されたアクティビティ図の一種です。シーケンス図で定義されたインタラクション使用リンクは、インタラクション概要図の要素として機能できます。

同期図

同期図（タイミング図）は、シーケンス図の特殊な形式であり、分類子のさまざまなインスタンスの状態とそのタイミングの変更に特別な注意が払われています。

パッケージ図

パッケージ図（パッケージ図）は、モデル自体の複雑さを管理できる唯一のツールです。

表記の主な要素は、さまざまなステレオタイプのパッケージと依存関係です。

実体関連モデル（ERモデル）

アナログ クラス図（UML）多分 ERモデル、データベースの設計に使用されます（リレーショナルモデル）。

実体関連モデル（ERモデル）は、ドメインの概念スキーマを記述できるようにするデータモデルです。 ERモデルは、高レベルの（概念的な）データベース設計で使用されます。その助けを借りて、主要なエンティティを強調表示し、これらのエンティティ間で確立できる接続を指定することができます。ウィキペディア

サブジェクトエリアのフラグメントは、エンティティのセットとして表すことができ、その間にいくつかの接続があります。

基本概念：

エッセンス（エンティティ）は、他のエンティティと区別するために何らかの方法で識別できるエンティティです。たとえば、 CLIENT 777..。エンティティは実際には属性のセットです。

エンティティセット（エンティティセット）-同じタイプ（同じプロパティを持つ）のエンティティのセット。

繋がり（関係）は、複数のエンティティ間に確立された関連付けです。

ドメイン（ドメイン）-属性の値のセット（スコープ）。

バイナリリンクには次の3つのタイプがあります。

1対1-1つのクラスのエンティティの単一のインスタンスは、別のクラスのエンティティの単一のインスタンスに関連付けられています（例：HEAD-DEPARTMENT）。
1からNまた 1対多-1つのクラスのエンティティの単一のインスタンスは、別のクラスのエンティティの多くのインスタンスに関連付けられています。たとえば、DEPARTMENT-EMPLOYEE;
NからMまた 多対多-1つのクラスのエンティティの多くのインスタンスは、別のクラスのエンティティの多くのインスタンスに関連付けられています。たとえば、EMPLOYEE-PROJECT;

基本的なUML概念の用語集

物体-一意であり、状態と動作をカプセル化するエンティティ。

クラス-状態を決定する共通の属性と動作を決定する操作を持つオブジェクトのセットの説明。

インターフェース-コンシューマーが要求し、サービスプロバイダーが提供できる一連のサービスを定義する名前付きの一連の操作。

コラボレーション-目標を達成するために相互作用するオブジェクトのセット。

俳優-モデル化されたシステムの外部にあり、システムと直接対話するエンティティ。

成分-必要なインターフェースと提供されたインターフェースの明確なセットを備えたシステムのモジュラー部分。

アーティファクト-ソフトウェア開発の過程で使用または生成される情報の項目。つまり、アーティファクトは、モデル要素（クラスやコンポーネントなど）から派生した実装の物理的な単位です。

ノード-アーティファクトが配置され、必要に応じて実行されるコンピューティングリソース。

行動エンティティは、行動を説明することを目的としています。基本的な動作エンティティは、状態とアクションの2つだけです。

州-オブジェクトのライフサイクルの期間。オブジェクトが特定の条件を満たすか、独自のアクティビティを実行するか、何らかのイベントの発生を待機します。

アクション-原始的な原子計算。

機械は、モデル化されたエンティティの動作を有限数の状態と遷移を持つ離散空間の形式で表すために必要な一連の概念を定義するパッケージです。

分類子同じタイプのオブジェクトのセットの記述子です。

追加の読み物

ファウラーM.UML。ファンダメンタルズ、第3版
Booch G.、Rambeau D.、JacobsonI.UML。ユーザーガイド

UMLモデル（UMLモデル）は、言語構造の有限集合のコレクションであり、その主なものはエンティティとそれらの間の関係です。

モデル自体のエンティティと関係は、メタモデルのメタクラスのインスタンスです。

最も一般的な観点からUMLモデルを考えると、それはグラフ（より正確には、ロードされたマルチ疑似ハイパーダイグラフ）であり、頂点とエッジに追加情報がロードされ、複雑な内部構造。 このグラフの頂点はエンティティと呼ばれ、エッジは関係です..。このセクションの残りの部分では、使用可能なエンティティタイプと関係の概要を簡単に（予備的に）提供します。幸いなことに、それらの数はそれほど多くありません。この本の後続の章では、すべてのエンティティと関係が、より詳細に、例を挙げて再度検討されます。

1.4.1。エンティティ

見やすくするために、UMLのエンティティは次の4つのグループに分割できます。

構造;
行動;
グループ化;
注釈。

ご想像のとおり、構造エンティティは構造を説明するためのものです。通常、構造エンティティには次のものが含まれます。

オブジェクト（オブジェクト）1は、一意であり、状態と動作をカプセル化するエンティティです。

クラス（クラス）2-状態を決定する共通の属性と動作を決定する操作を持つオブジェクトのセットの説明。

インターフェース（インターフェース）3は、コンシューマーが要求し、サービスプロバイダーが提供できる一連のサービスを定義する名前付きの一連の操作です。

協力（コラボレーション）4-目標を達成するために相互作用するオブジェクトのコレクション。

俳優（アクター）5は、モデル化されたシステムの外部にあり、システムと直接対話するエンティティです。

∇このような関係は確かに存在し、図1に示されています。 UML1のダイアグラムタイプ階層洗練されたステレオタイプとの依存関係として。

∇∇UML1では、協力図と同じ名前のエンティティの間に非自発的な関連付けが発生しましたが、これは完全に真実ではなく、誤解を招くこともありました。

∇∇∇UML2では、状態図の構文的および意味的な負荷が大幅に変更されたため、名前に内容が反映されなくなりました。

この本で使用されている新しいチャートとその名前のリストを以下に示します。

複合構造図
パッケージ図
ステートマシン図
コミュニケーション図
相互作用の概要図
タイミング図

図では。 UML 2のダイアグラムタイプ階層（パート1および2）は、UML2の図の関係を示すクラス図です。

この章の後半では、後で説明するための特定のコンテキストと語彙を用意するために、13の正規図すべてについて簡単に説明します。詳細は、本の残りの章に記載されています。

ただし、次のセクションに進む前に、標準でダイアグラムのフォーマットがどのように要求されているかについて少し説明しましょう。一般的なチャート表示テンプレートを以下に示します。

2つの主要な設計要素があります。外枠と図の名前が付いたラベルです。フレームを使用してすべてが単純な場合（図の要素を配置する領域の境界となる長方形）、図の名前は図に示すように特別な形式で記述されます。 チャートの表記.

示されたタブの複雑な形状は、すべてのツールでサポートされているわけではありません。ただし、セマンティクスがプライマリであり、表記がセカンダリであるため、これは必要ありません。これからは、全体を通して図のラベルとして長方形を使用しますが、これによって混乱が生じることはありません。

チャートに使用できるタグ（タイプ）を次の表に示します。標準で提供されるタグは、2番目の列に書き込まれます。ただし、実践が示しているように、標準によって提案されたルールは必ずしも便利で論理的に根拠があるとは限らないため、表の3番目の列には合理的な代替案が含まれています。

タブ。 チャートの種類とタグ

チャートタイトル	タグ（標準）	タグ（推奨）
使用図	使用事例また uc	使用事例
クラス図	クラス	クラス
オートマトン図	ステートマシンまた stm	ステートマシン
アクティビティ図	アクティビティまた活動	アクティビティ
シーケンス図	交流また SD	SD
コミュニケーション図	交流また SD	通信
コンポーネント図	成分また cmp	成分
配置図	未定義	展開
オブジェクト図	未定義	物体
内部構造図	クラス	クラスまた成分
相互作用の概要図	交流また SD	交流
同期図	交流また SD	タイミング
パッケージ図	パッケージまた pkg	パッケージ

UML（Unified Modeling Language）は、ソフトウェア開発におけるオブジェクトモデリングのためのグラフィカルな記述言語です。 UMLは広範な言語であり、グラフィカルな表記法を使用してUMLモデルと呼ばれるシステムの抽象モデルを作成するオープンスタンダードです。 UMLは、主にソフトウェアシステムを定義、視覚化、設計、および文書化するために作成されました。 UMLはプログラミング言語ではありませんが、UMLモデルをインタプリタコードとして実行することでコード生成が可能です。ウィキペディア

市販製品

Microsoft Visio

タイプ：商用ソフトウェア

UMLを含む豊富な図を描くことができるMicrosoftの人気のあるソフトウェア製品：

2010バージョンから、図をWeb（SharePoint + Visio Services）で公開できるようになりました。

Visio Viewer-以前に作成したVisio図を表示できる無料のプログラム。％D1％81％D1％81％D1％8B％D0％BB％D0％BA％D0％B5％20でダウンロードできます。

％0A

Microsoft％20Visual％20Studio％202010

％0A

％D0％A2％D0％B8％D0％BF：％20％D0％BA％D0％BE％D0％BC％D0％BC％D0％B5％D1％80％D1％87％D0％B5％D1％ 81％D0％BA％D0％BE％D0％B5％20％D0％9F％D0％9E％20（％D0％B5％D1％81％D1％82％D1％8C％20％D0％B1％D0 ％B5％D1％81％D0％BF％D0％BB％D0％B0％D1％82％D0％BD％D0％B0％D1％8F％20Express％20％D0％B2％D0％B5％D1％80 ％D1％81％D0％B8％D1％8F）。

％0A

％D0％92％20％D0％BF％D0％BE％D1％81％D0％BB％D0％B5％D0％B4％D0％BD％D0％B5％D0％B9％20％D0％B2％D0 ％B5％D1％80％D1％81％D0％B8％D0％B8％20 Microsoft％20Visual％20Studio％202010％20％D0％BF％D0％BE％D1％8F％D0％B2％D0％B8％ D0％BB％D1％81％D1％8F％20％D0％BD％D0％BE％D0％B2％D1％8B％D0％B9％20％D1％82％D0％B8％D0％BF％20％ D0％BF％D1％80％D0％BE％D0％B5％D0％BA％D1％82％D0％B0％20-％20モデリング、％20％D0％BA％D0％BE％D1％82％D0 ％BE％D1％80％D1％8B％D0％B9％20％D0％BF％D0％BE％D0％B7％D0％B2％D0％BE％D0％BB％D1％8F％D0％B5％D1 ％82％20％D1％80％D0％B8％D1％81％D0％BE％D0％B2％D0％B0％D1％82％D1％8C％20％D1％80％D0％B0％D0％B7 ％D0％BB％D0％B8％D1％87％D0％BD％D1％8B％D0％B5％20UML％20％D0％B4％D0％B8％D0％B0％D0％B3％D1％80％D0 ％B0％D0％BC％D0％BC％D0％B0％20％D0％B8％20％D0％BF％D1％80％D0％BE％D0％B2％D0％B5％D1％80％D1％8F ％D1％82％D1％8C％20％D0％BD％D0％B0％D0％BF％D0％B8％D1％81％D0％B0％D0％BD％D0％BD％D1％8B％D0％B5 ％20％D1％80％D0％B5％D1％88％D0％B5％D0％BD％D0％B8％D1％8F％20％D0％BD％D0％B0％20％D1％81％D0％BE ％D0％BE％D1％82％D0％B2％D0％B5％D1％82％D1％81％D1％82％D0％B2％D0％B8％D0％B5％20％D1％81％20％D0 ％BD％D0％B5％D0％BE％D0％B1％D1％85％D0％BE％D0％B4％D0％B8％D0％BC％D0％BE％20％D0％B0％D1％80％D1 ％85％D0％B8％D1％82％D0％B5％D0％BA％D1％82％D1％83％D1％80％D0％BE％D0％B9。

％0A

％D0％9F％D0％BE％D0％B7％D0％B2％D0％BE％D0％BB％D1％8F％D0％B5％D1％82％20％D0％B3％D0％B5％D0％BD ％D0％B5％D1％80％D0％B8％D1％80％D0％BE％D0％B2％D0％B0％D1％82％D1％8C％20シーケンス％20図％20％D0％BD％D0％ B0％20％D0％BE％D1％81％D0％BD％D0％BE％D0％B2％D0％B0％D0％BD％D0％B8％D0％B8％20％D0％BA％D0％BE％ D0％B4％D0％B0、％20％D0％B2％D0％B8％D0％B7％D1％83％D0％B0％D0％BB％D0％B8％D0％B7％D0％B8％D1％80 ％D0％BE％D0％B2％D0％B0％D1％82％D1％8C％20％D1％81％D0％B2％D1％8F％D0％B7％D0％B8％20％D0％B2％20 ％D0％BF％D1％80％D0％BE％D0％B5％D0％BA％D1％82％D0％B5％20％D0％BC％D0％B5％D0％B6％D0％B4％D1％83 ％20％D0％BA％D0％BE％D0％BC％D0％BF％D0％BE％D0％BD％D0％B5％D0％BD％D1％82％D0％B0％D0％BC％D0％B8 、％20％D1％81％D0％B1％D0％BE％D1％80％D0％BA％D0％B0％D0％BC％D0％B8％20％D0％B8％20％D1％81％D1％ 81％D1％8B％D0％BB％D0％BA％D0％B0％D0％BC％D0％B8％20％D0％B8％20％D1％82.％D0％B4。

％0A

％D0％9F％D1％80％D0％B8％D0％BC％D0％B5％D1％80％20Use％20case％20％D0％B4％D0％B8％D0％B0％D0％B3％D1％80 ％D0％B0％D0％BC％D0％BC％D1％8B、％20％D0％BD％D0％B0％D1％80％D0％B8％D1％81％D0％BE％D0％B2％D0％ B0％D0％BD％D0％BD％D0％BE％D0％B9％20％D0％B2％20Visual％20Studio％202010：

％0A％0A

％D0％9A％D1％80％D0％BE％D0％BC％D0％B5％20％D1％82％D0％BE％D0％B3％D0％BE、％20％D0％B4％D0％BE％ D1％81％D1％82％D1％83％D0％BF％D0％B5％D0％BD％20Visualization％20and％20Modeling％20Feature％20Pack％20（％D0％B4％D0％BB％D1％8F％20 ％D0％BF％D0％BE％D0％B4％D0％BF％D0％B8％D1％81％D1％87％D0％B8％D0％BA％D0％BE％D0％B2％20MSDN）、％20 ％D0％BA％D0％BE％D1％82％D0％BE％D1％80％D1％8B％D0％B9％20％D0％BF％D0％BE％D0％B7％D0％B2％D0％BE ％D0％BB％D1％8F％D0％B5％D1％82：

％0A

％D0％B3％D0％B5％D0％BD％D0％B5％D1％80％D0％B8％D1％80％D0％BE％D0％B2％D0％B0％D1％82％D1％8C％20 ％D0％BA％D0％BE％D0％B4％20％D0％BD％D0％B0％20％D0％B1％D0％B0％D0％B7％D0％B5％20UML％20％D0％B4％D0 ％B8％D0％B0％D0％B3％D1％80％D0％B0％D0％BC％D0％BC％20％D0％BA％D0％BB％D0％B0％D1％81％D1％81％D0 ％BE％D0％B2
％D1％81％D0％BE％D0％B7％D0％B4％D0％B0％D0％B2％D0％B0％D1％82％D1％8C％20UML％20％D0％B4％D0％B8％D0 ％B0％D0％B3％D1％80％D0％B0％D0％BC％D0％BC％D1％8B％20％D0％B8％D0％B7％20％D0％BA％D0％BE％D0％B4 ％D0％B0
％D0％B8％D0％BC％D0％BF％D0％BE％D1％80％D1％82％D0％B8％D1％80％D0％BE％D0％B2％D0％B0％D1％82％D1 ％8C％20UML％20％D0％B4％D0％B8％D0％B0％D0％B3％D1％80％D0％B0％D0％BC％D0％BC％D1％8B％20％D0％BA％D0 ％BB％D0％B0％D1％81％D1％81％D0％BE％D0％B2、％20％D0％B4％D0％B8％D0％B0％D0％B3％D1％80％D0％B0％ D0％BC％D0％BC％D1％8B％20％D0％BF％D0％BE％D1％81％D0％BB％D0％B5％D0％B4％D0％BE％D0％B2％D0％B0％ D1％82％D0％B5％D0％BB％D1％8C％D0％BD％D0％BE％D1％81％D1％82％D0％B5％D0％B9、％20％D0％B4％D0％B8 ％D0％B0％D0％B3％D1％80％D0％B0％D0％BC％D0％BC％D1％8B％20％D0％B2％D0％B0％D1％80％D0％B8％D0％B0 ％D0％BD％D1％82％D0％BE％D0％B2％20％D0％B8％D1％81％D0％BF％D0％BE％D0％BB％D1％8C％D0％B7％D0％BE ％D0％B2％D0％B0％D0％BD％D0％B8％D1％8F％20％D1％81％20XMI％202.1
％D1％81％D0％BE％D0％B7％D0％B4％D0％B0％D0％B2％D0％B0％D1％82％D1％8C％20％D0％B4％D0％B8％D0％B0 ％D0％B3％D1％80％D0％B0％D0％BC％D0％BC％D1％8B％20％D0％B7％D0％B0％D0％B2％D0％B8％D1％81％D0％B8 ％D0％BC％D0％BE％D1％81％D1％82％D0％B5％D0％B9％20％D0％B4％D0％BB％D1％8F％20ASP.NET、％20C％20％D0％ B8％20C ++％20％D0％BF％D1％80％D0％BE％D0％B5％D0％BA％D1％82％D0％BE％D0％B2
％D1％81％D0％BE％D0％B7％D0％B4％D0％B0％D0％B2％D0％B0％D1％82％D1％8C％20％D0％B8％20％D0％BF％D1 ％80％D0％BE％D0％B2％D0％B5％D1％80％D1％8F％D1％82％D1％8C％20layer％20diagrams％20％D0％B4％D0％BB％D1％8F％20C ％20％D0％B8％20C ++％20％D0％BF％D1％80％D0％BE％D0％B5％D0％BA％D1％82％D0％BE％D0％B2
％D0％BF％D0％B8％D1％81％D0％B0％D1％82％D1％8C％20％D1％81％D0％BE％D0％B1％D1％81％D1％82％D0％B2 ％D0％B5％D0％BD％D0％BD％D1％8B％D0％B5％20％D0％BF％D1％80％D0％BE％D0％B2％D0％B5％D1％80％D0％BA ％D0％B8％20％D0％B4％D0％BB％D1％8F％20layer％20diagrams

％D0％A1％D0％BA％D0％B0％D1％87％D0％B0％D1％82％D1％8C％20Visualization％20and％20Modeling％20Feature％20Pack％20％D0％BC％D0％BE％D0 ％B6％D0％BD％D0％BE％20％D0％BF％D0％BE％20％D1％81％D1％81％D1％8B％D0％BB％D0％BA％D0％B5：％20 http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

機会：

ユースケース図
配置図（トポロジー図）;
ステートチャート図;
アクティビティ図
相互作用図
シーケンス図
コラボレーション図
クラス図
コンポーネント図

スクリーンショット：

オープンソースプログラム

StarUML

機会：

UML2.0のサポート
MDA（モデル駆動型アーキテクチャ）
プラグインアーキテクチャ（COM互換言語で記述できます：C ++、Delphi、C＃、VB、...）

StarUMLは主にDelphiで記述されていますが、C / C ++、Java、Visual Basic、Delphi、JScript、VBScript、C＃、VB.NETなどの他の言語でコンポーネントを追加できます。以下にいくつかのスクリーンショットを示します。

クラス図：

ユースケース図：

ArgoUML

サポートされているチャート：

クラス
州
使用事例
アクティビティ
コラボレーション
展開
順序

機会：

9つのUML1.4図のサポート
プラットフォームに依存しない（Java 5以降）
UML1.4標準メタモデル
XMIサポート
GIF、PNG、PS、EPS、PGML、SVGにエクスポート
言語：EN、EN-GB、DE、ES、IT、RU、FR、NB、PT、ZH
OCLサポート
フォワード、リバースエンジニアリング

スクリーンショット：

すべてのUMLダイアグラムは、大きく2つのグループに分けることができ、最初のグループは一般的なダイアグラムです。一般的な図は、実際にはモデリングの主題に依存せず、主題領域、ソリューション領域などに関係なく、任意のソフトウェアプロジェクトで使用できます。

1.5.1。使用図

使用図（ユースケース図）は、システムの機能目的の最も一般的な表現です。

使用図は、モデリングの主な質問に答えることを目的としています。システムは外の世界で何をしているのでしょうか。

ユースケース図では、ユースケース1とアクター2の2種類のコアエンティティを使用しており、その間に次の基本的な関係タイプが確立されています。

アクターとユースケース3の間の関連付け。
アクター間の一般化4;
ユースケース間の一般化5;
ユースケース間の（異なるタイプの）依存関係6。

使用図には、他の図と同様に、7つのコメントが含まれる場合があります。さらに、図の読みやすさを向上させるために、これを行うことを強くお勧めします。

使用図で使用されている表記の基本要素を以下に示します。詳細な説明はセクション2.2に記載されています。

1.5.2。クラス図

クラス図（クラス図）は、システムの構造を説明する主な方法です。

UMLは主にオブジェクト指向言語であり、クラスが主要な（唯一ではないにしても）構成要素であるため、これは驚くべきことではありません。

クラス図では、1つの主要なタイプのエンティティが使用されます。クラス1（クラスの多数の特殊なケースを含む：インターフェイス、プリミティブタイプ、アソシエーションクラス、その他多数）。その間に次の基本的なタイプの関係が確立されます。

クラス2間の関連付け（多くの追加の詳細を含む）;
クラス3間の一般化。
4つのクラス間およびクラスとインターフェース間の（さまざまなタイプの）依存関係。

クラス図表記の要素のいくつかを以下に示します。詳細な説明は第3章に記載されています。

1.5.3。オートマトン図

オートマトン図（ステートマシン図）は、状態を明示的に強調表示し、状態間の遷移を記述することに基づいて、UMLの動作を詳細に記述する方法の1つです。

本質的に、オートマトン図は、その名前が示すように、状態遷移グラフ（第4章を参照）であり、多くの追加の詳細と詳細がロードされています。

オートマトン図では、1つの主要なタイプのエンティティ（状態1）と1つのタイプの関係（遷移2）が使用されますが、両方について、多くの種類、特殊なケース、および追加の指定が定義されています。導入調査にそれらすべてをリストすることは意味がありません。

オートマトン図のすべてのバリエーションの詳細な説明はセクション4.2にあり、次の図はオートマトン図で使用される表記法の基本要素のみを示しています。

1.5.4。アクティビティ図

アクティビティ図（アクティビティ図）-制御フローとデータフローの表示に基づいて動作を説明する方法。

アクティビティ図は、古き良きフローチャートに視覚的に似ている動作を説明するもう1つの方法です。ただし、オブジェクト指向アプローチと一致する最新の表記法、および最も重要なこととして、新しいセマンティックコンポーネント（ペトリネットの自由な解釈）により、UMLアクティビティ図はシステムの動作を記述するための強力なツールです。

アクティビティ図では、1つの主要なタイプのエンティティ（アクティビティ1）と1つのタイプの関係（遷移2（制御およびデータ転送））が使用されます。また、フォーク、マージ、結合、ブランチ3などの構造も使用されます。これらはエンティティに似ていますが、実際にはそうではありませんが、複数の場所の関係のいくつかの特殊なケースをグラフィカルに表現する方法を表しています。アクティビティ図要素のセマンティクスについては、第4章で詳しく説明します。アクティビティ図で使用される表記の基本要素を以下に示します。

1.5.5。シーケンス図

シーケンス図（シーケンス図）は、送信されたメッセージのシーケンスの表示に基づいてシステムの動作を説明する方法です。

シーケンス図では、1つの主要なタイプのエンティティ（相互作用する分類子1（主にクラス、コンポーネント、およびアクター）のインスタンス）と1つのタイプの関係（メッセージが交換されるリンク2）が使用されます3。メッセージを送信する方法はいくつかありますが、グラフィック表記では、関係に対応する矢印のタイプによって区別されます。

シーケンス図の重要な側面は、時間の経過を明示的に表示することです。シーケンス図では、おそらく同期図を除いて、他のタイプの図とは異なり、重要なのは要素間のグラフィック関係の存在だけでなく、図内の要素の相対位置でもあります。つまり、デフォルトでは上から下に向けられた（非表示の）時間軸があると想定され、後で送信されるメッセージは下に描画されます。

時間軸は水平方向に向けることができます。この場合、時間は左から右に流れると考えられます。

次の図は、シーケンス図で使用される表記法の基本要素を示しています。相互作用するオブジェクト自体を指定するには、標準の表記法（分類子インスタンスの名前が付いた長方形）を使用します。そこから伸びる点線をライフライン4と呼びます。これはモデル内の関係の指定ではなく、読者の目を正しい方向に導くように設計されたグラフィックの解説です。ライフラインに重ねられた細い縞の形の図も、モデル化されたエンティティの画像ではありません。これは、オブジェクトが実行オカレンス5を所有する時間間隔、つまりオブジェクトのアクティブ化が行われる時間間隔を示すグラフィック解説です。結合されたフラグメントステップ6により、シーケンス図に相互作用プロトコルのアルゴリズム的側面を反映させることができます。シーケンス図表記の詳細については、第4章を参照してください。

1.5.6。コミュニケーション図

コミュニケーション図（コミュニケーション図）-シーケンス図と意味的に同等の動作を説明する方法。

実際、これは相互作用する分類子インスタンスのメッセージ交換シーケンスの同じ説明であり、他のグラフィカルな手段でのみ表現されます。さらに、ほとんどのツールは、シーケンス図を通信図に、またはその逆に自動的に変換できます。

したがって、通信図およびシーケンス図では、1つの主要なタイプのエンティティ（相互作用する分類子1のインスタンスと1つのタイプの関係）のリンク2が使用されます。ただし、ここでは時間ではなく、特定のインスタンス間のリンクの構造に重点を置いています。

この図は、コミュニケーション図で使用される表記法の基本要素を示しています。相互作用するオブジェクト自体を指定するには、標準の表記法（分類子インスタンスの名前が付いた長方形）を使用します。協調図上の要素の相対的な位置は重要ではありません。重要なのはリンク（ほとんどの場合、関連付けのインスタンス）だけであり、それに沿ってメッセージが送信されます3。階層的な10進数は、時間の経過に伴うメッセージの順序を表示するために使用されます。

1.5.7。コンポーネント図

コンポーネント図（コンポーネント図）-シミュレートされたシステムを構成するモジュール（論理または物理）間の関係を示します。

コンポーネント図のエンティティの主なタイプは、コンポーネント1自体と、コンポーネント間の関係を示すインターフェイス2です。コンポーネント図では、次の関係が適用されます。

コンポーネントとインターフェース間の実装（コンポーネントはインターフェースを実装します）。
コンポーネントとインターフェース間の依存関係（コンポーネントはインターフェースを使用します）3。

この図は、コンポーネント図で使用される表記法の基本要素を示しています。詳細な説明は第3章に記載されています。

1.5.8。配置図

したがって、配置図では、コンポーネント図と比較して、2つのタイプのエンティティが追加されます。コンポーネント2とノード3の実装であるアーティファクト1（ノードのタイプを説明する分類子、または特定のインスタンス）、およびノード4間の関連付け関係。これは、ノードが実行時に物理的に接続されていることを示しています。

この図は、配置図で使用される表記法の基本要素を示しています。あるエンティティが別のエンティティの一部であることを示すために、「デプロイ」依存関係5が適用されるか、あるエンティティの形状が別のエンティティ6の形状の内側に配置されます。図の詳細な説明は、第3章に記載されています。

密閉