Modeling Changing States - UML

Assume that a payment can either be in an unauthorized or authorized state, and it is meaningful to show this in the domain model (it may not really be, but assume so for the discussion). As shown in Figure, one modeling approach is to define subclasses of Payment: UnauthorizedPayment and AuthorizedPayment. However, note that a payment does not stay in one of these states; it typically transitions from unauthorized to authorized. This leads to the following guideline:

Guideline : Do not model the states of a concept X as subclasses of X. Rather, either:

  • Define a state hierarchy and associate the states with X, or
  • Ignore showing the states of a concept in the domain model; show the states in state diagrams instead.

Figure 31.13 Modeling changing states.

Class Hierarchies and Inheritance in Software

This discussion of conceptual class hierarchies has not mentioned inheritance. because the discussion is focused on a domain model conceptual perspective, no: software objects. In an object - oriented language, a software subclass inherits the attribute and operation definitions of its superclasses by the creation of software class hierarchies. Inheritance is a software mechanism to make superclass things applicable to subclasses. It supports refactoring code from subclasses and pushing it up class hierarchies. Therefore, inheritance has no real part to play in the discussion of the domain model, although it most definitely does when we transition to the design and implementation view.

The conceptual class hierarchies generated here may or may not be reflected in the Design Model. For example, the hierarchy of authorization service transaction classes may be collapsed or expanded into alternate software class hierarchies, depending on language features and other factors. For instance, CV - templatized classes can sometimes reduce the number of classes.

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

UML Topics