Hatley and Pirbhai Extensions
12.4.4 Hatley and Pirbhai Extensions
The Hatley and Pirbhai [HAT87] extensions to basic structured analysis notation focus less on the creation of additional graphical symbols and more on the representation and specification of the control-oriented aspects of the software. The dashed arrow is once again used to represent control or event flow. Unlike Ward and Mellor, Hat- ley and Pirbhai suggest that dashed and solid notation be represented separately. Therefore, a control flow diagram is defined. The CFD contains the same processes as
The CFD shows how the DFD, but shows control flow, rather than data flow. Instead of representing con- events move through a trol processes directly within the flow model, a notational reference (a solid bar) to system. The CSPEC
a control specification (CSPEC) is used. In essence, the solid bar can be viewed as a indicates how software
behaves as a "window" into an "executive" (the CSPEC) that controls the processes (functions) rep- consequence of events resented in the DFD based on the event that is passed through the window. The CSPEC,
and what processes described in detail in Section 12.6.4, is used to indicate (1) how the software behaves come into play to
when an event or control signal is sensed and (2) which processes are invoked as a manage events.
consequence of the occurrence of the event. A process specification is used to describe the inner workings of a process represented in a flow diagram.
Using the notation described in Figures 12.12 and 12.13, along with additional information contained in PSPECs and CSPECs, Hatley and Pirbhai create a model of
a real-time system. Data flow diagrams are used to represent data and the processes that manipulate it. Control flow diagrams show how events flow among processes and illustrate those external events that cause various processes to be activated. The interrelationship between the process and control models is shown schematically in Figure 12.14. The process model is "connected" to the control model through data conditions. The control model is "connected" to the process model through process activation information contained in the CSPEC.
A data condition occurs whenever data input to a process result in control output. This situation is illustrated in Figure 12.15, part of a flow model for an automated monitoring and control system for pressure vessels in an oil refinery. The process check and convert pressure implements the algorithm described in the PSPEC pseudocode shown. When the absolute tank pressure is greater than an allowable maximum, an above pressure event is generated. Note that when Hatley and Pirb- hai notation is used, the data flow is shown as part of a DFD, while the control flow is noted separately as part of a control flow diagram. As we noted earlier, the verti- cal solid bar into which the above pressure event flows is a pointer to the CSPEC. Therefore, to determine what happens when this event occurs, we must check the CSPEC.
The control specification (CSPEC) contains a number of important modeling tools.
A process activation table (described in Section 12.6.4) is used to indicate which
F I G U R E 12.14
Process Model
The relationship
data input
between data data output and control
DFDs
models [HAT87]
PSPECs
process activators
Control Model
data conditions
CFDs
CSPECs
control output control input
Data flow diagram
Control flow diagram
Absolute tank
Check & pressure
Converted
pressure
convert Above pressure
pressure
Check & convert pressure
Max pressure
PSPEC
If absolute tank pressure > max pressure
then
set above pressure to “true”; else
set above pressure to “false”; begin conversion algorithm x-01a;
compute converted pressure; end
F I G U R E 12.15
endif
Data conditions
Paper feed status Level 1 CFD for
F I G U R E 12.16
(jammed, empty) photocopier
Start/stop
Read operator
input
Perform problem
diagnosis Reload
paper
Full
Repro fault
processes are activated by a given event. For example, a process activation table (PAT) for Figure 12.15 might indicate that the above pressure event would cause a process reduce tank pressure (not shown) to be invoked. In addition to the PAT, the CSPEC may contain a state transition diagram. The STD is a behavioral model that relies on the definition of a set of system states and is described in the following section.
12.5 B E H AV I O R A L M O D E L I N G
Behavioral modeling is an operational principle for all requirements analysis meth-
? ods. Yet, only extended versions of structured analysis ([WAR85], [HAT87]) provide a
How do I
model the
notation for this type of modeling. The state transition diagram represents the behav-
software’s
ior of a system by depicting its states and the events that cause the system to change
reaction to some
state. In addition, the STD indicates what actions (e.g., process activation) are taken
external event?
as a consequence of a particular event.
A state is any observable mode of behavior. For example, states for a monitoring and control system for pressure vessels described in Section 12.4.4 might be moni- toring state, alarm state, pressure release state, and so on. Each of these states repre- sents a mode of behavior of the system. A state transition diagram indicates how the system moves from state to state.
To illustrate the use of the Hatley and Pirbhai control and behavioral extensions, consider software embedded within an office photocopying machine. A simplified representation of the control flow for the photocopier software is shown in Figure
12.16. Data flow arrows have been lightly shaded for illustrative purposes, but in real- ity they are not shown as part of a control flow diagram.
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
Idle State transition
F I G U R E 12.17
Invoke read-op-input diagram for
Full and start
Invoke manage-copying
Copies done
Full
Invoke read-op-input
Invoke read-op-input
Making copies
Reloading paper
Empty Invoke reload paper
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more