The OOA Process - II

Scenarios

The Steps of OOA - Part 1

• Identify classes (objects)• Identify structures

– Generalization (generalization-specialization, “ISA” relationship type)

– Aggregation (whole – parts, “PART-OF” relationship type)

– Association (relationship)

• Define attributes

===> Static Object diagram

===> incomplete Object Dictionary

The Steps of OOA - Part 2

• Define services (operations) via scenarios– services per object– message passing between objects– coordination of message passing– states and transitions

===> Scenarios

===> complete Object Dictionary

OOA - Messages

• Form the dynamic portion

of the object diagram (scenarios)

• Sent by

– an object (instance)

– via an active local service

• Received by

– an object (instance)

– triggering the receiving service

label

sender

receiver

A Message’s “Life-Cycle”

• Connects to an object(object_id).service

• Triggers execution of the receiving service

• Carries input-parameters for the execution of the receiving service

• Is able to transmit output-parameters back to the sending service

Message Specification

• Scenarios (diagrams):– shown as bold or dotted line– labeled with the receiving service– parameters are optional– sequence number may be optional

• Object dictionary:– exist only as elements of an object’s services– specified as part of the service specifications

Syntax for Message Specification• Typically similar to:

SEND MESSAGE TO object (object_id).service (input-parameters, output-parameters)

– object: name of an object class– service: name of a service in that object class– object_id: identifies selected instantiation

===> Complete Object Dictionary===> Informal Scenarios Analysis

Programmer

Division

Department

(2,N)

(1,1)

works-for(1,1)(3,N)

The division wants to compile a list of theprg. languages “spoken”in its departments.

list of prog-lang.

Programmer

Division

Department

Alternative 1:Using output-parametersto get to the results.

list prg-skills(wait for result)

list prg-lang(wait for result)

report prg-langs

list prg-skillslist prg-lang

Programmer

Division

Department

Alternative 2:Using separate messagesto transmit results.

list prg-skills(do not wait for result)

list prg-lang(do not wait for result)

accept prg-lang

report prog-langsaccept prg-lang

list prg-skillslist prg-langs

OOA - Services

• Exist only as elements of an object/class

• Services model functionality:– data manipulation– control sequences– communication (using messages)– state transformation– interface handling

OOA - Services

• No separate graphical representation

(part of the class and object symbols)

• Services can be– public or– private

• Specified in the object dictionary

Attributes and Services

• The data capsule principle– a service has access to all attributes of the local

object – all services of an object share attributes as a

global data area– a service provides access to attributes for other

object.services (by accepting messages)– a service can have local variables

Services and Inheritance

• Services are inherited in a classification hierarchy

• Inheritance is mandatory• Multiple inheritance is possible

=> Position common services as high in the classification hierarchy as possible=> Generic services (service overlay / polymorphism)

Employee

Manager Programmer

Inheritance

fill-in time-sheetprepare paycheck

fill-in time-sheetlist prg-langs

fill-in time-sheet

Scenarios• Show separate self-contained sequences (threads)

of execution • Typically include:

– objects

– messages

– (services)

– (attributes)

• Do usually not include– Structures

• Can be represented by different UML diagrams

Manager Programmer

Division

Department

create (1)

hire (2)

hire (3)Scenario 1:“Open a new department”

OOAD - Modeling• Differentiation between static and dynamic diagrams• Usually

– one static class diagram

– multiple diagrams modeling system dynamics• possibly with different notations to capture specific dynamics

• Everything is based on the common object dictionary– also called: model, class specifications, ...

– diagrams are only views (or projections) of this common dictionary

– diagrams have to be compatible with• the dictionary and

• each other

Rememeber

Diagrams in UML • Requirements Diagrams (Use-Cases, Scenarios)• Class and Object diagrams – Static, structural view

• Classes & Objects• Attributes• Methods• Structures

– Association, Generalisation, Aggregation

• Behavioral diagrams- dynamic view– Collaboration Diagrams – Sequence Diagrams – Statechart Diagrams – Activity Diagrams

• Implementation diagrams– Component diagrams– Deployment diagrams

==> UML diagrams for representing “scenarios”

Sequence diagrams - example (1)

Sequence diagrams (1)• A sequence diagram shows a subset of the

possible interactions between objects in a system.– context sensitive “slicing“ of all possible interactions– a view on the dynamics of the system– focus on timing of interaction

• related operations can be deduced (less detail than in collaboration diagram)

• messages seen very much as events• relations and attributes are not shown

• Alternatives are– collaboration diagrams, activity diagrams, use cases– all have specific focus and strength

Sequence diagrams (2)• A sequence diagram is used to model

– a snapshot of interactions (events) within a time-frame– a scenario, (partial) process or transaction

• The diagram includes– objects (instances)

• only objects involved in the scenario• all objects only by name• the “life-line” of an object: the dimension of time• the “focus of control” (Steuerungsfokus): marks the active,

controlling object – messages

• messages are seen very much like events• parameters & conditions in messages are possible but unusual• returns/responses to messages are usually modeled separately

life-line

controlfocus

message specification

Sequence diagrams - notation (1)

:obj2:obj1

msg_x ( )

response_x

:obj3

msg_y ( )

response_y

contstraint

t1

t2

{t2 -t1 < delta}

selfdelegation

:obj1

indirectrecursion

Sequence diagrams - notation (2)

:obj2

msg_x ( )

response_x

msg_y ( )

response_y

:obj1

Sequence diagrams - notation (3)

:obj2

msg_x ( )

response_x

new ( )

delete ( )

create and

deleteobjects

:obj3

Sequence diagrams - notation (4)

:obj2:obj1

[cond1] msg_x1 ( )

response_x1

msg_y ( )

response_y

[cond2] msg_x2 ( )

response_x2

conditions and

alternative life-lines

Sequence diagrams - message (event) specification

• message & parameters - name of the message - usually the name of the operation to be invoked in the receiving object - usually not the full signature of the operation (check there) - iteration can be modeled using *

• result - unusual; usually modeled using a separate arrow - name of the result delivered by the message

• condition - boolean expression - use with caution - if many conditions are necessary, switch to activity diagrams

Collaboration diagrams

:OrderMgr :Component

:Customer

1.1: pcPrice:=getPrice( ):PersComp

:ShoppingCart

1: offer:=makeOffer(cid, pcid)

1.2: getDiscountRate( pcPrice )

1.1.1.*: getCost( )

askForOffer( )

1.3: getNickname( )

:Order

1.4: createOrder( )

• A collaboration diagram is used to model a snapshot of interactions between objects, forming a scenario.

Possible sequence diagram for the collaboration diagram on page 29

:OrderMgr :Component:Customer :PersComp:ShoppingCart

:Order

askForOffer()

makeOffer(cid,pcid)

getprice()

*getcost()

pcPrice

getDiscountRate(pcPrice)

getNickname

createOrder()offer

Sequence diagrams - example (3): operator assistet call

CallerCaller OperatorOperator CalleeCallee

time

call

ack

number

call

ack

talk

transfer

Get some practice!

:Atm

atm #

req_withdrw

Account

acct #balancesec-codestate

withdrw :Trans_Collection

trans_record

1: withdrw (..) 1.1: addElement (transaction) X

:Savings_Acct

Translate:CollaborationDiagram 3-aVersion 2.0

user

“parameter” acct#