基本的なUML図。 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）プログラミング言語に依存しません。
使用されるプロジェクト開発方法に依存しません。
任意のオブジェクト指向プログラミング言語をサポートできます。

＆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モデルの説明部分です。モデルの任意の要素に対する追加の説明、説明、またはコメントのコメントです。注釈要素の基本的なタイプは、注釈の1つだけです。メモは、非公式または公式のテキストで表現された、図へのコメントまたは制約を提供するために使用されます。

UMLの関係

＆nbsp＆nbsp＆nbsp＆nbspUMLでは次の関係タイプが定義されています。 依存関係、関連付け、一般化、および実装..。これらの関係は、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これから重要な結果が得られます。 1つの同じオブジェクトのセットが異なる協同組合に参加できます。検討中の協力に応じて、個々のオブジェクトのプロパティとそれらの間の接続の両方が変わる可能性があります。これが、コラボレーション図とクラス図を区別するものです。クラス図は、図要素間のすべてのプロパティと関連付けを示す必要があります。

コンポーネント図

＆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。標準ツールバーの外観

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

ブラウザウィンドウ

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

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

図-9。ブラウザの外観

専用ツールバー

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

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

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

ダイアグラムウィンドウ

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

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

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

ドキュメントウィンドウ

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

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

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

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

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

ログウィンドウ

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

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

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

結論

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

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

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

＆nbsp＆nbsp＆nbsp＆nbsp

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

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

UML 1.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つのエンティティ間の関係。矢印の横に独立したエンティティが示されています
一般化		一般的なエンティティ（祖先、親）と特殊なエンティティ（子、子）の間の関係。三角形は親側から指定されます。関係は、同じタイプのエンティティ間でのみ示されます
実現		エンティティ間の関係。一方のエンティティが、もう一方のエンティティが実行するアクションを定義します。リレーションシップは、インターフェイスとクラス（またはコンポーネント）の間、ユースケースとコラボレーションの間の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」ステレオタイプのクラスは境界クラスです）
ガード状態（ガード状態）		ブール条件（例：または[識別が完了しました]）
制限（制約）	{ }	モデル要素のセマンティクスを制限するルール（たとえば、（実行時間10ms未満））
タグ付きの値（タグ付きの値）	{ }	表記要素の新しいプロパティまたは修飾プロパティ（例：（バージョン= 3.2））

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


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

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

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

表11.5。ダイアグラム

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

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

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

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

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

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

相互作用の概要図も同様ですが、相互作用のフラグメント（refタグが付いたフラグメント）が非表示になっています。これはコンテキスト（概念）のものであり、その要素は個別の分解図に具体化されます。

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

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

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

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

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

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

UMLは、統一モデリング言語の頭字語です。実際、これは最も人気のあるビジネスプロセスモデリング手法の1つであり、ソフトウェア開発を指定、視覚化、および文書化するための国際標準表記です。 Object Management Groupによって定義され、いくつかの追加のUML表記システムの結果として出現し、現在、ビジュアルモデリングの事実上の標準となっています。オブジェクト指向プログラミングの基本原則は、モデルの構築から始まります。

UMLは、ソフトウェア開発とドキュメント化に関する混乱から作成されました。 1990年代には、ソフトウェアシステムを表現する方法がいくつかありました。これらのシステムを表現するためのより統一された視覚的なUML方法が必要であり、その結果、RationalSoftwareで働く3人のソフトウェアエンジニアによって1994年から1996年に開発されました。その後、1997年に標準として採用され、現在も使用されていますが、更新はわずかです。

基本的に、UMLはソフトウェア開発の分野における汎用モデリング言語です。ただし、アクティビティ図など、いくつかのビジネスプロセスまたはワークフロープロセスのドキュメントに反映されるようになりました。 UMLタイプの図は、フローチャートの代わりに使用できます。これらは、ワークフローをモデル化するためのより標準化された方法と、読みやすさと効率を向上させるための幅広い機能の両方を提供します。

このアーキテクチャは、UMLを作成するための基礎を定義するメタオブジェクトに基づいています。アプリケーション全体を作成するのに十分な精度です。完全に実行可能なUMLは、ソフトウェア開発サイクル全体のすべてのプロセスでさまざまなテクノロジーを使用して、複数のプラットフォームに展開できます。

