UML図はグラフィカルです。 UML図。 UML図の種類。プログラムのメインメニュー

UMLダイアグラムは、さまざまなソフトウェアの開発におけるオブジェクトモデリング用に設計された特殊なグラフィカル記述言語です。この言語は幅広いプロファイルを持ち、さまざまなグラフィカル表記法を使用してシステムの抽象的なモデルを作成するオープンスタンダードです。 UMLは、あらゆる種類のソフトウェアシステムの定義、視覚化、文書化、および設計を提供するために作成されました。 UMLダイアグラム自体はプログラミング言語ではありませんが、それに基づいて別のコードを生成する可能性を提供していることは注目に値します。

なぜそれが必要なのですか？

UMLは、あらゆる種類のソフトウェアのモデリングで終わるわけではありません。また、この言語は、今日、さまざまなビジネスプロセスのモデル化、システムエンジニアリングの実施、および組織構造の表示に積極的に使用されています。

UMLを使用すると、ソフトウェア開発者は、コンポーネント、一般化、クラス、動作、集約などの一般的な概念を表すために使用されるグラフィカルな表記法で完全な規則を適用できます。これにより、アーキテクチャと設計にさらに重点を置くことができます。

このような図にはいくつかの種類があることにも注意してください。

クラス図

UMLクラス図は、システムの構造を記述し、いくつかの異なるクラス間の属性、メソッド、および依存関係を示すように設計された静的構造図です。

使用方法に応じて、このような図の作成にはいくつかの観点があることに注意してください。

概念。この場合、UMLクラス図は特定のドメインのモデルを記述し、適用されたオブジェクトのクラスのみがその中に提供されます。
明確。この図は、さまざまな情報システムの設計プロセスで使用されます。
実装。クラス図には、プログラムコードで直接使用されるすべての種類のクラスが含まれています。

コンポーネント図

UMLコンポーネント図は、完全に静的な構造図です。これは、特定のソフトウェアシステムをさまざまな構造コンポーネントに分割し、それらの間の接続を示すことを目的としています。 UMLコンポーネント図自体は、あらゆる種類のモデル、ライブラリ、ファイル、パッケージ、実行可能ファイル、およびその他の多くの要素を使用できます。

複合/複合構造図

UML複合/複合構造図も静的構造図ですが、クラスの内部構造を示すために使用されます。可能であれば、この図は、クラスの内部構造にある要素の相互作用を示すこともできます。

それらのサブタイプは、協力のUMLダイアグラムです。これは、協力の境界内でのさまざまなクラスの相互作用だけでなく、役割を示すために使用されます。デザインパターンをモデル化する必要がある場合に非常に便利です。

UMLクラス図タイプと複合構造タイプを同時に使用できることは注目に値します。

配置図

この図は、動作中のノード、およびそれらにデプロイされたすべての種類のアーティファクトをシミュレートするために使用されます。 UML 2はアーティファクトをさまざまなノードにデプロイしますが、最初のバージョンはコンポーネントのみをデプロイします。したがって、UML配置図は、主に2番目のバージョンで使用されます。

アーティファクトとそれが実装するコンポーネントの間には、マニフェストの依存関係が形成されます。

オブジェクト図

このビューでは、特定の時点で作成されているシステムの完全または部分的なスナップショットを確認できます。特定のシステムのクラスのすべてのインスタンスを完全に表示し、それらのパラメーターの現在の値と、それらの間のリンクを示します。

パッケージ図

この図は本質的に構造的なものであり、その主な内容はすべての種類のパッケージとそれらの間の関係です。この場合、いくつかの構造図の間に厳密な分離はありません。その結果、それらの使用は、便宜上の目的でのみ発生することが多く、意味的な意味はありません。さまざまな要素が他のUML図を提供できることに注意してください（例：パッケージおよびパッケージ図自体）。

それらの使用は、特定の基準に従っていくつかの要素をグループに確実に編成するため、構造を単純化するため、およびこのシステムのモデルを使用して作業を編成するために実行されます。

アクティビティ図

UMLアクティビティ図は、特定のアクティビティをいくつかのコンポーネント部分に分解することを示しています。この場合、「アクティビティ」の概念は、並列の形式で特定の実行可能動作を指定すること、およびさまざまな従属要素の調整された順次実行を指します-ネストされたタイプのアクティビティとさまざまなアクション、特定のノードの出力を別のノードの入力に出力します。

