フォワードおよびリバースエンジニアリングによる実行可能システムの構築に使用されるオブジェクト指向システムの物理的側面のモデリングに使用されます。コンポーネント図は基本的に、システムの静的実装ビューをモデル化するためによく使用されるシステムのコンポーネントに焦点を当てたクラス図です。Editionは、すべてのUML図タイプをサポートするUMLソフトウェアです。それは国際的な賞を受賞したUMLモデラーですが、それでも使いやすく直感的で完全に無料です。無料ダウンロード一目でわかるコンポーネント図コンポーネント図は、開発中の実際のシステムをさまざまな高レベルの機能に分解します。各コンポーネントは、システム全体の中の1つの明確な目的に責任を持ち、必要に応じて他の重要な要素とのみ対話します。上記の例は、より大きなコンポーネントの内部コンポーネントを示しています。データ(アカウントおよび検査ID)は右側のポートを介してコンポーネントに流れ込み、内部コンポーネントが使用できる形式に変換されます。右側のインターフェースは必須インターフェースと呼ばれ、コンポーネントがその役割を果たすために必要なサービスを表します。その後、データは左側のポートに出力される前に、さまざまな接続を介して他のいくつかのコンポーネントとやり取りされます。左側のこれらのインターフェースは提供インターフェースとして知られており、これは展示コンポーネントによって提供されるサービスを表します。'ボックス’で囲まれていることに注意してください。(この場合、「ボックス」はそれ自体がコンポーネントです)。コンポーネント図の基本概念コンポーネントは、その内容をカプセル化し、その明示をその環境内で置き換えることができるシステムのモジュール部分を表します。2では、コンポーネントは、オプションのコンパートメントが縦に積み上げられた長方形として描画されます。2のコンポーネントの高水準の抽象ビューは、次のようにモデル化できます。コンポーネントの名前を持つ四角形コンポーネントアイコン付きの四角形ステレオタイプのテキストまたはアイコン、あるいはその両方を含む長方形インタフェース以下の例では、2種類のコンポーネントインタフェースを示しています。末尾に完全な円が付いている提供されたインタフェースシンボルは、コンポーネントが提供するインタフェースを表します。この「ロリポップ」シンボルは、インタフェース分類子の実現関係を表す省略形です。末尾に半円のみのソケット(別名ソケット)が必要なインターフェースシンボルは、コンポーネントが必要とするインターフェースを表します(どちらの場合も、インターフェースの名前はインターフェースシンボル自体の近くに配置されます)。インタフェースの使用(注文システム)サブシステムサブシステム分類子は、コンポーネント分類子を特殊化したものです。このため、サブシステムの表記要素は、コンポーネントの表記要素と同じ規則をすべて継承します。唯一の違いは、サブシステム表記要素がcomponentではなくsubsystemのキーワードを持つことです。港ポートは、システムまたはコンポーネントの端に沿った四角形を使用して表されます。多くの場合、ポートはコンポーネントの必須および提供されているインターフェースを公開するために使用されます。け、そして実現関係を含みます。それはまたメモと制約を含むかもしれません。協会:関連は、型付きインスタンス間で発生する可能性がある意味関係を指定します。それはプロパティによって表される少なくとも2つの端を持ち、それぞれは端のタイプに接続されます。アソシエーションの複数のエンドが同じタイプを持つことがあります。構成:コンポジットアグリゲーションは強力な形式のアグリゲーションで、一度に1つのインスタンスを1つのコンポジットに含める必要があります。コンポジットが削除されると、通常その部分もすべて一緒に削除されます。集約その端の1つが一種のアグリゲーションとしてsharedとマークされている一種のアソシエーション。それは共有アグリゲーションを持っています。1つまたは一連のモデル要素がその仕様または実装に他のモデル要素を必要とすることを意味する関係です。従属要素の完全なセマンティクスは、サプライヤ要素の定義に意味的または構造的に依存しています。一般化は、より一般的な分類子とより具体的な分類子の間の分類学的関係です。特定の分類子の各インスタンスは、一般的な分類子の間接的なインスタンスでもあります。したがって、特定の分類器は、より一般的な分類器の機能を継承します。ソースコードのモデリングフォワードまたはリバースエンジニアリングのいずれかによって、目的のソースコードファイルのセットを識別し、それらをファイルとしてステレオタイプ化されたコンポーネントとしてモデル化します。大規模システムでは、パッケージを使用してソースコードファイルのグループを表示します。ソースコードファイルのバージョン番号、その作者、および最後に変更された日付などの情報を示すタグ付きの値を公開することを検討してください。このタグの値を管理するためのツールを使用してください。依存関係を使用してこれらのファイル間のコンパイル依存関係をモデル化します。繰り返しますが、これらの依存関係の生成と管理に役立つツールを使用してください。++コード実行可能リリースのモデリングモデル化する一連のコンポーネントを特定します。通常、これには、1つのノード上に存在するコンポーネントの一部またはすべて、あるいはシステム内のすべてのノードにわたるこれらのコンポーネントのセットの配布が含まれます。このセットの各コンポーネントのステレオタイプを考えます。ほとんどのシステムでは、少数の異なる種類のコンポーネント(実行可能ファイル、ライブラリ、テーブル、ファイル、ドキュメントなど)があります。UMLの拡張メカニズムを使用して、これらのステレオタイプの視覚的な手がかり(手がかり)を提供できます。このセットの各コンポーネントについて、その隣接コンポーネントとの関係を検討します。ほとんどの場合、これには特定のコンポーネントによってエクスポート(実現)され、次に他のコンポーネントによってインポート(使用)されるインターフェースが含まれます。システムのシームを公開したい場合は、これらのインターフェースを明示的にモデル化してください。モデルの抽象化レベルを上げたい場合は、コンポーネント間の依存関係のみを表示して、これらの関係を取り除きます。物理データベースのモデリング論理データベーススキーマを表すモデル内のクラスを識別します。これらのクラスをテーブルにマッピングするための戦略を選択してください。あなたはまたあなたのデータベースの物理的な分布を考慮したくなるでしょう。あなたのマッピング戦略は、あなたがあなたのデータをあなたの配備されたシステム上に住ませたい場所によって影響されるでしょう。文書化するには、表としてステレオタイプ化されたコンポーネントを含むコンポーネント図を作成します。可能であれば、論理設計を物理設計に変換するのに役立つツールを使用してください。今すぐUMLコンポーネント図を描画しようコンポーネントダイアグラムとは何か、そしてコンポーネントダイアグラムの描き方を学びました。あなた自身の部品図を描く時が来ました。Editionを入手し、無料のコンポーネント図ツールを使用して独自のコンポーネント図を作成してください。それは使いやすく直感的です。