1. Domain Model Refinement
Chapter 32
Domain Model Refinement

2. Generalization in the Domain Model

3. Alternative Notations

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

5. 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

6. Subclass conformance

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

8. 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

9. Justifying Payment Subclasses

10. Justifying the AuthorizationService Hierarchy

11. Too many levels in the hierarchy

12. Sufficient number of levels

13. When are abstract superclasses needed?
When subclasses form a partition

14. Abstract Class Notation in UML

15. Modeling Changing States

16. Many-to-Many Associations

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

18. Better Solution

19. Recommended: Association Classes

20. Association Class Examples

21. 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

22. Refinement of NextGen POS Domain Model: Time Intervals

23. Role names

24. Roles in associations vs. Roles as concepts

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

26. Derivable attribute, but part of standard terminology

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

28. Reflexive Associations

29. Packages in Domain Models

30. Ownership of a class vs. reference to a class

31. Package Dependencies

32. 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

33. POS Partition to Packages

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