UMLアクティビティ図は、さまざまなビジネスプロセス、並列および順次計算をモデル化するためによく使用されます。とりわけ、それらはあらゆる種類の技術的手順をシミュレートします。

オートマトン図

このビューは、UML状態図とも呼ばれます。単純な複合状態と遷移を備えた提示されたステートマシンを持っています。

ステートマシンは、特定のオブジェクトが通過する一連のさまざまな状態、またはそのライフの一部のイベントに応答する相互作用、およびそのようなイベントに対するオブジェクトの応答の仕様です。 UMLステートチャートを使用するステートマシンは、ソース要素にアタッチされ、そのインスタンスの動作を定義するために使用されます。

いわゆるドラゴンスキームは、そのような図の類似物として使用することができます。

ユースケース図

UMLのユースケース図は、アクター間で発生するすべての関係と、さまざまなユースケースを示しています。その主なタスクは、顧客、エンドユーザー、または一部の開発者が特定のシステムの動作と機能について共同で話し合うことができる本格的な手段としての地位を提供することです。

システムのモデリングプロセスでUMLユースケース図が使用されている場合、アナリストは次のことを行います。

シミュレートされたシステムをその環境から明確に分離します。
アクター、このシステムとの相互作用の方法、および期待される機能を特定します。
このシステムの機能の詳細な説明に関連するさまざまな概念を主題分野として用語集に設定します。

使用図がUMLで作成されている場合、手順は、顧客との作業時に取得されるテキストによる説明から始まります。同時に、ユースケースのモデルを作成する過程でのさまざまな非機能要件が完全に省略されており、それらのために別のドキュメントがすでに作成されていることは注目に値します。

コミュニケーション

通信図は、UMLシーケンス図と同様に推移的です。つまり、相互作用自体を表現しますが、同時にさまざまな方法でそれを示します。必要に応じて、必要な精度で1つを変換できます。別のものに。

コミュニケーション図は、複合構造のさまざまな要素間で発生する相互作用と、協力の役割を示しています。シーケンス図との主な違いは、複数の要素間の関係を明確に示しており、時間が別の次元として使用されていないことです。

このタイプは、オブジェクト図で行われるのと同じ方法で複数のオブジェクトとリンクを並べ替えるための完全に自由な形式によって区別されます。この自由形式のメッセージの順序を維持する必要がある場合は、時系列に番号が付けられます。この図の読み取りは、元のメッセージ1.0から始まり、メッセージが1つのオブジェクトから別のオブジェクトに渡される方向に続きます。

これらの図のほとんどは、シーケンス図が提供する情報とまったく同じ情報を示していますが、情報の表示方法が異なるため、ある図の特定のものは別の図よりもはるかに簡単に識別できます。また、通信図は個々の要素が相互作用する要素をより明確に示し、シーケンス図は相互作用が発生する順序をより明確に示すことにも注意してください。

シーケンス図

UMLシーケンス図は、複数のオブジェクト間の相互作用を示しています。これらのオブジェクトは、発生時刻に従って順序付けられています。この図は、複数のオブジェクト間の時系列の相互作用を示しています。特に、インタラクションに参加するすべてのオブジェクトと、それらによって交換されるメッセージの完全なシーケンスが表示されます。

この場合の主な要素は、さまざまなオブジェクトの指定、および時間の経過を示す垂直線と、特定のオブジェクトのアクティビティまたはそれによる任意の機能のパフォーマンスを提供する長方形です。

コラボレーション図

このタイプの図を使用すると、ブロードキャストメッセージのシーケンスから抽象化して、複数のオブジェクト間の相互作用を示すことができます。このタイプの図は、特定のオブジェクトのすべての送受信メッセージと、これらのメッセージの形式をコンパクトな形式で表示します。

シーケンス図と通信図は同じ手順の単なる異なるビューであるため、Rational Roseは、シーケンス図から通信図を作成したり、その逆を行ったり、完全に自動的に同期したりする機能を提供します。

相互作用の概要チャート

これらはUMLダイアグラムであり、シーケンス要素と制御フロー構造の両方を含むアクティビティ図のサブセットです。

この形式がコラボレーション図とシーケンス図を組み合わせているという事実は注目に値します。これらの図は、形成されているシステム内の複数のオブジェクト間の相互作用をさまざまな観点から検討する機会を提供します。

