Examples of State Behavior

SE310 Analysis and Design of Software Systems

Lecture 10 – Event-Driven Architectures – Continued (OSE Chapter 13)

March 17, 2020 © Sam Siewert Significance of Design and Review

Applications – Software Running on Well-defined platform Systems Software – Software on Which Applications Run, Possibly Embedded Applications

© Sam Siewert 2 Design Vision and Reality Meeting requirements is sufficient, but may still not delight a customer Requirements, architecture, system design, sub-systems, detailed module/component design, Implementation, unit test, integration, system test, Army’s Hybrid Humvee Concept Acceptance?

Hybrid Prototype - Outcome

http://www.popsci.com/article/cars/will-helicopter-truck-fly © Sam Siewert 3 Design Team Status Assignment #4

Assignment #5 – Goal is to Complete Architecture and Requirements – Your Team Should be Beyond this – Domain Modeling and Starting on Detailed Design (State Machines, Activity Diagrams, SA/SD Flowcharts, etc.) – Present What You Have in Report

Scrum Leader Reports – Overall Team Status – Individual Updates

Design Walkthrough Readiness – Requirements Walkthrough on Tues or Thursday

a b a/x c b a c/z b/y z c x y (a) Interactive subsystem (b) Event-driven subsystem

6-5

Mealy / Moore State Machines can be Executed as a Model (E.g. Telelogic SDL, Now IBM Rational SDL)

Petri-Net Simulations – E.g. http://www.tapaal.net/

Ability to Specify and then Execute a Object State Design (Powerful Method), Requires CASE Tool Support

Verify POSITIVE and NEGATIVE Protocols

Great for Message Passing and Communication Interfaces

© Sam Siewert 6 Event Driven Systems - Key Takeaway Points • Object state modeling is concerned with the identification, modeling, design, and specification of state-dependent, reactive behavior of objects.

• The state pattern reduces the complexity of state behavior design and implementation, and makes it easy to change.

13-7

Use case-iteration Business goals allocation matrix & needs Current situation Accommodating Customer Requirements Change feedback Acquiring Iteration use cases Requirements Domain Modeling Preliminary requirements Domain model Domain model Deriving Use Cases from Requirements Actor-System Interaction Modeling Abstract & high level use cases, Expanded use cases & use case diagrams UI design Allocating Use Cases & Behavior Modeling & Subsystems Responsibility Assignment to Iterations Behavior models Use case-iteration allocation matrix Deriving Design Class Diagram Producing an Architecture Design Design class diagram Software architecture Test Driven Development, Integration, & Deployment

(a) Planning Phase (b) Iterative Phase – activities during each iteration control flow data flow control flow & data flow 13-8

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Object State Modeling • Identification, modeling, analysis, design, and specification of state-dependent reactions of objects to external stimuli. – What are the external stimuli of interest? – What are the states of an object? – How does one characterize the states to determine whether an object is in a certain state? – How does one identify and represent the states of a complex object? – How does one identify and specify the state-dependent reactions of an object to external stimuli? – How does one check for desired properties of a state behavioral model?

13-9

off park fwd brake

on off up down

on reverse neutral released

transmission engine brake

What is the state dependent behavior of a car?

13-10

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. State Machine vs. State Transition Table State Machine State Machine Shows P States and events Automatic Common Use (input/output) we Case: R expect in our design Back out of parking, Example lacks rev-up engine, Input/output events N then drive forward. Or Format-1: State Drive in forward, D Transition Table shows rev-up engine, reverse and back ALL States and into parking. transitions possible

Simple State Transition Table (input/output) State x State with i/o New State Green states allowed Current State Park Reverse Neutral Fwd (safe?, necessary?) 4 States, 6 allowed shift-down / noop / "P" NA NA "R" transitions Red states not Park allowed shift-down / (unsafe?, no shift-up / "P" noop / "R" NA "N" implementation?) Reverse Stay in Current State shift-down / NA shift-up / "R" noop / "N" "F" allowed/assumed Neutral