UMLは、ユーザーによるビジュアルモデリング言語の開発を目的としています。構造、テンプレート、コラボレーションなどの高レベルの設計概念をサポートします。 UMLは、次のような要素のコレクションです。

プログラミング言語ステートメント。
アクター-ユーザーまたはオブジェクトと対話するその他のシステムが果たす役割を説明します。
作業契約の履行のために実行され、図に示される活動。
一連のアクションのフローチャートによって視覚化された、顧客向けの特定のサービスを作成する一連のタスクを含むビジネスプロセス。
論理的で再利用可能なソフトウェアコンポーネント。

UML図は2つのカテゴリに分類されます。最初のタイプには、構造情報を表す7種類の図が含まれ、2番目のタイプには、一般的なタイプの動作を表す他の7種類の図が含まれます。これらの図は、システムのアーキテクチャを文書化するために使用され、UMLシステムモデリングに直接関係しています。

UMLダイアグラムは、システムモデルの静的および動的ビューとして表示されます。静的ビューには、静的構造を強調するクラスおよび複合構造図が含まれます。動的ビューは、シーケンス、アクティビティ、および状態図を使用して、オブジェクト間の相互作用とオブジェクトの内部状態の変化を表します。

IBM Rose、Rhapsody、MagicDraw、StarUML、ArgoUML、Umbrello、BOUML、PowerDesigner、Diaなど、さまざまなUMLモデリングツールを使用してモデリングを簡素化できます。

UMLは、ソフトウェア開発ドキュメントとビジネスプロセスの両方で、さまざまな方法で使用されます。

スケッチ。この場合、UMLダイアグラムは、システムのさまざまな側面と特性を伝えるために使用されます。ただし、これはシステムのトップレベルのビューにすぎず、プロジェクトを最後まで実行するために必要なすべての詳細が含まれていない可能性があります。
フォワードデザイン-スケッチのデザインは、アプリケーションをコーディングする前に行われます。これは、ユーザーが作成しようとしているシステムまたはワークフローのより良い概要を提供するためです。多くの設計上の問題や欠陥を特定できます。これにより、プロジェクトの全体的な健全性と幸福が向上します。
リバースデザイン。コードが記述されると、UMLダイアグラムは、さまざまなアクティビティ、役割、参加者、およびワークフローのドキュメントの形式として表示されます。
設計図。この場合、図は完全な構成として機能し、システムまたはソフトウェアの実際の実装のみが必要です。これは多くの場合、CASE（コンピューター支援ソフトウェアエンジニアリングツール）ツールを使用して行われます。 CASEツールを使用する主な欠点は、一定レベルの知識、ユーザートレーニング、および管理と人員が必要になることです。

UMLは、Java、C ++、Pythonのようなスタンドアロンのプログラミング言語ではありませんが、適切なツールを使用すると、疑似UMLになる可能性があります。この目標を達成するには、システム全体をさまざまな図で文書化する必要があり、適切なソフトウェアを使用して、図をコードに直接変換できます。この手法は、グラフの描画に費やす時間が実際のコードを作成するよりも時間がかからない場合にのみ役立ちます。 UMLはシステムモデリング用に作成されましたが、ビジネス分野でいくつかの用途があります。

以下は、ビジネスモデリングのUML図の例です。

実用的な解決策の1つは、アクティビティ図を通じてテレセールスのプロセスフローを視覚化することです。注文が入力として受け取られた瞬間から、注文が完了して特定の出力が与えられる瞬間まで。

UMLダイアグラムにはいくつかの種類があり、実装前または実装後に、ドキュメントの一部としてそれぞれが異なるタスクを実行します。他のすべてのタイプを含む2つの最も広いカテゴリは、動作図と構造図です。名前が示すように、一部のUMLダイアグラムは、システムまたはプロセスの構造を分析および描写しようとしますが、他のダイアグラムは、システム、その参加者、およびコンポーネントの動作を説明します。

さまざまなタイプは次のように分類されます。

システムとアーキテクチャを文書化するときに、14種類のUML図のすべてが定期的に使用されるわけではありません。
パレートの法則は、UML図の使用にも適用されます。
チャートの20％は、開発者が80％の時間使用しています。