同期図

これは、特定の時間スケールでライフラインの状態の変化を明確に示す代替シーケンス図です。さまざまなリアルタイムアプリケーションで非常に役立ちます。

メリットは何ですか？

UML使用図と他の図を区別するいくつかの利点に注意する価値があります。

言語はオブジェクト指向であり、その結果、実行された分析と設計の結果を記述するための技術は、現代のタイプのあらゆる種類のオブジェクト指向言語のプログラミング方法に意味的に近いです。
この言語を使用すると、システムはほぼすべての可能な観点から記述でき、同様に、その動作のさまざまな側面が記述されます。
すべての図は、構文に比較的すばやく慣れた後でも、比較的読みやすくなっています。
UMLを使用すると、独自のグラフィックおよびテキストのステレオタイプを拡張したり、導入したりできます。これは、ソフトウェアエンジニアリングだけでなく、UMLの使用にも貢献します。
この言語は非常に普及しており、非常に活発に開発されています。

欠陥

UMLダイアグラムの作成には多くの利点があるという事実にもかかわらず、次の欠点について批判されることがよくあります。

冗長性。ほとんどの場合、批評家はUMLが大きすぎて複雑すぎると言い、これは不当であることがよくあります。これには、冗長または実質的に役に立たない構造や図が多数含まれています。新しいリビジョンでは「委員会によって開発された」妥協点が多いため、このような批判は最初のバージョンではなく、2番目のバージョンに当てはまります。
さまざまな意味の不正確さ。 UMLは、それ自体、英語、およびOCLの組み合わせによって定義されるため、正式な記述の手法によって正確に定義される言語に固有の剛性が不足しています。特定の状況では、OCL、UML、および英語の抽象構文が互いに矛盾し始めますが、他の場合には不完全です。言語自体の不正確な記述は、ユーザーとツールプロバイダーの両方に同様に影響を及ぼします。これは、さまざまな仕様を解釈する独自の方法により、最終的にツールの非互換性につながります。
実施と研究の過程における問題。上記の問題はすべて、UMLの導入と学習のプロセスで特定の問題を引き起こします。これは、リーダーシップがエンジニアにUMLを強制的に使用するように強制し、事前のスキルがない場合に特に当てはまります。
コードはコードを反映しています。もう1つの意見は、重要なのは美しく魅力的なモデルではなく、動作するシステム自体、つまりコードがプロジェクトであるということです。この見方に沿って、ソフトウェアを書くためのより効率的な方法を開発する必要があります。 UMLは、モデルをコンパイルして実行可能コードまたはソースコードを再生成するアプローチで高く評価されています。しかし実際には、言語にはチューリング完全性のプロパティがないため、これでは不十分な場合があり、生成される各コードは、UMLインタープリターツールが想定または定義できるものによって最終的に制限されます。
負荷の不一致。この用語は、特定のシステムの入力が別のシステムの出力を認識できないことを判断するためのシステム分析の理論に由来します。他の標準的な表記システムと同様に、UMLは、他のシステムよりも効率的かつ簡潔な方法で一部のシステムを表すことができます。したがって、開発者は、UMLや他のプログラミング言語のすべての長所を織り込むのにより快適なソリューションに傾倒しています。この問題は、開発言語がオブジェクト指向のオーソドックスな教義の基本原則に準拠していない場合、つまり、OOPの原則に従って機能しようとしない場合にさらに明白になります。
用途が広いことを試みます。 UMLは、現在利用可能なすべての処理言語との互換性を追求する汎用モデリング言語です。特定のプロジェクトのコンテキストでは、設計チームが最終的な目標を達成できるようにするために、その言語の適切な機能を選択する必要があります。さらに、特定の領域でUMLの範囲を制限するための可能な方法は、完全には定式化されていないが、それ自体が批判の対象である形式主義を通過します。

したがって、この言語の使用はすべての状況に関連するわけではありません。

UMLまたは統一モデリング言語は、ソフトウェア開発におけるオブジェクトモデリングのためのグラフィカルな記述言語です。しかし、UMLの使用はITに限定されません。UMLの実用的なアプリケーションのもう1つの大きな領域は、ビジネスプロセスモデリング、システムエンジニアリング、および組織構造のマッピングです。 UMLを使用すると、ソフトウェア開発者は、一般的な概念を表すためのグラフィック表記に同意し、設計と開発に集中することができます。

