RD-R149 079 A PROGRAM MANAGER'S METHODOLOGY FOR DEVELOPING 1/2STRUCTURED DESIGN IN EMBEDDED NEAPONS SYSTEMS(U) NAYRLPOSTGRADUATE SCHOOL MONTEREY CA J I RANSBOTHN ET AL.

UNCLASSIFIED DEC 83 F/G 912 N

mEEmohhomhomiImEmhhhEEEohhhEsmEEEohhEEEohEEEmohEohEEshhE

NAIOAL- - - - TAOA -- g - A ** *

1*2

;*,1

111.0 960-I.0

1.25 4 I.

ICRCP ESLTO TS HR

fitO1111- uO .SANAD -6

IEEE,-

NAVAL POSTGRADUATE SCHOOLMonterey, California

DTIC* ELECT

APR 1 2 1984,

THESISDA PROGRAM MANAGER'S METHODOLOGYFOR DEVELOPING STRUCTURED DESIGN

IN EMBEDDED WEAPONS SYSTEMS

by

James I. Ransbotham, Jr.and

Donald F. Moorehead, Jr.

a.. December 1983C-,l

Thesis Advisor: Ronald W. Modes* LUJApproved for public release; distribution unlimited

84 04 12 066

.. ..... .... . . . . . . . . 7

SECURITY CLASSIPICATION OF THIS PAGE (Vlkimi Dat Enered) ______________

RP MATAINPAGE READ INSTRUCTIONSREPOR DOCMENTTIONBEFORE COMPLETING FORM1. REPORT MN491ER 2. GOVT ACCESSION NO. 3. RECIPIENT'S CATALOG NUMBER

4. TITLE (0d Su&Uff.) S. TYPE OF REPORT A PERIOD COVEREDA Program Manager's Methodology for Master's ThesisDeveloping Structured Design in December 1983Embedded Weapons Systems 4. PERFORMING ORG. REPORT NUMBER

7. AUTHOR(S) S. CONTRACT OR GRANT NUMBER(*)

James I. Ransbotham, Jr.andDonald F. Moorehead, Jr.

9PERFORMING ORGANIZATION MNZ AND ADORESS 10. PROGRAM ELEMENT. PROJECT. TASKC

Naval Postgraduate School AE OKUI UBRMonterey, California 93943

It. CONTROLLING OFFICE NAME AND ACDRESS 12. REPORT DATE

Naval Postgraduate School December, 1983Monterey, California 93943 13. NUMBER OF PAGES

I&. MONITORING AGENCY NAME SAOSRESSI differeut fte Controling Office) 15. SECURITY CLASS. (of this eotsp )

UNCLASSIFIED

* 15a. OECLASSIFICATION/ DOWNGRADINGSCHEDULE

16. DISTRIBUJTION STATEMENT (of Oli. RepAff)

*Approved for public release; distribution unlimited

17. DISTRIBuTION STATEMENT (of Ifh. abetreet enteed In Block 26. it different bass Report)

If. SUPPLEUMTARY NOTES

19. KEY WORDS fCo.Mue so muwo. aide if uwsoemy nd idmffflp by block nmnes)

Methodology, Embedded Weapons Systems, Structured Design

77~~ 20. AftTRACI (COMeffa n revese Wd it*1 necemy snd Identify by Week mA..~)$ This thesis demonstrates a methodology to be used by a Program

Manager to allow him to procedurally monitor the design develop-* ment of an embedded weapons system. The methodology consists of a

unique combination of several software engineering strategiesintegrated to form a powerful management tool. The primaryp: objective of the methodology is to provide an algorithmic pro-cedure which stresses simplicity (Continued)

Do 1" 1473 EDITION OF NO14V 61 IS OBSOLETEJN11 S/N 0102* If.014. 6601 1SECURITY CLASSIFICATION OF THIS PAGE (Mhen Doe Enisiec'

