Modeling Behavior with UML Interactions and Statecharts Bruce Powel Douglass, Ph.D. Chief Evangelist I-Logix, Inc. www.ilogix.com UML is a trademark or registered trademark of Object Management Group, Inc. in the U.S. and other countries. Page 1 About the Author • Chief Evangelist for I-Logix •Author of • Real-Time UML 2nd Edition: Efficient Objects for Embedded Systems (Addison- Wesley, Dec. 1999) • Doing Hard Time: Developing Real- Time Systems with UML, Objects, Frameworks, and Patterns (Addison- Wesley, 1999) • Real-Time Design Patterns: Robust Scalable Architectures for Real-Time Systems (Addison-Wesley, 2002) • Advisory Board • Embedded Systems Conference • UML World Conference • Software Development Magazine •Co-chair of OMG RTAD Work Group Page 2 Agenda • Basic Behavioral Concepts • Interactions – Semantics of Interactions – Sequence Diagrams – Collaboration Diagrams – Using Interactions • Statecharts – Semantics of Statecharts – Statechart Notation – Activity Diagrams – Using Statecharts Page 3 Basic Behavioral Concepts Page 4 What IS Behavior? • Behavior is a change in condition or value over time – May be in response to an event or request – May be externally visible or not Page 5 What kinds of things have Behavior? • Classifiers – Big Objects •Systems • Subsystems • Components – Small Objects • “primitive” or “semantic” objects – Use Cases • Collaborations – Collaborations are groups of objects working together for a common behavioral purpose • E.g. realize a use case Page 6 Types of Behavior • Behavior can be simple Simple behavior does not depend on the object’s history • Behavior can be continuous Continuous behavior depends on the object’s history but in a smooth, continuous fashion • Behavior can be stateful State-driven behavior means that the object’s behavior can be divided into disjoint sets Page 7 Simple Behavior • The behavior is not affected by the object’s history – cos( x ) – getTemperature( ) – setVoltage( v ) – max(a,b) b 2 – ∫ e−x dx a • May be decomposed arbitrarily deeply into subpart behaviors Page 8 Continuous Behavior • Object’s behavior depends on history in a continuous way. It does the same kind of behavior but resulting values vary depending on object history X Y W V Zn – Control loops n n + n n + Ka - Delay + Kb – digital filter ddjj+++−−123 d j d j − fj = 4 – fuzzy logic Uses partial set membership to compute a smooth, continuous output Page 9 State Behavior • Behavior depends on the history of the object, but in a discrete way • Object does different kinds of behavior and accepts different events in different states – When aircraft is on the ground, landing gear cannot be withdrawn – When aircraft is ascending, landing gear cannot be lowered – When aircraft is descending, landing gear cannot be raised – When aircraft is in cruise, landing gear can neither be raised nor lowered Page 10 Piece-wise Continuous • A combination of state and continuous – Eg cublic splines State 1 State 2 State 3 • Performs same actions but results vary depending on object history Page 11 Behavioral Synchronization • BS applies to how elements synchronize with respect to the invocation of services during an interaction • Types – Synchronous • Sender blocks and waits until Receiver is done – Asynchronous • Sender “sends and continues” • Receive processes when it is ready Page 12 Behavior the Single Thread • Single threaded behavior is EASY Page 13 Behavior and Multiple Threads • Independent multithread behavior is EASY Page 14 Behavior and Chaos • Interacting multithread behavior is VERY HARD Page 15 Problems with Interacting Threads • Protection of data and resource integrity in the presence contention – No problem with multiple readers – With >= 1 modifier and other accessors, the data may be corrupted or bad values may be returned • Deadlock – Happens when a resource client waits for a condition that can never happen Page 16 Resource Contention Solutions • Make resources reentrant – Difficult when modifying or updating a resource • Serialize access – Critical section • Disables task switching during resource access – Mutual exclusion semaphores • Implies priority inversion – Asynchronous rendezvous • Implies queuing (queue access must also be protected) Page 17 Deadlock Prerequisites • ALL of the following are required to have deadlock: – Mutual exclusion (locking) of resources – Resources are held (locked) while others are waited for – Preemption while holding resources is permitted – A circular wait condition exists (P1 waits on P2 which waits on P3 which waits on P1). • Liveness can be assured by breaking any of the above required conditions Page 18 Deadlock B R1 Available Locked R2 Available 111 R1: Resource Locked 1 D 1 Task 1 Task 1 Task E Task 2 Active 1 1 Inactive 1 R2: C 1 Resource 1 Blocked Task 2 Task Active Inactive A Blocked 0 20 40 60 80 100 120 140 160 180 200 220 240 Time Legend: Priority: Task 1 > Task 2 Adapted from Real-Time A: Task 2 runs with the intent of locking R1 then R2 Design Patterns by Bruce B: Task 2 locks R1 and is about to lock R2, when... C: Task 1 runs, prempting Task 2, with the intent of locking R2 then R1 Powel Douglass D: Task 2 locks R2. Addison-Wesley, 2002 E: Now Task 2 needs to lock R1, however R1 is already locked. So Task 2 must block until Task 1 can release R1. However, Task 1 cannot run to release R1 because it needs R2 which is locked by Task 2. Page 19 (some) Deadlock Solutions • Critical Sections – Don’t allow other tasks to run while resources are locked • Simultaneous Locking – Don’t wait while for other resources • Ordered Locking – Require locking to take place in a particular order (break circular waiting) • Priority Ceiling Protocol – Don’t allow locking of low priority resources if a higher priority resource is held Page 20 Timing and performance • In real-time systems, we must understand the Qualities of Service provided by the behavior – Worst case execution time – Average case execution time – Memory requirements – Write access time vs read access time • We do this by attaching constraints to the behavioral elements – Actions (on statecharts) – Methods Page 21 Interactions Page 22 Interaction • A collection of communications between instances, including all ways to affect instances, – Operation invocation, – Instance creation – Instance destruction • May be synchronous, asynchronous, or a mixture • Communications are partially ordered in time Page 23 UML Interaction Concepts • Instance – An object •Link – A run-time connection allowing communication •Action – Specification of an executable statement •Stimulus – Communication between two instances Page 24 UML Interaction Concepts • Operation – Specification of a requestable service provided by an instance • Method – Implementation of an operation •Call – Specification of a synchronous communciation • Signal – Specification of an asynchronous communication • Event – An occurrence of interest that results in a signal or operation call Page 25 Stimulus Specification •Simple goto(x,y,z) • With Sequence # 1.4 goto(x,y,z) – Dotted number indicates nested 1.4 newPos = goto(x,y,z) call TaskA:1.4 newPos = goto(x,y,z) • With Thread ID TaskB:2.3 TaskA/1.4 newPos = goto(x,y,z) • With Guards and Predecessors TaskB2.3/ TaskA: 1.4 [x^2 > y^2+z^2] newPos = goto(x,y,z) Page 26 Interaction Notations in UML • Sequence diagram – Most common – Emphasizes sequence over collaboration structure • Collaboration diagram – Less common – Emphasizes collaboration structure over sequence Page 27 Sequence Diagrams • Sequence diagrams show the behavior of a group of instances over time. Instances may be – Objects (most common) – Use case instance – System – Subsystem –Actor Page 28 Sequence Diagrams good for… •Useful for – Capturing typical or exceptional interactions for requirements – Understanding collaborative behavior – Demonstrating that collaboration realizes use case properly – Testing collaborative behavior Page 29 Sequence Diagrams Instance lifeline Partition line stimulus description Time constraint Collaboration boundary Page 30 SDs for Use Case Details • Capture interactions of System (or the use case) under consideration and actors • Used in a “black box” manner • Show typical and exceptional scenarios of use case, one scenaro per sequence diagram • Commonly a dozen to several dozen scenarios per use case Page 31 Use case Example Page 32 Use Case Sequence Diagram Page 33 UC Sequence Diagram (detail) Page 34 Use Case realization • Use cases are realized by collaborations of instances • How do you connect the use case sequence diagram to the collaboration? – How do you show it is CORRECT? • ANS: Execute Elaborated Scenarios – ADD collaboration details and show the SAME set of scenarios with this new detail – Demonstrate via execution the behavior is consistent with the required behavior Page 35 Use Case Collaboration Page 36 Use Case Realization Page 37 Use Case Realization (detail) Page 38 Special Case: Activations • Activations are useful for the sequential message exchanges stimulus activation return Page 39 Partial Ordering • Objects are normally assumed to be potentially concurrent with other objects and so SDs only specify partial order Page 40 Rules of (partial) Order • Message events (send or receive) on the same lifeline are fully ordered • Msg.send event precedes Msg.receive event for each message • All other orders are indeterminate Page 41 Sequence Diagrams and States State • States can be shown on sequence diagrams. The states holds in time until a change of state occurs • Shows to correspondence between