UMLの利点

UMLは、モデル化されるシステムの要素にグラフィカルシンボルを使用し、UML図は理解できるほど単純です。
UMLを使用すると、さまざまな側面を考慮して、考えられるほぼすべての観点からシステムを記述することができます。
UMLはオブジェクト指向です。その分析と構築の方法は、現代のOOP言語で使用されているプログラミング方法に意味的に近いものです。
UMLはオープンスタンダードです。この規格はバージョンからバージョンへと発展および進化し、システムの記述に関する最新の要件を満たしています。
追加のテキストおよびグラフィックタイプの導入を可能にする拡張メカニズムが含まれているため、IT分野だけでなくUMLを使用できます。

UML図の種類

UMLには14種類の図があります。それらは2つのカテゴリーに分けることができます：

構造情報構造を表す。
行動システムの動作と相互作用のさまざまな側面を表します。行動図の別の亜種が考慮されます 相互作用図.

UMLダイアグラムタイプ階層、
クラス図で表される

構造図

クラス図オブジェクト指向モデリングの重要な要素です。この図の助けを借りて（実際には、 クラス、彼らの属性, メソッドおよびクラス間の依存関係）は、ドメインモデルとモデル化されたシステムの構造を記述します。
コンポーネント図プログラムコードの内訳を大きなブロック（構造コンポーネント）に表示し、 依存関係それらの間の。コンポーネントには、パッケージ、モジュール、ライブラリ、ファイルなどがあります。
オブジェクト図は、特定の時点でのモデル化されたシステムの完全または部分的なスライスを示しています。これは、クラスインスタンス（オブジェクト）、それらの状態（現在の属性値）、およびそれらの間の関係を表します。
複合構造図クラスの内部構造と、可能であれば、この構造の要素間の相互作用を示します。
パッケージ図パッケージとそれらの間の関係を示します。このタイプの図は、モデルの要素を特定の基準に従ってグループに結合することにより、モデルの構造を単純化する（したがって、モデルを操作する）のに役立ちます。
配置図ソフトウェアコンポーネントの展開をシミュレートします（ アーティファクト）コンピューティングリソース/ハードウェアコンポーネント（ ノード).
プロファイル図は、UMLをさまざまなドメインや業界に合わせて調整できるようにする拡張メカニズムについて説明しています。

UMLクラス図の例

行動図

アクティビティ図アクションを表示します（行動）そのうちのいくつかの活動（ アクティビティ）。アクティビティ図は、ビジネスプロセス、ワークフロー、シーケンシャルおよび並列コンピューティングをモデル化するために使用されます。
ユースケース図（また ユースケース図）は、アクター（キャラクター）とモデル化されたシステムのユースケース（その機能）との関係を説明します。ダイアグラムの主な目的は、顧客、開発者、およびエンドユーザーがシステム（その機能と動作）について共同で話し合うためのワンストップショップになることです。
状態図エンティティの動的な動作を示し、現在の状態に応じて、このエンティティがさまざまなイベントにどのように反応するかを示します。これは本質的に原子理論からの状態図です。
コミュニケーション図（以前のバージョンでは 協力図）は、複合構造のパーツ間の相互作用とコラボレーションの役割を示しています。この図は、要素（オブジェクト）間の関係を明確に示しています。
シーケンス図オブジェクトの相互作用のシーケンスを視覚化するために使用されます。特定のオブジェクトのライフサイクルと、ユースケース内のアクター（アクター）の相互作用、それらが交換するメッセージのシーケンスを示します。
インタラクション概要チャートシーケンス図と制御フロー構造の一部が含まれています。さまざまな観点からオブジェクトの相互作用を検討するのに役立ちます。
同期図-タイミングに特化した、相互作用図の別のサブタイプ。この種の図は、特定の期間におけるオブジェクトの動作を調査するために使用されます。

UMLは現在、ソフトウェアシステムのビジュアルモデリングの標準表記であり、1997年の秋にオブジェクト管理グループ（OMG）によって採用され、多くのオブジェクト指向CASE製品によってサポートされています。

UML標準は、モデリング用に次の一連の図を提供します。

