design - uvic.ca

35
Design

Upload: others

Post on 18-Jan-2022

5 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Design - UVic.ca

Design

Page 2: Design - UVic.ca

Design• Iteratively Do the Right Thing, Do the Thing Right.

– The requirements and object-oriented analysis has focused on learning to do the right thing

– By contrast, the design work will stress do the thing right; that is, skillfully designing a solution to satisfy the requirements for this iteration.

• Furthermore, it is natural to discover and change some requirements during the design and implementation work of the early iterations.

Page 3: Design - UVic.ca

During Design…• Logical solution based on the object-oriented paradigm is

developed. • Heart is the creation of interaction diagrams, which illustrate

how objects collaborate to fulfill the requirements. – Dynamic object modeling.

• Creation of interaction diagrams requires the application of principles for assigning responsibilities– Design patterns.

• After—or in parallel with—drawing interaction diagrams, (design) class diagrams can be drawn. – These summarize the definition of the software classes (and interfaces) that

are to be implemented in software.

Page 4: Design - UVic.ca

Sequence and CommunicationDiagrams

• The term interaction diagram is a generalization of two more specialized UML diagram types.

• sequence diagrams • communication diagrams

• Both can be used to express similar message interactions.

Page 5: Design - UVic.ca

• Sequence diagrams illustrate interactions in a fence format, in which each new object is added to the right.

: A myB : B

doTwo

doOne

doThree

Page 6: Design - UVic.ca

What might this represent in code?

public class A{private B myB = new B();

public void doOne(){myB.doTwo();myB.doThree();

}// …

}

Page 7: Design - UVic.ca

• Comunication diagrams illustrate object interactions in a graph or network format, in which objects can be placed anywhere on the diagram

: A

myB : B

1: doTwo

2: doThree

doOne

Page 8: Design - UVic.ca

Type Strengths Weaknesses

Sequence •clearly show sequence or time ordering of messages

•simple notation

•space economical—flexibility to add new objects in two dimensions

•forced to extend to the right when adding new objects; consumes horizontal space

Collaboration •difficult to see the sequence of messages

•more complex notation

Page 9: Design - UVic.ca

: Register : Sale

makePayment (cashTendered )

makePayment (cashTendered )

: Paymentcreate(cashTendered )

Sequence Diagram: POS Example

Page 10: Design - UVic.ca

Communication Diagram: POS Example

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Payment

makePayment(cashTendered)

direction of message

Page 11: Design - UVic.ca

In Rational Rose…

Create an actor in the use case view and drag it in the sequence diagram. There can’t be links from nowhere.

Enable Focus of Control. Tools->Options->…

For ‘create’ message drag the arrow to inside Payment.

Page 12: Design - UVic.ca

In Rational Rose…

Create an actor in the use case view and drag it in the communication diagram. There can’t be links from nowhere.

Disable the default collaboration diagram numbering. Tools->Options->…

Page 13: Design - UVic.ca

Visual Paradigm for UML

http://www.visual-paradigm.com/product/vpumlhttp://www.visual-paradigm.com/product/vpuml/vpumldocuments.jsp

Page 14: Design - UVic.ca

:Sale

lifeline box representing an unnamed instance of class Sale

s1 : Sale

lifeline box representing a named instance

«metaclass»Font

lifeline box representing the class Font, or more precisely, that Font is an instance of class Class – an instance of a metaclass

sales: ArrayList<Sale>

lifeline box representing an instance of an ArrayList class, parameterized (templatized) to hold Sale objects

sales[ i ] : Sale

lifeline box representing one instance of class Sale, selected from the salesArrayList <Sale> collection

related example

Terminology

Page 15: Design - UVic.ca

Messages can also go from right to left.

Messages: Left-Right, Right-Left

Page 16: Design - UVic.ca

Two ways to return values

Page 17: Design - UVic.ca

Messages to “self” or “this”

Page 18: Design - UVic.ca

Frames: LoopTo add a loop condition:

• Right click on the frame

• From thePop-up menu choose “manage operands”

