OO Methodology Elaboration Iteration 3 – Part 1 Refining Models.

OO Methodology

Elaboration Iteration 3 – Part 1

Refining Models

2

Table of Contents

• Iteration 1– Use-Case Model

– Process Sale Use Case

– Domain Model

– Design Model

• Iteration 2 – GRASP: More Patterns for Assigning Responsibilities

– Designing Use-Case Realizations with GoF Design Patterns

• Iteration 3– Iteration 3 and Its Requirement

– Related Use Cases

– Modeling Generalization

– Refining the Domain Model

– Adding New SSDs and Contracts

– Modeling Behavior in Statechart Diagrams

– Designing the Logical Architecture with Patterns

– Organizing the Design and Implementation Model Packages

– Introduction to Architectural Analysis and the SAD

– Designing More Use-Case Realization with Paterns

– Designing a Persistence Framework with Patterns

3

Iteration 3 Requirements

• Handle credit payment authorization

• Provide failover to local services when the remote services cannot be accessed.

• Provide support for POS device handling, such as the cash drawer and coin dispenser

• Support for persistent objects

4

Relating Use Cases

• Three methods of relating use cases– include

– extend

– generalize

• The include relationship– a relationship from a base use case to an inclusion use case

– specify how the behavior of the inclusion use case can be inserted into the behavior of the base use case

– an inclusion use case represents encapsulated behavior that potentially can be reused in multiple base use cases

– an inclusion use case is not a separate instantiable classifier

– an inclusion use case sets attribute values in the base use case

– the base use case must not access the attributes of inclusions

Process Sale Process Rental

Handle Credit Payment

<<include>><<include>>

5

The include Relationship

Use Case: Process Sale (the base use case)Main Success Scenario:1. Customer arrives at a POS ...7. Customer pays and System handles payment...Extensions:7b. Paying by credit: Include Handle Credit Payment7c. Paying by check: Include Handle Check Payment

Use Case: Process Rental (the base use case)Extensions:...6b. Paying by credit: Include Handle Credit Payment

Use Case: Handle Credit Payment (inclusion use case)Level: subfunctionMain Success Scenario:1. Customer enters their credit information.2. System sends payment authorization request to an external

Payment Authorization Service System.3. ...Extensions:2a. System detects failure to collaborate with external system:

1. System signals error to cashier.2. Cashier asks Customer alternate payment.

....

6

The extend Relationship

• The extend Relationship– a relationship from an extension use case to a base use case

– The extension use case incrementally modifies the base use case in a modular way

– a base use case defines a set of extension points, references of locations in the base case

– an extension use case contains a list of one or more insertion segments

– an extension use case accesses and modifies attribute values in the base use case

– the base use case must not access the attributes of extensions

Process Sale

Extension Points:Payment

VIP Customer

Handle Gift CertificatePayment

<<extend>>Payment [Customer presentsa gift certificate]

7


Use Case: Process Sale (base use case)

Extension Points: VIP Customer, step 1. Payment, step 7.

Main Success Scenario:1. Customer arrives at a POS ...7. Customer pays and System handles payment...

Use Case: Handle Gift Certificate Payment(extension)

Trigger: Customer wants to pay with gift certificate

Extension Points: Payment in Process Sale

Level: subfunction

Main Success Scenario:

1. Customer gives gift certificate to Cashier

2. Cashier enter gift certificate ID.

...

8


• Example : ATM

9

The generalize Relationship

• The generalize Relationship– a taxonomic relationship between a child use case and the

parent use case

– the parent describes the characteristics the child shares with other use cases

– the child inherits the behavior sequence of the parent and may insert additional behavior into it.

– the child may modify behavior steps inherited from the parent

Verify Identity

Check Password Retinal Scan

10

Comparison of Use Case Relationships

11

Modeling Generalization

• Generalization-specialization class hierarchy

• Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass(special concept)

• Generalization is different from inheritance– inheritance is a mechanism for combining shared incremental

descriptions to form a full description of an element

CashPayment

CreditPayment

CheckPayment

Paymentsuperclass - more generalconcept

subclass - morespecialized concept

these are conceptualclasses, not softwareclasses

12


• Conceptual Subclass Definition Conformance– 100% of the conceptual superclass’s definition shold be

applicable to the subclass

– the subclass must conform to 100% of the superclass’s attribute and associations (100% rule)

• Conceptual Subclass Set Conformance– all members of a subclass set must be members of their

superclass set. (Is-A rule)

CashPayment

CreditPayment

CheckPayment

Payment

amount : Money

abstract classindicated by italics

Payment

CashPayment CreditPayment CheckPayment

13


• When to Define a Conceptual Subclass– the subclass has additional attributes of interest.

– the subclass has additional associations of interest.

