1. Domain Model Refinement Notation Extensions

2. Things not seen before in the Domain Model Similar to the concepts in the Object Models Generalization and specialization Conceptual class hierarchies Association classes that capture information about the association Time intervals Packages as a means of organization

3. Fig. 31.1 Domain Classes

4. Fig. 31.2 Alternate notation They each show the same thing

5. Conceptual Superclasses and Subclasses Conceptual superclass is more general than subclass All members of subclass must be members of the superclass 100% of superclass definition shall apply to the subclass Subclass “is-a” superclass Woman “is-a” human Man “is-a” human Anything else that is a human? All humans have a heart and a brain.

6. Fig. 31.3 Cash Payment is-a payment. No other type of payment is possible in this domain, e.g. no gift certifications

7. Fig. 31.4 Set view Venn Diagram view: All instances of “cash payment” are also members of the “payment class.

8. Fig. 31.5 Pays-for applies to all payments!

9. Start with the super-class and look at differences to find the sub-classes that make sense. Subclass has additional attributes Subclass has additional associations Subclass usage differs from superclass Subclass represents an animate entity that behaves differently When to use a subclass

10. Fig. 31.6 Only useful to POS if men and women pay different amounts, e.g. have specific gender discounts. Useful for age.

11. When to define a superclass Start with a set of sub-classes and look for commonalities that help the model. Potential subclasses represent variations of concept Subclasses meet “is-a” rule and 100% rule All subclasses have common attributes that can be factored out All subclasses have the same association that can be factored out

12. Fig. 31.7 NextGen POS Class Hierarchies 1 1 3 3 2 2

13. Fig. 31.8 1 1 2 2

14. More or Less Generalization? (Fig. 31.9) Too much middle management?

15. Fig. 31.10

16. Fig. 31.11 Abstract Conceptual Classes

17. Fig. 31.12

18. Fig. 31.13 Modeling Changing State Why is this better? More accurate representation of the details.

19. If a class C can simultaneously have multiple values for attribute A, put these in a separate class When to use association class An attribute is related to the association, not a class Instances of association class have a lifetime dependency on the association Many to many associations between two concepts can produce multiple values simultaneously. Association Classes

20. Fig. 31.14 Think: transaction ID

21. Fig. 31.15 Think: transaction ID

22. Fig. 31.16 Think: transaction ID

23. Fig. 31.17

24. Aggregation and Composition Composition in the Domain. If in doubt don’t use it! Should be obvious Composition when: Whole-part exists Lifetime of composite is bound together Operation to the composite propagates to parts

25. Fig. 31.18

26. Fig. 31.21

27. Fig. 31.22 Derived Elements No new information but helps comprehension

28. Fig. 31.23

29. Fig. 31.24 Qualified Associations

30. Fig. 31.25 Self referential

31. Packages Group elements: By subject area In same class hierarchy In same use cases Strong associations Do not know this until the project grows

32. Fig. 31.26 Helps comprehension as the project grows. Can only see so many things in a group.

33. Fig. 31.27 Shows where the elements belongs, which package owns it.

34. Fig. 31.28 Sales is dependent on Core. Sales refers to Core.

35. Fig. 31.29 POS Domain Model organization

36. Fig. 31.30 Contents of Core

37. Fig. 31.31

38. Fig. 31.32

39. Fig. 31.33

40. Fig. 32.34

41. Monopoly (Fig. 31.35)