Download - 6. Basic Behavioral Modeling
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 number 1.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