Chapter 32

1. Chapter 32 Domain Model Refinement CS6359 Fall 2011 John Cole

2. Generalization and Specialization • Conceptual class hierarchies are the basis for software class hierarchies that exploit inheritance • Association classes capture information about the association • Time intervals capture the idea that some objects are valid for a limited time CS6359 Fall 2011 John Cole

3. Concepts for this Iteration CS6359 Fall 2011 John Cole

4. Generalization • CashPayment, CreditPayment, and CheckPayment are similar • Identify commonality among concepts and define a superclass • Separate and shared arrow notations in UML CS6359 Fall 2011 John Cole

5. Defining Superclasses and Subclasses • A conceptual superclass definition is more general than a subclass definition • A subclass is a subset of its superclass • Conformance: 100% of the superclass definition should be applicable to the subclass’s attributes and associations • The “is-a” rule CS6359 Fall 2011 John Cole

6. When to Define a Subclass? • The subclass has additional attributes of interest • The subclass has additional associations • The subclass is operated on differently from the superclass or other subclasses • The subclass represents an animated thing that behaves differently from the superclass CS6359 Fall 2011 John Cole

7. When to Define a Superclass? • Possible subclasses represent variations of a similar concept • Subclasses will conform to the 100% and is-a rules • All subclasses have the same attribute that can be factored out and put in the superclass • All subclasses have the same association that can be related to the superclass CS6359 Fall 2011 John Cole

8. Abstract Conceptual Classes • If every member of a class C must also be a member of a subclass, then C is called an abstract class • That is, if C is never used by itself, but only derived classes are used, C is abstract • UML uses italics for abstract classes CS6359 Fall 2011 John Cole

9. Modeling Changing States • Don’t model the states of a concept as subclasses, but rather either: • Define a state hierarchy and associate the states with the class, or • Ignore showing the states of a concept in the domain model; show states in state diagrams CS6359 Fall 2011 John Cole

10. Diagrams CS6359 Fall 2011 John Cole

11. Association Classes • Larman’s example: • Credit card authorization services assign a merchant ID to each store for identification • A payment authorization from the store needs the merchant ID • A store has a different ID for each service • Where in the model should the merchant ID attribute reside? CS6359 Fall 2011 John Cole

12. Association Classes • If a class C can simultaneously have many values for the same kind of attribute A, create an association class with that attribute and associate it with C • E. g. a person may have many phone numbers. Place phone number in a separate class and associate many of these with Person • How does this relate to database design? CS6359 Fall 2011 John Cole

13. Association Class Guideline • An association class may be useful if: • An attribute is related to an association • Instances of the association class have a lifetime dependency on the association • There is a many-to-many association between two concepts and information associated with the association itself • The best example I have is from databases: A person can interview with many companies. The Interview association class has information. CS6359 Fall 2011 John Cole

14. Aggregation and Composition • Aggregation has no meaningful distinct semantics in UML • Use composition instead • Composition is a strong kind of whole-part aggregation CS6359 Fall 2011 John Cole

15. Composition • Implies the following: • An instance of the part belongs to only one composite instance at a time • The part must always belong to a composite (Fingers always belong to a Hand) • The composite is responsible for the creation and deletion of its parts. If the composite is destroyed, the parts must either be destroyed or attached to another composite CS6359 Fall 2011 John Cole

16. Composition Guidelines • If in doubt, leave it out • The lifetime of the part is bound to the lifetime of the composite • There is an obvious whole-part physical or logical assembly • Some properties of the composite propagate to the parts • Operations applied to the composite propagate to the parts, such as destruction, movement, recording CS6359 Fall 2011 John Cole

17. Time Intervals and Product Prices • If a SalesLineItem is associated with a ProductDescription and that contains the price, then you can always get the price, right? CS6359 Fall 2011 John Cole

18. Time Intervals and Product Prices • If a SalesLineItem is associated with a ProductDescription and that contains the price, then you can always get the price, right? • Wrong. If the price changes, old sales refer to the new price CS6359 Fall 2011 John Cole

19. Two Approaches • Copy the current price to the SalesLineItem • Associate a collection of ProductPrices with ProductDescriptions, each with its applicable time interval. • Why might the second option not always be better? CS6359 Fall 2011 John Cole

20. Association Role Names • Each end of an association is a role. Properties are: Name and multiplicity • For example, a City is an object in an association, but its role in a flight might be destination CS6359 Fall 2011 John Cole

21. Roles: Concept vs. Association • Roles in associations are good because they express the idea that the same instance of a person takes on multiple roles depending upon the association. • Roles as concepts provide flexibility in adding attributes, associations, and additional semantics. (Roles as separate classes.) CS6359 Fall 2011 John Cole

22. Roles in Associations CS6359 Fall 2011 John Cole

23. Qualified Associations • A qualifier may be used in an association. The qualifier value makes each thing on the left unique. • Use carefully; they don’t usually add new information. CS6359 Fall 2011 John Cole

24. Reflexive Associations • A concept may have an association to itself. CS6359 Fall 2011 John Cole

25. Organizing Domains with Packages • When the domain model gets too large, factor it into packages of strongly related concepts • A UML package is shown as a tabbed folder, with subordinate packages in it. For example, a domain may have a Sales and Core elements package. CS6359 Fall 2011 John Cole

26. Packages: Ownership vs. Reference • An element is owned by the package in which it is defined but may be referenced in other packages. • Qualify the element name with the name of the package. E. g. in Sales: Core Elements::Register –Captures Sale CS6359 Fall 2011 John Cole

27. Packages: Dependency • If a model’s elements are dependent upon another, show the dependency with an arrowed line. For example, Sales is dependent upon Core Elements. CS6359 Fall 2011 John Cole

28. Partitioning the Model • 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 case • Are strongly associated CS6359 Fall 2011 John Cole

29. POS Domain Model packages CS6359 Fall 2011 John Cole

30. POS Payments CS6359 Fall 2011 John Cole

31. Monopoly Refinements CS6359 Fall 2011 John Cole