AD-A014 583 STRUCTURED ANALYSIS MODEL FOR NAVAL .

2. 3Top-Down ViewsThe principle of "top-down" system design gives an overallorganization to the set of SA blueprints.It is based upon viewinga system from the highest-level, most general viewpoint, and thenbreaking down this view into successively finer and finer levels of detail.Structured Analysis adopts this top-down approach, and further refinesthe rules by the principle that any specific blueprint view is composedof not less than three and not more than six pieces.The top-down"decomposition" procedure thus presents first a very general view thatis understandable by a wide class of readers--by top management downto the individual workers.As successively finer levels are shown, moreand more of the detail is exposed, and the detail needed for completeunderstanding is attained.Note that various levels of the managementpersonnel need not become familiar with these lower levels, sincethey may only be concerned with overview or briefing-levels ofdetail.It should be noted, however, that since the lower levels arederived directly as expansions of detail from the higher levels, allviews are rigorously tied together into a single model and thus eventop-level overviews represent the true picture of what is contained atlower levels, with nothing omitted or added.Meanwhile, the 3-6rule ensures that neither too little additional detail to be meaningful nortoo much to be understandable is introduced by each lower leve’ presented.The Structured Analysis top-down decomposition model is represe-ued by a series of diagrams as shown in Figure 2.2.In Figure 2.2,me 3-6 details at each level are represented as numbered boxes, andwe see that each individual detail box is decomposed into another diagramat the next lower level.Each diagram is called the "parent" of its 3-6"children" diagrams, and each diagram is numbered in a Dewey-decimalmanner, based upon the box number assigned in its parent view (e. g. ,diagrams 211,212, and 213 are children of diagram 21).Each diagramin this structure is called a "node", and a complete layout of all nodesof a model in the form of a "table of contents" diagram is called a "nodediagram" for the model (see Section 4. 1).2-5

.Figure 2.2i-jLStructured Analysis ModelA complete analysis may require additional diagrams which donot fit into this top-down decomposition.These additional diagrams areused to highlight some particular point which may be obscure in a complexdiagram.For example, a diagram may be used to show the major feedbackpaths in a sub-system.These extra SA diagrams are called "FEOs",where this acronym stands for "For Exposition Only", since they exposesome aspect of a system but are not part of the top-down diagram struc ture that makes up the basic model.2-6

âActivity and Data AspectsTo describe any complex system completely, there are two basicaspects which must be covered: the functions performed by the systemand the things upon which the functions act.In Structured Analysis, wecall the functions '’activities" and the things "data".(Note that the termdata" as used here covers more than the term "data" as used in computerapplications or in mathematics--it includes anything which is not anactivity. )In Structured Analysis, we decompose a system once based uponits activities, and again, in a separate model, based upon its data.the same subject matter is examined twice:results in two separate top-down models.Thus,once from each aspect. ThisAs a final step, the two modelsare tied together to show how details of one aspect correspond to detailsin the other aspect.Actually, as will be seen in Section 3. 3, each aspectpresents a complete analysis of the subject.In the activity model,activities are emphasized and data items appear as the interfacesbetween them, whereas in the data model, data is emphasized andactivities are included as interfaces.both data and activities.Therefore, each model containsHowever, the emphasis is quite importantin determining the specific decomposition into levels of detail, andthe reader will soon see how by building these two separate modelswith these two complementary emphases, we achieve a much richerunderstanding of the subject than is afforded by a single model.«2-7

Section 3DIAGRAM SYNTAXStructured Analysis diagrams are composed of boxes and arrows.Many box-and-arrow "languages" exist (flow charts, pert charts, blockdiagrams, etc.), but the conventions chosen for Structured Analysis arevery carefully selected to provide very simple yet expressive componentparts for the purpose of describing complex systems.In other words,the box and arrow conventions provide a very natural language for expres sing system activity and data modules without becoming so complex asto make them difficult to read.For connecting between top-down levels . *.;d for same-level moduleinterfacing, the boxes and arrows of Structured Analysis correspondclosely to the plug-in circuit modules discussed in the overview (Section2.1).The activity or data described by the box can be removed andreplaced by an equivalent module, much like electronic circuit modulereplacement (see Figure 3.1).Figure 3. 1Plug-In SA Module2-8