・ユースケース図-組織または企業のビジネスプロセスをモデル化し、作成される情報システムの要件を決定するため。

・クラス図（クラス図）-システムのクラスの静的構造とそれらの間の接続をモデル化するため。

行動図

・相互作用図;

・シーケンス図-単一のユースケース内でオブジェクト間でメッセージを交換するプロセスをシミュレートします。

・コラボレーション図-1つのユースケース内のオブジェクト間のメッセージングプロセスをモデル化するため。

・ステートチャート図-1つの状態から別の状態への移行中のシステムオブジェクトの動作をモデル化するため。

・アクティビティ図-さまざまなユースケースのフレームワークでシステムの動作をモデル化するため、またはアクティビティをモデル化するため。

実装図：

コンポーネント図-情報システムのコンポーネント（サブシステム）の階層をモデル化するため。

・配置図-設計された情報システムの物理アーキテクチャをモデル化します。

図では。 1.1は、このコースプロジェクトで開発する必要のある基本的な図を含む、情報システムの統合モデルを示しています。

米。 1.UML言語の表記法における情報システムの統合モデル

4.2. ユースケース図

ユースケースは、外部オブジェクト（アクター）によってトリガーされたイベントに応答してシステムによって実行される一連のアクションです。ユースケースでは、ユーザーとシステム間の一般的な相互作用について説明します。最も単純なケースでは、ユースケースは、ユーザーが特定の情報システムに実装したい機能についてユーザーと話し合うことによって決定されます。 UMLでは、ユースケースは次のように表されます。

図2。使用事例

アクターは、システムに関連してユーザーが果たす役割です。アクターは役割を表し、特定の人物や役職ではありません。ユースケース図では定型化された人物として描かれていますが、アクターは、システムからの情報を必要とする外部情報システムである場合もあります。いくつかのユースケースが本当に必要な場合にのみ、ダイアグラムにアクターを表示します。 UMLでは、アクターは図形として表されます。

図3。俳優（俳優）

アクターには主に3つのタイプがあります。

・ユーザー;

・システム;

・これと相互作用する他のシステム。

システム内のイベントの起動がそれに依存している場合、時間はアクターになります。

4.2.1. ユースケースとアクターの関係

UMLでは、ユースケース図は図要素間のいくつかのタイプの関係をサポートします。

コミュニケーション、

包含（含む）、

拡張（拡張）、

一般化。

通信リンクユースケースとアクターの関係です。 UMLでは、通信リンクは一方向の関連付け（実線）を使用して表示されます。

図4。通信リンクの例

包含リンク複数のユースケースで繰り返されるシステム動作の一部がある状況に適用されます。これらのリンクは通常、再利用可能な関数をモデル化するために使用されます。

拡張リンクシステムの通常の動作の変化を説明するために使用されます。これにより、あるユースケースで必要に応じて別のユースケースの機能を使用できるようになります。

図5。インクルージョンとエクステンションの接続例

一般化リンク複数のアクターまたはクラスが共通のプロパティを持っていることを示します。

図6。一般化リンクの例

4.3.

相互作用図オブジェクトの相互作用するグループの動作を説明します。通常、相互作用図は、1つのユースケース内のオブジェクトの動作をカバーします。このような図には、多数のオブジェクトと、それらが相互に交換するメッセージが表示されます。

メッセージ送信者オブジェクトが受信者オブジェクトにその操作の1つを実行するように要求する手段です。

有益なメッセージ受信者オブジェクトにその状態を更新するための情報を提供するメッセージです。

リクエストメッセージ（質問）受信者オブジェクトに関する情報の発行を要求するメッセージです。

命令メッセージ受信者に何らかのアクションを実行するように求めるメッセージです。

相互作用図には、シーケンス図とコラボレーション図の2種類があります。

4.3.1. シーケンス図

シーケンス図単一のユースケース内で発生するイベントのフローを反映します。

特定のシナリオ（ユースケース）に関係するすべてのアクター（アクター、クラス、またはオブジェクト）が図の上部に表示されます。矢印は、必要な機能を実行するために、アクターとオブジェクト間、またはオブジェクト間で渡されるメッセージに対応しています。

シーケンス図では、オブジェクトは長方形として描画され、垂直の破線が下向きに描画されます。この行はと呼ばれます オブジェクトのライフライン ..。これは、相互作用の過程におけるオブジェクトのライフサイクルの断片です。

