software design representation using abstract process · pdf fileent notations andterminology...

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-6, NO. 5, SEPTEMBER 1980

[181 G. B. Purdy, "A high security log-in procedure," Commun. Ass.Comput. Mach., vol. 17, Aug. 1974.

[19] C. E. Shannon, "Communication theory of secrecy systems,"Be1l Syst. Tech. J., vol. 28, no.4, 1949.

[20] J. L. Smith, W. A. Notz, and P. R. Osseck, "An experimentalapplication of cryptography to a remotely accessed data sys-tem," IBM Rep., 1972.

[211 F. A. Stahl, E. Gudes, and H. S. Koch, "The coordination of- cryptographic and traditional access copitrol techniques for

protection in computer systems," presented at the IEEE Work-shop: Trends and Applications-Computer Security and In-tegrity, May 1977.

[22] K. G. Walter, W. F. Orden, W. C. Rounds, F. T. Bradshaw, S. R.Ames, and D. G. Shumway, "Primitive models for computersecurity," Case Western Reserve Univ., NTIS AD-778 467, 1973.

[23] E. Wong and T. C. Chiang, "Canonical structures in attributebased file organization," Commun. Ass. Comput. Mach., vol. 14,Sept. 1971.

Ehud Gudes was born in Haifa, Israel. He re-ceived the B.S. degree in physics and the M.S.degree in computer science from the Technion-Israel Institute of Technology, Haifa, Israel, in1967 and 1973, respectively, and the Ph.D.degree in computer and information science_from the Ohio State University, Columbus,

From 1970-1973 he worked as a SystemProgrammer at the Technion-Israel ComputerCenter. From 1976 until August 1979 he was

an Assistant Professor of Computer Science at the Pennsylvania StateUniversity, University Park. There he did research and published papersin the areas of data security and database systems. He has also con-sulted on and developed an on-line information retrieval system. Heis currently working at Wang Laboratories, Lowell, MA, where he isresponsible for query language development.

Software Design Representation Using AbstractProcess Networks

LEON J. MEKLY, MEMBER, IEEE, AND STEPHEN S. YAU, FELLOW, IEEE

Abstract-An approach to software design representation which isconsistent with the concept of engineering blueprints is presented. Themain criteria for software engineering blueprints are defined and a net-work scheme of graphical representation is considered through an over-view of Petri net techniques. The concept of an abstract process (AP)is introduced as the basic element of system representation. An ab-stract process network schema of software design representation isdeveloped and supported by an algebraic system of notation. Methodsof AP-net construction are presented and illustrated by examples. Theadvantages of using the proposed approach in different phases of soft-ware engineering are pointed out and the main directions for furtherresearch have been identified.

Index Terms-Abstract process, AP-net, engineering blueprint, fi-nite state machines, Petri net, process expression, software designrepresentation.

I. INTRODUCTIONT HE PROBLEMS of software development are well known,Tas well as the need for an engineering approach to solvethem. The design phase of the software life cycle is the pri-mary activity in which the introduction of mathematical for-malism and engineering discipline is of critical importance.However, an ever increasing number of proposed methodol-ogies, many of which are largely intuitive, still fail to provide

a consistent engineering basis for software design and furthercreate the problem of deciding which methodology is the cor-rect one for any particular case. Moreover, the use of differ-ent notations and terminology makes the transition from onephase of development to another extremely difficult. There-fore, developing an engineering approach to software designis one of the most important problems in software engineering.This problem is approached here by recognizing that design

is the process of building the representation of an object to becreated, and therefore the correct form of design representa-tion is considered to be the main instrument necessary for theintegration of essential mathematical and engineering conceptsinto the software design process. This paper presents an ap-proach to the problem of software design representation whichis consistent with the concept of blueprints used in the engi-neering professions.In Section II, a brief overview of the role of the design phase

is provided to point out that the concept of engineering blue-prints is the main tool for the unification of the importantprinciples and practices of software engineering. The neces-sary criteria of the software engineering blueprints are formu-lated following a brief discussion of the present techniques.In Section III, a brief overview ofPetri net techniques is givenand their various features and limitations are noted to providea few basic ideas for the development of a network scheme of

Manuscript received October 1979; revised May 1980. This work was software design representation.supported in part by the U.S. Army Research Office under Grant In Section IV, the concept of a hierarchical abstract processDAA27-76-G-0183. is introduced as the basic element of system modeling. A de-L. J. Mekly is with Teletype Corporation, Skokie, IL 60077.iS. S. Yau is with the Department of Electrical Engineering and Com- velopment of abstract process network schemata is presented

puter Science, Northwestern University, Evanston, IL 60201. through the stepwise definition of the essential primitives and

0098-5589/80/0900-0420$00.75 ) 1980 IEEE

420

MEKLY AND YAU: SOFTWARE DESIGN REPRESENTATION

construction rules. In Section V, a formal definition of ab-stract process networks is given and the method of theirspecification is illustrated by a simple example. The advan-tages of using the proposed scheme of representation in dif-ferent phases of software development are pointed out.In Section VI, the construction methods of abstract process

networks are presented and illustrated by examples. Theaspects of using other forms of representation with abstractprocess networks are also considered. Section VII concludesthe paper with a brief summary of results, their practical im-plications, and recommendations for further research.

II. SOFTWARE DESIGN AND REPRESENTATIONThe software design phase occupies the central position in

the software life cycle. It transforms the "what" requirementsinto "how" specification, and thus, assumes the main respon-sibility for the entire product. The design phase is concernedwith making major decisions at the structural level. It notonly defines a detailed plan for system implementation, test-ing, and maintenance, but also provides a feedback to therequirements analysis phase to point out incompleteness andambiguity in problem definition from which the most criticalerrors usually originate.Recognition of the critical role of the software design phase

has spurred the development of many design techniques, tools,and methodologies, most of which have been already surveyedin a number of papers, books, reports, and special tutorials[1 -[7]. Nevertheless, software engineering is in a predica-ment; and large-scale software systems are too costly, tooerror-prone, too complex, and too hard to maintain [8]. Oneof the reasons is that there exists a significant delay betweenthe introduction of new techniques and their practical accep-tance, as it has been in the case of structured programming.Another reason is that too much attention is given to themethods and techniques of implementation, and far too littleto the quality of design being implemented [9].A comparison of design methodologies can be used to reveal

their strong and weak points so that another "improved"methodology can be proposed, and so on. However, many ofthe proposed methodologies fail to demonstrate a practicallyeffective approach to software design, to enforce a consistentengineering discipline, and to provide a sound theoreticalbasis.Since design is the process of building the representation of

an object to be created, the form of design representation is ofcritical importance to software engineering. In every engineer-ing profession, the form of design representation is associatedwith the concept of an engineering drawing, frequently calleda "blueprint." The need for a software blueprint has beenstated explicitly in a number of papers [10] - [12]. In [12],the term "blueprint" has been even used to define the soft-ware design phase as the creation of software blueprints.However, there is no yet commonly accepted defmition of

software engineering blueprints, and until recently, softwaredesign representation has not been even addressed as a specificresearch problem [131 . The range of proposed representationschemes extends from very graphical forms [10] to highlyanalytical expressions [14], [15]. Many forms of representa-

tion, such as flowcharts [16], computation structures [17],data flowgraphs [18], structure charts [19], HIPO diagrams[20], Nassi-Shneiderman charts [21], [22], decision tables[23], [24], etc., primarily evolved along with the developmentof programming techniques [25]. A number of representationschemes have resulted from the application of structured pro-gramming concepts [26] to conventional flowcharting tech-niques [27].Although recent experimental investigations seriously ques-

tioned the utility of the flowcharting techniques [30] andcautioned users to beware of their possible pitfalls [29], theintuitive simplicity of flowcharts is the main reason for theirwide popularity. For example, a recently proposed scheme ofrepresentation for multiprocessing [30] is based entirely onthe use of structured flowcharts. Also, it has been shown [31]that there exists an interesting similarity between flowchartsand electrical circuits.Some forms of representation, such as structured English

[32], also known as program design language (PDL) [33],[34], are essentially the textual equivalents of flowcharts.These forms are neither graphical, nor analytical. Neverthe-less, they are also claimed by some authors [37] to be thesoftware blueprints. An extensive survey of existing tech-niques for the specification of software in all developmentphases is provided in [36]. The methods, which are not in-cluded there, are probably only [37] - [41]. However, whichof the representation schemes, if any, can be qualified as thesoftware engineering blueprints?Obviously, this question can be answered only if we know

the criteria which define the concept of engineering blue-prints. To identify the important features of engineeringblueprints, let us consider a particular representation schemewhich is used in the design of computer hardware, since thefunctions of hardware and software are based on the same log-ical principles. A direct relationship between graphical andanalytical forms of representation used in digital logic design[42] is the most important feature of that scheme, becausea simple to interpret graphical representation can be easilyconverted to equivalent algebraic expressions to facilitateformal analysis and simplification.Another property of such representation is the explicit

separation of the logical structure from the specification ofimplementation details. In software context, the value ofthis principle has been demonstrated by the fact that struc-tured programming and good style [43] make the structureof programs more visible, and thus, easier to understand andmaintain [44]. However, for the purpose of analysis, it stillmay be necessary to extract and evaluate the program struc-ture by graphical means [45], [46]. Then, why not specifythis structure separately, from the very beginning, instead ofspreading it over specific processing details and then trying tomake it visible?

Finally, it is important to note that an engineering blueprintis not just a form of specification, or documentation, but aformal model of system functional and structural aspects.Therefore, the graphical-analytical simplicity of a design rep-resentation scheme is the key feature for the effective con-struction and analysis of system models. Considering the gen-

421


eral features of engineering blueprints in the context of themain principles and goals of software engineering [48], weconclude that the software engineering blueprints must satisfyat least the following criteria.

1) Represent the logical structure of a system and the cor-responding data transformations at different levels of abstrac-tion.2) Provide a complete, unambiguous, and machine process-

able specification for system implementation, testing, andmaintenance.3) Provide a simple means of graphical expression for

