Review of getting started: Dynamic Model - State Diagram. States Labeled with Conditions. Dynamic Models for E.S. More Dynamic Modeling

Size: px

Start display at page:

Download "Review of getting started: Dynamic Model - State Diagram. States Labeled with Conditions. Dynamic Models for E.S. More Dynamic Modeling"

Barnaby Snow
9 years ago
Views:

1 Review of getting ed: More Dynamic Modeling Scenario making: gets us ed thinking about s. Interface (high-level prototyping): helps us to think about order of things. (happening in projects) Event trace: helps to know what object is doing what action. State Diagram creation tips. 1 2 Dynamic Model - State Diagram Graphical representation of a finite state machine. Changing states - transitioning on s. Events - external stimuli and internal messages ex. button pushed; timer complete; tub full. ex. complete sent by state In each state, a set of predicates based on instance variables, is valid. States Labeled with Conditions Microwave Oven _oven/:=t; error:=t open_door/close:=f SOP open_door/close:=f; heat:=f (null) close_door SE1 S0 done/:=f; heat:=f, error do/close:=t close_door close _oven/:=t open_door/close:=f SE2 reset/close:=f; S2 warmup/heat:=t, close, error:=f, close error S4 close; heat _cooking/:=f S3,close, heat 3 4 Dynamic Models for E.S. Dynamic Model for user buttons would be simplistic; button modeling might not be needed. pushed on off button pushed Some environmental units might have behavior that should be modeled. (like an engine shifting through speeds) For embedded systems - might only need one significant behavior model (for controller.) Complex models will be decomposed into more detailed behavioral models. Concurrency could be present within a model. How dynamic model relates to object model One state diagram for each class (with important behavior.) Each class has concurrent behavior. ggregation in the Object Model usually implies concurrency in the Dynamic Model

Changing states - transitioning on s. Events - external stimuli and internal messages ex. button pushed; timer complete; tub full. ex. complete sent by state In each state, a set of predicates based on instance variables, is valid.

2 Examples of ggregation (5.17) Object model Car Ignition Transmission rake ccelerator How to model concurrency within an object Ignition Car Transmission turn key to [Transmission in Neutral] release key off ing on turn key off Neutral push R push N push N push F Forward stop upshift upshift first second third downshift downshift Reverse Each class here will need a concurrent state diagram 7 off ccelerator depress accelerator on release accelerator off rake depress brake release brake on How to hide complexity Not have a flat state diagram Start abstract and then do subdiagrams. use bull s eye Take one abstract state and expand it with state generalization. idle Example of nesting (and other syntax as well) coin in(value) cancel / refund coins coin in(value) Example: lower-level state diagram for Dispense item activity [item empty] [change=0] Do/add to balance(value) select(item) [change<0] Do/test item present; make change [change>0] Do/dispense change Do/move arm to correct row Do/move are to correct column Do/push item off shelf 9 stop 10 Push F State Generalization Neutral Forward Push R Push N Push N Reverse Neutral Push R Push N Reverse Push F Push N Forward Upshift Upshift First downshift Second downshift Third Notation on Transitions and in States Do/ activity takes some time. associated with a state. Guards conditions - boolean [ guard ] ctions : instantaneous associated with an. /action State1 1 (attribs) [condition1]/ action1 do/ activity 1 You might need any or all of these for your project! State2 do/ activity

off Neutral push R push N push N push F Forward stop upshift upshift first second third downshift downshift Reverse Each class here will need a concurrent state diagram 7 off ccelerator depress

3 Checking for completeness and consistency Formal specifications do this better! The mathematical format can allow automation of these types of checks. Every state should have a way in and out. unless ing point or ending point. Look for one object s Dynamic Model sending an that doesn t have any receiving transition in another object s DM. Things to watch out for Think about input from concurrent objects at unexpected times. ex. If more than one TM machine is trying to access the same account at the same time. User input when not planned. (OK to ignore, but make sure that is what is really wanted.) Take your scenarios and see if they work! Walk through seeing that all the object s operations/messages has all the needed transitions Producer-Consumer - Normal Scenario Producer-Consumer State machine 1 get send(.get) data 0 fetch get/send(.) timeout/ send(.nak) data(buf) stash do/save buf data_ready/.data(buf) timeout asic Class Diagram Producer-Consumer State machine 2 get, nak send(.get) data,, nak 0 fetch get/send(.) timeout/ send(.nak) data(buf) nak data_ready/.data(buf) timeout stash do/save buf 17 / 18 3

Things to watch out for Think about input from concurrent objects at unexpected times. ex. If more than one TM machine is trying to access the same account at the same time.

4 Topics Covered: Dynamic Model Timing and Exceptional Handling Dynamic Model Synchronization schemes Exception Handling Timing including safety critical issues. stop Synchronization (Very Simple) Power Plant In concurrent processing, the actions of the objects are rarely independent of each other. One may need to stop and for another process to catch up or get to a certain state. Example: In a nuclear power plant, the model would need to reflect ing for rods to be in place before generating power. off/insert rods off/ close valves; pumps off cool idle Get_ready do/open valves timeout(1s)[water cold] too_hot/insert rods pumps_on heat do/raise rods op_temp/send(pumps_on) pumps do/ pumps Synchronization of States by status detection Synchronization of States by a common 1 1 IN(2) State1 State1 1 1 State2 State2 2 2 Transition between 1 and 2 will not fire until object has entered state Firing of the two transitions in the two models will happen at the same time. 24 4

One may need to stop and for another process to catch up or get to a certain state.

5 Synchronization of States by common data Synchronization of States by Communication State1 do: x:=0 State1 State1 /send(sync) State1 sync State2 do: x:= 1 When(x==1) State2 State2 State2 Transition from State 1 to State 2 will not fire until in State 2. (This assumes shared memory.) Exception Handling Examples of exception handling Events such as resets and hardware interrupts must be handled. These are called Exceptions. Needed if user can exit a sequence of states at anytime. 27 Possible to modeling exiting all the substates of a superstate in UML. Ex. Pushing the N (neutral button) in any of the forward states of a transmission. 3 ways to exit: normal completion, direct transition, and exception. 1 Superstate substate1 exception_ substate2 some_ normal exiting by completion using a final state. Good modularity. normal exit but violates data hiding 28 Timing Issues in Dynamic Model Sometimes the firing of a transition is time dependent, especially in embedded systems. Real-time systems might have transitions that are tied to a real-time clock. States might time-out after a certain length of time. Transitions might need to be stalled for a certain length of time. Timing (Safety critical) Safety critical real-time solutions example: transition out of boiler on state after being in this state for 1 hour, even if one expects a transition on when(temperature>=expected). oiler On when(temperature >= expected) timeout(1h) Off 29 5

) 25 26 Exception Handling Examples of exception handling Events such as resets and hardware interrupts must be handled. These are called Exceptions.

6 Delays in Dynamic Model More Timing Issues in D. M. Sometimes a transition should not be fired for a certain amount of time. This timing constraint can be modeled using timeout and an extra state ex. 10 seconds since the exit from state This will delay the transition to State for 10 seconds. timeout(10s) State Hold State For a real-time system, the might refer to a real-time clock example: changing a traffic signal from day operation to night operation at 10 p.m. Day superstate 2200_hours 0600_hours Night superstate

10 seconds since the exit from state This will delay the transition to State for 10 seconds.

Compliance and Requirement Traceability for SysML v.1.0a

Compliance and Requirement Traceability for SysML v.1.0a 1. Introduction: Compliance and Traceability for SysML v.1.0a This document provides a formal statement of compliance and associated requirement traceability for the SysML v. 1.0 alpha specification, which