6. Basic Behavioral Modeling

Interactions

Sung KimCS6359

Chapter 15 Slide 2

Overview

• Interactions– Roles– Links– Messages– Actions– Sequences

• Modeling flows of control.• Creating well-structured algorithms.

Sung KimCS6359

Chapter 15 Slide 3

Terms & Concepts

• Interaction—behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose.

• Message—specification of a communication between objects that conveys information with the expectation that activity will ensue.

Sung KimCS6359

Chapter 15 Slide 4

Interactions• Static representation of objects working to

complete some action.• Introduce messages between objects and classes.– Invocation of an operation.– Construction or destruction of an object.

• Models flow of control within an operation.– Identify how messages are dispatched across time.– Focus on the structural relationships among objects

involved in an interaction.

Sung KimCS6359

Chapter 15 Slide 5

Interactions (cont’d)

• Properties of well-structured interactions– Efficient– Simple– Adaptable– Understandable

Sung KimCS6359

Chapter 15 Slide 6

Objects & Roles

• Objects within an interaction– Concrete—something from the real world.– Prototypical—representative instance of

something from the real world.• Collaborations use strictly prototypical things.• Prototypical instances of interfaces and abstract types

are valid.

– Can be identified from class diagrams.

Sung KimCS6359

Chapter 15 Slide 7

Links

• Semantic connection among objects.• An instance of an association or dependency.• Provide a passage for messages.

Person

+ setCompensation( s : Salary )+ assign( d : Department )…

Company1..* *

employee employer

p : Person : Company

assign( development )

named objectlink

anonymous object

message

Sung KimCS6359

Chapter 15 Slide 8

Link Existence

• Model operation needed to create link.• Adorn end of link with stereotype.– Association– Self– Global– Local– Parameter

Sung KimCS6359

Chapter 15 Slide 9

Messages

• Directed line near link.• Name of operation that must be defined on

target.

t : AirTrafficPlanner p : FlightPlan

1 : getPositionAtTime( t )

objectlink

sequence number1.1 : getLastCheckpoint( )

message

Sung KimCS6359

Chapter 15 Slide 10

Modeling Actions

•Call*—invokes an operation on an object.•Return—returns a value to the caller.•Send*—sends a signal to an object.•Create—creates an object.•Destroy—destroys an object.

*Essentially the same, but send implies an event notification or control flow between objects.

Sung KimCS6359

Chapter 15 Slide 11

Actions Depicted

: TicketAgent

c : Client p : PlanningAgent

<<create>>

setItenerary( i )calculateRoute()

route

<<destroy>>X

notify()

object

create

actual parameter

return return value

destroy

send

call on self

Sung KimCS6359

Chapter 15 Slide 12

Sequencing

• A stream of messages where actions are delegated forms a sequence.

• The beginning of each sequence is rooted in some process or thread.

• Each thread defines a distinct flow of control.• Messages are ordered in sequence by time.– Represented by a sequence number followed by a colon.

Sung KimCS6359

Chapter 15 Slide 13

Procedural Sequencing

• Most common.• Each message within the same operation is

numbered sequentially.• Nested messages are prefixed with the

sequence number of the invoking operation.• Rendered with filled solid arrow.

Sung KimCS6359

Chapter 15 Slide 14

Flat sequencing

• InfrequentNot recommended for most situations.

• Each message is numbered sequentially in order of timing.

• Shows progression of control.• Rendered with stick arrowhead.

Sung KimCS6359

Chapter 15 Slide 15

• Procedural Sequence

• Flat Sequence

Sequencing Depicted

:View c : Controller :Cache2 : clickAt( p ) 2.2 : putRecentPick( l )

2.1 : l = findAt( p )

c : Caller :Telephone :Exchange1 : liftHandset() 2 : assertCall()

flat flow of control

sequence numbermessage sequence number

sequence numbermessage

nested of control

Sung KimCS6359

Chapter 15 Slide 16

Thread Identification

• Message sequence number prefixed with thread identifier.

• Helps distinguish multiple threads of control.• Consider coloring messages to match threads.

Sung KimCS6359

Chapter 15 Slide 17

Creation & Destruction

• Adorn with constraints.– new– destroyed– transient

c : Controller

1 : <<create>>2.3 : update( p )4 : <<destroy>>

{transient}

Sung KimCS6359

Chapter 15 Slide 18

Representing Interactions

• Sequence diagram– Emphasizes time ordering of messages.– Depicts the lifeline of objects.

• Collaboration diagram– Emphasizes structural organization.– Potentially easier to model complex interactions.

Sung KimCS6359

Chapter 15 Slide 19

Modeling Flow of Control (steps)

• Set the context for the interaction.• Set the stage by identifying participating

objects.• If emphasizing the structural organization,

