1. 1 ECE 355: Software Engineering CHAPTER 2 Unit 4 (Part 3) Presentation material based on past ECE 355 notes by Prof. K. Czarneszki.

2. 2 Course outline Unit 1: Software Engineering Basics Unit 2: Process Models and Software Life Cycles Unit 3: Software Requirements  Unit 4: Unified Modeling Language (UML) Unit 5: Design Basics and Software Architecture Unit 6: OO Analysis and Design Unit 7: Design Patterns Unit 8: Testing and Reliability Unit 9: Software Engineering Management and Economics

3. 3 UML - Outline Introduction Structural modeling Behavioral modeling –Use case diagrams –Interaction diagrams  State diagrams –Activity diagrams Advanced modeling

4. 4 ONON Automata A machine whose output behavior is not only a direct consequence of the current input, but of some past history of its inputs Characterized by an internal state which represents this past experienceONON ONON ONON OFFOFF

5. 5 State Machine (Automaton) Diagram Graphical rendering of automata behavior off on Lamp On Lamp Off off on

6. 6 Outputs and Actions As the automaton changes state it can generate outputs: on off Lamp On print(”on”) print(”on”) Lamp Off off on Moore automaton on off Lamp On Lamp Off off print(”on”) on/print(”on”) Mealy automaton

7. 7 Extended State Machines Addition of variables (“extended state”) off on Lamp On Lamp Off off on/ctr := ctr + 1 ctr : Integer

8. 8 A Bit of Theory An extended (Mealy) state machine is defined by: –a set of input signals (input alphabet) –a set of output signals (output alphabet) –a set of states –a set of transitions triggering signal action –a set of extended state variables –an initial state designation –a set of final states (if terminating automaton)

9. 9 Basic UML Statechart Diagram top ReadyReady stop /ctr := 0stop StateState TriggerTrigger ActionAction InitialpseudostateInitialpseudostate TransitionTransition FinalstateFinalstate DoneDone “top” state

10. 10 What Kind of Behavior? In general, state machines are suitable for describing event-driven, discrete behavior –inappropriate for modeling continuous behavior time threshold

11. 11 Event-Driven Behavior Event = a type of observable occurrence –interactions: synchronous object operation invocation (call event) asynchronous signal reception (signal event) –occurrence of time instants (time event) interval expiry calendar/clock time –change in value of some entity (change event) Event Instance = an instance of an event (type) –occurs at a particular time instant and has no duration

12. 12 The Behavior of What? In principle, anything that manifests event-driven behavior –There is no support currently in UML for modeling continuous behavior In practice: –the behavior of individual objects –object interactions The dynamic semantics of UML state machines are currently mainly specified for the case of active objects

13. 13 Events Event: Spec of a significant occurrence that has a location in time and space. State machine: occurrence of a stimulus that triggers a state transition. Four kinds of events Signals Calls Passing of time Change in state

14. 14 Signals A named object that is thrown asynchronously by one object and then caught by another. Model the relationship between an operation and the events that it can send by using a dependency relationship. > Collision Force: Float MovementAgent Position velocity moveTo() >

15. 15 Modeling Exceptions > Exception setHandler() firstHandler() > Duplicate Overflow Underflow Set add() remove() >

16. 16 Signals as Triggers Sending of a signal Asynchronous ManualManualAutomaticAutomatic Collision(force)

17. 17 Call Events as Triggers Dispatch of an operation Synchronous startAutopilot(normal) ManualManualAutomaticAutomatic

18. 18 Time and Change events Time event: Represents passage of time (keyword: after) Change event: Change in state or satisfaction of some condition (keyword: when) when (11:49PM)/ selfTest() after (2 seconds)/ dropConnection() IdleIdleActiveActive

19. 19 Advanced States Parts of a state Name Entry/exit actions Do activity Internal transitions: transitions which don’t lead to a state change (and don’t trigger entry/exit actions) Substates: nested structure; disjoint, concurrent. Deferred events: List of events that are not handled in that state, but queued for handling by the object.

20. 20 Advanced States Tracking entry / setMode(onTrack) exit / setMode(offTrack) newTarget / tracker.Acquire() do / followTarget selfTest / defer Entry action Exit action Internal trans. Activity Deferred event