easy understanding and interpretation of a system design.4) Provide a simple algebraic system of design expression,

easily convertible to an equivalent graphical form, to facilitatethe analysis, modification, and verification of design by meansof formal algebraic operations.5) Enforce a discipline upon creativity during a design pro-

cess so that a produced design is hierarchically organized,modular, and well structured.6) Provide a simple means to model dynamic properties of

a system by explicitly identifying the relationship amongvarious conditions, decisions, and actions.7) Integrate the basic principles and concepts of system de-

sign (such as abstraction, elaboration, analysis, synthesis, func-tional decomposition, hierarchy, modularity, etc.), for theireffective application during the software design process.In the following sections, we will discuss the main steps and

the results of developing a formal approach to software designrepresentation, which is consistent with the main criteria forthe software engineering blueprints.

III. OVERVIEW OF PETRI NET TECHNIQUESDesign is a synthesis process which defines the interconnec-

tion of parts to form a system, and that is why the concept ofa network plays an important role in a number of engineeringdisciplines. A network scheme not only represents the struc-ture of a system, but also allows one to determine its dynamicproperties as well. Therefore, an overview ofpowerful networkmodeling techniques can provide a few basic ideas for develop-ing an engineering approach to software design representation.Among the various techniques of system modeling, based on

the network concept, it seems that Petri nets are more suitablefor our use according to our criteria. An extensive survey ofPetri net concepts and their applications is available in [49].Structurally, Petri nets are very simple extensions of conven-tional directed graphs with two types of nodes: places cor-responding to conditions, and transitions corresponding toevents. That is, Petri nets are bipartite graphs, where thenodes of one type can be directly connected only to thenodes of the other type.State information is represented in a Petri net by placing

tokens in the places. A token in a place indicates that aparticular condition represented by that place is satisfied.Each place in a Petri net may contain one or more tokens,or it may be empty. The distribution of tokens among theplaces of a Petri net is called a marking. If all input places

is said to be enabled, and, therefore, it may fire. When atransition fires, one token is removed from each of its inputplaces and one token is added to each of its output places.In general, each marking defines a set of transitions enabled

to fire. If this set is empty, the execution of the Petri nethalts. However, if several transitions are enabled, then a de-cision must be made as to which transition will fire next. Twoenabled transitions are called concurrent if their inputs are dis-joint. Otherwise, these transitions are said to be in conflict.The concepts of concurrency and conflict are central to Petrinet theory.Among a few problems associated with Petri net analysis are

liveness, safeness, and reachability. A Petri net is live if a dead-lock cannot occur during the network execution. A deadlockindicates the existence of a transition which cannot fire, andno sequence of transition firings will result in a marking en-abling that transition. A Petri net that never has more thanone token in any place is called a safe Petri net. This limita-tion, however, can be extended so that a Petri net becomesk-safe if the number of tokens in any place never exceeds k.A reachability problem is closely related to the liveness

problem of Petri net. The question is whether any particularmarking for a given Petri net can be reached from its initialmarking. This problem is particularly important becausemany analysis questions can be expressed in terms of reach-ability. However, although the reachability problem is gen-erally solvable [49], it may be too complex to be practical.The general tools for the analysis of Petri nets are usuallybased on the concept of a reachability tree. However, thereachability problem cannot, in general, be answered by thistechnique. Another approach is based on the use of a transi-tion matrix which represents the change in the marking foreach place with respect to each transition. Nevertheless, someproblems of Petri nets, such as the equality of reachabilitysets, are known to be unsolvable [49].The scale of the formal modeling techniques, which are

based on the concept of a directed graph, extends betweentwo extremes with respect to their modeling and decisioncapabilities. At one end of this scale are the fmite state ma-chines, with low modeling power and high decidability. Atthe other end are Turing machimes, with good modeling capa-bility and poor decision power. Petri nets represent an at-tempt to compromise between those two factors and havebeen originally defined as an answer to the limited modelingpower of the finite state machines. In terms of modelingcapabilities, Petri nets seem to be just below Turing machines,and, therefore, any significant extension of Petri nets tendsto be equivalent to a Turing machine. That is, the analysisof such extensions becomes extremely complicated due toundecidability problems. However, the modeling and de-cision capabilities of Petri nets are not satisfactory for everyparticular case, and therefore, a number of extensions andsubclasses have been developed to satisfy a variety of needs[50].A significant extension of Petri nets was the introduction of

inhibitor arcs, such that a transition can fire only if inhibitorplaces have no tokens. Other extensions of Petri nets include

422

of a transition contain at least one token, then the transition


the introduction of priorities between transitions, time boundson transition firings, and constraint sets that prohibit tokensto reside simultaneously in the specified places.The analysis of Petri nets can be simplified if their synthesis

is restricted so that every produced model is correct due to itsconstruction. However, similarly to unstructured flowcharts,Petri nets fail to enforce any discipline during the constructionprocess. Therefore, a general approach to simplify the analysisis to define a suitable subclass of Petri nets with a limitedmodeling power. A subclass of Petri nets is usually definedby imposing certain structural restrictions, e.g., a restrictionon the use of common input places eliminates a conflictproblem.The following subclasses of structurally restricted Petri

nets have been identified [511: 1) finite state machines,2) marked graphs, 3) free choice nets, and 4) simple Petrinets. For example, a finite state machine is a Petri net whereeach transition has only one input place and one outputplace. A similar restriction is used for a marked graph, butit applies to places instead of transitions. Another methodof imposing restrictions on Petri net models is suggested byMisunas [51], where a P-net is defined as a Petri net, limitedby a set of constraints C, which force the net to be safe andfree of conflicts.A good example of using both the restrictions and the ex-

tensions of Petri nets, with a goal of improving the modelingconvenience and simplifying the analysis, is demonstratedby the formulation of E-nets [53], [54]. Another modifica-tion of Petri nets, called pro-nets (551, is intended for model-ing of software and hardware systems which are too complexto allow observation of the entire structure at any one time.Baer in [56] briefly gives examples of a few subclasses and

extensions of Petri nets which have been used for design,simulation, and performance evaluation of distributed com-puter architecture. Some results of an investigation towardthe applicability of Petri net models to support specificationof system requirements have been reported in [57], [58]. Theuse of Petri net techniques in the design of a compiler for aparallel environment is demonstrated in [591. Applications ofPetri nets for design of communication procedures are dis-cussed in [60], and for performance evaluation of distributedcomputing systems in [61 1. An overview of some applicationsof Petri nets to different types of systems and further refer-ences are provided in [62].Petri nets with their extensions and subclasses provide sev-

eral advantages as a system modeling technique. First, theoverall system structure and behavior is often easier to under-stand due to the graphical and precise nature of the represen-tation scheme. Second, the behavior of the system can beanalyzed using the Petri net theory and analytical tools [63],[64].However, the purpose of Petri net techniques is not to pro-

vide an engineering blueprint of system design, but primarilyto study the concurrent events in system operation. Thesynthesis rules of Petri nets do not enforce a discipline forconstruction of modular, well-structured models which are

ability. Petri net techniques are not supported by a simple-to-use algebraic system, e.g., as Boolean algebra for hardwarelogic design, to facilitate a formal manipulation of the equiva-lent graphical representations. Also, they do not offer astraightforward approach to a formal proof of design cor-rectness, and the analysis of Petri net models is too complexto be practical for software engineers.The main concepts of Petri nets and their various extensions

and subclasses, as well as their various features and limitations,provide a few basic ideas for developing a scheme of softwaredesign representation which satisfies the criteria for softwareengineering blueprints.

IV. DEVELOPMENT OF ABSTRACT PROCESS NETWORKSA. Abstract Process ConceptThe external environment in which a system operates and

with which it interacts is assumed here to be that part of themedia which provides all system stimulations and absorbs allsystem responses. An image of its external environment andthe current state of a system can be represented through a setof system variables. A system state space is an n-dimensionalvector space defined on system variables. A system state is apoint of state space defined by a vector of values assumed bysystem variables. Any assignment operation on system vari-ables corresponds to a transition from one system state toanother (possibly the same one).The enumeration of all possible system states is neither

practical nor necessary. The important thing is to determinewhether a value of some variable satisfies a particular condi-tion, so that an appropriate action can be taken. Usually, wediscriminate not between individual states but between setsof system states, where a set is specified by a predicate onsystem variables. The system's activity can be described as asequence of states or as a sequence of operations. However,the same state transition may be produced by different opera-tions, while the same operation may lead to different statesat different times. Therefore, a complete representation of adiscrete phase of system activity requires one to specify notonly the set of operations performed during that phase, butthe corresponding initial and final states as well.An abstract process (AP) is a representation schema for a

discrete phase of system activity directly associated with somefunction and identifiable by the initial and final states withrespect to that function. (The word "abstract" reflects theassociation with a formal schema of system representation,and not with any actual system in particular. The conceptof a process, however, may have different interpretations indifferent contexts [65].) Formally, an abstract processschema is a quintuple P = <A,I, F, 0, Z>, where A =theinitial state set, I = the input set, F = the process function,O = the output set, and Z = the final state set.A graphical representation of the abstract process schema

is illustrated in Fig. 1. The main feature of this representa-tion is the orthogonality of control (A - F - Z) and data(I - F - 0) flows through the function of AP. This functioncan be represented hierarchically, in terms of the lower levelabstract processes, while at the highest level of abstraction the

423

free from the problems of conflicts, safeness, and reach-


Fig. 1. Abstract process representation.

whole system can be represented by a single AP. Since an APschema is finite by definition, an apparently continuous op-

eration of some systems can be described by a sequence offinite processes at the next lower level of representation.The basic properties of abstract processes, a formal approach

to their decomposition, and the algebraic system for their ana-

lytical representation are presented in [66]. Here, we providea short summary of the algebraic system of abstract process

expressions as the necessary background for the developmentof equivalent graphical forms. To simplify the notation, an

abstract process is denoted by a single letter which is uniquewithin a given set of abstract processes.

1) P = ab denotes a sequential decomposition (in general,not commutative) of process P into process "a" followed byprocess "b" so that

A(P)=A(a), Z(P)=Z(b), Z(a)CA(b).

2) P = a + b denotes a selective decomposition (commuta-tive, unless a specific test sequence is required) ofP, where theinitial state sets A(a) and A(b) constitute a partition of theinitial state set A(P), i.e.,

A(P) A(a) U A(b), A(a) n A(b) = 0.

Note: Sequential decomposition is not distributive over

selective decomposition; however, the inverse is true, i.e.,

P = a(b + c) #ab + ac, butP = (a + b) c =ac + bc.

(P ab + ac because A(ab) = A(ac) = A(a) is not a partitionofA(P).)3) P = a*b, (a b, b 0) is an iterative schema, where "a"