shift-up / NA NA noop / "F" "N" Fwd Start state assumed and eliminated © Sam Siewert 11 State Machine vs. State Transition Table State Machine State Machine Shows P States and events Automatic Common Use (input/output) we expect Case: R in our design Back out of parking, Example lacks rev-up engine, Input/output events N then drive forward. Or Drive in forward, Format 2: State Transition D rev-up engine, Table shows ALL States reverse and back and transitions possible into parking.

EFSM State Transition Table State x Event (input), with (New State, [condition], “action”) condition (guard) and Event Green states action allowed (safe?, necessary?) State No action Shift Down Shift Up Reverse 4 States, 6 allowed Red states not Park []/"P" [enable] / NA allowed Park "R" Neutral transitions (unsafe?, no Reverse Park [enable] [enable] / implementation?) []/"R" / "P" Reverse "N" Reverse Neutral Fwd [enable] [enable] / Stay in Current State []/"N" / "D" Neutral "R" allowed/assumed Neutral Fwd []/"F" NA [enable] / Fwd "N" © Sam Siewert Start state assume and eliminated here 12 State Machine vs. State Transition Table

Park Ready Started (brake + (brake + (brake + 1 in-gear) in-gear) in-gear)

Simple State Transition Table (input/output)

New State 2

Current State 1 2 3 N 4 5 R

noop / "1" NA NA DOWN / "N" NA NA NA 1 Neutral 3 NA noop / "2" NA UP / "N" NA NA NA 2

NA NA noop / "3" DOWN / "N" NA NA NA 3

OVER-UP / OVER-DOWN WAY-OVER- WAY-OVER- UP / "1" DOWN / "2" noop / "N" "3" / "4" UP / "5" DOWN / "R" 4 N

NA NA NA UP / "N" noop / "4" NA NA 4

NA NA NA DOWN / "N" NA noop / "5" NA 5 R 5 NA NA NA UP / "N" NA NA noop / "R" R © Sam Siewert 13 Basic Definitions • An event is some happening of interest or a request to a subsystem, object, or component.

• A state is a named abstraction of a subsystem/ object condition or situation that is entered or exited due to the occurrence of an event.

13-14

13-15

What to look for Example Classification Rule Something interest An online application Event E1 happened submitted. Mode of operation A cruise control operates State S2 in activated/ deactivated modes. Conditions that govern Turn on AC if room Guard G1 the processing of an temperature is high condition event An act associates w/an Push the lever down to Response R1 event set the cruising speed.

More rules are found in the textbook.

13-16

Source & Destination 1 resp. 1x resp. 1y resp. 2x event 1a resp. 2y Source & event 1b State Destination 3 Machine event 3a resp. 3x event 3b Source & event 2a event 3c Destination 2 event 2b

13-17

13-18

• It is a systematic approach to state behavior modeling.

13-19

Event stubs list the events. State & E1 E2 E3 Substate State stubs show the states.

S4 TBD TBD TBD S (init) A single-line separates 2 specialization substates Component substate S5 TBD TBD TBD S A double-line separates 1 component substates S6 TBD TBD TBD (init) S 3 S6 [C] / a1; S7 TBD TBD a2 Transition entry, which means: if object is in S7 and E3 occurs and condition C is S9 NA TBD TBD true, then actions a1 and a2 are executed Specialization S8 and object enters S6. substate SA TBD S9 TBD

Table entry: initially all are “TBD.” Eventually, each should be “NA,” or a transition entry. 13-20

13-21

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Usefulness of State Transition Table • The systematic approach ensures internal completeness --- every state-event combination is analyzed. • State diagrams can be generated automatically. • It is easy to detect: – dead state – unreachable state – neglected event – impossible transitions – nondeterministic transitions – redundant transitions – inconsistent transitions

13-22

13-23

Cruise Activated