ソフトウェア開発で最も一般的に使用される要素は次のとおりです。

使用図;
クラス図;
順序。

アクション図は、ビジネスプロセスモデルを作成するための最も重要なUML図です。ソフトウェア開発では、さまざまなアクションの流れを説明するために使用されます。それらは、順次または並列のいずれかです。それらは、アクティビティの結果として使用、消費、または生成されたオブジェクトと、さまざまなアクティビティ間の関係を表します。

上記のすべては、明確な開始と終了で相互接続されているため、相互につながるビジネスプロセスをモデル化するために重要です。ビジネス環境では、これはビジネスプロセスマッピングとも呼ばれます。主な俳優は、著者、編集者、出版社です。 UMLの例には次のものがあります。レビュー担当者がドラフトをレビューし、いくつかの変更を加える必要があると判断した場合。次に、作成者はドラフトを改訂し、概要を分析するために再度返します。

使用図

システムの基礎-システムのレベルの要件を分析するために使用されます。これらの要件は、さまざまなユースケースで表されます。 UML図の3つの主要なコンポーネントは次のとおりです。

機能的-ユースケースとして提示されます。
アクションを説明する動詞。
アクター-システムと対話します。アクターは、ユーザー、組織、または外部アプリケーションです。参加者間の関係は直線の矢印で表されます。

たとえば、在庫管理図の場合です。この場合、所有者、サプライヤー、マネージャー、在庫スペシャリスト、および在庫検査官がいます。丸いコンテナは、アクターが実行するアクションを表します。考えられるアクションには、株式の購入と支払い、株式の品質の確認、株式の返却、または配布が含まれます。

このタイプの図は、システムの参加者間の動的な動作を表示するのに非常に適しており、実装の詳細を反映せずに表示を簡素化します。

一時的

UMLタイミング図は、フォーカスが時間に依存する場合にオブジェクトの関係を表すために使用されます。同時に、オブジェクトがどのように相互作用したり、相互に変化したりするかは興味深いものではありませんが、ユーザーは、オブジェクトとサブジェクトが線形の時間軸に沿ってどのように動作するかを想像したいと考えています。

個々の参加者は、ライフラインによって表されます。ライフラインは、個々の参加者が1つのステージから次のステージに移動するときに、基本的にステージを形成する線です。焦点は、イベントの期間とそれに応じて発生する変更にあります。

タイミングチャートの主なコンポーネントは次のとおりです。

ライフラインは個人会員です。
状態のタイムライン-単一のライフパスは、プロセス内のさまざまな状態を通過できます。
期間制約-制約が満たされるのに必要な期間を表す時間間隔制約。
時間制限-参加者が何かをしなければならない時間間隔を制限します。
破壊の外観-個々の参加者を破壊し、その参加者のライフサイクルの終わりを表すメッセージの外観。

状態図とも呼ばれる水平図は、システム内のコンポーネントのさまざまな状態を説明するために使用されます。ダイアグラムは基本的に、オブジェクトの複数の状態と、内部および外部のイベントに基づいてオブジェクトがどのように変化するかを記述するマシンであるため、最終的な名前の形式を取ります。

非常に単純なマシン状態図は、チェスゲームになります。典型的なチェスゲームは、白による動きと黒による動きで構成されています。白は最初の動きを持っており、それがゲームを開始します。ゲームの終了は、白または黒のどちらが勝ったかに関係なく発生する可能性があります。ゲームは、試合、辞任、または引き分け（異なるマシン条件）で終了する可能性があります。ステートチャートは、主にさまざまなシステムの順方向および逆方向のUML設計で使用されます。

連続

このタイプの図は、コンピュータサイエンスコミュニティの間だけでなく、ビジネスアプリケーションを開発するための設計層モデルとしても最も重要なUML図です。それらは、視覚的に自明の性質があるため、ビジネスプロセスを説明するために人気があります。名前が示すように、図は、サブジェクトとオブジェクトの間で発生するメッセージと相互作用のシーケンスを示しています。アクターまたはオブジェクトは、必要な場合、または別のオブジェクトがそれらと通信したい場合にのみアクティブにできます。すべての通信は時系列で表示されます。

詳細については、以下のUMLシーケンス図の例を参照してください。

