elaboration phases moving to design

8/8/2019 Elaboration Phases Moving to Design

1/28

RUP: Elaboration Phases

Moving to Design


2/28

Domain Model (partial) for POS

System: Adding Attributes


3/28

SSD for a Process Sale scenario


4/28

Moving to Design

Design is initiated mainly in the UP elaboration phaseiterations,

but is iteratively deepened through the rest of theproject plan

The idea is to design

the actual software artifacts

but not build them

analogy might be blueprints for a building


5/28

Moving to Design

The three key design issues (in the object-orientedparadigm): must create the objects

must create the operations must assign responsibility for the operations to appropriate

objects

Artifacts associated with design

software contract (already done)

interaction diagram (today) sequence diagram

communication (collaboration) diagram

Class diagram (today)

Some other possibly (later)


6/28

How do we create the Objects?

Look at the domain model

choose objects associated with the real world

makes initial design easier helps in assigning operations to objects

helps in later maintenance: as the world changes it is clearerwhat is impacted in the software

There will likely be internal objects at the

presentation and services layer they will reflect natural categories at their layer

Design patterns

standard software design clichs that can recommend objects


7/28

How do we create the operations? The first place to look

at the system sequence diagrams,

gives the main operations that cross the system boundary

The next place to look

At the use cases, especially fully dressed ones

the main success scenario will suggest the operations crucialto carrying out that success scenario

alternative scenarios will suggest other operations

Design patterns

standard software design clichs that can recommendoperations

A Key Difficulty

create new operations or do your job with existing ones?


8/28

Assigning Operations to Objects

(details later) The main technique used in assigning operations to

objects is design patterns

GRASP principles (Larman)

Expert

Creator

Low Coupling

High Cohesion

Indirection

Protected Variations

GoF (Gang of Four) design patterns

massive number of design patterns created since GoF, for generaland special purposes


9/28

Interaction Diagrams Forevery operation it is useful to diagram the steps it

carries out,

the main message passing behaviour to achieve theoperation

Interaction diagrams allow this to be done

at level of abstraction that is more conceptual than code

Two kinds sequence diagrams: essentially the same syntax as system

sequence diagrams, but for internal system operations

communication (collaboration) diagrams


10/28

Sequence Diagram Syntax

: Register : Sale

msg2()

msg3()

msg1()

msg4()

msg5()


11/28

Communication Diagram Syntax

;ClassAmsg1() :ClassB1: msg2( )

:ClassC

1.1: msg3()

2.1: msg5()

2: msg4( )

:ClassD

2.2: msg6()

first second

fourth

sixth

fifth

third


12/28

enterItem Sequence Diagram

: Re gisterenterItem

(item ID , quantity)

: ProductC atalog

spe c := getSpecifica tion( itemID )

{

enterItem( id, qty)

{

.. .// local visibility via assignment of returning object

ProductSpecification spec = catalog.getSpecification(id);

.. .

}}


13/28

Tips About Interaction Diagrams Choosing between sequence and communication

diagrams sequence diagram shows explicit time-line, reading down,

but is awkward to develop since you must anticipate everyobject that participates in the message before hand

(see system sequencepay by creditscenario, next slides)

communication diagram seems more jumbled,

but is more flexible and closer to functional styles of method

creation


14/28


15/28

POS Pay by Credit Scenario

makeCreditPayment

(credN um, expiryDa te)

reply := requestApproval(request)

postRe ceivable( rece ivable )

actor

:CreditAuthorizationService

actor:Accounts

enterItem(itemID, quantity)

:NextGenPOSSystem

: C ashier

endSale()

Process S alePay by C redit Scenario

description, total

total with taxes

* [more items]

makeNewSale()

actor:TaxCalculator

taxLineItems :=getTa xes( s ale )

postSale( s ale )


16/28

The Class Diagram Analogy: the class diagram is to design what the

domain model is to analysis

The class diagram summarizes the main objects in the actual design (classes)

the main associations and cardinalities between objects

the main attributes and their type in each object

the main operations assigned to each object (methods) The class diagram is a snapshot of

what the main classes will be in the software and

what methods each will be responsible for


17/28

POS Class Diagram

SalesLineItem

quantity : Integ er

getSubtotal()

ProductCatalog

.. .

getSpecification(...)

ProductSpecification

description : Textprice : MoneyitemID : ItemID

.. .

Store

address : Addressname : Text

addSale(...)

Payment

amount : Mone y

.. .

Contains

1..*

Contains

1..*

Register

endSale()

enterItem(...)makeNewSale()

makePayment(...)

Sale

date : Date

isComplete : Booleantime : T ime

becomeComplete()makeLineItem(...)

makePayment(...)getTotal()

Captures

Houses

Uses

Looks-in

Paid-by

Describes

1 1

1

1 1

1

1

1

1

1

1

1

1

*

Logs-completed4 *


18/28

The Domain Model is notthe Class

Diagram

Payment

amount

ale

da te

t me

Pays-for

Payment

amount: Money

ge tBalance (): Money

Sale

da te : D a te

startT me : T me

ge tTotal(): Money. . .

Pays-for

UP D o m a i n Mo d e l

Stakeholder's view ofthe noteworthy concepts in the doma in.

UP D esign Mo d e l

The object-orien ted developerha s taken inspiration from the real world do ma inin crea ting software c lasses.

The refore, the representational gap be tween how s takeholders c onceive the