leverUpAnd onOffButton Cruising Hold() Increasing Pressed() Cancelled Speed

leverDown()/ leverDown Cruise setDesiredSpeed(), Deactivated leverUpAnd AndHold() Hold() leverUp() leverReleased() / setDesiredSpeed() leverPulled(), onOffButton brakeApplied() Decreasing Pressed() Cruising leverReleased()/ Speed setDesiredSpeed() leverDown leverDown() / AndHold() setDesiredSpeed()

13-24

CruiseControl

onOffButtonPressed() leverDown() leverUp() brakeApplied() leverDownAndHold() leverUpAndHold() leverPulled() leverReleased() setDesiredSpeed()

13-25

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Implementing State Behavior • Conventional approaches: – nested switch approach – using a state transition matrix – using method implementation

13-26

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Conventional Implementation: Nested Switches • Using nested switch statements switch (STATE) { case Init: switch (EVENT) { case State button clicked: set cursor to crosshair, STATE=AddState; break; case Trans button clicked: set cursor to crosshair; STATE=AddTransition; break; } case AddState: switch (EVENT) { ... } case AddTransition: switch (EVENT) { ... } case ... } • Using a state transition matrix

13-27

13-28

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Using Method Implementation • State behavior of a class is implemented by member functions that denote an event in the state diagram. • The current state of the object is stored in an attribute of the class. • A member function evaluates the state variable and the guard condition, executes the appropriate response actions, and updates the state variable.

13-29

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Problems with Conventional Approaches • High cyclomatic complexity (number of states multiplied by number of transitions). • Nested case statements make the code difficult to comprehend, modify, test, and maintain. • Difficult to introduce new states (need to change every event case). • Difficult to introduce new events (need to change every state case). • Solution: apply state pattern

13-30

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Transformation Schema for Real Time Systems • Ward and Mellor extended DFD with control flows and control processes. • Control processes are modeled by Mealy type state machines. • Control processes control the ordinary data transformational processes. • Control flows represent events or triggers to control processes and responses of control processes to transformational processes.

13-31

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Transformation Schema for Real Time Systems • Real time data flows, which must be processed quickly enough to prevent losing the data.

• Data flows and control flows may be related using logical connectors.

• Timing may be specified for state transitions and data transformation processes.

13-32

transformational processes, representing computations or information processing activities

control processes, representing system’s state dependent behavior, which is modeled by a Mealy type state machine continuous data flow, which must be processed in real time ordinary or discrete data flow

event flow or control flow that triggers a transition of the state machine of a control process, or a command from a control process to a transformational process 13-33

a indicates that either data flow a or data P + flow b is required to begin executing b process P

These logical connector can be applied to both data flow and control flow and transformation process and control process.

13-34

X Two subsets of Z are used by two different Z successor processes. Y

Z All of Z is used by two different successor processes.

X Z Z is composed of Two subsets provided by two Y different predecessor processes.

Z All of Z is provided by either one of two predecessor processes.

13-35

brake resume Record enable/disable Rotation trigger Rate 2.2.2 rotation rate start/stop Cruise increase Control speed 2.2.1 speed reached enable/ throttle disable control Return to enable/ Previous disable enable/ Speed rotation rate disable 2.2.5 throttle rotation position rate Increase throttle Maintain Speed 2.2.3 control Constant Speed rotation rate set point throttle 2.2.4 control throttle throttle position position rotation rate

13-36

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Cruise Control State Machine enable/trigger “Record Rotation Rate”, enable “Maintain Constant Speed brake/disable “Maintain Constant Speed” Maintain Speed start increase speed/disable stop increasing speed/disable “Increase “Maintain Constant Speed”, Speed”, trigger “Record Rotation Speed” enable “Increase Speed” enable “Maintain Constant Speed” Increase Speed brake/disable “Increase Speed” Interrupted

resume/enable “Return brake/disable “Return to Previous Speed” to Previous Speed” Resume Speed

