アベニュー、コーダー！UMLクラス図は、システムの構造を示し、クラス、それらの属性、メソッド、およびオブジェクト間の関係を記述します。
小さな子供たちでさえ、UMLが統一モデリング言語から来ていることを知っています。ロシア語の場合、統一モデリング言語は、伝説が言うように、深刻な叔父や叔母が最終的にさまざまな円、ダッシュ、雲で泳ぐのに飽きたときに開発されました。
怠惰すぎて読めない人のために：
主人公
まず、クラスとは何かを思い出してみましょう。一言で言えば、クラスは、初期状態値を提供するオブジェクトを作成するためのテンプレートです。可変フィールドの初期化と、フィールドおよびメソッドの動作の実装です。
基本的に、クラスはオブジェクトが何であるかを記述します。
クラスは、状態（属性）と動作（メソッド）を説明する概念を表します。各属性には独自のタイプがあり、各メソッドには独自の署名がありますが、クラス図では、クラス名のみに情報を入力する必要があります。これは論理的です。世界の最高の精神科医でさえ、この名前のない正方形が何であり、一般的に何を指しているのかを理解できません。
クラス名は最上部の区分に記述され、次にクラスの属性（タイプはコロンの後に記述されます）、そして最後に下位の区分にメソッドがあります。
メソッドが返すことができるタイプは、メソッド署名の最後のコロンの後に書き込まれます。スコープ修飾子は、クラスの属性とメソッドの前に表示されます。
メソッドの各パラメーターには、メソッドの方向（in、out、inout）の説明を含めることもできます。
この図では、method1はp1を入力として使用し、p1の値は何らかの方法でメソッドによって使用され、メソッドはp1を変更しません。
Method2はp2をI / Oパラメーターとして受け取り、p2の値は何らかの方法でメソッドによって使用され、メソッドの出力を受け取りますが、メソッド自体もp2を変更できます。
Method3は、出力パラメーターとしてp3を使用します。つまり、パラメーターは、メソッドの出力値のリポジトリとして機能します。
ソフトウェア開発ライフサイクルにおけるクラス図の展望
ソフトウェア開発ライフサイクルのさまざまな段階でクラス図を使用でき、通常、詳細レベルを進むにつれて、3つの異なる視点からクラス図を徐々にモデル化します。
概念的な視点は、図が現実世界の物事を説明するものとして解釈される場合です。したがって、概念的な観点から見ると、調査領域の概念を表す図を描きます。これらの概念は、それらを実装するクラスに関連しています。概念的な観点は、言語に依存しないと見なされます。
仕様の観点とは、ダイアグラムが、ソフトウェアの抽象化または仕様とインターフェイスを備えたコンポーネントを記述していると解釈されるが、特定の実装に結び付けられていない場合です。
実装の観点は、図が特定のテクノロジーと言語でソフトウェアの実装を説明するものとして解釈される場合です。
したがって、実装の観点から見ると、ソフトウェアの実装を見ていることになります。
関係タイプ
次に、UML図で最も一般的な6つの主要なタイプのクラス関係表記を示します。
協会。
オブジェクトを接続するリンクと同様に、関連付けはクラスをリンクします。オブジェクトを接続するには、オブジェクト間に関連付けが必要です。
相互作用する2つのクラスがあると仮定すると、それらの間に連続した接続線を描画して、図上の関連付けを示す必要があります。多くの場合、その意味を伝える動詞も見ることができます。
さらに、多重度、つまり関係に参加できるオブジェクトの数を指定することもできます。多重度は、間隔のコンマ区切りリストとして指定され、各間隔は最小-最大として表されます。
たとえば、1人の学生が多くの教師から学ぶことができます。
しかし、教師は多くの学生に教えることができます。
継承
または、一般化とも呼ばれます。
名前が示すように、これは親クラスとその子孫の間の関係の概略図です。中空の矢印は常に親クラスを指します。
継承の典型的な例：親Figureクラスから継承するsquare、rectangle、およびcircleクラス。
私たちは、クラスごとに別々に継承を描写し、それらを組み合わせる権利があります。
継承が抽象クラスからのものである場合、そのような親クラスの名前はイタリック体で記述されます。
実装
通常、これは、インターフェイスとそのインターフェイスを実装するオブジェクトとの間の関係を指します。
たとえば、Ownerインターフェースには私有財産を売買するためのメソッドがあり、このインターフェースを実装するPersonクラスとCorporationクラスの関係は、インターフェースを指す矢印の付いた破線として図に示されます。
依存関係
あるクラスのオブジェクトは、そのメソッドで別のクラスのオブジェクトを使用できます。
オブジェクトがクラスフィールドに格納されていない場合、この種のクラス間関係は依存関係としてモデル化されます。
実際、依存関係は2つのクラスの関連付けの特殊なケースであり、この場合、一方のクラスの変更は、もう一方のクラスの変更を容赦なく伴います。
たとえば、Personクラスには、入力パラメータbookを持つhasReadメソッドがあります。これは、たとえば、人が本を読んだ場合にtrueを返します。
依存関係は、たとえば別のクラスのメソッドが依存しているクラスに面した矢印の付いた破線で示されます。
集約
あるクラスが別のクラスの一部である、クラス間の特別なタイプの関係。
たとえば、プログラマーの職場は、椅子、テーブル、コンピューター、ファンで構成されていますが、「職場」というクラスを削除すると、これらのクラスはすべて個別になります。
集約は、クラスの一部であるクラスからアグリゲータークラスに向けられた中空のひし形の実線として示されます。
組成
実際、一種の集約、この場合のみ、別のクラスの一部であるクラスは、アグリゲータークラスが破棄されるときに破棄されます。
たとえば、私たちの体は臓器で構成されていますが、それ自体では実行可能ではありません。
組成は凝集と同様の方法で示されますが、今回はダイヤモンドが完全に充填されています。
Finalchka
UMLは、「何をどこに、何から継承するか」を理解している初心者にとって非常に役立ちます。英語を話す同僚が言うように、「森全体が木の幹の後ろにどのように見えるかを見るのに役立ちます」。
したがって、小さいながらも素晴らしいプロジェクトを開始する前に、すぐにコードを取得しないでください。まず、UMLでアプリケーションアーキテクチャを設計します。
アベニュー！