各メッセージは、2つのオブジェクトのライフライン間の矢印として表されます。メッセージは、ページに表示されている順序で上から下に表示されます。各メッセージには、少なくともメッセージ名がタグ付けされています。オプションで、引数といくつかの制御情報を追加することもできます。自己委任（オブジェクトがそれ自体に送信するメッセージ）を表示できます。メッセージの矢印は同じライフラインを指しています。

米。 7.シーケンス図の例

4.3.2. コラボレーション図

協力図特定のシナリオ（ユースケース）内のイベントのフローを表示します。メッセージは時間順に並べられていますが、コラボレーション図はオブジェクト間の関係に重点を置いています。コラボレーション図は、シーケンス図に含まれるすべての情報を表しますが、コラボレーション図はイベントのフローを異なる方法で記述します。オブジェクト間に存在する接続を理解しやすくなります。

コラボレーション図では、シーケンス図のように、矢印は特定のユースケースで交換されるメッセージを示します。それらの時系列は、メッセージの番号付けによって示されます。

米。 8.協力図の例

4.4. クラス図

4.4.1. 一般情報

クラス図システムのクラスのタイプと、それらの間に存在するさまざまな種類の静的リンクを定義します。クラス図には、クラス属性、クラス操作、およびクラス間の関係に適用される制約も示されています。

UMLクラス図はグラフであり、そのノードはプロジェクトの静的構造の要素（クラス、インターフェイス）であり、アークはノード間の関係（関連付け、継承、依存関係）です。

クラス図は、次の要素を示しています。

・パッケージ-相互に論理的に関連するモデル要素のセット。

・クラス-類似したオブジェクトのグループの一般的なプロパティの説明。

・インターフェイスは、このインターフェイスに関連付けられた任意のクラスのオブジェクトが他のオブジェクトに提供する一連の操作を定義する抽象クラスです。

4.4.2. クラス

クラスは、同様のプロパティ、つまりデータと動作を持つエンティティ（オブジェクト）のグループです。クラスの個々の代表は、クラスオブジェクト、または単にオブジェクトと呼ばれます。

UMLでのオブジェクトの動作は、オブジェクトと外界およびオブジェクト自体のデータとの相互作用に関する規則として理解されます。

図では、クラスは実線の境界線を持つ長方形として表され、水平線で3つのセクションに分割されています。

上部のセクション（名前セクション）には、クラス名とその他の一般的なプロパティ（特に、ステレオタイプ）が含まれています。

中央のセクションには、属性のリストが含まれています

下部には、その動作（クラスによって実行されるアクション）を反映するクラス操作のリストがあります。

属性と操作のセクションのいずれかが表示されない場合があります（同時に両方も表示されない場合があります）。欠落しているセクションの場合、分割線を引く必要はなく、その中の要素の有無を何らかの方法で示します。

例外などの追加のセクションは、特定の実装の裁量で導入される場合があります。

米。 9.クラス図の例

4.4.2.1.クラスのステレオタイプ

クラスステレオタイプは、クラスを分類するためのメカニズムです。

UMLで定義されている主なクラスのステレオタイプは3つあります。

境界

実在物

コントロール。

4.4.2.2.境界クラス

境界クラスは、システムと環境全体の境界にあるクラスです。これらは、ディスプレイ、レポート、ハードウェア（プリンターやスキャナーなど）とのインターフェース、および他のシステムとのインターフェースです。

境界クラスを見つけるには、ユースケース図を調べる必要があります。アクターとユースケースの間のすべての相互作用には、少なくとも1つの境界クラスが必要です。アクターがシステムと対話できるようにするのはこのクラスです。

4.4.2.3.エンティティクラス

エンティティクラスには、保存された情報が含まれています。これらはユーザーにとって最も重要であるため、名前にサブジェクト領域の用語を使用することがよくあります。通常、エンティティクラスごとに、データベースにテーブルが作成されます。

4.4.2.4.コントロールクラス

コントロールクラスは、他のクラスのアクションを調整する責任があります。通常、各ユースケースには、そのユースケースのイベントのシーケンスを制御する1つの制御クラスがあります。制御クラスは調整を担当しますが、他のクラスは多くのメッセージを送信しないため、それ自体は機能を実行しません。代わりに、彼は自分で多くのメッセージを送信します。マネージャークラスは、単に他のクラスに責任を委任するだけです。このため、マネージャークラスと呼ばれることがよくあります。