– the subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other classes

– the subclass concept represents an animate thing that behaves differently than the superclass or other classes

• When to Define a Conceptual Superclass– the potential conceptual subclasses represent variations of a

similar concept

– the subclasses will conform to the 100% and Is-A rules

– all subclasses have the same attribute which can be factored out and expressed in the superclass

– all subclasses have the same associations which can be factored out and related to the superclass

MaleCustomer

FemaleCustomer

Customer Correct subclasses.

But useful?

14

Abstract Conceptual Classes

• If every member of a class C must also be a member of a subclass, the class C is called an abstract conceptual class

Payment


Payment


If a Payment instance mayexist which is not aCashPayment, CreditPaymentor CheckPayment, thenPayment is not an abstractconceptual class.

Payment is an abstractconceptual class. A Paymentinstance must conform to oneof the subclasses:CashPayment, CreditPaymentor CheckPayment.

abstract conceptual class

(a)

(b)

CashPayment

CreditPayment

CheckPayment

Payment

amount : Money

abstract classindicated by italics

15

NextGen POS Class Hierarchies

• Payment Classes

• Authorization Service

CashPayment

CreditPayment

CheckPayment

Payment

amount : Money

Check

Identifies-credit-with Paid-with*

each payment subclass ishandled differently

additional associations

superclass justified by commonattributes and associations

SalePays-for

CreditCard

1

1

1 1

CreditAuthorization

Service

CheckAuthorization

Service

CheckPayment

AuthorizationService

addressnamephoneNumber

additional associations

superclass justified bycommon attributes andassociations

StoreAuthorizes-payments-of *

Authorizes

CreditPayment

Authorizes

**

*

1 1

16

NextGen POS Class Hierarchies

• Authorization Transaction Classes– Degree of generalization

CreditPaymentApproval

Reply

CheckPaymentApproval

Reply

CreditPaymentApprovalRequest

CheckPaymentApprovalRequest

CreditPaymentDenialReply

CheckPaymentDenialReply

CheckPaymentAuthorization

Reply

CreditPaymentAuthorization

Reply

PaymentAuthorization

Reply


Request

PaymentAuthorizationTransaction

datetime

Concepts too fine grained?Useful to show this degree ofpartitioning?

Each transaction ishandled differently, soit is useful to partitionthem into discreteclasses.

CreditPaymentApprovalRequest

CheckPaymentApprovalRequest


Reply


Request

PaymentAuthorizationTransaction

datetime

CreditPaymentApproval

Reply

CheckPaymentApproval

Reply

CreditPaymentDenialReply

CheckPaymentDenialReply

17

Modeling Changing States

• Do not model the states of a concept X as superclasses of X. Rather either:

– define a state hierarchy and associate the states with X

– Ignore showing the states of a concept in the domain; show the sates in a state diagram instead.

Transition between Non-member Customer and Member Customer ???

Paymentnot useful

these subclasses arechanging states of thesuperclass

UnauthorizedPayment

AuthorizedPayment

PaymentState better

UnauthorizedState

AuthorizedState

Payment Is-in 1*

18

Constraints on Generalization

• A constraint on a generalization specifies further information about how the generalization could be used and extended

• Predefined constraints– overlapping

– disjoint

– complete

– incomplete

Worker

Butcher Baker CandlestickMaker

{overlapping, incomplete}

Customer

FemaleCustomer

MaleCustomer

{complete,disjoint}

19

Association

• Association– Association is semantic relationship between two or more

classifiers that involves connection among their instances

– Each instance of an association(a link) is a tuple (an ordered list) of references to objects

• Structure

• Advanced Topics– association class

– n-ary association

– derived association

– qualifier

A Bq_name:C0..*role

qualifier

multiplicity

rolename

navigability

associationpath aggregation/

composition

associate

associationname

20

Association Class

• Association class is an association that is also a class

• It may have attributes, operations and associations with other classes

• Semantics– a link(instance) of an association class takes its identity from

the object references in it.• job1 : c1 – p1

• job2 : c1 – p2

• job3 : c1 – p1

– an association is a set of tuples and has no duplicates among its object references

Company Person

Job

salary

0..* 0..*

employer employee

duplicate (not correct)

21

Association Class

• Consider the following associations

– implicit relationship by Job class

– provides duplicates in relationship among Company and Person objects

• c1 – job1 – person1



• An Example1. a person owns stock (some number of shares) of a company

2. a person purchased stock of a company several times each with different price at different time

duplicate (correct)

Company Person

Stock

quantity

0..* 0..*

Company PersonJob

salary0..* 0..*1 1

Company PersonPurchase

salarydatecost

0..* 0..*1 1

buyerseller

seller buyer

22

Association Class

