同じ階層内で、各パッケージは他のパッケージと異なる名前を持つ必要があります。パッケージの名前は2つの形式があります:
シンプル名:シンプル名はパッケージの名前文字列のみを使用します;
パス名:多くの場合、パッケージ内に他のパッケージが含まれている場合、外側のパッケージの名前を使用してパッケージのパスを示します。基本的な構文は:[外部パッケージ名::本パッケージ名]です。
パッケージ図はパッケージとパッケージ間の関係で構成され、パッケージ間の関係の説明を通じてシステムの各モジュール間の依存関係を示します。
パッケージはUMLの各モデル要素を組織管理するためのメカニズムであり、概念的に似ている、関連のあるモデル要素を一つのパッケージにまとめ、さまざまな機能や用途を持つモジュールを形成し、パッケージ内の要素の可視性を制御することで、複雑なシステムをよりよく理解できるようにします。
どのUML要素もパッケージにグループ化できるため、クラス、オブジェクト、ユースケース、コンポーネント、ノード、ノードインスタンスなどをパッケージとして組織化することで、現実世界のUMLモデルに含まれる無数の要素の組織を管理しやすくします。
複数ユーザーのリアルタイム共同編集と共有リンクによる即時情報伝達をサポート
テキスト入力から自動生成し、スタイルを自動最適化
組み込みテーマと完全カスタマイズ可能なデザイン
アイコン、画像、ラベル、LaTeX数式、コードブロック、リンク、添付ファイルなどをサポート
エクスポート: PNG, VISIO, PDF, SVG | インポート: VISIO, Mermaid
リアルタイムクラウド保存、マルチデバイス同期、バージョン履歴、データ保護
同じ階層内で、各パッケージは他のパッケージと異なる名前を持つ必要があります。パッケージの名前は2つの形式があります:
シンプル名:シンプル名はパッケージの名前文字列のみを使用します;
パス名:多くの場合、パッケージ内に他のパッケージが含まれている場合、外側のパッケージの名前を使用してパッケージのパスを示します。基本的な構文は:[外部パッケージ名::本パッケージ名]です。
パッケージはグループ化のメカニズムであるため、パッケージ内にはUMLの任意の要素(クラス、オブジェクト、ユースケース、インターフェース、コンポーネント、ノードなど)を含めることができ、他のパッケージ、ユースケース図、コラボレーション図、シーケンス図なども含めることができます。
パッケージ内要素の可視性は、パッケージ外部の要素がパッケージ内要素にアクセスできる権限を指し、一般的には3つの権限があります:公開、非公開、保護。
依存関係:パッケージ間の依存関係は、2つのパッケージ内のいくつかの要素間に依存が存在することを指します。依存は破線の矢印で表され、矢印は依存するパッケージから依存されるパッケージに向かいます。パッケージ間の依存関係は、汎化、実装、インポートなどである可能性があります。
汎化関係:パッケージ間の汎化関係はクラス間の汎化関係に似ており、この汎化関係は特定のパッケージが一般的なパッケージの要素を置き換えることができ、新しい要素を追加できることを指します。実際には、パッケージ間の汎化も依存関係の一種です。
パッケージのステレオタイプは一般的に6種類あります:ビジネス分析モデル、ビジネスシステム、ビジネスユースケース分析モデル、ドメインパッケージ、レイヤー、サブシステムです。必要に応じて適切なステレオタイプを選択し、パッケージの役割を迅速に識別できます。
1、大規模システムの複雑さを管理する
2、システムモジュール構造を反映する
3、モジュール間の依存関係とインターフェース関係を示す
4、チーム協力とモジュール分割を容易にする
1、大規模システムの階層モデリング
アーキテクチャの階層を示し、表示層、ビジネス層、データアクセス層の依存関係を示します。
2、チーム協力とモジュール分割
開発前にパッケージ図を使用して責任モジュールを分割し、パッケージ間の依存方向を明確にし、循環依存を避けます。
3、コードとモデルの整合
Java、C++などの言語で「パッケージ」または「名前空間」とUMLパッケージ図は良好なマッピング関係があり、コード構造のモデリングに適しています。
4、リファクタリングとデザインの最適化
パッケージ図を分析して高結合、低凝集の問題を特定し、モジュール分割を調整します。
パッケージ内の要素には制限はありません。パッケージはグループ化のメカニズムであり、パッケージ内にはクラス、ユースケース、インターフェース、コンポーネント、ノードなどのUMLの要素を含めることができます。また、他のパッケージ、ユースケース図、コラボレーション図、シーケンス図なども含めることができます。
できません。1つの要素は1つのパッケージにしか属することができません。
同じ階層内では、それぞれのパッケージは他のパッケージと異なる名前を持つべきです。
1. パッケージ間の循環依存を避けること;
2. パッケージの命名を簡潔で記述的にすること。
パッケージ図はクラス図の要素(クラス、インターフェース、サブシステムなど)を組織化およびグループ化するために使用され、論理的な階層構造を強調します。
一方、クラス図はクラス間の構造的関係を記述するために使用され、クラス自体の詳細に焦点を当てます。
できます。パッケージ図はパッケージのネストされた構造をサポートしており、パッケージ内部でさらに細分されたサブパッケージを表現するために使用され、複雑なシステムの階層構造の表現によく用いられます。
通常、パッケージ図は主に依存関係を使用しますが、必要に応じて他の図(例えばコンポーネント図)を組み合わせて実装、インポートなどの意味を表現することができます。標準のパッケージ図では、さまざまな関係を混在させることは一般的に推奨されません。
1. 低結合高凝集:パッケージ間の依存関係を可能な限り減らし、独立性を強化する;
2. 依存方向の明確化:依存の単方向性を維持し、循環依存を避ける;
3. 層別設計:アーキテクチャのレイヤーに従ってパッケージを分割し、一般的な層分け:プレゼンテーション層 → ビジネスロジック層 → データアクセス層;
4. 内部構造のカプセル化:必要なクラスやインターフェースのみを公開し、実装の詳細を隠す;
5. コメントとラベルを使用して関係を説明する:例 <