Escolar Documentos
Profissional Documentos
Cultura Documentos
1330
cess, superbubbles are drawn around groups of processes, 2. Experience and lessons learned with the
control specs and stores on the enhanced data/control flow Hatley-Pirbhai methodology
diagram (EDFD) to show the allocation to architecture
modules. Processes which cannot be fully allocated to a For applying HPM to a complex radar system, several
module, must be decomposed further to permit allocation adaptations were made to the method. The first adaptation
of whole processes to modules. The traceability matrix concerns the flows on the AFD. In HPM, the flows be-
documents the allocation of requirements to architecture. tween modules on the AFD are the flows crossing the su-
Once the requirements and architecture models are com- perbubble boundaries on the enhanced requirements
plete, the process is repeated for each module in the archi- data/control flow diagram. These architecture flows are
tecture model. The processing allocated to a module be- then allocated to interconnects from the AID. A difficulty
comes the core requirements model at the next level. The arises when the modules from the system are expanded into
requirements model is then enhanced to include processing subprojects. The method states that the core requirements
necessary for intermodule communication. As with the for a module are enhanced to handle intermodule communi-
system, the enhanced processing is partitioned into mod- cation. The enhancing is necessary when data must be
ules and the whole process begins again. In this way, a converted to a communication format for transmission
complicated system is specified one layer at a time with across a bus. The result of enhancing is that the data flows
more detail being added at each level. Ultimately, each re- leaving a module are no longer the flows shown on the
quirement is partitioned to either hardware or software. AFD. In fact, the flows allocated to interconnects at the
At each level, the system’s functionality is described in system level do not flow across the interconnects. The en-
the detail appropriate to the level. For example, at the hanced flows from the module subproject are what flow be-
level of a radar system, the detailed processing required to tween modules via interconnects.
generate an excitation waveform need not be specified. It is To resolve this inconsistency, the author made a modi-
sufficient to state that waveforms with certain characteris- fication to the method. The flows on the AFD are taken
tics are required to accomplish a stated purpose and leave from the enhanced requirements for a module. Now, the
the details to a lower level in the total model. flows leaving a module will be shown on the AFD, the
4 2 5
4 1
Module 2 6 AFD
3
Module 3
EDFD 1
Module Core Requirements 2 3
Module Enhanced Requirements
5 2.1
7
2.2
DFD 2.3
6 2.1 1
2.2
2 3
Module 2 requirements 2.4
shown as an example EDFD
AID
Figure 1 Model development process. Enhancing requirements models for each architecture module
before drawing flows on the AFD provides consistent allocation of architecture flows to interconnects.
1331
AFD for a module will balance with the parent AFD, and between hardware and software. The method states that
the allocation of flows to interconnects will remain consis- when requirements are partitioned between hardware and
tent throughout the total model. The penalty for this modi- software, the hardware and software core requirements are
fication is that the AFD and AID cannot be completed un- enhanced to handle hardware/software communication as
til the enhanced requirements for the modules are complete. well as intermodule communication. In radar/processor ap-
This lag did not pose a significant problem for the author’s plications and many others, hardware and software com-
project, especially in light of the gains in consistency municate via registers. This mechanism lends itself to be-
achieved by the modification. The development process for ing modeled as a store. As shown in Figure 2, using
the adaptation, illustrated in Figure 1, is as follows: stores alone or enhanced processes that produce flows into
1. Develop system core requirements including context stores is an effective technique for modeling hard-
diagram, DFDs, CFDs, control specs, process specs ware/software communication. Stores are especially effec-
and dictionary. (Context and top-level DFD shown) tive for communicating control flows between hardware
2. Enhance the core requirements. and software because HPM prohibits transformation of
3. Determine the architecture modules for the system control flows within a process spec.
and draw the ACD. (ACD and AFD with only mod- In Figure 2, hardware process 1 produces a control
ules shown) flow into store B which is accessed by software process 2.
4. Allocate processes, control specs and stores from the Hardware process 3 is an enhanced process which trans-
enhanced requirements to architecture modules using forms the output of hardware process 1 into flow A which
superbubbles and the traceability matrix. is accessed by software process 1 via store A. The output
5. Draw the core requirements for each module in the flows for software processes 3 and 4 must be transformed
system, taking the requirements directly from the in hardware for communication to other modules since
traceability matrix. (Module 2 core requirements software cannot talk directly to an external module.
shown as an example. Processes 4 and 1 from the Hardware processes 4 and 5 accomplish the interface pro-
system are renumbered as 2.1 and 2.2, respectively.) cessing for software, receiving their inputs via stores.
6. Enhance the module core requirements as necessary A final variation from traditional HPM was the addition
for intermodule communication, new user interfaces of an architecture interconnect context drawing. The AID
and maintenance/self-test. (Note: enhanced processing shows the interconnect channels between the system and
is not required for the inputs to process 2.1 because external terminators. However, the AID does not show the
2.1 is an enhanced process from the system model.) destination or source of the external interconnects.
7. Draw the flows and interconnects on the AFD and Furthermore, in complex systems, the AID is very busy
AID based on the boundaries of the enhanced module so external interconnects are not easily identified. The ar-
requirements. (AFD and AID shown) chitecture interconnect context diagram is a valuable tool
The second adaptation of HPM was done in the interface in communicating the system boundary with the customer
A 4 C
2 3 1 1 4
1
1 B A
C 3 B 3
4 2 2 D
D
5
Enhanced processes for
intermodule communication
Figure 2 Hardware/software interface modeling using stores. Hardware processes produce flows
into stores which are accessed by software processes. Software processes produce flows into stores which are
accessed by hardware processes and transformed for intermodule communication.
1332
as it isolates the external interconnections along with their of objects. You also strip the requirements from the re-
source or destination on one drawing. quirements specification into a second class. Finally, you
establish links between objects of the two classes to show
3. Commercial off-the-shelf tools the dependence of Hughes requirements on customer sys-
tem requirements.
The commercial off-the-shelf (COTS) tools were chosen
The tool allows you to associate a set of attributes with
to facilitate generation of the documents and reports re-
the members of a given class. Two of the attributes in use
quired by the customer, and to satisfy resource constraints.
on our project are priority and rationale. It now becomes
The state of our tools environment during the first nine
straightforward to generate a report listing all high priority
months of 1994, is shown in Figure 3. The environment
requirements in the customer specification, and to show for
is distributed across both Unix and Macintosh platforms,
each which requirements in the requirements specification
which is a tool integration challenge.
combine to satisfy that customer requirement.
Originally, the project expected to use a Unix tool to
Additionally, you can include in the report the rationale for
support the HPM architecture model and provide easy inte-
the choice of each requirement.
gration with the requirements traceability tool.
Unfortunately, support for the architecture model was not 4. User developed and enhanced COTS tools
provided when expected. Thus, the decision was made to
use TurboCASE/Sys, which supports the architecture The nature of the current generation of Computer Aided
model and which is hosted only on the Macintosh. In addi- System Engineering (CASE) tools is such that for opera-
tion, the requirements database tool, Requirement tional use on a real project, it is necessary to perform
Traceability Management (RTM) did not support hierarchi- some degree of tailoring, enhancing, and integrating to the
cal requirements definition, so Microsoft Word was used COTS tool set. This results in a set of tools and utilities
for the initial document development. The role of auto- which are either enhanced versions of tools provided by the
mated tools is as follows. vendor (enhanced COTS) or new tools written by your
Radar requirements specification. The text of staff (user developed). The following examples illustrate
the requirements and the boilerplate is captured in Word. the need for the services of a competent toolsmith.
The HPM requirements model is captured in TurboCASE/ Enhanced COTS t o o l s . Referring again to
Sys and exported. The graphics are then touched-up in Figure 3, we focus on the bubble labeled "Strip" in the
MacDraw and pasted into the specification in Word. middle of the diagram. This enhanced COTS tool strips re-
Architecture specification. This specification quirements from a specification generated with Word into
contains the complete requirements and architecture mod- the RTM database. A very coarse, but configurable, strip
els, along with supporting text. The same tools are used to utility is provided with RTM. After some training and ex-
generate it as for the previous specification. perience, you can learn how to tailor and enhance the basic
Trace reports. The main tool for the various trace utility for most of your own needs. We found to our dis-
reports is RTM, a requirements management and tracing appointment that even with help from the vendor we were
tool. To generate trace reports with RTM, you strip the unable to fully satisfy our needs. Our solution has been to
customer requirements specification into the database such resort to some unattractive manual steps to compensate,
that each requirement becomes a separate object in a class while continuing to search for automated means.
A second enhanced COTS example is provided by the
UDT bubble labeled “Generate report.” RTM provides a report
Strip Customer Generate
reqs Trace writing tool, which can pull objects from the database and
RTM report
RTM report format them into reports, of the type described in the pre-
RTM ceding section. An expert user employs a scripting lan-
Link Radar
reqs/attrib Strip guage to specify the format of the report and the objects
Unix UDT and attributes to be included. Several of these report gener-
Macintosh d ators have been developed for the project.
Radar spec Wor Data dict
Enter Edit User developed tools (UDT). The strip bubble is
reqs/attrib
& edit actually a sequence of three filters, the last of the three be-
MacDr DFDs
aw ing the enhanced COTS tool described just above. The first
Enter Structured reqs Export two filters preprocess the file to be stripped in order to
& edit & arch model
prepare it for the last of the three. For this purpose two
TurboCASE/Sys small programs were written by our toolsmith. These are
Figure 3 Operational tool use. Both Unix and simple examples of user developed utilities.
Macintosh tools support project tasks.
1333
A more substantial user developed tool, not shown in information which would not be available otherwise.
the figure, is called AutoDoc. The planned functionality Management must be committed to achieving the benefits
for AutoDoc is to automatically generate the requirements of methods and tools and provide support in overcoming
specification from the RTM database and the HPM tool the initial challenges.
database. In October 1994, we expect to generate the tex- CASE team. The CASE team is a group of individu-
tual portions of new specifications from the requirements als which is responsible for making the use of methods
database. This eliminates a major source of inefficiency and tools a success. Some of the necessary roles for team
and error – maintaining the requirements text in two members are as follows.
places. 1. Methods leader/facilitator. The project needs a
methods leader/facilitator to adapt the methods (e.g.,
5. Operational lessons learned HPM) to the specific application and to help engi-
neers apply methods to the specific application.
Methods and CASE plan. We found the use of a
2. CASE infrastructure leader. Especially during
CASE implementation plan to be very helpful. The plan
the start up phase, a CASE leader is needed to ensure
includes the project goals being addressed by CASE, the
the infrastructure foundation is ready. The CASE
methods to be used and how the tools will support the
leader is also needed to guide the toolsmiths and fo-
methods. The plan provides the link between the program
cus attention on problems that arise.
goals and the daily tasks. Without a clear understanding of
3. Toolsmiths. CASE tools are still immature, and
what the project is trying to accomplish, it is easy to be-
most tools promise more than they can deliver today.
come caught up in performing tool directed tasks which
Toolsmiths are needed to tailor and enhance and con-
may not support project goals. With a CASE plan, when
nect the tools.
tool limitations require work-arounds, they can be judged
4. Expert tool users. An expert tool user for each
against project goals, which then can be consciously modi-
tool provides support to other tool users, communi-
fied if deemed appropriate.
cates user needs to the CASE leader and the tool-
Infrastructure. The tool and method infrastructure
smiths, and is a good point of contact with the tool
needs to be in place and stable before the project begins.
vendor.
Our project staff and our CASE team experienced consider-
5. System administrator. Workstation based tools
able inconvenience due to our shortcomings in this arena.
are complex so a system administrator is needed to
To accomplish the project tasks, the following infrastruc-
maintain licenses, set up accounts, make backups,
ture tasks need to be completed very early:
and resolve tool problems with the host platforms.
1. Select tools and host platforms
2. Set up work area 6. Summary
3. Purchase workstations
4. Purchase software licenses Structured methods, such as HPM, bring structure and
5. Install licenses rigor to complex projects, making the project more man-
6. Develop CASE implementation plan ageable, higher quality, as well as providing a wealth of
7. Conduct methods training project information. Automated tools are required to sup-
8. Conduct tools training port the capture of the diagrams and data, and to assure
9. Develop CASE tool extensions. consistency. A CASE team is required to maintain both
Most of these infrastructure tasks are not technically methods and tools, and to support users. The probability
difficult, however, they are all time consuming and if they of success is greatly improved by deploying a proper in-
are not complete before the project begins, it introduces frastructure ahead of time, developing a clear plan for the
significant risk into the project. use of CASE, providing strong management endorsement,
Management sponsorship. It is important to get and assigning the right people to the task.
management endorsement and support for the use of new
methods and tools. Change is uncomfortable for people References
especially when it means more up-front work. Thus, a [1] D. J. Hatley and I. A. Pirbhai, Strategies for Real-Time
strong management stance is necessary to help overcome System Specification., Dorset House, New York, 1988.
resistance. It is to be expected that the use of new tools [2] E. Yourdon and L. L. Constantine, Structured Design:
and methods initially will slow down project progress, so Fundamentals of a Discipline of Computer Program and
schedule must be adjusted to reflect this. However, new Systems Design., Prentice-Hall, Englewood Cliffs, 1979.
[3] T. De Marco, Structured Analysis and System
tools and methods make a complex task more manageable Specification., Prentice-Hall, Englewood Cliffs, 1978.
when used correctly. For database related methods and
tools, the databases provide a wealth of readily available
1334