例が示すように、構造図はシステムの構造を示すために使用されます。より具体的には、言語は、システムのアーキテクチャとさまざまなコンポーネントがどのように相互接続されているかを表すためにソフトウェア開発で使用されます。

UMLクラス図は、ソフトウェアドキュメンテーションの最も一般的なタイプの図です。現在作成されているほとんどのプログラムは依然としてオブジェクト指向プログラミングパラダイムに基づいているため、ソフトウェアを文書化するためにクラス図を使用することは一般的に理にかなっています。これは、OOPがUMLクラスとそれらの間の関係に基づいているためです。簡単に言うと、チャートには、データフィールドとも呼ばれる属性、およびメンバー関数と呼ばれる動作とともに、クラスが含まれています。

具体的には、各クラスには3つのフィールドがあります。上部に名前、名前のすぐ下に属性、下部に操作/動作です。さまざまなクラス間の関係（接続線で表される）は、クラス図を構成します。上記の例は、基本的なクラス図を示しています。

オブジェクト

UML構造図について説明するときは、コンピューターサイエンスの概念を深く掘り下げる必要があります。ソフトウェア開発では、クラスは抽象データ型と見なされ、オブジェクトはインスタンスです。たとえば、一般的な抽象型である「Car」がある場合、「Car」クラスのインスタンスは「Audi」になります。

UMLオブジェクト図は、ソフトウェア開発者が、生成された抽象構造が実際に実装されたとき、つまりオブジェクトが作成されたときに実行可能な構造であるかどうかを確認するのに役立ちます。一部の開発者は、これを2次レベルの精度検証と見なしています。クラスのインスタンスを表示します。より正確には、ジェネリッククラス「Customer」には、たとえば「James」という名前の実際の顧客が含まれるようになりました。 Jamesは、より一般的なクラスのインスタンスであり、同じ属性を持ちますが、指定された値を持ちます。アカウントと普通預金口座でも同じことが行われました。それらは両方ともそれぞれのクラスのオブジェクトです。

展開

配置図は、ソフトウェアとハードウェアの関係を視覚化するために使用されます。具体的には、配置図を使用して、ソフトウェアコンポーネント（アーティファクト）がノードと呼ばれるハードウェアコンポーネントにどのように展開されるかについての物理モデルを構築できます。

Webアプリケーションの一般的な単純化された展開パターンには、次のものが含まれます。

ノード（アプリケーションサーバーとデータベースサーバー）。
アーティファクトクライアントアプリケーションスキーマとデータベース。

パッケージ図は、上で説明したUML配置図のマクロに似ています。さまざまなパッケージにノードとアーティファクトが含まれています。それらは、ダイアグラムとモデルコンポーネントをグループにグループ化します。これは、名前空間がある程度関連するさまざまな名前をカプセル化するのとよく似ています。最終的に、パッケージは、より複雑なシステムと動作を表すために、他のいくつかのパッケージによって作成することもできます。

パッケージ図の主な目的は、複雑なシステムを構成するさまざまな主要コンポーネント間の関係を示すことです。プログラマーは、この抽象化機能がパッケージ図を使用するための優れた利点であると考えています。特に、詳細を図から除外できる場合はそうです。

人生の他のことと同じように、何かを正しくするためには適切なツールが必要です。ソフトウェア、プロセス、またはシステムを文書化するには、UML注釈と図テンプレートを提供するツールを使用します。図を描くのに役立つさまざまなソフトウェアドキュメンテーションツールがあります。

それらは通常、次の主要なカテゴリに分類されます。

紙とペンは簡単です。彼らは紙とペンを取り、インターネットからUML構文コードを開き、必要なあらゆるタイプの図を描きます。
オンラインツール-グラフの作成に使用できるオンラインアプリケーションがいくつかあります。それらのほとんどは、有料サブスクリプションまたは限られた数の無料ティアチャートを提供します。
無料のオンラインツールは、有料のものとほとんど同じです。主な違いは、有料のものは特定のチャート用のチュートリアルと既製のテンプレートも提供することです。
デスクトップアプリケーションは、ダイアグラムに使用する典型的なデスクトップアプリケーションであり、他のほぼすべてのダイアグラムはMicrosoftVisioです。高度な機能を提供します。唯一の欠点は、あなたがそれを支払わなければならないということです。