• NextGen POS Requirements– Authorization services assign a merchant ID to each store for

identification

– A payment authorization request from the store to an authorization service needs the merchant ID

– A store has a different merchant ID for each service

• Placing Merchant ID in the Store class or AuthorizationService

– it is incorrect because a Store can have more than one value for merchantID

• A better solution, not yet useful

addressmerchantIDnamephoneNumber


addressmerchantIDname

Store both placements ofmerchantID are incorrectbecause there may bemore than one merchantID



addressname

Store

merchantID

ServiceContractPurchases

1..* *

a better model, but notyet as useful as possible

Sells

Authorizes-payments-via 1..**

23

Association Class

• Final Solution : using an association class

• Guidelines for adding association classes– an attribute is related to an association

– instances of the association class have a life-time dependency on the association

– there is many-to-many association between two concepts and information associated with the associated with the association itself

– a link (an instance of association) is identified by two objects in it.



addressname

Store

merchantID

ServiceContract an association class

its attributes are related tothe association

its lifetime is dependent onthe association

Authorizes-payments-via 1..**

24

n-ary Association

• An association among three or more classes

• each instance of the association is an n-tuple of values from the respective classes

• Properties– navigability is meaningless

– multiplicity may be specified but is less obvious and complicated

– aggregation is meaningless

• Generally, n-ary associations are useful only when all the values are needed to uniquely determine a link

• An n-ary association is almost always implemented as a class whose attributes include pointers to the participant objects

Year

PlayerTeam

season

goalkeeper

team*

*

*

25

n-ary Association

• Multiplicity in n-ary association– the multiplicity is defined with respect to the other n-1 ends.

• e.g. in a ternary association (A,B,C), the multiplicity in C states how many C objects may appear in association with a particular pair of A and B objects.

• Example: Course Registration

– for a (course, student) pair, there is zero or one professor

– for a (student, professor) pair, there are many courses

– etc.

Student

ProfessorCourse *

*

0..1

Registration

26

n-ary Association

• Example(cont.)

Student

Professor

Course

*

Registration

*

*11 1

Student

Professor

OpenCourse

1

Registration

1..*

*11 1

Course

*

1

27

Qualifiers

• Qualifier– a slot for an attribute or list of attributes on a binary

association– the values of the attributes select a unique related object or a

set of related objects from the entire set of objects– it is an index on the traversal of an association– qualified object vs target object– a qualifier always acts on an association whose multiplicity is

many in the target direction

• The purpose of the qualifier is to reduce the multiplicity to one by adding the qualifier so that a query can be assured of returning a single value

Bank

account #

Person

*

1 multiplicity after qualification

targetclass

qualifiedclass

qualifier

(bank, accont#) -> one personone person -> many (bank, account #)

28

Qualifiers

• Example

Directory

filename

File

*

0..1

(directory,filename) -> o or 1filedirectory -> many filesfile -> many (directory, filename)file-> many directoriesfile -> many file names

Directory

filename

File

*

0..1

1

*

{same}

same but different level ofdetails

(directory,filename) -> o or 1filedirectory -> many filesfile -> many (directory, filename)file-> 1 directoryfile -> many file names

29

Qualifiers

• Qualified Association in NextGen POS

ProductCatalog

ProductSpecification

itemID Contains

ProductCatalog

ProductSpecification

Contains 1..*

multiplicity reduced to 1

(a)

(b)

qualifier

1

11

30

Roles

• Role names

• Roles as Concepts vs Roles in Associations

Flight CityFlies-to* destination

role name

describes the role of a city in theFlies-to association

Person

*parent

Creates

2

child

1

Store PersonEmploys-to-handle-sales cashier

Employs-to-manage manage

r

**

Manages

*worker

manager

Store

Cashier

ManagerEmploys

*

Employs

*

roles as concepts

Manages

*

roles in associations

1

1

1

1 1

31

Derived Elements

• Derived element is an element that can be computed from other elements and is included for clarity

• It is logically redundant and adds no semantic information

Person

birthdate/age { age = currentDate-

birthdate }

Company

Person

1

*

1

* Department

worksForDepartment

/worksForCompany

derivedassociation

date/totaltime

Sale

derived attribute

32

Constraints on Associations

• Ordered

• Exclusive-OR

SalesLineItem1..*{ordered

}

Sale

... 1there is some kind ofordering, such as byorder added

Insurancecompany

Insurancecontract

Person Compnay

{or}

1

0..*

1..* 1..*

0..*

OO Methodology Elaboration Iteration 3 – Part 1 Refining Models.

Documents

base use casethe base

base use caseextensions

modular waya base use

base use casethe extension

relationshipuse case

case accesses

handle credit paymentuse

handle check paymentuse