21. 21 Order of Actions: Simple Case Exit actions prefix transition actions Entry action postfix transition actions Resulting action sequence: printf(“exiting”); printf(“to off”); lamp.off(); Resulting action sequence: printf(“exiting”); printf(“to off”); lamp.off(); printf(“exiting”);printf(“needless”);lamp.off();printf(“exiting”);printf(“needless”);lamp.off(); off/printf(“needless”); off/printf(“to off”); LampOffLampOff entry/lamp.off(); exit/printf(“exiting”); LampOnLampOn entry/lamp.on(); exit/printf(“exiting”);

22. 22 Internal Transitions Self-transitions that bypass entry and exit actionsLampOffLampOffentry/lamp.off(); exit/printf(“exiting”); off/null; Internal transition triggered by an “off” event Internal transition triggered by an “off” event

23. 23 State (“Do”) Activities Forks a concurrent thread that executes until: –the action completes or –the state is exited through an outgoing transition ErrorError entry/printf(“error!”) do/while (true) alarm.ring(); “do” activity

24. 24 Guards Conditional execution of transitions –guards (Boolean predicates) must be side-effect free SellingSelling UnhappyUnhappy HappyHappy bid /sell bid [(value >= 100) & (value < 200)] /sell bid /sell bid [value >= 200] /sell bid /reject bid [value < 100] /reject

25. 25 Static Conditional Branching Merely a graphical shortcut for convenient rendering of decision trees /sell [(value >= 100) & (value < 200)] /sell /sell [value >= 200] /sell /reject [value < 100] /rejectSellingSellingUnhappyUnhappy HappyHappy bid bid

26. 26 Dynamic Conditional Branching Choice pseudostate: guards are evaluated at the instant when the decision point is reached SellingSelling UnhappyUnhappy HappyHappy bid /gain := calculatePotentialGain(value) /sell [(gain >= 100) & (gain < 200)] /sell /sell [gain >= 200] /sell /reject [gain < 100] /reject DynamicchoicepointDynamicchoicepoint

27. 27 Hierarchical State Machines Graduated attack on complexity –states decomposed into state machines LampFlashingLampFlashingflash/ 1sec/ 1sec/ FlashOffFlashOff entry/lamp.off()FlashOnFlashOnentry/lamp.on() off/LampOffLampOffentry/lamp.off() LampOnLampOn entry/lamp.on() on/ on/ on/

28. 28 “Stub” Notation Notational shortcut: no semantic significance LampFlashingLampFlashing flash/ on/ FlashOn FlashOff off/LampOffLampOffentry/lamp.off() LampOnLampOn entry/lamp.on() on/ on/

29. 29 LampFlashingLampFlashing 1sec/ 1sec/ FlashOffFlashOff entry/lamp.off()FlashOnFlashOnentry/lamp.on() off/LampOffLampOffentry/lamp.off() LampOnLampOn entry/lamp.on() on/ Group Transitions Higher-level transitionsflash/ on/ Default transition to the initial pseudostate Default transition to the initial pseudostate Group transition

30. 30 LampFlashingLampFlashing off/ FlashOffFlashOff FlashOnFlashOn Triggering Rules Two or more transitions may have the same event trigger –innermost transition takes precedence –event is discarded whether or not it triggers a transition (non- persistent input) on/

31. 31 Deferred Events Events can be retained if they do not trigger a transition off/ LampOnLampOn entry/lamp.on() on/ LampOffLampOff entry/lamp.off() off/defer Deferred event

32. 32suspend/ History Return to a previously visited hierarchical state –deep and shallow history options DiagnosingDiagnosing Diagnostic1Diagnostic1 Step11Step11 Step12Step12 Diagnostic2Diagnostic2 Step21Step21 Step22Step22 resume/H*H*

33. 33 Orthogonality Multiple simultaneous perspectives on the same entity Child Adult Retiree age Poor Rich financialStatus

34. 34 Orthogonal Regions Combine multiple simultaneous descriptions Child Adult Retiree age Poor Rich financialStatus Poor RichfinancialStatusChild Adult Retireeage

35. 35 OutlawOutlaw LawAbidingLawAbidingPoorPoor RichRich financialStatuslegalStatus Orthogonal Regions - Semantics All mutually orthogonal regions detect the same events and respond to them “simultaneously” –usually reduces to interleaving of some kind robBank/robBank/

36. 36 Transition Forks and Joins For transitions into/out of orthogonal regions: StaffMemberStaffMember employee ChildChildAdultAdultRetireeRetiree age ManagerManager

