When to Define a Conceptual Superclass? - UML

Generalization into a common superclass is usually advised when commonality is identified among potential subclasses. The following are motivations to generalize and define a superclass:

Guideline Create a superclass in a generalization relationship to subclasses when:

  1. The potential conceptual subclasses represent variations of a similar concept.
  2. The subclasses will conform to the 100% and Is - a rules.
  3. All subclasses have the same attribute that can be factored out and expressed in the superclass.
  4. All subclasses have the same association that can be factored out and related to the superclass.

The following sections illustrate these points.

NextGen POS Conceptual Class Hierarchies

Payment Classes

Based on the above criteria for partitioning the Payment class, it is useful to create a class hierarchy of various kinds of payments. The justification for the superclass and subclasses is shown in Figure.

Authorization Service Classes

Credit and check authorization services are variations on a similar concept, and have common attributes of interest. This leads to the class hierarchy in Figure.

Figure 31.7 Justifying Payment subclasses

Figure 31.8 Justifying the AuthorizationService hierarchy

Authorization Transaction Classes

Modeling the various kinds of authorization service transactions (requests and replies) presents an interesting case. In general, transactions with external services are useful to show in a domain model because activities and processes tend to revolve around them, They are important concepts.

Should the modeler illustrate every variation of an external service transaction? It depends. As mentioned, domain models are not necessarily correct or wrong. but rather more or less useful. They are useful, because each transaction class is related to different concepts, processes, and business rules.

A second interesting question is the degree of generalization that is useful to show in the model. For argument's sake, let us assume that every transaction has a date and time. These common attributes, plus the desire to create an ultimate generalization for this family of related concepts, justifies the creation of PaymentAuthorizationTransaction.

But is it useful to generalize a reply into a CreditPaymentAuthorizationReply and
CheckPaymentAuthorizationReply, as shown in Figure, or is it sufficient to show less generalization, as depicted in Figure?

Figure 31.9 One possible class hierarchy for external service transactions

Figure 31.10 An alternate transaction class hierarchy

The class hierarchy shown in Figure is sufficiently useful in terms of generalization, because the additional generalizations do not add obvious value. The hierarchy of Figure expresses a finer granularity of generalization that does not significantly enhance our understanding of the concepts and business rules, but it does make the model more complex - and added complexity is undesirable unless it confers other benefits.

Abstract Conceptual Classes

It is useful to identify abstract classes in the domain model because they constrain what classes it is possible to have concrete instances of, thus clarifying the rules of the problem domain.

Definition : If every member of a class C must also be a member of a subclass, then class C is called an abstract conceptual class.

For example, assume that every Paymentinstance must more specifically be an instance of the subclass CreditPayment, CashPayment, or CheckPayment. This is illustrated in the Venn diagram of Figure. Since every Payment member is also a member of a subclass, Payment is an abstract conceptual class by definition.

Figure 31.11 Abstract conceptual classes

In the POS domain, every Payment is really a member of a subclass. Figure is the correct depiction of payments; therefore, Payment is an abstract conceptual class.

Abstract Class Notation in the UML

To review, the UML provides a notation to indicate abstract classes - the class name is italicized.

Figure 31.12 Abstract class notation

Guideline : Identify abstract classes and illustrate them with an italicized name in the Domain Model, or use the {abstract} keyword.


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

UML Topics