Chapter 32 Domain Model Refinement CS 6359 Fall

Chapter 32 Domain Model Refinement CS 6359 Fall 2011 John Cole 1

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 CS 6359 Fall 2011 John Cole 2

Concepts for this Iteration Category Examples Physical or tangible objects Credit. Card, Check Transactions Check. Payment, Cash. Payment Other computer or electro-mechanical systems external to ours Credit. Authorization. Service, Check. Authorization. Service Organizations Records of finance, work, contracts, legal matters Accounts. Receivable, General. Ledger CS 6359 Fall 2011 John Cole 3

Generalization • Cash. Payment, Credit. Payment, and Check. Payment are similar • Identify commonality among concepts and define a superclass • Separate and shared arrow notations in UML CS 6359 Fall 2011 John Cole 4

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 CS 6359 Fall 2011 John Cole 5

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 CS 6359 Fall 2011 John Cole 6

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 CS 6359 Fall 2011 John Cole 7

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 CS 6359 Fall 2011 John Cole 8

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 CS 6359 Fall 2011 John Cole 9

Diagrams CS 6359 Fall 2011 John Cole 10

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? CS 6359 Fall 2011 John Cole 11

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? CS 6359 Fall 2011 John Cole 12

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. CS 6359 Fall 2011 John Cole 13

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

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 CS 6359 Fall 2011 John Cole 15

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 CS 6359 Fall 2011 John Cole 16

Time Intervals and Product Prices • If a Sales. Line. Item is associated with a Product. Description and that contains the price, then you can always get the price, right? CS 6359 Fall 2011 John Cole 17

Time Intervals and Product Prices • If a Sales. Line. Item is associated with a Product. Description 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 CS 6359 Fall 2011 John Cole 18

Two Approaches • Copy the current price to the Sales. Line. Item • Associate a collection of Product. Prices with Product. Descriptions, each with its applicable time interval. • Why might the second option not always be better? CS 6359 Fall 2011 John Cole 19

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 CS 6359 Fall 2011 John Cole 20

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. ) CS 6359 Fall 2011 John Cole 21

Roles in Associations CS 6359 Fall 2011 John Cole 22

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. CS 6359 Fall 2011 John Cole 23

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

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. CS 6359 Fall 2011 John Cole 25

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 CS 6359 Fall 2011 John Cole 26

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. CS 6359 Fall 2011 John Cole 27

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 CS 6359 Fall 2011 John Cole 28

POS Domain Model packages CS 6359 Fall 2011 John Cole 29

POS Payments CS 6359 Fall 2011 John Cole 30

Monopoly Refinements CS 6359 Fall 2011 John Cole 31