domain, and its representation in software, has bee n lowered.

1 1

1 1

A Paymentin the D omain Model

is a concept, buta Paymentin

the D esign Model is a softwareclass. They are no tthe same

thing, b utthe formerinspiredthe

naming and definition ofthelatter.

This reduces the

representa tional gap .

This is one ofthe big ideas in

objecttechnology.

inspires

objectsand

names in


19/28

Visibility: the ability of one object tosee or have a reference to another object

attribute visibility

B is visible to class A because B is an attribute of A: remains aslong as class A exists

parameter visibility

B is visible to class A because B is passed as a parameter of amethod of A: remains only while method is being executed

local visibility

B is visible to class A because B is declared as local within amethod of A: remains only while method is being executed

global visibility

B is visible to class A because B is global to A: permanent


20/28


21/28

ParameterVisibility

2: akeLineIte (desc, qty)enterIte (id, qty)

1: desc = get roduct esc(id)

2.1: create(desc, qty)

: egister :Sale

: roduct

atalog

sl : SalesLineIte akeLineIte ( roduct escription desc, int qty)

{

...

sl = new SalesLineIte (desc, qty);

...

}

B is visible to class A because B is passed as a parameter of a method of A:

remains only while method is being executed


22/28

Local VisibilityB is visible to class A because B is declared as local within a method

of A: remains only while method is being executed

: egisterenterIte

(ite I , qua ntity)

: ro du ct a ta lo g

de sc = ge t roduct e sc( ite I )

e n te rIte ( id , q ty){

.. .

/ / local visibility via assign ent of returning object

ro du ct e sc rip tio n d e sc = ca ta lo g.g e t ro du ct e s (id );

.. .

}


23/28

Global Visibility B is visible to class A because B is global to A:

permanent, because it persists as long as A and B

exists One way to achieve global visibility is to assign an

instance to a global variable, which is possible in

some languages, such as C++, but not others, such

as Java.

The preferred method to achieve global visibility is to

use the Singleton pattern, which we will discuss later


24/28

Assigning Responsibility What objects get which responsibilities?

Responsibilities for doing an object doing something itself, such as:

creating an object

doing a computation

initiating an action to be carried out by other objects

controlling and coordinating activities in other objects

Responsibilities for knowing knowing about private encapsulated data

knowing about related objects

knowing about things it can derive or calculate

There are good vs bad ways of assigning

responsibilities


25/28

Larmans GRASP Principles Information Expert

assign a responsibility to the information expert, the class that hasthe information necessary to fulfil the responsibility

Creator a version of expert for creation: assign to B the responsibility of

creating an instance of class A if

B contains A

B aggregates A

B has initializing data for A

B records A B closely uses A

Controller

a version of expert for handling system events: the classresponsible for handling system events should be a classrepresenting the overall system, device or subsystem or a classrepresenting a use case scenario within which the system eventoccurs


26/28

The GRASP Principles (II) Low Coupling (evaluative)

assign responsibilities so that unnecessary coupling remains low

High Cohesion (evaluative)

assign responsibilities so that cohesion remains high, objects arefocussed

Indirection

assign the responsibility to an intermediate object to mediatebetween objects so they arent tightly coupled

Protected Variations

identify points of predicted variation or instability and assignresponsibilities to create a stable interface around them

Polymorphism

when related alternatives or behaviours vary by type, assign theresponsibility for the behaviour using polymorphic operations to thetypes for which the behaviour varies


27/28

Use of the GRASP Principles

2: mak eLineItem(s pec, qty)enterItem(id, qty)

1: spec := getSpecification(id)

2.1: create(spec, qty)

1.1: spec := find(id)

:Register :Sale

:Product

Catalog

sl: SalesLineItem

SalesLineItem:SalesLineItem:Product

Specification

2.2: add(sl)

by Expert

by Controller

T his find mes sa ge is to theMap object (the multiobject),not to a ProductSpecification.

C A U T I O N :

T his is a multiobjec t collec tion (s uch a s a M ap), not a

ProductSpe cifica tion. It ma y contain m any

ProductSpecifications.

C A U T I O N :

This is a multiobject collection (such as a List), not a

SalesLineItem. It may contain many SalesLineItems.

by Creator

add the newly created

Sa les LineItem instance to the

multiobject ( e.g., List)


28/28

Relationship of

Various UP

Artifacts

: System

enterItem(id, quantity)

...

Process S ale

1. Customer

arrives ...

. Ca shier

makes new

sale.3. ...

Use Cases System Sequence Diagrams

makeNewSale()

Sale

timeStamp

Register

...11

ProductCatalog

. . .

domain concepts

system

events

Dom a in M ode l

Us e -Ca se M o de l

De s ign M ode l

: Register

enterItem(id, quantity)

: ProductCa talog

spec := getSpec ification( id )

addLineItem( spe c, quantity )

: Sale

. . .

use-case

rea liz ation with

interactiondiagrams

conceptualclasses in

the

domain

inspire the

names ofsome

software

classes in

the des ign

makeNewSale()

create()

Register

...

makeNewSale()enterItem(...)

...

ProductCatalog

...

getSpecification(...) : ProductSpecification

...

the des ign

classes

discovered

while d es igning

UCR s can besumma riz ed in

class diagrams

Cashier

ProcessS a l e

Use C ase Diagrams

: Cashier

1 1

. . .

. . .

Captured-on

elaboration phases moving to design

Documents