UML にはどのようなタイプのモデルが存在するか。 UML 言語の一般的な特徴。 インタラクション概要図

Windows Phoneの場合 14.03.2022
Windows Phoneの場合

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.0 から始まり、その後、あるオブジェクトから別のオブジェクトにメッセージが送信される方向に進みます。

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

シーケンス図

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

この場合の主な要素は、さまざまなオブジェクトの指定、時間の経過を表す垂直線、特定のオブジェクトのアクティビティや機能の実行を表す四角形です。

連携図

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

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

インタラクション概要図

これらはアクティビティ図の一種であり、シーケンス要素と制御フロー構造の両方を含む UML 図です。

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

タイミング図

特定の時間スケールにわたるライフラインに沿った状態の変化を明示的に示すシーケンス図の代替バージョンを表します。 さまざまなリアルタイム アプリケーションで非常に役立ちます。

利点は何ですか?

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

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

欠陥

UML 図の構築には多くの利点があるという事実にもかかわらず、次のような欠点があると批判されることがよくあります。

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

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

注釈: このコースの主題は、UML (統一モデリング言語) です。 前回の講義では、UML とは何か、その歴史、目的、言語の使用方法、定義の構造、用語、表記法について説明しました。 UML モデルは一連の図であることに注意してください。 この講義では、次の質問について考えます。なぜ数種類の図が必要なのか。 図の種類。 OOP と作図シーケンス

この講義の主な内容について説明する前に、そもそもなぜ図を作成する必要があるのか​​について話しましょう。 あらゆるシステム (ソフトウェアに限らず) のモデルの開発は、常にその作成または更新に先立って行われます。 これは、少なくとも、解決される問題をより明確に想像するために必要です。 よく考えられたモデルは、開発チーム内の対話にとっても、顧客との相互理解にとっても非常に重要です。 最終的に、これにより、コードに実装される前に、設計が「アーキテクチャ的に一貫している」ことが保証されます。

私たちが複雑なシステムのモデルを構築するのは、複雑なシステムを「ひと目見て」完全に説明することができないからです。 したがって、特定のタスクに不可欠なシステムのプロパティのみを強調表示し、これらのプロパティを表示するモデルを構築します。 オブジェクト指向分析の方法を使用すると、実際の複雑なシステムを最も適切な方法で記述することができます。 しかし、システムの複雑さが増すにつれて、優れたモデリング技術の必要性が生じます。 前回の講義ですでに述べたように、統一された モデリング言語(統一モデリング言語、UML)。システムを指定、視覚化、設計、文書化するためのグラフィカル言語です。 UML を使用すると、作成中のシステムの詳細なモデルを開発し、その概念だけでなく実装の特定の機能も反映できます。 UML モデル内では、システムに関するすべてのアイデアが、ダイアグラムと呼ばれる特別なグラフィック構造の形式で記録されます。

注記。 すべてではなく、図の種類の一部のみを検討します。 たとえば、この講義ではコンポーネント図については説明しません。これは図の種類の概要を説明するだけです。 特定のアプリケーション モデルの図の種類の数はまったく制限されません。 単純なアプリケーションの場合、例外なくすべてのタイプの図を作成する必要はありません。 それらの一部は単に欠落している可能性がありますが、この事実はエラーとはみなされません。 特定の種類の図が利用できるかどうかは、特定のプロジェクトの詳細によって異なることを理解することが重要です。 他のタイプの図 (ここでは説明しません) に関する情報は、UML 標準に記載されています。

数種類の図が必要な理由

まず、用語を定義しましょう。 この講義の導入部分で、システム、モデル、ダイアグラムの概念を繰り返し使用しました。 著者は、私たち一人ひとりがこれらの概念の意味を直観的に理解していると確信していますが、それを完全に明確にするために、もう一度用語集を見て次の文を読んでみましょう。

システム- 共通の動作目的によって統合された、相互接続された制御サブシステムのセット。

はい、あまり参考になりません。 では、サブシステムとは何でしょうか? 状況を明確にするために、古典的なものに目を向けてみましょう。

システム特定の目標を達成するために編成され、場合によってはさまざまな観点からのモデルのセットを使用して記述されたサブシステムのセットを指します。

まあ、できることは何もないので、サブシステムの定義を探す必要があります。 そこにはこうも書いてある サブシステムは要素のコレクションであり、その一部は他の要素の動作を指定します。 イアン・サマーヴィルはこの概念を次のように説明しています。

