The package diagram consists of packages and the relationships between packages, showcasing the dependencies between different modules of the system through the description of the relationships between packages.
A package is a mechanism for organizing and managing various model elements in UML. It organizes conceptually similar and related model elements into a package, forming modules with various functions or purposes, and can control the visibility of elements within the package to help people better understand complex systems.
Any UML element can be grouped into a package, so classes, objects, use cases, components, nodes, node instances, etc., can be organized into packages, making the organization of countless elements contained in a real-world UML model easier to manage.
Supports real-time multi-user co-creation with shareable links for instant information transfer
Automatically generates graphics from text input and applies style enhancements
Prebuilt themes with full customization for personalized designs
Supports icons, images, labels, LaTeX formulas, code blocks, links, attachments and more
Export: PNG, VISIO, PDF, SVG | Import: VISIO, Mermaid
Real-time cloud storage, multi-device sync, version history, and secure data protection
At the same level, each package should have a unique name different from other packages. Package names come in two forms:
Simple name: A simple name uses only the package's name string;
Path name: In many cases, a package contains other packages, so the outer package name is used to indicate the package path. The basic syntax is: [Outer Package Name::This Package Name].
A package is a grouping mechanism, so it can contain any elements in UML, such as classes, objects, use cases, interfaces, components, nodes, etc. It can also contain other packages, use case diagrams, collaboration diagrams, sequence diagrams, etc.
Visibility of elements within a package refers to the access permissions of external elements to elements within the package. There are commonly three permissions: public, private, protected.
Dependency relationship: A dependency relationship between packages refers to a dependency existing between several elements within two packages. Dependency is represented by a dashed arrow, with the arrow pointing from the dependent package to the package it depends on. The dependency relationship between packages can be generalization, realization, import, etc.
Generalization relationship: The generalization relationship between packages is similar to the generalization relationship between classes. This generalization relationship means that the specialized package can replace elements in the general package and can add new elements. In fact, generalization between packages is also a kind of dependency relationship.
There are commonly 6 types of package stereotypes: business analysis model, business system, business use case analysis model, domain package, layer, and subsystem. You can choose the appropriate stereotype as needed to quickly identify the role of the package.
1. Manage the complexity of large systems
2. Reflect the modular structure of the system
3. Represent dependency and interface relationships between modules
4. Facilitate team collaboration and module division
1. Layered modeling of large systems
Represent architectural layers, such as the dependency relationships of presentation layer, business layer, data access layer.
2. Team collaboration and module division
Use package diagrams to divide responsibility modules before development, clarify the direction of dependencies between packages, and avoid circular dependencies.
3. Align code with models
Languages like Java, C++ have a good mapping relationship between 'packages' or 'namespaces' and UML package diagrams, suitable for code structure modeling.
4. Refactor and optimize design
Identify high coupling and low cohesion issues by analyzing package diagrams, and adjust module division accordingly.
There are no restrictions on elements within a package. A package is a grouping mechanism, so it can contain any elements in UML, such as classes, use cases, interfaces, components, nodes, etc. It can also contain other packages, use case diagrams, collaboration diagrams, sequence diagrams, etc.
No, an element can only belong to one package.
At the same level, each package should have a name distinct from other packages.
1. Avoid cyclic dependencies between packages;
2. Package names should be simple and descriptive.
Package diagrams are used to organize and group elements in class diagrams, such as classes, interfaces, subsystems, etc., emphasizing logical hierarchical structure.
Class diagrams, on the other hand, are used to describe the structural relationships between classes, focusing on the details of the classes themselves.
Yes, package diagrams support nested structures of packages, used to express the subdivision of sub-packages within a package, often used to represent layered structures in complex systems.
Typically, package diagrams mainly use dependency relationships, but if needed, other diagrams (such as component diagrams) can be used to express semantics like implementation and import. It is generally not recommended to mix multiple relationships in standard package diagrams.
1. Low coupling and high cohesion: Minimize dependencies between packages to enhance independence;
2. Clear dependency direction: Maintain unidirectional dependencies to avoid cyclic dependencies;
3. Layered design: Divide packages according to architectural layers, common layering: presentation layer → business logic layer → data access layer;
4. Encapsulate internal structure: Expose only necessary classes or interfaces, hiding implementation details;
5. Use comments and labels to explain relationships: such as <
