UML図（統一モデリング言語、Unified Modeling Language）は、ソフトウェアシステムを記述、視覚化、構築、記録するための標準化されたモデリング言語です。UML には、ドメイン モデル (Domain Model)、オブジェクト モデル (Object Model)、システム シーケンス図 (System Sequence Diagram) など、さまざまな種類の図があります。これらの図は、システムのさまざまなレベルと側面を説明するために使用されます。
ドメインモデル (ドメインモデル)
ドメイン モデルは、実際の問題ドメインに焦点を当て、主要な概念、要件、概念間の関係を特定するのに役立ちます。一般に、実際的な問題に対処するときは、最初にドメイン モデルを使用して主要な概念と各概念間の関係を分析します。
たとえば、今図書館システムを構築したいと考えています。図書館には本と利用者がいます。利用者がどの本を借りたかを記録する必要があります。そうすると、図書館アカウントと本という 2 つの重要な概念とそれらの関係を抽出できます。次のように表現されます:
対応するコード表現は次のとおりです。
class Account {
id : int ;
lateFees : int ;
borrowed: List <Book>;
boolean borrow( Book) { …}
void save();
}
class Book { … }ドメイン モデルを描画するときは、オブジェクト名とそれに含まれる属性を描画することに限定されます。ここでは、実際には図書館アカウントに別の属性があります。それは、bororBook ですが、接続を通じてそれと Book の間の関係をすでに示しています。包含関係にあるため、図書館アカウントの属性に書籍を重複して書き込む必要がありません。
ここでは二つの概念を線分で結び、その関係を言葉で示し、一つの図書館アカウントが*、つまり複数の書籍に対応し、両者の量的な関係を示しています。実際、ほとんどの場合、中央の線分には矢印が付いています (ここでは右矢印である必要があり、図書館アカウントが本を借りることを示します。左矢印の場合は、上記のコメントを借りる必要があります)。必須ではなく、必須のものに属します。
ドメインモデルにおける「has a」関係には、Composition と Aggregation の 2 つの異なる描画方法があり、それらの主な違いは、全体と部分のライフサイクル関係と部分の独立性です。写真を直接見てください:
UML クラス図では、Composition (組み合わせ) と Aggregation (集約) を区別するために実体表記と中空表記が使用されます。構成 (組み合わせ) : 構成関係は、UML クラス図では実線の菱形の矢印で表されます。ひし形の端が全体、矢印の端が部分を指しており、全体と部分のライフサイクルは密接に関係しています。構成関係では、全体がなければ部分は意味を持ちません。たとえば、人には手とステップがありますが、その人から切り離されてしまったら、手と脚だけでは意味がありません。
集約 (集約) : 集約関係は、 UML クラス図では白抜きの菱形の矢印で表されます。ひし形の端が全体を指し、矢印の端が部分を指します。中空のひし形は、集約関係の全体と一部が比較的独立したライフサイクルを持っていることを示しています。集合関係では、部分が全体から分離されても、独立して存在できます。たとえば、車輪と車、車輪は単独で存在することができます。
オブジェクトモデル
実際、オブジェクト モデルはドメイン モデルに非常に似ています。つまり、クラス内のメンバー変数の型、メソッド、パラメーター、戻り値の型など、実装の詳細はドメイン モデルに基づいて追加されます。クラスに含まれています。たとえば、先ほどの図書館アカウントの場合、オブジェクト モデルでは次のように表現されます。
このうち、borrow(book)、returnItem(book)、payFees(int) はすべてこの図書館アカウントのメソッドに属しており、その責任でもあります。ドメイン モデルを通じて、さまざまなオブジェクトの具体的な実装の詳細とメソッドの責任をよりよく認識できるようになります。ドメイン モデルがより高い抽象レベルにあり、現実世界の問題ドメインに密接に関連している場合、オブジェクト モデルはより低い抽象レベルにあり、ソフトウェア実装に密接に関連しています。
後ほど、ドメイン モデル、オブジェクト モデルから最終的な Java コードに至るまで、プロジェクト全体を要約して例を示す予定で、時間があれば書きます。
システムシーケンス図（システムシーケンス図）
システム シーケンス ダイアグラム (SSD) は、システム境界上のイベントのシーケンスを記述するために使用されるモデルであり、特定の使用シナリオにおけるシステムの対話プロセスを示します。システム シーケンス図は、ユーザーやシステム全体などのシステム レベルのコンポーネントのみに焦点を当てています。これにより、内部の詳細に焦点を当てるのではなく、システムの全体的な動作に焦点を当てることができます。たとえば、図書館システムの利用者が本を借りる操作の場合、システムシーケンス図は次のように表現できます。
システム シーケンス図を通じて、ユーザーとシステムの間で可能な対話方法と対話シーケンスを明確に示すことができ、同時にいくつかの可能な応答が点線の戻る矢印で示されます。システム シーケンス図は、オブジェクト指向設計のプロセスにおける重要なツールであり、システムの相互作用を効果的に理解し、設計するのに役立ちます。
相互作用図
インタラクション ダイアグラムは、オブジェクト間の相互作用と通信を表すために使用されるモデリング ツールであり、システム内の動作とコラボレーションを説明するために使用されます。インタラクション図には、シーケンス図 (シーケンス図) と通信図 (コミュニケーション図) の 2 つの一般的な表現があります。ここでシーケンス図について話しましょう。シーケンス図は上記のシステム シーケンス図に非常に似ていますが、全体を単にシステムとして見るのではなく、より具体的なオブジェクトまたはクラス間の相互作用を記述することができます。理解するには次の図を見てください。
図書館システム全体としては、その中に多くのオブジェクトがあり、これらのオブジェクトがどのように相互作用して情報を伝達するかは、相互作用図のシーケンス図を通じてよく表現できます。
まとめ：
この記事では、ドメイン モデル、オブジェクト モデル、システム シーケンス図、相互作用図など、UML 図におけるいくつかの一般的な図の定義、使用シナリオ、描画方法をまとめます。