システムには、複数のユースケースに共通する他の制御クラスが存在する場合があります。たとえば、セキュリティイベントの監視を担当するSecurityManagerクラスが存在する場合があります。 TransactionManagerクラスは、データベーストランザクションに関連するメッセージの調整を担当します。リソース共有、分散データ処理、エラー処理など、システムの操作の他の要素を処理する他のマネージャーがいる場合があります。

上記のステレオタイプに加えて、独自のステレオタイプを作成できます。

4.4.2.5.属性

属性は、クラスに関連付けられた情報の一部です。属性は、カプセル化されたクラスデータを格納します。

属性はクラス内に含まれているため、他のクラスからは隠されています。したがって、属性の読み取りと変更を許可するクラスを指定する必要がある場合があります。このプロパティは、属性の可視性と呼ばれます。

属性は、このパラメーターに対して4つの可能な値を持つことができます：

パブリック（一般、オープン）。この可視性の値は、属性が他のすべてのクラスに表示されることを前提としています。どのクラスでも、属性の値を表示または変更できます。 UML表記では、共通属性の前に「+」記号が付きます。

プライベート（クローズド、シークレット）。対応する属性は、他のクラスには表示されません。プライベート属性は、UML表記に従って「-」で示されます。

保護されていますこのような属性は、クラス自体とその子孫のみが使用できます。保護された属性のUML表記は、「＃」記号です。

パッケージまたは実装この属性は汎用であると想定していますが、そのパッケージ内にのみ存在します。このタイプの可視性は、特別なアイコンで示されません。

クローズ性またはセキュリティの助けを借りて、属性の値がシステムのすべてのクラスによって変更される状況を回避することが可能です。代わりに、属性を変更するためのロジックは、属性自体と同じクラスにラップされます。設定した可視性パラメーターは、生成されるコードに影響します。

4.4.2.6.オペレーション

操作はクラス固有の動作を実装します。操作には、名前、パラメーター、戻り値の3つの部分があります。

パラメータは、「入力」操作によって受け取られる引数です。戻りタイプは、操作のアクションの結果を参照します。

クラス図では、操作の名前と操作の名前の両方を、パラメーターと戻り値とともに表示できます。ダイアグラムの作業負荷を軽減するには、一部の操作の名前と、その他の操作の完全な署名のみを表示すると便利です。

UMLでは、操作の表記は次のとおりです。

操作名（引数：引数のデータ型、引数2：引数2のデータ型、...）：戻り値の型

考慮すべきトランザクションには、次の4つのタイプがあります。

実装操作;

制御操作;

アクセス操作;

補助操作。

実装操作

実装者の操作は、いくつかのビジネス機能を実装します。このような操作は、相互作用図を調べることで見つけることができます。このタイプの図はビジネス機能に焦点を合わせており、図の各メッセージは実装操作に関連付けられている可能性があります。

各実装ステップは、対応する要件まで簡単に追跡できる必要があります。これは、シミュレーションのさまざまな段階で実現されます。アクティビティはインタラクション図のメッセージから派生し、メッセージはユースケースに基づいて生成されたイベントフローの詳細な説明から派生し、後者は要件から派生します。このチェーン全体をトレースする機能により、すべての要件がコードに実装され、すべてのコードが要件を実装することが保証されます。

制御操作

Managerの操作は、オブジェクトの作成と破棄を制御します。クラスコンストラクタとデストラクタはこのカテゴリに分類されます。

アクセス操作

属性は通常、プライベートまたは保護されています。ただし、他のクラスでは、値を表示または変更する必要がある場合があります。これにはアクセス操作があります。このアプローチにより、属性をクラス内に安全にカプセル化し、他のクラスから属性を保護しながら、属性へのアクセスを制御することができます。クラス属性ごとにGetおよびSet操作を作成するのが標準的な方法です。

補助操作

ヘルパー操作は、その責任を果たすために必要であるが、他のクラスは何も知らないはずのクラスの操作です。これらは、クラスのプライベートで保護された操作です。

トランザクションを識別するには、次の手順に従います。

1.シーケンス図と協調図を調べます。これらの図のメッセージのほとんどは、実装アクティビティです。リフレクティブメッセージは補助操作になります。

