Building System Models for RE Chapter 13 Modeling System Operations
Modeling Instance Behaviors Scenarios as UML Sequence Diagrams
Modeling Instance Behaviors Scenarios as UML Sequence Diagrams
Scenario Refinement Episodes Agent Decomposition Illustrate sub-goals Consider coarse-grained agent first, then refine May involve coarse-grained interactions, rather than pure events. May span successive states (macro-events)
Modeling Class Behaviors State machines (SM) complement scenarios: Make state info explicit Capture behavior of agent of any instance, not just a specific instance Capture all admissible sequences
Modeling Class Behaviors 2 Types of State variables: Snapshot State Possible value for xi SM State Some variable always has the same value regardless of other differing state variable values 2 SM Event Types: External – SM does not control Internal – Controlled by agent associated with SM
Modeling Class Behaviors State Machines as UML Diagrams
Modeling Class Behaviors State Machines as UML Diagrams Transitions labeled by events fire if an event occurs Transitions with no labels fire automatically
Modeling Class Behaviors Guarded Transitions Captures necessary conditions for firing Without an event label -> trigger condition
Modeling Class Behaviors Actions Auxiliary operation applied when transitions fire Used to prescribe operations to be applied in specific circumstances I.e. acquisition of knowledge, display of information to/from the environment, acknowledgement, etc.
Modeling Class Behaviors Event Notifications Allow transition between diagrams Event is notified from producing diagram to consuming diagram Entry/Exit Actions Entry: action has to be applied when entering a state Exit: Action has to be applied when leaving the state * different from pre/post conditions, designates timing
Examples/Tips
Examples/Tips
State Machine Refinement: Sequential and Concurrent Sub-States Sequential Decomposition: decompose SM into sub-states by new transitions Recursive Instance modeled is in super-state iff it is one and only one sub-state Incoming transition to super-state is inherited by every sub-state as an incoming transition Except when non-deterministic
State Machine Refinement: Sequential and Concurrent Sub-States Parallel Decomposition SM decomposed into concurrent sub-states Requires KxN states rather than K^n due to concurrency Models concurrent behavior of agent controlling multiple states in parallel The instance modeled by the state diagram is in the super-state iff it is each concurrent sub-state. Incoming transitions to super-state are inherited to all substates Outgoing tranistion from super-state is inherited by every substate If the outgoing transition has no event or guard label, it is fired when all implicit outgoing transitions have been fired. If the outgoing transition has a guard/event label, it is fired when the event occurs provided the guard is true, forcing exit from all concurrent sub-states.
State Machine Refinement: Sequential and Concurrent Sub-States Guidelines: For each sub-diagram, insert a initial sub-state and a final sub-state for those that reach the desired state. Structure diagrams: do not connect a sequential sub-state of a concurrent state to sequential sub-state of other concurrent states or outer super-states. Check after decomposition to maintain synchronization. Make sure guards, events, etc. line up.
Building Behavior Models Goals capture functional and non-functional aspects have AND/OR structures Pros: Support reasoning in early RE, provide conflict management, threat analysis, evaluation of alternatives, responsibility assignment, animation, requirements doc. generation. Cons: Viewed as too abstract, behaviors left implicit, hard to elicit, hard to make precise. See p. 464, table 13.1
Building Behavior Models Scenarios informal, narrative. Pros: easy for stakeholders to understand, provide acceptance tests for free. Cons: inherently partial, cover few behaviors of specific instances, require large# of scenarios. See p. 464, table 13.1
Building Behavior Models State Machines Visual abstractions of explicit behaviors. Pros: can be formally verified, yield counterexamples when problems are encountered, good basis for code generation Cons: too operational too early in the RE process, difficult to build, too implicit. See p. 464, table 13.1