32.18. 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.To review, a UML package is shown as a tabbed folder (see Figure 32.26). 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 32.26. 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 32.27). A class shown in a foreign package may be modified with new associations, but must otherwise remain unchanged.
Figure 32.27. A referenced class in a package.
[View full size image]
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 32.28).
Figure 32.28. A package dependency.
How to Partition the Domain Model
How should the classes in a domain model be organized within packages? Apply the following general guidelines:
Guideline To partition the domain model into packages, place elements together that:
|
POS Domain Model Packages
Based on the above criteria, the package organization for the POS Domain Model is shown in Figure 32.29.
Figure 32.29. Domain concept packages.
Core/Misc Package
A Core/Misc package (see Figure 32.30) 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 32.30. Core 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 32.31).
Figure 32.31. Payments package.
[View full size image]
Products
With the exception of composite aggregation, there are no new concepts or associations particular to this iteration (see Figure 32.32).
Figure 32.32. 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 32.33).
Figure 32.33. Sales package.
[View full size image]
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 32.34 will understand that the transactions are for the payment; adding the names merely makes the diagram more busy.
Figure 32.34. Authorization transaction package.
[View full size image]