• Add a constraint such as ‘more items’

Page 19: Design - UVic.ca

Frames: Conditional Messages

Page 20: Design - UVic.ca

Frames: Conditional Messages (UML 1 style)

Page 21: Design - UVic.ca

Frames: Mutually Exclusive Conditional Messages

Page 22: Design - UVic.ca

Iteration Over a Collection

Or we can leave things more implicit like here.

Page 23: Design - UVic.ca

How to Relate Interaction DiagramsSelect the ‘Interaction use’ frameRight click and open the specifications. Specify that it refers to another interaction diagram. Close the specifications. Double click on the ref frame. It will open another (empty) diagram. Draw there the ‘authenticate user’ part. Name this new diagram ‘AuthenticateUser’

Page 24: Design - UVic.ca

Messages to Classes to Invoke Static (or class) Methods

Page 25: Design - UVic.ca

Polymorphic Messages Payment {abstract}

authorize() {abstract}...

CreditPayment

authorize()...

DebitPayment

authorize()...

Payment is an abstract superclass, with concrete subclasses that implement the polymorphic authorize operation

:Register

authorizedoX

:Payment {abstract}

polymorphic message object in role of abstract superclass

stop at this point – don’t show any further details for this message

:DebitPayment

doAauthorize

:Foo

doB

:CreditPayment

doXauthorize

:Bar

separate diagrams for each polymorphic concrete case

Page 26: Design - UVic.ca

Communication diagramExamples

Page 27: Design - UVic.ca

Links1: makePayment(cashTendered)2: foo

2.1: bar: Register :Sale

link line

1: msg22: msg33: msg4

3.1: msg5: Register :Sale

all messages flow on the same link

msg1

Page 28: Design - UVic.ca

Messages to “self” or “this”

: Register

msg1

1: clear

Page 29: Design - UVic.ca

Creation

1: create(cashier)

: Register :Sale

create message, with optional initializing parameters. This will normally be interpreted as a constructor call.

«create»1: make(cashier)

: Register :Sale

if an unobvious creation message name is used, the message may be stereotyped for clarity

1: create(cashier): Register :Sale {new}

Three ways to show creation in a communication diagram

Page 30: Design - UVic.ca

Message Number Sequencing

: Amsg : B1: msg

: C

1.1: msg

2.1: msg

2: msg

: D

2.2: msg

first second

fourth

sixth

third

fifth

Page 31: Design - UVic.ca

Conditional Messages

1 [ color = red ] : calculate: Foo : Bar

message1

conditional message, with test

1a [test1] : msg2

: A : B

: C

1a.1: msg3

msg1

: D

1b [not test1] : msg4

1b.1: msg5

: E

2: msg6

unconditional after either msg2 or msg4 1a and 1b are mutually

exclusive conditional paths

Page 32: Design - UVic.ca

Looping

1 * [ i = 1..n ]: num = nextInt: SimulatorrunSimulation : Random

iteration is indicated with a * and an optional iteration clause following the sequence number

Page 33: Design - UVic.ca

Iteration Over a Collection1 * [i = 1..n]: st = getSubtotal: Salet = getTotal

This lifeline box represents one instance from a collection of many SalesLineItem objects.

lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value comes from the message clause.

lineItems[i]:SalesLineItem

this iteration and recurrence clause indicates we are looping across each element of the lineItems collection.

1 *: st = getSubtotal: Salet = getTotal lineItems[i]:SalesLineItem

Less precise, but usually good enough to imply iteration across the collection members

Page 34: Design - UVic.ca

Messages to Classes to Invoke Static (or class) Methods

1: locs = getAvailableLocales: Foo «metaclass»

Calendar

doX

message to class, or a static method call

Page 35: Design - UVic.ca

Polymorphic Messages

:Register authorizedoX :Payment {abstract}

polymorphic message

object in role of abstract superclass

:DebitPayment

authorize

:Foo

stop at this point – don’t show any further details for this message

separate diagrams for each polymorphic concrete case

doAdoB :CreditPayment

authorize

:BardoX