サブシステムは、その機能が他のサブシステムのサービスに依存しないシステムです。 ソフトウェア システムは、比較的独立したサブシステムの集合として構造化されています。 サブシステム間の相互作用も定義されます。

これもあまり明確ではありませんが、より良くなります。 「人間」の言葉で言えば、システムは比較的自立した単純なエンティティのセットとして表されます。 これは、プログラム開発の過程で、標準的な「キューブ」、つまり視覚的なコンポーネントからグラフィカル インターフェイスを構築する方法や、プログラム テキスト自体も、機能ごとにまとめられたサブルーチンを含むモジュールに分割される方法と比較できます。以下のプログラムで再利用できます。

私たちはシステムの概念を理解しています。 設計プロセス中にシステムが考慮されます さまざまな観点からモデルの助けを借りて、そのさまざまな表現が図の形で表示されます。 繰り返しになりますが、読者は概念の意味について疑問を抱くかもしれません。 モデルそして 図。 これは美しい定義だと思いますが、あまり明確ではありません システムの意味的に閉じた抽象化としてのモデル状況を明確にすることはできそうにないので、「私たち自身の言葉で」説明してみます。

モデル- これは、特定のタスクに対するシステムの最も重要な特性のみを表示する特定の (物質的かどうかに関係なく) オブジェクトです。 モデルは異なります - 有形と無形、人工と自然、装飾と数学...

いくつか例を挙げてみましょう。 私たちが幼い頃に夢中になって遊んだ、私たちにとって身近なプラスチック製のおもちゃの車は、単なるものにすぎません。 材料人工装飾実車の模型。 もちろん、そのような「車」にはエンジンがなく、タンクにガソリンを充填せず、ギアボックスは機能しません（実際、ギアボックスはまったくありません）が、モデルとしてこのおもちゃはその機能を完全に満たしています: 4 つの車輪、車体、ドア、窓の存在、運転能力などの特徴が表示されるため、子供に車についてのアイデアを与えます。

医学研究では、人間の臨床試験に先立って動物実験が行われることがよくあります。 この場合、動物は次のように行動します。 天然素材人間のモデル。

上に示した方程式もモデルですが、これは数学モデルであり、重力の影響下での物質点の動きを記述します。

残っているのは、図が何であるかを言うことだけです。 ダイアグラムは、多くの要素をグラフィカルに表現したものです。 通常、頂点 (エンティティ) とエッジ (関係) を含むグラフとして表現されます。 図の例はたくさんあります。 これは、私たち全員が学生時代からよく知っているブロック図、ユーザーマニュアルで見ることができるさまざまな機器の設置図、およびディスク上のファイルとディレクトリのツリー（ツリーコマンドを実行することで確認できます）です。 Windows コンソール、その他多数。 日常生活では、文字よりも絵を認識しやすいため、四方八方から図が私たちを取り囲んでいます。

さて、ソフトウェア設計 (その他) の話に戻りましょう。 この業界では ダイアグラムを使用すると、さまざまな視点からシステムを視覚化できます。 たとえば、図の 1 つはユーザーとシステムの相互作用を説明し、別の図は動作中のシステムの状態の変化を説明し、3 番目の図はシステム要素の相互作用などを説明できます。 複雑なシステム小さくてほぼ独立したモデル、つまり図のセットとして表すことができますし、そうすべきです。そして、それらのそれぞれがシステムの機能の特定の側面に焦点を当てており、システムを説明して全体像を得るには十分ではありません。違った 抽象化のレベル。 言い換えれば、各モデルは、設計されたシステム上の特定の視点に対応します。

前の段落ではモデルの概念を非常に自由に扱ったという事実にもかかわらず、上記の定義の文脈では次のことが理解されるべきです。 個々の図はモデルではありません。 図はモデルを視覚化する手段にすぎず、2 つの概念を区別する必要があります。 のみ 一連の図がシステム モデルを構成しますそしてそれを最も完全に説明していますが、文脈を無視して切り取られた単なる 1 つの図ではありません。

チャートの種類

UML 1.5の定義 12 種類のチャート、次の 3 つのグループに分けられます。

  • 4 種類の図はアプリケーションの静的構造を表します。
  • 5 つはシステムの動作側面を表します。
  • 3 つはシステム動作の物理的側面を表します (実装図)。

UML 2.1 の現在のバージョンには、あまり多くの変更が加えられていません。 図の外観がわずかに変更され (フレームやその他の視覚的な改善が見られます)、表記がわずかに改善され、一部の図には新しい名前が付けられています。