denotes a finite (possibly empty) sequence of occurrences ofprocess "a" always followed by exactly one occurrence ofprocess "b," e.g., a*, aa*, a*a are not process expressions.4) P = a Ib denotes a concurrent occurrence of processes "a"

and "b," i.e., aIb is definable if, and only if, ab = ba (a com-

mutative case of a sequential decomposition).5) P = aP + b is a recursive schema of abstract process P

represented in terms of component processes "a" and "b."6) "a" denotes an identity process specified by a single set

of states, i.e., a = <A = Z #0,F = I = 0 = O>.Note: In case of a selective decomposition, an identity pro-

cess is equivalent to a skip or exit operation. In case of a

sequential decomposition, it explicitly represents the initialset of its successor, or the final state set of its predecessor.

Therefore, a sequential identity process is denoted by a specialsymbol 'y.7) "O" denotes an empty process, i.e., a + 0 = a and Ob =

bO =0. However, O*b =y*b = yb = b.

B. GeneralApproachThe main approach undertaken here toward the formulation

of abstract process networks (AP-nets) is to augment the fimitestate machines, as the simplest subclass of Petri nets, with asufficient degree of modeling power and application con-venience while making them free of decision conflicts. Inorder to achieve a properly nested, hierarchical structure ofAP-nets and to simplify their analysis, the intention is toadapt the concepts of structured programming [26] to thesynthesis rules of AP-nets. The first step in this approach is torepresent the basic constructs of structured programming, alsoknown as D-charts (D for Dijkstra) [67], in terms of finitestate machines. Then, based on the analysis of these models,the next step is to define an appropriate set of primitives andconstruction rules necessary to formulate the AP-nets.The main reason for considering D-structures is their theo-

retical completeness in representing the flow of control as-sociated with the realization of computing algorithms, asdemonstrated by Bohm and Jacopini [67]. Over the years, anumber of theoretical results have been presented on thelimitations of various control structures, placing this issue on afirm foundation [27]. Another reason is that the principlesof structured programming can also provide a simple mecha-nism to enforce a discipline over creativity during the designprocess.The basic D-structures and their finite state equivalents are

shown in Fig. 2. Although the finite state models represent adirect relationship between the states and transitions, themain problem is that the translation of decision points in D-structures results in a conflict situation. Therefore, the nextstep is to modify the finite state representation so that alogic of decision making can be shown explicitly and withoutconflicts.

C. Sequential SchemaAssuming that each place in a Petri net corresponds appro-

priately to the initial or to the fmal state set of an abstractprocess, and each transition corresponds to a process func-tion, then Fig. 2(a) essentially represents a sequence of twoabstract processes. Since each transition corresponds to a setof operations performed on the elements of a system statevector, it is preferable to represent such a transformation bya rectangle than by a bar. This change not only helps to as-sociate a finite time requirement for each state transformation,but is also consistent with a traditional representation of op-erations using a "processing box."A transition, represented by a rectangle, is called a state

transformation transition. It represents a function of an ab-stract process, and therefore, may have only one input placeand one output place. A predicate associated with the inputplace of a state transformation transition is called a precondi-tion of state transformation. Similarly, a predicate associated

424


r- - -

L__

Fig. 2. AP-net model of process selection.

with the output place of a state transformation transition iscalled a postcondition. (This terminology is consistent withHoare's axiomatic basis for computer programming [69].)

D. Selective SchemaFig. 2(b) corresponds to a selective decomposition of ab-

stract processes. However, the finite state model in this casefails to represent the disjunctive logic of the initial state setpartitioning. (This is a typical conflict problem of Petrinets where two transitions share the same input place.) Theevolution of this representation into an explicit form is illus-trated in Fig. 3. Fig. 3(a) is equivalent to a representation ofan abstract process which is to be selectively decomposed asshown in (b). In Fig. 3(c) this decomposition is representedas a network of abstract processes. A logical relationshipamong the abstract processes is expressed by means of a newtype of a transition, called a state definition transition. It isrepresented by a bar and a corresponding logical operatorplaced in a small circle to indicate input or output logic, asappropriate. The firing rules of a state definition transitionare determined by its logic. For example, a state definitiontransition with multiple disjunctive inputs and a single outputbecomes enabled when only one of its input places receives atoken. Firing of this transition moves a token from themarked input place to the output place.A position of a token corresponds to a current system state,

i.e., a token.represents a system state vector. Each place rep-resents a set of system states specified by means of a predicate.Therefore, in case of a disjunctive output logic, a token movesto a place which corresponds to a current system state. Astate definition transition always indicates a shift from onehierarchical level to another, i.e., a creation or a terminationof some abstract process.The abstract process network in Fig. 3(c) illustrates also

the capability to represent a hierarchical structure of abstractprocesses. A rectangle (shown by dashed lines), which en-closes a part of that structure between the two state defmi-tion transitions, is nothing else but a state transformation

Fig. 3. AP-net model of process iteration.

transition of a parent abstract process. Therefore, eachmatching pair of state definition transitions encloses a rep-resentation of an abstract process at a lower hierarchicallevel.

E. Iterative SchemaFinally, let us consider the fmite state model of the iterative

construct, as shown in Fig. 2(c). In addition to the same con-flict problem, as in the case of a selective structure, a sharedinput place is also the output place of the iterated transition.Fig. 4 illustrates construction of an AP-net to represent aniterative structure starting from its finite state model shown in(a). As in the case of selective schema, the conflict problem isresolved by means of a state definition transition as shown inFig. 4(b). However, there are still other problems to be solved.

First, the representation in Fig. 4(b) fails to show explicitlya hierarchical structure of abstract processes. That is, therepresentation of a parent process is not complete. This prob-lem can be also solved with the help of another state definitiontransition using the property of the iterative scheme P = a*b,according to which the final state sets of a parent process andprocess "b" are equal.The last problem is that the final state set of process "a" is

shown as the initial state set of a parent process. It is im-portant to note here that, although the two sets are equal,they cannot be represented by the same place, since everytermination of process "a" would imply another occurrenceof a parent process. To remedy this problem, the final stateset of process "a" is represented by a place marked with anasterisk "*". This mark means that the place represents astate set which is equal to the initial state set of the corre-sponding parent process.The AP-net representation of the iterative construct is shown

in Fig. 4(c). The final state set of process "a" is marked byan asterisk, with no arcs originating from this place. A dashedline is only used to illustrate the convention that a tokenreaching a place marked with an asterisk must be removedfrom that place to pass again through the decision logic of

425

(:::.DI 1+1 I

(:::::DJct)


P=aP+4

,___ __

P-a b -

Fig. 4. AP-net models of D-structures.

P-a-b

a-O*bFig. 5.

the initial state definition transition. Since the position of a

token corresponds to the current system state, the token isthen moved to the corresponding initial state set.

F. Summary ofAP-Net ConstructsFig. 5 provides a summary of results obtained during the

translation of D-structures into abstract process networks.Each construct can be represented using two equivalent forms,i.e., analytically and graphically, so that the advantages of eachform can be readily utilized. The generalization of AP-netstructures for any number of abstract processes is straightfor-ward using the following process expressions:

1) Sequence: P = abc ... k2) Selection: P=a+b+c+s--+k3) Iteration:

P=(a+b+c+**.+k)*(l+m+n+** .+q).

The completeness of AP-nets is not only implied by the

Fig. 6. Recursive and concurrent AP-nets.

theoretical completeness of D-structures, but can be alsodemonstrated by their generality to represent recursive andconcurrent structures of abstract processes. The construc-tion of AP-nets for these forms follows directly from thecorresponding process expressions, as shown in Fig. 6. Adouble line rectangle is used only as a visual aid to point outa recursive structure. Similarly, a dashed line is a reminderof a hierarchical nature of AP-nets.

V. SPECIFICATION OF AP-NETSA. Elements ofAP-NetsFormally, an abstract process network (AP-net) is a di-

rected graph with all nodes partitioned into two disjointsets: a set of places P and a set of transitions T, such thatan arc can be directed from an element of either set onlyto an element of the other set. The set of transitions T ispartitioned into a subset DC T of state defimition transi-tions and a subset F C T of state transformation transitions.A relationship between the places and the transitions is de-fined by a set of mappings M. In addition, all places andtransitions are defined with respect to a system state vectorV of variables, including an independent time variable t.Therefore, any AP-net N can be defined by a four-tupleN= <P, T,M, V>.A place pi EP, represented graphically by an ellipse, cor-

responds to a set of system states satisfying certain condi-tions imposed on the elements of a system state vector V, and,therefore, is associated with a predicate which specifies thecorresponding set of states. Any place in an AP-net mayhave only one input transition and only one output transi-tion. Because of this restriction AP-nets are free of conflicts.A transition d, ED, represented graphically by a bar, is

called a state definition transition. The input-output rela-tionship between all places directly associated (connected)with the same state defimition transition may be either one-to-n or n-to-one, where 1 < n 6 p - 2 and p is the total num-ber of places in the AP-net. A logical relation between multi-ple input or output places with respect to the same state

426


definition transition is represented by an appropriate symbolenclosed by a small circle. This representation is an integralpart of a state definition transition, and therefore, should notbe considered as a separate element of AP-nets.A one-to-n state definition transition may also be called a

state analysis transition, since it defines a set of system statesin terms of specific subsets, each corresponding to a particularcondition. Similarly, an n-to-one state definition transitionmay be called a state synthesis transition. A state analysistransition identifies a particular subset of states, of which thecurrent system state is an element, so that a token can betransferred to the corresponding place enabling a specificstate transformation transition which performs the requiredaction. A state synthesis transition is used to define a setof system states summarizing the results which could be pro-duced by the corresponding set of actions.A state definition transition represents a particular decision

making process in the system's activity requiring a finite timeinterval. A state analysis transition may extend a system statevector by declaring and initializing additional (temporary)variables, so that each subset of system states can be definedin terms of specific conditions. A state synthesis transitionsynchronizes the arrival of tokens from concurrent inputplaces, as defined by its input logic, contracts a system statevector by removing all temporary variables, and then movesa token to the output place.To each state analysis transition in the AP-net there always

corresponds a unique state synthesis transition, and there-fore, the total number of state definition transitions in anyAP-net is even. Each matching pair of state definition transi-tions identifies a subnetwork at the next lower hierarchicallevel, so that the analysis of an AP-net can be performed atany level of detail. Also, the overall analysis is greatly sim-plified, since each subnetwork can be analyzed independently.In this respect, a matching pair of transitions is similar to amatching pair of parentheses in algebraic expressions.A state transformation transition fi E F, represented by a

rectangle, corresponds to some action specified in terms ofoperations on the elements of a system state vector. A statetransformation transition always has a single input place and asingle output place. A transition becomes enabled when itsinput place receives a token. Firing of the transition removesa token from the input place and keeps it inside the transitionuntil its termination. Then a token is moved into the outputplace indicating the results of a state transformation.State transformation transitions can be used to represent var-

ious actions at different levels of abstraction. At the lowestlevel, a state transformation transition can be used to representa simple operation on the elements of a system state vector.At the highest level, a single state transformation transitioncan represent a function of the whole system. The process ofabstraction of AP-nets is based on the identification of match-ing pairs of state definition transitions and replacement of apart of the AP-net enclosed by each such pair of transitionsby a corresponding state transformation transition.Since at the highest level of abstraction an AP-net consists

when the input place receives a token. That is, the concept ofinitial marking is not significant with respect to the AP-netsbecause of the existence of unique initial and final places inevery AP-net.The next element in the four-tuple specification of an AP-

net is a set of mappings M which defines a relationship be-tween the places and the transitions. For every transitionin an AP-net there corresponds an element ofM which speci-fies the input and output places associated with that transi-tion. Therefore, it is convenient to represent each element ofM by a triple

<input (s), transition, output (s)>.

The first element of a triple specifies the input places to atransition, the second element identifies the transition itself,and the third one specifies the output places from that transi-tion. The logical relationship between the places is shown byappropriate symbols. For example, a triple <p3, d3,p4 + p5>denotes a mapping from a place p3 to a state definition transi-tion d3, the output of which is the exclusive selection ofplaces p4 or p5.The last element of the AP-net quadruple is a system state

vector V which defines a set of system variables. Initially, thisvector includes only those variables which are known ex-temally with respect to a given AP-net. During the executionof an AP-net this vector may be extended with additional(temporary) variables when the lower level processes arecreated, and then contracted again when those processes areterminated. An n-tuple of values assumed by the n variablesof the vector V at any time t defines a state of the system atthat time. A system state vector is associated with a token,and therefore, the position of a token in the AP-net indicatesits current state. Since no more than one token can ever bein any place of the net at the same time, the AP-nets arebounded and safe.However, the total number of tokens during the execution

of an AP-net is not necessarily equal to one or is kept con-stant. That is, the total number of tokens indicates the num-ber of concurrent processes being active at any particulartime. Termination of the concurrent actions is synchronizedby the corresponding state synthesis transition. This transi-tion becomes enabled only after termination of all statetransformation transitions in a concurrent set. Then, fiingof the state synthesis transition removes all the tokens fromits input places and puts a single token into the output place.Since a state analysis transition can extend a state vector

with additional (temporary) variables which are removed laterby the corresponding state synthesis transition, the size of asystem state vector is not constant during the execution ofAP-nets. That is, a system state vector V in the AP-net qua-druple initially includes only those variables which are knownextemally to the system, while a complete specification of Vis distributed over the set of all state definition transitions.

B. Specification ofAP-Nets-ExampleThe basic concepts of AP-nets and their formal specifica-

tion can now be illustrated by a simple example. Let N be

427

of one state transfonnation transition with a single input placeand a single output place, the execution of a network begins


an AP-net defined by the quadruple <P, T,M, V>, whereeach element is specified as shown in Fig. 7.

Fig. 8 represents the same AP-net in a graphical form. Al-though the graphical form contains much less informationthan the corresponding formal specification, it almost in-stantly communicates the structural aspects of the given net-work. That is, the identification of abstract processes andthe formulation of process expressions to represent theirrelationship can be done by a simple visual inspection ofthe network structure. However, since a formal specificationallows one to automate the analysis process, the advantagesof analytical representation become more obvious with largernetworks.A specification of each identified abstract process can be

derived from definitions of the corresponding places andtransitions of the network. For example, an abstract pro-cess "c," as indicated in Fig. 8, corresponds to a mapping<p3, f2, p5>, and therefore, can be specified as

