object-oriented analysis and design chapters 9, 31: domain models 1

1

Object-Oriented Analysis and DesignCHAPTERS 9, 31: DOMAIN MODELS

2

What will we learn?Refining the Domain Model

3

Refining Domain Models: Super and Sub Classes

Recall that once the initial Domain Model has been created, it may be enhanced in future iterations as more details are added to use cases, or our understanding of the system under development increases

Early iterations tend to be high level, but more details are added in later

We saw that as use case scenarios are extended, it may make sense to collect several conceptual classes together to form a super-class, with individual sub-classes

A conceptual super-class definition is more general or encompassing than a subclass definition

All members of a conceptual subclass set are members of their superclass set

4

Super- and Sub-Classes

CashPayment

CreditPayment

CheckPayment

Payment

amount : Money

Payment

CashPayment CreditPayment CheckPayment

5

Super and Sub ClassesAll statements about the super-class apply to any sub-classes; in other words, 100% of the super-class definition applies to the sub-class

The sub-class must conform to the attributes and associations of the super-classA Credit Payment pays-for a Sale. A Check Payment has an amount

CashPayment

CreditPayment

CheckPayment

Payment

amount : MoneySalePays-for

11

6

Refining Domain Models: Super and Sub Classes

Can think of the “sub-class as being a kind of super-class”A Credit Payment is a kind of PaymentOften shortened to: A Credit Payment is a Payment

All members of the sub-class set must be members of the super-class set, i.e. sub-class x is a super-class y

We can identify sub-classes by these two rulesThe 100% rule – all members of the sub-class must be a member of the super-classThe “is a” rule – the sub-class is a kind of super-class

Any sub-class of a super-class must obey these rules

7

Sub-Classes: When to DefineOccasionally a super-class is created to capture similar sub-classes, but usually the process works the other way: A more general super-class has been defined, and as the iterations proceed, sub-classes are created to handle more detailed scenarios

Guidelines: Create a sub-class when …The class under consideration “is a” kind of an existing super-classThe class under consideration has additional attributes of interestThe class under consideration has additional associations of interestThe class under consideration is operated on, handled, reacted to, or manipulated differently than the super-class (or other subclasses)The class under consideration represents an actor that behaves differently than the super-class or other sub-classes

8

Super- and Sub-Classes: When to Create

Bad example:

MaleCustomer

FemaleCustomer

Customer Correct subclasses.

But useful?

When would this make sense? Market research model, where there are behaviors of male and female shoppers that are different Medical research, since men and women are different biologically

9

Super-Classes: When to DefineThis may occur when common traits are identified among various conceptual classes in the Domain Model

Create a super-class when:The potential sub-classes appear to be variations of the same conceptAll the potential sub-classes will conform to the “is a” rule for the new super-classA set of common attributes that belong to all the potential sub-classes is identified and can be factored outA set of common associations that all potential sub-classes have has been identified and can be factored out

10

Example: Payment Sub-Classes

CashPayment

CreditPayment

CheckPayment

Payment

amount : Money

Check

Identifies-credit-with Paid-with*

each payment subclass is handled differently

additional associations

superclass justified by common attributes and associations

SalePays-for

CreditCard

1

1

1 1

11

CreditAuthorization

Service

CheckAuthorization

Service

CheckPayment

AuthorizationService

addressnamephoneNumber

additional associations

superclass justified by common attributes and associations

StoreAuthorizes-payments-of *

Authorizes

CreditPayment

Authorizes

**

*

1 1

12

Domain Models: Levels of GranularityAs the Domain Model evolves, the question will arise: What level of detail to go to? How many sub-classes?

Depends on the system being modeled – remember, the Domain Model is a tool to help understand the system

Note that system transactions (request – reply) are usually modeled, because other activities and processes depend upon them

But it is not always necessary to define sub-classes for every transaction

General rule: don’t add complexity unless needed!

13

CreditPaymentApproval

Reply

CheckPaymentApproval

Reply

CreditPaymentApprovalRequest

CheckPaymentApprovalRequest

CreditPaymentDenialReply

CheckPaymentDenialReply

CheckPaymentAuthorization

Reply

CreditPaymentAuthorization

Reply

PaymentAuthorization

Reply

PaymentAuthorizationRequest

PaymentAuthorizationTransaction

datetime

Concepts too fine grained?Useful to show this degree of partitioning?

Each transaction is handled differently, so it is useful to partition them into discrete classes.

14




Reply

PaymentAuthorizationRequest


datetime


Reply


Reply



15

Abstract Conceptual ClassesRecall that when we were developing use cases, we saw that it may be useful to collect a series of steps that occurs in several use cases and define an abstract use case that the other use cases could refer to

We can do something similar for conceptual classes: If every member of a class C is a sub-class of C, then C is called an abstract class. But if there is an instance of C that is not a member of a sub-class, then C is not an abstract class.

The Payment conceptual class we have been discussing is an abstract class, because all payments fall into one of the three sub-classes

Usually, when a super-class is created from a set of sub-classes, the super-class is abstract

Not all super-classes are abstract classes

Denote with italics in Domain Model

16

