統一されたモデリング言語の基礎。 UML図を描画するためのツール線種はuml図で使用されます

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

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

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

1.4.1。エンティティ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

チャートタイトル	タグ（標準）	タグ（推奨）
使用図	使用事例または uc	使用事例
クラス図	クラス	クラス
オートマトン図	ステートマシンまたは stm	ステートマシン
活動図	アクティビティまたは行為	アクティビティ
シーケンス図	インタラクションまたは sD	sD
コミュニケーション図	インタラクションまたは sD	通信
コンポーネント図	成分または cmp	成分
配置図	決まっていません	展開
オブジェクト図	決まっていません	オブジェクト
内部構造図	クラス	クラスまたは成分
相互作用の概要図	インタラクションまたは sD	インタラクション
同期図	インタラクションまたは sD	タイミング
パッケージ図	パッケージまたは pkg	パッケージ

すべての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の実装であるアーティファクト1とノード3（ノードのタイプを説明する分類子、または特定のインスタンスのいずれか）と、ノード4は、実行時にノードが物理的に接続されていることを示しています。

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

11.1。統合モデリング言語の構造

統合モデリング言語 （UML）は現在、オブジェクト指向システムの設計と開発の結果を記述（文書化）するための事実上の標準です。 UMLの開発は、1994年にRationalSoftwareのGradyBoochとJamesRambeauによって開始されました。 1995年の秋にIvarJacobsonが加わり、同じ年の10月にUnifiedMethodの暫定バージョン0.8がリリースされました。それ以来、UML仕様のいくつかのバージョンがリリースされており、そのうちの2つは国際標準のステータスを持っています。

UML1.4.2-「ISO / IEC 19501：2005。情報技術。オープン分散処理。統合モデリング言語（UML）。バージョン1.4.2」（eng。「情報技術。オープン分散処理。統合モデリング言語（UML）。バージョン1.4.2 "）;

UML 2.4.1- "ISO / IEC 19505-1：2012。情報技術。OMGUML。パート1.インフラストラクチャ"（eng。 "情報技術-オブジェクト管理グループ統合モデリング言語（ OMG UML）-パート1：インフラストラクチャ "）および" ISO / IEC 19505-2：2012。情報技術。統合オブジェクト管理グループモデリング言語（OMG UML）。パート2.上部構造 "（eng。"情報技術-オブジェクト管理グループ統合モデリング言語（OMG UML）-パート2：スーパーストラクチャー "）。

最新の公式言語仕様はwww.omg.orgで見つけることができます。

UMLの一般的な構造を次の図に示します。

図： 11.1。 UML構造

11.2。 UMLのセマンティクスと構文

セマンティクス -言語単位の意味を研究する言語学のセクション、まず第一に、その単語とフレーズ。

構文 -単語とその形式をフレーズや文に組み合わせる方法、文を複雑な文に組み合わせる方法、テキストの一部としてステートメントを作成する方法。

したがって、UMLに適用されるように、セマンティクスと構文は、基本的な概念（モデル要素）とそれらの拡張のメカニズムを表すために、自然言語と正式な言語を組み合わせたプレゼンテーションスタイル（モデル構築）を定義します。

11.3。 UML表記

表記法は、視覚的に表現するためのセマンティクスをグラフィカルに解釈したものです。

UMLは3つを定義します エンティティタイプ :

構造-概念的または物理的なオブジェクトを反映した抽象化。

グループ化-ダイアグラム要素のセマンティック統合に使用される要素。

説明（注釈）-ダイアグラム要素へのコメント。

次の表に、グラフィカル表記で使用される主なエンティティと、それらを表示する主な方法について簡単に説明します。

表11.1 エンティティ

タイプ	名前	指定	定義（セマンティクス）
構造	（クラス）		共通の構造と動作を持つ多くのオブジェクト
	（オブジェクト）		明確に定義された概念上の境界、個性（アイデンティティ）、状態、および動作を備えた、実際のエンティティまたは想像上のエンティティの抽象化。 UMLの観点からは、オブジェクトはクラスインスタンス（エンティティインスタンス）です。
	（俳優）	エンジニアパスサービス	システムと相互作用し、その機能を使用して特定の目標を達成したり、特定の問題を解決したりする、システム外部のエンティティ。したがって、アクターは情報の外部ソースまたはレシーバーです。
	（使用事例）		システムによって実行されるアクションの説明。これは、アクターにとって重要な結果につながります。
	（状態）		エンティティが特定の条件を満たす、何らかのアクティビティを実行する、または何らかのイベントの発生を待機する、エンティティのライフサイクルの瞬間の説明
	協力（コラボレーション）		特定の問題を解決する過程でのアクター、オブジェクト、およびそれらの相互作用の一連のインスタンスの説明
	（成分）		一貫したインターフェイスのセットの実装を提供するシステムモジュールを含む、システムの物理的な部分（ファイル）
	（インターフェース）	iCalculation	クラスまたはコンポーネントによって提供されるサービス（サービスのセット）を定義する一連の操作
	（ノード）		問題を解決するためのリソースを提供するシステムの物理的な部分（コンピューター、プリンターなど）
グループ化	（パッケージ）		要素をグループ化するための一般的なメカニズム。コンポーネントとは異なり、パッケージは純粋に概念的な（抽象的な）概念です。パッケージの特定のケースは、システムとモデルです。
	（断片）		アクターとオブジェクトインスタンス間の特定の相互作用の領域
	（アクティビティパーティション）		1つのエンティティ（アクター、オブジェクト、コンポーネント、ノードなど）によって実行される操作のグループ（責任の領域）
	（中断可能な活動領域）		非標準的な状況の結果として通常のシーケンスが中断される可能性がある操作のグループ
説明する	注意（コメント）		アイテムコメント。コメント項目に破線で添付します

一部の情報源、特に[、]も、行動エンティティを区別します 相互作用 そして 有限状態マシン、しかし論理的な観点から、それらは図として分類されるべきです。

による上記のエンティティの一部は、分解図での詳細な説明を意味します。トップレベルの図では、特別なアイコンまたはラベルでマークされています。

次の表に、すべてのタイプの説明を示します関係エンティティ間の関係を示すために図で使用されるUML。

表11.3。関係

名前	指定	定義（セマンティクス）
協会		2つ以上のエンティティ間の意味のある関係を説明する関係。最も一般的な種類の関係
集約		「部分」-「全体」の関係を説明する関連付けのサブタイプ。「部分」は「全体」とは別に存在できます。菱形は「全体」側から示されます。関係は、同じタイプのエンティティ間でのみ示されます
組成		「部分」が「全体」とは別に存在できない集約のサブタイプ。原則として、「パーツ」は「全体」と同時に作成および破棄されます
依存		1つのエンティティ（独立）の変更が別のエンティティ（依存）の状態または動作に影響を与える可能性がある2つのエンティティ間の関係。独立したエンティティは矢印の横に示されています
一般化		一般的なエンティティ（祖先、親）と特殊なエンティティ（子、子）の間の関係。三角形は親側から示されます。関係は、同じタイプのエンティティ間でのみ示されます
実現		エンティティ間の関係。1つのエンティティが、別のエンティティが実行するアクションを定義します。リレーションシップは、インターフェイスとクラス（またはコンポーネント）の間、ユースケースとコラボレーションの間の2つの場合に使用されます。矢印側は、アクション（インターフェイスまたはユースケース）を定義するエンティティを示します