ただし、正確な数字は 正準図私たちにとって、それはまったく重要ではありません。なぜなら、特定のアプリケーションの特定のモデルに対する図の種類の数が厳密に固定されていないため、それらのすべてではなく一部のみを考慮するからです。 単純なアプリケーションの場合、すべての図を作成する必要はありません。 たとえば、ローカル アプリケーションの場合、展開図を構築する必要はありません。 図のリストは開発中のプロジェクトの詳細に依存し、開発者自身によって決定されることを理解することが重要です。 好奇心旺盛な読者がすべての UML 図について知りたい場合は、UML 標準 (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML) を参照してください。 このコースの目的は、UML のすべての機能を完全に説明することではなく、この言語を紹介し、このテクノロジの最初のアイデアを提供することだけを目的としていることに注意してください。

そこで、次のような種類の図について簡単に説明します。

  • ユースケース図;
  • クラス図。
  • オブジェクト図;
  • シーケンス図。
  • 相互作用図;
  • 状態図。
  • アクティビティ図;
  • 展開図.

これらの図のいくつかについては、今後の講義でさらに詳しく説明します。 今のところ、詳細には焦点を当てませんが、図の種類を少なくとも視覚的に区別し、図の主な種類の目的についての最初のアイデアを与えることを読者に教えることを目標に設定します。 それでは、始めましょう。

ユースケース図

すべてのシステム (ソフトウェアを含む) は、運用中に人々によって使用されたり、他のシステムと対話したりするという事実を考慮して設計されています。 システムの動作中に対話するエンティティは、 俳優、そして各アクターは、システムが厳密に定義された予測可能な方法で動作することを期待します。 エクターをより厳密に定義してみましょう。 これを行うには、UML 用の素晴らしいビジュアル辞書を使用します。 ザイコムメンター:

エクター（俳優）- これは、先例またはエンティティ (システム、サブシステム、またはクラス) と対話するときに実行される、論理的に関連する一連の役割です。 アクターは、エンティティの外部にあるものを表す人、または別のシステム、サブシステム、またはクラスにすることができます。

グラフィック的には、エクターは次のいずれかで表されます。 小さな男」、私たちが子供の頃に描いた、家族のメンバーを描いたものに似たもの、または 対応するステレオタイプを持つクラスシンボル、写真に示されているように。 どちらの表現形式も同じ意味を持ち、図で使用できます。 「ステレオタイプ化された」形式は、システム アクターを表すため、またはアクターにプロパティがあり、それらを表示する必要がある場合によく使用されます (図 2.1)。

注意深い読者はすぐに次のように尋ねるかもしれません。 なぜ俳優であって俳優ではないのか? 私たちも同意しますが、「エクター」という言葉はロシア人の耳に少し耳障りです。 その理由は簡単です。「ector」という言葉が由来です。 アクション、翻訳すると、 アクション。 「エクター」という言葉を直訳すると、 俳優- 長すぎて使いにくい。 したがって、私たちはこのように話し続けます。


米。 2.1.

同じ注意深い読者なら、この行為者の定義の中に「前例」という言葉がチラチラしていることに気づいたかもしれません。 それは何ですか？ 私たちが今話していることを思い出せば、この質問はさらに興味をそそられるでしょう。 ユースケース図。 それで、

使用事例- ユーザーの視点 (ブッチ) から見たシステム動作の別の側面の説明。

この定義は非常に明確で包括的ですが、同じ方法を使用してさらに明確にすることができます。 ザイコムメンター「オム：

使用事例- アクターが観察した結果につながる、システムによって実行される一連の一連のイベント (オプションを含む) の説明。 ユースケースはエンティティの動作を表し、アクターとシステム間の相互作用を記述します。 ユースケースは、特定の結果が「どのように」達成されるかを示すのではなく、「何が」達成されるかだけを示します。