Modeling State ChangesOccasionally it is necessary to capture the state of an transaction, for example, in the Domain Model.

This should not be done with sub-classes, because the super-class can transition

Best to use a separate conceptual class for this, and provide state subclasses of the state class

The association is usually “is-in” for these state transition classes

State transitions can also be captured in a state diagram

17

Example: Modeling State Changes

Paymentnot useful

these subclasses are changing states of the superclass

UnauthorizedPayment

AuthorizedPayment

PaymentState better

UnauthorizedState

AuthorizedState

Payment Is-in 1*

18

Association ClassesOften, the association between conceptual classes contains information that needs to be captured in the model, but does not belong in either class as an attribute

A merchantID may be an attribute with the payment authorization service, but this does not belong in either the Store or AuthorizationService classesA salary may be an attribute of employment, but it does not belong as an attribute of the person or employer classes

General rule: If class C can simultaneously have many values of attribute A, then A should not be placed in C.

Could create a new conceptual class and associate it with the existing classes, but this can add complexity to the model

Better way: Create a special class that represents the attributes of the association

19

Example: An Association Class



addressname

Store

merchantID

ServiceContractan association class

its attributes are related to the association

its lifetime is dependent on the association

Authorizes-payments-via

1..**

20

Association Classes – When to AddIf the attribute(s) appear to be related to the association and not a particular conceptual class ….

The lifetime of the attributes is dependent upon the association …

There is a many-to-many association between two conceptual classes, and there are many attributes (common clue)

21

Aggregation and CompositionThese are software class concepts that will be important later

Aggregation implies a container or collection of classesIn this case, if the container class is destroyed, the individual parts are notDenoted in UML as an open diamond

Composition also implies a collection of classes, but with a stronger life dependency

If the container class is destroyed, the individual component instances are also destroyedDenoted by a filled in diamond in UML

22

Examples: Aggregation and Composition

23

Aggregation and CompositionUsually not critical for domain models, but may be used to …

Clarify constraints in the Domain Model (e.g. existence of a class depends on another class)

Help model situations when create/delete operations apply to many sub-parts

24

Examples: Composition in NextGen POS

SalesLineItemSale1..*

ProductDescription

ProductCatalog 1..*

1

1

25

Association Role Names

Occasionally a role name is added to an association; this name describes the role the object plays in the association

Not required, often included if there role is not clear

Should model the role as a separate class if there are unique attributes, associations, etc. related to the role

Flight CityFlies-to* destination

role name

describes the role of a city in the Flies-to association

Person

*parent

Creates

2

child

1

“Reflexive Association”

26

Qualified AssociationsA qualifier may be used in an association; it distinguishes a set of objects at the far end of the association based upon the qualifier value

In the example below, we can identify the ProductDescriptions by the itemID, so we denote this in the UML diagram and change the multiplicity. Be careful not to design!

ProductCatalog

ProductDescription

itemID Contains

ProductCatalog

ProductDescription

Contains

1..*

multiplicity reduced to 1

(a)

(b)

qualifier

1

11

27

Packages

Often, a Domain Model may become complex and hard to read

Re-structuring the model using packages is an way to improve readability and maintainability

Domain

Core Elements Sales

28

Packages

An element is owned by the package it belongs to, but can be referenced by elements in another package

SalesCore Elements

Sale

Core Elements::Register

Captures

Store RegisterHas1..*1

1

1

29

Packages

Packages may be dependent upon each other; this happens if the elements know about or are coupled to elements in another package

Domain

Core Elements Sales

30

Partitioning the Domain Model Use packages to partition the Domain Model when there are groups of elements that …

… are in the same subject area, closely related by concept or purpose

… are in the same class hierarchy together

… participate in the same use case

… are strongly associated

31

NextGen POS – Domain Model

Domain

Core/Misc Payments Products Sales

Authorization Transactions

32

NextGen POS: Core/Misc Package

Core/Misc

Register Manager

Store

addressname

Houses

1..*

Employs

1..*1

1

33

Payments

Check

AccountsReceivable

CreditPayment

CheckPayment

CheckAuthorization

Service

CreditAuthorization

Service

Authorized-by

Authorized-by

***



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

34

Products

1..*

Core::Store

Stocks

*

Describes

*

Sales::SalesLineItem

Described-by *

Records-sale-of

0..1

ProductDescription

descriptionpriceitemID

ProductCatalog

Item1

1

1

1

1

35

Sales

Cashier

Customer

1..*

SalesLineItem

/quantity

Sale

dateisCompletetime

Initiates

Core::Register

Records-sales-on

Captured-on

Core::Store

Logs-completed*

1

1

1

1

1

1

1

1

TaxLineItem

descriptionpercentageamount

1..* 1

36

Authorization Transactions




Reply


Request


Reply


Reply




37

Takeaways from Chapters 9 and 31

Learn how to associate the conceptual classes of a Domain Model

Understand how to assign key attributes to conceptual classes, and when to define a new data type class

Understand how to create sub- and super-classes

38

Next … Chapter 16: UML Class Diagram Notation

An overview of Java concepts: Inheritance, Polymorphism, Interfaces

object-oriented analysis and design chapters 9, 31: domain models 1

Documents