identify related links.• Specify the messages that pass from object to

object in time order.

Sung KimCS6359

Chapter 15 Slide 20

Flow of Control by Time

s1 : StockQuoteSubscriberp : StockQuotePublisher

attach(s1)

s2 : StockQuoteSubscriber

attach(s2)

notify()

update()

update()

getState()

getState()

Sung KimCS6359

Chapter 15 Slide 21

Flow of Control by Organization

s1 : StockQuoteSubscriber

p : StockQuotePublisher

s2 : StockQuoteSubscriber

1 : attach(s1)6 : getState()

2 : attach(s2)7 : getState()

3 : notify()

4 : update()

5 : update()

Sung KimCS6359

Chapter 15 Slide 22

Hints & Tips

• A well-formed interaction.– Encompasses only the objects that work together

to carry out some behavior bigger than the sum of the elements.

– Has a clear context.– Optimally balances time and resources.– Promotes adaptability since operations may be

likely to change.– Understandable

Sung KimCS6359

Chapter 15 Slide 23

Hints & Tips (cont’d)

• Depicting interactions.– Choose an emphasis for the interaction.– Show only the object properties that are

important in its context.– Show the message properties that are important

in its context.

Sung KimCS6359

Chapter 15 Slide 24

Summary

• Interactions– Roles– Links– Messages– Actions– Sequences

• Modeling flow of control.

6. Basic Behavioral Modeling

Use Case Diagrams

Sung KimCS6359

Chapter 16 Slide 26

Overview

• Use cases– Include– Extend

• Actors• Modeling behavior of an element.• Realizing use cases with collaborations.• Modeling the context of a system.• Modeling the requirements of a system.• Testing from use cases.

Sung KimCS6359

Chapter 16 Slide 27

Use Case Definition

• …User Guide– Description of a set of sequences of actions that a

system performs to yield an observable result of value to an actor.

• Object-oriented Software Engineering; Jacobson, ‘92– Narrative document that describes the sequences

of events of an actor using a system to complete a process.

Sung KimCS6359

Chapter 16 Slide 28

Use Cases

• Defines “what” without specifying “how”!• Specify desired behavior.• Promotes communication among:– End users– Domain experts– Architects– Developers– Information Modelers

Sung KimCS6359

Chapter 16 Slide 29

Use Cases (cont’d)

• Represents a set of functional requirements on a system.

• Achieve a tangible amount of work.• Provide a starting point for test cases.

Process loan

actoruse case

name

LoanOfficer

Sung KimCS6359

Chapter 16 Slide 30

Actor

• Coherent set of roles that users assume when interacting with a system.

• Human or automated systems.• Represents an individual interacting with the

system in a specific way.• Live outside the system.• Connected to use cases through associations.automated system

<<stereotype>>

Sung KimCS6359

Chapter 16 Slide 31

Use Cases and Flow of EventsTypical Course of Events

• Usually described in informal text or formal structured text.

• Visualized in interaction diagrams; commonly system sequence diagram.

• Exceptional flows or variations depicted separately.

• Identifies when the use case begins and ends.

Sung KimCS6359

Chapter 16 Slide 32

Use Cases and Scenarios

• Scenarios describe a particular sequence through a use case.

• Real or prototypical values are used.• Each sequence defines a set of system operations.• System operation:– System level function.– A single interaction between an actor and the system.

Sung KimCS6359

Chapter 16 Slide 33

Use Cases and Collaborations

• Collaboration—a society of classes and other elements that work together to implement the behavior of a use case.

• Realization of a use case.

Place order

Order managementuse case

collaborationrealization

Sung KimCS6359

Chapter 16 Slide 34

Organizing Use Cases

• Use packages.• Factor common behavior through

relationships.– Generalization– Extend– Include

Sung KimCS6359

Chapter 16 Slide 35

Generalized Use Case

• Child inherits behavior and meaning from parent.

• Child may be substituted any place for a parent.

• Rendered same as class generalization.

Sung KimCS6359

Chapter 16 Slide 36

Use Case Inclusion

• Base use case explicitly incorporates the behavior of another use case.

• The included use case cannot stand alone.• Example of delegation.• Rendered as a stereotyped dependency.

Sung KimCS6359

Chapter 16 Slide 37

Extending a Use Case

• Base use case incorporates the behavior of another use case.

• The extending use case indicates where the extended behavior occurs in the base use case.

• Base use case only extended through extension points.

• Used to model optional behavior.• Rendered as a stereotyped dependency.

Sung KimCS6359

Chapter 16 Slide 38

Use Case Organization Example

Track order generalization

Validate user

Retinal scan

Check password

Place rush order

Place order

Extension points:set priority

extension

inclusion

extension point

<<extend>>

(set priority)

<<include>>

<<include>>

Sung KimCS6359