37. 37 Execution semantic of a state machine on off Lamp On Lamp Off off on/print(”on”) stop Handle Event Initialize Object Terminate Object Wait for Event Dispatch Event

38. 38 Execution semantic of a state machine One event input queue per state machine Run-to-completion model –serialized event handling (dispatch of next event only if processing of the previous completed, i.e., all state transitions and actions (incl. synchronous calls) completed) –eliminates internal concurrency (one event handling loop running in one thread; but activities may be concurrent) –minimal context switching overhead ActiveObject: Event input queue

39. 39 Processes and Threads Active object Owns a process/thread. Can initiate control activity. Process: Independent address space. Execute concurrently with other processes. Threads: Hidden inside a process. Not independently scheduled by OS.

40. 40 Object and Threads Passive objects: depend on external power (thread of execution) Active objects: self-powered (own thread of execution) Handle Request Initialize Object Terminate Object Wait for Request Handle Request Initialize Object Terminate Object Wait for Request

41. 41 Active1Active1Active2Active2 The Run-to-Completion Model A high priority event for (another) active object will preempt an active object that is handling a low-priority event hi lo

42. 42 Communication Objects interact by passing messages. Active/passive objects  4 kinds of interactions. Passive => passive: simple invocation of operation. Active => active: interprocess communication (blocking semantics: synchronous, asynchronous) Active => passive: difficult. Model synchronization. Passive => active: interprocess communication.

43. 43 Passive Objects: Dynamic Semantics Encapsulation does not protect the object from concurrency conflicts! Explicit synchronization is still required Handle Request Initialize Object Terminate Object Wait for Request

44. 44 Synchronization (Active => passive) lead to multiple flows of control in one object at the same time. State corruption may occur  need for mutual exclusion. Treat an object as a critical region. Three alternatives: sync properties to ops. Sequential, guarded, concurrent.

45. 45 Synchronization Sequential: Callers coordinate outside the object. Failure  integrity not guaranteed. Guarded: Integrity guaranteed by sequentializing all calls to guarded ops. Concurrent: Integrity is guaranteed by treating the op as atomic. (synchronized in Java).

46. 46 Synchronization Buffer Size : integer add() {concurrent} remove() {concurrent) synchronization property

47. 47 UML - Outline Introduction Structural modeling Behavioral modeling –Use case diagrams –Interaction diagrams –State diagrams  Activity diagrams Advanced modeling

48. 48 Activity Diagram Applications Intended for applications that need control flow and/or object/data flow models …... rather than event-driven models like state machines. For example: business process modeling and workflow. The difference in the three models is how step in a process is initiated, especially with respect to how the step gets its inputs.

49. 49 Control Flow Each step is taken when the previous one finishes … …regardless of whether inputs are available, accurate, or complete (“pull”). Emphasis is on order in which steps are taken. Not UML Notation! Chart Course Cancel Trip Analyze Weather Info Weather Info Start

50. 50 Object/Data Flow Each step is taken when all the required input objects/data are available … … and only when all the inputs are available (“push”). Emphasis is on objects flowing between steps. Design Product Procure Materials Procure Materials Acquire Capital Build Subassembly 1 Build Subassembly 1 Build Subassembly 2 Build Subassembly 2 Final Assembly Final Assembly Not UML Notation

51. 51 State Machine Each step is taken when events are detected by the machine … … using inputs given by the event. Emphasis is on reacting to environment. Ready To Start Coin Deposited Ready For Order Selection Made Dispense Product Dispense Product Return Change Return Change Cancel Button Pressed Not UML Notation

52. 52 Activity Diagrams Based on State Machines Currently activity graphs are modeled as a kind of state machine. Modeler doesn't normally need to be aware of this sleight-of-hand...... but will notice that "state" is used in the element names. Activity graphs will become independent of state machines in UML 2.0.

53. 53 Kinds of Steps in Activity Diagrams Just like their state machine counterparts (simple state and submachine state) except that...... transitions coming out of them are taken when the step is finished, rather than being triggered by an external event,...... and they support dynamic concurrency. Action Action (State) Subactivity Subactivity (State)

54. 54 Action (State) An action is used for anything that does not directly start another activity graph, like invoking an operation on an object, or running a user-specified action. However, an action can invoke an operation that has another activity graph as a method (possible polymorphism). Send message Index := lookup(e) + 7; simple action expression

