When choosing to include classes in specific packages, it is useful to assign the classes with the same inheritance hierarchy to the same package. There is also a strong argument for including classes that are related via composition, and classes that collaborate with them, in the same package. Packages are represented in UML 2. The package must show the package name and can optionally show the elements within the package in extra compartments.
A «merge» connector between two packages defines an implicit generalization between elements in the source package, and elements with the same name in the target package.
The source element definitions are expanded to include the element definitions contained in the target. The target element definitions are unaffected, as are the definitions of source package elements that don't match names with any element in the target package. Package can also be merged with other packages. A package is rendered as a tabbed folder - a rectangle with a small tab attached to the left side of the top of the rectangle.
If the members of the package are not shown inside the package rectangle, then the name of the package should be placed inside. The members of the package may be shown within the boundaries of the package. In this case the name of the package should be placed on the tab. A diagram showing a package with content is allowed to show only a subset of the contained elements according to some criterion.
Members of the package may be shown outside of the package by branching lines from the package to the members. This notation for packages is semantically equivalent to composition which is shown using solid diamond. The elements that can be referred to within a package using non-qualified names are:.
This means that the specific package must conform to the interface of the general package. This is comparable to the specification perspective of subtyping within class diagrams see Chapter 4.
Generalization implies a dependency from the subtype to the supertype. You don't need to show the extra dependency; the generalization itself is enough. Putting abstract classes in a supertype package is a good way of breaking cycles in the dependency structure. In this situation, the database interface packages are responsible for loading and saving the domain objects in a database.
They therefore need to know about the domain objects. However, the domain objects need to trigger the loading and saving. The generalization allows us to put the necessary triggering interfacevarious load and save operationsinto the database interface package. These operations are then implemented by classes within the subtype packages. There is then no dependency between the database interface package and the Oracle interface package, even though at run time, it will be the subtype package that gets called by the domain.
But the domain thinks it is dealing only with the simpler database interface package. Polymorphism is just as useful for packages as it is with classes. As a rule of thumb, it is a good idea to remove cycles in the dependency structure. I'm not convinced that you should remove all cycles, but you should certainly minimize them. If you do have them, try to contain them within a larger containing package.
In practice, I have found cases in which I have not been able to avoid cycles between domain packages, but I do try to eliminate them from the interactions between the domain and external interfaces. Package generalization is a key element in doing this. In an existing system, dependencies can be inferred by looking at the classes.
This is a very useful task for a tool to perform. I find this handy if I am trying to improve the structure of an existing system. A useful early step is to divide the classes into packages and to analyze the dependences among the packages. Then I refactor to reduce the dependencies.
Toggle navigation. See also. Home Programming UML. Packages The idea of a package can be applied to any model element, not just classes. Figure Package Diagram A dependency between two packages exists if any dependency exists between any two classes in the packages.
Figure is a more complex package diagram that contains additional constructs. Advanced Package Diagram First, we see that I have added a Domain package that contains the orders and customers packages. Remember the name: eTutorials. Chapter 1. What Is the UML? How We Got Here. Notations and Meta-Models.
Why Do Analysis and Design? Looking for More Information. Package diagram, a kind of structural diagram, shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules, showing different views of a system, for example, as multi-layered aka multi-tiered application - multi-layered application model.
Package diagrams are used to structure high level system elements. Packages are used for organizing large system which contains diagrams, documents and other key deliverables. Package diagram is used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements. Package diagram follows hierarchal structure of nested packages.
0コメント