13-37

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Timed State Machine • Time intervals can be used to label the state transitions. • The time intervals define the timing lower bounds and upper bounds allowed for processing the event and executing the list of actions. • The time interval can be decomposed to define the allowed times for processing the event, and executing each of the actions in the action list. • Similarly, time can be defined for state entrance action, state exit action, and state activity.

13-38

event/action event/action [x,y] [x] S1 S2 S1 S2

Time interval. Time interval. The time allowed for processing The time allowed for processing the event and executing the the event and executing the action is x to y time units. action is x time units. track(contact)/ event[x,y]/ (targetList.fit action[u,v] (contact)[5,8]) S1 S2 S1 S2

The time allowed for processing The time allowed for targetList the event is x to y time units object to fit the contact with a and executing the action is u to tracked target is 5 to 8 time v time units. units. 13-39

• Nested case statements make the code difficult to comprehend, modify, test, and maintain.

• Difficult to introduce new states (need to change every event case).

• Difficult to introduce new events (need to change every state case).

13-4040

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Applying State Pattern • The state pattern is a low complexity and easy to extend approach to implement a state machine. Each mathod is Each method is “state:=state.ti();” “return this;” i=1, 2, 3 t1() t2()[c1]/a() Subject State t1() state t1(): State S1 S2 Client t2() t2(): State t3() t3()[c2] t3(): State State machine for a subject Legend: S1 S2 S1, S2: states implement t1() t2(): State t1(), t2(): state transition t1(): State behavior; t3(): State [ci]: guard condition return new S2(); /a(): action to be performed 13-4141

CruiseControl State states : State [ ] CruiseDeactivated onOffButtonPressed() onOffButtonPressed onOffButtonPressed leverDown() (c:CruiseControl) (c:CruiseControl) leverUp() leverDown (c:CruiseControl) brakeApplied() leverUp (c:CruiseControl) leverDownAndHold() leverReleased (c:CruiseControl) leverUpAndHold() state leverDownAndHold (c:CruiseControl) leverUpAndHold (c:CruiseControl) leverPulled() leverPulled(c:CruiseControl) CruiseActivated leverReleased() brakeApplied(c:CruiseControl) setDesiredSpeed(c:CruiseControl) onOffButtonPressed (c:CruiseControl)

DecreasingSpeed IncreasingSpeed CruisingCancelled Cruising leverReleased leverReleased leverDownAndHold(c:CruiseControl) leverDownAndHold(c:CruiseControl) (c:CruiseControl) (c:CruiseControl) leverUpAndHold(c:CruiseControl) leverUpAndHold(c:CruiseControl) leverDown(c:CruiseControl) leverDown(c:CruiseControl) leverUp(c:CruiseControl) leverPulled(c:CruiseControl) brakeApplied(c:CruiseControl) 13-42

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Benefits of State Pattern • Significantly reduces the cyclomatic complexity of the state handling code. • Easy to add states --- simply add state subclasses and implement the relevant operations. • Easy to add transitions --- simply add operations to the State class and implement the operations in relevant State subclasses. • Easy to understand, implement, test and maintain.

13-4343

if (rmTempsetTemp) else furnaceRelay.off(); acRelay.on() else acRelay.off(); timerOff() heat()/ cool()/ startTimer() startTimer() HEATING OFF COOLING off()/ off()/ timerOff() stopTimer() stopTimer() AC Relay Furnace Relay off() off() OFF COOLING off HEATING on() on()

13-4444

