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 Domain Classes

Fig 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 Cash Payment is-a payment. No other type of payment is possible in this domain, e.g. no gift certifications

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

Fig Pays-for applies to all payments!

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

Fig 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 NextGen POS Class Hierarchies

Fig

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

Fig

Fig Abstract Conceptual Classes

Fig

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

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

Fig Think: transaction ID

Fig Think: transaction ID

Fig Think: transaction ID

Fig

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

Fig

Fig

Fig Derived Elements No new information but helps comprehension

Fig

Fig Qualified Associations

Fig 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 Helps comprehension as the project grows. Can only see so many things in a group.

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

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

Fig POS Domain Model organization

Fig Contents of Core

Fig

Fig

Fig

Fig

Monopoly (Fig )