Ave Coder！
あなたはクールな製品のアイデアを得ましたが、細部が細かいためにコードに行き詰まり、全体像を失いたくないのですか？あなたは企業のサーバーをうんざりさせるために腰を下ろしていると思いますか、あなたは何かクールでITを満たす必要がありますか？
この一連の記事は、若い成長についての有用な、しかし時にはとらえどころのない知識-UML図に専念します。まず、既存の図の概要から始めましょう。歴史について少しお話しましょう。なぜこれほど多くの図が必要なのでしょうか。
UMLは統一モデリング言語の略であり、ご存じのように、システムおよびソフトウェア開発者がソフトウェアシステムアーティファクトを定義、視覚化、設計、および文書化するのを支援するために設計されたダイアグラムの統合セットで構成される標準化されたモデリング言語です。たとえば、ビジネスモデリング用です。
UMLは、大規模で複雑なシステムのモデリングに効果的であることが証明されている一連の最良のエンジニアリング手法であり、オブジェクト指向ソフトウェア開発の非常に重要な部分です。
UMLは主にグラフィカル表記を使用して、ソフトウェアプロジェクトのデザインを表現します。UMLを使用すると、設計チームがコミュニケーションを取り、潜在的なプロジェクトを調査し、ソフトウェアのアーキテクチャ設計を検証するのに役立ちます。
UMLの起源
UMLの目標は、すべてのオブジェクト指向メソッドで使用できる標準表記法を提供し、先行表記法の最良の要素を選択して統合することです。UMLは幅広いアプリケーション向けに開発されました。その結果、幅広いシステムとアクティビティ（たとえば、分散システム、分析、システムの設計と展開）の設計を提供します。
UMLはゼロから生まれたのではなく、いくつかの重要なイベント、性格、方法論が先行しました。例えば：
- OMT [James Rumbaugh 1991], .
- Booch [Grady Booch 1994] — . - . , , , , .
- OOSE (- [Ivar Jacobson 1992]) — , — , , .
1994年、ジムランボはジョンランボと混同されることはありませんでしたが、ジムは、上記のオブジェクトモデリング手法の作成者であり、ゼネラルエレクトリックを去り、Rational CorpのGrady Butchに加わったときに、ソフトウェアの世界を驚かせました。パートナーシップの目的は、彼らのアイデアを単一の統一された方法に組み合わせることでした（この方法の実際の名前は、実際には「統一された方法」でした）。
1995年までに、OOSEの作成者であるIvar JacobsonもRationalに加わっており、彼のアイデア（特に「ユースケース」の概念）は、現在統一モデリング言語と呼ばれる新しい統一メソッドに含まれていました。
よく知られているギャングオブフォーとは対照的に、チームランボ、ブッシュ、ジェイコブソンはスリーアミーゴとして知られています。
UMLは他のオブジェクト指向表記にも影響を受けています。
- メラーとシュラー[1998]
- Coad and Yourdon [1995]
- ヴィルフス・ブロック[1990]
- マーティンとオデル[1992]
UMLには新しい概念も含まれていますが、その当時、拡張メカニズムや言語制約などの他の基本的な方法にはありませんでした。
UMLを選ぶ理由
多くの企業でソフトウェアの戦略的価値が高まるにつれて、業界はソフトウェアの生産を自動化し、品質を向上させ、コストと市場投入までの時間を短縮する方法を模索していました。
これらの手法には、コンポーネント技術、ビジュアルプログラミング、テンプレート、および構造が含まれます。
企業はまた、スケールアップするシステムの複雑さを管理する方法を探しています。
特に、物理的な分散、同時実行、レプリケーション、セキュリティ、ロードバランシング、フォールトトレランスなど、繰り返し発生するアーキテクチャの問題に対処する必要性を認識しています。
さらに、Webの開発はいくつかのことを単純化しますが、一般に、これらのアーキテクチャの問題を悪化させます。
統一モデリング言語（UML）は、これらのニーズを満たすために開発されました。
UML設計の主な目標は次のとおりです。
- 既成の表現力豊かなビジュアルモデリング言語をユーザーに提供して、意味のあるモデルを開発して共有できるようにします。
- コアコンセプトを拡張するための拡張性と特殊化のメカニズムを提供します。
- 特定のプログラミング言語や開発プロセスに依存しない。
- モデリング言語を理解するための正式なフレームワークを提供します。
- オブジェクト指向ツールの市場の成長を奨励します。
- コラボレーション、構造、テンプレート、コンポーネントなどの高度な開発コンセプトのサポート。
- ベストプラクティスを統合します。
UML図は、構造図と動作図の2つのタイプに分類されます。
構造図は、抽象化と実装のさまざまなレベルでのシステムとその部分の静的構造、およびそれらの関係を示しています。構造図の要素は、システムの意味のある概念を表しており、抽象的な現実世界の実装概念を含めることができます。構造図には7つのタイプがあります。
- 複合構造図
- 配置図
- パッケージ図
- プロファイル図
- クラス図
- オブジェクト図
- コンポーネント図
動作図は、システム内のオブジェクトの動的動作を示します。これは、時間の経過に伴うシステムの一連の変化として説明できます。行動図は次のとおりです。
- 活動チャート
- ユースケース図
- 状態図
- シーケンス図
- コミュニケーション図
- インタラクション概要チャート
- タイミング図
次に、それぞれについて少し説明します
クラス図
クラス図は、ほとんどすべてのオブジェクト指向メソッドで使用される中心的なモデリング手法です。この図は、システム内のオブジェクトのタイプと、オブジェクト間に存在するさまざまな種類の静的関係を示しています。
クラスダイアグラムで最も重要な3つのタイプの関係（実際にはそれ以上）は次のとおりです。
タイプインスタンス間の関係を表す関連付け。たとえば、人が会社で働いている場合、会社には複数のオフィスがあります。
継承。オブジェクト指向デザインの継承と厳密に一致します。
オブジェクト指向設計におけるオブジェクト構成の形式である集約。
コンポーネント図
統一モデリング言語では、コンポーネント図は、コンポーネントを組み合わせて、より大きなコンポーネントまたはソフトウェアシステムを形成する方法を示します。
ソフトウェアコンポーネントのアーキテクチャと、コンポーネント間の依存関係を示しています。
これらのソフトウェアコンポーネントには、ランタイムコンポーネント、実行可能コンポーネント、およびソースコードコンポーネントが含まれます。
配置図
配置図は、オブジェクト指向ソフトウェアシステムの物理的側面のシミュレーションに役立ちます。これは、ソフトウェアアーティファクトの展開（配布）としてシステムのアーキテクチャを示すブロック図です。
アーティファクトは、開発プロセスの結果である物理的な世界の特定の要素を表します。
この図は、ランタイム構成を静的ビューでモデル化し、アプリケーション内の成果物の分布を視覚化しています。
ほとんどの場合、これには、ハードウェア構成とそれらをホストするソフトウェアコンポーネントのシミュレーションが含まれます。
オブジェクト図
静的オブジェクト図はクラス図のインスタンスです。これは、特定の時点でのシステムの詳細な状態のスナップショットを示しています。違いは、クラス図がクラスとその関係の抽象的なモデルであることです。
ただし、オブジェクト図は特定の瞬間のインスタンスであり、特定の性質を持つため、データ構造の例を示すために、オブジェクト図の使用はかなり制限されています。
パッケージ図
パッケージ図は、パッケージとパッケージ間の依存関係を示すUML構造図です。
これにより、システムのさまざまなビューを表示できます。たとえば、階層化されたアプリケーションを簡単にシミュレートできます。
複合構造図
複合構造図はクラス図に似ており、主にシステムをミクロレベルでモデル化するときに使用される一種のコンポーネント図ですが、クラス全体ではなく、個々の部分を示しています。これは、クラスの内部構造と、この構造によって可能になる相互作用を示す一種の静的構造図です。
この図には、内部、パーツが相互に通信するためのポート、またはクラスインスタンスがパーツと外界と対話するためのポート、およびパーツやポート間のコネクタを含めることができます。複合構造は、実行時に相互作用して目標を達成する相互接続された要素のセットです。各要素には、コラボレーションにおける特定の役割があります。
プロファイル図
プロファイル図を使用すると、ドメイン固有およびプラットフォーム固有のステレオタイプを作成し、それらの間の関係を判別できます。ステレオタイプの形状を描画し、リソース指向のインターフェースを介してそれらを構成または汎化にリンクすることにより、ステレオタイプを作成できます。ステレオタイプの値を定義して視覚化することもできます。
ユースケース図
ユースケース図は、ユースケースの観点からシステムの機能要件を説明しています。本質的に、これはシステム（前例）とその環境（俳優）の想定される機能のモデルです。
ユースケースにより、システムに必要なものとシステムがそれらのニーズを満たす方法をリンクできます。
アクティビティ図
アクティビティ図は、選択、反復、および同時実行をサポートする、ステップバイステップおよびステップバイステップのワークフローをグラフィカルに表現したものです。
これらは、複雑なビジネスルールと操作の調査、およびユースケースとビジネスプロセスなどのターゲットシステムの制御フローを記述します。
UMLでは、アクティビティ図は計算プロセスと組織プロセスの両方をモデル化するように設計されています。
状態図
状態図は、システムの動作を記述するためにUMLで使用される一種の図であり、David Harelの状態図の概念に基づいています。状態図は、許可された状態と遷移、およびこれらの遷移に影響を与えるイベントを示します。オブジェクトのライフサイクル全体を視覚化し、状態ベースのシステムをよりよく理解するのに役立ちます。
シーケンス図
シーケンス図は、時系列に基づいてオブジェクトの相互作用をモデル化します。特定のユースケースで、一部のオブジェクトが他のオブジェクトとどのように相互作用するかを示します。
コミュニケーション図
シーケンス図と同様に、コミュニケーション図もユースケースの動的な振る舞いをモデル化するために使用されます。シーケンス図と比較して、コミュニケーション図は、時系列ではなくオブジェクトの相互作用を示すことに重点を置いています。実際、コミュニケーション図とシーケンス図は、意味的に同等であり、互いに流れ込むことができます。
インタラクション概要チャート
相互作用の概要図は、相互作用の管理フローの概要に焦点を当てています。これは、ノードが相互作用または相互作用イベントであるアクティビティ図の変形です。相互作用の概要図は、メッセージとライフラインが非表示になっている相互作用を示しています。「実際の」図をリンクして、相互作用概要図内の図間の高度なナビゲーションを実現できます。
タイミング図
タイミング図は、特定の期間におけるオブジェクトの動作を示します。実際、これはシーケンス図の特別な形式であり、それらの違いは、時間を左から右に増やすように軸が入れ替わっていることと、垂直に配置された別々の区画に生存線が表示されていることです。
UMLに非常に多くの図があるのはなぜですか？
これは、アナリスト、デザイナー、コーダー、テスター、品質管理、顧客、技術著者など、多くの利害関係者がソフトウェア開発に関与するため、システムをさまざまな視点から見ることができるためです。
これらの人々はすべて、システムのさまざまな側面に関心があり、それぞれに異なるレベルの詳細が必要です。
たとえば、コーダーはシステムの設計を理解し、設計を低レベルコードに変換できる必要があります。
逆に、テクニカルライターはシステム全体の動作に関心があり、製品の機能を理解する必要があります。
UMLは、すべての関係者が少なくとも1つのUMLダイアグラムから利益を得ることができるような表現力豊かな方法で言語を提供しようとしています。
読むのが面倒な人のために：
アヴェ！