55. 55 Subactivity (State) A subactivity (state) starts another activity graph without using an operation. Used for functional decomposition, non-polymorphic applications, like many workflow systems. The invoked activity graph can be used by many subactivity states. Subactivity

56. 56 Example aPOEmployee.sortMail Deliver Mail POEmployee sortMail() Check Out Truck Put Mail In Boxes Deliver Mail

57. 57 Activity Graph as Method Application is completely OO when all action states invoke operations All activity graphs are methods for operations. POEmployee sortMail() aPOEmployee.sortMail POEmployee.deliverMail deliverMail() «realize» Check Out Truck Put Mail In Boxes PO Employee Deliver Mail Method

58. 58 Dynamic concurrency Applies to actions and subactivities. Not inherited from state machines. Invokes an action or subactivity any number of times in parallel, as determined by an expression evaluated at runtime. Expression also determines arguments. Upper right-hand corner shows a multiplicity restricting the number of parallel invocations. Outgoing transition triggered when all invocations are done. Currently no standard notation for concurrency expression or how arguments are accessed by actions. Attach a note as workaround for expression. Issue for UML 2.0. Action/Subactivity *

59. 59 Object Flow (State) A special sort of step (state) that represents the availability of a particular kind of object, perhaps in a particular state. No action or subactivity is invoked and control passes immediately to the next step (state). Places constraints on input and output parameters of steps before and after it. :Class [State]

60. 60 Object Flow (State) Take Order must have an output parameter giving an order, or one of its subtypes. Fill Order must have an input parameter taking an order, or one of its supertypes. Dashed lines used with object flow have the same semantics as any other state transition. :Order [Taken] Take OrderFill Order

61. 61 Coordinating Steps Initial state Final state Fork and join Inherited from state machines

62. 62 Decision point and merge ( ) are inherited from state machines. For modeling conventional flow chart decisions. Coordinating Steps Calculate Cost Charge Account Get Authorization [cost < $50] [cost >= $50]

63. 63 Synch state ( ) is inherited from state machines but used mostly in activity graphs. Provides communication capability between parallel processes. Coordinating Steps * State machine notation Inspect Install Foundation Build Frame Install Electricity in Foundation Put On Roof Install Electricity In Frame Install Electricity Outside Install Walls **

64. 64 Convenience Features (Synch State) Forks and joins do not require composite states. Synch states may be omitted for the common case (unlimited bound and one incoming and outgoing transition). Build Frame Install Foundation Install Electricity in Foundation Put On Roof Install Electricity In Frame Install Electricity Outside Install Walls Inspect Activity diagram notation

65. 65 Convenience Features (Synch State) Object flow states can be synch states

66. 66 Convenience Features Fork transitions can have guards. Register Bug Evaluate Impact Fix Bug Revise Plan Release Fix Test Fix [ priority = 1] Register Bug Evaluate Impact Fix Bug Revise Plan Release Fix Test Fix [ priority = 1] [else] Instead of doing this:

67. 67 Convenience Features Partitions are a grouping mechanism. Swimlanes are the notation for partitions They may represent an object or set of object performing the contained actions. They do not provide domain-specific semantics. Tools can generate swimlane view from domain-specific information without partitions. Register Bug Evaluate Impact Fix Bug Revise Plan Release Fix Test Fix [ priority = 1] Management Support Engineering

68. 68 Convenience Features Signal send icon Signal Coffee Pot Wake Up Get Cups Turn on Coffee Pot Coffee Done Drink Coffee Signal … translates to a transition with a send action. Signal receipt icon … translates to a wait state (a state with no action and a signal trigger event).

69. 69 When to Use Activity Diagrams Use activity diagrams when the behavior you are modeling... –does not depend much on external events. –mostly has steps that run to completion, rather than being interrupted by events. –requires object/data flow between steps. –is being constructed at a stage when you are more concerned with which activities happen, rather than which objects are responsible for them (except partitions possibly).

70. 70 Activity Diagram Modeling Tips Control flow and object flow are not separate. Both are modeled with state transitions. Dashed object flow lines are also control flow. You can mix state machine and control/object flow constructs on the same diagram (though you probably do not want to).

71. 71 Activity Diagram Example From UML User Guide:

72. 72 Activity Diagram Example