SMCUUTY CLAMICATION OF TIS PAGE (3h= DOM ESM"

ABSTRACT (Cont inued)

at all levels of abstraction. Further, the system must becapable of generating good system specifications, good documenta-tion, and fully understandable products. Sample products fromthe implementation of the methodology on the HARPOON ShiboardCommand-Launch Control Set (HSCLCS) are provided for illustrativepurposes.

Accession For0 f

N-TI GRA&I tpc(DTIC TABaUnannounced F]Just ificat io.

4*%

Dist ribiftion/

Availntllity CodesAvail and/or

Dist Speci

%I .

1%

-6

.5,, N 0102- LF- 014- 6601

2 SECURITY CLASSIFICATION OF 11415 PAGa(~MA =74"WaE)

.. ... % 5 .'5*.5 . . 5

Approved for public release; i-stribution unlimited.

a Progzam Manager's .EathodologyfolDevploping structured DesigniEmbedded Weapons Systems

by

Jases I. Pansbotham Jr.Lieutenant Commander, Unite& States Nay

B.S., Georgia Institute of Technology, 1972

and

Donald F. Mooreheall Jr.Lieutenant Commands: Uralel States Navy

B.S., U.S. Naval Acilamy, 1975

Submit:ed in partial fulfillment of therequirements for the degree of

MASTER OF SCIENCE IN COMPUTER SCIENCE

frem the

NAVAL POSTGRADUATE SCHOOLDecember 1983

Authors:

IAproved by:

Thesis Advisor

Second Reader

Chairmaiz, £Epartment of Cotuputer Science

. . . -. _ ... .. .1

pUDean o f n~. Policy Scfie-nces

3

* .'.*, ,- : .. * . ... . .. .".; -., * ,K* , '. , : , ' ', .. ' .'..,m .. -. > *," . -, ;'&:. ..c .: - ..... *-..-

4 ABSTRACT

This thesis demonstrates a methiodology to ba used by aProgram Hanager to allow him to procedurally monitor the

design development of an embedded waapons system. The msth-

odology consists of a unique combination of several softwareengineering strategies intagratal to form a powerful manage-

meat tool. The primary objezctive of the methodology i-s to

provide an algorithmic procedure which stresses simplicity

at all levels of abstraction. Further, the system must be

capatle of generating good syste specifications, good docu-

mentation, and fully understandabla products. Sample prod-

ucts frcm the implementation of the methodology on the

* HARPOON Shipboard Command-Launch Control Set (HSCLCS) are

* provided for illustrative purposes.

'4

4°

TABLE OF CONTENTS

I. INTRCDUCT ION . . . . . . . . . . . . . . . . . . . 10

A. BACKGROUND . .. . . .. . . . . . .. . .. . 10

B. PURPOSE . . . . . . . . . . . . . . . . . . . 11

C. SCOPE OF THE METHODOLOGY ........... 11

D. METHODOLOGY OVERVIEW . . . . . . . . . . . . . 12

II. BACKGROUND OF THE HARPOON CONTROL SET DESIGN . . . 22

A. EXISTING HARPOON WEAPON SYSTEM . . . . . . . . 22

B. FROBLEMS ASSOCIATED WITH EXISTING HSCLCS . . . 24

C. HARPOON WEAPON SYSTEM CONSTRAINTS ...... 25

D. SYSTEM DEFINITION FOR HSCLCS UPGRADE ..... 25

E. STATE OF THE UPGRADE . . . . . . . . . . . . . 26

III. SOFTWARE ENGINEERING SNAPSHOT .......... 28

IV. DESIGN METHODCLOGY .... ............ .... 32

A. METHODOLOGY CRITERIA ............. 38

1. Goals and Principles . . . . . . . . . . . 38

2. Principle Set Synthesis ......... 43

B. METHODOLOGY COMPONENTS . . . . . . . . . . . . 44

1. Data Flow Analysis . . . . . . . ..... 44

2. Transform/Trar.saction Analysis . . . . . . 54

3. Modular Development ........... 71

4. Transition to ADA Design . . . . . . . . . 74

5. Specification Refinement . . . . . . . . . 76

C. METHODOLOGY EVALUATION ............ 77

V. CCNCLUSIONS . . . . . . . . . . . . . . . . . . . 82

APPENDIX A: HSCLCS EATA FLOW DIAGRAMS ......... 85

5

.

APPENDIX E: HSCLCS HIERARCHY CHARTS . . . . . . . . . . 93

APPENDIX C: HSCLCS ACDULE DESCRIPTI3S ........ 106

N APPENDIX D: HSCLCS ADA DESIGN . . . . . . . . . . . . 118

APPENDIX E: HSCLCS SAMPLE SOFTWARE SPECIFICATIONS . . 126

APPENDIX F: HSCLCS SYSTEM DIAGRAMS . . . . . . . . . . 135

-A LIST CF R!FERENCES .... ..... . ..... ... 140

" .BIBLIOGRAPHY 141

INITIAL DISTRIBUTION LIST . . . . . . . . . . . . . . . 142

4.

-N

4.

4;

4-

-4i

.4,"'~ ';..''""". .. ,2"""""""""" "2', . .'-.. .,,•, -:"" . ""'. ". .. , " -.. . . . . . .

*.4

LIST OF PIGORBS

1.1 Program Management High Level Flow Chart . 13

1.2 Detail of the Software Engineering

Methodology .............. .l1.3 Eetail of the CSS System Development.. . 21

2.1 Software Plan from Reference 1 . . . . . . . . . 27

4.1 Methodology Sequential Flow ..... . 344.2 Contributors to the Methodology . . . 37

4.3 Illustration of the Principle Se Synthesis 45

4.4 HSCLCS Source/Sink Diagram . . . 48

4.5 HSCIES System Flow Diagram. . .. .... 51

4o6 HSCCS Decode Output DFD . . . . .... 52

4.7 HSCIES Display Engagement DFD ..... 55

4.8 HSCWCS Display Engagement DFD Refinement One 56

4.9 Transform Flow . . . . . . . . . o . .. . . . 584.10 Transaction Flow . . . . . . . . . o . . . . . . 594.11 Isolation of the Transaction Center . . 61

4.12 Marking the Secondary Flow ....... 634.13 Dominant Flow First Cut Hierarchy . . . 64

4.14 Secondary Flow First Cut Hierarchy . . . . . . . 65

4.15 Cocplete Second-Lev3l Factoring Hierarchy . . . 67

4.16 Hierarchy of Functions: Final Refinemenz . . 70

4.17 Sample Module Description ......... 734.18 Sample Module Design in ADA SDL ...... 76

. 1 Source/Sink Diagram . . . . . . . . . . . . . . 861.2 System Overview DFD . . . . . . . . .... 87A.3 Complete Manual Process Data Flow Diagram 88

1.4 Update Track Data Base DFD ....... 89

1.5 Complete Convert Environmantzal Data DFD . . . 90

7

".

*' a -a - .. .. . % ' . . . . .

I 4* ' i

i -''' . . . . . . . . . . ... .. • , , , % . , : , -

A. 6 Decode Output DFD ........ 91

A. 7 Plan Engagement DFD .. .. .... .. 92

B.i First Cut Transform Analysis.. . . . . . . . 94

B. 2 Refinement of Transform Analysi-s........ 95

B.3 Process Input . . . . . . . . . . . . . . . . . 96

B.LI Prccess Engagement . . . . . . . . . . . . . . . 97

B.5 Process Display . . . . . . . . . . . . . . . . 98

B.6 Program Design Structure . . .. . . . . . . . . 99

P .7 Irarsition Structure of Fi1--ure B.6 . . . . . . 130

B.8 Action Pat-h Structure of Track Data Base

Manager . . . . . . . . . . . . . . . . . 0 . 101

B.9 Actibn Path of EnvironmerntaJ. Da-a Bass

Manager . ............... . . . . 102

B.10 Action Path cf Display Managar . . . . . . . . 103

B.ll Action Path of Engagesment 3anage: . . . . . . 104

B.12 Action Path cf Track Data Base Mgr, withHeuristic . . . . . . . . . . . . . . . . . . 105

1.1 Hardware Component Overview :)f HARPOON

Weapon System . . . . . . . . . . . . . . . . 136

F .2 Existing Cannister Launch HSCLCS MCI? . . . . 137

F.3 Proposed Cannister Launch HSCLCS MCI? . . . . 138F.14 Saxple Display from Proposed MCI? . . . . . . 139

8

- AC Kilo LEDGMENTS

The au-hors wish to thank the following people. LCDR Ron

4 modes, our advisor, fcr supplying -:-- necessary guidance and

s upport to sae us through the diffi.cul. times. LCDR Ron

Kurtlh, our second reader, fcr his insight and tizely encour-

agement. Finally, and most importantly, to our wives, Marti

and Shirley, for suppcr.ing the sucaessful completion of our

work.

"'-.

"! I. IN TRODUCTIDN

l. BACKGROUUD

V Project Management within the Navy involves the

coordination of a ccplex set of managerial and technicalresponsibilities. The complexity is the result of such

factors as the diversified areas in which a Program Managermust become competent and the size and complexity of modern

weapons systems. The task is aggravated and the problems

magnified by several factors including schedule limitaticns

and resource scarcity (human, monetary, procedural manage-

ment tools, etc). Because the current institutionalized

procedures are inadaquate, a Program Manager has insuffi-cient tangible guidelines to organiz _ a project in a way

which will counter and mitigate complexity.

As a consequence, most projects suffer increasing inef-ficiency which is paralleled by a rise in disorganizaticn.

This is a sure result of unccntrolied compl.xity. On_ ofthe more nctable areas of inefficiency is in the Drocess of

specifying -he desired system. Dur current "methodology"

all tco cften generates nebulous and inaccurate system spec-

ifications. This situation be-gins a snowball effect of

increasinc ambiguity as contractors, bidding on the project,

attempt tc design a system to meet specifications which may

not be ccmplete or correct. Ther-fore, contractors are

forced to react to the assumed meanng of poor specifica--ions rather than acting toward generating a clear, logical,

and correct design. This approach to generating specifica-tions generally results in the contractor's proposals not

meeting the user's real need. Hopefully, pzoblems are

discovered early; tie later they surface, the higher the

10

".A .. i ' ,% ,,' '.f , " . . " . " . ' " . - . " . - , . . . - . ".• . . - . . - .. . .L e'I.t ., ,- _- % % --. ' . . " - " . . " . ' . ' . . . . . ' ' "" - .

I

cost to ccrrect them. A- best, however, these unde-ected

flaws cause the needless loss of much time and money (after

the project is given tc a con-racto:-) rege:dless of when

discovered.

To summarize, complexity is inhezent but controllable in

all projects. We currently dc very little in at-empting to

control it. rhe resulting disorganization leads "o time and

money losses mainly due to poor specifications.

E. PURPOSE

This thesis presents a prcc.dd_-al methodology for an

embedded weapons system's s p-c- ficatior development and

design documentation, answering ta9 need defined in theprevious section. The method is abstracted from a case

st.udy of the Harpoon Shipboard Command-Launch Corntrol Set

system devel: pmnt initialized by Sentman and Maroney

[Ref. 1] and refined by Olivier and Olsen (Raf. 2]. It isour intention to show that by using this methodology,

complexity will be reduced and the following improvemqnts -o

embedded weapons system procurement will be realized:

1. better specifications generated,

2. better evaluation of contractor's proposals,

3. increased efficiency within the project manager's

office,

4. better pass dcwn infcrmation available to the project

manager's relief, and

5. develcpment ccsts lowered.

C. SCOPE OF THE HETECDOLOGY

The methcdology discussed in this thesis is intended to

apply to the development of all embedded ccmputer systems

for tactical weaponry. The possibility for a broader scope

exists since the underlying principles are widely

lt

applicable. However, further generalizing of the method-ology is nct appropriate at this time since the case s-udy

only addressed a tactical weapons embedded computer sys-em.Figure 1. 1 shows the placement of the Software

Engineerirg_ M.ethodology within the initial waapons system-' procurement phase. Figure 1.2 details the general flcw of

con:rol within the Software Engin-ering Methodology. Thisfigure also shows that while the Contrac-or Support Services

(CSS) Contractor develops the specifications and other prod-

ucts, the Program Manager lends guidance to and approves the

final products of this process. The guidance supplied is of

a managerial and not a technical nature. Sinc _ our handlinq

of the methcdology is concerned with the technical issues ofhow the prccedureqs should be performed, the thrust of curdiscussion will be aimed at the CSS System Developmen- block

of Figure 1.2.

D. HETHCDOLOY OVERVIEW

It was cur determination that the system design method-

clogy, while generally only an abstraction from the case

s-udy, must possess several broad traits in order to meet

the objectives stated in the Purpose, Section B. Wherethese traits were not innate in the abstracted procedures,

the methcdology was refin.d to encompass them. rhese traitsare introduced below. The Conclusions portion of this

thesis, Chapter 5, discusses why each of these traits is

necessary and how they permeate the methodology.

1. Simplicity. Simplicity of the methodology and in the

understanding of its goals and products is necessary.

Unless a system is simple, it has grea- potential to

become part of the complexity problem -ather than

part of its solution.

12

' '," -' : Z.... ....,.-... ..:..--.-.....:-..:. -.......-.- .. ---... ,-----.. ...-....---... ..,.

C7,

N. CC INUT

DAT I

-- IAA

S 0I G

'p.S

M E ITHI0IA0L 0EGT

SPECSIO

I~ IN DAA

I DECISEON

-- - - - - -- - --FINAL- - - - - - - -- - -

REQUEST- I FOR FOR

I PROPOSALS

Figure . Prograu danagement Hi1gh Level Flow Chart.

F 13

[i IT I4

FUNCSPECSI E

-. IPROGRAM GUIDANCE CSSMAAE j bTEI REIE DEEOMT

I IPOUTD DESIG

SPDCSNS

IFigure 1.2 Detail cf tha Softwa~a Engineering 3sthodology.

.1'* 14

7 i V

2. Generator of Good System Spec- -cations. The me hcd-

olcgy must prcduce firzm, finsly-tunei, an~d in.-hcus=

system specification3s. Noze that the term In-house

refers to the projact being directly supervisad by

the Program Manager regardless of where thF actual

work is performed. To be most effective, h-lw~ver,the actual work should be done in thc- same general

iccation as the Program Manager 0i . the same

office, office building, :r group of buildings) .

This assumes that it -Is nazcessary to have physicalcloseness of the Program Manager and t hq prcjcectdesigner in crder to achieave their con~tinual and

effective communication.

*3. Generator of Good Do3cumentaticn Products. The wsth-

cdclogy muist prcduce products which sarve as a prcpe-r

passdovn to r91liefs of4 ther Program %lanager and his* staff memebers. If design lezisicrts and system spec-

ifi-cations are not* properly documented, cc~pcrA,

kncwledge will surealy be lost upon job turn-over.L4. Generator of Under:standabla Products. The method-

occy must produce products which require little

formal training to understand and use. hUsc it m ust

t e couched in terminology zeasily absorbed by the

average Program Manager.

To ensure that these brcad systam trait a.6ahevd

th a methodology must yield products which possess several

sioecific featurss, inter ilia understandability, reli-

ability, eff>' 'cy, and modifiabil',ity. Thess are the major

goals of '+-ware angirneerIng des--gn methods. To

achieve the- ic goals, the software must adhere to

many structur L -ac, ples. Ross, Goodenough, and Irvine

A (Ref. 3] provide the following list f. required principles:

15%J4

* .-. -

1. Mcdularity. The modularity principle defines how to

structure a software system appropriately.

2. Abstraction. The abstractioai principle helps iden-

tify essential properties common to superfic iaIly

different entities.

3. Localization. Tha localization principle highlights

methods for bringing related things into physical

prcximity.

4. Hiding. The hiding principle highlights mhe

Importance of making nonessential implementa-ion

information irnaccessible. It enforces constraint on

access to infcrmation.

5. Unifority. The uniformity p:inciple ensures consis-

tency.

6. Ccsoleteness. The completeness principle ensures

nothing is left out.

7. Confirmability. The confirmability principle ensures

that information needed to verify correctness has

been explicitly stated.

The methodology must meet the goals and objectives detailed

above and must possess the listed traits. It must also

adhere tc all of the principles of software engine=.ring

design strategies. Only by religious adherance to these

criteria can the complexity of designing a tactical weapons

system be significantly reduced.

There is one fundamental premise of this methodology

imperative to its success: the system software development

must hold top priority with hardwire issues being deferred

until the system specifications are comple-ed. In other

words, the software decisions must drive the hardware selec-

tion. This premise has been reiterated and substantiated by

numerous case studies performed in recent years among them

Barry Boebm's "software first machine" [Ref. 4]. In view of

the fact that the amcunt of computer d-velopment money spent

16

on software is several times the amount spent on ha-dware,this is a lcgical prioritization of project emphasis.

The basis for the above premise is that, in crer to

meet the gcals of reliability, modifiability, main-ain-

ability, and to a large degree portability In software, it

must be procedurally dev-loped independent ¢f and without

regard for the hardware on which it will exccut_. A major

source of frustration and inefficiency for programmers and

maintainers of current. tactical weapons system software isthat the hardware is ingrained in and ar. inflexible part of

the system. Consequently, all modifications to the software

must he couched in the limitations of the system har-dware,

limitations which often require that software mcdifications

disregard all principles of software engizeering. If the

reverse process, that of allowing the hardware to drive the

software, is used, these hardware deficiencies are quickly

realized. When this occurs, the potential for maint=.inir.g

the desired goals specified above is grea-ly reduced.

Holding off on the hardware specification until the

methodology is completed is not an unrealistic proposal.

This is especially true in light of the high frequency of

hardware change and upgrade which most weapons system

projects experience. The basic idea is simple: it is rela-

tively easy to find shelf hardware to implement a softwaresystem while the difficulty of achieving the design goals

listed akcve on a specified piece o' hardware is at best

unpredictable.

A standard argument against having the software drive

the hardware is that there are many hardware systems

purchased (one per platform) but only one software system.

This basically implies that cost savings are more a function

of hardware than software. This argument could be valil if

no modifications to the software9, which des-roy its struc-

ture, were required. But the probability of achieving this

17

% %*

cver the system's life cycle? is Incredibly small. if ths

structure is lestroyed, the future sys-tem ccsts, evmn in

iisccuntad cr constant dcllars, would invariably be manytJmes the initial cost savings in hardware.

Prior t, initiating the procedures cf the methodology,

the Procram manager along with his staff must brecome

familiar with the current project locuments and the? specific

*pur--osaz and mission of the weapons system. The first step

s o eme intimate ly famili ar wi-h te taS-ciiations detaled in the Life Cycle Management

Milestone Zero documentation, the Justification f or Ma jorSvst.Pu New Start (JRSYS) .These broad system requirements

*are develooed based on a projacted mission need by

De~artment of the Navy planners. In-house refinement of

-t.hese Brcad Specifications due to zhanging negds, t echni cal

advancements, and inputs from the fleer (the user group)

Produces a set of Initial Functional Specifi&cations. Next

*the Initial Funct-ional Specifications are used as the input

*to -the methcdology tc design the proposed system utilizing-the ri nci1 les of scftware engineering. Agqaina Fi-gura 1.1

* provides a 7rachi-c repressntaticn o)f this flow.

Three disloint items are pertinent to the overall view

of the methcdology in this stage of the sysrtm devslopmant.

First, the system design is most likely being parformed by aCont~act:cr Sunport Service (CSS) firm. This is because the

*Proaram Mara'amr nor his staff have the time and in many

*cases the atility to Ferform these tasks. Second, this CSSfirm- isefcieypato the Program office. Itshould

* not be -hcucht of as a separae entity but rather as a tech-

%~ rical rep'resentative augmenting the Program Manager'Is staff.

This closeness ensures that the Program Manager's desireds stem will be generated. Third, the products produced by

V. the systam are generated and updated i4teratively (see Figure

1.2). This continual refinement of the products ensures

j~. 18

qcod documentation of the perceived systsm. Th-se items of

note must be fully comprehended by the Program Manager in

crder to most effectively utilize the methodology.

There are four output products gana-ated and refined by

usina this methodlogy: a detailed set of system specifica-

tions (t.e final Refined Specifications) , complets Data Flow

Diaarams and Hierarchy Charts, the designed system in ADA

Sostem Desian Language (SDL) with Module Descriptions, and

D-4sian Decision Documentation (see Appendices A-E which show

* these troducts for the HSCLCS design). Ccliectively they

provide all the documentation requi-ed to perpetuate ths

cor-orat- memory of th- project and to give a complete

Picture cf the proposed system. Individually they provide

the following functicns:1. System Specifications. These are the detailed speci-

fications delivered to project bidders responding to

the request fcr proposals. T he higher the leve=l ofrefinement of the specifications when en~ering this

nhase of weapcrs system development, the better the

chances are that bidders will develop sound system

=rcpcsals to meet the real need.

2. Data Flow Diagrams (DFD) and Hierarchy Charts. These-rcducts provide a graphic display of thm system byillustrating the system functional operation. Using

onl7 the functions to be performed and the input and

outout data needed to perform these functions, DFD's

and Functional Hierarchies are simple to generate and

Use.

3. Design in ADA SDL Uith Module Descriptions. The

design provides a procedural-level illustration of

the system. It documents how the required functions

shcwn in the DFD's are transposed into a hierarchy of

zroc.dures, fuctions, and tasks for data manipulationin order to perform these functions.

I."

19

do

% "' "- '"- "" " -

4. Design Decision Documentation. While most design

decisions appear in cther documents (i.a. the speci-

fications, design, etc.), some a-e no . feasiblyincludable in cther pro-ducts. The Dpsign Decision

Documentation provides a place -.o store pe.rtinznt

facts and parameters of the system.

Thus far in this sacticn we have dealt with tha neces-

sary goals, principles, and requiraments of the Software

IEngineering Methodolcgy box of Figure 1.1 and not ths

mechanics of the system. This is because the high-l.vel

.- view cf the methcdology must be one of achievement of design

objectives and not in the procedures necessary to produce

" documents. Whether or net these objectives are met will be

the subject of Chapter 5, Conclusions. However, to provide

a proper overview of the methodology details Figure 1.3 is

included as an illustration of the iterativs product formu-

lation phase. The de.ailed discussion of this flow and its

subgoals is the sole subject of Chapter 4.

20

, -n nun--N,,& i ll &,l, %. l,, d- ' ,,a '', , '.. . . . . . ., . . , . - . . . .o . . , , . . .

INTER-I MEDIATE

* I PRODUCTS I

I PROGRAM* f GUIDANCE

I ~cSSII SYSTEM.I DEVELOPMENTI

r-DIAGRAMSI

DESIONS ANALYSIS FUNCTIONS

ESG INC*I

C IDEISON

'M

fD E NS ODUAR MDUL

IRI IOSSGH AD DEG _ _ _ ENS ___D

Pigure 1. 3 Detail of the CSS System Development.

21

-J

'.4

V V

11. BACKGROUND OF THE HARPOON CONTROL SET DESIGN

Recently when the missil subsystem cf" the HARPCON

Weapon System was upgraded to include two new block enhaace-

ments, the existing HARPOON Shipboard Command-Launch Cor-!ol

Set (HSCLCS) was rendered i.nalequate to support the d.--sign

features of the new blocks of_ missilzes. Upon axaminat_ n by

anal ysts, i;t was decided that the ixisting HSCLCS softwarewas not modifiable and a new design effort was necessary.

The new design would need to not only cover the recet

missile changes but also be fexibla enough to be modified to

support anticipated technical achilevaemts i n t he nesar

future. This chapter will introduce the basic facets of t:

HARPOON Weapon System and provids background on -:h~ work

*done in two previous theses, [Ref. 1] and (Ref. 2], tward

* redesign of the HSCLCS.

* *A. EXISTING HARPOON WEAPON SYSTEIM

The HARPOON Weapon System (HWS) has been deavelopel to

fulfill the requirements of the Navy's ant---ship mission.

AThe HNS is currently deployed on surface shlips, submarines

and aircraft. The HWS provides over the horizon an-ti-ship

capability in all weather, day c= night. rhe HWS is

comprised of the missile, launcher, and command-launch

subsystems. The sbip-la unched HIARPOON employs either

onboard or third par-ty sensor dat-a for targeting InfA'orma -

tion. The missile is a "J'a unch and forget" w-a p:n, since no

ship control or information is needed after launch.

For surface ships, the HWS control and data processingfunctions are provided by the HSCLCS which Ahas threes modesof operation: normal, casualty and training. In the ncrmal

mode he mjor unctcns of the HSCLCS are:

22

1. Distribution of power to various HWS equipment.

2. Selection and application of missile warmup pow-r.

3. The ability tc conduct various automatic and manuiall,

initiated tests which confirm the operability of the

s y Stem.4. Distribution cf ship motion data from ship equipm=nt.

5. Selection, transfer, processing and display of target

data.

6. Coordination c4. the selection of the -t:actical missile

mode and type of fusing.7. Selection of the launcher cell containing th3

.ntended missile to be launched.

8. Initialization of the selected missile and the super-

vision of the exchange of data between missile aad

other HWS equipment.

9. Control of all missile firing activities.

These functions arp implemented and integrated by ths

HARPOCN Weapon Control Indicator Panel (HWCIP) and the

HARPOON Weapon Ccntrcl Console (HWCC)

The HWCC contains most of the HARPOON system-unique

command and launch subsystem equipment, including the Data

Processor Computer (DPC), the Data Conversion Unit (DPU) and

the HWCC life support equipment. Together these components

perform data processing and conversion among various data

types and provide interfacing with existing sensor and

ship's equipment.

The WCIP provides visual status information to -he oper-

ator during formulation of the fire control problem, andadditionally provides manual controls for the opera-.or. The

existing WCIP is shown in appendix E.

The DPC is a 16-bit microcomputer with 15K of E-RCM.

The DPC uses an assembly language pzogram -o provide the

following:

23

6...

1. Launch envelope parameter validation.

2. Missile command aeneration for implementation ofmissile ccntrcl parameters inzluding ship's a.t-i-ude,

search pa-.tern orders, engine starting, flight :.rmi-

nation range, altimeter setting, and various s !ec-table flight trajectcry and maneuvering modes.

3. Pre-launch testing.4. Pre-launch sequencing and timing.

5. Data formatting and transfer synchronization.

The DCU processes all digital and analog signal conver-

sions as required by installed hardware. The DCU also

provides interfacing of targe- data inputs from the Naval

Tactical Data System (NTDS) Slow Int-rface. Ship motion

parameter data is also converted in the DCU.

E. PROBlERS ASSOCIATED WITH EXISTING HSCLCS

Since the existing software of the present HSCLCS is

written in assembly code and is heavily hardware dependent,

the maintenance cost in the face of periodic missile chancesis relatively high. Also several different hardware config-

urations exist for tie different firing platforms.

The HSCICS also has numarous deficiences in engagementplanning as the operator cannot fully control the featuresof the new block missiles. In fact, the operator has no

automated assistance in engagemet planning in the currentsystem, and there is no display of tda tactical situation a

the WCIP. The current firing solution does no- have environ-

mental factors included unless the operator considers them

manually. On some platforms NTDS was intended to provide the

services mentioned in most of these deficiencies but the

location of the WCIF has inhibitad this effort and indeed

many HARPOON platforms do not have NTDS!

24

Lf.

C. HRPOON WEAPON SYSTEM CONSTRAINTS

The constraints in this section are fo= the most oart

technically orianted. Ianagerial constraints ars to ba

determined by competent authority at a 1a-ar date. The" upgrade cf -he HSCLCS must be abla to support th= new block

" missiles as well as -he old ones sinc= the oil missiles willbe_ in the fleet for some time.

The implementaticn of the upgrade mus-t continus to

provide all previoius fuctions as well as :-erfacinJg withNTDS. The existing launcher hardware will r-main the same

and the physical size of the HSCLCS must be the same.

While the DPU hardware configuration cannot change., theEPC software is subject to change as necessary to implement

the upgraded HSCLCS. Although -he current software is in

assembly language, this is not a requirement for theupgrade. System reliability of the upgrade must me-: or

exceed existing standards for the HSCLCS.

D. SYSTEM DEFINITION FOR HSCLCS UPGRADE

A detailed discussion of the system definition for -he

upgrade can be found in [Ref. 1]. It is summarized below.

The hardware of the system will change significantly.

The existing DPC will be replaced with a commercially avail-able CPU with additonal memory. The WCIP will be modified to

include a display which shows the current tactical situaon

and programmable software keys to zontrol both the display

and engagement planning features which w"ll be incorporated

into the DPC sof-ware. A hook and cursor similar to thosei

in NTDS will also be provided at the WCIP for the opera-cr

A display p.ocessor will be attached to the WCIP. The DCUhardware will remain the same however the software must be

changed to accommodate new inputs f-om NTDS and environ-

mental data.

25

.................. %. . .. . . . . . . . . . . . . . .

7. - - .- -W.W--. ' -. . W. C Pk .1% -. S

The software upgrade of the DPC wdhich i-s the major part

of the HSCLCS focused upon by this thesi-s is to slimirnats

the existing deficiencies mentioned in the section B of this

chapter. Specifically, a scftrware plan muse be developed

which prcduces adequate software t ha t provi-des r equi_4rad

capabilitities and is flexible enough in design to be modi-fied in the future with minimum amount of blood and tsars.

1. STATE OF THE UPGRADE

The software upgrads of the HSCLCS has been the subject

*of the two previously ref=.renced thesas. The initial thrus-:

cf the first thesis by naroney and Santman was to develop a

software plan, Figure 2. 1, and complete the -fir--st threephases. E mpha sis was placed on good software engineering

techniques. A systems raguiraments analysis was conduc-.edwhich prcduced revised system speafcain and laid --he

*foundation for the prel- in ary design. Data flow diagrams

aAnd subsequent tr--ansfcrm analysis techniques described in

[Ref. 5] were used. ADA was chosen. as the system design

language in anticipation of isproclamation as the standard

DOD SDL and because it lends itself so well to the modu-larity concepts necessary for modular design.

The second t-hes is by Olsen and Olivier continued thesof tware development by deriving a preliminary design fromthe products of 'laroney and Sentman. To continue the plan,

a f-inal desiga must be completed along with detailed docu-

mentation. ThiLs final design process is descrie i h

methcdolccy chapter.

26

c 0.

I0 z

I~ 40

I1 z

I 0 'A

CT

II

Figure 2.1 Softvare Plan Afzom Rafe=sn ce 1 .

27

-t ~~~~~~~~~~~~~~ ~ ~~~~~~ -' ' .-_ . -. ._ ..... -5,-, _ -,...% ' ' ' J -- ,-.> - - . . . .- .- ' . . . . . . . .!

J.J

III. SOPTWARE ENGINEERING SNAPSHOT

The need for good software engineering techniques has

become increasingly evident in th . pas, decade with the

exponential qrowth cf software development and maintenance

costs. Since necessity is the mother of invention, the

number of new software -ngineering methods and techniques

* has also grcwn exponentially. The major contributors to the

methodolcqy of this thesis, Pr-ssman, De Marco, and Booch,

all have derived systems for software design using thsir cwn

particular styles. In -this chapter we will briefly discuss

those st:les and alsc comment on some other software designmethodologies.

Structured design was first publicized by Yourdon and

Contantine [Ref. 6]. It was developed to be used as the

transition tool between Structured Analysis and actualimolementation. Composed of various concepts, measures,

rules of thumb, and analysis techniques, this method with

early development by re Marco is the basis for the Pressman

design methcdology.

In [Ref. 7], De Marco describes the life cycle of a

software project from requirements analysis to specifica-

tions. After an initial survey of systems rquirements, a

data flow analysis is conducted using data flow diagrams.

The next steD involves creating a data dictionary from the

data identifisd in the data flow analysis. At this point in

re Marco's me+thodology, the data flow diagrams are trans-

lated into a set of specifications using a subset of English

called Structured English. Structured English is as-ecificaticn language that makes use of a limited vocabu-

larv and a limited syntax. The vocabulary consists ofimperative verbs, terms defined in the Data Dictionary, and

28

2-.......................-'-,.. . -- . .- - ........... ..- '.-.... .. -... .. .. - .... ,.... ... .-.. ... . . , . . ... .- , .,-

certain reserved words for logic formation. The mappinr of

the data flcw analysis to the Structured English specif ca-

tions is fairly algorithmic but uses several heuris-ics -hat

will not be discussed here. De Marco also explains thedesired traits of a design based on the specificaticns

generated, but does not include a procedure for realizat or"

of the design.

Pressman, (Ref. 5], elaborates on all phases of the

softwars life cycle and gives several different approaches

to design such as data flow oriented design and data struc-

ture oriented design. In bcth of these areas he carries thesoftware development process through the praliminary design

phase but does not address specification generation. Thedata flow analysis cf Pressman resembles that of D? Marco

but his transform/transaction analysis which leads to module

hierarchy charts contibutes significantly to designrealizaticn.

The okject orienteff design methodology of Booch (Ref. 8]

concerns the development of design after some sort of data

analysis has been ccnducted. Booch does not indica-e apreference as tc whether data flow diagrams or any other

kind of analysis identifies the objects in a project as longas the method is complete. After objects are identified and

given attributes, this methodology develcps a system designby stepwise refinement of a simple prose description of the

system. This prose evs.itually is transformed into ADA

system design language. No guidance for conversion of theADA SDL to structured system specifications is given in zhismethodology.

There are several system analysi-s and design tccls -hat

have keen itplemented but have not gained wide-spread use.SADT (a trademark of SOFTECH, Inc) is a system analysis anddesign technique developed within the Ycurdon organizationthat is used as a tcol for system definition, software

29

2- '., .''.'. .%'-,-. "%" °"" ' , ,' ' "' ' -" J ,'.'-',"- - •"... ". - .. . . ,. .. .. . . .

L e.

requirements analysis, and system deasign. The ui-h'dolcqy

*encompasses technical tools and a well-defined crgariiza-

tional harzess through which the tools are applied. An

-automatzed requirements analysis tool i1.s SEEM (Ref. 5],*~~- her elmns trbu tes , relationships, and structures

*(all parts of the Requirements Statement Language (ESL)) are

combined tc form the details of the raqui-remsnts speciJfica-

*tion. SEEM was initially designed for embedded computersystems and requires a software support package called REVS

*which uses computer graph ics and repors oninrmto

flow. S 4:ill ancther automated tOolI i6 CADSAT(Computer-Aided Design and Specifi-cation. Anal ysi-s Tocol)which with FSL/PSA prcvi-des an analyst with several capabil-

* ities. Th~ese include:

1. description of -Ln f orma ti.on systams, regardless of

applicaticn area,

2. creation of a data base containing descriptors for

tbs informaticr system,3. addition, dele+-ion, and modifi-cation of descriptors,

and

4. production of formatted d:ocumented an'1 varicus

:epcrts on the specificaticn.

CADSAT dces not present a panacea but itdoes provide

*benefits that include documentation q uali6t y, easy cross

reference of documents, easy modification, and reduced main-

tenance ccsts. The major disadvantage of most of these

automated systems is that they require a considerable amount

c f trainirg in order to be used effectively. However, theconcept of automated design is here to stay becauZ e the

benefits far outweigh the disadvant.ages.The methods described above are only a f ew of the many

*ways -that software development is being conducted today.

The design tools such as decision tab.es, flow charts,

HIPO-charts, st~uctured flow charts, an d pr-ogram li.stinrgs

30

-.L . - .' - m _ _ - - p r.p.

abound. It is outside the scope of this th.sis tc discuss

In detail all of ths methodologies, but each one is based on

the design principles outlined in this -hesis. : -each

methodology produces results with tha desired cha-ac-e-s-

tics, only through extensive experience can one juigs the

relative efficiency cf the methodologies. Since scftWari

engineering is still at the fledgling s-:age, we can only

hope that these methodologies will mitigate the software

crisis.

31

- - - .. *- ' * - -~ -• . - .

IV. DESIGN 3ITIODOLOGI

The methodology for refining embedded comput.r weapcns

systems specif icaticrs, which is the subject of -hischapter, is required to possess an algorithmic form and

logical design a- all levels. By levels we mean the lev-ls

of abstraction from which the methodology can be viewed.

Pr example, an outsider to the projct office would view

the methodology as a "black box,, which inputs broad specifi-

cations and fleet criteria and outputs final dsign specifi-

cations and refined desigr products (see Figure 1.1). The

Program Manager would be heavily involved in the it:a-ive

refinement of the system specifications ard products and

consequently would see the methodology as a generation and

refinement tool. His "black box" would be the Ccntractor

Support Services (CSS) System Development block of Figures

1.2. Finally, the CSS Contractor would view the methodology

as an algorithm for Froduction. This algorithmic flow is

shown in Figure 1.3. These ars proper abstractions for the

methodology; they optimally map the responsibilities of each

of the individuals into their required level of concern for

detail.

This chapter is concerned with .r.roducing a mej-hodology

at the CSS Contractor level which embraces all of the goals

and principles and proper trade-offs of Software Engineering

design. This level can be viewed as the bottom of the

abstrac-:ion hierarchy because it is .he lowest level at

which tie entire design is still within view. It is our

belief that if this level of the design methodology is

well-structured and simple then the entire hierarchy will be

so. This hypothesis wll be further developed in Chapter 5.

32

N'

The methodology, at the level specified above, W P_

conceived and tuned using the f ollIow ing pair of g-a-;Jn a

rules: itmust have a simple, saquential form and It must-

support a lata transform driven des ign. By data -rernsform

driven design we mean that the products of des gn m ust

*project hew a datum is interrelated to ot.her data and how

data is transformed as processes act upon it. The re:asons

for these basic requirements are the subject o f the two

subsequent paragraphs. The achiavement of the fir-st

requirement is best revealed by an illustraticn; Figure 4. 1serves this purpose. Notice on this diagram that ths flow

*is cha~acterized by singular inputs and outputs with a

*proc-essing block between them. T~his by defi-ni:ior iS the

*simplest fo:rm of seguential flow, thus -he fizs t r - I _ issati sf isd. Figure 4. 1 a d di-ti'on all1Y shc ws t-hat tn's first

s sep of tte methcdolcqy or what w= will henceforth ref=r to

*as the first methcdology functlo. is t:o manipulat s the spec-*ifications into Data Flow Diagrams. This function, adata

flow analysis, str ict ly follows De Marco'S procedure[Ref. 7], a procedure which fully Incorporates the cri-Sriafor data transfcrm driven design listed in the defirition

above. it follows that the second rule: is additinal

sati-sfied.

There are several strong reasons 'for requiring a method-

clogy with simple, sequential flow. For example, the usage

*of such a methodology is straight-fcwar-d and easily

grasped. Further, this type of flow tends to be highly

- ~ logic rather than heuristic oriented. But the chief reason

*we wanted simple, sequential flow was to have a szructurte

-)which readily supported our methodology model. This molel

v iews the system as a series of functional mappings, e.g.

aata flow analysis is a function mapping specifctin int

hi-erazchy of Data Flow Diagrams (see Figure 4.1). Thce use

c f the wcrd functicn is not intended to impl y tha-, the?

.. .. .. .. .. .. .. . . ~ .* . .. .. .. .. . .. .. .. .. .. .. .

SPECS

DATA FLOW

-- ANALYSIS

DATA FLOW

I S C

I DIGRM

TQANSFORM/I

' RANSACT

LY IS

ANALYSIS

HIERARCHY OF.

FUNCTIONS

D- EVELOP-MENT

MODULE

DESCRIPTIONS- TRANSI

L- TION TO/ADA DESIGiDESIGN IN

ADA SOLSPECS

- REFINE-DESIGN ENT

DECISIONS REFINED SPECS

4 1I Aet.Adology Sequenta]l Flow.

34

l~ , .'. ", . ,. ' ".''_ ,,-" , -;. . .--- - .' i '._- ,,, . ,-. -.- ' .,, - -, '-- _' ,.,:.' --I. I" _ . .: .-. : ..

'r V7....

products, i.e. the Data Flow Diagrams, produced by the -e-h-

odology are themselves unique; the mapping is no-

one-to-one. However, we suggest that each of our methcd-

ology functions map their input product into a small set of

cutput products which is a realistic partition of all

possitle output products. By realistic partition we mean an

equivalence subset of the output products which contains

only those products having all of the desired structurs

principles but which omits those grossly inefficient repre-sentaticns of the solution. The ben-fit cf this terminclogy

is it eables the reader to view the methcdology frcm a

familar technical vantage. Using the tsrminology we _ntro-

duce our hypothesis that these functions retain the proper-

ties of the input Froducts by transmitting them to the

output products. In other words the methodology functions

are designed to ensure that the good initial structur Js

carried forward throughout the methodology.

The main reason for requiring th- m-thodology to use

data driven design was based on :he fact that real-time

systems (all applications of our methodology will be real-

time systems) are easiest to dasign this way. Shcoman[Ref. 9] supports this hypothesis. We decided on data flowdesign because the graphical nature of the data flcw model

supports DeMarco's [ef. 7] belief that all products of

analysis functions should be graphic.

The procedures of the methodology represent the compila-

tion of related work performed by several distinguished

pioneers in the field of software engineering. But the

overwhelming majority of contributions came from three indi-

viduals: De Marco; Pressman; and Booth. While each cf these

men see the problem in the same basic light, they have chan-

neled their research efforts into different facets of the

problem. The De Marco contribution consists of a method for

transfcrzing system specifications into a set of structured

35

- %

products, Data Flow Diagrams, which represent a graphic

solution to the specification requirements. Pressman

details a procedure, transform/transaction analysis, forcreating an abstracted hierarchy of contex--indep r. d a.nt

modules, a Function Hisrarchy, from Data Flow Diagrams.

Booch, claiming to have achieved object oriented design

[Ref. 8], contributes a method for developing a final design

given a Function Hierarchy. It will be shown later that theBooch procedure is in fact an objsct oriented lesign tech-

nique. Figure 4.2 illustrates the specific areas of method-

ology coverage by each of the authors. Fortunately for cur

purposes, these areas of specialization correspond to c-e or

more of the specific functions iz our methodology such that

all of them (except Specifications Refinement which is our

contribution) have been significantly researched. Thus only

the structural interfaces between the various contributors

need to be specified before reducing the methodology tc a

series cf independent functional units (see section B).

The effort required to structurally in-erface between

the contributors is minimal. On the surface this may appear

puzzling in light of the complexity normally encountered

when synthesizing a complete product from disjoint pieces.

But because each of the contributors used the same generally

accepted product formats at the interface points, t.h.s

problems were not present. No interface is required between

the De Marco and Pressman pcrticns of the methodology. This

is because Pressma3 uses all of the rules of De Marco to

produce Data Flow Diagrams, the input to his transform/

transaction analysis. Consequently, we can viaw this situ-

ation as if De Marco and Pressman "collaborated" on ths

interface. Nor is ar interface between Pressman an! Booch

required. The portion of Booch's method we use requires

only a function hierarchy as input. Since :his is the

output product of Pressman, no structural interface s:eci-

fied ty the methodology is needed.

36

I ]1.()ml M W - % ' , " ;*%** ' " '** * * . ... .-.*. ... . " .- , ? : ,: ' ' '

- %7 1%

SPECS

,, I DATA FLOW.r- ANALYSIS

DATA FLOW DeMARCO

DIAGRAMS/TRANSFORM/1

I' TRANSACTI |ANALYSIS

HIERARCHY OF. PRESSMANFUNCTIONS

, MODULARr-- DEVELOP-

MENT

I MODULEI DESCRIPTIONSI I* | TRANSI-

TION TO BO0CHADA DESIGN

DESIGN INADA SDL

* SPECSREFINE -

*DESIGN MENTDECISIONS

REFINED SPECS

4I

Figure 4.2 Ccntributors to the Methodology.

37

*. - * . . * . -'.* . . . . .-Q- -. *~. . . . .

A. NETHCDOLOGY CRITERIA

1. Goals and Pricivles

The goals for the software produced by the method-

* ology (understandability, reliability, efficiency, and mod-

fiabilit.y) are generally accapted by software eng-Jiners as

those of primary i*m porta nce. In ganeral, this list sencom-

*passes all of the relevant attri;.butes necessary tc ansurr!that software will realiz e it minmmlieccl ot

These goals are defined as fcllows:

1. Under stan da bi4lity . Understandability is that pcten-

tial for software to projac- a clear and lcgica.-

meaning. it is achievable in all systems readless

of the complexity if both ttia structure and the level

of abstraction area appror-riate for t he proposed

appl ication. It must be stressed tha- both o,: -hesq

properties are needed. Having merely a formatted

structure yields a legible but complzx product. I

order to realize any of the other goals, understand-

ability is paramount.

2. Reliability. Reliability is the abilityothsf-

ware to functicn, under all conditonasth pei

fications intended. It can be thought of as freedom

frcm anomolies as well as the3 absense of blatantmistakes. Beliability also encompasses Srror

recoveryr the abi-;lity of the program to continue3

proces3ing in the event c-r non-catastrophic system12~aillure. Achievement 0o total :esliability is

extremely dif fic ul1t o~ p:: ve ever. in -a s ysteam

strictly adhering to srf w&7=- eng ,eeriaq pri cipes

It is impossible to prove sof-tware re:biyunder

lesser conditicns.

3. Efficiancy. Effic=.ency, as a stri-u4d-vn3 coal,..s wrong. Howe vsr, bia:~. m-rcec akcs a

38

i2 I

L .'. o

- .- . - ."...* , - . -- r-r r

System impractical. The efficien:cy balanci must be

" achieved by first adhering o all other goals and

then screeninq for gross inefficiencies which can bs

. corrected by encapsulating and modifying inefficient

- modules. This is suppor--ed oy Belady and Lehman

(Ref. 10] who state that glob 1 oot;mizat on is not a

practical objective, but that by locally op-imizing,

global sub-optimization can be ach:eved. Thus effi-ciiency shculd be deferred u.z:l a Solid svystm s-ruc-

"ture is established.

4. Modifiability. Mdifiabilitv is a broad term whichencompasses the ability to esasily change sof-ware for

enhancements or errors, for performance -uning, andfor subsetting. The achievement of modifiability is

difficult because the effects of change are very hardtc predict. Thus modifiability, more t:han any othergoal, universally re-uires the s - rict adherence to

all of the software engineering principles.

To meet -hese design goals, the principles addressed

in Chapter 1 (modularity, abstraction, hiding, localiza-ion,

uniformity, completeness, and confirmability) are theprimary attributes req'.ired of the methodology products. Itseems apparent from cur readings that among the seven prin-

ciples, modularity and abstraction are uniformly accepted as

*he dcminant -equirements of all software. rhis is notsurprising considering that these software qualities, which

,logically reduce larce problems into manageable subproblems,

are the most effective reducers of complexity. These twoprinciples are highly coupled; one abstracts to reduce

P ipzcCmplexity by modularizing and modularizes by performing aseries of logical abstractions. Thus they should be thought

of as iteratie subprocesses of some higher level genericdesign process. A more let aied descr iption cf the

39

°I

requirements and specifications to benchmark the achievement

cf modularity and abstracticr, are given below:

1. Modularity. As stated above, i- is nearly impossible

to address modularity as a s:and-_icne pr:ncto!-. In

its simplest form, however, modularity can be consid-

ered achieved when the scluticn t-o -.he problsm is

reduced to a hierarchy of sepaately addressablemodules. in order for t1-is hierarchy to kpprcach the

optimal solution, though, it must have a good balance

between two inversely proportional measures: the

degree of module complexity and the degree of inter-

fice complexity.

2. Abstraction. Abstraction, too, is not an independent

concept. It can be considered achieved when the

problem has been iteratively expanded (or stepwise

refined) such that each of the abstraction levels hasa sclution representation which captures the essense

of the system at this level, but specifies nc unnec-

essary complicating details. These levels ofabstraction provide an intellectually graspable view

of the probler's solution.

Of the remaining principles required of the method-

ology the most important ones are completeness, indepen-

dence, and hiding. While the presentation of these

principles may tend to imply that they are of second echelonorder, this is not true. Rather they complete the system of

interwcven requirements of the methodology. The resason

these principlsE are presented separately is because unlike

modularity and abstraction these :cncep:s are not univer-

sally accepted in name or in their definition by the

contributors. Yet each of them is either directly stated o:

indirectly supported as method requirements. For example,Pressman stresses module independance , a concept which

40

- . . ---.. -

[ .,, , . + - . ° -.S . . . . - . . • ••. • . J +. • . . • • . + . • + . . . - . ° . - -. .

7- Y. S..-. -

" equires modularity, abstraction, and completeness as p-=s-

quisite principles. Thus Pressman must indirectly supportthese structural ccncepts. Further, he requir=es the

simplicity of module interface in his independence concept.

* This is actually a loose form of the hiding principle. The

' key pcint, however, is that his method builds a s-::ucte-

which allows hiding to be efficiently appended to the set ofprinciples across the interface with t-he Booch method. From

a broad scope this implies that the method embraces a more

stringent set of principles at each method interface ulti-mately yielding a design which adher-s to all of the n=ces-

sary structure principles. This idea is developed in the

next subsection. The specifications for achievement ofthese three additional concepts are given below:

1. Ccmpleteness. Completeness, a principle stressed byDe Marco, is a critical property of the products of

cur methcdology. Its cziticality is especiallyapparent when performing the firs- finc-i c n, data

flcw analysis. Tt is ,andatory tc ensure that each

system specification is appropriately captured inr at -

least one Data Flow Diagram. If the first prcc edurof the methodology produces a complete set of Data

Flcw Diagrams then all subsequent steps will have agood, graphical representation of the requirements bywhich to benchmark. Thus achievement of comolet-ness

requires the assurance that each methodology function

carries forward all of the information from -he input

product into the output product.

2. Indepen dence. Independencs, the chief princiol;stressed by Pressman, becomes an important concep-

when developing the Function Hierarchy. The degreeof module independence car best be qualitatively

measured by first measuring the levels of cohrision

and coupling of the modules. Cohesion Is the measure

41

%,,~~~~~.. .. o . -. :......,,........---........ ..... ,.... .. ........... ........

r4C.--~r~ r*..iw ....rr1-. ..... .. . r. r!

of module single-minde-dness [Ref. 5]. The highes-

cohesion, which is the goal state for maximznc

independence, is achieved when every module has a

single functicn. Coupling is the measure of moiuleinterconnecticn ar. interdependence (Ref. 5]. rhe

lowest coupling is realized when the ints-r-_caces

between modules are simplest. Low coupling iL also

reguired to achieve modular ind9pendenc. Thus inde-pend4nce is achieved when the design products have

mcdules which address a specific subfunction of

requirements and has a simple interface when vi-wed

frcm other modules.3. Hiding. Hiding, a principle developed by Parnas and

hichly stressed in the Booch method, implies the

prereguisite achievemant cf completenass, modularity,

abstraction, and independence. An expansion of the

reguir-ments of independence that distinguisheshiding as a more powerful concept is that these

single function modules must have a simple interface,

the interface must be the only part of the modulevisible to other modules, and how the function isaccomplished within the module must be hidden

(Ref. 11]. This invisibility of module internalinformation takes us one step beyond what these otherfour principles provide: design decision encapsula-

tion. Therefore, achievement of hiding reguires a

conscious effort by designers to delay designdecisions until the latest possible rime and when

decisions are made they must be encapsulated andconcealed in the structure of the design.

Tim Rentsch has boldly defined the requirements of

the nebulous procedure termed object oriented design[Ref. 12]. He states that the essense of -his ccncept is an

42

- ,. ,. . • - -- - - - - . • . o . . • . - °. . , ' . .

F.* v .-. -

adherence to the principles of abstraction, informationhiding, decision encapsulation, and modularity. Using his

definition we can conclude two interesting facts. First.,the Booch method, as Booch himself claims, is object

oriented design. Second, our methodology, because of itsstrong adherence to the five major structure principles, is

also an example of object oriented design. As the software

"buzz wcrd" of the 1980's, object oriented design will

undoubtedly be a aust in DOD software by the 1990's.

S2. P-inciplS Set* Synthesis

Ncw that all of the design concepts required in thi

methodolcgy have been formally presentad, it is necessary tc

show how they are related to the methodclogy functions.

This includes determining the point at which each of these

principles becomes an active concept in the design. Thesynthesis idea cf this subsecticn refers to the fact that

all of tle individual principles are not uniformly visiblethroughout every function of the methodology. They have apoint at which they become necessary and are thereaftercarried forward in the principle set. This idea that

concepts once incorpcrated in the design are thereafteringrained in its structure is justified in Section C of this

chapter.Tc realize a principle at the optimum time in the

design, the structure must be capable of suppcrting the

inclusion of the new concept. A rather simple way of

viewing this requires one to visualize the principle to be

added as needing a set of prerequisite traits. For example,

the prerequisites for independence are completeness,abstraction and modularity. Thus, if the current structurs

of the design contains the prerequisite traits then the

structure will be capable of supporting the new principle.

L43

a.

".'- ° o '. 'o ° ° .o' . ° % . ° • . .- ° .• .

Eecause the sst of principles Dehaves in tha maner

stated akcve, the structure requirements become increasingly

more stringent as the design is refined. This Is the

desired effect ba-cause the ultimate objective of the method-

ology is to produce a design which encompasses all of the

software traits but maintains its flexibility as long as

possible.

. Tie initial principle sat for the methodology

contains the concepts of abst:acti3n and completeness. I

i easy to see abstraction as a necessity because mach of

the functions iteratively refines i-s products and the

. refinement process is ba sed on levels off abstraction.

- Completeness across all of tht interfaces requires no expla-

- nation; without all cf the parts, the design could not be

correct. At the first interface, the DeMarco/Pressman junc-

tion, the structure must be able to support the addition of

" modularity. The fact that modularity is required at this

point in the design is no surprise considering that the

purpose of the Pressman function is to modularize. The

second and subsequent iterations of the module heirarchy

continually refine the design structure to achieve lowmodule coupling and high module cohesion. When a satisfac-

tory trade-off between coupling and cohesion is made, inde-

pendence cf modules iS achieved thus appending independencs

to the set of principles. With the set of principles now

containina all the prerequisites, the P=essman/Booch ia-.er-

face structure is capable of supporting hiding. Figure 4.3

illustrates the synthesis of the principle set.

B. RETHODOLOGY COMPCNENTS

1. Data Flow Analysis

Data flow analysis is the first facet of the evalua-

tion and synt hesis phase of th a software r equirement!s

% 44 * - -. . *-. . .. .... . * ..

S. '

*,- II

SPECS

-I -

A C DATA FLOWANALYSIS

T P DE MARCOR LI

I A E .... -C T TRANSFORM/

MI TRANSACTO0N ANALYSIS

N S U E PRESSMAN

R N MODULAREI D H DEVELOP-

T E I MENTYN C IE N

I ITRANSI-TION TO

ADA DESIGNOI 8BOOCH

SPECSREFINE-MENT

IREFINED SPECSI.I

Figure 4.3 Illustration of the Principle Sat Synthesis.

45f i' ' - ' . . . , - . . - . i . i . ] - ' - . " - - - . - . . . - . -, ' . . ' . . - . . - . - . . . . ' . . , . - , , . - , , , , . . - . , - . ,

9°'

determination process. By examining the data flow we aet

the big picture on what the entira system receives as input

and produces as output and the path that data follows in the

system to be designed. Data flow is our analysis start

point because we do not want to get bogged down in specific

areas of a system trying to defins functions which may notbe clear in the initial analysis. Data flow, on the cther

hand, is usually much easier to identify than flow ofcontrol, which in most large scale projects is very complex.

The primary tool we will use to examine the data flow willbe the Data Flow Diagram (DFD). In this section we will

briefly describe how to build a DFD summarizing the methods

detailed in (Ref. 5] and [Ref. 7] and also what the DFD can

give to the Program Manager. We will also introduce a set

cf example DFD's from the HSCLCS system that will be used asa case study to illustrate the methodology components

throughout the chapter.

a. Data Flow Diagram Definition

The data flow diagram is a graphical aid for

depicting the data flow of the software system being

designed. A complete understanding ,f the DFD is imperative

to the understanding cf the design methodology described inthis paper. The most significant characteristics cf DFD's

are:

1. The diagrams are graphic.

2. They produce natural partitions in a system.

3. They are multidimensional.4. They emphasize the flow of Iata.

5. They de-emphasize the flow of control.

Data flow diagrams are made up of four basic

elements:

46

KN

, ,,r' . .-., "-- . . . .. . . . - ." - -. -- . - . - . - _ -. - . . ' "- -,

1. Data flows represented by an arrow or vector from the

scurce of the data tc the destination.

2. Prccesses represented by circles or "bubbles".

3. Stcred information (e.g data bases or files) repre-

sentad by two horizontal parallel lines with a nean-

ingful label.

4. Data sources and sinks represented by bcx=s.

Data flow can be broadly defined as information

flowing tetween two processes or between a process and a

source or a sink. There ar- several general rules

concerning data flow.

1. Data flow names are hyphenated and capitalized.

2. No two data flcws have the same name.

3. Choose names that describe the data explicitly but be

concise.

4. Data flow should not represent a flow cf control.5. Data flow is not considered a process activator.

Procisses invariably show some amount cf work

performed on data. Mcre explicitly, a process is a transfor-

mation of incoming data flow into outgoing data flow. Each

process bubble should be numbered and given a unique

descriptive name.Sources and sinks increase the readability of

the DFD by showing where the net inputs to the system come

from and where the net outputs go to. Sources and sinks

differ from files and data bases in that they are considered

to be cut of the context of the system. Thus, they show how

the internal system relates -o the outside world. igure

4.4 is the source/sink diagram for the Harpoon System

Command-Launch Ccntrcl System (HSCLCS).

47

mm . %%iHin a in-MP ' m u , ~, -, --.- a - - . . , " -. " ?.. ". .. ". ".

SOURCE TRANSFORMATION SINK

HARPOON LAUNCHER' WCIP AND

OPERATOR MISSILE

MANUALDATAINPUT

SHIPENVIRON LAUNCHER MISSILE ORDER

DATA

~SHIPPARAMETER AND

ENVIRONMENTAL DATA HSCLCS! NTDS

I OPERATOR DISPLAY5, I

HARPOONSLAUNCHERHAPOAND) WCIP

MISSILE OPERATOR

I LAUNCHERMISSILEFEEDBACK

1-I

II

Figure 4.L4 RSCLCS Source/Sink Diagram.[.4

[.4.

[ * - . -

[ - .

97 -. N %-,K "

h. DFD Construction

The first point to keep in mind during the data

flow analysis is not to try to learn everything at ons -. ime

about the whole system. Think top down by ccnceptualizing

the high level data flow first, defering the development of

the low level data flow. Especially avoid addressing any

implementaticn details at this time and be flexible enough

in your thought process to start over from scratch if road-

-b- locks are encountered. Remember the data flow analysis

process is iterative.

The primary input to the data flow analysis is

the Broad Specifications of the system to be designed.

Direct liaison with the Program nanager and prospective

users may also provide additional information. A key point

to remember during each phase of the methodology is that

decisions concerning design that are not specifically

addressed in the Broad Specifications must be documented at

the pcint of the decision. These design decisions will

later be used to update the Broad Specifications.

To start the process, identify all net input and

output data flows and list them around the border of your

working paper. This step is important because it is at this

point that you define the context or scope of the analysis

to be conducted. Data flow outside of the scope defined

here will never be addressed again.

Filling in the DFD is the next step of the

process. Wha -t you try to do is put lines in your diagram

depicting data flow and try tc connect them with circles or"bubbles" where a data transformation occurs. You can start

from the inputs, outputs or in the middle whichever is the

most ctvicus development for you. Insure flow of data goes

from left to right for ease of reading and avoid looping

hack to the left. If a loop appears necessary, duplicate

49

..............................................

the process bubble that is lcoped to in order to keen the

data flow mov.ng right. Do not cross lines and defer naming

the bubbles until later. When all of the data flows are

connected then examine each bubble to determine if some data

flow occurs within a bubble to achieve -the bubble output.

If so, then break down the bubble into subprocssses and

create lines for the new data flows discovered. If your

working paper is getting flooded with lines at this point,

it may be tim- to consider a leveled DFD approach.

Basically with the leveled DFD the first sheet

of working paper contains the set of lines and bubbles that

were thought of on the first cut while subsequent sheets

contain the internal development of bubbles that were deter

mined to contain internal data flow. The leveled DFD syszem

enforces top-down data analysis for large systems which in

turn naturally induces modularity in system design develop-

ment. Figure 4.5 is an example of a first cut system DFD.

For convention purposes the bubble which spawned the

internal data flows will be called the parent and the

bubbles that result are called children. For numbering

clarificaticn a child is always given a unique number which

is prefixed by the parents bubble or process number. As a

correctness check, always be sure the inputs and outputs of

the children correspcnd to those of the parent and vice

versa. It is also wise to only expand one bubble at a time

to insure continuity of thought. Data bases and files

accessed or modified by a bubble should appear on the high

level diagram with the parant and the appropriate lower

l.vel diagram with the child. To be sure, upon further

analysis a child may develop children of its own and in thisway various levels of a system would be created. Figure 4.6

shows how one bubble of the HSCLCS was decomposed to form

new levels. Note that this particular example does not

balance parent and child inputs and outputs; so further

refinement is required to capture the correct data flow.

50

-~

IM" 12

U dc

- I. IIc 1 9

I 4at

I a01 a1 '

I all I

taP.

I II-~ 4 6

Ma

4. &4LSS~tmFo Darm

.4 4 51

Z -.

4 .2

z aPiuI 4. ILSDcd uptDD

552

After your paper is filled with lines and

bubbles, you should label the data flows. Make sure the

names of the data flows are honest, concise and descrip-ive.

Be careful not to grcup disparate items together into one

data flow when they have no business being zrea--ed as a

whole. If the name is not very obvious, it is possible thatyou need to r.partiticn or break d-wn the flow into levels.

The naming process is designed to help you catch errors In

your data analysis so be prepared to back up and reconsider

at this pcint.

After the data flows are appropriately label-.d,

it is time to label and number the process bubbles. Usesimilar guidelines for naming the bubbles as you did for the

data ficws. Additionally,try to construct names with a

singular action verb and singular object. If you find your-

self caught using two verbs for one bubble, it may be time

to repartiticn.

After one iteration of the DFD process, a good

practice is to set it aside for awhile before begirning the

refinement process. The refinement process consists of

examining each bubble and data flow line to determine if

further decomposition is required. Information ccntinuity

is required on all refinements in that all incoming and

outgoing data flows in a refinement must have appeared on

the previous version. Figures 4.7 and 4.8 show a initial

decomposition of a process bubble and a subsequent refine-

ment. The iterative process continues until the analyst

feels that all bubbles and data flows have been compl tely

develcped or until further decompcition would not be of any

practical use in his opinion. Clearly, experience will best

teach the analyst when the bottom level is reached.Furthermore, fin&. versions of DFD's from this stage of the

design methodology may be required to be modified during the

next phases of the methodology.

53

L

. .. . ... ....-. ... . . ..-. ... . . . . .. . . . . .. . . . .

Examples cf DFD development for the HSCLCS are

* contained in Appendix A.

c. Using the DFD

The initial use of the DFD :s -o conver-t this

product into a Function Hierarchy via the transform/Stransaction analysis technique described I n 'he next

* secticn. The Program Manager will use the DFD's to famil-

iarize himself with the basic data flow cf the design cf the

system graphically without having to trace the flow of data

through a lengthy alqorithm, the Broad Specifications, or

the final design. This initial graphic understanding of the

system to be managed will also allow the Program Manager to

more easily understand the final design itself and to be

able to quickly ccnceptualize th . flow of information

Srefered to in the design decisions documenta-ion.

The data flow analysis, completed in tho form of

data flow diagrams, will lay the corner s-one for the devel-opment of the design. This process must be done carefullyto insure that the foundations for modularity and implicit

informaticn hiding are established from the beginning of the

system development process.

2. Transfo rmTransacticn Analsis

a. Def initions

"ransform/trans action analysis is an algorithmic

techrique f-,r developing a Hierarchy of Functions which is

dependent only on the structure of the input product, the

ata Flow Diagrams. As the method name implies, there are

only two high-level structural forms indigenous to data flow

diagrams: transform flow and transaction flow. The methodsupposes that certain fundamental characteristics exist in

all scf-ware systems: data must be nput, manipulated, and

54

-C

i La

I CA

-- C

I IzI Ia

vi w

C- -c.7 ISLC Dioa naeetI

LJC

4.~~a Q~~~

.. j IA

I II

I L&S

I~~L -j -

I UAI IA

I Ia

Fi-~ 4. IICC i~a taae- F aieetCeI 56

77 P. W-.. .

output. These characteristics are broad enough in natu_- to

make the technique widely applicable to many types of soft-

ware development. Specifically, the method is highly ccmpa-

-able with the develcpment of real-time syst=ms makiLng it

ideal for our purposes. The reader desiring further d-scus-

sion of the technique should ccnsult Pressman [Ref. 5].

Transform flow, our fundamintal system model for

all data flow, envisicns the system as inputinc and output-ting data in an "external world" form and processing (trans-

forming) cf informaticn in an internal form. Trnsform flowis necessary to accommodate both the user who must input and

interpret data in the external form and -he computer which

must process data in the internal form. Simply stated, if

the flow of information can be viewed over time as: (1) an

afferen- flow from the external representation of the inputs

to the internal representation; (2) a process flow wher :hzinternally represented data is manipulated to producq the

d- sired results; and (3) an efferent flow from the intarnal

representraticn to some appropriate external display for thsinformation then transform flow is present. Figure 4.9

illustrates the transform ficw of information. Transformflow, as a basic model for all software development, charac-

terizes systems very simply. They input data, change it to

an internal form, process it, change it to a suitable output

structure, and output it.To solidify the above discussion, we must d-fine

afferent and afferent flow which is the key to the charac-

terizaticn cf transform flow. Afferent flow is information

flow along paths which cause the gradual transformation of

data from an external format to an, internal format. The

transformation can be viewed as a funneling of the infcira-tion through external/internal interface translators toward

a central processing Fcint, a transform center. Efferent

flow is the flow of information outward from the transform

57

Io -~-~ 2. ->:-* *\ - ~ * .**- . .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .

EXT

I NFI0 AER F EIM F F F

IA E L E L

I0 N NN T TINT* PR__ _ _ _ _ __OW

I TIME

Figure 49 Transform Flow.

c-ant er through Jnterna1/extsL-na. interface translators to

the devices which will display the: results of thm processing

to the system user.ansacticn flow i's characterized by a process,

called a transaction center, which takes an external impetus

and causes the data flow to be directead down one of severalpaths emanating from the transaction center. The pa th ta ken

*is determined by the value of the -nput. FiJgura 4.10 showsthe generic form of a transaction zlw An ayvsaia

tion of transaction flow Is tc compare It wi-:h the standardcase statement. The case statement structure? corresponds to

*the transaction center, th e c3se 7ariJable value is equiva-lent to the external impetus (input) , and the suhp=roc-=ss

58

J".

Pi i p

I IMPETUS

I (N -)

P(N) P N

III

Figure 4.10 Transaction Flow.

cald wtn executing the case stats-ment cor-esponds to theaction path taken in the Data Flow Diagram.

b. P--ocsdures: A Case Study

To present +-he tran sf o r/transa c- i" n ana lysisec h nique, a case study of the HSCLCS Disgiay Engaement

Module will be ued. Th,: . Data Flow Diagram petinent to -.hecase study i6s shown in F~gure 4.8. A g-3nszal -ule applicable-o this analysis is tha-- he -zn t"' r zefnmn -~cs f

the Data Flow Diagrams must 5 ccmpl!s-ad bsfc- e commeanc'nq

59

,W,. ),, .I., . - . . - . - . .I., . . . . , . . .' , . . . , . . , , ' . - . ' . : . ' . ? . . : .. . ; : . . ; , . - - : , , . , . . - . . . , - . . - . . - , . . . , - . . - . - . . - .

the prccedure. Otberw ise, the proper struct ure cf he

function. Hierarchy cannot be assured. Th=- procdur_-

detailel below provides a tem~plate for a generi4c system. I n

some relatively simple developments, all of tsesteps m!%v

nct be needed, e.g. secondary flow analysis, an~d can.li -z i:e

* fcrs be omitted.(1) flo! CharacteriLStigs. The first step of he

procedure is to dete mie the character isti4c f low ~ h

data. It ia possible for both types of flow to exist on i* single diagram; this is the case for our ?xample. U-nder

these circumstances the dcminant :Elow Dat:ern must be dster-

mined. In the case study, the transactior. flow about the

bubble labeled "'Display En-gaqement Controller" appears to be

dominant.(2) taki he LDiaqrm. Next t-hs Data Flow

rliagram :s annotated to shcw the various -Flcw bour'ar;.ss.Because ths transaction flow is dominant , we w;.Il apply the

rules for marking the transaction flow first and look for

*the afferent/efferent boundaries to mark the transfcr:m flow

*-second. T he rul21e s for tr ns act ion analysis begin wit-h

*finding and isolating the transaction center. As t-hp !efi-nition states, the transac-tion cent:er -:s that procedural

hble which ccntain -uLi. radally .ema:,-ati ng d at a

paths. Figure 4.11 shows the isolation of 1-he trarsactiJon

center for the case study. This i-dentificatlion of the major

flow v-ill ulti-mately develop the upper level1 modules on theFunction Hierarchy. To provide details for a good HierarchyChrfurther refinement of the flow characteristics must

he performed. Since all of the secondary flow in the case

* study Is transform in nature, the next step is to locate the

transform centers. They are easily found by observing the

affarent flow into selected procedural bubbles and the efte-

rent flow cut of others. In the case study, the secondary

* flow on the left side of the transaction center is detai'led

60

*~~~~a Q

7*-~~C < .J JL0i m

-0 -0 C

L.J- -J -. 5

Q. UC k. *c I.-.5..

IU -flI Iz

0 CL. dc

* I II IC

0 -C-C I.

Figure 4.11 Isolation of the Transaction Center.

61

while cn the right side it is trivial (see Figure 4.12).

The right side is trivial because :hs flow boundaries ar- in

lowest terms: a single datum afferent flow; a slgle

processing bubble; and a single datum efferent flow. Thus,

one would expect the modular breakdown on the input side of

the hierarchy to be scmewhat more detailed than that on the

controller side. Later this will be shown to be the case.

(3) Hierarchy cf the Dominant Flow. Once the

Data Plow Diagram is appropriately marked, the first cut

hierarchy for the dominant flow is generated. The fact that

flow is the key to generating the hierarchy supports the

suppositicn that the structure built during twe data flow

analysis will be maintained. Both types of flow have

strictly mechanical means to arrive at the first cut hier-

archy. This is because of the way data flow diagrams are

partitioned when marked.

When the dominant flow is transform in

nature then the first-level factoring produces a two level

hierarchy. The upper level is a control module with a

• generic name chosen tc illustrate tha global function of the

procedure. The second level contains three generic ccr.trol

modules with the following functions: one coordinates the

afferent information, the second controls the processing,

and the third coordinates the efferent information. The

process bubbles controlled by the se three modules are

captured by the afferen t/processing/effer ent boundaries

marked on the Data Flow Diagrams.

Should the dominant flow be transaction in

- nature, the first-level factoring produces a three level

hierarchy. The upper level performs the same function as

its counterpart used in transform flow. The middle level

- consists of two controllers: .ne for con:rolling modules• which handle the input flow to the transaction center and

cne for ccntrolling modules which handle -he individual

62

777 -

-0 - -C

(j CLIJ 0-La ., ~ ,..

1- o

2C <

IA -C- - ~-§i.~ - -

rn _ __

____________________________________________4j_______________________._ VI________