2.制御操作を検討します。コンストラクタとデストラクタを追加する必要がある場合があります。

3.アクセス操作を検討します。他のクラスが処理する必要があるクラス属性ごとに、GetおよびSet操作を作成する必要があります。

4.4.2.7.接続

関係は、クラス間の意味関係です。これにより、クラスは別のクラスの属性、操作、および関係について学習できます。つまり、あるクラスがシーケンス図または協調図で別のクラスにメッセージを送信できるようにするには、2つの間に関係がなければなりません。

クラス間で確立できる関係には、関連付け、依存関係、集約、および一般化の4つのタイプがあります。

コミュニケーション協会

アソシエーションは、クラス間のセマンティックリンクです。それらはクラス図に通常の線として描かれています。

米。 10.コミュニケーション協会

アソシエーションは、例のように双方向にすることも、単方向にすることもできます。 UMLでは、双方向の関連付けは、矢印のない、または両側に矢印がある単純な線として描画されます。一方向の関連付けでは、その方向を示す1つの矢印のみが示されます。

関連付けの方向は、シーケンス図と協調図を調べることで判断できます。それらへのすべてのメッセージが1つのクラスによってのみ送信され、別のクラスによってのみ受信されるが、その逆の場合は、これらのクラス間で一方向の関係が発生します。少なくとも1つのメッセージが反対方向に送信される場合、関連付けは双方向である必要があります。

関連付けは反映することができます。反射的関連付けは、クラスの1つのインスタンスが同じクラスの他のインスタンスと相互作用することを前提としています。

コミュニケーション依存症

依存関係もクラス間の関係を反映しますが、それらは常に一方向であり、一方のクラスがもう一方のクラスで行われた定義に依存していることを示しています。たとえば、クラスAはクラスBのメソッドを使用します。次に、クラスBが変更された場合、クラスAで対応する変更を行う必要があります。

依存関係は、2つのグラフ要素間の破線として表され、矢印の端に固定された要素は、その矢印の先頭に固定された要素に依存していると見なされます。

米。 11.コミュニケーション依存症

これらのクラスのコードを生成する場合、新しい属性は追加されません。ただし、通信をサポートするために必要な言語固有のステートメントが生成されます。

リンクアグリゲーション

集約は、より緊密な関連付けの形式です。集約とは、全体とその一部の間の接続です。たとえば、Carのクラスだけでなく、Engine、Tiresのクラス、および車の他の部分のクラスがあるとします。その結果、Carクラスのオブジェクトは、Engineクラスのオブジェクト、Tiresの4つのオブジェクトなどで構成されます。集合体は、クラス全体のひし形の線として視覚化されます。

米。 11.コミュニケーションの集約

単純な集約に加えて、UMLは構成と呼ばれるより強力な形式の集約を導入します。構成によれば、オブジェクトパーツは単一の全体にのみ属することができ、さらに、原則として、パーツのライフサイクルは全体のサイクルと一致します。つまり、パーツはそれとともに生きて死にます。全体の除去は、その部分にまで及びます。

このカスケード削除は、集約の定義の一部と見なされることがよくありますが、役割の多重度が1..1の場合は常に暗示されます。たとえば、顧客を削除する必要がある場合、この削除は注文（さらには注文明細）に適用する必要があります。

オブジェクトの作成から破壊まで、そのライフ中の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つの決定的な違いは、図に示すように、通常のアクティビティは「瞬間的」であり、通常のイベントによって中断できないことです。一方、実行アクティビティは限られた時間だけ実行でき、中断できます。 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回で行われますが、状態の問題を解決する必要があるときはいつでも使用できます。ランタイム状態テーブルは、再コンパイルせずに変更できます。これは、いくらか便利です。状態パターンの作成は簡単で、各状態には個別のクラスが必要ですが、記述する必要のあるコードの量は非常に少なくなります。

与えられた実装は実質的に最小限ですが、それらは使用方法のアイデアを与えます 状態図..。いずれの場合も、状態モデルの実装はかなりステレオタイプ化されたプログラムにつながるため、通常、このために何らかの形式のコード生成に頼るのが最善です。

サイトニュースを購読すると、サイトの右側の列に購読フォームがあります。

プロとしてフリーランスを学びたい方は、コース「」にご招待します。

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

密閉