関連付け、集約、構成については、 多様性 （英語の多重度）。関係に参加しているエンティティのインスタンスの総数を特徴づけます。これは通常、対応するエンティティの近くの関係の両側に示されます。多重度は、次の方法で指定できます。

-*-何も含まない任意の数のコピー。

非負の整数-多重度は厳密に固定されており、指定された数に等しくなります（例：1、2、または5）。

非負の整数の範囲「最初の数値..2番目の数値」（例：1..5、2..10、または0..5）;

特定の初期値から任意の最終的な「最初の番号.. *」までの数値の範囲（例：1 .. *、5 .. *または0 .. *）;

コンマで区切られた非負の整数と範囲のリスト（例：1、3..5、10、15 .. *）。

多重度が指定されていない場合、その値は1と見なされます。依存関係、一般化、および実装に参加しているエンティティのインスタンスの多重度は、常に1と見なされます。

次の表で説明します 拡張するメカニズム エンティティと関係のセマンティクスを明確にするために使用されます。一般に、拡張メカニズムは、括弧または引用符で囲まれたテキストの文字列です。

表11.4。拡張メカニズム

名前	指定	定義（セマンティクス）
固定観念（固定観念）	« »	表記要素のセマンティクスを指定する指定（たとえば、「include」ステレオタイプの依存関係は包含関係として扱われ、「boundary」ステレオタイプのクラスは境界クラスです）
ガード状態（ガード状態）		ブール条件（例：または[識別が完了しました]）
制限（制約）	{ }	モデル要素のセマンティクスを制限するルール（たとえば、（実行時間10ミリ秒未満））
タグ付きの値（タグ付きの値）	{ }	表記要素の新規または修飾プロパティ（例:(バージョン\u003d 3.2））

引用符で囲まれたテキストの文字列として示されるステレオタイプに加えて、グラフィカルなステレオタイプをチャートで使用できます。次の図は、標準およびステレオタイプの表示の例を示しています。


a）標準指定		b）標準指定テキストステレオタイプ		c）グラフィックステレオタイプ

図： 11.2。標準およびステレオタイプのクラス表示の例

図開発中の情報システムのいくつかの側面を表す表記要素のグループです。ダイアグラムは通常、エンティティが頂点であり、関係が円弧である接続されたグラフです。次の表に、UML図の簡単な説明を示します。

表11.5。ダイアグラム

図			予定
				物理的な実現の程度によって	ダイナミクスを表示することによって	表示されたアスペクトによって
（使用事例）			システム機能、アクターと機能間の相互作用を表示します	論理的	静的	機能的
（クラス）			クラス、インターフェイス、およびそれらの間の関係のセットを表示します	論理的または物理的	静的	機能的および情報的
（パッケージ）			パッケージのセットとそれらの間の関係を表示します	論理的または物理的	静的	成分
動作（動作）	（ステートマシン）		エンティティの状態と、そのライフサイクル中のエンティティ間の遷移を表示します	論理的	動的	行動
	（アクティビティ）		システム内のビジネスプロセスを表示します（動作アルゴリズムの説明）
	相互作用（インタラクション）	（シーケンス）	オブジェクトとアクター間でメッセージを渡すシーケンスを表示します
		（コミュニケーション）	シーケンス図に似ていますが、オブジェクト間の相互作用の構造に重点が置かれています
実装（実装）	（成分）		システムコンポーネント（プログラム、ライブラリ、テーブルなど）とそれらの間の関係を表示します	物理的	静的	成分
	（展開）		ホストごとのコンポーネントの配置とその構成を表示します

UML 2.x標準では、追加の高度に専門化された図も定義されています。

オブジェクト図も同様ですが、クラスの代わりにオブジェクトが表示されます。

タイミング図（タイミング図）-時間の経過に伴うオブジェクトの状態を記述します。

複合構造図-他のクラスと対話するためのクラスのポート（インターフェイスを含む）を記述します。

プロファイル図-それらに含まれるクラスの説明に似ています。

インタラクションの概要図も同様ですが、インタラクションフラグメント（refタグ付きのフラグメント）が非表示になっています。これは文脈的（概念的）なものであり、その要素は個別の分解図に具体化されます。

システムの内部アーキテクチャの拡大された概念表現の目的のために、構築中の大部分は、いわゆるグラフィックステレオタイプの使用を許可します。このような図は1と呼ばれますが、UML標準で定義されている図のリストには属していません。

システムの個別のモデルを開発する場合、いくつかのタイプの図が作成されます。さらに、複雑なシステムのモデルを開発する場合、原則として、同じタイプの複数の図が作成されます。同時に、これが必要でない場合は、別々のタイプの図を作成しないことも可能です。たとえば、ダイアグラムとは交換可能です。これらは、複雑な動作をするオブジェクトに対してのみ作成されます。次の表は、システムモデルごとに図を作成（改良）する必要性に関するガイダンスを示しています。

表11.6。モデルと図のリンク

この表はテストモデルを示していません。これは、その構築のフレームワーク内で図が作成されていないためですが、完全性と一貫性がチェック（テスト）されています。

構築後の図の一部は、次のモデルの開発（技術プロセス）での開発と改良が必要です。したがって、たとえば、開発中に明確にする必要があります。モデルで。

4.概念「」に定義を与えます。

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 installumletの場合

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

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

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

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

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

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

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

に 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つはコンポーネントとノードの実装であるアーティファクト（ノードのタイプを説明する分類子、または特定のインスタンスのいずれか）、およびノー\u200b\u200bド間の関連付け関係であり、そのノードを示します。実行時に物理的に接続されます。

オブジェクト図

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

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

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

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

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

同期図

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

パッケージ図

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

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

エンティティ関係モデル（ERモデル）

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

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

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

基本概念：

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

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

コミュニケーション （関係）は、複数のエンティティ間に確立された関連付けです。

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

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

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

基本的なUML概念の用語集

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

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

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

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

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

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

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

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

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

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

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

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

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

追加の読み物

ファウラーM.UML。基礎、第3版
Booch G.、Rambeau D.、Jacobson I. UML ユーザーガイド

＆nbsp＆nbsp＆nbsp＆nbsp統合モデリング言語（UML）は、ソフトウェアシステム、およびビジネスモデルやその他の非ソフトウェアシステムを指定、視覚化、構築、および文書化するための言語です。 UMLは、大規模で複雑なシステムのモデル化に以前から成功裏に使用されてきたエンジニアリング手法の融合です。

＆nbsp＆nbsp＆nbsp＆nbsp UMLの作成者は、ソフトウェアシステム、ビジネスシステム、およびその他のさまざまな性質のシステムを定義、表現、設計、および文書化するための言語としてUMLを表現します。 UMLは表記法とメタモデルを定義します。表記法は、モデルで使用されるグラフィカルオブジェクトのコレクションです。モデリング言語の構文です。

＆nbsp＆nbsp＆nbsp＆nbsp UMLは、次のようなビジュアルモデルを作成するための表現力豊かなツールを提供します。

プロジェクトに関与するすべての開発者が一律に理解している。
プロジェクト内のコミュニケーション手段です。

＆nbsp＆nbsp＆nbsp＆nbsp統合モデリング言語（UML）：

オブジェクト指向（OO）プログラミング言語に依存しません。
使用するプロジェクト開発方法に依存しません。
任意のOOプログラミング言語をサポートできます。

＆nbsp＆nbsp＆nbsp＆nbsp UMLはオープンソースであり、基盤となるコアに拡張できます。 UMLでは、さまざまなサブジェクト領域のクラス、オブジェクト、およびコンポーネントを意味のある形で記述することができます。多くの場合、互いに大きく異なります。

UML図

＆nbsp＆nbsp＆nbsp＆nbspシステム設計者が自由に使用できるRational Roseは、次のタイプの図を提供します。これらの図を順次作成すると、設計されたシステム全体とその個々のコンポーネントの全体像を把握できます。

ユースケース図（ユースケース図）;
展開図（トポロジ図）;
ステートチャート図;
相互作用図; 活動図（活動図）;
シーケンス図（一連のアクションの図）;
コラボレーション図;
クラス図（クラス図）;
コンポーネント図（コンポーネント図）;
行動図（行動図）;
活動図（活動図）;
実装図

＆nbsp＆nbsp＆nbsp＆nbspこれらの各図は、システムモデルのさまざまなビューを具体化したものです。この場合、ユースケース図はシステムの概念モデルを表しており、他のすべての図を作成するための開始点です。クラス図は、システムの構造設計の静的な側面を反映する論理モデルであり、論理モデルの一種でもある動作図は、その機能の動的な側面を反映します。実装図は、システムのコンポーネントを表し、その物理モデルを参照するために使用されます。

＆nbsp＆nbsp＆nbsp＆nbsp上記の図のうち、2つ以上の亜種を示すために使用されるものもあります。次の図は、スタンドアロンビューとして使用されます：使用例、クラス、状態、アクティビティ、シーケンス、協調、コンポーネント、および展開。

＆nbsp＆nbsp＆nbsp＆nbsp UMLダイアグラムの場合、含まれる情報の観点から重要な3種類の視覚的表記があります。

接続、平面上のさまざまな線で表されます。
テキスト個々の幾何学的形状の境界内に含まれています。
グラフィックシンボルチャートのビジュアルの近くに描かれています。

＆nbsp＆nbsp＆nbsp＆nbspダイアグラムをグラフィカルに表示する場合は、次の規則に従うことをお勧めします。

各図は、シミュレートされたドメインの一部を完全に表したものである必要があります。
図に示されているモデルエンティティは、同じ概念レベルである必要があります。
エンティティに関するすべての情報は、図に明確に表されている必要があります。
ダイアグラムに矛盾する情報を含めることはできません。
図はテキスト情報で過負荷にしないでください。
各図は、そのすべての要素を正しく解釈するために自給自足である必要があります。
特定のシステムを説明するために必要なダイアグラムタイプの数は厳密には固定されておらず、開発者によって決定されます。
システムモデルには、UML表記で定義されている要素のみを含める必要があります。

UMLのエンティティ

＆nbsp＆nbsp＆nbsp＆nbsp UMLは、次の4種類のエンティティを定義します。 構造的、行動的、グループ化および注釈..。エンティティは、モデルの作成に使用される言語の基本的なオブジェクト指向の要素です。

＆nbsp＆nbsp＆nbsp＆nbsp 構造エンティティ UMLモデルの名詞です。通常、これらは、システムの概念要素または物理要素に対応するモデルの静的部分を表します。構造エンティティの例は、「クラス」、「インターフェース」、「協調」、「ユースケース」、「コンポーネント」、「ノード」、「アクター」です。

＆nbsp＆nbsp＆nbsp＆nbsp 行動エンティティuMLモデルの動的な部分です。これらは、時間と空間におけるモデルの動作を説明する動詞です。行動エンティティには主に2つのタイプがあります。

相互作用は行動であり、その本質は特定の目標を達成するために特定のコンテキスト内のオブジェクト間でメッセージを交換することです。
オートマトンは、さまざまなイベントに応答してオブジェクトまたはインタラクションが通過する状態のシーケンスを決定する動作アルゴリズムです。

＆nbsp＆nbsp＆nbsp＆nbsp グループ化エンティティuMLモデルの編成部分です。これらは、モデルを分解できるブロックです。そのようなプライマリエンティティの単一のコピーがあります-これはパッケージです。

＆nbsp＆nbsp＆nbsp＆nbspパッケージは、アイテムをグループに編成するためのユニバーサルメカニズムです。構造、動作、およびその他のグループ化エンティティをパッケージに配置できます。プログラムの実行中に実際に存在するコンポーネントとは異なり、パッケージは純粋に概念的なものです。つまり、開発プロセス中にのみ存在します。

＆nbsp＆nbsp＆nbsp＆nbsp 注釈エンティティUMLモデルの説明部分です。モデルの任意の要素に対する追加の説明、説明、またはコメントのコメントです。注釈要素の基本的なタイプは、注釈だけです。メモは、非公式または公式のテキストで表現された、図へのコメントまたは制限を提供するために使用されます。

UMLの関係

＆nbsp＆nbsp＆nbsp＆nbsp次の関係タイプがUMLで定義されています。 依存関係、関連付け、一般化、および実装..。これらの関係は、UMLの主要な接着構造であり、エンティティを使用してモデルを構築する方法でもあります。

＆nbsp＆nbsp＆nbsp＆nbsp 依存は、2つのエンティティ間のセマンティック関係であり、一方の変更が独立していて、もう一方の依存のセマンティクスに影響を与える可能性があります。

＆nbsp＆nbsp＆nbsp＆nbsp 協会 -オブジェクト間の一連の意味的または論理的な接続を記述する構造的な関係。

＆nbsp＆nbsp＆nbsp＆nbsp 一般化 特殊な要素オブジェクト（子孫）を一般的な要素オブジェクト（祖先）に置き換えることができる関係です。同時に、オブジェクト指向プログラミングの原則に従って、子はその親（親）の構造と動作を継承します。

＆nbsp＆nbsp＆nbsp＆nbsp 実現は分類子間の意味関係であり、一方の分類子が義務を定義し、もう一方がその履行を保証します。実装関係は、次の2つの場合に発生します。

インターフェイスとそれを実装するクラスまたはコンポーネントの間。
ユースケースとそれらを実装するコラボレーションの間。

一般的なUMLメカニズム

＆nbsp＆nbsp＆nbsp＆nbsp UMLでシステムを正確に記述するために、いわゆる一般的なメカニズムが使用されます。

仕様;
追加（装飾）;
部門（共通の部門）;
拡張メカニズム。

＆nbsp＆nbsp＆nbsp＆nbspUMLはグラフィカル言語だけではありません。その表記の各グラフィック要素には仕様対応する言語構成のテキスト表現を含みます。たとえば、クラスアイコンには、その属性、操作、および動作を説明する仕様がありますが、視覚的には、図では、アイコンはこの情報のごく一部しか反映していないことがよくあります。さらに、モデルには、このクラスの別の表現が含まれている場合があり、モデルのまったく異なる側面を反映していますが、それでも仕様に対応しています。したがって、グラフィカルなUML表記を使用してシステムを視覚化し、仕様を使用してその詳細を記述します。

＆nbsp＆nbsp＆nbsp＆nbspほぼすべてのUML要素には、最も重要な特性を視覚的に表現する独自のグラフィック表現があります。エンティティ表記「クラス」には、その名前、属性、および操作が含まれています。クラス仕様には、属性と操作の可視性、コメント、またはクラスが抽象的であることの表示など、他の詳細を含めることができます。これらの詳細の多くは、グラフィックまたはテキストとしてレンダリングできます。追加クラスを表す標準の長方形に。

＆nbsp＆nbsp＆nbsp＆nbspオブジェクト指向システムをモデル化する場合、特定の分割表現されたエンティティ。

＆nbsp＆nbsp＆nbsp＆nbspまず、クラスとオブジェクトへの分割があります。クラスは抽象化であり、オブジェクトはその抽象化の具体的な実施形態です。この点で、ほとんどすべての言語構成は、クラス/オブジェクトの二重性によって特徴付けられます。したがって、ユースケースとユースケースインスタンス、コンポーネントとコンポーネントインスタンス、ノードとノードインスタンスがあります。グラフィック表現では、オブジェクトにクラスと同じ記号を使用し、名前に下線を引くのが通例です。

＆nbsp＆nbsp＆nbsp＆nbsp次に、インターフェイスとその実装に分かれています。インターフェイスはコミットメントを宣言し、実装はそれらのコミットメントの具体的な実施形態を表し、宣言されたセマンティクスが厳密に守られていることを保証します。このため、ほとんどすべてのUML構造は、インターフェース/実装の二重性を特徴としています。たとえば、ユースケースは協同組合によって実装され、操作はメソッドによって実装されます。

＆nbsp＆nbsp＆nbsp＆nbsp UMLはオープン言語です。つまり、制御された拡張機能でドメインモデルの詳細を反映できます。

＆nbsp＆nbsp＆nbsp＆nbspUML拡張メカニズムには次のものがあります。

ステレオタイプ（ステレオタイプ）-UMLの語彙を拡張し、既存の言語要素に基づいて、特定の問題を解決するための新しいものを作成できるようにします
タグ付き値-基本的なUML構造のプロパティを拡張し、要素仕様に追加情報を含めることができるようにします。
制約-UML構造のセマンティクスを拡張して、新しいルールを作成し、既存のルールをオーバーライドできるようにします。

＆nbsp＆nbsp＆nbsp＆nbspこれらの3つの言語拡張メカニズムを組み合わせることで、プロジェクトのニーズや開発テクノロジーの特性に応じて変更することができます。

ユースケース図

＆nbsp＆nbsp＆nbsp＆nbspこのタイプの図では、システムによって実行される操作のリストを作成できます。このタイプの図は、システム要件のリストがそのような図のセットに基づいて作成され、システムによって実行される機能のセットが決定されるため、機能図と呼ばれることがよくあります。

図-1。ユースケース図

＆nbsp＆nbsp＆nbsp＆nbspユースケース図は、システムの機能またはシステムが実行することになっていることを説明します。ダイアグラムの作成には、次の目標があります。

シミュレートされたドメインの一般的な境界とコンテキストを定義します。
設計されたシステムの機能的動作に関する一般的な要件を策定します。
システムの初期概念モデルを開発し、その後、論理モデルと物理モデルの形式で詳細を説明します。
システム開発者とその顧客およびユーザーとの対話のための初期ドキュメントを準備します。

＆nbsp＆nbsp＆nbsp＆nbspユースケース図の本質は次のとおりです。設計中のシステムは、ユースケースを使用してシステムと対話するエンティティまたはアクターのセットとして表されます。この場合、アクター（アクター）またはアクターは、外部からシステムと対話するエンティティです。それは、開発者自身が決定するように、モデル化されたシステムへの影響のソースとして機能できる人、技術デバイス、プログラム、またはその他のシステムである可能性があります。 使用事例 システムがアクターに提供するサービスを説明するのに役立ちます。

＆nbsp＆nbsp＆nbsp＆nbspユースケースの目的は、エンティティの内部構造を明らかにすることなく、エンティティの動作の完全な側面またはフラグメントを定義することです。このようなエンティティは、システムまたは独自の動作を持つモデルの任意の要素にすることができます。

＆nbsp＆nbsp＆nbsp＆nbsp各ユースケースは、モデル化されたエンティティがアクターの要求に応じて提供する個別のサービスに対応します。つまり、そのエンティティの使用方法を決定します。アクターの要求に応じて初期化されるサービスは、完全で分割できない一連のアクションです。これは、システムが要求の処理を終了した後、次の要求の準備をするために元の状態に戻る必要があることを意味します。

＆nbsp＆nbsp＆nbsp＆nbspユースケースは、設計されたシステムの外部要件を指定するためと、既存のシステムの機能動作を指定するための両方に使用できます。全体としての一連のユースケースは、システムの予想される動作のすべての可能な側面を定義する必要があります。さらに、ユースケースは、提供されたサービスを正しく操作できるようにするために、アクターがシステムと対話する方法を決定する要件を暗黙的に設定します。便宜上、複数のユースケースを個別のパッケージと見なすことができます。

＆nbsp＆nbsp＆nbsp＆nbsp使用例としては、顧客の現在のアカウントのステータスの確認、アイテムの購入の注文、顧客の信用度に関する追加情報の取得、モニター画面へのグラフィックフォームの表示などがあります。

クラス図

＆nbsp＆nbsp＆nbsp＆nbspオブジェクト指向プログラミングの中心は、クラス図の形式での論理システムモデルの開発です。クラス図（クラス図）は、オブジェクト指向プログラミングのクラスの用語でシステムモデルの静的構造を表すために使用されます。クラス図は、特に、オブジェクトやサブシステムなど、ドメインの個々のエンティティ間のさまざまな関係を反映し、それらの内部構造と関係のタイプを説明できます。

図-2。クラス図

＆nbsp＆nbsp＆nbsp＆nbspダイアグラムアイコンを使用すると、システム、クラス関係（クラス）、およびインターフェイス（インターフェイス）の複雑な階層を表示できます。このタイプの図は、システムオブジェクトを表示するコラボレーション図と内容が反対です。 Rational Roseを使用すると、このタイプの図をさまざまな表記で使用してクラスを作成できます。雲のように。したがって、クラスは、特定のオブジェクトが将来作成されるための単なるテンプレートです。

＆nbsp＆nbsp＆nbsp＆nbspクラス図はグラフであり、その頂点は「分類子」タイプの要素であり、さまざまなタイプの構造関係によって接続されています。クラスダイアグラムには、インターフェイス、パッケージ、リレーションシップ、さらにはオブジェクトやリレーションシップなどの個々のインスタンスを含めることもできます。

＆nbsp＆nbsp＆nbsp＆nbsp クラス（クラス） UMLでは、同じ構造、動作、および他のクラスのオブジェクトとの関係を持つオブジェクトのセットを示すために使用されます。クラスは、長方形としてグラフィカルに描かれ、さらに水平線でセクションまたはセクションに分割できます。これらのセクションには、クラス名、属性（変数）、および操作（メソッド）を含めることができます。

状態図（状態図）

＆nbsp＆nbsp＆nbsp＆nbsp UMLの各状態図は、特定のクラスの1つのインスタンスのすべての可能な状態と、ある状態から別の状態への遷移の可能なシーケンスを記述します。つまり、外部の影響への応答として、オブジェクトの状態のすべての変化をモデル化します。

＆nbsp＆nbsp＆nbsp＆nbspステートチャートは、個々のオブジェクトの動作を説明するために最も一般的に使用されますが、ユースケース、アクター、サブシステム、操作、メソッドなどの他のモデルコンポーネントの機能を指定するためにも使用できます。

図-2。状態図

＆nbsp＆nbsp＆nbsp＆nbsp状態図は、オートマトンを表す特別な種類のグラフです。グラフの頂点はオートマトンの可能な状態であり、対応するグラフィックシンボルで示され、円弧は状態から状態への遷移を示します。モデルの個々の要素をより詳細に表示するために、状態図を相互にネストすることができます。

＆nbsp＆nbsp＆nbsp＆nbspUMLメタモデル内機械は、モデル化されたエンティティの動作を、有限数の状態と遷移を持つ個別の空間として表すために必要な一連の概念を定義するパッケージです。

＆nbsp＆nbsp＆nbsp＆nbsp可能な状態のいずれかにあるシステムの期間は、ある状態から別の状態に移行するのにかかる時間を大幅に超えています。制限では、遷移時間は（特に指定されていない限り）ゼロに等しくなる可能性がある、つまり、オブジェクトの状態の変化が即座に発生する可能性があると想定されます。

＆nbsp＆nbsp＆nbsp＆nbspオートマトンの動作は、それらを接続する円弧の方向を考慮して、頂点から頂点へのグラフに沿った順次移動としてモデル化されます。

＆nbsp＆nbsp＆nbsp＆nbspマシンでは、次の前提条件が満たされている必要があります。

オブジェクトが入ることができる状態は、その現在の状態によってのみ決定され、履歴には依存しません。
各時点で、オートマトンはその状態の1つにしか存在できません。同時に、イベントが発生しない場合、オートマトンは任意の長さの時間、別の状態のままにすることができます。
オートマトンが特定の状態にある時間、および特定の状態に到達する時間は、まったく指定されていません。
オートマトンの状態の数は有限である必要があり、それらすべてを明示的に指定する必要があります。個々の疑似状態には仕様（初期状態と最終状態）がない場合があります。この場合、それらの目的とセマンティクスは、モデルのコンテキストと考慮される状態図から完全に決定されます。
オートマトングラフには、孤立した状態と遷移を含めるべきではありません。最初の状態を除いて、各状態について、前の状態を決定する必要があり、各遷移はオートマトンの2つの状態を接続する必要があります。
オブジェクトが2つ以上の後続の状態に同時に移行できる場合、オートマトンに競合する遷移が含まれていてはなりません（並列サブオートマトンの場合を除く）。 UMLでは、ガード条件を導入することで競合を回避できます。

状態 UMLメタモデルだけでなく、応用システム分析においても基本的です。動的システムの全体的な概念は、状態の概念に基づいています。 UMLの状態のセマンティクスには、いくつかの特定の機能があります。

＆nbsp＆nbsp＆nbsp＆nbsp UMLでは、状態は、特定の条件が満たされる単一の状況をモデル化するために使用される抽象的なメタクラスを指します。状態は、クラスまたはオブジェクトの属性の特定の値のセットとして指定できます。個々の属性値の変更は、モデル化されたクラスまたはオブジェクトの状態の変更を反映します。

活動図

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

＆nbsp＆nbsp＆nbsp＆nbsp実際、このタイプの図は、モデル化されたオブジェクトの状態を反映するためにも使用できますが、アクティビティ図の主な目的は、オブジェクトのビジネスプロセスを反映することです。このタイプの図では、プロセスのシーケンスだけでなく、プロセスの分岐や同期も表示できます。

＆nbsp＆nbsp＆nbsp＆nbspこのタイプの図を使用すると、ブロック図の作成に使用できるなど、あらゆる複雑なオブジェクトの動作のアルゴリズムを設計できます。

＆nbsp＆nbsp＆nbsp＆nbspアクティビティ図は、UMLで操作を実行するプロセスをモデル化するために使用されます。それらが使用するグラフィカル表記は、状態と遷移も含むという点でステートチャート表記と非常に似ています。アクティビティ図の各状態は、いくつかの基本操作の実行に対応しており、次の状態への遷移は、この操作が完了したときにのみ実行されます。

＆nbsp＆nbsp＆nbsp＆nbspしたがって、アクティビティ図は状態図の特殊なケースと見なすことができます。これらを使用すると、内部アクティビティおよびアクションの完了により、手続き型および同期制御の機能をUMLに実装できます。アクティビティ図を使用する主な方向は、実行のためのアルゴリズムを提示する必要がある場合に、クラス操作の実装機能を視覚化することです。

＆nbsp＆nbsp＆nbsp＆nbspUMLのコンテキストで アクティビティ は、マシンによって実行される個々の計算のコレクションであり、何らかの結果またはアクション（アクション）につながります。アクティビティ図には、あるアクティビティから別のアクティビティへの遷移のロジックとシーケンスが表示され、アナリストの注意は結果に集中します。アクティビティの結果は、システムの状態の変化または何らかの値の戻りにつながる可能性があります。

＆nbsp＆nbsp＆nbsp＆nbsp アクション状態 は、何らかの入力アクションがあり、少なくとも1つの遷移が状態を離れる状態の特殊なケースです。この遷移は、入力アクションがすでに完了していることを暗黙的に想定しています。アクション状態は基本的なものであるため、内部遷移を持つことはできません。アクション状態の一般的な使用法は、アルゴリズム（手順）または制御フローの実行における単一のステップをシミュレートすることです。

シーケンス図

＆nbsp＆nbsp＆nbsp＆nbsp状態とアクティビティの図を検討するとき、これらの図はシステムの動作のダイナミクスを指定するために使用されますが、時間は明示的に存在しないことに注意してください。オブジェクトの相互作用を記述する同期プロセスをモデル化する場合、動作の時間的側面が非常に重要になる可能性があります。 UMLは、シーケンスダイアグラムを使用して、時間の経過に伴うオブジェクトの相互作用をモデル化します。

＆nbsp＆nbsp＆nbsp＆nbspシーケンス図はそれらのみを示しています オブジェクト相互作用に直接関与している人。シーケンス図の重要なポイントは、時間の経過に伴うオブジェクトの相互作用のダイナミクスです。

＆nbsp＆nbsp＆nbsp＆nbsp UMLでは、シーケンス図には2つの次元があります。最初の左から右への垂直線の形式で、それぞれが相互作用に参加している個別のオブジェクトのライフラインを示しています。図の左端は、相互作用を開始するオブジェクトを示しています。右側には、最初のオブジェクトと直接相互作用する別のオブジェクトが示されています。したがって、シーケンスダイアグラム内のすべてのオブジェクトは、相互作用するときのオブジェクトのアクティビティの順序または程度によって決定される、何らかの順序を形成します。

＆nbsp＆nbsp＆nbsp＆nbspグラフィカルに、各オブジェクトは長方形として描かれ、そのライフラインの上部に配置されます。オブジェクト名とクラス名は、コロンで区切られた長方形の中に書かれています。この場合、オブジェクトの機能であるレコード全体に下線が引かれます。

＆nbsp＆nbsp＆nbsp＆nbspシーケンス図の2番目の次元は、上から下への垂直時間軸です。図の最上部は、最初の瞬間に対応しています。オブジェクトの相互作用は、あるオブジェクトから別のオブジェクトに送信されるメッセージを通じて実装されます。メッセージはメッセージ名とともに横矢印で表示され、その順序は発生時刻によって決まります。つまり、上のシーケンス図にあるメッセージは、下にあるメッセージよりも早くトリガーされます。シーケンス図は前後の相互作用の時間的順序のみをモデル化しているため、時間軸のスケールは示されていません。

コラボレーション図

＆nbsp＆nbsp＆nbsp＆nbsp協調図の主な機能は、相互作用のシーケンスだけでなく、この相互作用に関係するオブジェクト間のすべての構造的関係をグラフィカルに表す機能です。

図-3。協力の図

＆nbsp＆nbsp＆nbsp＆nbspこのタイプの図では、メッセージのシーケンスから抽象化して、オブジェクトの相互作用を説明できます。特定のオブジェクトのすべての送受信メッセージとこれらのメッセージのタイプは、このタイプの図にコンパクトな形式で反映されます。

＆nbsp＆nbsp＆nbsp＆nbspまず、長方形の形式の協調図は、オブジェクトの名前、そのクラス、および場合によっては属性値を含む、インタラクションに参加しているオブジェクトを示します。さらに、クラス図のように、オブジェクト間の関連付けは、さまざまな接続線の形式で示されます。この場合、関連付けの名前と、この関連付けでオブジェクトが果たす役割を明示的に指定できます。さらに、動的リンク-メッセージフローを描くことができます。これらは、オブジェクト間の接続線としても表され、その上に、メッセージ初期化の一般的なシーケンスの方向、メッセージ名、およびシーケンス番号を示す矢印があります。

＆nbsp＆nbsp＆nbsp＆nbspシーケンス図とは異なり、コラボレーション図は、インタラクションで特定の役割を果たすオブジェクト間の関係のみを示します。このチャートは、時間を別の次元として示していません。したがって、相互作用のシーケンスと並列ストリームは、シーケンス番号を使用して決定できます。したがって、オブジェクト間の関係をリアルタイムで明示的に指定する必要がある場合は、シーケンス図で指定するのが最適です。

＆nbsp＆nbsp＆nbsp＆nbspコンセプト コラボレーション はUMLの基本的な概念の1つです。これは、モデル化されたシステムの一般的なコンテキストで特定の目的と相互作用するオブジェクトのセットを指定するのに役立ちます。協力自体の目的は、システム内の個々の最も重要な操作の実装の機能を指定することです。協力は、この協力の参加者の相互作用の観点から、システムの動作の構造を定義します。

＆nbsp＆nbsp＆nbsp＆nbsp協力は2つのレベルで提示できます。

仕様レベル-考慮される相互作用における分類子の役割と関連付けの役割を示します。
例レベル-協力において別々の役割を形成するインスタンスと関係を示します。

＆nbsp＆nbsp＆nbsp＆nbsp BOMレベルの協力図は、相互作用に関与する要素が果たす役割を示しています。このレベルでの協力の要素はクラスと協会であり、協力の参加者間の分類者と協会の別々の役割を指定します。

＆nbsp＆nbsp＆nbsp＆nbsp例レベルの協調図は、オブジェクト（クラスインスタンス）と関係（関連付けインスタンス）のコレクションで表されます。リンクはメッセージ矢印で補足されます。このレベルでは、操作または分類子の実装に直接関連するオブジェクトのみが表示されます。この場合、分類子の役割のみが協調図に表示され、分類子自体は表示されないため、すべてのプロパティまたはすべての関連付けを記述する必要はまったくありません。したがって、分類子はそのすべてのインスタンスの完全な説明を必要としますが、分類子の役割は、特定の協力に参加するために必要なプロパティと関連付けのみの説明を必要とします。

＆nbsp＆nbsp＆nbsp＆nbspこれから重要な結果が得られます。同じオブジェクトのセットが異なる協同組合に参加できます。考慮される協力に応じて、個々のオブジェクトのプロパティとそれらの間の接続の両方が変更される可能性があります。これが、コラボレーションダイアグラムとクラスダイアグラムを区別するものです。クラスダイアグラムは、ダイアグラム要素間のすべてのプロパティと関連付けを示す必要があります。

コンポーネント図

＆nbsp＆nbsp＆nbsp＆nbspこのタイプの図は、システムの物理設計におけるコンポーネントごとのクラスとオブジェクトの分散を目的としています。このタイプの図は、ユニット図と呼ばれることがよくあります。

図-4。コンポーネント図

＆nbsp＆nbsp＆nbsp＆nbspソフトウェアシステムの完全な設計は、論理レベルと物理レベルのモデルのセットであり、互いに一貫している必要があります。 UMLは、実装図を使用して、システムのモデルを物理的に表します。 コンポーネント図 そして 展開図.

＆nbsp＆nbsp＆nbsp＆nbspコンポーネント図は、前述の図とは対照的に、システムの物理的表現の機能を説明します。これにより、ソースコードと実行可能コードであるソフトウェアコンポーネント間の依存関係を確立することにより、開発中のシステムのアーキテクチャを定義できます。コンポーネント図の主なグラフィック要素は、コンポーネント、インターフェイス、およびそれらの間の依存関係です。

＆nbsp＆nbsp＆nbsp＆nbspコンポーネント図は、次の目的で作成されています。

ソフトウェアシステムのソースコードの一般的な構造の視覚化。
ソフトウェアシステムの実行可能バージョンの仕様。
プログラムコードの個々のフラグメントの再利用を保証します。
概念的および物理的なデータベーススキーマの表現。

＆nbsp＆nbsp＆nbsp＆nbspシステムアナリスト、アーキテクト、およびプログラマーは、コンポーネント図の開発に関与しています。コンポーネント図は、プログラムコードの形式で、論理ビューからプロジェクトの特定の実装への一貫した移行を提供します。一部のコンポーネントは、プログラムコードのコンパイルの段階でのみ存在でき、その他のコンポーネントはその実行の段階で存在できます。コンポーネント図は、コンポーネント間の一般的な依存関係を反映しており、後者を分類子と見なしています。

＆nbsp＆nbsp＆nbsp＆nbsp UML言語で物理エンティティを表すために、特別な用語が使用されます- 成分..。コンポーネントは一連のインターフェースを実装し、モデルの物理的表現の要素の一般的な指定に役立ちます。コンポーネントをグラフィカルに表すために、特別な記号が使用されます。左側に2つの小さな長方形が挿入された長方形です。大きな長方形の中には、コンポーネントの名前と、必要に応じていくつかの追加情報が書かれています。このシンボルの表現は、コンポーネントに関連付けられている情報の性質に応じてわずかに異なる場合があります。

展開図

＆nbsp＆nbsp＆nbsp＆nbspこのタイプの図は、システムのハードウェア、つまりプログラムではなく「ハードウェア」を分析するように設計されています。英語からの直接翻訳では、展開は「展開」を意味しますが、「トポロジ」という用語は、このタイプの図の本質をより正確に反映しています。

図-5。展開図

＆nbsp＆nbsp＆nbsp＆nbspどのプラットフォームおよびどのコンピューティングが実装されているかについての情報がない場合、ソフトウェアシステムの物理的表現を完成させることはできません。ユーザーのコンピューター上でローカルに実行され、周辺機器やリソースを使用しないプログラムが開発されている場合は、追加の図を作成する必要はありません。企業アプリケーションを開発する場合、このような図の存在は、ネットワークの分散コンピューティングおよび通信リソースを効果的に使用したり、セキュリティを確保したりするために、コンポーネントの合理的な配置の問題を解決するのに非常に役立ちます。

＆nbsp＆nbsp＆nbsp＆nbsp展開図は、UMLの分散ソフトウェアシステムの全体的な構成とトポロジを表すように設計されています。

＆nbsp＆nbsp＆nbsp＆nbsp展開図は、実行の段階（実行時）にのみ存在するプログラムの要素とコンポーネントを視覚化するように設計されています。この場合、実行可能ファイルまたは動的ライブラリであるプログラムのコンポーネントインスタンスのみが表示されます。実行時に使用されないコンポーネントは、展開図には表示されません。したがって、プログラムのソースコードを持つコンポーネントは、コンポーネント図にのみ存在できます。それらは展開図には示されていません。

＆nbsp＆nbsp＆nbsp＆nbsp展開図には、プロセッサ、デバイス、プロセス、およびそれらの間の関係のグラフィカル表現が含まれています。論理ビュー図とは異なり、展開図は、実装の詳細を完全に反映する必要があるため、システム全体で統一されています。展開図の作成は、通常、ソフトウェアシステムモデルの仕様の最後のステップです。

＆nbsp＆nbsp＆nbsp＆nbsp展開図を作成する場合、次の目標が追求されます。

物理ノードごとにシステムコンポーネントの分布を決定します。
実行段階でのシステム実装のすべてのノード間の物理接続を示します。
システムのボトルネックを特定し、そのトポロジを再構成して、必要なパフォーマンスを実現します。

＆nbsp＆nbsp＆nbsp＆nbsp展開図は、システムアナリスト、ネットワークエンジニア、およびシステムエンジニアが共同で作成します。

RationalRoseデスクトップ機能

＆nbsp＆nbsp＆nbsp＆nbsp Rational Rose CASEツールは、よく知られているビジュアルプログラミング環境と同様に、プログラムの動作インターフェイスに対して一般的に受け入れられている標準を実装します。ユーザーのコンピューターにRationalRoseをインストールした後、初心者でもほとんど問題は発生しません。このプログラムをMS Windows 95/98環境で起動すると、画面に動作するインターフェイスが表示されます（図6）。

図-6。 RationalRoseプログラムの作業インターフェースの概観

＆nbsp＆nbsp＆nbsp＆nbsp Rational Roseの作業インターフェイスはさまざまな要素で構成されており、その主なものは次のとおりです。

プログラムのメインメニュー
ダイアグラムウィンドウ
ドキュメントウィンドウ
ブラウザウィンドウ
ログウィンドウ

これらの各要素の目的と主な機能について簡単に考えてみましょう。

プログラムのメインメニュー

プログラムのメインメニューは、一般的に受け入れられている標準で作成されており、次の形式になっています（図7）。

名前からその目的が明らかな個々のメニュー項目は、プロジェクト全体に関連する同様の操作を組み合わせたものです。一部のメニュー項目には、使い慣れた機能（プロジェクトを開く、図を出力および印刷する、クリップボードにコピーする、クリップボードからさまざまな図要素を貼り付ける）が含まれています。その他は非常に具体的であるため、学習するために追加の作業が必要になる場合があります（プログラムコードの生成、モデルの整合性のチェック、追加のモジュールの接続のオプション）。

図-7。 プログラムのメインメニューの外観

標準ツールバー

標準ツールバーはメインプログラムメニューの下にあり、次のようになります（図8）。一部のツールは利用できません（新しいプロジェクトにはアイテムがありません）。標準のツールバーを使用すると、開発者が最も頻繁に実行するメニューコマンドにすばやくアクセスできます。

図-8。 標準ツールバーの外観

ユーザーは、このパネルの外観を自由にカスタマイズできます。これを行うには、[ツール]-\u003e [オプション]メニュー項目を選択し、[ツールバー]タブを開きます。このようにして、さまざまなツールボタンを表示または非表示にしたり、サイズを変更したりできます。

ブラウザウィンドウ

デフォルトでは、ブラウザウィンドウは、標準ツールバーの下の作業インターフェイスの左側にあります（図9）。

ブラウザは、モデルビューを階層構造に編成します。これにより、ナビゲーションが簡素化され、プロジェクト内の任意のモデル要素を見つけることができます。この場合、開発者がモデルに追加した要素は、すぐにブラウザウィンドウに表示されます。したがって、ブラウザウィンドウで要素を選択すると、ダイアグラムウィンドウで要素を視覚化したり、仕様を変更したりできます。ブラウザでは、モデルアイテムをパッケージに整理したり、モデルのさまざまなビュー間でアイテムを移動したりすることもできます。必要に応じて、ブラウザウィンドウを作業インターフェイスの別の場所に配置するか、[表示]メニュー項目を使用して完全に非表示にすることができます。外枠の境界線をドラッグして、ブラウザのサイズを変更することもできます。

図-9。 ブラウザの外観

専用ツールバー

特別なツールバーは、作業インターフェースの中央にあるブラウザーウィンドウとダイアグラムウィンドウの間にあります。デフォルトでは、モデルのクラス図を作成するためのツールバーが提供されています（図10）。

図-10。 専用のクラス図ツールバーの外観

ツールバーのフレームを目的の場所に移動することで、特別なツールバーの場所を変更できます。特定のツールに対応する個々のボタンを追加または削除して、パネルの構成をカスタマイズすることもできます。ボタンの割り当ては、対応するボタン上でマウスポインタを一時停止した後に表示されるツールチップから確認できます。

ダイアグラムウィンドウ

ダイアグラムウィンドウは、そのインターフェイスの主要な作業領域であり、プロジェクトモデルのさまざまなビューが視覚化されます。デフォルトでは、ダイアグラムウィンドウは作業インターフェイスの右側にありますが、その場所とサイズも変更できます。新しいプロジェクトを開発するときに、プロジェクトウィザードを使用しなかった場合、ダイアグラムウィンドウは、モデル要素を含まない空白の領域になります（図11）。

このウィンドウにある図の名前は、プログラムのタイトルバー（プログラムの最上行）に表示されます。ウィンドウが全画面表示に最大化されていない場合は、図ウィンドウのタイトルバーに表示されます。ダイアグラムウィンドウに同時に複数のダイアグラムを表示できますが、アクティブにできるのはそのうちの1つだけです。たとえば、図では。 11、他の図がありますが、展開図はアクティブです。ダイアグラムを切り替えるには、標準ツールバーで目的のビューを選択するか、[ウィンドウ]メニュー項目を使用します。別のチャートビューをアクティブにすると、特別なツールバーの外観が変わり、特定のチャートビューに合わせて調整されます。

図-11。 モデルのさまざまなビューを含むダイアグラムウィンドウの外観

ドキュメントウィンドウ

デフォルトのドキュメントウィンドウが画面に表示されない場合があります。この場合、メニュー項目の[表示]-\u003e [ドキュメント]からアクティブにできます。その後、ブラウザの下に表示されます（図12）。

ドキュメントウィンドウは、その名前が示すように、モデルビューの要素をドキュメント化することを目的としています。あなたはそれに様々な情報を書くことができます、そして何が重要か-ロシア語で。この情報はその後コメントに変換され、プログラムコード実行のロジックに影響を与えることはありません。

ドキュメントウィンドウで、ダイアグラムの個々の選択された要素に関連する情報がアクティブになります。要素は、ブラウザウィンドウまたはダイアグラムウィンドウのいずれかで選択できます。新しい要素（クラスなど）が図に追加されると、そのドキュメントが自動的に生成されますが、空です（ドキュメントなし）。その後、開発者は必要な説明情報を独自に入力します。この情報は記憶されており、プロジェクトの作業中に変更できます。

作業インターフェイスの他のウィンドウと同様に、ドキュメントウィンドウのサイズと位置を変更できます。

図-12。 ドキュメントウィンドウの外観

ログウィンドウ

ログウィンドウは、プログラムでの作業中に生成されたさまざまなサービス情報の自動記録を目的としています。ログには、モデルの更新、メニューとツールバーのカスタマイズ、プログラムコードの生成時に発生するエラーメッセージなど、開発者のアクションの時間と性質が記録されます。

ログウィンドウは、ダイアグラムウィンドウ領域の作業インターフェイスに常に存在します（図13）。ただし、他のダイアグラムウィンドウで閉じるか、最小化することができます。ログウィンドウは、[ウィンドウ]-\u003e [ログ]メニューからアクティブにできます。この場合、作業インターフェイスの右側のペインで他のウィンドウの上に表示されます。このウィンドウを完全に削除することはできません。最小化することしかできません。

図-13。 ログウィンドウの外観

結論

＆nbsp＆nbsp＆nbsp＆nbsp時間の経過とともに、UMLは、数学者、システムアナリスト、物理学者、プログラマー、マネージャー、エコノミスト、その他の専門家がコミュニケーションを取り、専門知識を統一された形で提示できる「エスペラント」になります。結局のところ、本質的に、各スペシャリストは彼の知識の分野でモデルの概念で動作します。そして、UML言語を使用して指定できるのはこのモデルの側面です。

＆nbsp＆nbsp＆nbsp＆nbspこの点で、UML言語は知識表現言語の機能をますます獲得するため、UML言語の重要性が大幅に高まります。同時に、モデルの構造と動作を表現するための視覚的手段がUML言語に存在することにより、宣言的および手続き的知識の適切な表現を実現し、これらの形式の知識間の意味的対応を確立することが可能になります。 UMLのこれらすべての機能により、近い将来、最も深刻な見通しがあると結論付けることができます。

この記事では、ソフトウェア開発の新時代、UMLの新しい要件への影響、およびそれらを満たすためのベストプラクティスについて説明します。
＆nbsp7。「RationalRoseでのデータモデリング」SergeyTrofimov RationalRoseを使用した物理データ表現のモデリングについて説明します
＆nbsp 8.UML言語。 UMLの一般的な理解：言語の構造、グラフィック要素、および図。
＆nbsp9。実用的なUML。このドキュメントは、実用的なUMLの翻訳です。開発者のための実践的な紹介。開発者向けの実用的な紹介
＆nbsp10。「オブジェクト指向モデリングUMLの標準言語」VendrovAlexanderMikhailovich。 UMLの歴史
＆nbsp 11.UMLは統合モデリング言語です。この資料には、UMLで使用されるソフトウェアシステムと表記法を説明する方法に関する初期情報が含まれています。
＆nbsp 12.UML言語。ユーザーガイド。 Grady Booch、James Rambeau、Ivar Jacobson
＆nbsp13。「RationalRoseのUML図」SergeyTrofimov
＆nbsp 14.「分析と設計。ビジュアルモデリング（UML）RationalRose」KonstantinDomolego
＆nbsp 15. GennadyVernikovのライブラリ。設計およびモデリング標準の完全な説明。
＆nbsp16。「ソフトウェアシステムの開発でUMLを使用したドメイン記述の例」Ye.B. Zolotukhina、R.V。アルフィモフ。この記事では、Unified Modeling Language（UML）の使用に基づくドメインモデリングへの可能なアプローチの具体例を示します。