Chapter 32

Chapter 32

Domain Model Refinement

1CS6359 Fall 2011 John Cole

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


Concepts for this IterationCategory Examples

Physical or tangible objects CreditCard, Check

Transactions CheckPayment, CashPayment

Other computer or electro-mechanical systems external to ours

CreditAuthorizationService, CheckAuthorizationService

Organizations

Records of finance, work, contracts, legal matters

AccountsReceivable, GeneralLedger


Generalization

• CashPayment, CreditPayment, and CheckPayment are similar

• Identify commonality among concepts and define a superclass

• Separate and shared arrow notations in UML


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


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


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


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


CashPayment

CreditPayment

CheckPayment

Payment

amount : Money

abstract classindicated by italics

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


Diagrams

Paymentnot useful

these subclasses arechanging states of thesuperclass

UnauthorizedPayment

AuthorizedPayment

PaymentState better

UnauthorizedState

AuthorizedState

Payment Is-in 1*

CS6359 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?


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?


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.


Aggregation and Composition

• Aggregation has no meaningful distinct semantics in UML

• Use composition instead• Composition is a strong kind of whole-part

aggregation


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


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


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?


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


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?


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


Flight CityFlies-to* destination

role name

describes the role of a city in theFlies-to association

Person

*parent

Creates

2

child

1

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.)


Roles in Associations

Store PersonEmploys-to-handle-salescashier

Employs-to-manage

manager

**

Manages

*workermanager

Store

Cashier

ManagerEmploys *

Employs *

roles as concepts

Manages

*

roles in associations

1

1

1

1 1


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.


ProductCatalog

ProductSpecification

itemID Contains

ProductCatalog

ProductSpecification

Contains

1..*

multiplicity reduced to 1

(a)

(b)

qualifier

1

11

Reflexive Associations

• A concept may have an association to itself.


Person

*parent

Creates

2

child

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.


Store RegisterHas1..*

package: Core Elements

1

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


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.


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


POS Domain Model packages


Domain

Core/Misc Payments Products Sales

AuthorizationTransactions

Core/Misc

Register Manager

Store

addressname

Houses

1..*

Employs

1..*1

1

POS PaymentsPayments

Check

AccountsReceivable

CreditPayment

CheckPayment

CheckAuthorization

Service

CreditAuthorization

Service

Authorized-by

Authorized-by

***

AuthorizationService

addressnamephoneNumber

Core::StorePayment

amount

Establishes-credit-for

Logs

*

CreditCard

expiryDatenumber

DriversLicense

number

1..*

Establishes-identity-for

Paid-by

CashPayment

amountTendered *

Sales::CustomerAbused-by

Identifies

Authorization Transactions::PaymentAuthorizationReply

- CheckPayments have CheckPaymentReplies

- CreditPayments have CreditPaymentReplies

1

1

1

111

1

1 1

1

1

Authorizes-payments-of

merchantID

ServiceContract

1


Monopoly Refinements


Chapter 32

Documents

Transcript of Chapter 32