Chapter 31 Domain Model Refinement Notation Extensions Things

Chapter 31 Domain Model Refinement Notation Extensions

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

Fig. 31. 1 Domain Classes

Fig. 31. 2 Alternate notation They each show the same thing

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.

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

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

Fig. 31. 5 Pays-for applies to all payments!

When to use a subclass 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

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

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

Fig. 31. 7 1 3 2 Next. Gen POS Class Hierarchies

Fig. 31. 8 1 2

More or Less Generalization? (Fig. 31. 9) Too much middle management?

Fig. 31. 10

Fig. 31. 11 Abstract Conceptual Classes

Fig. 31. 12

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

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

Fig. 31. 14 Think: transaction ID

Fig. 31. 15 Think: transaction ID

Fig. 31. 16 Think: transaction ID

Fig. 31. 17

Aggregation and 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

Fig. 31. 18

Fig. 31. 21

Fig. 31. 22 Derived Elements No new information but helps comprehension

Fig. 31. 23

Fig. 31. 24 Qualified Associations

Fig. 31. 25 Self referential

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

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

Fig. 31. 27 Shows where the elements belongs, which package owns it.

Fig. 31. 28 Sales is dependent on Core. Sales refers to Core.

Fig. 31. 29 POS Domain Model organization

Fig. 31. 30 Contents of Core

Fig. 31

Fig. 31. 32

Fig. 31. 33

Fig. 32. 34

Monopoly (Fig. 31. 35)