27.10. Using Packages to Organize the Domain Model
A domain model can easily grow large enough that it is desirable to factor it into packages of strongly related concepts, as an aid to comprehension and parallel analysis work in which different people do domain analysis within different sub-domains. The following sections illustrate a package structure for the UP Domain Model.
UML Package Notation
To review, a UML package is shown as a tabbed folder (see Figure 27.17). Subordinate packages may be shown within it. The package name is within the tab if the package depicts its elements; otherwise, it is centered within the folder itself.
Figure 27.17. A UML package.
Ownership and References
An element is owned by the package within which it is defined, but may be referenced in other packages. In that case, the element name is qualified by the package name using the pathname format PackageName::ElementName (see Figure 27.18). A class shown in a foreign package may be modified with new associations, but must otherwise remain unchanged.
Figure 27.18. A referenced class in a package.
Package Dependencies
If a model element is in some way dependent on another, the dependency may be shown with a dependency relationship, depicted with an arrowed line. A package dependency indicates that elements of the dependent package in some way know about or are coupled to elements in the target package.
For example, if a package references an element owned by another, a dependency exists. Thus, the Sales package has a dependency on the Core Elements package (see Figure 27.19).
Figure 27.19. A package dependency.
Package Indication without Package Diagram
At times, it is inconvenient to draw a package diagram, but still desirable to indicate the package that the elements are a member of.
In this situation, include a note (dog-eared note) on the diagram, as illustrated in Figure 27.20.
Figure 27.20. Illustrating package ownership with a note.
How to Partition the Domain Model
How should the classes in a domain model be organized within packages? Apply the following general guidelines:
|
To partition the domain model into packages, place elements together that:
|
It is useful if all elements related to the domain model are rooted in a package called Domain, and all widely shared, common, core concepts are defined in a packaged named something like Core Elements or Common Concepts, in the absence of any other meaningful package within which to place them.
POS Domain Model Packages
Based on the above criteria, the package organization for the POS Domain Model is shown in Figure 27.21.
Figure 27.21. Domain concept packages.
Core/Misc Package
A Core/Misc package (see Figure 27.22) is useful to own widely shared concepts or those without an obvious home. In later references, the package name will be abbreviated to Core.
Figure 27.22. Core package.
There are no new concepts or associations particular to this iteration in this package.
Payments
As in iteration 1, new associations are primarily motivated by a need-to-know criterion. For example, there is a need to remember the relationship between CreditPayment and CreditCard. In contrast, some associations are added more for comprehension, such as DriversLicense Identifies Customer (see Figure 27.23).
Figure 27.23. Payments package.
Note that PaymentAuthorizationReply is expressed as an association class. A reply arises out of association between a payment and its authorization service.
Products
With the exception of composite aggregation, there are no new concepts or associations particular to this iteration (see Figure 27.24).
Figure 27.24. Products package.
Sales
With the exception of composite aggregation and derived attributes, there are no new concepts or associations particular to this iteration (see Figure 27.25).
Figure 27.25. Sales package.
Authorization Transactions
Although providing meaningful names for associations is recommended, in some circumstances it may not be compelling, especially if the purpose of the association is considered obvious to the audience. A case in point is the associations between payments and their transactions. Their names have been left unspecified because we can assume the audience reading the class diagram in Figure 27.26 will understand that the transactions are for the payment; adding the names merely makes the diagram more busy.
Figure 27.26. Authorization transaction package.
Is this diagram too detailed, showing too many specializations? It depends. The real criteria is usefulness. Although it is not incorrect, does it add any value in improving understanding of the domain? The answer should influence how many specializations to illustrate in a domain model.