UML図。 UML：理論から実践までuml図の形式での設計ソリューションの表現

5.4。 オブジェクトダイアグラムエッセンシャル：オブジェクトとそれらの関係オブジェクトダイアグラムは、論理システム設計における既存のオブジェクトとそれらの関係を示します。 言い換えると、オブジェクトダイアグラムは、ある構成でのイベントのフローのスナップショットです。

5.7。 プロセス図。 重要：プロセッサ、デバイス、および接続プロセス図は、物理システム設計におけるプロセッサ間のプロセスの分散を示すために使用されます。 別のプロセス図は、プロセス構造の1つのビューを示しています

10.4。 UML図10.4.1。 視覚図の種類UMLUMLを使用すると、いくつかの種類の視覚図を作成できます。 シーケンス図; 協調チャート; クラス図; 状態図; チャート

1.2.6。 ワイヤーフレーム図 1.2.26は、ワイヤーフレーム図と呼ばれる境界ボックスのある分解図の典型的な例を示しています。 図： 1.2.26。 ワイヤーフレームを使用した分解図の例ワイヤーフレームには、ヘッダー（フレームの上部）とフッター（下部）が含まれています。

タイミング図入力電圧と出力電圧のタイミング図を取得するには、入力ファイルを少し変更する必要があります。 前の例のように、正弦波の入力電圧が使用されます。Vi1 0 sin（0 0.5V 5kHz）過渡解析とともに

チャートとグラフ無限の一連の数字の背後にある意味を識別できるのは専門家だけですが、誰もがヒストグラムまたは円グラフを理解できます（または少なくとも理解していると宣言できます）。 VBAにはチャートツールが組み込まれていませんが、

5.1.14。 チャートチャートは、数値テーブルデータをグラフィカルに表現したものです。 Pagesには、列、積み上げ列、棒、積み上げ棒、線、面積、積み上げ面積など、いくつかの種類のグラフがあります。

5.2.8。 チャートチャートは、選択した範囲のデータをグラフィカルに表現したものです。チャートを作成するには、以下のアルゴリズムに従います。1。 計算値のテーブルを作成します。2。 必要な範囲を選択します（隣接していない長方形で構成できます）

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列目には合理的な代替案が含まれています。

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

統合モデリング言語 （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。 拡張メカニズム

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

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

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

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

表11.5。 ダイアグラム

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

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

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

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

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

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

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

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

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

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

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

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

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.0メッセージから始まり、メッセージが1つのオブジェクトから別のオブジェクトに渡される方向に続きます。

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

シーケンス図

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

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

コラボレーション図

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

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

相互作用の概要チャート

これらはUMLダイアグラムであり、アクティビティダイアグラムの一種であり、シーケンス要素と制御フロー構造の両方が含まれています。

この形式は、コラボレーション図とシーケンス図を組み合わせたものであり、システム内の複数のオブジェクト間の相互作用をさまざまな観点から検討する機会を提供します。

同期図

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

メリットは何ですか？

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

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

短所

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア開発で最も一般的に使用される要素：

• 使用図;
• クラス図;
• シーケンス。

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

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

使用図

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

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

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

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

一時的

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

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

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

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

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

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

連続

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

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

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

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

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

オブジェクト

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

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

展開

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

Webアプリケーションの一般的な簡略化された展開スキームには、次のものが含まれます。

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

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

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

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

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

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

したがって、UMLがオブジェクト指向ソフトウェアの開発に関連する重要な側面であることは明らかです。 グラフィカル表記を使用して、システムプログラムのビジュアルモデルを作成します。