System Models

1. System Models Object-Oriented Software EngineeringCS350

2. System Model • Conceptual model that describes and represents a system • Required to describe and represent multiple views • Describes and represents the multiple views possibly using two different approaches • Non-architectural • Architectural

3. System Model • A system comprises multiple views such as … • Planning • Requirement (analysis) • Design • Implementation • Deployment • Structure • Behavior • Input data • Output data

4. Data Flow Diagram(DFD) • Graphical representation of the "flow" of data through an information system, modeling its process aspects • Often a preliminary step used to create an overview of the system which can later be elaborate • DFDs can also be used for the visualization of data processing (structured design)

5. Data Flow Diagram (DFD) • Shows what kinds of information will be input to and output from the system • Where the data will come from and go to • Where the data will be stored • Does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel (which is shown on a flowchart)

6. Data Flow Diagram(DFD) Function Input/Output File/Database Flow

7. Data Flow Diagram(DFD)

8. State Machine • Used to give an abstract description of the behavior of a system • This behavior is analyzed and represented in series of events, that could occur in one or more possible states • Each diagram usually represents objects of a single class and track the different states of its objects through the system

9. State Machine • Can be used to graphically represent finite state machines(C.E. Shannon & W. Weaver, "The Mathematical Theory of Communication“, 1949) • Another possible representation is the State transition table

10. Examples

11. Examples

12. State Diagram Vs. Flowchart • State machine performs actions in response to explicit events • Flowchart does not need explicit events but rather transitions from node to node in its graph automatically upon completion of activities

13. Exercise • Create a state diagram to model the operation of a simple cell phone • The cell phone has an on/off switch • It has a numeric keypad that produces a keypad press event with a digit as its argument • The phone has a three-way switch that is set to ringing, vibrating, or both; it determines the action of the phone when a call comes in • The phone also has an action button that (a) initiates a call when seven digits have been entered, (b) answers a call when the phone is ringing or vibrating, and (c) terminates a call (hangs up) if a call is in progress • If the action button is pressed when fewer than seven digits have been entered and the phone is not ringing, the digits are erased (this is how dialing mistakes are corrected) • Finally, the phone has a display that shows the digits that have been pressed so far, if any • Use at least one composite state in your model

14. Events & States

15. Event • Something that happens • Affects the system • Type of occurrence rather than actual occurrence • Can have parameters • Placed in an event queue when received • Becomes current event when dispatched • Is consumed after being processed

16. State • Captures the relevant aspects of the system's history • In programming, instead of recording using a multitude of variables, flags, and convoluted logic, you rely mainly on just one state variable • State machines supplemented with variables are called extended state machines

17. State Vs. Extended State • State • Qualitative aspects of a system • Extended state • Quantitative aspects of a system

18. State Vs. Extended State • Example: A state machine representing the behavior of a pocket calculator • Could use an extended state variable DecimalFlagto remember that the user entered the decimal point to avoid entering multiple decimal points in the same number • A better solution is to observe that entering a decimal point really leads to a distinct state entering_the_fractional_part_of_a_numberin which the calculator ignores decimal points

19. State Vs. Extended State • Why? • It eliminates one extended state variable and the need to initialize and test it • The state-based solution is more robust because the context information is used very locally (only in this particular state) and is discarded as soon as it becomes irrelevant

20. Guard Condition • Needed when using an extended state machine • Boolean expressions • Evaluated dynamically based on the value of extended state variables and event parameters • Think IF-THEN-ELSE

21. Action • Performed when an event is dispatched • Examples: • Changing a variable • Performing I/O • Invoking a function • Generating another event instance • Changing to another state

22. Transition • Aka state transition • Switching from one state to another • Caused by a trigger event • Can have a guard in extended state machines(BTW, guard expressions should have NO side effects, such as affecting other guards)

23. Run-to-Completion (RTC) • All state machine formalisms assume that a state machine completes processing of each event before it can start processing the next event • This is called run-to-completion • Requires an event queue • During event processing, the system is unresponsive, so the ill-defined state has no practical significance

24. Hierarchically Nested States • A state machine will attempt to handle any event in the context of the substate, which conceptually is at the lower level of the hierarchy

25. Hierarchically Nested States • If the substate "result" does not prescribe how to handle the event, the event is not • Rather, it is handled at the higher level context of the superstate "on"

26. Hierarchically Nested States • This system is in state "result" as well as "on“ • State nesting is not limited to one level

27. Hierarchically Nested States • States that contain other states are called composite states • States without internal structure are called simple states • A nested state is called a direct substate when it is not contained by any other state • Otherwise, it is referred to as a transitively nested substate

28. Hierarchically Nested States • Top state • Abstract root of state machine • Programming by difference • Ignoring commonly handled events, which are automatically handled by higher-level states

29. Orthogonal Regions • Address the frequent problem of a combinatorial increase in the number of states when the behavior of a system is fragmented into independent, concurrently active parts

30. Orthogonal Regions • Here the complete state is the Cartesian product of the two components and four states

31. Entry/Exit Actions • Entry action - entry to a state • Exit action - exit from a state • Provide means for guaranteed initialization and cleanup

32. Internal Transitions • Internal actions that execute but do not lead to a change of state (state transition) • In the absence of entry and exit actions, internal transitions would be identical to self-transitions

33. Transition Execution Sequence • Evaluate the guard condition associated with the transition and perform the following steps only if the guard evaluates to TRUE • Exit the source state configuration • Execute the actions associated with the transition • Enter the target state configuration

34. Local Vs. external Transitions • Doesn’t cause exit from and reentry to the main source state if … • the main target state is a substate of the main source • the main target is a superstate of the main source state

35. Event Deferral • Sometimes an event arrives when a state machine cannot handle the event • Every state can include a clause[event list]/defer • If an event in the current state’s deferred event list occurs, the event will be saved (deferred) for future processing until a state is entered that does not list the event in its deferred event list

36. Other Symbols • Initial pseudostate • Terminate pseudostate • Entry point • Exit point • Choice

37. Other Symbols • Fork • Join • Final state

38. Exercise • Interpret the following diagrams

39. Exercise

40. Exercise