したがって、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モデルの特定の予測を復元します。これは、モデルとコードの一貫性を確保し、前任者の機能を継承するシステムを設計するときに非常に重要ですシステム。

オブジェクトの作成から破壊まで、そのライフ中の1つのオブジェクトの動作を示します。各状態図は、ある種のオートマトンを表しています。

行動計画

[説明]セクションで、ダイアグラムを読み取るために必要なステートチャートシンボルの基本セットを調べます。

他のセクション（例、アプリケーション）を読んだ後、自分で状態図を描いてみることができます。

メモ（説明）

これは基本的な文字セットです 状態図図を読むことができるようにする必要があります。他のセクション（「例」、「アプリケーション」）を読んだ後、作曲できるようになります 状態図自分で！

学期	画像	説明
初期疑似状態		システムの初期状態
遷移		遷移とは、ある状態から別の状態に移行することを意味します。
州		アクターの観察結果につながる、システムによって実行されるアクション（オプションを含む場合があります）を示します。
州活動状態		ユースケースの複雑なステップは、別のユースケースで表すことができます。 UML用語では、最初のユースケースには2番目のユースケースが含まれると言います。
最終状態		システムまたはサブシステムの境界を定義できます。
内部活動		状態が遷移せずにイベントに反応できる場合。この場合、イベント、保護、およびアクティビティは状態の長方形の内側に配置されます。
入力アクティビティ		状態に入るたびに入力アクティビティが実行されます
出力アクティビティ		アクティビティの終了-状態を終了するたびに実行されます。
超国家		いくつかの州が共通の移行と内部活動を持っていることがよくあります。このような場合、それらをサブステートに変換し、一般的な動作をスーパーステートに移動できます。
並列状態		状態は、同時に実行される複数の同時状態に分割できます。

創造性のテクニックを適用する方法

UML状態図は、複数のユースケースでの単一オブジェクトの動作を説明するのに適しています。しかし、それらは多くのオブジェクトの相互作用によって特徴付けられる振る舞いを記述するのにはあまり適していません。したがって、状態図と組み合わせて他のテクノロジーを使用することは理にかなっています。たとえば、相互作用図（第4章）は、単一のユースケースでの複数のオブジェクトの動作を完全に説明し、UMLアクティビティ図は複数のユースケースで複数のオブジェクトの基本的なフローを示すのに適しています。

誰もがステートチャートを自然だと考えているわけではありません。スペシャリストがどのように協力しているかをご覧ください。チームメンバーが、ステートチャートが自分のワークスタイルに適しているとは思わない可能性があります。これは最大の困難ではありません。さまざまな作業テクニックを共有することを忘れないでください。

状態図を使用している場合は、システムのクラスごとに状態図を描画しようとしないでください。このアプローチは、正式に完全性を厳密にするためによく使用されますが、ほとんどの場合、エネルギーの浪費です。ステートチャートは、興味深い動作を示すクラスにのみ使用してください。ステートチャートを作成すると、状況を理解するのに役立ちます。

多くの専門家は UIエディターとコントロールには、ステートチャートを使用して表示するときに役立つ機能があります。

学ぶ方法

ここでは、可能な限り簡単に学習する方法を提供しようとしました。 UML状態図.

他の多くの言語と同様に、それはそれを説明するために文字のセットを使用します。これらの記号の意味は、「備考（説明）」セクションの表に記載されています。各記号には、独自の名前（用語）とスペルがあります。また、各用語には、その主な本質をすばやく理解するために簡単な説明が付いています。

さらに、「例」のセクションに進むことをお勧めします 状態図さまざまなチャートを読んでみてください。次に、「アプリケーション」のセクションを検討する価値があります。UMLの図の種類の数は少ないですが、対応する図を本来の目的に使用する場合にのみ、それらを使用することで最大のメリットを得ることができます。

使用例

ステートマシン図システムの動作を説明するためのよく知られたテクノロジーです。状態図は1960年以来、何らかの形で存在しており、オブジェクト指向プログラミングの初期には、システムの動作を表すために使用されていました。オブジェクト指向のアプローチでは、単一のクラスの状態図を描画して、その存続期間中の単一のオブジェクトの動作を示します。