The following 3ections describe the SAbox and arrow conventiondetails, first discussing individual boxes, then box connection on a singlediagram, and lastly, boxes connected across levels of decomposition.3.1Individual Box Conventions3.1.1Box Shape and MeaningThe four-sided box is the only shape of box used in StructuredAnalysis.Inside the box, the name of the activity (activity model) ordata item (da'a model) is written.In the activity case, the name containsa verb (to express action) and in the data case it is a noun or noun phrase(to express a data item) Figure 3.2 illustrates the two forms.Hk1r';¡::ÜFigure 3.2 Activity and Data Box Titles3.1.2Arrow InterfacesArrows are used to connect boxes on a diagram, and representinterfaces between boxes.The four sides of a box are each assigned aspecific meaning which defines the kind of arrow which may enter orleave that side of the box.Figure 3. 3 defines this box/interface arrowconvention, where more than one arrow may enter or leave a single side.2-9

CONTROL O OUTPUTINPUTMECHANISMFigure 3.3 Box/Interface Arrow DefinitionThese rules are strictly obeyed in all SA diagrams.That is,an arrow is not permitted to leave the left side of a box, and an arrowentering the left side of a box always represents an input, etc.3.1.3Arrow LabelsAs with box titles, titles are written along interface arrows todefine the interfaces.The arrow title may simply be written nearby(above or below), or may be attached to an arrow by a "squiggle" if itwould otherwise be ambiguous as to which of several arrows is intended,due to their close proximity on the diagram form.Figure 3.4 illustratesarrow label conventions.label 1Figure 3.4 Arrow Labeling ConventionsIn Figure 3.4, "label 1" labels the horizontal arrow and "label 2" labelsthe right-hand vertical arrow.In the latter case, a squiggle associatesthe label with the right-hand arrow rather than the nearby left-hand arrow.2-10

3.1.4Kinds of ArrowsEach of the four categories of interface arrowhas a particularkind of interface it represents (the kind of thing represented by the arrow).In the activity diagram case, the interfaces between activity boxes aredata items, since data is commonly passed back and forth betweenactivities.In the data diagram case, the interfaces between data boxesare activities, since activities create and make use of data items, andtherefore serve the interface role.The "mechanism11 arrow is an exceptionto this rule, since it represents the mechanism necessary to "realize thebox" (see complete definition below).In the activity case, the mechanismis the person or thing which serves as the "processor" which carries outthe activity (or some portion of it).In the data case, the mechanism is the"storage device" used to hold the data item (or some portion of it).3,1,5Box/Arrow Convention SummaryThe box interface conventions are summarized in Figure 3. MECHANISM(store)MECHANISM(processor )UiFigure 3, 5 Box/Interfaces Arrow ConventionsExamples of interfaces are illustrated in Figure 3.6.2-11

considerpricesweatheri-SLseedsi r QWVEGETAS les s e11 VEGETABLES S-barnfarmerData ViewActivity ViewFigure 3, 6Examples of Interfaces/If you were to write equivalent sentences for the two boxes of Figure 3. 6,they would say "the farmer grows vegetables from seeds subject to thecontrol of the weather" and "vegetables are grown and kept in the barn,from which they are sold, considering current prices". The example illustrates the usefulness of separating the conceptsof input and control.There is a basic difference between an input, which(in the activity view) is converted jy the activity into the output, and acontrol, which is never modified by the activity, but rather constrains howthe activity functions in converting the input into the output.The controlthus serves a completely different role than the input, and this distinctionis important to the basic understanding of the system's operation.In actual practice, a single interface arrow may include aspectsof both input and control.In this case, the rule is that"an arrow is always considered as a control unlessits obviously serves only as an input"2-12

The reader should therefore not be too hasty to judge that an interfacearrow is in error if he feels the input/control convention is wrong.K;;-HeV should attempt to consider the arrow as intended by the author beforePimaking too hasty a judgment.g Il3,1.6î;:î(mvArrow Category DefinitionsTo summarize the arrow conventions, the four categories aredefined as:Activity Diagrams:*Input: Data transformed by the activity into the output. Output: Data created by the activity. Control: Data used to control the process of convertingthe input into the output.Mechanism: The processor which performs theactivity (person, computer program, etc.)Data Diagrams: Input: Activity which creates the data. Output: Activity which uses the data. Control: Activity which controls the creationor use of the data.Mechanism: The storage device used to hold thedata (buffer, computer memory, etc. )* For convenience of reference, inputs and controls are sometimescalled "entries", while outputs are sometimes called "exits".2-13

3.1.7Multiple Arrow InterfacesIn Section 3. 1. 2, single arrows were shown entering or leaving thefour sides of a box, for simplicity.multiple arrow interfaces.Actually, boxes frequently haveThese are shown as separate arrows, asillustrated by Figure 3#7.RecipesFamilyPreferencesV egetablesChefStoveUtensilsFigure 3-7 Example of Multiple InterfacesClearly, too many such arrows tend to clutter an SA diagram, and arediscouraged.Instead, interface arrows are commonly "clustered1’ intoa single arrow sometimes called a "pipeline" (but drawn the same way),and labeled with an appropriate, more general title which classifies themultiple contents of the pipeline.To see the fine interface detail shownby the breakout of the individual arrows, a lower-level diagram in thetop-down structure may be examined.For example, the four outputarrows shown in Figure 3. 7 might be clustered into two pipelines labeled"main course" and "side dishes", where the "side dishes" pipeline con tains the three arrows "soup", "salad", and "dessert", thus simplifyingthe interface arrows picture at this level of diagram.This "clustering" technique plays an important role in creatingunderstandable SA diagrams.It may be noted here that the level ofgenerality of box and arrow titles should more or less match at anyone diagram level, and that both box and arrow titles should growsuccessively more detailed as lower levels of diagrams are examined.2-14

3. 2Connections Between BoxesSo far in the discussion, we have considered only individual boxesand their interface arrows3To form a complete Structured Analysisdiagram, 3-6 boxes are drawn on an SA diagram form.The box titlesrepresent a carefully chosen decomposition of a single box on the parentdiagram, and cover the exact same subject matter, only in a lower levelof detail.The input, output, and control arrows are then connected toshow interfaces between the boxes.Figure 3. 8 illustrates four connectedboxes as their interface structure might appear on an SA diagram.THISBOXFigure 3. 8Multiple Box InterfacesThe basic connection rule is that any output arrow may providesome or ¿11 of the input, control, or mechanism to any other box.fact, as illustrated by the output of box 1 in Figure 3. 8an output arrowmay split, and provide entries or mechanisms to several boxes.2-15In

3. 2. 1Constraint RelationshipsIn Structured Analysis, the connection of the output of one box toone or more other boxes shows a constraint relationship between thosetwo boxes.That is, in an activity diagram, the box receiving the datais constrained, since it cannot begin its activity until the box providingthe data sends it along.On a data diagram, the data cannot be used untilthe indicated activities supply it.This convention provides a subtle butimportant difference between common flow charts and Structured Analysisdiagrams, in that SAdiagrams can very naturally depict simultaneousactivities.As an illustration, consider Figure 3.8 as an activity diagram.Since box 1 provides input to both boxes 2 and 3, neither activity 2 nor 3can begin until this data is provided.Once it i s provided by box 1, box 2may begin its action, but box 3 cannot start, since it must wait for box 2to provide the needed control data, as shown.If the control ajw frombox 2 to box 3 did not exist, both boxes 2 and 3 could have started andoperated in parallel, using the output of box 1 (see Figure 3. 9).Figure 3.9Simultaneous Action2-16

Thus, sequence relationship can be shown, but the author is notconstrained to simple sequences.This sort of flexibility is essentialin properly modeling real-life system operation, and plays an importantrole in modeling various forms of feedback actions and in highlightingsystem initial corditions, both of which will become clear in the discussionbelow.3. 2. 2Specific Interface FormatsTo describe the various forms of interface connections in moredetail, the following sections begin with simple interface relationships,and build up to more and more elaborate relationships and commonpatterns found in Structured Analysis models.Examples are taken fromthe activity view to illustrate each point, but equivalent forms of relation ships on data diagrams are equally straightforward.3. 2. 2. 1Basic Input/Output RelationshipThe basic input/output relationship is illustrated by a box whichproduces output which is, in turn, used as input by another box.Figure3.10 illustrates this relationship.Figure 3.10Input/Output ExampleHere, seeds grow into vegetables, which in turn are cooked to producesoup.The input/output relationship is clear, in that the data (seeds,vegetables, and soup are modified by the activities (grow and cook)and therefore cannot reasonably serve as controls.2-17

,,, ippppW-- 3. 2. 2. 2 Basic Output/Control RelationshipsInstead of producing input to a second box, an activity may producea control, as illustrated in Figure 3. 11.Figure 3.11Output/Control ExampleIn Box i, new combinations are tried, and combinations that work outwell are formalized into recipes, which, in turn, control the cookingprocess.The recipe is clearly a control on the process, and does notmake sense as an input, since it is not modified by the activity.3. 2. 2. 3 Basic Output/Mechanism RelationshipFinally, Figure 3,12 illustrates the output of a box used as amechanism of a second box.vegetablesCOOK oupchef«UntrainedpeopleOTrain Chef«Figure 3, 12Output/Mechanism ExampleThis diagram shows the "chef training program" supplying chefs to manthe cooking effort.This type of "activity-producing mechanism" combination is quite rare in SAdiagrams, and is usually handled by simplynaming the mechanism on the arrow, and providing the activity and datamodels of the mechanism separately.

3.2.3Arrow Splits and JoinsFigure 3. 8above, shows one case of an arrow split in which theoutput of box 1 provides inputs to boxes 2 and 3.This is a common arrowpattern in Structured Analysis, and all manner of splits and joins arecommonly used to show box relationships.To clarify whether all or partof the contents of an arrow follows which of the branches at splits andjoins, SA uses theconvention that all data flows along all branchesunless otherwise indicated by a special label on an arrow branch. Theseconventions are summarized in Figure 3. 13.Me snsAMeansTA—rAiI(Where D is aportion of A)MeansFigure 3.13A&&Arrow Branches and Joins2-19

Figure 3.14 shows a complete SAdiagram, illustrating various combi nations of arrow splits and joins.Figure 3.14Example of Arrow Splits and JoinsFigure 3.14 says that vegetables can be cooked, sold, or given away, orthat seeds can be extracted from them.The money obtained in the c aseof a sale can be used to buy seeds, tools, or clothes, or can be given awayto produce happiness.2-20

PIArrow splitting is illustrated by the input arrow labeled "vegetables"which splits into four branches which provide the input to the four uses ofvegetables shown.Since no labels are shown on the branches, this saysthat all vegetables go to all four boxes.If the label "tomatoes" had beenwritten on the arrow branch entering the EXTRACT box, this would haveindicated that only tomato seeds are to be extracted.In the output case,"money" is shown splitting and being used by either BUY or GIVE AWAY.HIn the GIVE AWAY case, both vegetables and money are given away, asindicated by the two input arrows entering the box.Arrow joining is illus trated by the arrow labelled "seeds", showing that seeds can either beextracted directly from vegetables,

Naval Telecommunications Procedures Users Manual NTP 3, This model has been produced for the Naval Research Laboratory to provide an in-depth example of the use of Structured Analysis. The model depicts the activities and data involved in the production of naval messages using the procedures defined in the aforementioned manual.Author: Clare Feldmann, Ken Schoman, Dick SnyderPublish Year: 1975