先例は非常に簡単な方法で指定されます。楕円の形で、その中にその名前が示されます。 ユースケースとアクターは線を使用して接続されます。 多くの場合、線の一方の端に図形が描かれます。 2.3

  • 設計されたシステムの動作に対する一般的な要件の形成。
  • その後の詳細説明のためのシステムの概念モデルの開発。
  • 顧客およびシステムユーザーとの対話のための文書の準備。

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

    UML の簡単な歴史

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

    オブジェクト テクノロジとデータベースの分野における標準の採用を担当する組織であるオブジェクト管理グループ (OMG) の要請により、統一と標準化という緊急の問題は、最も人気のある 3 つの OO メソッドの作成者によって解決されました。 Butch、D. Rambo、A. Jacobson は協力してバージョン UML 1.1 を作成し、1997 年に OMG によって標準として承認されました。

    UMLは言語です

    どの言語も語彙と、単語を組み合わせて意味のある構造を作成するためのルールで構成されています。 これは、特に UML などのプログラミング言語の構造です。 その特徴は、言語辞書がグラフィック要素で構成されていることです。 各グラフィック シンボルには特定のセマンティクスが関連付けられているため、ある開発者が作成したモデルは、別の開発者や、UML を解釈するソフトウェア ツールでも明確に理解できます。 ここから特に、UML で表現されたソフトウェア モデルは、OO プログラミング言語 (Java、C++、VisualBasic など) に自動的に変換できることがわかります。つまり、UML をサポートする優れたビジュアル モデリング ツールがあれば、モデルを構築すると、このモデルに対応するサンプル プログラム コードも受け取ります。

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

    UML辞書

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

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

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

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

    図。 UML では次の図が提供されます。

    • システムの動作を説明する図:
      • 状態図
      • アクティビティ図、
      • オブジェクト図、
      • シーケンス図、
      • コラボレーション図。
    • システムの物理的な実装を説明する図:
      • コンポーネント図。
      • 展開図。

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

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

    UML が提供するもの。

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

    そして最後は…

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

    すべての UML 図は 2 つのグループに分類できます。1 つ目は一般的な図です。 一般的な図は、モデリングの主題から実質的に独立しており、主題領域、ソリューション領域などに関係なく、あらゆるソフトウェア プロジェクトで使用できます。

    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 と呼びます。 これはモデル内の関係を表すものではなく、図の読者を正しい方向に導くために設計されたグラフィカルなコメントです。 生命線に重ねられた細い縞模様の図形も、シミュレートされた実体の画像ではありません。 これは、オブジェクトが制御フロー（実行発生）５を所有している期間、すなわちオブジェクトの起動が行われている期間を示すグラフィカルなコメントである。 結合フラグメント ステップ 6 により、シーケンス図に対話プロトコルのアルゴリズム的側面を反映させることができます。 シーケンス図の表記のその他の詳細については、第 4 章を参照してください。

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

    コミュニケーション図(コミュニケーション図) は、シーケンス図と意味的に同等の動作を記述する方法です。

    実際、これは、対話する分類子のインスタンスのメッセージ交換シーケンスの同じ記述であり、他のグラフィック手段によってのみ表現されています。 さらに、ほとんどのツールは、シーケンス図を通信図に、またはその逆に自動的に変換できます。

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

    この図は、通信図で使用される表記の主な要素を示しています。 相互作用するオブジェクト自体を指定するには、標準的な表記法 (分類子インスタンスの名前を含む四角形) が使用されます。 連携図内の要素の相対位置は重要ではありません。メッセージが送信される接続 (ほとんどの場合は関連付けのインスタンス) のみが重要です 3。 階層的な 10 進番号付けは、時間の経過に伴うメッセージの順序を表示するために使用されます。

    1.5.7. コンポーネント図

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

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

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

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

    1.5.8. 配置図

    配置図(展開図) は、システム要素の構成と接続を表示するとともに、実行時にそれらがコンピューティング リソース上で物理的にどのように配置されているかを示します。

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

    この図は、レイアウト図で使用される表記法の主な要素を示しています。 あるエンティティが別のエンティティの一部であることを示すには、「デプロイ」依存関係が適用されるか 5 、または 1 つのエンティティの図が別のエンティティの図の中に配置されます 6 。 図の詳細については、第 3 章で説明します。

    UML (統一モデリング言語) は、ソフトウェア開発分野におけるオブジェクト モデリングのためのグラフィカル記述言語です。 しかし、UML の使用は IT に限定されず、UML の実用的な応用のもう 1 つの大きな分野は、ビジネス プロセスのモデリング、システム設計、組織構造のマッピングです。 UML を使用すると、ソフトウェア開発者は共通の概念を表現するためのグラフィック表記法に同意し、設計と開発に集中できます。

    UML の利点

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

    UML 図の種類

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

    • 構造的な、情報構造を表します。
    • 行動的な、システムの動作とインタラクションのさまざまな側面を表します。 動作図の別のサブタイプが考慮されます 相互作用図.

    UML 図タイプの階層、 クラス図で表現される

    構造図

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

    UML クラス図の例

    動作図

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


    読むことをお勧めします