Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
THEHATLEY/PIRBHAI
MODEL
So!Now I know alittle about the
DeMarco Model.But what’s thisHatley/Pirbhai
stuff?
Real-Time Structured Analysis - Hat/Pir MSE - ANU
INFORMATION vs REAL-TIME SYSTEMS
Information Systems:
– Analysed & designed on basis of static data models.
– Emphasis on data storage, update and access.
– Timing issues (although important) are not critical.
Real-Time Systems:
– Analysed & designed with an emphasis on timerelated change in conditions and processes.
– Data storage is usually not encyclopedic andtherefore does not require rigorous modelling.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
REAL-TIME (EMBEDDED) SYSTEMS
DEFINITION:
• Any information processing activity or system whichmust respond to externally generated input stimuliwithin a finite & specified period of time (Young - 1982)
HARD REAL-TIME SYSTEMS:
• Are critically time dependent.
• Missed deadlines may be disastrous.
SOFT REAL-TIME SYSTEMS:
• Are time dependent.
• Missed deadlines not usually disastrous.See Burns & Wellings (Ref 26)
Real-Time Structured Analysis - Hat/Pir MSE - ANU
ASPECTS FOR CONSIDERATION
• Size and ComplexityManagement, Staffing, Development Techniques, Estimating,
Scheduling, Maintenance, Metrics etc.
• AlgorithmsManipulation of real numbers. Mathematical modelling of
system components that are under control (eg. PID).
• Reliability and SafetyExceptional conditions of operation. Risk of failure
predictions. Provision of facilities to guarantee reliability.
• ConcurrencyRecognition of separate system elements that must work or
be controlled in parallel.
• Time DependencySeparation of those system inputs that cause the generation
of certain system outputs within specific time constraints.
• Interaction with other systems
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
S/W ELEMENTS OF REAL-TIME SYSTEMS
Digital ControlAlgorithms
Data Acquisition
Data Retrieval, Massaging & Display
Operator Interface
DATABASE
INTERFACE
DISPLAYDEVICES
OPERATOR’SCONSOLE
MONITORINGSYSTEM
PROCESSINGSYSTEM
REAL-TIME CLOCK
REAL-TIME COMPUTER
Real-Time Structured Analysis - Hat/Pir MSE - ANU
DEMARCO MODEL REVISITED
• Assumes ideal technology:
Instantaneous responses.
Steady state operation.
Time independent.
• De-emphasises control view:
Decisions described at PSpec level only.
Ignores process sequencing/activation.
Little support for describing states.
• Emphasises data view:
All processing is on data.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
HATLEY/PIRBHAI MODEL
• Hatley/Pirbhai (Requirements) Model =
DeMarco (Data Processing) Model + Control Model
• Control Model is used to specify:
–Requirements that exhibit finite state machine behaviour.
–What behaviour the Data Process Model must exhibit whenthe system is under the influence of particular external orinternal conditions or operating modes.
–Separate operational modes.
–High level decisions that affect operational modes.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
THE HATLEY/PIRBHAI MODEL
Requirements Specifications are constructed using:-
– Data Flow Diagrams & Control Flow DiagramsShowing data processes, data inputs and outputs.
Showing control processing, control inputs and outputs.
– Requirements DictionaryContaining definitions of data inputs, outputs, stores andintermediate data plus definitions of control inputs, outputs,stores.
– Structured LanguageAs for DeMarco Model.
– Control SpecificationsFSMs which map control inputs to control outputs &/or showcontrol of data processes according to the control inputs.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
PROCESSTRANSFORM
FUNCTIONBUBBLE
DFD/CFD ELEMENTS
TERMINATOR
DATAFLOWS
STORE
Processes should be named with a short action clause summarisingwhat is to be done to the input (data) in order to produce the output (data).
• Dataflows indicate the content and direction of flow of information (or materials) to and from processes, stores and terminators.• Treat them as pipelines along which single or groups of data/material items of known content and nature can flow.• Their names reflect their content - nouns or adjectives.• They do not contain or represent dynamic behaviour - no verbal names.
• Stores represent dataflows or control flows that are frozen for an indeterminate time.• The (data or control) information/materials they represent can be accessed at any time and in any order - non-destructively.• Nouns and/or adjectives should be used - sometimes plural.• Event stores (Ward/Mellor) queue incoming events - reads are destructive.
Terminators represent things that are external to the system, but whichare important because they provide &/or receive system input and output.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
DFD/CFD ELEMENTS
• Control flows indicate the composition and direction of flow of control information to and from CSpecs, control stores and terminators.• Treat them as pipelines along which single or groups of control items of known composition flow.• Their names reflect their content - nouns or adjectives.• They do not contain or represent dynamic behaviour - no verbal names.• Event flows (Ward/Mellor) have similar meaning to control flows but are also used as prompts to enable/disable processes and they do not contain grouped elements.
CONTROLFLOWS
CSpec
• Control Specifications (CSpecs) are used to indicate finite state machine behaviour in the form of:
STATE TRANSITION DIAGRAMSSTATE EVENT MATRICESDECISION TABLESPROCESS ACTIVATION TABLES
See Hatley/Pirbhai (Ref 8) and Ward/Mellor (Ref 9)
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL FLOW DIAGRAMS
Basic characteristics of CFDs:
• They are paired with Data Flow Diagrams
• Have the same:
Numbering, Levelling, Balancing, Parent/Child relationships.
• Show processes (same as DFDs) but not Data Flows.
• Only concerned with elements that are affected by control.
• Data processors are affected by high level control decisionsbut data flows are not.
• Show Control Flows and Stores
• Show Control Specifications (if any)
Real-Time Structured Analysis - Hat/Pir MSE - ANU
DATAFLOW DIAGRAM DECOMPOSITION
RequirementsDictionary
Data Flow /Data StoreDefinition~~~~~~~~~~~~~~~~~~
DFD 1.1 DFD 1
DFD 0
CONTEXT DATA
THE SYSTEM
0
Actuator
Human
Physical Environment
Software Package
Sensor
PROCESS
1PROCESS
2
PROCESS
3PROCESS
4STORE-A
PROCESS
1.1.1PROCESS
1.1.2
PROCESS
1.1.3
STORE-A
PROCESS
1.1PROCESS
1.2
PROCESS
1.3
STORE-B
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL FLOW DIAGRAM DECOMPOSITION
RequirementsDictionary
Control Flow /Control StoreDefinition~~~~~~~~~~~~~~~~~~~~~~
CFD 1.1 CFD 1
CFD 0
CONTEXT CONTROL
PROCESS
1.1PROCESS
1.2
PROCESS
1.3
STORE-B
Control Output-A
Control Input-A
s1
s2
Decision
PROCESS
1PROCESS
2
PROCESS
3PROCESS
4STORE-A
Control Input-AControl
Input-B
s1
Control Output-A
Control Output-B
THE SYSTEM
0
Actuator
Human
Physical Environment
Software Package
Sensor
Control Output-B
Control Output-A
Control Input
PROCESS
1.1.1PROCESS
1.1.2
PROCESS
1.1.3
STORE-A Decision
Real-Time Structured Analysis - Hat/Pir MSE - ANU
COMBINED DFD/CFD DECOMPOSITION
DFD/CFD 1.1 DFD/CFD 1
DFD/CFD 0
CONTEXT DATA & CONTROL
THE SYSTEM
0
Actuator
Human
Physical Environment
Software Package
Sensor
Control Output-B
Control Output-A
Control Input
PROCESS
1PROCESS
2
PROCESS
3PROCESS
4STORE-A
Control Input-AControl
Input-B
s1
Control Output-A
Control Output-B
PROCESS
1.1.1PROCESS
1.1.2
PROCESS
1.1.3
STORE-A Decision
PROCESS
1.1PROCESS
1.2
PROCESS
1.3
STORE-B
Control Output-A
Control Input-A
s1
s2
Decision
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL FLOWS
• Represent pipelines that transport control informationof known composition.
• Named according to content - use nouns or adjectives.
• Compositional elements can be primitive or collective.
• Primitive elements always consist of discrete values.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL FLOWS
POSSIBLE SOURCES:
» External environment
» Control Specifications (CSpecs)
» Process Specifications - resulting from decisionsmade within PSpec about input data conditions.
POSSIBLE DESTINATIONS:
» External environment
» Control Specifications
» Not PSpecs - they only transform data inputs.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
REQUIREMENTS DICTIONARY
• Contains definitions of both data flows & stores andcontrol flows & stores.
• Notation used for all definitions is that of DeMarco.
• Primitive data flow definitions can be continuous ordiscrete in nature.
• Primitive control flow definitions must be discrete innature.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
REQUIREMENTS DICTIONARY
Symbol
=
This + That
n{ That }m
[ This | That | Another | ... ]
(This)
" That "
* Note about this & that *
This + That + Another + ...
<That>This
Meaning
composed of
This together with That
n to m iterations of That
select one of This or That or Another or ...
This is optional
literally the word That
comment field and/or primitive element
key attribute of data entity (@ in TeamWork)
That version of This (TeamWork only)
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
Door_Position = [“Open” | “Closed”]
* The only door positions of interest *
----------
Rate: Event-driven by operator.
Fan_Setting = [“Off” | “Low” | “Medium” | “High”]
* Various fan rotation speed settings *
----------
Rate: As required.
Received = [“True” | “False”]
* Indicator for acknowledgment of receipt of certain signals *
----------
Versions: <Start_Date>, <Start_Time>, <Duration_Time>
CONTROL FLOW DEFINITION EXAMPLES
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL FLOW DEFINITION EXAMPLES
Primitive definition:
Windows_Command =
[“Main” | “Accessories” | “Windows_Applications”]
Decomposable definition:
Windows_Command =
[Main | Accessories | Windows_Applications]
Main =
[“File_Manager” | “Control_Panel” | “Print_Manager”
| “Clipboard” | “DOS_Prompt” | “Windows_Setup”]
Accessories =[“Notepad” | “Write” | “Clock” | “Calendar” | “Terminal”]
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL FLOW DEFINITION EXAMPLES
Grouped definition:
File_Management_Activity =
Main + File_Manager + File_Selection + (File_Operation) + ...
• Primitive control flow definitions are common with mostsystems.
• Decomposable definitions are less common.
• Grouped definitions are relatively uncommon.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS
Absolutes of Real-Time Systems:
– Behave predictably.
– Maintain history of events or system conditions.
– Change behaviour (predictably) according to eventhistory (past and present).
• These properties imply that real-time systems must dealwith a finite number of events and produce a finitenumber of outcomes in order to behave predictably.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS
Represent various finite state machines as follows:
• State Transition Diagrams STD
• State Event Matrices SEM
• Decision Tables DT
• Process Activation Tables PAT
• Finite State Machines (FSMs) can be used only when afinite number of inputs having a finite set of values canlead to a finite number of outputs (or set of actions)having a finite set of values.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS
CSpecs are best used for systems that exhibit:
• significant numbers of states or modes of operation.
• significant complexity in terms of elaborating decisionsthat affect or determine system configuration or modesof operation.
• significant numbers of inputs (events) that have noeffective content and merely serve as triggers/signalsfor actions that affect operational modes (or states) ofparts of the system.
• high level management control of large portions of thesystem.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS
The FSMs within CSpecs are best used to:
• elaborate system states in terms of externallyobservable behaviour - with STDs.
• specify states in terms of combinations of active andinactive processes - with STDs and PATs.
• specify sequences of high level actions that changeoperational modes - with STDs and PATs
• specify results of particular combinations of controlinput - with DTs and PATs
• map combinations of input control signals into anoutput signal - with DTs.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TYPES OF FSM USED WITHIN CSPECS
Two Categories:
COMBINATIONAL
– Outputs are uniquely determined by current inputs.
– Keeps no information of past events (no memory).
– Include Decision Tables & Process Activation Tables.
SEQUENTIAL
– Outputs determined using both current and previousinputs.
– Maintains information on specific system conditions(has memory).
– Include State Transition Diagrams & SEMs.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
COMBINATIONS OF FSM TYPES IN CSPECS
ACTION LOGIC
COMBINATIONAL MACHINE
(PAT)
DECISION LOGIC
COMBINATIONAL MACHINE
(DT)
SEQUENTIAL MACHINE
(STD)
Control Events
Control Actions
Action Decisions
Event Decisions
Control Actions
Real-Time Structured Analysis - Hat/Pir MSE - ANU
HATLEY/PIRBHAI & SEQUENTIAL FSMs
Basic Characteristics:-
1 Use a hybrid form of Mealy and Moore models in anattempt to take advantage of both models.
– Basically use Mealy model.
– Additionally use Moore when it is (more) convenient.
2 Define states as being the mode or condition of system.
3 Output of SFSM includes activation of processes.
4 Actions associated with a transition continue in effectuntil the next transition.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
HATLEY/PIRBHAI SFSM CONVENTIONS - STD
Actions includeactivation of processes onassociated DFD.
When Process-1 isactivated, it will remainactive (in State-2) untilEvent-3 causes atransition from State-2.
Events are represented withinput Control Flow values
Actions are represented with output Control Flow values or indicated Process Activations
CFD/DFDSTD
DataFlow-3
DataFlow-2
Event-1/Action-2
Event-3/Action-1; Action-2
DataFlow-1
Event-3
Event-2
Action-1
Action-2
Event-1
Event-2/Action-2
Event-3/Enable Process-2
Event-1/Enable Process-1
/Action-1
State-1
State-2
State-3
Process-1
Store
Process-2
Real-Time Structured Analysis - Hat/Pir MSE - ANU
DataFlow-3
DataFlow-2
DataFlow-1
Event-3
Event-2
Action-1
Action-2
Event-1
Process-1
Store
Process-2
EVENT
STATE
Enable P-1
State-2
Action-2
Action
Next State
Action-2
State-2
Enable P-2
State-3
A-1 & A-2
State-1
Event-1 Event-2 Event-3
State-1
State-2
State-3
HATLEY/PIRBHAI SFSM CONVENTIONS - SEM
The State Event Matrix is analternative form for an STD.
CFD/DFDSEM
For Mealy form of SFSM cells of the matrixthat correspond to a transition will containthe resulting action together with the nameof the destination state.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
HATLEY/PIRBHAI CFSM CONVENTIONS
The value of Event Decision isdetermined by the combinationof the input values of Event-1,Event-2 and Event-3.
Events are represented withinput Control Flow values
Event decisions are represented withoutput Control Flow values.
CFD/DFDDT
DataFlow-3
DataFlow-2
DataFlow-1Event-3
Event-2EventDecision
Event-1
Process-1
Store
Process-2
Event-1 Event-2 Event-3EventDecision
DiscreteValue-1
DiscreteValue-2
DiscreteValue-3
Decision1
DiscreteValue-2
Discretevalue-3
DiscreteValue-1
Decision2
DiscreteValue-1
DiscreteValue-2
Decision2
DiscreteValue-1
Real-Time Structured Analysis - Hat/Pir MSE - ANU
HATLEY/PIRBHAI CFSM CONVENTIONS
The integer values indicate (de)activation of Process-1 and/or Process-2 and are determinedby the combination of the input values of Event-1,Event-2 and Event-3.
Events are represented withinput Control Flow values
Control Actions are represented withindications of process activation in a table.
CFD/DFDPAT
ControlActions
Only those processes beingcontrolled are shown in the PAT
DataFlow-3
DataFlow-2
DataFlow-1
Event-3
Event-2
Event-1
Process-1
Store
Process-2
Event-1 Event-2 Event-3Process
1
DiscreteValue-1
DiscreteValue-2
DiscreteValue-3
1
DiscreteValue-2
Discretevalue-3
DiscreteValue-1
1
DiscreteValue-1
DiscreteValue-2
0DiscreteValue-1
Process2
0
2
1
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS AS STDs
Light_Setting
Fan_Setting
Lock_Setting
<Timing_Data>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temp>Received
TemperatureTime_Remaining
Heat_Setting
Temperature_Overrun
<Overall>Setpoint_Range
Setpoint_Temperature
<Accepted>Timing_Data
Timing_Data
<Accepted_Duration>Time
Average_Temperature
Calculate
Average
Temperature
Maintain
Setpoint
Temperature
Accept
Setpoint
Temperature
Accept
Timing Data
1
2
4
6
TEMPERATURE_STATISTICS
ACCEPTED_SETPOINT_TEMPERATURE
TEMPERATURE_TOLERANCES
DATE_AND_TIMEACCEPTED_TIMING_DATA
Count Down
To Time Out
7
Oven_Statess1
Processes under control
FSM Control Flow Outputs (Actions)
FSM Control Flow Inputs (Events)
<Additional>Temperature
Combined DFD0/CFD0 showingdata & control processing
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS AS STDs
Light_Setting
Fan_Setting
Lock_Setting
<Timing_Data>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temp>Received
Calculate
Average
Temperature
Maintain
Setpoint
Temperature
Accept
Setpoint
Temperature
Accept
Timing Data
1
2
4
6
TEMPERATURE_STATISTICS
ACCEPTED_SETPOINT_TEMPERATURE
TEMPERATURE_TOLERANCES
DATE_AND_TIMEACCEPTED_TIMING_DATA
Count Down
To Time Out
7
Oven_Statess1
Processes under control
FSM Control Flow Outputs (Actions)
FSM Control Flow Inputs (Events)
CFD0 showing controlprocessing only
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS CONTAINING STDs
IDLE_WAITING
Time_To_Stop/Lock_Setting = "Unlocked"; Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"
(~<Duration_Time>Received | ~<Setpoint_Temp>Received)
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"; Disable "Count Down To Time Out"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"; Enable "Count Down To Time Out"
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"
~<Start_Time>Received
<Start_Time>Received
(~<Duration_Time>Received | ~<Setpoint_Temp>Received)
<Duration_Time>Received & <Setpoint_Temp>Received
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature" Enable "Count Down To Time Out"
Time_To_Start
/Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"
(~<Duration_Time>Received | ~<Setpoint_Temp>Received)/Disable "Count Down To Time Out"
(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &<Duration_Time>Received & <Setpoint_Temp>Received/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";Enable "Count Down To Time Out" READY_WAITING
READY_IMMEDIATE
RUNNING
3
4
5
6
(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& <Duration_Time>Received & <Setpoint_Temp>Received
/Light_Setting = "Off"; Fan_Setting = "Off" Lock_Setting = "Unlocked"
IDLE WITH DOOR OPEN
IDLE WITH DOOR CLOSED
2
1
FSM Actions that control Processes on corresponding DFD
Light_Setting
Fan_Setting
Lock_Setting
<Timing_Data>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temp>Received
Oven_Statess1
Pure Hatley/Pirbhai STD
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECIFICATIONS CONTAINING STDs
RUNNING
/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"
Time_To_Stop/Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"
Door_Position = "Closed"
(~<Duration_Time>Received| ~<Setpoint_Temp>Received
Door_Position = "Open"/Disable "Count Down To Time Out"
Door_Position = "Closed"
Door_Position = "Open"
~<Start_Time>Received
<Start_Time>Received
(~Duration_Time>Received| ~<Setpoint_Temp>Received)
<Duration_Time>Received &<Setpoint_Temp>Received
Door_Position = "Closed"/Enable "Count Down To Time Out"
Time_To_Start
(~<Duration_Time>Received| ~<Setpoint_Temp_Received)/Disable "Count Down To Time Out"
(<Start_Date>Received |~<Start_Date>Received) &<Start_Time>Received &<Duration_Time>Received &<Setpoint_Temp>Received
IDLE WITH DOOR CLOSED /Light_Setting = "Off"; Fan_Setting = "Off" Lock_Setting = "Unlocked"
IDLE WITH DOOR OPEN
/Light_Setting = "On"; Fan_Setting = "High"
IDLE_WAITING
/Light_Setting = "On"; Fan_Setting = "High"
READY_WAITING
/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = Unlocked"; Enable "Count Down To Time Out"
READY_IMMEDIATE
/Light_Setting = "On"; Fan_Setting = "High"
1
2
3
4
5
6
(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& <Duration_Time>Received& <Setpoint_Temp>Received
FSM Actions that control Processes on corresponding DFD
Light_Setting
Fan_Setting
Lock_Setting
<Timing_Data>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temp>Received
Oven_Statess1
Combined Mealy& Moore STD
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECS CONTAINING DTs AND STDs
IDLE_WAITING
Time_To_Stop/Lock_Setting = "Unlocked"; Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"
(~<Duration_Time>Received | ~<Setpoint_Temp>Received)
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"; Disable "Count Down To Time Out"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"; Enable "Count Down To Time Out"
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"
~<Start_Time>Received
<Start_Time>Received
(~<Duration_Time>Received | ~<Setpoint_Temp>Received)
<Duration_Time>Received & <Setpoint_Temp>Received
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature" Enable "Count Down To Time Out"
Time_To_Start/Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"
(~<Duration_Time>Received | ~<Setpoint_Temp>Received)/Disable "Count Down To Time Out"
(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &<Duration_Time>Received & <Setpoint_Temp>Received/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";Enable "Count Down To Time Out"
READY_WAITING
READY_IMMEDIATE
RUNNING
3
4 6
(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& <Duration_Time>Received & <Setpoint_Temp>Received
/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"
IDLE WITH DOOR OPEN
IDLE WITH DOOR CLOSED
2
1
5
Use a DT when combinations of specificevents result in the establishment of particular important conditions of whichthe system needs to be aware.
<Duration_ Time>
Received
<Setpoint_ Temperature>
Received
Minimum_ Inputs_
Available
"True" *Don't Care* "False"
*Don't Care* "True" "False"
"True" "True" "True"
Real-Time Structured Analysis - Hat/Pir MSE - ANU
Minimum_Inputs_
Available<Duration_Time>
Received
Light_Setting
Fan_Setting
Lock_Setting
<Start_Date>Received +<Start_Time>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temperature>
Received
Calculate
Average
Temperature
Maintain
Setpoint
Temperature
Accept
Setpoint
Temperature
Accept
Timing Data
1
2
4
6
TEMPERATURE_STATISTICS
ACCEPTED_SETPOINT_TEMPERATURE
TEMPERATURE_TOLERANCES
DATE_AND_TIMEACCEPTED_TIMING_DATA
Count Down
To Time Out
7
Oven_Statess1
s0 Enough_Inputs
Enough_Inputs
s0
CONTROL SPECS CONTAINING DTs AND STDs
Each CFD contains justONE CSpec sometimesmade up of two or moreSHEETS
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
Minimum_Inputs_
Available<Duration_Time>
Received
Light_Setting
Fan_Setting
Lock_Setting
<Start_Date>Received +<Start_Time>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temperature>
Received
Calculate
Average
Temperature
Maintain
Setpoint
Temperature
Accept
Setpoint
Temperature
Accept
Timing Data
1
2
4
6
TEMPERATURE_STATISTICS
ACCEPTED_SETPOINT_TEMPERATURE
TEMPERATURE_TOLERANCES
DATE_AND_TIMEACCEPTED_TIMING_DATA
Count Down
To Time Out
7
Oven_Statess1
s0 Enough_Inputs
Enough_Inputs
s0
CONTROL SPECS CONTAINING DTs AND STDs
CSpec bars can be duplicated for diagrammatic convenience.Each duplicated CSpec barrepresents the same SHEET.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECS CONTAINING DTs AND STDs
IDLE_WAITING
Time_To_Stop/Lock_Setting = "Unlocked; Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"
~Minimum_Inputs_Available
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"; Disable "Count Down To Time Out"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"; Enable "Count Down To Time Out"
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"
~<Start_Time>Received
<Start_Time>Received
~Minimum_Inputs_Available
Minimum_Inputs_Available
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature" Enable "Count Down To Time Out"
Time_To_Start/Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"
~Minimum_Inputs_Available/Disable "Count Down To Time Out"
(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &Minimum_Inputs_Available;/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";
READY_WAITING
READY_IMMEDIATE
RUNNING
3
4 6
(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& Minimum_Inputs_Available
/Light_Setting = "Off"; Fan_Setting = "Off" Lock_Setting = "Unlocked"
IDLE WITH DOOR OPEN
IDLE WITH DOOR CLOSED
2
1
5
;
SHEET-1 (s1) Oven_States
<Duration_ Time>
Received
<Setpoint_ Temperature>
Received
Minimum_ Inputs_
Available
"True" *Don't Care* "False"
*Don't Care* "True" "False"
"True" "True" "True"
SHEET-0 (s0) Enough_Inputs
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECS CONTAINING PATs AND DTs
“Open”
“Closed”
Door_Position
<Start_Date>Received
<Start_Time>Received
<Duration_Time>
Received
Time_To_Start
Time_To_Stop
<Setpoint_Temperature>
Received
PROCESS7
PROCESS1
Light_Setting
Fan_Setting
Lock_Setting
“Open”
“Open”
“Closed”
“Closed”
“Closed”
“Closed”
“True”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False” “False” “False”
“False” “False” “False”
“False” “False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”“True” “True”
“True” “True”
“True”
“True”“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
*Don’t Care*
“False”
“False”
*Don’t Care*
*Don’t Care*
*Don’t Care*
“Off”
“On”
“Unlocked”
“Locked”
“On”
“On”
“Locked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off” “Off”
“High”
“High”
“High”
0 0
0
0
0
0
0
0
0
0
1
0
1 1
1
1
CONTROL EVENTSEVENT
DECISIONSCONTROLACTIONS
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECS CONTAINING PATs AND DTs
“Open”
“Closed”
Door_Position
<Start_Date>Received
<Start_Time>Received
<Duration_Time>
Received
Time_To_Start
Time_To_Stop
<Setpoint_Temperature>
Received
PROCESS7
PROCESS1
Light_Setting
Fan_Setting
Lock_Setting
“Open”
“Open”
“Closed”
“Closed”
“Closed”
“Closed”
“True”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False” “False” “False”
“False” “False” “False”
“False” “False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”“True” “True”
“True” “True”
“True”
“True”“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
*Don’t Care*
“False”
“False”
*Don’t Care*
*Don’t Care*
*Don’t Care*
“Off”
“On”
“Unlocked”
“Locked”
“On”
“On”
“Locked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off” “Off”
“High”
“High”
“High”
0 0
0
0
0
0
0
0
0
0
1
0
1 1
1
1
The DT part of a combined PAT and DT.
DTs should be used whenever complicated decisions about control input combinationsneed to be made in order to produce possible combinations of control outputs.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECS CONTAINING PATs AND DTs
“Open”
“Closed”
Door_Position
<Start_Date>Received
<Start_Time>Received
<Duration_Time>
Received
Time_To_Start
Time_To_Stop
<Setpoint_Temperature>
Received
PROCESS7
PROCESS1
Light_Setting
Fan_Setting
Lock_Setting
“Open”
“Open”
“Closed”
“Closed”
“Closed”
“Closed”
“True”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False” “False” “False”
“False” “False” “False”
“False” “False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”“True” “True”
“True” “True”
“True”
“True”“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
*Don’t Care*
“False”
“False”
*Don’t Care*
*Don’t Care*
*Don’t Care*
“Off”
“On”
“Unlocked”
“Locked”
“On”
“On”
“Locked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off” “Off”
“High”
“High”
“High”
0 0
0
0
0
0
0
0
0
0
1
0
1 1
1
1
The PAT part of a combined PAT and DT.
PATs can be used whenever complicated decisions about control input combinationsneed to be made in order to produce possible combinations of control actions.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPECS CONTAINING PATs AND DTs
“Open”
“Closed”
Door_Position
<Start_Date>Received
<Start_Time>Received
<Duration_Time>
Received
Time_To_Start
Time_To_Stop
<Setpoint_Temperature>
Received
PROCESS7
PROCESS1
Light_Setting
Fan_Setting
Lock_Setting
“Open”
“Open”
“Closed”
“Closed”
“Closed”
“Closed”
“True”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False” “False” “False”
“False” “False” “False”
“False” “False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”
“False”“True” “True”
“True” “True”
“True”
“True”“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
“True”
*Don’t Care*
“False”
“False”
*Don’t Care*
*Don’t Care*
*Don’t Care*
“Off”
“On”
“Unlocked”
“Locked”
“On”
“On”
“Locked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Unlocked”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off”
“Off” “Off”
“High”
“High”
“High”
0 0
0
0
0
0
0
0
0
0
1
0
1 1
1
1
This PAT contains the transition information of the previous STD.Each row of this PAT could be viewed as representing a state - perhaps!
Using a COMBINATIONAL FSM to represent state information creates ambiguity.Combinational FSMs should be used only in situations when past history is unimportant.
PATs are best usedwhen it is necessaryto view all of thepossible processactivations for a given CFD.
PATs should not beused in lieu of STDsbecause they tend tohide important stateinformation.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPEC CONTAINING DT, STD & PAT
Minimum_Inputs_
Available<Duration_Time>
Received
Light_Setting
Fan_Setting
Lock_Setting
<Start_Date>Received +<Start_Time>Received
Door_Position
Time_To_Stop
Time_To_Start
<Setpoint_Temperature>
Received
Calculate
Average
Temperature
Maintain
Setpoint
Temperature
Accept
Setpoint
Temperature
Accept
Timing Data
1
2
4
6
TEMPERATURE_STATISTICS
ACCEPTED_SETPOINT_TEMPERATURE
TEMPERATURE_TOLERANCES
DATE_AND_TIMEACCEPTED_TIMING_DATA
Count Down
To Time Out
7
Oven_Statess1
s0 Enough_Inputs
Enough_Inputs
s0
Count_Down
Maintain_Setpoint
PATs2
Process (de)activations resultingfrom control actions within an STDcan be made more obvious on thecorresponding CFD by inclusionof a PAT.
The disadvantage is thatsome superfluous controlflows have to be created to connect the STD withthe PAT.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
CONTROL SPEC CONTAINING DT, STD & PAT
IDLE_WAITING
Time_To_Stop/Lock_Setting = "Unlocked"; Maintain_Setpoint = "Off"; Count_Down = "Off"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"
~Minimum_Inputs_Available
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"; Count_Down = "Off"
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"; Count_Down = "On"
Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"
~<Start_Time>Received
<Start_Time>Received
Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Maintain_Setpoint = "On" Count_Down = "On"
Time_To_Start/Lock_Setting = Locked"; Maintain_Setpoint = "On
~Minimum_Inputs_Available/Count_Down = "Off"
(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &Minimum_Inputs_Available/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";Count_Down = "On"
READY_WAITING
READY_IMMEDIATE
RUNNING
3
4 6
(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& Minimum_Inputs_Available
/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"
IDLE WITH DOOR OPEN
IDLE WITH DOOR CLOSED
2
1
5
~Minimum_Inputs_Available
Minimum_Inputs_Available
Alternative to showing (de)activationsof processes within STD is to provideaction decisions (output control flows)that enter a PAT.
Count_ Down
Maintain_ Setpoint
PROCESS 7
"On" "Off" 1
"On" "On" 1
"Off" "Off" 0
PROCESS 1
0
1
0
SHEET-2 (s2) PAT
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
REQUIREMENTS MODEL SUMMARY
DATA FLOWDIAGRAMS
PROCESSSPECIFICATIONS
CONTROL FLOWDIAGRAMS
CONTROLSPECIFICATIONS
DataInput
DataOutput
ControlInput
ControlOutput
Control Inputderived from
Data Conditions
Process Activationsderived from
Control Decisions
PROCESS MODEL
CONTROL MODELAdapted from Hatley/Pirbhai-1987 (Ref 8)
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS
System and Software Requirements Specifications:
– are the result of analysis.
– are fully documented statements of what a system orsoftware product must achieve.
– should not contain descriptions of system structureor how to achieve particular requirements.
– become the starting point for design.
Timing Specifications therefore:
– are determined for overall (external) systembehaviour.
– are not provided for particular (internal) processessince no design structure has yet been determined.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS
THESYSTEM
0
TERMINATOR TERMINATOR
TERMINATOR TERMINATOR
T0
0
T10 -T0
0
T 0 -T02
Repetition Rate
Input-to-OutputResponse Time
All Timing Specifications relate toinputs to, & outputs from systemas a whole.
There are two types ofTiming Specification.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS - REPETITION RATE
<Accepted> Timing_Data
Time_Remaining
Temperature_ Overrun
Average_ Temperature
Setpoint_ Temperature
Timing_Data
Temperature
Heat_Setting
Light_Setting
Fan_Setting
Door_Position
Lock_Setting
Maintain Oven
Temperature
0
OPERATORDOOR
EXHAUST FAN
OVEN LIGHT
HEATING ELEMENTTHERMOMETER
Output signal(s) that are requiredto be recomputed at a particularfrequency.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS - REPETITION RATE
REPETITION RATE:
– The required recomputation rate of signal outputs tothe external environment.
– Is included with the description of the signal in theRequirements Dictionary.
• Example (from previous slide)
Time_Remaining = *The amount of time that remains before a run ends*----------Units: Hours:Minutes:SecondsRange: 0:0:0 to 12:0:0Accuracy: 1 secondRate: Once per minute
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS - I>O RESPONSE TIME
INPUT-TO-OUTPUT RESPONSE TIME:
– A specification of allowable timing ranges (withinwhich the system must respond) for each input eventand the resulting output response(s).
– Can be included with each of the dictionarycomponents that contribute to the various sets ofevent-responses.
– Is better to tabularise.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS - I>O RESPONSE TIME
<Accepted>Timing_Data
Time_Remaining
Temperature_Overrun
Average_Temperature
Setpoint_Temperature
Timing_Data
Temperature
Heat_Setting
Light_Setting
Fan_Setting
Door_Position
Lock_Setting
MaintainOven
Temperature
0
OPERATORDOOR
EXHAUST FAN
OVEN LIGHT
HEATING ELEMENTTHERMOMETER
Input signals and correspondingoutput responses, some of whichare time critical.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
TIMING SPECIFICATIONS - I>O RESPONSE TIME
EXTERNALINPUT
SIGNAL
EXTERNALOUTPUTSIGNAL
RESPONSETIME
EVENT EVENT
Temperature Temperaturevalue is read
Heat_Setting Heat_Settingvalue is issued
< 1 second
Temperatureoutside
tolerance
Temperature_Overrun
Temperature_Overrun value
is issued
< 0.5 second
Door_Position Door isclosed
Fan_Setting,Light_Setting
Fan and Lightare turned off.
< 50 milli secs
Timing_Data Timingdata isentered
<Accepted>Timing_Data
Timing_Datavalue is
accepted
Not critical.
...................... .............. ................... .................... ....................
Table of Specified Input-to-Output Response Times
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
GUIDELINES FOR USING HATLEY/PIRBHAI
There are no strict step-by-step procedures.
However, the following guidelines are useful:-
• Construct an Event/Action list to more easily:
– Identify processes that transform input data (ormaterial) flows into output data flows.
– Isolate those inputs that directly control the internaloperation of the system.
– Isolate those data inputs that are used to makedecisions about controlling parts of the system.
– Identify various operating modes together with theinputs that cause operational mode changes.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
GUIDELINES FOR USING HATLEY/PIRBHAI
• Use Event/Action list to separate data signals fromcontrol signals.
– Data signals usually have some content in the formof a range of non-discrete values.
– Control signals will always have discrete values andtend to be used to trigger some action.
Activate, enable, engage, execute, stop/start, trigger, toggle.
– Some signals may have discrete values but not bepart of the control model - they are then data signals.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
GUIDELINES FOR USING HATLEY/PIRBHAI
• Use Event/Action list to establish processes first.
– Because it is preferable to identify what is to becontrolled before isolating control-type activities.
• Establishing what is to be controlled before thinking too muchabout control issues ensures less confusion and fasterprogress toward a good set of requirements specifications.
– Because the control model is dependent upon theprocess model in most systems.
– By applying DeMarco approach to construct theessential functional abstractions anddecompositions.
• This can be done by transforming the event/action list into a setof event/action diagrams before composing a set of DFDs.
Real-Time Structured Analysis - Hat/Pir MSE - ANU
GUIDELINES FOR USING HATLEY/PIRBHAI
• Keep control issues at a high-level.
– Because it is important to determine systemoperating modes (states).
– Because low-level control issues tend to be morestrongly related to implementation issues.
• Overuse of Hatley/Pirbhai Model at lower levels of functionaldecomposition can obscure specifications with implementationdecisions.
– Because it will aid architectural decisions during thedesign phase.
Page ‹#›
THE HATLEY/PIRBHAI MODEL
Software Improvements©Copyright 1997 Software Improvements
Real-Time Structured Analysis - Hat/Pir MSE - ANU
HATLEY/PIRBHAI & SYSTEM DEVELOPMENT
SYSTEMREQUIREMENTS
COLLECTION
SYSTEMDESIGN
SOFTWAREREQUIREMENTS
ANALYSIS
HARDWAREREQUIREMENTS
ANALYSIS
SYSTEMINTEGRATIONAND TESTING
PRELIMINARYDESIGN
DETAILEDDESIGN
FABRICATION
HWCITESTING
PRELIMINARYDESIGN
DETAILEDDESIGN
CODINGAND UNITTESTING SOFTWARE
INTEGRATIONTESTING
SYSTEMREQUIREMENTS
ANALYSIS
HARDWARE DEVELOPMENT
SOFTWARE DEVELOPMENT