Positive Behavioral Supports for Students with ASD Module 8 Lesson 1.
Module 3: Advanced Features – Part II: Behavioral Diagrams
description
Transcript of Module 3: Advanced Features – Part II: Behavioral Diagrams
![Page 1: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/1.jpg)
1
Module 3: Advanced Features –Part II: Behavioral Diagrams
![Page 2: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/2.jpg)
2
3 basic building blocks of UML - DiagramsGraphical representation of a set of elements.Represented by a connected graph: Vertices are things; Arcs are relationships/behaviors.5 most common views built from UML 1.x: 9 diagram types. UML 2.0: 12 diagram types
Behavioral DiagramsRepresent the dynamic aspects.
– Use case– Sequence;
Collaboration– Statechart– Activity
Structural DiagramsRepresent the static aspects of a system.
– Class;
Object– Component– Deployment
Behavioral Diagrams
– Use case
– Statechart– Activity
Structural Diagrams
– Class;
Object– Component– Deployment– Composite Structure– Package
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview– Timing
![Page 3: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/3.jpg)
3
Use Case Diagrams
Behavioral Diagrams
– Use case
– Statechart– Activity
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview– Timing
![Page 4: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/4.jpg)
4
Use Cases
Scenarios describe a single path, or a particular sequence E.g., Use Case: Order Goods
Scenario 1: all goes well Scenario 2: insufficient funds Scenario 3: out of stock
System test cases: Generate a test script for each scenario (flow of events). Obtain initial state from preconditions. Test success against post conditions.
When to Use Use Cases Fowler’s View: do use cases first before object modeling
Capture the simple, normal use-case first For every step ask “What could go wrong?” and how it might work out differently Plot all variations as extensions of the given use case
Another view: do object modeling first, then use cases Another: iterate model - use case - model - use case ... What did we do?
![Page 5: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/5.jpg)
5
Organizing Use Cases
• Generalization, Extend, Include/Use, packages
Track ordergeneralization
Validate user
Retinal scan
Check password
Place rush orderPlace order
Extension points:set priority
extension
inclusion
extension point
<<extend>>
(set priority)
<<include>>
<<include>>
• Track Order - Obtain and verify the order number; For each part in the order, query its status, then report back to the user.
• Place Order - Collect the user’s order items. (set priority). Submit the order for processing.
common to multiple use cases;Often no actor may be associated with a ‘used’ use case
UML 1.3: Replaces <<uses>> relationship with Generalization and <<include>> dependency (http://www.jeckle.de/files/viewfront.pdf)
does a bit more or deals with a special situation
extension use case
inclusion use case
child use case
base use case
![Page 6: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/6.jpg)
6
A Use Case Template (http://www.bredemeyer.com/pdf_files/use_case.pdf)
Non-Functional (optional)List of NFRs that the use case must meetIssues List of issues that remain to be resolved
Use Case Identifier: e.g., “Withdraw money”; ref # = wm3; mod history = …
Actors List of actors involved in use case
Brief description Goal: E.g., “This use case lets a bank account owner withdraw money from an ATM machine”; Source: Bank doc 2.3
Preconditions What should be true before the use case can start.
Postconditions What should hold after the use case successfully completes.
Basic flow of events The happy/sunny day flow. The most common successful case.
Alt. flow of events /subflows Difference for the specific subflow
Exception flows Subflows may be divided into 1) normal, 2) successful alternate actions, and 3) exception/error flows.
![Page 7: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/7.jpg)
7
A Use Case TemplateUse Case (id, ref#, mod history)
2. Reparing_Cellular_Network
History created 1/5/98 Derek Coleman, modified 5/5/98
Description (goal, source) Operator rectifies a report by changing parameters of a cell
Actors Operator (primary, Cellular network, Field maintenance engineer)
Assumptions (successful use case termination condition)
Changes to network are always successful when applied to a network
Steps 1. Operator notified of network problem
2. Operator starts repair session
3. REPEAT
3.1 Operator runs network diagnosis application
3.2 Operator identifies cells to be changes and their new parameter values
3.3 IN PARALLEL
3.3.1 Maintenance engineer tests network cells ||
3.3.2 Maintenance engineer sends fault reports
UNTIL no more reports of problem
4. Operator closes repair session
Variations (optional) #1. System may detect fault and notify operator or
Field maintenance engineer may report fault to Operator
Non-Functional (optional) Performance Mean: time to repair network fault must be less than 3 hours
Issues (that remain to be resolved)
What are the modes of communication between field maintenance engineer and operator
(http://www.bredemeyer.com/pdf_files/use_case.pdf)
Use Case Extension Repair_may_fail extends 2. Reparing_Cellular_Network
Description Deals with assumption that network changes can never fail
Steps #3.3. if the changes to network fail then the network is rolled back to its previous state
Issues How are failures detected? Are roll backs automatic or is Operator intervention required?
![Page 8: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/8.jpg)
8
Sequence Diagrams
Behavioral Diagrams
– Use case
– Statechart– Activity
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview– Timing
![Page 9: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/9.jpg)
9
Interaction Diagrams (sd and cd) show the interaction of any kind of instance (classes, interfaces, components,
nodes and subsystems);
messages sent/received by those objects/instances (invocation, construction/destruction, of an operation)
realizes use cases to model a scenario
Interaction types (these are isomorphic, when no loops or branching)– Sequence diagram —emphasizes the time ordering of messages.
– Communication (Collaboration) diagram — emphasizes the structural organization of objects that directly send and receive messages.
Objects within an interaction can be:
– Concrete: something from the real world. (e.g., John: Person)
– Prototypical: representative instance of something from the real world
(e.g., p: Person)• Communication diagrams use (strictly) prototypical things.• Prototypical instances of interfaces and abstract types are valid.
![Page 10: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/10.jpg)
10
Interaction Diagram: sequence vs communication
s1 : StockQuoteSubscriberp : StockQuotePublisher
attach(s1)
s2 : StockQuoteSubscriber
attach(s2)
notify()
update()
update()
getState()
getState()
s1 : StockQuoteSubscriber
p : StockQuotePublisher
s2 : StockQuoteSubscriber
1 : attach(s1)6 : getState()
2 : attach(s2)7 : getState()
3 : notify() 4 : update()
5 : update()
Observerdesignpattern
objectrole:ClassName
Procedure call, RMI, JDBC, …
Activations (See pg 14)- Show duration of execution- Shows call stack- Return message
Implicit at end of activationExplicit with a dashed arrow
objects
Time
{update < 1 minutes}
classifiers or their instances,
use cases or actors.
![Page 11: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/11.jpg)
11
Interactions - Modeling Actions• Simple• Call• Return • Send
: TicketAgent
c : Client p : PlanningAgent
<<create>>
setItenerary( i )calculateRoute()
route
Xnotify()
return value
send
call on self
<<destroy>>
actual parameter
return
end of object life
destroy: e.g., in C++ manual garbage collection; in Java/C#, unnecessary
Additional considerations To show nested messages, use ?. To show constraints like time and space, use ?. For formal flow of control, attach pre and post conditions to each message (?)
1
natural death/self destruction
asynchronous in 2.0 (stick arrowhead) – no return value expected at end of callee activation
half arrow in 1.x
activation of caller may end before callee’s (???)
for each conference
loop
![Page 12: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/12.jpg)
12
concurrent lifelines- for conditionals- for concurrency
linking sequence diagrams
ob1:C1
ob3:C3
ob2:C2
ob3:C3
op1
[x>0] foo(x)
[x<0] bar(x)
do(w)
do(z)
recurse()
[z=0] jar(z)
ob3:C3
[z=0] jar(z)
ob3:C3
conditional
recursion
Sequence Diagrams – Generic vs. Instance
2 forms of sd: Instance sd: describes a specific scenario in detail; no conditions, branches or loops. Generic sd: a use case description with alternative courses.
Here, conditional or concurrency?
![Page 13: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/13.jpg)
13
Timing constraints Useful in real-time applications useful to specify race condition behaviour Two ways to specify (in 1.x) any example?
![Page 14: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/14.jpg)
14
Interactions - Procedural Sequencing vs. Flat Sequencing
Flat Sequencing• Infrequent: Not recommended for most
situations.• Each message is numbered sequentially
in order of timing.• Rendered with stick arrowhead.
c : Clientx x.k
c : Clientx y
7
456
12
3
CAN’T TELL RELATIONSHIPS
Procedural Sequencing (Dewey decimal system) • 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.
89
3.1.1
1.11.23.1
12
3
1.1.11.1.2
![Page 15: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/15.jpg)
15
:Eunconditional
Interactions – conditional paths, asynchronous message[Craig Larman] [http://www.phptr.com/articles/article.asp?p=360441&seqNum=6&rl=1]
:A
:C
:B
:D
1: msg1 1a [test1]:msg2
2: msg7
1b [not test1]:msg3
1c: msg4 a.1:<<create>>
1a and 1b are mutuallyexclusive conditional paths
1c.1: msg5
active object
asynchrous message
a.2:update( p ):F
Is this ok?Can you produce a corresponding sd?Is there a unique sequence of paths?
![Page 16: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/16.jpg)
16
Use Case
Modeling Different Levels of Abstraction
Interaction Diagram at a High Level of Abstraction
: Order Clerk: Order Taker : Order
FulfillmentsubmitOrder
placeOrder
acknowledgeOrder
Interaction Diagram at a Lower Level of Abstraction
: Order Clerk: Order Taker : Order
Fulfillment: Billing Agent: CreditCard
AgensubmitOrder
placeOrder
processCard
acknowledgeOrder
triggerBill
Order ClerkPlace Order
Establish trace dependencies between high and low levels of abstraction Loosely couple different levels of abstraction
• Use Cases trace to Collaborations in the Design Model, to a society of classes •Components trace to the elements in the design model, then to Nodes
<<trace>>
<<trace>>
model
![Page 17: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/17.jpg)
17
public Class Selection { private Purchase myPurchase = new Purchase(); private Payment myPayment; public void purchase()
{ myPurchase.buyMajor(); myPurchase.buyMinor(): myPayment = new Payment( cashTender ); //. . }
// . . }
:Selection :Purchase
:Payment
purchase
buyMajor
buyMinor
create(cashTender)
Sequence Diagrams & Some Programming
![Page 18: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/18.jpg)
18
Why do people call it an ATM machine, but they know it's really saying Automated Teller Machine Machine?
Why do people say PIN number when that truly means Personal Identification Number Number?
![Page 19: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/19.jpg)
19
sd Withdrawal
:User :ATM :Bank
refAuthenticate
alt
alt
PIN OK
PIN NOK
withdraw
msg (“amount”)
amount (a) chkAcct (a)
msg (“card”)
msg (“illegal entry”)
enough bal
not enough bal
moneyreceipt
msg(“amount too big”)
sd Authenticate
:User :ATM :Bank
ref EnterPIN
loop(0,3)
PIN NOKmsg (“try again”)
cardId(cid)
Idle
ref EnterPIN
sd EnterPIN
:User :ATM :Bank
PIN NOK
pin-nok
Digit[4]
alt
pin-ok
PIN NOK
Code(cid,pin)
Frames: References
continuation
nested fragment
op
era
nd
so
pe
rato
r
![Page 20: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/20.jpg)
20
sd Withdrawal
:User :ATM :Bank
refAuthenticate
PIN OK PIN NOK
withdraw
msg (“amount”)
amount (a) chkAcct (a)
msg (“card”)
msg (“illegal entry”)
not enough balmsg(“amount too big”)
Interaction Overview Diagram
:User :ATM :Bank
sd
:User :ATM
sd
:User :ATM
sd
enough balmoneyreceipt
:User :ATM :Bank
sd sd
Relationship with Sequence Diagram?
![Page 21: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/21.jpg)
21
Frames & Interaction Fragment Operators
Flow of Control – sd: named sequence diagram ref: reference to “interaction fragment”
Naming– loop: repeat interaction fragment– opt: optional “exemplar” (cf. break)
– alt: selection– par: concurrent (parallel) regions (e.g., mo.cookFood -> par(nukeFood, rotateFood)
Ordering– seq: partial ordering (default) (aka “weak”)– strict: strict ordering– criticalRegion: identifies “atomic” fragments
Causality– assert: required (i.e. causal)– neg: “can’t happen” or a negative specification– Ignore/consider: messages outside/inside causal stream
Frame: as the graphical boundary, and a labeling mechanismFrame name: “frame type name[(param type: param name)] [: return type: return name]”
[guard condition] can appear as the first item underneath
![Page 22: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/22.jpg)
22
What can be in the top boxes?(http://www.agilemodeling.com/artifacts/sequenceDiagram.htm)
Outputting transcripts
Boundary/interface elements: software elements such as screens, reports, HTML pages, or system interfaces that actors interact with.
Control/process elements (controllers): These serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions. Often implemented using objects, but simple ones using methods of an entity or boundary class.
Entity elements
![Page 23: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/23.jpg)
23
Modeling Protocols - Associating Protocols with Ports
«interface»«interface»CalleeCallee
«interface»«interface»CalleeCallee
«interface»«interface»CallerCaller
«interface»«interface»CallerCaller
«interface»«interface»OperatorOperator
«interface»«interface»OperatorOperator ClassXClassX
By a set of interconnected interfaces, invoked according to a formal behavioral specification.
callercallercallercaller operatoroperatoroperatoroperator calleecalleecalleecallee
Interaction specs
initialinitialinitialinitial
connectedconnectedconnectedconnected
connectingconnectingconnectingconnecting
state machine spec
Operator Assisted CallOperator Assisted Call
«uses»
«uses» «provides»
Can you depict this using balls & sockets?
![Page 24: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/24.jpg)
24
call
ack
number
call
ack
talk
transfer
CallerCallerCallerCaller OperatorOperatorOperatorOperator CalleeCalleeCalleeCallee
Protocols: Reusable Interaction Sequences(http://cot.uni-mb.si/ots2003/ppt/Selic-UML2.0-tutorial.030504.pdf)
Communication sequences that always follow a pre-defined dynamic order occur in different contexts with different specific participants (i.e., instances)
Interfaces
![Page 25: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/25.jpg)
25
From Diagrams to ObjectsCollect all messages to define object’s methods and state transitions !
Phone Directory
![Page 26: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/26.jpg)
26
State Transition Diagrams
Behavioral Diagrams
– Use case
– Statechart– Activity
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview– Timing
![Page 27: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/27.jpg)
27
State Transitions
event name [guard condition] / action
^object/className.event
15 sec
send
• State machine - event-ordered behavior that specifies the sequences of states an object/instance (of class/interface/collaboration/…/system) goes through during its lifetime; events trigger transitions and cause responses. (StateChart is one particular kind of state machine by David Harel)
• State - condition or situation during which an object/instance may perform some activity; The state of an object is characterized by the value of one or more of its attributes.
• Activity - ongoing non-atomic execution within a state machine.
• Action - executable atomic computation that results in a change in state of the model or the return of a value.
event name (a:T) [guard condition] / action
![Page 28: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/28.jpg)
28
State Transitions
initialization
open
add student [count<10]
cancel cancel
closed
canceled
add student/ set count=0;^CourseRoster.create(course)
[count=10]
^CourseRoster.delete
triggerless transitionguard
actionevent trigger send signal
Each diagram must have one and only one start state A diagram may have one or more stop states Automatic transition - occurs when the activity of one state completes Non-automatic transition - caused by a named event
![Page 29: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/29.jpg)
29
State Transitions – notational variation
open
cancel
closed
canceled
[count=10]
open
cancel
closed
canceled
[count=10]
open
cancel
closed
canceled
not cancel and [count=10]
![Page 30: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/30.jpg)
30
Advanced States Entry & exit actions - actions that always occur upon entry into or
exit away from a state regardless of transition. Internal Transitions - triggered by events but don’t change state. Activities - ongoing behavior which continues until interrupted. Deferred events - events ignored by the current state, but postponed
for later processing.
Tracking
entry / setMode( onTrack ) exit / setMode( offTrack )newTarget / tracker.Acquire() do / followTarget selfTest / defer
entry action
exit action
internal transition
activity
deferred event
name
![Page 31: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/31.jpg)
31
Substates Substate -- state nested inside of another state. Sequential substates (then a nonorthogonal state) Concurrent substates (then an orthogonal state)
Idle
Maintenance
Active
Validating
Selecting Processing
Printing
[not continue]
entry / readCard exit / ejectCard
[continue]
sequential substatecomposite state
maintain
cardInserted
cancel
Idle
Maintenance
Testing
Commanding
H
H
Testingdevices
Waiting
Selfdiagnosis
Command
maintain
composite state
concurrentsubstate [continue]
joinfork
[not continue]keyPress
Initial state/ pseudostate
![Page 32: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/32.jpg)
32
VerifyCard
OutOfService
acceptCard
ReleaseCardVerifyTransaction
outOfService
releaseCard
ATM
ReadAmount :ReadAmountSM abortedaborted
rejectTransaction
againagain
Modular Submachines
usage of exit pointusage of exit point
usage of entry pointusage of
entry point
invoked submachine
invoked submachine
ReadAmountSM
selectAmount
EnterAmount
ok
abort
abortedabortedamount
otherAmountabort
againagain
EXIT pointEXIT point
ENTRY pointENTRY point
Submachinedefinition
Submachinedefinition
http://www.xpdian.com/UML2.0changes.html
![Page 33: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/33.jpg)
33
Specialization• Redefinition as part of standard class specialization
ATM
acceptCard()outOfService()amount()
BehaviourStatemachine
FlexibleATM
otherAmount()rejectTransaction()
Behaviour
Statemachine
<<Redefine>>
![Page 34: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/34.jpg)
34
Events – External vs. Internal Events Events can be categorized into external or internal events. External events are those that pass between the Actors and the system.
System
Event Even
t
NetworkElement
elementPort: Port
Internal events pass between objects residing within the application system.
NetworkController
consolePort[2..*] : Port
1
![Page 35: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/35.jpg)
35
• Signal - kind of event that represents the specification of an asynchronous stimulus communicated between instances.
• Modeled as a class• Dispatched (thrown) by one object and continues flow of execution• Received (caught) by another object at some future point in time.
• Can be sent as:– Action of a state transition– Message in an object interaction– Dependencies <<send>> show signals sent by a class
moveTo
positionvelocity
MovementAgent
<<signal>>Collision
force : float
<<send>>
send dependency
Signal parameters
signal
Signalscollision( force : float )powerLosspowerDown
TroubleManager
• Modeling Signal Receiver: as an active class; Consider 4th compartment for signals.
Events – 4 Kinds: Signals; Calls; Passing of Time; Change in State
![Page 36: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/36.jpg)
36
Call Events Represents the dispatch of an operation Synchronous
AutomaticManualstartAutopilot( normal )
event
parameter
Time & Change Event
• Time event - represents the passage of time: after( periodOfTime )
• Change event - represents a change in stateor the satisfaction of some condition: when( booleanExpr )
time event
Idle
Active
when( 11:49pm ) / selfTest()
after( 2 sec ) / dropConnection()
change event
Events – 4 Kinds: Signals; Calls; Passing of Time; Change in State
![Page 37: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/37.jpg)
37
Modeling Family of Signals and Exceptions
Signal events are typically hierarchical. Look for common generalizations. Look for polymorphic opportunities.
<<signal>>RobotSignal
<<signal>>HardwareFault
<<signal>>Collision
sensor : int
<<signal>>MotorStall
<<signal>>MovementFault
<<signal>>BatteryFault
<<signal>>VisionFault
<<signal>>RangingFault
Consider the exceptional conditions of each class. Arrange exceptions in generalization hierarchy. Specify the exceptions that each operation may raise.
– Use send dependencies– Show in operation specification
setHandler()firstHandler()lastHandler()
<<exception>>Exception
<<exception>>Duplicate
<<exception>>Underflow
<<exception>>Overflow
add()
remove()
Setitem
<<send>>
<<send>>
<<send>>
![Page 38: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/38.jpg)
38
Activity Diagrams
Behavioral Diagrams
– Use case
– Statechart
– Activity
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview– Timing
![Page 39: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/39.jpg)
39
Activity Diagram Basics• Activity Diagram – a special kind of Statechart diagram, but showing the flow from activity to
activity (not from state to state).• Activity state –non-atomic execution, ultimately result in some action; a composite made up of
other activity/action states; can be represented by other activity diagrams• Action state –atomic execution, results in a change in state of the system or the return of a value
(i.e., calling another operation, sending a signal, creating or destroying an object, or some computation); non-decomposable
action state
: CertificateOfOccupancy[completed]
object flow
Select site
Commission architect
Develop plan
Bid plan
Do site work Do trade work()
Finish construction
initial state
sequential branch/decision
[not accepted]
[else]
final state
concurrent fork
activity state with submachine
concurrent join
do construct()Entry/ setLock()
triggerless transition
guard expression
No notational distinction between action and activity states!But, activity states can have certain types of parts
optional
0..*
AND
one incoming, several outgoingmerge (unbranch) multiple incoming, one outgoing(for alternative threads) OR
![Page 40: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/40.jpg)
40
Swimlanes & Object Flow
Request service
Pay
Collect order
Take order
Deliver order
Fill order
Customer Sales Stockroom
Order[placed]
Order[filled]
Order[entered]
Order[delivered]
object flow
?
• Object flow – objects connected using a dependency to the activity or transition that creates, destroys, or modifies them
• A swimlane is a kind of package.• Every activity belongs to exactly one swimlane, but transitions may cross lanes.
swimlane
What if using pins?
flow finalthe process stops at this point for thispart of the activity diagram
sub-activity indicator
![Page 41: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/41.jpg)
41
Object Flows and Pins
A shorthand notation: use input pins and output pins (parameters).
Invoice inv;inv = new Invoice;FillOrder(inv);
![Page 42: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/42.jpg)
42
A Simple Example – Order Processing
<<precondition>> Order complete<<postcondition>> Order closed
activity parameter node = object node
What if using swimlanes?
![Page 43: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/43.jpg)
43
A Simple Example – Order Processing Using sub-activity
Is this the same as the previous one?
![Page 44: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/44.jpg)
44
POEmployee.sortMail
Activity Diagram even as Method
POEmployee.deliverMail
POEmployee
sortMail()deliverMail(k: Key)
ad POEmployee.deliverMail
Check Out Truck
Put Mail in Boxeskey
ad POEmployee.sort-deliverMail
![Page 45: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/45.jpg)
45
Interruptible Activity Region• An interruptible activity region surrounds a group of actions that can be
interrupted.
• the Process Order action will execute until completion, then pass control to the Close Order action, unless a Cancel Request interrupt is received which will pass control to the Cancel Order action.
![Page 46: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/46.jpg)
46
An Activity Diagram – Distributing schedules
<<signal>>
redundant constraint
object
pin parameter
http://www.agilemodeling.com/artifacts/activityDiagram.htm
hour-glass symbol represents time
send receive
send receive
![Page 47: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/47.jpg)
47
Pins, Parameters, Effects(www.jot.fm/issues/issue_2004_01/column3.pdf )
effect that their actions have on objects that move through the pin: one of the four values create, read, update, or delete.
Take Order creates an instance of Order and Fill Order reads it.
The create effect is only possible on outputs; and the delete effect is only possible on inputs.
![Page 48: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/48.jpg)
48
Multiple Tokens Object nodes can hold more than one value at a time, and some of these values can be the same.
Upper bound: the maximum number of tokens an object node can hold, including any duplicate values.
At runtime, when the number of values in an object node reaches its upper bound, it cannot accept any more.
If painting is delayed too much for some reason, the input pin will reach its upper bound, and parts from polishing will not be able to move downstream; If painting is delayed further, the output pin of polishing will fill up and the polishing behavior will not be able to transfer out polished parts; Unless the polishing behavior has an object node internal to it that buffers output parts, it will not be able to take parts from its input pin, which will likewise fill up and propagate the backup; Only when the input pin to PAINT goes below its upper bound will parts be able to flow again.
![Page 49: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/49.jpg)
49
Multiple Tokens - Ordering
• Object nodes holding multiple values can specify the order in which values move downstream.
• The default is FIFO (a pipe); users can change this to LIFO (a queue), or specify their own behavior to select which value is passed out first.
Non-Determinism (http://www.jot.fm/issues/issue_2004_01/column3.pdf)
![Page 50: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/50.jpg)
50
Parameter Multiplicity & Object Flow Weight
• Minimum multiplicity on an input parameter means a behavior or operation cannot be invoked by an action until the number of values available at each of its input pins reaches the minimum for the corresponding parameter, which might be zero
Weight on object flow edges specifies the minimum number of values that can traverse an object flow edge at one time.
![Page 51: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/51.jpg)
51
Interaction Overview Diagrams
Behavioral Diagrams
– Use case
– Statechart– Activity
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview– Timing
![Page 52: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/52.jpg)
52
Interaction Overview Diagram (
http://www.agilemodeling.com/artifacts/interactionOverviewDiagram.htm)
variants on UML activity diagrams which overview control flow. The nodes within the diagram are frames, not activities Two types of frame shown:
interaction frames depicting any type of UML interaction diagram (sequence diagram: sd, communication diagram: cd, timing diagram: td , interaction overview diagram: iod ) interaction occurrence frames (ref; typically anonymous) which indicate an activity or operation to invoke.
sd Enroll in Seminar lifelines :Student :Seminar :Course :Enrollment
:Student :Seminar :Course
refSelect Seminar()
getPrereq ()isEligible(std)
sd Determine Eligibility
{0..7msec}
[not eligible]
:Seminar :EnrollmentNumber enrolled
cd Determine Seat Availability
refAddToWaitingList()
refEnroll in Seminar()
[seat available]
[no seat]
![Page 53: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/53.jpg)
53
sd Withdrawal
:User :ATM :Bank
refAuthenticate
PIN OK PIN NOK
withdraw
msg (“amount”)
amount (a) chkAcct (a)
msg (“card”)
msg (“illegal entry”)
not enough balmsg(“amount too big”)
Interaction Overview Diagram
:User :ATM :Bank
sd
:User :ATM
sd
:User :ATM
sd
enough balmoneyreceipt
:User :ATM :Bank
sd sd
Relationship with Sequence Diagram?
![Page 54: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/54.jpg)
54
Timing Diagrams
Behavioral Diagrams
– Use case
– Statechart– Activity
Interaction Diagrams
– Sequence;
Communication
– Interaction Overview
– Timing
![Page 55: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/55.jpg)
55
Interaction Diagram: Timing DiagramTo explore the behaviors of 0..* objects throughout a given period of time. Two basic flavors: concise notation and robust notation
The lifecycle of a single seminar The critical states – Proposed, Scheduled, Enrolling Students, Being Taught, Final Exams, ClosedThe two lines surrounding the states are called a general value lifeline. When the two lines cross one another it indicates a transition point between states. Timing constraints along the bottom of the diagram, indicating the period of time during which the seminar is in each state.
criticalstates
Timing constraints
![Page 56: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/56.jpg)
56
http://www.visual-paradigm.com/highlight/highlightuml2support.jsp
Interaction Diagram: Timing Diagram (robust notation)
timing ruler w. tick marks
states
state timeline
transition point
Can you transform this into a concise notation?
![Page 57: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/57.jpg)
57
Appendix: Miscellaneous
![Page 58: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/58.jpg)
58
Role Names
![Page 59: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/59.jpg)
59
Iterative Messages[Craig Larman] [http://www.phptr.com/articles/article.asp?p=360441&seqNum=6&rl=1]
![Page 60: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/60.jpg)
60
Polymorphic Message[Craig Larman] [http://www.phptr.com/articles/article.asp?p=360441&seqNum=6&rl=1]
![Page 61: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/61.jpg)
61
Sequence Diagram Shapes
![Page 62: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/62.jpg)
62
![Page 63: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/63.jpg)
63
Race conditions E.g. an object receives two messages Order of arrival changes behaviour Only one order leads to correct behaviour
CellularRadio expects Answer() not Connect(pno) Two states when Send can be pressed
To make outgoing call (after dialling digits) To answer incoming call
State diagram can be useful here To help realize there is a race condition To specify what should happen
Angled arrows- Show message delay
• Dialer: gather digits, emit tones
• Cellular Radio: communicate with cellular network
• Button, Speaker, Microphone, Display hardware
![Page 64: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/64.jpg)
64
![Page 65: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/65.jpg)
65
Sequence Diagram - Reference
(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)
![Page 66: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/66.jpg)
66
VerifyCard
acceptCard
ReleaseCardVerifyTransaction
outOfService
releaseCard
OutOfService
ATM
{final}
{final}
{final}
{final}
ReadAmount
selectAmount
amount
State Machine Redefinition
enterAmount
okreject
{extended}
otherAmount
{extended}
FlexibleATM
![Page 67: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/67.jpg)
67
Interaction Diagram: Timing Diagram (robust notation)
A frame to bound the two lifelines
states/conditions
events/stimuli
transition point
message
state timeline
state timeline
timing ruler w. tick marks
timing constraint
timing observation
![Page 68: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/68.jpg)
68
Timing Diagram – another example(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)
![Page 69: Module 3: Advanced Features – Part II: Behavioral Diagrams](https://reader035.fdocuments.us/reader035/viewer/2022062422/56813c52550346895da5d3b4/html5/thumbnails/69.jpg)
69
_timing?timeout ^_txport!data0
_timing: interface/connection?: receivetimeout: event ^: send_txport: interface/connection!: senddata0: event+: multiple receive“:”: multiple send
Real-Time Extensions: Using CCS