彼らがステートマシンについて書くときはいつでも、クルーズコントロールシステムや自動販売機が必然的に例として引用されます。
ゴシック城の秘密のコントロールパネルコントローラーを使用することにしました。この城では、宝物を見つけにくいように隠したいと思っています。金庫の鍵にアクセスするには、燭台から戦略的なろうそくを引き出す必要がありますが、鍵はドアが閉じている場合にのみ表示されます。ロックが表示されたら、キーを挿入して金庫を開けます。セキュリティを強化するために、キャンドルを取り外した後にのみ金庫を開けることができるようにしています。泥棒がこの予防策に注意を払わない場合、私たちは泥棒を飲み込む恐ろしいモンスターを解き放ちます。

図では。 10.1ショー 状態図私の変わったセキュリティシステムを管理するコントローラークラス。状態図は、作成中のコントローラーオブジェクトの状態から始まります。 待って..。これは、図に次のように示されています。 初期疑似状態これは状態ではありませんが、初期状態を指す矢印が付いています。
この図は、コントローラーが次の3つの状態のいずれかになり得ることを示しています。待って、ロックして開く..。この図には、コントローラーがある状態から別の状態に遷移するための規則も示されています。これらのルールは、遷移（状態を結ぶ線）の形式で表示されます。

遷移とは、ある状態から別の状態に移行することを意味します。各トランジションには、次の3つの部分で構成される独自のラベルがあります。
トリガー-署名/アクティビティ..。それらはすべてオプションです。いつもの、トリガーID状態変化を引き起こす可能性がある唯一のイベントです。

保護は、指定されている場合、移行が行われるために満たされなければならないブール条件です。アクティビティは、移行中のシステムの動作です。それはどんな行動表現でもかまいません。トリガー識別子の完全な形式には、複数のイベントとパラメーターを含めることができます。待機状態（図10.1）から別の状態への遷移は、「待機状態では、ろうそくを外すと、ロックが表示され、ロック状態になります」と読み取ることができます。

遷移の説明の3つの部分はすべてオプションです。アクティビティをスキップするということは、移行中に何も起こらないことを意味します。ガードをスキップするということは、トリガーイベントが発生した場合に常に遷移が行われることを意味します。トリガー識別子が欠落することはめったにありませんが、発生します。これは、遷移がすぐに発生することを意味します。これは、主にアクティビティの状態で観察できます。

イベントが特定の状態で発生した場合、この状態から1つの遷移のみを行うことができます。たとえば、ロック状態（図10.1）では、保護は相互に排他的である必要があります。イベントが発生したが、許可された遷移がない場合（たとえば、待機状態で金庫を閉じる、ドアが開いているときにろうそくを外すなど）、イベントは無視されます。

最終状態（ 最終状態）は、ステートマシンの実行が終了したことを意味します。これにより、コントローラーオブジェクトが削除されます。そのため、不注意で罠に陥った人のために、コントローラーオブジェクトが存在しなくなったため、ウサギをケージに戻し、床を洗い、システムを再起動することを余儀なくされたと報告します。

ステートマシンは、直接観察または操作されたオブジェクトのみを表示できることに注意してください。したがって、ドアが開いているときに金庫に何かを入れたり、そこから何かを取り出したりすることを期待するかもしれませんが、コントローラーはそれについて何も言うことがないため、図にはマークを付けませんでした。

開発者がオブジェクトについて話すとき、オブジェクトの状態、つまりオブジェクトのフィールドに含まれるすべてのデータの組み合わせを指すことがよくあります。ただし、ステートマシン図の状態は、より抽象的な状態の概念です。重要なのは、状態が異なれば、イベントに反応する方法も異なるということです。

ステートチャートの内部アクティビティ