Chapter 16 Slide 39

Example (cont’d)

Track OrderMain flow of control : Obtain and verify the order number. Include (Validate user). For each part in the order, query its status, then report back to the user.

Place OrderMain flow of control: Include (Validate user). Collect the user’s order items. (set priority). Submit the order for processing.

Sung KimCS6359

Chapter 16 Slide 40

Modeling the Behavior of an Element

• Element could represent– The system as a whole.– A subsystem.– An individual class.

• Important reasons:– Allows domain experts to specify external view to

sufficient details for developers to continue.– Provides a means for developers to approach and

understand an element.– Provides a basis for testing.

Sung KimCS6359

Chapter 16 Slide 41

Modeling Behavior (steps)

• Identify actors that interact with the element.• Organize actors by generalized and more specialized

roles.• Consider the primary ways actors interact with the

element.• Consider the exceptional ways actors interact with an

element.• Organize the behaviors as use cases.

Sung KimCS6359

Chapter 16 Slide 42

Hints & Tips on Use Cases

• Well structured use case:– Names a single, identifiable and atomic behavior.– Factors common behavior through inclusion.– Factors variants by pushing behavior through

extension.– Describes the flow of events such that a non-technical

person can follow.– Clarified by a minimal set of scenarios that specify the

normal and variant semantics.

Sung KimCS6359

Chapter 16 Slide 43

Hints & Tips on Use Cases (cont’d)

• Depicting a use case:– Show only the use cases that are important to

understand the behavior in a particular context.– Show only the actors related to those use cases.

Sung KimCS6359

Chapter 16 Slide 44

Use Case Diagrams

• Use case diagram—diagram that shows a set of use cases and actors and their relationships.

• Used to visualize the behavior of a system.• Allows users to comprehend the interactions

with the system.

Sung KimCS6359

Chapter 16 Slide 45

Use Case Diagram (an example)

system boundary

Place phone call

extension

actor

«extend»

Use scheduler

Receive phone call Receive additionalcall

Place conferencecall

«extend»CellularNetwork

use case

association

Cellular Telephone

Sung KimCS6359

Chapter 16 Slide 46

Use Case Diagram Contents

• Use cases• Actors• Relationships– Dependencies– Generalizations– Associations

• Notes and constraints

Sung KimCS6359

Chapter 16 Slide 47

Common Uses

• Model the context of a system.– Identifying the system border.– Defining what is inside the system.– Defining what is outside the system.

• Model the requirements of a system.– What the system should do.– Independent of how the system will do it!

Sung KimCS6359

Chapter 16 Slide 48

Modeling the System Context• Identify the actors that surround the system.– Which groups need help from the system.– Which groups are needed to execute system functions.– Which groups interact with external hardware.– Which groups perform secondary functions.

• Organize actors using generalization if appropriate.

• Use stereotypes for actors to aid understanding.• Populate a use case diagram with actors and

associate with system use cases.

Sung KimCS6359

Chapter 16 Slide 49

Context Example

Perform cardtransaction

CustomerCredit Card Validation System

Processcustomer bill

Reconciletransactions

Managecustomeraccount

CorporateCustomer

RetailInstitution

Sung KimCS6359

Chapter 16 Slide 50

Modeling System Requirements

• Establish the system context.• Consider the behavior that each actor expects from

the system.• Name common behaviors as use cases.• Factor common behavior; extensions, inclusions, and

generalizations.• Model the actors, use cases, and relationships into a

use case diagram.• Adorn with notes for non-functional requirements.

Sung KimCS6359

Chapter 16 Slide 51

Modeling System Test Cases

• For each use case, identify its flow of events.• Generate a test script for each flow.– Obtain initial state from preconditions.– Test success against post conditions.

• Build necessary test drivers to simulate scenarios using test scripts.

• Use tools to regression test using the tests.

Sung KimCS6359

Chapter 16 Slide 52

Hints & Tips on Use Case Diagrams

• Well-structured use case diagrams:– Focused on communicating a single aspect of a

system’s static use case view.– Contains only actors and use cases essential to

that aspect.– Should contain sufficient detail to inform a reader

of important system semantics.

Sung KimCS6359

Chapter 16 Slide 53

Hints & Tips on Use Case Diagrams (cont’d)

• Depicting a use case diagram:– Choose a name that communicates purpose.– Minimize crossing of lines.– Physically co-locate semantically related elements.– Use notes and colors for necessary emphasis.– Only show what is more or less useful!

Sung KimCS6359

Chapter 16 Slide 54

Summary

• Use cases & Actors• Typical course of events.• Scenarios• Collaborations.• Organizing use cases.• Modeling behavior.

• Use case diagrams– Definition– Example– Contents– Common uses

• Modeling system context• Modeling system requirements• Modeling system test cases