process c: (y > 0A x = uUY)[x := x*u;y :=y -1(y>0A x = u-Y).

The initial and final state sets of an abstract process arespecified by the predicates of the corresponding input andoutput places, respectively, while its function is defined bythe corresponding state transformation transition. (Thisnotation is also consistent with the concept of guarded com-mands introduced by Dijkstra [70], [71] .) In case of a higherlevel process, such as process "b" in Fig. 8, its function can bespecified in terms of lower level processes, e.g.,

process b: (v > 0)[var x: real,y: integer;

x := I;y :=v;processc*d;](z uV).

C. Practical ConsiderationsIn general, the construction of AP-nets is similar to a flow-

charting technique, due to a direct relationship between thebasic AP-net constructs and D-structures, as summarized inFigs. 5 and 6. However, a formal definition of the AP-netprimitives allows a rigorous representation of system modelsin terms of relevant conditions, decisions, and actions. More-over, the formulation of AP-nets enforces a system modelingprocess to produce a very regular, hierarchical structure whichsimplifies the analysis process.The analysis of AP-net models includes the following major

steps. First, a given network must be checked as to whether itis indeed an AP-net and if necessary corrected appropriately.The second step is to identify and label all abstract processesin the given or (corrected) network and to reveal their hierar-chical relationships. The next step involves the specificationof each identified abstract process and the formulation of pro-cess expressions representing the structure of the AP-net. Fi-nally, a model should be simplified, if possible, and verifiedfor design correctness.Using the advantages offered by the hierarchical structure

of AP-nets, a formal proof of design correctness can be under-taken in a bottom-up direction. That is, it is necessary first toprove the correctness of each process at the lowest hierarchicallevel, then at the next level, and so on, until the correctness of

V = <var u,z: real; v: integer;> is a state vector.

P = {Cp1 p2*3 4 p10 P20 PY P4- P5 6- P7P1 (T)M

P2( > 0),

is a set of pLaces

P3: (y > OtAx = uv y)

P4 : (y = OAx = uv),

p (y > OAx = uvY),

P6: (z = X)

P7: (z = uV);

T{d1 d2, f1, f2, f3} is a set of transitions

d1: [var x: reaL; y: integer; x := 1; y v],

d2 Cdiscard x,y),

f(:Cread(u,v)3,

f2:Ex x*u; y := y-13,f3: tz x; writeLn(z)];

m={1 '2, '3, m4 mS} is a set of mappings

m1 =<P1P f1 P2>0n2 <P2, d, p3+p4>,

3 =<P3, f2' P5m4 =<p4, f3, P6>,

m5 =7<P6, d2m p7>;

Fig. 7. Example of AP-net specification.

C { od ib

N-a.b; b-c*d;N-a.c*d

Fig. 8. Example of AP-net representation.

the whole model is established [72]. Since the process expres-sions specify a set of all possible execution paths in the AP-netand since for each transformation along an execution pathboth the preconditions and the postconditions are explicitlyspecified by place predicates, a formal proof of design correct-ness [73] can be made practical through the development ofautomated tools. The benefits which can be derived from theuse of AP-net design representation in software testing andmaintenance are obvious for the same reasons.AP-nets are primarily intended for the representation of

large scale software systems in terms of the main functionalcomponents. However, since the basic constructs of AP-netsare consistent with the definition of D-structures, and, there-

428

-7a


fore, with the concepts of structured programming, the AP-net representation of any system component at the lowestlevel of abstraction can be made directly compatible with theimplementation in a high-level language, as shown in Fig. 9 forthe previously considered example. However, the scheme ofAP-net specification, where each abstract process can be de-fined separately, and where the overall network structure canbe independently described by process expressions, suggeststhe new approach to the design of programming languages.This approach can also simplify the design of language com-pilers, since there will be no need to scan all source code toreveal its structure.

VI. AP-NET CONSTRUCTION METHODSFor the use of any formal technique, there is a need for a

formal specification interposed between the system conceptand its design. The purpose of a formal specification is to pro-

vide a mathematical description of what is to be designed so

that the correctness of the design can be established from itsequivalence to the specification [74]. Considering a growinginterest in finite state techniques for software design [75] -

[82], we present a few methods of AP-net construction usinga state transition diagram as a starting point. A state transitiondiagram is a simple tool to denote the main system states andtransitions, in terms of which a system concept can be for-mally represented. However, it is neither practical nor neces-

sary for this initial state diagram to be of a structured type,e.g., as defined in [82]. What must be structured is the repre-

sentation of design to simplify system implementation, testing,and maintenance.

A. Interpretation ConventionsSystems which have been modeled as finite state machines

are usually called stimuli-driven, i.e., those which are drivenby external inputs [80]. The finite state machines used inthese models are known as transition assigned, or Mealy ma-

chines [42], where the next state and output are determinedby the present state and input. Here, we generalize the notionof stimuli to be any condition or circumstance which leads toa state transformation activity. Also, the interpretation ofstate transition diagrams is made consistent with the definitionof abstract processes.According to conventional interpretation, each phase of sys-

tem activity is associated with the corresponding state in a

state transition diagram. However, in our case, a system stateis a point in the system state space, and therefore, does notspecify any particular action. A circle in a state transitiondiagram represents a set of system states satisfying a particularcondition. Thus, a statement that a system is in a state ofdoing something means in our interpretation that this activityis represented by the corresponding transition associated withthat state. (Such a transition usually forms a loop.)All system activity is represented by means of state transi-

tions, where each transition denotes some abstract process.

Therefore, a transition is specified by a triple:

(precondition) [transformation] (postcondition)

where a "precondition" is defined as the weakest predicate

program exponent(input, output);

varU, z, x: reaL;

v, y: integer;

begin

read(u, v);

x 1;

y : ;

while y > 0 do begin

x x * U;

y y - 1

end;z := x;

writeln(z)

end .

Fig. 9. Example of AP-net implementation.

in the context of Dijkstra calculus [71], and a "transforma-tion" defines a set of operations (including input and output)on the elements of a system state vector. The concept ofguarded commands [70], while receiving an increasing pop-ularity [84], [851, is also consistent with our formulation ofabstract processes, and therefore, offers the advantage ofalready available theorems for the derivation and formalproof of system designs [73]. It should be noted, however,that in our case there is no need for the awkward "do... od"and "if... .fi" constructs, since the structure of abstract pro-cesses can be conveniently represented by process expres-sions, while each process can be specified by a guarded com-mand and denoted by a simple algebraic term.Assuming that a system concept is formally represented by

a state transition diagram, and using the above outlined con-ventions of interpretation, let us consider the aspects of AP-net construction during the system design phase. Fig. 10illustrates a simple state transition diagram which provides ahigh-level representation of system operation. For con-venience, this diagram is arranged so that all transitions entereach state at the top and leave it at the bottom.

B. GraphicalMethodThe first step in the graphical construction of an AP-net is

to identify all state- definition and transformation transitionsas indicated by dashed lines in Fig. 10. Next, a diagram istransformed into an intermediate form, where each state hasexactly one input and one output, and where all transitionsare explicitly represented. Then a diagram is analyzed toidentify all matching pairs of state definition transitions, sothat all abstract processes and their hierarchical relationshipcan be explicitly represented (see Fig. 11). Next, the structureis corrected by adding the missing state definition transitionsand by splitting the paths sharing common processes.The fmal result is shown in Fig. 12, where the AP-net repre-

sents an iterative part of some process at the higher hierar-chical level, since the original state transition diagram containsa cycle. Obviously, the manual procedure of AP-net deriva-tion is not attractive, especially for the more complex diagrams.

429


Fig. 10. System state transition diagram.

r-~-I _ _ _

I

I I a IdI

II

I r--

I I

I II I

I II I

Fig. 11. Identification of abstract processes.

C. AlgebraicMethodAnother approach is based on the algebraic properties of

abstract processes. This method requires one to find a regularexpression for a given state transition diagram, from which theequivalent process expressions can be derived. The construc-tion of AP-nets from process expressions is straightforward.Derivation of regular expressions from state transition dia-

grams is based on the results of Kleene's theorem [86], the

N (a + b(d +e f)h+c f h)*Q

Fig. 12. AP-net representation of system design.

first part of which states that for every transition graph thereexists a regular expression. A regular expression can be ob-tained by using a graphical method of state elimination [86],or by using a table of derivatives as described in [87]. Thefirst method is relatively simple, but requires for each stepto perform a visual inspection of the graph to figure out theresults of each state elimination and to draw a new graph forthe next step. The second method is too complex to be prac-tical for any alphabet consisting of more than two symbols.Here, we offer an automated version of the first method

using a connectivity matrix C, where every element ci1 denotesa transition from state "i" to state "j." First, a given transitiongraph is converted into a generalized transition graph, as de-scribed in [86], by adding a unique pair of initial and final states(x and y). Then, a connectivity matrix is constructed so thateach row corresponds to a "from state" and each column to a"to state." Since the initial and fmal states are not associatedwith "from" or "to" states, respectively, the connectivitymatrix is an (n - 1) X (n - 1) square matrix, where n is thetotal number of states in a generalized transition graph. Foreach element cii we use the following conventions.

1) If a, b, c, , k are transitions from state m to state n,thencmn=a+b+c+ * *+k.2) If there is no any direct transition from state m to

state n, then Cmn = 0Fig. 13 illustrates a generalized state transition graph for the

previous example (Fig. 10) and the corresponding connectiv-ity matrix. Since the method is based on the stepwise elimina-tion of states, each step results in the reduction of the matrix

430


y

h 2,d f

1 2 3 4 Yx Y ed00O

2 01oOle dio3 0 01 f 0 i

41 h |o 0 0

Fig. 13. Graph connectivity matrix.

by a row and a column, corresponding to each eliminated state"i," while each element Cjk of the matrix is updated (to in-clude all indirect transitions from state "j" to state "k" viastate "i") according to the following expression:

CGk ' Cjk + Cii(Cii)*Cik.where "i" is a state to be eliminated, and "i" is neither theinitial nor the final state.Since the total number of states is finite, and with each step

this number is reduced by one, the process terminates with asingle element matrix representing the regular expression for agiven transition graph. The next step is then to simplify theresult, using the identities of regular expansions, and to trans-late it into equivalent process expressions. (The translation isbased on the axioms of the abstract process algebra [66].)For example, a state elimination sequence 4-3-2-1 generates aregular expression

[a + cf*gh + b(dh + ef*gh)] *

which after simplification produces the same result as shownin Fig. 12. However, the reader is invited to try this algorithmwith different sequences to show that the final result is notnecessarily unique, and in general, its complexity depends onthe particular sequence of state eliminations. The to/fromtransition ratio of each state, as well as the precedence rela-tion on the set of all states, are the primary factors to be con-sidered in selecting a particular sequence of state eliminations.

D. StateArbitrationMethodFinally, we offer a very simple and consistent method of

AP-net construction using the concept of state arbitration.The principle is based on the explicit indication of the nextstate at the end of each state transformation transition. Thatis, with each transition in a given state transition graph weassociate, as before, an abstract process which performs thecorresponding transformations. However, at the time oftermination, each process sets a special variable in the systemstate vector to indicate the next state of the system.At the next higher hierarchical level, we associate an ab-

stract process with each state in a given state transition dia-gram. Each process at this level is selected based on theevaluation of the next state variable performed by the ab-

stract process at the level of a state transition diagram. Fig.14 illustrates an AP-net structure for a state transition dia-gram of Fig. 10 using the concept of state arbitration.

E. Representation ofControl and Data Flows

In the formulation of the abstract process concept, theintersection of control and data flows is the central pointover which the function of each abstract process is specified.The main approach to the formulation of AP-nets has beenbased on the consideration of control flow in the representa-tion of abstract process structures. However, because of theorthogonality of control and data flows in the abstract pro-cess model, the same principles can be used to construct anAP-net representing system characteristics in terms of dataflow. That is, for the same system it is possible to constructtwo AP-net models, one for control flow and one for dataflow.Depending on the nature of a particular system, it may be

sufficient to consider the aspects of system modeling in termsof a single kind of flow, either control or data. But in a gen-eral case, the aspects of control and data flows may be equallyimportant for a complete representation of system behavior.However, the main problem is that, no matter how completeeach model may be, the use of two separate models, besidesbeing inconvenient, lacks representing explicitly a complex re-lationship between control and data entities in actual systems.The problem of simultaneous representation of control and

data flows is not new. For example, this problem appears tobe obvious in the discussion of LOGOS [88], where it hasbeen suggested to use two separate graphs. The formulationof computation structures [17] is also based on two separategraphs, due to the lack of a better solution. The same prob-lem has been mentioned in the formulation of E-nets [54],where data are represented as attribute values of tokens whichmay change as the tokens flow through the net. This featureis provided in AP-nets where a token represents a system statevector.In the construction of a Petri net model for a parallel com-

piler, as discussed in [59], the authors share the same opinionthat the important quality of a modeling tool is to be descrip-tive of both the control and data flows. In their approachtoward a single graph model, a data operator, associated witha particular transition, provides a visual aid in the interpreta-tion of a network. In this respect, an AP-net model providesa definite advantage, since all operations on data are definedin the formal specification of each state transformationtransition.Although AP-nets provide a partial solution to a simultaneous

representation of control and data flows, in case of interact-ing concurrent processes this solution may still be inadequate.In this case, an AP-net model can be extended to include anappropriate representation of interaction between the cor-responding state transformation transitions using any suitabletechnique. For example, as shown in Fig. 15, a simple Petrinet model can be used to represent locally the interaction be-tween the concurrent processes. A communication path canbe also represented by a data flowgraph as defined in computa-tion structures [17].

431


I

Ir - --- ---I r--II I III I I

I _ III II (

I I II 39

Fig. 14. AP-net with state arbitration.

_ _ _ _ _ _ _. _ __J

Fig. 15. Interaction of abstract processes.

A fornal basis for adding any representation of data flowto a control-oriented AP-net is provided by the definition ofan abstract process model. That is, every state transformationtransition in the AP-net corresponds to a function of some

abstract process with its input and output sets connected alongthe direction of data flow. Therefore, a state transformationtransition allows the interconnection of control and data flowsin AP-nets. This feature of AP-nets facilitates the use of dif-ferent representation schemes to provide additional means ofexpression in special cases, if necessary.

VII. CONCLUSIONSThe form of software design representation is the key in-

strument for the introduction of engineering discipline intothe software design process. In engineering, the form ofdesign representation is associated with the concept of a

blueprint. The most important aspect of a real engineeringblueprint is that it is not just a form of documentation or

specification. An engineering blueprint is a particular formof design representation which can be used to model thelogical structure and dynamic behavior of a system throughthe combination of analytical and graphical techniques.In this paper we have presented a formal scheme of soft-

ware design representation which is consistent with the con-cept of engineering blueprints. An overview of Petri nettechniques has been used to derive a few basic ideas and topoint out some problems to be solved while taking a net-work approach to the development of a software designrepresentation scheme. The concept of an abstract processhas been introduced as the basic element of system model-ing. An abstract process represents a discrete phase of sys-tem activity associated with the transformation of identifiablesystem states. An abstract process is defined by a quintupleof sets, and therefore, a number of key features can be simplydefined as a relation on these sets. An important property ofan abstract process is based on the orthogonality of controland data flows. The analysis of set relationships along eachflow provides a formal approach to process decomposition.The main result of the proposed approach is the formula-

tion of abstract process networks (AP-nets) which incorporatethe basic concepts of structured programming, finite statemachines, and Petri nets. The construction rules of AP-netsassure a well-defined, hierarchical structure of system modelswhere all abstract processes can be easily identified and rep-resented by process expressions. Practical methods of AP-net construction have been presented and illustrated byexamples.The AP-nets may be considered as a structured version of

Petri nets, with the advantages of explicit representation ofdecision logic and a simple algebraic notation. Moreover,AP-nets are free of conflicts, safe, live, and easy to analyze.Since AP-nets can represent a system hierarchically, i.e., atany level of detail, the range of their applicability can extendfrom the specification of system requirements to the imple-mentation and maintenance. This feature can simplify thetransitions from one phase to another in the software lifecycle.The AP-nets are consistent with the majority of existing rep-

resentation schemes, and therefore, can be easily convertedinto other forms such as flowcharts, flowgraphs, state transi-tion graphs, decision trees, structure charts, etc. Moreover,there exists a close similarity between the control flow portionof an abstract process, Dijkstra's guarded commands, and the

432


condition/action rules of decision tables. In terms of hierarchi-cal nesting, AP-nets are similar to Nassi-Shneiderman charts,while the data flow portion of abstract processes includes theconcept of input-process-output in HIPO diagrams. This uni-versality of AP-nets simplifies the use of different method-ologies, and therefore, facilitates the integration of availabletechniques into a systematic engineering discipline.The AP-net scheme of software design representation offers

a number of interesting features and capabilities. However,their effective utilization requires a continuing researcheffort. Besides the development of specific design method-ologies, the set-theoretic model. of system representationneeds further refinement toward the identification of sys-tem states and functions. Also the algebraic system of AP-net representation needs further development to simplifythe analysis and manipulation of process expressions.The formulation of AP-net structures, and their consis-

tency with Hoare's axiomatic basis for computer program-ming and Dijkstra's calculus, offer a number of features re-quired in the formal proof of design correctness. Therefore,to take advantage of these properties requires further re-search. Finally, the explicit separation of the system struc-ture representation (in the form of process expressions) fromthe specification of processing functions of each abstract pro-cess, which provides a definite advantage in the analysis andmodification of system design, also suggests considering a dif-ferent approach to design implementation.Although any AP-net design, at the lowest level of abstrac-

tion, can be directly implemented using general-purpose high-level languages, the particular advantage of process expressionsfor explicit representation of system structure can be utilizedonly through the development of special languages and systemarchitectures "liberated from the von Neumann style" [89].

REFERENCES

[ 1] R. E. Fairle, "Modern software design techniques," in Proc. MRISymp. Comput. Software Eng., 1976, pp. 11-30.

[2] L. J. Peters and L. L. Tripp, "Companing software design method-ologies," Datamation, pp. 89-94, Nov. 1977.

[3] R. C. Tausworthe, Standardized Development of Computer Soft-ware. Englewood Cliffs, NJ: Prentice-Hall, 1977.

[4] Infotech State of the Art Report, Software Engineering Tech-niques, vols. 1, 2. Infotech Int., 1977.

[5] Infotech State of the Art Report, Structured Analysis and De-sign, vols. 1, 2. Infotech Int., 1978.

[61 P. Freeman and A. I. Wasserman, Software Design Techniques,2nd ed. New York: IEEE, 1977.

[7] C. V. Ramamoorthy and R. Y. Yeh, Tutorial: Software Method-ology. New York: IEEE, 1978.

[8] W. Myers, "The need for software engineering," Comput., vol.11, pp. 12-26, Feb. 1978.

[9] C. A. R. Hoare, "Software engineering: A keynote address," inProc. 3rd Int. Conf Software Eng., May 1978, pp. 1-4.

[10] D. T. Ross, "Structured analysis (SA): A language for com-municating ideas," IEEE Trans. Software Eng., vol. 3, pp. 16-34, Jan. 1977.

[11] A. I. Wasserman et al., "Software engineering: The tumingpoint," Comput., vol. 11, pp. 30-41, Sept. 1978.

[12] A. I. Wasserman and P. Freeman, "Software engineering educa-tion: Status and prospects," Proc. IEEE, vol. 66, pp. 886-892,Aug. 1978.

[13] P. Freeman, "Software design representation: A case study,"Software Practice and Experience, vol. 8, pp. 501-512, Sept.-Oct. 1978.

[14] I. Greif, "A language for formal problem specification," Com-mun. Ass. Comput. Mach., vol. 20, pp. 931-935, Dec. 1977.

[15] A. C. Shaw, "Software descriptions with flow expressions,"IEEE Trans. Software Eng., vol. SE-4, pp. 242-254, May 1978.

[161 N. Chapin, "Flowcharting with the ANSI standard: A tutorial,"ACM Comput. Surveys, vol. 2, pp. 119-146, June 1970.

[17] H. A. Sholl and T. L. Booth, "Software performance modelingusing computation structures," IEEE Trans. Software Eng.,vol. SE-1, pp. 414-420, Dec. 1975.

[18] U. R. Kodres, "Analysis of real-time systems by data flowgraphs,"IEEE Trans. Software Eng., vol. SE-4, pp. 169-178, May 1978.

[19] W. P. Stevens, G. J. Myers, and L. L. Constantine, "Structureddesign," IBM Syst. J., vol. 13, no. 2, pp. 115-139, 1974.

[20] J. F. Stay, "HIPO and integrated program design," IBM Syst. J.,vol. 15, no. 2, pp. 143-154, 1976.

[21] I. Nassi and B. Shneiderman, "Flowchart techniques for struc-tured programming," ACM SIGPLAN Notices, vol. 8, pp. 12-26,Aug. 1973.

[22] C. M. Yoder and M. L. Schrag, "Nassi-Shneiderman charts. Analternative to flowcharts for design," in Proc. Software Qualityand Assurance Workshop, SIGSOFT Notes, vol. 3, no. 5, Nov.1978, pp. 79-86.

[23] U. W. Pooch, "Translation of decision tables," ACM Comput.Surveys, vol. 6, pp. 125-151, June 1974.

[24] J. R. Metzner and B. H. Barnes, Decision Table Languages andSystems. New York: Academic, 1977.

[25] L. J. Peters and L. L. Tripp, "Software design representationschemes," in Proc. MRI Symp. Comput. Software Eng., 1976,pp. 31-56.

[26] E. W. Dijkstra, "Notes on structured programming," in Struc-tured Programming, O.-J. Dahl, Ed. New York: Academic,1972, pp. 1-81.

[27] H. F. Ledgard and M. Marcotty, "A genealogy of control struc-tures," Commun. Ass. Comput. Mach., vol. 18, pp. 629-639,Nov. 1975.

[28] B. Schneiderman et al., "Experimental investigations of the util-ity of detailed flowcharts in programming," Commun. Ass.Comput. Mach., vol. 20, pp. 373-381, June 1977.

[29] L. A. Levental and W. C. Walsh, "Program design: Beware offlowcharting pitfalls," Digital Design, pp. 20-22, Nov. 1978.

[30] A. T. Cohen and L. S. Levy, "Structured flowcharts for multi-processing," Comput. Languages, vol. 3, no. 4, pp. 209-220,1978.

[31] U. R. Kodres, "Discrete systems and flowcharts," IEEE Trans.Software Eng., vol. SE-4, pp. 521-525, Nov. 1978.

[32] T. DeMarco, Structured Analysis and System Specification.New York: Yourdon, 1978.

[33] S. H. Caine and E. K. Gordon, "PDL-A tool for software design,"in Proc. Nat. Comput. Conf New York: AFIPS, 1975, pp.271-276.

[34] P. V. Leer, "Top-down development using a program designlanguage," IBM Syst. J., vol. 15, no. 2, pp. 155-170, 1976.

[35] Y. Chu, "Introducing software blueprint," inProc. COMPSAC '77,Nov. 1977, pp. 9-16.

[36] C. V. Ramamoorthy and H. H. So, "Software requirements andspecifications: Status and perspectives," in Tutorial: SoftwareMethodology. New York: IEEE, 1978, pp. 43-164.

[37] M. A. Jackson, Principles of Program Design. New York: Aca-demic, 1975.

[38] J. D. Warnier, Logical Construction of Programs. New York:Van Nostrand Reinhold, 1976.

[39] K. T. Orr, Structured Systems Development. New York: Your-don, 1977.

[40] S. S. Yau and C. C. Yang, "An approach to distributed comput-ing system software design," in Proc. Ist Int. Conf. DistributedComput. Syst., Oct. 1979, pp. 31-42.

[41] P. Lu and S. S. Yau, "A methodology for representing the formalspecification of distributed computing system software design,"in Proc. Ist Int. Conf. Distributed Comput. Syst., Oct. 1979,pp. 212-221.

[42] Z. Kohavi, Switching and Finite Automata Theory. New York:McGraw-Hill, 1970.

[431 B. W. Kernighan and P. J. Plauger, The Elements ofProgrammingStyle. New York: McGraw-Hill, 1974.

[44] R. D. Gordon, "Measuring improvements in program clarity,"IEEE Trans. Software Eng., vol. SE-5, pp. 79-90, Mar. 1979.

[45] M. R. Paige, "Program graphs, an algebra, and their implica-tions for programming," IEEE Trans. Software Eng., vol. SE-1,pp. 286-291, Sept. 1975.

[46] T. J. McCabe, "A complexity measure," IEEE 7rans. SoftwareEng., vol. SE-2, pp. 308-320, Dec. 1976.

433


[471 M. E. Stickney, "An application of graph theory to softwaretest data selection," in Proc. Software Quality and AssuranceWorkshop, ACM SIGSOFT Notes, vol. 3, Nov. 1978, pp. 111-115.

[48] D. T. Ross et al., "Software engineering: Process, principles, andgoals," Comput., pp. 17-27, May 1975.

[49] J. L. Peterson, "Petri nets," ACM Comput. Surneys, vol. 9, pp.223-252, Sept. 1977.

[501 J. L. Peterson, "An introduction to Petri nets," in Proc. Nat.Electron. Conf, vol. 32. Nat. Eng. Consortium, Oct. 1978,pp. 144-148.

[51] J. B. Dennis et al., "Computation structures: A. Petri nets,"M.I.T. Project MAC Progress Rep. VIII, pp. 13-23, July 1971.

[52] D. Misunas, "Petri nets and speed independent design," Com-mun. Ass. Comput. Mach., vol. 16, pp. 474-481, Aug. 1973.

[53] G. J. Nutt, "Evaluation nets for computer system performanceanalysis," in Proc. Fall Joint Comput. Conf., Dec. 1972, pp.279-286.

[54] J. D. Noe and G. J. Nutt, "Macro E-nets for representation ofparallel systems," IEEE Trans. Comput., vol. C-22, pp. 718-727, Aug. 1973.

[55] J. D. Noe, "Hierarchical modeling with pro-nets," in Proc. Nat.Electron. Conf., vol. 32. Nat. Eng. Consortium, Oct. 1978, pp.155-160.

[56] J.-L. Baer, "Models for the design, simulation and performanceevaluation of distributed-function architecture," in Proc. COMP-CON '74, Feb. 1974, pp. 81-84.

[57] E. E. Balkovich and G. P. Engelberg, "Research towards a tech-nology to support the specification of data processing systemperformance requirements," in Proc. 2nd Int. Conf SoftwareEng., Oct. 1976, pp. 110-115.

[58] C. Davis and C. Vick, "The software development system,"IEEE Trans. Software Eng., vol. SE-3, pp. 69-84, Jan. 1977.

[59] J.-L. Baer and C. S. Ellis, "Model, design, and evaluation of acompiler for a parallel processing environment," IEEE Trans.Software Eng., vol. SE-3, pp. 394-405, Nov. 1977.

[60] P. Azena et al., "Design and verification of communicationprocedures: A bottom-up approach," in Proc. 3rd Int. ConfSoftware Eng., May 1978, pp. 168-174.

[61] C. Whitby-Strevens, "Towards the performance evaluation ofdistributed computing systems," in Proc. COMPSAC '78, Nov.1978, pp. 141-146.

[62] T. Agerwala, "Some applications of Petri nets," in Proc. Nat.Electron. Conf., vol. 32. Nat. Eng. Consortium, Oct. 1978,pp. 149-154.

[63] W. L. Heimerdinger, "A Petri net approach to system level faulttolerance analysis," in Proc. Nat. Electron. Conf., vol. 32. Nat.Eng. Consortium, Oct. 1978, pp. 161-165.

[64] Y. W. Han, "Performance evaluation of a digital system using aPetri net-like approach," in Proc. Nat. Electron. Conf., vol. 32.Nat. Eng. Consortium, Oct. 1978, pp. 166-172.

[65] J. J. Homing and B. Randell, "Process structuring," ACM Com-put. Surveys,vol. 5, pp. 5-29, Mar. 1973.

[66] L. J. Mekly, "A systems approach to software design represen-tation," Ph.D. dissertation, Dep. Elec. Eng. Comput. Sci., North-westem Univ., Evanston, IL, 1979.

[67] H. D. Mills, "The new math of computer programming," Com-mun. Ass. Comput. Mach., vol. 18, pp. 43-48, Jan. 1975.

[68] C. Bohm and G. Jacopini, "Flow-diagrams, Turing machines,and languages with only two formation rules," Commun. Ass.Comput. Mach., vol. 9, pp. 366-376, May 1966.

[69] C. A. R. Hoare, "An axiomatic basis for computer programming,"Commun. AsS. Comput. Mach., vol. 12, pp. 576-580, 583, Oct.1969.

[70] E. W. Dijkstra, "Guarded commands, nondeterminacy and formalderivation of programs," Commun. Ass. Comput. Mach., vol.18, pp. 453-457, Aug. 1975.

[71] -, A Discipline of Programming. Englewood Cliffs, NJ:Prentice-Hall, 1976.

[72] J. M. Spitzen et al., "An example of hierarchical design andproof," Commun. Ass. Comput. Mach., vol. 21, pp. 1064-1075,Dec. 1978.

[73] D. Gries, "An illustration of current ideas on the derivation ofcorrectness proofs and correct programs," IEEE Trans. SoftwareEng., vol. SE-2, pp. 238-244, Dec. 1976.

[74] B. H. Liskov and S. Zilles, "Specification techniques for dataabstractions," in Proc. Int. Conf Reliable Software, Apr. 1975,pp. 72-87.

[75] D. M. Birke, "State-transition programming techniques and their

use in producing teleprocessing device-control programs," IEEETrans. Commun., vol. COM-20, pp. 569-575, June 1972.

[76] K. G. Salter, "A methodology for decomposing system require-ments into data processing requirements," in Proc. 2nd Int.Conf Software Eng., Oct. 1976, pp. 91-101.

[77] P. Chung and B. Gaiman, "Use of state diagrams to engineer com-munications software," in Proc. 3rd Int. Conf Software Eng.,May 1978, pp. 215-221.

[78] A. B. Ferrentino and H. D. Mills, "State machines and theirsemantics in software engineering," in Proc. COMPSAC '77,Nov. 1977, pp. 242-251.

[79] T. S. Chow, "Testing software design modeled by finite-statemachines," IEEE Trans. Software Eng., vol. SE-4, pp. 178-187, May 1978.

[80] -, "Analysis of software design modeled by multiple finitestate machines," in Proc. COMPSAC '78, Nov. 1978, pp. 169-173.

[81] J. V. Landau, "State description techniques applied to industrialmachine control," Comput., vol. 12, pp. 32-40, Feb. 1979.

[82] E. J. Wilkens, "Finite state techniques in software engineering,"in Proc. COMPSAC '77, Nov. 1977, pp. 691-697.

[83] L. C. Carpenter and L. L. Tripp, "Software design validationtool," in Proc. Int. Conf Reliable Software, Apr. 1975, pp.395-400.

[84] T. E. Lindquist and R. F. Keller, "The correctness of programswritten in the language KL-1," in Proc. COMPSAC '77, Nov.1977, pp.635-639.

[85] D. L. Boyd and A. Pizzarello, "Introduction to the WELLMADEdesign methodology," IEEE Trans. Software Eng., vol. SE-4,pp. 276-282, July 1978.

[86] Z. Manna, Mathematical Theory of Computation. New York:McGraw-Hill, 1974.

[87] A. Ginzburg, Algebraic Theory of Automata (ACM MonographSeries). New York: Academic, 1968.

[88] C. W. Rose, "LOGOS and the software engineer," in Proc. FallJoint Comput. Conf., Dec. 1972, pp. 311-323.

[89] J. Backus, "Can programming be liberated from thevonNeumannstyle? A functional style and its algebra of programs," Commun.Ass. Comput. Mach., vol. 21, pp. 613-641, Aug. 1978.

Leon J. Mekldy (M'76) received the M.S. degreein electrical engineering from the IMinois In-stitute of Technology, Chicago, and the Ph.D.degree in computer science from NorthwesternUniversity, Evanston, IL.He is presently a Senior R&D Engineer at

Teletype Corporation, Skokie, IL, where he isresponsible for design evaluation and certifica-tion of data communication systems and ap-plications software. With over 16 years of en-gineering experience in different areas of

analog and digital electronics, mobile radio communications, LSI MOSchip design, automated test systems, and data communication equip-ment, his current research interests include the hardware-softwarearchitecture of microprocessor-based systems, software engineeringmethodologies and standards, and computer communication networks.Dr. Mekly served twice on the International Advisory Panel of Elec-

tronics Magazine, and is a member of the IEEE Computer Society, theAssociation for Computing Machinery, and its Special Interest Groupon Software Engineering (SIGSOFT).

Stephen S. Yau (S'60-M'61-SM'68-F'73) re-ceived the B.S. degree from the NationalTaiwan University, Taipei, Taiwan, China,in 1958, and the M.S. and Ph.D. degrees fromthe University of Illinois, Urbana, in 1959 and1961, respectively, all in electrical engineering.He joined the faculty of the Department of

Electrical Engineering, Northwestern Univer-sity, Evanston, IL, in 1961, and is now Profes-sor and Chairman of the Department of Elec-trical Engineering and Computer Science. He

is currently interested in reliability and maintainability of computing

434


systems, software engineering, real-time systems, and pattern recogni-tion. He has published over 90 technical papers in these and otherareas. He is a Life Fellow of the Franklin Institute from which he re-ceived the Louis E. Levy Medal in 1963; he also received the GoldenPlate Award of the American Academy of Achievement in 1964. Hewas the President of the IEEE Computer Society in 1974-1975, theDivision V (Computer Society) Director of the IEEE in 1976-1977,and Chairman of IEEE Technical Activities Board Development Com-mittees in 1979. He has been a Director of the American Federationof Information Processing Societies since 1972 and is now a member

of the Executive Committee. He was the Conference Chairman ofthe First Annual IEEE Computer Conference, Chicago, 1967, the Gen-eral Chairman of the 1974 National Computer Conference, Chicago;and the General Chairman of the IEEE Computer Society's First In-ternational Computer Software and Applications Conference, Chicago,IL, 1977 (COMPSAC '77).Dr. Yau is a member of Association for Computing Machinery, the

Society for Industrial and Applied Mathematics, the American Associa-tion for the Advancement of Science, the American Society for Engi-neering Education, Sigma Xi, Tau Beta Pi, and Eta Kappa Nu.

On Deadlock Detection in Distributed Systems

VIRGIL D. GLIGOR AND SUSAN H. SHATTUCK

Abstract-A hierarchically organized and a distributed protocol fordeadlock detection in distributed databases are presented in [11. Inthis paper we show that the distributed protocol is incorrect, and pre-sent possible remedies. However, the distributed protocol remainsimpractical because "condensations" of "transaction-wait-for" graphsmake graph updates difficult to perform. Delayed graph updates causethe occurrence of false deadlocks in this as well as in some other dead-lock detection protocols for distributed systems. The perfonnancedegradation that results from false deadlocks depends on the charac-teristics of each protocol.

Index Terns-Deadlock detection, delayed graph updates, distributedsystems, false deadlocks, on-line protocols, ostensibly blocked transac-tions, out-of-order graph updates.

I. INTRODUCTIONA DISTRIBUTED SYSTEM consists of a collection of

processes which execute on spatially separated com-puters and which can communicate with one another by ex-changing messages. Such a system differs from a traditionalmultiprocessing system in at least two important ways: first,there is no globally shared memory, and second, the delaysin message delivery are not negligible when compared to theexecution time of a single process.In principle, protocols for deadlock detection in distributed

systems need not differ from the more traditional protocolsthat are used in centralized systems. In practice, however, lackof shared memory makes the construction and the mainte-nance of various graphs used for deadlock detection the sourceof significant bookkeeping and, possibly, of performance prob-lems. For example, fully distributed protocols for deadlockdetection may require that each site of the distributed system(i.e., each computer installation) construct and maintain a

Manuscript received June 14, 1979; revised December 12, 1979. Thiswork was supported by the National Aeronautics and Space Adminis-tration under Contract NAS 5-24407.The authors are with the Department of Computer Science, Univer-

sity of Maryland, College Park, MD 20742.

graph for deadlock detection [1], [2]. To ensure that eachsite maintains as accurate a view of the process and resourcestatus as possible, per-site concurrency controllers exchangemessages that cause additions and deletions of graph nodesand arcs. Arbitrary delays in message delivery may causedeletion requests for certain arcs to arrive at a site before themessages that would have caused the addition of those arcsto the local graph. "Out-of-order" graph updates do notappear in centralized systems because a single graph for dead-lock detection is constructed and maintained in physicallyshared memory.Most concurrency control mechanisms used in practice rely

on resource locking and deadlock detection protocols to en-sure consistency [3]. Renewed interest in distributed systemshas resulted in the publication of at least ten protocols fordeadlock detection. However, few of these_protocols are cor-rect and fewer appear to be practical. In this paper, we pointout that, unlike their hierarchical protocol, the distributedprotocol presented in [1] by Menasce and Muntz, is incor-rect. We also point out further problems with this and withother deadlock detection protocols for distributed systems.

II. A COUNTEREXAMPLE TO THE MENASCE-MUNTZDISTRIBUTED PROTOCOL

A. PreliminariesIn the Menasce-Muntz distributed protocol, transactions are

required to lock resources before (and unlock them after)operations, such as read and write, are performed. Each trans-action is associated with a site of the distributed system, anddoes not migrate from site to site after' the transaction starts.A transaction can be thought of as a process that is equippedwith locking and recovery mechanisms [3]. Lock requests andreleases by transactions are arbitrated by a (concurrency)controller. The controller also builds the "transaction-wait-for" (TWF) graph and detects deadlocks. In distributed

0098-5589/80/0900-0435$00.75 © 1980 IEEE

435

software design representation using abstract process · pdf fileent notations andterminology...

Documents