Domain Model Refinement Chapter 32 Domain Model Refinement

Generalization in the Domain Model

Alternative Notations

Conceptual superclass: More general and encompassing than a subclass Generalization Conceptual superclass: More general and encompassing than a subclass

All members of a conceptual subclass are members of the superclass “Is a” relationship All members of a conceptual subclass are members of the superclass 100% of superclass definition must apply to subclass All attributes All associations

Subclass conformance

When to partition a conceptual class into subclasses When subclass has additional attributes of interest When subclass has additional associations of interest When subclass is manipulated differently from superclass and other subclasses

When to define a conceptual superclass? Potential conceptual subclasses represents variations of a similar concept Subclass will conform to the 100% and “is a” rules All subclasses have the same attribute that can be factored out All subclasses have the same association that can be factored out

Justifying Payment Subclasses

Justifying the AuthorizationService Hierarchy

Too many levels in the hierarchy

Sufficient number of levels

When are abstract superclasses needed? When subclasses form a partition

Abstract Class Notation in UML

Modeling Changing States

Many-to-Many Associations

Many-to-Many Associations Wrong to have a single attribute in this case

Better Solution

Recommended: Association Classes

Association Class Examples

What good are they in a domain model Composition What good are they in a domain model Has impact on “create-delete” relationships Parts need to be deleted before whole Parts do not exist outside the whole It helps pick the “creator” Operations applied to whole propagate down to part

Refinement of NextGen POS Domain Model: Time Intervals

Role names

Roles in associations vs. Roles as concepts

Only include derived attributes if they are standard part of terminology Otherwise, avoid them.

Derivable attribute, but part of standard terminology

Qualified Associations Don’t use qualified associations in domain model to show design decisions Example: Unique ID assigned in SW, not part of store

Reflexive Associations

Packages in Domain Models

Ownership of a class vs. reference to a class

Package Dependencies

How to partition domain model classes into packages? Place elements together that Are in the same subject area Closely related by concept or purpose Are in a class hierarchy together Participate in the same use cases Are strongly associated

POS Partition to Packages

Core/Misc Package: Widely Shared Concepts or Concepts without an Obvious Home