Techniques and Tools for Software Requirements Analysis
Download
Report
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