Reflexive Associations - UML

A concept may have an association to itself; this is known as a reflexive association.

Figure 31.25 Reflexive association

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. 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 31.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. A class shown in a foreign package may be modified with new associations.

Figure 31.27 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.

Figure 31.28 A package dependency

How to Partition the Domain Model

How should the classes in a domain model be organized within packages?

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.

Figure 31.29 Domain concept packages

Core / Misc Package

A Core / Misc package is useful to own widely shared concepts or those without an obvious home. In later references, the package name will be abbreviated to Core.

There are no new concepts or associations particular to this iteration in this package.

Figure 31.30 Core package

Figure 31.31 Payments 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.

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.

Figure 31.32 Products package

With the exception of composite aggregation and derived attributes, there are no new concepts or associations particular to this iteration.

Figure 31.33 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 will understand that the transactions are for the payment: adding the names merely makes the diagram more busy.

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.

Figure31.34 Authorization transaction package.

Example: Monopoly Domain Model Refinements

Figure shows refinements to the Monopoly domain model. These include:

  1. Different kinds of property squares (LotSquare,...). This reflects the guideline that if the domain rules treat a noteworthy concept in a different or distinct manner, then show it a separate specialization.
  2. An abstract superclass Property Square.This is justified because all the subclasses have a price attribute and an Owns association with a Player.

Figure 31,35 Iteration - 3 Monopoly domain model


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics