Transcript Techniques and Tools for Software Requirements Analysis

System Models
Object-Oriented Software Engineering
CS350
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
System Model

A system comprises multiple views such as …
◦
◦
◦
◦
◦
◦
◦
◦
◦
Planning
Requirement (analysis)
Design
Implementation
Deployment
Structure
Behavior
Input data
Output data
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)

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)

Data Flow Diagram(DFD)
Function
Input/Output
File/Database
Flow
Data Flow Diagram(DFD)
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

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
Examples
Examples
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
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
Events & States
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

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

State Vs. Extended State

State
◦ Qualitative aspects of a system

Extended state
◦ Quantitative aspects of a system
State Vs. Extended State

Example: A state machine representing
the behavior of a pocket calculator
◦ Could use an extended state variable
DecimalFlag to 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_number
in which the calculator ignores decimal points
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
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

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
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)

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

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
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"

Hierarchically Nested States
This system is in state "result" as well as
"on“
 State nesting is not limited to one level

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

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
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
Orthogonal Regions

Here the complete state is the
Cartesian product of the two
components and four states
Entry/Exit Actions
Entry action - entry to a state
 Exit action - exit from a state
 Provide means for guaranteed
initialization and cleanup

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 selftransitions

Transition Execution Sequence
1.
2.
3.
4.
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
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
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

Other Symbols

Initial pseudostate

Terminate
pseudostate

Entry point

Exit point

Choice
Other Symbols

Fork

Join

Final state
Exercise

Interpret the following diagrams
Exercise
Exercise