状態は、を使用して遷移をコミットせずにイベントに反応できます 内部活動 (内部活動）。この場合、イベント、保護、およびアクティビティは状態の長方形内に配置されます。

図では。 10.2は、ヘルプシステムのシンボルとイベントの内部アクティビティで状態を示します。これは、エディタのテキストフィールドで確認できます。 UI..。内部アクティビティは、自己遷移のようなものです。つまり、同じ状態に戻る遷移です。内部アクティビティの構文は、イベント、保護、および手順の同じロジックに従います。

図では。 10.2には、特別なアクティビティも表示されます。 入力および出力アクティビティ. 入力アクティビティ状態に入るたびに実行されます。 出力アクティビティ-あなたが州を去るときはいつでも。ただし、内部活動は開始されません 入力および出力アクティビティ; これが違いです 内部活動と自己遷移 .

ステートチャートのアクティビティの状態

これまでに説明した状態では、オブジェクトはサイレントであり、次のイベントを待ってから何かを実行します。ただし、オブジェクトが何らかのアクティビティを示す状態が発生する可能性があります。

州検索図で。 10.3はそのような状態です 活動状態：進行中のアクティビティは記号で示されます 行う /; したがって、用語 do-activity （アクティブになる）..。検索が完了すると、新しい機器を表示するなど、アクティビティなしで遷移が実行されます （新しいハードウェアを表示）..。キャンセルイベントの場合（ キャンセル）、それから do-activity中断するだけで、状態に戻ります ハードウェアウィンドウを更新します。

行動活動と通常の活動の両方が、何らかの行動の現れを表しています。 2つの決定的な違いは、図1に示すように、通常のアクティビティは「瞬間的」であり、通常のイベントによって中断できないことです。一方、doアクティビティは限られた時間だけ実行でき、中断できます。 10.3。瞬時性は、システムごとに異なる方法で解釈されます。リアルタイムシステムの場合、これにはいくつかのマシン命令が必要になる場合があり、デスクトップソフトウェアの場合、これには数秒かかる場合があります。

V UML 1一般的な活動は、用語で表されました アクション（アクション）と用語 アクティビティ（アクティビティ）は 行う活動.

超国家

いくつかの州が共通の移行と内部活動を持っていることがよくあります。このような場合、図に示すように、それらをサブステートに変換し、一般的な動作をスーパーステートに移動できます。 10.4。超国家がなければ、トランジションを描く必要があります キャンセル（キャンセル）州内の3つの州すべて 接続の詳細を入力します.

並列状態

状態は、同時に実行される複数の同時状態に分割できます。図では。 10.5は、CDまたはラジオのいずれかをオンにして、現在の時刻またはアラーム時刻のいずれかを表示できる単純な目覚まし時計を示しています。

CD /ラジオオプションと現在の時間/信号時間は並列です。これを非並列状態図で表現したい場合は、状態を追加する必要があるときに厄介な図になります。動作の2つの領域を2つのステートチャートに分割すると、より明確になります。

米。 10.5には 背景の状態（履歴疑似状態）。これは、時計がオンになると、ラジオ/ CDオプションが、時計がオフになったときの状態になることを意味します。先史時代から出てきた矢印は、先史時代がなかったときに最初に存在した状態を示しています。

状態図の実装

状態図は、ネストされたswitchステートメント、状態パターン、および状態テーブルの3つの主な方法で実装できます。ステートチャートを操作するための最も簡単なアプローチは、図1に示すようなネストされたswitchステートメントです。 10.6。

この方法は簡単ですが、この単純な場合でも非常に長くなります。さらに、このアプローチではコントロールを失う可能性が非常に高いため、初歩的な状況でも使用することはお勧めしません。
Stateパターンは、状態の動作を処理するための状態クラスの階層を表します。ステートチャートの各状態には、独自の状態サブクラスがあります。コントローラには、状態クラスに単純に転送する各イベントのメソッドがあります。図に示す状態図。 10.1は、図に示すクラスを使用して実装できます。 10.7。

階層の最上位は、イベントを処理するすべてのメソッドの説明を含む抽象クラスですが、実装は含まれていません。
特定の状態ごとに、状態からの遷移を開始する特定のイベントのハンドラーメソッドを書き直すだけで十分です。
状態テーブルは、状態図をデータとして表します。

だから、図の図。 10.1は表の形で提示することができます。 10.1。
次に、実行時に状態テーブルを使用するインタープリター、またはそのテーブルに基づいてクラスを生成するコードジェネレーターを構築します。

明らかに、状態テーブルでの作業のほとんどは1回で行われますが、状態の問題を解決する必要があるときはいつでも使用できます。ランタイム状態テーブルは、再コンパイルせずに変更できます。これは、いくらか便利です。状態パターンの作成は簡単で、各状態には個別のクラスが必要ですが、記述する必要のあるコードの量は非常に少なくなります。