State states[OFF]=new OFF(), SeasonSwitch $states: State[] states[COOL]=new COOLING(), cool() state cool():State states[HEAT]=new HEATING(); heat() off() heat (): State off (): State if (rmTemp

COOLING HEATING OFF timerOff() timerOff() cool(): State off (): State off (): State heat (): State stopTimer(); stopTimer(); startTimer(); acRelay.off(); furnaceRelay.off(); furnaceRelay.on(); return states[OFF]; return states[OFF]; return states[HEAT]; 13-4545

Activity Diagram - Flowchart showing concurrency

CFD is an Extension to DFD to Combine State Behavior with Processing – SA/SD Origin – Ward and Mellor – Transformational Schema for Real-Time Systems

Activity Diagram is UML Model to Achieve Similar Analysis and Specification to Unify Object State Models with Transformation

We Recommend Doing Both, but Activity Diagrams are Supported by UML and UML Tools (Key Advantage) © Sam Siewert 46 Key Takeaway Points • Activity modeling deals with the modeling of the information processing activities of an application or a system that exhibits sequencing, branching, concurrency, as well as synchronous and asynchronous behavior.

• Activity modeling is useful for the modeling and design of transformational systems.

14-47

(a) Planning Phase (b) Iterative Phase – activities during each iteration control flow data flow control flow & data flow 14-48

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. What Is Activity Modeling • Activity modeling focuses on modeling and design for – complex information processing activities and operations – information flows and object flows among the activities – branching according to decisions – synchronization, concurrency, forking, and joining control flows – workflow among the various departments or subsystems 14-49

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Why Activity Modeling Systems analysis and design need to • describe current information processing activities in the organization or existing system (modeling of the existing system) to help the development team understand the existing business • describe information processing with the proposed solution (system design)

14-50

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Activity Diagram • An activity diagram models the information processing activity in the real world (analysis model) or the system (design model). • A UML activity diagram is a combination of – flowchart diagram • for decision making or branching – data flow diagram • for information processing and data flows – Petri net diagram • for various control flows • for synchronization, concurrency, forking, and joining 14-51

Flowchart with concurrency shown

Fork and Join

Decision logic

Procedures

Start state

Final state

Activity or action Conditional branching Control flow Object flow obj:Class Forking

Joining or synchronization Swim lane to represent info and control flow between departments/subsystems Initial node, final node, and flow final node 14-53 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. A Flowchart

decision x=x+1 making x<10

y=y+1

y<10

14-54

Books information processing Book activity details Publishers address orders 1 2 Customer Verify verified Generate Order order Requisition Publisher to Publisher Purchase Credit status Pending orders orders Order details data flow Customers

14-55

Petri-Net Simulations – E.g. http://www.tapaal.net/

56 Petri Nets

places, representing an abstract condition

transitions, representing an event or happing

relationship between a place and a transition, it can only come from a place to a transition or from a transition to a place

tokens, which can be placed in places to indicate that the condition is true

14-57

You can interpret a new job arrives the places and transitions. That processor available is, assigning job meanings to them. waiting events begin process job being processed

process done condition of system job ready to go

job leaves

14-58

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Petri Net Execution • A transition is enabled if t1 and only if each of its input places contains a token. t2 • A transition can be fired sooner or later if it is enabled.

t3 • Firing a transition – removes a token from each of its input places AND – places a token into each of t4 its output places 14-59

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Petri Net Marking An initial marking is an t1 assignment of tokens to places. p2 t1 is always enabled, because it does not p1 have an input place. t2 firing t1 places a token in p1 t2 is now enabled p3 firing t2 removes one token from each of p1 and p2 and places one t3 token in p3

p4 t3 is now enabled firing t3 removes one token from t4 p3 and places one token in p4 and p2 14-60

“a new job arrives” is always enabled, a new job arrives processor meaning a new job can arrive anytime. available job fire “a new job arrives” waiting “begin process” is now enabled begin process fire “begin process” job being job is being processed processed “process done” is now enabled process fire “process done” done job is ready to leave & processor is job ready to go available again “job leaves” is now enabled job leaves

fire “job leaves” 14-61

t1 (p1, p2, p3, p4) p2 (0, 1, 0, 0) p1 t1

t2 (1, 1, 0, 0) t2 t1 p3 (1, 1, 0, 0) (0, 0, 1, 0)

14-62

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Petri Net Analysis Tree • A marking is presented by a list t1 of “0” and “1”: p2 p1 (n1, n2, ..., nk) where ni = 1 if place i contains a t2 token

p3 • The root of the tree denotes the initial marking (initial system

t3 state). • Thus, the initial marking and p4 root of tree for the Petri net on left is: t4 (0, 1, 0, 0). 14-63

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Petri Net Analysis Tree t1 p2 p1 • Firing a transition grows t2 the tree with a new p3 branch, labeled by the t3 transition fired and the (0, 1, 0, 0) p4 resulting new marking. t4 t1 t1 (1, 1, 0, 0) p2 p1 t1 t2 t2 (0, 0, 1, 0) t1 p3 (1, 1, 0, 0) p2 t1 p1 t3 p2 p1 t2 p4 t2 p3 t4 p3 t3 t3 p4 p4 t4 14-64 t4 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Petri Net Analysis

t1 w denotes a (0, 1, 0, 0) large number of tokens t1 p1 p2 because t1 (w, 1, 0, 0) can be fired t2 many times. t2 (w, 0, 1, 0) p3 t3 t3 (w, 1, 0, 1) t4 t2 p4 (w, 1, 0, 0) (w, 0, 1, 0) t4 These have occurred at a higher level. 14-65 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Petri Net Expressiveness

parallelism

sequencing

synchronization

exclusion

14-66

Activity or action Conditional branching Control flow Object flow obj:Class Forking

Joining or synchronization Swim lane to represent info and control flow between departments/subsystems Initial node, final node, and flow final node 14-67 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Box Office Order Processing branching branching Set Up Order condition [single order] Assign Seats activity [subscription] forking to create Assign Seats Award Bonus concurrent threads

Debit Account Charge Credit Card joining to synchronize concurrent threads

Mail Package merging alternating threads

14-68

object flow Place Order Pack Items

: NewOrder Ship Order branching Verify Order forking

[reject] [ok] Show Msg Fill Order

: Invoice Send Invoice

Make Payment Process Payment

merging alternating joining routes Close Order concurrent threads 14-69

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Activity Decomposition and Invocation • A complex activity can be decomposed and <> represented by another activity diagram. An Activitiy Database • The rake-style symbol is used to signify that the It is described by activity has a more a more detailed detailed activity Another DB activity diagram. diagram.

14-70

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Expansion Region • An expansion region is A collection of a subset of activities or line items Place Order actions that should be :Order repeated for each :LineItem element of a collection. Add Item to Add Cost to • The repeated region shipment Invoice may produce one or :Item :LineItemCost

more collections. :Shipment :Invoice Ship Order Send Invoice

Expansion region

14-71

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Using Activity Diagram • Modeling, analysis and design of complex information processing activities involving one or all of the following: – control flows – object flows or data flows – access to databases or data depositories – conditional branching – concurrent threads – synchronization • Work flow among multiple organizational

units and/or subsystems. 14-72 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Using Activity Diagram • Activity diagram can be used alone or used with the other diagrams. • Activity diagram can be used to model the information processing activity of a system, subsystem or component, or a method of a class.

14-73

14-74

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Relation to Other Diagrams • An activity may be a use case, or suggest a use case. Therefore, activity modeling is useful for identifying use cases. • Activity diagrams are useful for showing workflows and control flows among use cases. • Activity modeling is useful for processing complex requests in a sequence diagram. • An activity may exhibit state-dependent behavior, which can be refined by state modeling.

14-75

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Relation to Other Diagrams • A state may represent a complex process, which can be modeled by an activity diagram. • Each object sent from one activity to another should appear in the design class diagram (DCD), or the domain model. • Swim lanes may suggest object classes in the domain model, or the DCD. The activities of the swim lane identify operations for the class. • A complex activity may decompose into lower-level activities. Some of these may be operations of the class.

14-76