A Survey of Structured and Object-Oriented Software ... › robin › web › virtualclassroom ›...

A Survey of Structured and Object-Oriented SoftwareSpecification Methods and TechniquesROEL WIERINGA

University of Twente

This article surveys techniques used in structured and object-oriented softwarespecification methods. The techniques are classified as techniques for thespecification of external interaction and internal decomposition. The externalinteraction specification techniques are further subdivided into techniques for thespecification of functions, behavior, and communication. After surveying thetechniques, we summarize the way they are used in structured and object-orientedmethods and indicate ways in which they can be combined. The article ends with aplea for simplicity in diagram techniques and for the use of formal semantics todefine these techniques. The appendices show how the reviewed techniques areused in 6 structured and 19 object-oriented specification methods.

Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications—tools; D.2.2 [Software Engineering]: Design Tools andTechniques—Object-oriented design methods; state diagrams

General Terms: Design, Languages

1. INTRODUCTION

In the past 20 years, a large number ofmethods have been proposed for thespecification of software systems. Until1988, the proposed methods followedthe structured approach and since thattime, most proposals have followed theobject-oriented approach. In the shorttime since 1988, at least 19 object-ori-ented methods have been proposed inbook form and many more have beenproposed in conference and journal pa-pers. This survey puts these develop-ments in perspective by reviewing thestate of the art of structured as well asobject-oriented methods. It identifiesthe underlying composition of struc-tured and object-oriented software spec-

ifications, investigates in which re-spects object-oriented specificationsdiffer essentially from structured ones,and points out opportunities for combin-ing the two kinds of specifications. Mostmajor structured and object-orientedspecification methods are reviewed inthe appendix, where “major” means thatthe method must have been described ina book rather than only in a conferenceor journal paper. The distinction be-tween structured and object-orientedmethods is artificial because somemethods, such as JSD and SDL 92, oc-cupy an intermediate position in thisdivision and other methods, such asthose of Shumate and Keller [1992] andFiresmith [1993], incorporate elements

Author’s address: Department of Computer Science, University of Twente, Enschede, the Netherlands.Permission to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1999 ACM 0360-0300/99/1200–0459 $5.00

ACM Computing Surveys, Vol. 30, No. 4, December 1998

of both. Nevertheless, the division has abroad validity and it simplifies the dis-cussion. Qualifications are made wherenecessary.

To keep the discussion manageable,we restrict ourselves to the specificationof software at an external and concep-tual level. These levels are defined inSection 2. With this restriction, whatdoes a specification method include? Weconsider a software specification methodto have the following components.

—Techniques for representing proper-ties of software. Examples of suchtechniques are natural languages, for-mal languages, and diagram tech-niques.

—Interpretation rules for these tech-niques. For example, natural lan-guages are interpreted as describedby some dictionary and grammar, for-mal languages have a formal seman-tics, and diagram techniques havesome intended meaning described inmethod handbooks.

—Interconnection rules for the tech-niques. These interconnection rulestell us how different techniques canbe combined into a coherent specifica-tion of software and what this com-bined specification means. For exam-ple, in different methods, entity-relationship models are connected invarious ways to dataflow models andto state transition models. Each ofthese ways is characterized by differ-ent interconnection rules that are, orshould be, defined by the methodhandbook.

—Heuristics for the usage of the tech-niques. These heuristics should beconsistent with the meaning of thetechniques and the interconnectionrules. Often they follow from thesemeanings. For example, if class spe-cialization is interpreted as subset-ting of class extensions, a simple heu-ristic to find specializations is to askwhether an instance of the subclass isalways also an instance of the super-class. If specialization is interpretedin another way, for example, as reuse

of class specifications, this heuristicmay not apply but other heuristicswill be valid.

We restrict our attention to semiformaltechniques, by which we mean diagramtechniques and techniques that usesome form of structured natural lan-guage.

The structure of this article is as fol-lows. In the rest of this introduction, webriefly discuss other surveys of struc-tured and object-oriented specificationmethods. Section 2 introduces a frame-work in terms of which we present andanalyze the methods. This framework isbased upon the philosophy of systemsengineering and is general enough toaccommodate structured as well as ob-ject-oriented methods without distort-ing the characteristic philosophy ofthese methods. It allows us to presentthe techniques in Section 3 in a system-atic manner and to disentangle in Sec-tion 4 the agreements and differencesbetween structured and object-orientedmethods. The actual survey of thesemethods is relegated to the appendices,so that readers can refer to those meth-ods with which they are less familiar.Appendix A surveys 6 structured speci-fication methods and Appendix B sur-veys 19 object-oriented methods in his-torical order of first publication in bookform. The subsections of these appendi-ces can be read in any order.

In Section 3 we review the techniquesemployed by the methods surveyed inthe appendices. This is not a catalogueof all possible techniques that can beused in software specification. For ex-ample, Petri nets are not discussed and,as pointed out, formal specificationtechniques are left out of consideration.However, the coverage of the techniquesused in the methods listed in the appen-dices is fairly complete. We do not dis-cuss every variant of every techniquebut restrict ourselves to a representa-tive of every technique “family.” For ex-ample, we do not discuss all class mod-eling techniques but discuss the UMLvariant only. Other overviews of tech-

460 • R. Wieringa


niques are given by Davis [1993] andMartin and McClure [1985].

Section 4 compares the way struc-tured and object-oriented methods makeuse of these techniques, focusing on theinterconnection rules and the character-istic heuristics used to find a specifica-tion. We identify some essential differ-ences and agreements and point outunification opportunities. Section 5winds up the survey with a summary offindings and directions for further re-search.

Throughout the article, we use a con-trol system for a juice plant as a run-ning example, adapted from an examplegiven by Shlaer and Mellor [1992]. Thecontrol system controls the way juice istransported from storage tanks to cook-ing tanks, heated, and then transportedto an operation where it is canned.

Since 1992, a number of surveys andcomparisons of object-oriented methodshave appeared. Fichman and Kemerer[1992] compare three structured withthree object-oriented analysis methodsalong 11 modeling dimensions. Thesedimensions were identified by analyzingthe six reviewed methods but they arenot explained in detail. It is, for exam-ple, not clear why this would be a com-plete list of dimensions or whether alldimensions are at the same level of ab-straction. Fichman and Kemerer do notpresent the techniques used in themethods in detail, as we do. They alsodiscuss structured and object-orienteddesign methods, which we leave out ofconsideration. Sutcliffe [1991] lists fourfeatures of object-oriented models (ab-straction, classification, inheritance,and encapsulation) and tabulates fiveobject-oriented methods against thesefeatures. He also lists three features ofstructured models (functions, data,events) and tabulates eight structuredmethods against these features as wellas against the object-oriented features.The discussion is very sketchy andthere are no clear conclusions.

All other reviews ignore structuredmethods. Most of them give a list offeatures of object-oriented models

and/or the object-oriented software de-velopment process, and tabulate somemethods against these features. Takenseparately, the lists look plausibleenough, but different papers use differ-ent lists of features and none of themmakes clear why the features they pro-pose should be part of the list, orwhether their list encompasses all es-sential features of object-oriented meth-ods. Champeaux and Faure [1992] dis-cuss a number of key object-orientedconcepts such as inheritance, attributes,events, and the like, and then tabulatefor each of 12 methods whether theseconcepts occur in the method. Monarchiand Puhr [1992] distinguish a numberof features of the process and notationof object-oriented methods and then tab-ulate for each of 23 methods whetherthese features occur in the method.Most of the reviewed methods are de-scribed in papers; some are described inbooks. Monarchi and Puhr use a list of14 notation features, including the abil-ity to represent objects, relationships,attributes, behavior, communication,and so on. Fowler [1994] looks at sevenobject-oriented analysis and designmethods and discusses a number of dia-gram techniques used in them. He thengives a number of guidelines for choos-ing an object-oriented method. Hodgson[1994] gives a brief history of structuredand object-oriented methods without go-ing into much detail. Hutt [1994b] andHutt [1994a] contain a compilation ofmethod descriptions, all according tothe same format, submitted by thosewho invented the methods. Embley etal. [1995] draw up a list of 30 features ofan object-oriented analysis notation andevaluate six methods on this list, againby tabulating features against methods.The features include the ability to rep-resent objects with identity, state, andbehavior, the ability to representclasses, relationships, aggregation, gen-eralization, actions, triggers, and so on.Iivari [1995] compares six methods forobject-oriented analysis on their abilityto model the structure, function, andbehavior of software systems. He con-

Specification Methods and Techniques • 461


cludes that object-oriented methods areunderdeveloped in the specification ofexternal functions of the system as awhole (as opposed to the functions ofindividual objects). He also concludesthat object-oriented methods are weakin guidelines to partition the systeminto subsystems. These conclusionsagree with the conclusions we draw inthis article.

This survey differs from all of these inthat we give a detailed catalogue oftechniques used in structured and ob-ject-oriented methods, and of the use ofthese techniques made by these meth-ods. A second difference is that in ouranalysis (Section 4), we concentrate onthe overall structure of software specifi-cations and look for commonalities anddifferences in the reviewed methodswith respect to this overall architecture.Our comparison framework is carefullyargued from a small number of princi-ples taken from systems engineering.We do not enter a discussion aboutwhich features should and should not besupported by a “true” object-orientedmethod. We take a nonpartisan ap-proach by attempting to appreciate ev-ery method, structured or object-ori-ented, on its own terms and by trying torecognize opportunities for advancingthe state of the art beyond the struc-tured-object-oriented dichotomy by pick-ing the best ideas from both approaches.

2. A FRAMEWORK FOR COMPARISON

The framework set out in this section isdescribed and motivated in detail else-where [Wieringa 1996]. The basic con-cept in the framework of comparison isthat of a system. A system is an assem-blage of parts forming a complex orunitary whole that serves a useful pur-pose [Blanchard and Fabrycky 1990, pp.1–2]. In this wide sense, organizations,pieces of furniture, thermostats, cars,and software products are examples ofsystems. It is crucial that the parts of asystem interact in such a way that theycause the system as a whole to have auseful function for one or more entities

in the environment of the system. Anarbitrary collection of items with someinteractions among the items is not nec-essarily a system. In order for a collec-tion of interacting items to count as asystem, the interactions among theitems must produce a coherent and use-ful overall behavior.

In systems and software engineeringone often reserves the term “system” forthe entire constellation of equipment,software, and human procedures to bedeveloped and refers to the softwarecomponents of the system as “softwareproducts.” Here we use the term in avery liberal way to indicate any collec-tion of interacting items that serves auseful purpose, including hardware,software products, and software productcomponents. However, we do restrictourselves to systems that interact withtheir environment.

A system delivers a service to its envi-ronment by interacting with it. Thereare certain relevant ways in which wecan describe these interactions. Interac-tions can always be partitioned intopieces that are useful for the environ-ment, called functions. Examples fromthe juice plant controller are controllingthe transport of juices from storage tocooking tanks, controlling the heating ofthe cooking tanks, and the like. Second,system interactions are by nature al-ways communications with one or moreentities in the environment of the sys-tem. For example, a juice plant control-ler communicates with storage tanks,cooking tanks, temperature sensors,and so on. Third, the way in whichfunctions are ordered in time is calledthe behavior of the system. For exam-ple, a cooking tank must be heated onlyafter it has been filled with juice, andheating involves switching the heateron and off in order to maintain thetemperature for a period of time. Com-munication and behavior should betreated as orthogonal properties of func-tions. Communications are the wayfunctions are ordered in space wherebehavior is the way in which functionsare ordered in time. Taking the grand

462 • R. Wieringa


view, the distinction between communi-cation and behavior is similar to thedistinction between space and time.Closer to home, but still taking a ballpark view, the distinction is a basicproperty of algebraic process descriptionlanguages, where operators to specifycombinations of communicating pro-cesses are distinguished from operatorsto specify the dynamics of processes[Milner 1980, p. 61].

Functions, communications, and be-havior are system properties. There areother kinds of system properties, suchas security and user-friendliness, butthese are not specified by the tech-niques reviewed in this survey and weleave these out of consideration.

We can describe properties at differ-ent levels of abstraction. For example,at the most abstract level, the interac-tions between a juice plant and its envi-ronment can be described as “providecanned juice to customers.” This highestlevel description of the interactions iscalled the mission of the juice plant. Ata more detailed level, we may describefunctions such as “take order,” “deliverjuice,” and “order ingredients,” and atthe most detailed level we may describeatomic transactions between the juiceplant and its environment. This leads tothe idea of a refinement hierarchy ofbehavior descriptions, in which the be-havior of a system is described at in-creasing levels of detail. The lowestlevel of detail is that of the atomicpieces of behavior with which a systeminteracts with its environment. Theseare called atomic because intermediarystates that occur during the behaviorare not externally observable, or atleast not considered to be externallyobservable. These atomic pieces of be-havior are called transactions.

The parts of a system may themselvesbe systems that act together to producethe behavior of the system. This leads tothe idea of an aggregation hierarchy ofsystems, in which systems at one levelof aggregation have subsystems at thenext lower level of aggregation and arethemselves part of a compound system

at the next higher aggregation level.There are two important ways to de-scribe the decomposition of a system: wecan specify its components and, for eachcomponent, we can specify the way itinteracts with its environment to realizeoverall system behavior. The environ-ment of a component consists of othercomponents as well as the environmentof the system. The specification of theinteraction of the components can itselfbe divided into the specification of com-munication, functions, and behavior ofeach component. This pattern repeatsitself at every level of aggregation. Itfollows that when we talk about proper-ties, interactions, functions, and thelike, we should always indicate the levelin the aggregation hierarchy aboutwhich we are talking. In this survey, weassume that we have fixed a system ofinterest and talk about system func-tions, system communications, and thelike, in contrast to component functions,component communications, and so on.To emphasize that system functions,and the like, are interactions with theenvironment, we also talk of externalsystem functions, and the like.

Note that components can interactwith the system environment. It isthrough these interactions that the sys-tem interactions are realized. Note alsothat the concept of a transaction, intro-duced previously, must be related tothat of aggregation level. For each sub-system we can define transactions assubsystem functions whose internalstates we consider unobservable. A sys-tem transaction is then realized as aprocess consisting of lower-level sub-system transactions.

The aggregation and refinement hier-archies are orthogonal. This can be rep-resented visually by what Harel andPnueli [1985] call the magic square ofsystem development (Figure 1). Everypoint in this square represents a level ofaggregation and a level of interactionrefinement. The top-left point repre-sents the highest aggregation level andthe highest level of abstraction: theoverall mission of the entire system.



The bottom-right point represents thelowest aggregation level and the lowestlevel of abstraction: the atomic transac-tions of the lowest-level components ofthe system. The orthogonality of the twodimensions of the square means the fol-lowing.

—At a given level of aggregation andabstraction, we can decrease the ab-straction level at which we specify theinteractions of a system at that levelwithout decreasing the aggregationlevel. This is called interaction refine-ment. At the highest level of refine-ment (the lowest abstraction level),we specify the transactions of a sys-tem.

—Conversely, at a given level of aggre-gation and abstraction, we can decom-pose a system without decreasing thelevel of abstraction. This is called in-teraction allocation and flowdown. Weallocate a system interaction to one ormore components if we decide thatthese components will realize the sys-tem interaction. We flow down thesystem interaction if we specify whatthe component interactions arethrough which the system interactionis realized.

We can apply the idea of refinement tothe three aspects of interaction (viz.,functions, behavior, and communica-tion). This gives us three species of re-finement; function, behavior, and com-munication. Of these, functionrefinement is the most basic, because

the system functions provide the raisond’etre of the system: the system exists toprovide functions to its environment.We therefore look at function allocationand flowdown in somewhat more detail.

Consider a system S at a certain ag-gregation level, whose functions arespecified at a certain level of abstrac-tion. This corresponds to a point in themagic square. Suppose that the func-tions of S at this level of refinement arefunction 1, . . . , function n and that wehave identified components component1, . . . , component m. We next decide foreach component whether it plays a rolein each function. This can be repre-sented visually by means of a traceabil-ity table such as shown in Figure 2. Across in an entry means that the compo-nent plays a role in the function, with-out yet indicating what this role is; ab-sence of a cross indicates that thiscomponent plays no role in the realiza-tion of this function. A traceability tablerepresents the allocation of functions tocomponents. It is called a traceabilitytable because it allows us to trace com-ponent functions to system functionsand vice versa. If we add more informa-tion and indicate in each entry what thefunction is that the component shouldhave in order to play this role in thesystem function, then we call the result-ing table a function decomposition table.This represents the flowdown of func-tions to components. Allocation andflowdown are well-known techniquesfrom systems engineering [Davis 1993,

Figure 1. The magic square. The arrows point towards the direction of increase. To increase behaviorrefinement is to decrease behavior abstraction and to increase system decomposition is to decrease theaggregation level.

464 • R. Wieringa


p. 190]. The function decomposition ta-ble plays a central part in our analysisof methods.

Before we summarize our framework,we must make one more distinction. Itis useful to distinguish a conceptual de-composition of a system from a physicaldecomposition. A conceptual decomposi-tion is a decomposition whose partition-ing criterion is defined in terms of theexternal environment of the system,which is the environment where the us-ers of the system reside. (Users may bepeople or other systems.) The physicaldecomposition of a system is a decompo-sition defined in terms of the underlyingphysical components of the system, suchas lower-level equipment or softwarecomponents. The physical decomposi-tion criterion does not refer to the exter-nal environment but to the underlyingimplementation environment. For ex-ample, an entity-relationship diagramrepresents a conceptual decompositionof a database. A relational databaseschema, in which each relation corre-sponds to an entity type or relationshipin an entity-relationship model, is still aconceptual decomposition. A relationalschema, in which the relations corre-spond to storage entities such as files, isa physical decomposition. In thisschema, conceptual entities may havebeen split or merged in order to improveperformance. Another example of a con-ceptual decomposition is a JSD model inwhich the components correspond to do-main entities or to external systemfunctions. In a physical decomposition,these are all mapped to the availablephysical resources and a scheduler may

have been added to interleave processesthat are conceptually concurrent.

The conceptual decomposition corre-sponds to the essential model of Mc-Menamin and Palmer [1984] and thespecification model of Cook and Daniels[1994]. It is a halfway station betweenthe specification of external functional-ity and the internal physical decomposi-tion. In the physical decomposition, is-sues are dealt with such as thedistribution of resources, processingtime, memory capacity, and error han-dling. The conceptual decomposition is away to make the demands of externalfunctionality explicit without yet worry-ing about these implementation deci-sions.

The relationship between the concep-tual and physical decompositions ismany–many. One conceptual componentis implemented in one or more physicalcomponents, and one physical compo-nent implements one or more concep-tual components. This can be repre-sented by a second kind of traceabilitytable, which sets conceptual againstphysical components. In this article, un-less otherwise stated, the decomposi-tions that we talk about are conceptual,not physical.

To summarize our framework, wehave a number of kinds of system prop-erties that we can specify. The followinglist relates these to the function decom-position table of the system.

—System functions. These are the use-ful pieces of behavior offered to theenvironment of the system, and corre-

Figure 2. Function decomposition table.



spond to items in the top row of thetable.

—System behavior. This is the behaviorof the system over time. This concernsthe way in which the functions in thetop row are, can, or must be orderedin time. It thus concerns the entiretop row.

—System communication. This concernsthe communication of the system withexternal entities in its environment.It does not correspond to an aspect ofthe function decomposition table ofthe system, but it would correspond toa column of the function decomposi-tion table of the environment, ofwhich the system is one component.

—Conceptual decomposition. These arethe conceptual components of the sys-tem, defined in terms of their mean-ing for the external environment, andcorrespond to the items in the left-most column of the table.

—Component functions. These are theuseful pieces of behavior offered bythe components to their environment,and correspond to entries in the table.

—Component behavior. This is the wayin which component functions are,can, or must be ordered in time, andcorresponds with a row in the func-tion decomposition table.

—Component communication. This isthe way in which the components in-teract in order to realize the externalfunctions, and corresponds to the col-umns of the function decompositiontable. In each column, the componentfunctions are listed that interact torealize the external function.

Due to the repetition in this pattern,there are only four different kinds ofproperties that we need specificationtechniques for:

—function specification techniques,—behavior specification techniques,—communication specification tech-

niques, and—decomposition specification tech-

niques.

There are of course other properties,often called “nonfunctional,” that can bespecified, but the reviewed methods of-fer no techniques for these. In the nextsection we therefore use the precedingclassification of techniques.

3. SPECIFICATION TECHNIQUES

3.1 Graphical Techniques

We start with a brief summary of thegraphical structures encountered in thevarious techniques that follow. In gen-eral, there are only two kinds of graph-ical structures, graphs and Venn dia-grams. A graph is a set of nodesconnected by edges. (A node may beconnected to itself.) Usually, each edgeconnects two nodes, but in a hyper-graph, an edge may connect two or morenodes. In a directed graph, the edgeshave a direction. So in a directed hyper-graph, each hyperedge has a collectionof source nodes and a collection of desti-nation nodes. In a labeled graph, edgesand/or nodes may be labeled. A tree is agraph with one designated node calledthe root and in which from every nodethere is exactly one path to the root.The nodes with the longest paths to theroot are called the leaves of the tree.

A graph can be drawn in many differ-ent ways, so that one must distinguishthe graph from a presentation of thegraph. Many methods annotate theirgraph presentations with additionalcomments and adornments that do notbelong to the underlying mathematicalformalism of a graph. If there are differ-ent kinds of nodes and edges, these areusually presented by different shapes.Many methods allow dangling edgesthat are connected to one node only and“dangle in the air” at the other side.This can be assimilated with the idea ofa graph by allowing some nodes to beinvisible in the presentation.

A Venn diagram is a collection of ar-eas indicated by closed curves. We callthese areas blobs. Hierarchy can be rep-resented by a Venn diagram by enclos-ing one blob within another. Venn dia-

466 • R. Wieringa


grams as such are not used in any of thereviewed techniques but the idea to rep-resent hierarchy by enclosure is used inseveral techniques, such as SDL blockdiagrams and in the Statemate lan-guages.

A higraph is a combination of a Venndiagram and a hypergraph, extendedwith the explicit labeling of areas andCartesian products. The nodes of a hi-graph are blobs and these may be con-nected by hyperedges. Explicit labelingof areas means that in Figure 3, dia-grams (a) and (b) are equivalent repre-sentations of the same higraph. In dia-gram (c), A and B have an intersection,called C. Since Venn diagrams do notrequire explicit labeling of areas, dia-grams (a), (b), and (c) are different Venndiagrams. The Cartesian product A ofblobs B and C is represented as shownin Figure 4. Higraphs were introducedby Harel [1988].

The following sections describe theuse of these graphical structures in anumber of specification techniques. Ingeneral, one cannot tell by looking at adiagram what it represents. The mean-ing of a diagram is given by a set ofinterpretation rules, which must be de-fined elsewhere. The interpretationrules are never specified together withthe diagram but the diagram must beaccompanied with an indication ofwhich interpretation rules are intendedto be applied. Without such an indica-tion, the diagram is meaningless. Inmost cases, the interpretation rules fora particular kind of diagram are givenin a book that describes the method. Insome cases, such as the statechart lan-guage of Statemate, the interpretationrules are formal [i-Logix 1991a], and insome very rare cases, such as for SDL,

the interpretation rules are laid down ina standards document [ITU 1992].

3.2 Decomposition SpecificationTechniques

Decomposition specification techniquescan be used to specify the items in theleft-most column of the function decom-position table.

3.2.1 Entity-Relationship Diagrams.Entity-Relationship diagrams (ERDs)were introduced by Chen [1976] to rep-resent the conceptual structure of datain a database system. An ERD is alabeled hypergraph in which the nodesrepresent types of entities and the hy-peredges represent arbitrary relation-ships. The nodes of the hypergraph arepresented by rectangles and the hy-peredges by diamonds.

Figure 5 contains a fragment of ERDfor a juice plant control system, derivedfrom the specification of Shlaer andMellor [1992]. The diagrams shows thatthere are two kinds of TANKs, STORAGETANKs and COOKING TANKs. The hy-peredge tank usage is called a special-ization relationship and connects thenode TANK with two other nodes, thatare called its specializations. EachCOOKING TANK is connected to oneHEATER and each HEATER belongs toone COOKING TANK. A BATCH of juiceis allocated to one COOKING TANK and

Figure 3. Higraphs versus Venn diagrams.

Figure 4. A higraph with a Cartesian product.



belongs to exactly one RECIPE. EachRECIPE is related to a JUICE SPECIFI-CATION. There is some special informa-tion connected to this relationship bymeans of the associative entity typeJUICE IN RECIPE. The extra informationis that there is a certain percentage ofthis juice in this recipe, but this is notdetailed in the diagram.

A relationship node in an ERD canrepresent any kind of relationship. Itmay represent a communication linkbut it may also represent a visibilitylink, a permission, a part-of link, and soon.

From the start of their introductionby Chen, ERDs have been ambiguous,representing components in the envi-ronment of the software product or rep-resenting conceptual software compo-nents. This ambiguity arises from thefact that in database systems, whereERDs are mainly used, the conceptualstructure of the data must correspond tothe conceptual structure of the part ofthe world represented by the database.The same ambiguity can also exist inmodels of control-intensive systems: AnERD can represent the part of the worldcontrolled by the system or it can repre-

sent conceptual objects inside the sys-tem. One cannot tell by looking at Fig-ure 5 whether COOKING TANKrepresents real cooking tanks in the en-vironment, or software objects in thecontrol system. It follows that, in addi-tion to the normal interpretation rulesfor a notation, an ERD must be accom-panied by an annotation that tells thereader whether the ERD is to be inter-preted in the real world or in the soft-ware.

3.2.2 Class Diagrams. There aremany variations and extensions of theERD technique. All object-oriented spec-ification methods use some extension ofthe technique. We refer to this as aclass diagram, but different OO meth-ods tend to use different variations orextensions with different names, suchas “information model,” “object model,”“object structure diagram,” “staticstructure diagram,” and so on. Figure 6contains a class diagram following theconventions of the Unified ModelingLanguage (UML, Appendix B.19). Theparallel with Figure 6 is clear. A note-worthy difference is that nodes now rep-resent object classes, where objects have

Figure 5. Fragment of an entity-relationship diagram of the data manipulated by a juice plant controlsystem.

468 • R. Wieringa


a local state represented by attributes,and they have local operations that maychange those attributes. Entities speci-fied by ERDs also have attributes, butin structured analysis they do not havelocal operations. A node in a class dia-gram may be labeled with some or allattributes and operations of the objectsof this class.

A second important difference is thatthe class diagram contains an addi-tional object class, TEMPERATURERAMP, which has no counterpart in theERD. This is not a difference in diagramtechniques but in methodology. Thetask of instances of this class is to con-trol the heating process of a cookingtank, something that would be modeledby a control process in dataflow models.

3.3 Communication SpecificationTechniques

Communication specification techniquesshow how the conceptual componentsinteract to realize external system in-teractions. This corresponds to the col-umns in the function decomposition table.

3.3.1 Dataflow Diagrams. A data-flow diagram (DFD) is a labeled di-rected hypergraph in which the nodesrepresent functions and the edges data-flows between functions. It is used instructured analysis to specify the func-tions of a system. There are three kindsof nodes in a DFD that represent func-tions, data stores, and external entities.The functions and data stores are de-fined in terms of their meaning for the

Figure 6. Fragment of a UML class diagram of the juice plant control system.



external interactions of the system, sothey are conceptual (not physical) sys-tem components.

Figure 7 shows a part of a DFD of thejuice plant control system, following theYSM convention [Yourdon Inc. 1993].External entities in the environment ofthe control system are represented bysquares, functions are represented bycircles, memory by two parallel lines,and dataflows by arrows. The asteriskin the label of the data store TEMPERA-TURE RAMP DATA means that this data

store has multiple representations inthis diagram.

Most versions of structured analysis,including the Yourdon Systems Method(YSM, Appendix A.2), distinguishes twokinds of functions, called data processes,represented by unbroken circles, andcontrol processes, represented by dashedcircles. Data processes transform data;control processes transform the mode ofbehavior of the system. For example,Figure 7 shows that there is a controlprocess Control temperature ramp and a

Figure 7. Fragment of a dataflow diagram of the functions of the juice plant control system.

470 • R. Wieringa


number of data processes to turn aheater on and off, and so on. This con-trol process corresponds to the TEM-PERATURE RAMP object class of Figure6. We discuss the methodological differ-ence between these two modeling ap-proaches when we look at decompositioncriteria in Section 4.2.3.

A second distinction made by YSM isthat between instantaneous processes,whose activity lasts only one instant oftime, and continuing processes, whoseactivity lasts a period of time. There isno visual convention to distinguish thetwo kinds of processes. In Figure 7,Monitor deadline is a continuing dataprocess and Control temperature ramp isa continuing control process. All otherprocesses in the figure are instanta-neous. Control processes are usuallycontinuing processes. An instantaneouscontrol process has no memory and canalways be specified by a decision tablethat transforms a number of discretebinary input flows into a number ofdiscrete binary output flows.

The diagram shows the data inter-faces between the functions (unbrokenarrows) as well as the event interfaces(dashed arrows). The double-headed ar-row represents a time-continuous flow.A continuous dataflow contains datavalues for periods of time. A continuousevent flow contains Boolean values thatmay be present over periods of time.There are some special symbols that canappear as labels of event flows. For ex-ample, T, E, and D stand for triggering,enabling, and disabling a data or con-trol process, respectively.

The data processes in Figure 7 mustbe specified in structured analysis bytextual specifications that define the re-lation between their inputs and outputs.This is not treated in this article. Thecontrol process behaves as a finite statemachine and must be specified bymeans of a state transition diagram ortable (Section 3.5.5).

All versions of dataflow modelingsince DeMarco [1978] use hierarchicalDFDs to reduce the complexity of alarge dataflow diagram. Any part of a

large diagram can be abstracted awayby replacing it by a process group,which has the same visual presentationas a data process (an unbroken circle).The process group is specified sepa-rately by showing the DFD portion forwhich it stands. The intention is that aprocess group represent a coherentgroup of software functions. This con-vention is well suited to the representa-tion of a functional decomposition of thesystem, discussed in Section 4.2.3.

3.3.2 Context Diagrams. A contextdiagram is a graph in which one noderepresents the system and the othernodes represent important systems inits environment. The edges representcommunications among the systems. Acontext diagram will at least show thesystems with which the system underdevelopment communicates, but it mayshow other systems, if these are neces-sary to understand the behavior re-quired of the system under development[Jackson 1995].

In structured analysis, a context dia-gram only shows the systems that thesystem communicates with, called ex-ternal entities, and the edges representdataflows between the system and itsexternal entities (Appendix A.2). Inother words, in structured analysis, acontext diagram is a dataflow diagram.Large context diagrams may be splitinto a number of partial context dia-grams, one for each major system func-tion.

3.3.3 SADT Activity Diagrams. Anactivity diagram is a directed hyper-graph in which the nodes represent ac-tivities and the edges represent flows ofdata, matter, or energy between activi-ties. Activity diagrams are used inSADT to specify a conceptual decompo-sition of a system into a number ofcooperating activities (Appendix A.1).The technique was introduced by Ross[1977]. Figure 8 shows an activity dia-gram with three activities, representedby boxes with rounded corners. Arrowsentering a box from the left represent



input data, arrows leaving to the rightrepresent output data, arrows enteringfrom above represent control informa-tion, and arrows entering a box frombelow represent mechanisms by whichthe activity is to be performed. Activitydiagrams can be structured hierarchi-cally, so that one activity box can bedecomposed into a lower-level activitydiagram. The decomposition hierarchydoes not represent a physical decompo-sition of the system under description,but is a conceptual decomposition of thetasks to be performed by the system.This convention is well suited to therepresentation of functional decomposi-tion. In contrast to DFDs, activity dia-grams have only one kind of componentand the interfaces between the activi-ties distinguish input, output, control,and mechanism.

3.3.4 Statemate Activity Charts. Ac-tivity charts are higraphs without inter-sections or Cartesian products that areused in Statemate to represent externalsystem behavior (Appendix A.3). Theyare variants of DFDs with a differentsyntax but with a similar meaning.Statemate distinguishes external activi-ties, regular activities, control activi-

ties, and data stores, which correspondto external entities, data processes, con-trol processes, and data stores in DFDs,respectively. Regular activities are rep-resented by rectangles with sharp cor-ners, control activities by rectangleswith rounded corners, and data storesby rectangles in which the verticaledges are dashed. Data and event flowsbetween activities are represented bydirected hyperedges. In Figure 9, D is acontrol activity, B a data store, and X andY are external activities. The other nodesin the diagram are regular activities.

The hierarchy of activities is repre-

Figure 9. An activity chart.

Figure 8. Activity diagram.

472 • R. Wieringa


sented by means of inclusion of rectan-gles. Control activities are always sub-activities of regular activities, and aregular activity can have at most onecontrol activity as an immediate compo-nent. Control activities are specified byextended finite state machines, speci-fied in Statemate by means of state-charts (Section 3.5.7). Extended finitestate machines are finite state ma-chines extended with variables that canbe updated. Control activities can thusmaintain a state in their variables, canperform data processing (testing andupdating the variables), and can containcontrol.

3.3.5 Object Communication Diagrams.An object communication diagram(OCD) is a directed graph in which thenodes represent object classes and theedges represent possible object commu-nications. The technique is used in theShlaer–Mellor method to represent ob-ject communications. Figure 10 shows afragment of an OCD based upon an ex-ample given by Shlaer and Mellor[1992]. For the sake of the example, thediagram represents a slightly differentsituation than that shown by the DFDin Figure 7; the start heating message issent to the temperature ramp object notby an operator but by a batch object.

The diagram shows external entities(operator) as well as object classes.Edges represent possible communica-

tions. For example, the edge start batchshows a possible communication be-tween an instance of Operator and aninstance of Batch. Temporal ordering ofcommunications is not represented.

3.3.6 JSD System Network Diagrams.A system network diagram (SND) is adirected graph in which the nodes rep-resent processes and the directed edgesrepresent communications. SNDs areused in JSD to specify system functions(Appendix A.6). Figure 11 shows anSND with three processes, representedby rectangles, and two communicationconnections. SV represents a state vec-tor connection, which is a connectionthrough which a reader process (TEM-PERATURE RAMP CONTROL) reads thestate of another process. D represents adata stream connection, which is aqueue through which a sender sendsmessages to a receiver. The other circlesrepresent queues through which thesystem receives messages from its envi-ronment and sends messages to its envi-ronment. The external entities thatsend and receive these messages are notrepresented in an SND. In JSD, each ofthe three processes in the SND would bean extended finite state machine, speci-fied by means of a process structurediagram (Section 3.5.2). JSD allowsthese processes to have local state vari-ables (called attributes) and to test andupdate these variables.

Figure 10. Fragment of an object communication diagram.



SNDs are similar to DFDs in thatboth represent the system as a networkof communicating components. How-ever, SNDs recognize only one kind ofcomponent, a process that maintains astate and has behavior over time. DFDscontain three kinds of components, thatmaintain a state (data stores), update it(data processes), and have a behaviorover time (control processes). This is animportant technical difference betweenthe diagram techniques that is relatedto the concept of a state machine. InDFDs, control processes can do no dataprocessing or data storage, whereas inSNDs, the processes can store, test, andupdate data. Activity charts occupy anintermediate position in this spectrumbecause they contain regular activitiesand data stores just as DFDs do, buttheir control activities can store, test,and update data as well. We return tothis in the discussion of extended finitestate machines in Section 3.5.4.

Another difference between the dia-gram techniques is that SNDs are flatwhereas DFDs are hierarchical. Typi-cally, one SND is specified for each ex-ternal system function. From a method-ological point of view this correspondsto the heuristic of event partitioning instructured analysis in which one DFD isdrawn for every event-response pair ofthe system [McMenamin and Palmer1984]. This means that for every columnin the function decomposition table, a

diagram is drawn. We elaborate on thisin our discussion of decomposition crite-ria in Section 4.2.3.

The nodes in Figure 11 represent soft-ware components. TEMPERATURE SEN-SOR and HEATER represent entities inthe part of the world controlled by thesoftware, which is why we call themsurrogates. They are represented as en-tity types in the ERD of Figure 5 and asobject classes in the class diagram ofFigure 6. TEMPERATURE RAMP CON-TROL is a function process whose task itis to enforce certain behavior on theexternal entities. This corresponds to acontrol process in the DFD of Figure 7and to an object class in Figure 6. Thedistinction between surrogates andfunction processes is an importantmethodological difference between func-tional decomposition and object-ori-ented decomposition. This too is dis-cussed in more detail in Section 4.2.3.

3.3.7 SDL Block Diagrams. A blockdiagram is a graph in which the nodesrepresent blocks and the edges repre-sent channels through which the blockscan communicate. They are used in SDLto partition a complex system into sim-pler parts (Appendix A.4).

Blocks communicate by sending sig-nals through channels. Signals travel-ing along a channel may experience de-lay. A channel may carry signals in bothways. Figure 12 shows a simple block

Figure 11. A system network diagram.

474 • R. Wieringa


diagram. The Transport block can send abatch_id to the Heating block, that cansend a heating_finished signal back tothe Transport block. When used to rep-resent a system decomposition, theseblocks represent system components.They are conceptual components, be-cause they are defined in terms of theirmeaning for external system behavior.

A block can be decomposed into alower-level block diagram, provided thatthe interface of a block is equal to thatof its decomposition. Hierarchical dia-grams can be used to specify differentlevels in an aggregation hierarchy,called service layers in SDL [Belina etal. 1991; ITU 1993]. Each leaf block in ablock hierarchy contains one or moreprocesses. Processes cannot be part ofnonleaf blocks. This means that a blockeither has subblocks or it contains pro-cesses, but not both.1 Each process is anextended finite state machine, specifiedby an SDL state diagram (Section3.5.8). The processes within one leafblock communicate with each other bymeans of signal routes. The differencewith channels is that signals experienceno delay when traveling through a sig-nal route, whereas they may experiencedelay when traveling through a chan-nel. The behavior of a leaf block is theresult of the behavior of its componentprocesses. The behavior of a higher-level block is the result of the behaviorof its component blocks.

Block diagrams are similar to DFDsand activity charts in that they all rep-resent a hierarchy of system functions

and their communications. An impor-tant difference is that in a block dia-gram, control is only specified at theleaves of the hierarchy, whereas inDFDs and activity charts, control maybe specified at any level in the hierar-chy.

A second important difference ap-pears if we flatten both hierarchies. Aflattened DFD or activity chart consistsof a number of communicating controlprocesses, data processes, and datastores. A flattened block diagram con-sists of SDL processes, which are ex-tended finite state machines, just ascontrol activities in activity charts andprocesses in SNDs are. Extended finitestate machines contain control (a finitestate machine), data processing (testsand updates), and data storage (vari-ables).

A third difference between block dia-grams and DFDs is that a channel orsignal route combines the features ofdata and event flows: it may carry asingle signal, like an event flow, or asignal together with data values, like adata flow.

Block diagrams are similar to SADTactivity diagrams in that they both rep-resent a collection of communicating ac-tivities that can be decomposed hierar-chically. However, activity diagrams donot allow the inclusion of control andhave no precise semantics for communi-cation, as block diagrams do.

The idea of block diagrams is a natu-ral one and it occurs in several object-oriented methods with a telecommuni-cation background. For example, inOOSE, design components are calledblocks [Jacobson et al. 1992, pp. 224–227]. In the commercialized variant ofOOSE called Objectory, the term “block”has been replaced by the term “designobject” [Objectory AB 1995a, p. 88]. See

1 This simple picture is complicated by the possi-bility of combined block specifications, which fromone point of view are leaf blocks used to specifythe behavior that must be implemented, and fromanother point of view are nonleaf blocks, decom-posed into lower-level blocks that implement thisbehavior.

Figure 12. A simple block diagram.



also Appendix B.5. Block diagrams arealso closely related to actor class dia-grams in ROOM (Appendix B.11). Anactor class diagram is a block diagramin which processes can be defined forblocks at each level of the hierarchy.The blocks in these diagrams are calledactors.

3.3.8 Sequence Diagrams. A se-quence diagram represents a particularsequence of messages exchanged be-tween a number of entities. In the tele-communications area, they have beenstandardized as message sequencecharts [ITU 1994]. They are used incombination with SDL specifications toillustrate sequences of messages be-tween a system and its environment.They were introduced into object-ori-ented modeling by Objectory [Jacobsonet al. 1992], and since then have becomepopular in object-oriented methods torepresent communications between ob-jects.

Figure 13 shows a sequence diagramthat represents the communicationamong a number of objects in responseto the operator message to start heat-ing. The communicating entities are

represented by vertical lines. The down-ward direction represents the advanceof time. Horizontal arrows representmessages. Sequence diagrams can beextended with conventions to representtimeouts, global conditions across dif-ferent entities, delayed message recep-tion, and the like.

A sequence diagram shows one partic-ular communication sequence in onerun of the system. This stands in con-trast to the communication specificationtechniques reviewed so far, which spec-ify properties of all possible runs of thesystem. A second property of sequencediagrams is that they show communica-tion as well as behavior. They couldtherefore also have been listed as be-havior specification techniques.

3.3.9 Collaboration Diagrams. A col-laboration diagram is a directed graphin which the nodes represent communi-cating entities and the edges representcommunications. The edges are num-bered to represent the ordering of com-munications in time. Figure 14 containsa collaboration diagram that representsthe same message sequence as Figure13. Collaboration diagrams have been

Figure 13. A sequence diagram.

476 • R. Wieringa


introduced by Wirfs-Brock et al. [1990]and have, in various guises, becomepopular in object-oriented methods torepresent message exchanges betweenobjects. In the UML (Appendix B.19),they can be extended with annotationsthat represent dataflows between thecommunicating objects and variousadornments that represent the way inwhich the communications are imple-mented.

Collaboration diagrams differ fromDFDs, activity diagrams, activitycharts, and block diagrams becausetheir nodes represent objects, not activ-ities. This also sets them apart fromobject communication diagrams, be-cause those diagrams represent objectclasses, not individual objects. In addi-tion, just as do sequence diagrams, col-laboration diagrams represent the se-quence of messages in one particularscenario whereas all other communica-tion diagrams represent possible com-munications in all possible scenarios.

3.3.10 Summary. We can distin-guish two kinds of diagrams to repre-sent communication; diagrams that showcommunication sequence (sequence dia-grams and collaboration diagrams) anddiagrams that show a set of possiblecommunications without indicating anysequence (all other diagrams). Dia-grams that show communication se-quence illustrate communications aswell as behavior in one particular run ofthe system. The other diagrams showcommunication only and do not refer toa particular run of the system.

A second distinction to be made con-cerns the kinds of things that can com-municate. We have seen the followingkinds of conceptual components.

—Finite state machines. Control pro-cesses in DFDs are specified by finitestate machines.

—Extended finite state machines. Thesecontain control, local variables, andtests and updates of these variables.

Figure 14. A collaboration diagram.



Control activities (activity charts),JSD processes, and SDL processes areexamples. The objects in sequenceand collaboration diagrams can alsobe viewed as extended finite state ma-chines.

—Data processing activities. Examplesare data processes (DFDs), activitiesrepresented by SADT activity dia-grams, and regular activities (activitycharts). All data processing performedby SDL blocks is ultimately part ofSDL processes, which are extendedfinite state machines.

—Data stores. These are present inDFDs and activity charts.

In addition to these conceptual compo-nents, DFDs and activity charts alsorepresent the external entities withwhich the system communicates.

Complexity reduction by means of hi-erarchy is possible in DFDs, activitycharts, and block diagrams. Hierarchymay be represented in a Venn diagram-like way by enclosure of areas or implic-itly, by a naming convention.

There is a considerable range in thepossible properties of communication:synchronous or not, delay or not, reli-able or not, unidirectional or bidirec-tional, and so on. The reviewed tech-niques should define a semantics for thenotations so that it is clear what kind ofcommunication is represented. Withoutsuch clarity, the notation may be usedto give a rough sketch of vague ideasbut not to communicate a meaning un-ambiguously to others. There is consid-

erable difference among the techniqueson the matter of semantics. SADT activ-ity diagrams hardly have any communi-cation semantics; DFDs and object com-munication diagrams are slightly lessambiguous. Petersohn et al. [1994] de-fine different possible semantics forDFDs. SNDs have a better defined se-mantics, but there is nothing near aformal specification of this. SDL blockdiagrams and activity charts have pre-cisely defined communication proper-ties. The semantics of communication inblock diagrams is formalized in an ITUstandard.

3.4 Function Specification Techniques

Function specification techniques areused to specify the external functions ofa system, which are the items in the toprow of the function decomposition table,or the functions of system components,which are the items in each row of thetable.

3.4.1 Function Refinement Trees. Afunction refinement tree represents sys-tem behavior at an increasing level ofdetail at the same level of aggregation.Figure 15 shows part of a function re-finement tree of a juice plant controlsystem. A function refinement tree in-creases the level of detail along the hor-izontal dimension of the magic square.The highest level of detail at a givenlevel of aggregation is that of atomicfunctions, that is, transactions. Theleaves of a fully grown function refine-ment tree thus represent transactions.

Figure 15. Part of a function refinement tree of a juice plant control system.

478 • R. Wieringa


We should stress that function refine-ment and system decomposition are or-thogonal. Figure 15 is compatible withmany different system decompositions,only one of which is a decompositioninto modules that correspond to systemfunctions. Other possible decomposi-tions include subject domain partition-ing, in which the conceptual compo-nents correspond to entities in therepresented or controlled part of theworld.

We cannot tell by looking at a treediagram whether it is a function refine-ment tree or a system decompositiontree. Thus, interpreted as a system de-composition tree, Figure 15 would rep-resent a functional system decomposi-tion of the juice plant control systeminto functional modules. This is anotherexample of the importance of annotat-ing the diagram not only with the inter-pretation rules to be used, but also withan indication of the domain in which thediagram is to be interpreted.

In information engineering, a func-tion refinement tree is used to representa hierarchical decomposition of businessfunctions of an organization indepen-

dently from the actual organizationstructure (Appendix A.5). In product de-velopment, function refinement treesare used to represent the functions of aproduct in a hierarchical manner. If afunction refinement tree is used to-gether with a hierarchical diagramtechnique such as DFDs, SADT activitydiagrams, Statemate activity charts, orSDL block diagrams, then the tree canbe made to correspond to the hierarchi-cal decomposition of the diagram.

3.4.2 Event-Response Specification. Asimple way of specifying the functions ofa system is to make a list of events towhich the system must respond andwrite down the desired response foreach event. Other properties can also benoted, such as where the event comesfrom, where the response goes to, whatthe desired response time is, and so on.It may also be useful to add informationthat relates the event-response pair toother parts of the specification, such asan indication of the conceptual compo-nents that handle the event.

Figure 16 shows an example event-response specification of a function ac-

Figure 16. Event-response specification for a function of the juice plant control system.



cording to YSM (Appendix A.2). Thefunction finish heating is triggered bythe temporal event temperature rampcompleted. This is called a temporalevent because it consists of a significantmoment in time, namely, the occurrenceof the desired endtime for heating acooking tank. This is noted in the speci-fication by saying that the detectionmechanism is time. The other kind ofevent that can trigger a system functionis an external event, which is generatedby an external entity. For externalevents, the external entity that gener-ates it must be noted. The other proper-ties of the function listed in Figure 16only make sense when the specificationcontains a dataflow model. This is al-ways the case in YSM but in othermethods, one would want to specifyother kinds of properties instead. Forexample, in object-oriented methods,one could specify which objects handlethe event and which objects produce theresponse.

Event-response pairs are functions ofthe system. If event-response specifica-tions are combined with a function re-finement tree, they should thus corre-spond to nodes in a function refinementtree. Event-response pairs may or maynot be transactions. For example, theresponse of a controller to the request toheat a cooking tank is to heat the cook-ing tank and this takes a significantamount of time, with intermediarystates that are externally observable.However, the response of the controllerto the event that the desired tempera-ture is reached is to switch off theheater, and this conceptually takesplace at the same instant as the eventoccurrence. Event-response pairs thusmay or may not correspond to the leavesof the function refinement tree, andthere may be refinement relations be-tween event-response pairs.

3.4.3 Declarative and ImperativeSpecifications

Each function is executed when the sys-tem is in some state and leaves the

system in a possibly different state. Itmay accept input from the environmentand may produce output sent to theenvironment. The effect of the functioncan be specified textually in two ways,declaratively or imperatively. In a de-clarative specification, we describe pre-and postcondition pairs, where a pre-condition is a condition on the input andsystem state at the start of executingthe function and the postcondition is acondition on the output and the systemstate after the execution of the function.In an imperative specification, we de-scribe the activities to be performed toget from the input and initial systemstate to the output and resulting systemstate. There are a large number of semi-formal and formal languages to writedeclarative or imperative specifications.We do not review these here but illus-trate the idea by using natural lan-guage.

Figure 17 shows a declarative specifi-cation of the data process Start tempera-ture ramp of the DFD in Figure 7. Theoutputs of this data process are Bool-eans and we use their names to indicatepostconditions. The idea is that if theprecondition is true for the input val-ues, then the data process guaranteesthat the postcondition is true. If theprecondition is false, then nothing isguaranteed. Preconditions and postcon-ditions come in pairs, of which the pre-conditions are preferably mutually ex-clusive and jointly exhaustive of allpossible cases. If they are not mutuallyexclusive, then the postconditions ofoverlapping preconditions must be mu-tually consistent. If they are not jointlyexhaustive, then the effect of the func-tion in some states is not specified.

Figure 18 shows an imperative speci-fication of the same process. It reads thedataflow input, collects the necessarydata from three data stores, and writesa record to another data store. The ad-vantage of an imperative specification isthat, written down in a suitable lan-guage, it leads to an executable specifi-cation that can be validated at an earlystage of development. Its disadvantage

480 • R. Wieringa


is that it specifies a process by giving animplementation for it. For example, theimplementation in Figure 18 gives aparticular order of reading the datastores. This does not decrease the de-signer’s freedom to choose another im-

plementation of the same process but ingeneral what exactly counts as the“same” process is a moot point. To findan equivalent implementation of thesame process, one needs a declarativespecification that says what the input-

Figure 17. A declarative specification.

Figure 18. An imperative specification.



output relation is that must be realizedby the different implementations.

The advantage of a declarative speci-fication is that it is completely imple-mentation-independent. However, itsdisadvantage is that it is an underspeci-fication. The implementor has to figureout what is changed as a result of thefunction and what remains the same.For example, the declarative specifica-tion of Figure 17 says that if precondi-tion 1 is satisfied, then after an execu-tion of the function a new record existsin the store TEMPERATURE RAMPDATA. This does not imply that the restof the data store remains unchanged. Itis a constraint on the next state of thestore that can be satisfied in many dif-ferent ways. The new record may beadded to the existing records, or it mayreplace any or all of them. The declara-tive semantics of new will not tell thisunless we add the frame assumptionthat whatever cannot be inferred fromthe postcondition to change remains thesame. It is not a trivial matter to deter-mine this, especially if the postconditioncontains disjunctions or negations andimplies derived updates. Borgida et al.[1995] summarize the frame problem fordeclarative software specifications. Im-perative specifications do not have theframe problem, because they specify thechange in terms of a sequence of ele-mentary changes whose effect on thevariables is completely specified. For ex-ample, in any specification language,the semantics of the create statementwould be that a record is added to TEM-PERATURE RAMP DATA. This is not aconstraint that can be satisfied in vari-ous ways; it is an instruction that yieldsa definite result.

Whether one needs declarative or im-perative specifications, or both dependsupon what one wants to do with a spec-ification. Declarative and imperativefunction specifications may be used tospecify external system functions, forexample, as part of event-responsepairs, or component functions, such asobject operations. They may also beused to specify state transitions in ex-

tended state machines, as discussed inSection 3.5.4.

3.4.4 Use Case Diagrams. Use caseshave been introduced by Jacobson et al.[1992] in OOSE to represent externalsystem functionality (Appendix B.5) andhave been adopted since then by severalother methods and notations. A use caseis an interaction between the systemand an external entity that has a use forthat external entity. The interactionneed not be atomic. In the terminologyof this article, a use case is the same asan external system function. Use casescan be described by a narrative text, ormore formally by a specification of pre-and postconditions of the use case. Forcomplex use cases, Jacobson et al.[1992] recommend the use of a statetransition diagram. An overview of theuse cases can be given by a use casediagram, that shows for each use casewhich external entities are involved init. Figure 19 shows a fragment of a usecase diagram of the juice plant controlsystem. Figure 20 gives an example of aspecification of the heat the cooking tankuse case, following the Fusion conven-tion [Coleman 1996]. Use case specifica-tions may be supplemented with se-quence diagrams that illustrate thesequence of message exchanges.

A use case diagram actually showssystem functions as well as externalcommunications, and could also havebeen listed in the section of communica-tion specification techniques. Like con-text diagrams, they show communica-tions between the system and itsexternal entities. The difference withcontext diagrams is that a use case dia-gram shows system functions and theircommunications, whereas a context dia-gram shows dataflows between the sys-tem and external entities. One can,however, draw partial context dia-grams, one for each major system func-tion [Yourdon Inc. 1993, p. 170]. Usecase diagrams differ only marginallyfrom these. If a use case diagram iscombined with a function refinementtree, then the use cases should corre-

482 • R. Wieringa


spond to nodes in the diagram. Often,these nodes will not be leaves of thetree, because use cases generally arenot atomic functions.

3.4.5 Summary. Each of the re-viewed techniques draws attention to adifferent aspect of external system func-tionality. A function refinement tree re-lates the overall mission of a system toits functions down to its atomic transac-tions. For each function, it shows whythe system must have that function—torealize its mission. Use case diagramssummarize the communications thattake place during particular functions.All functions can be specified as event-response pairs but it is most efficient todo this only for atomic functions, thatis, transactions. A context diagram canbe used to specify the data exchangesbetween the system and its environ-ment. One may choose to draw one par-tial context diagram for each use case,one for each major system function.

There is no need for formality in func-tion refinement trees, context diagrams,

or use case diagrams. The importantpoint in using these is to follow goodheuristics and not to put more meaningin these diagrams than is intended. Thespecification of event-response pairs isin need of a bit more formality. In par-ticular, the specification of the effects ofevents must be carefully specified, de-claratively or imperatively. When inves-tigating a method, one should look care-fully at the possibility of ambiguity inthe specification technique used forthis. This is important, because custom-ers should get the system functions forwhich they thought they asked.

3.5 Behavior Specification Techniques

Behavior specification techniques canbe used to show how functions of asystem or of its components are orderedin time. This corresponds to the rows ofthe function decomposition table.

3.5.1 Process Graphs. A processgraph is a directed graph with labelededges, in which the nodes represent

Figure 19. Fragment of a use case diagram of the juice plant control system.



states and the edges represent statetransitions. Usually, there is an initialstate, represented by a node that ispointed at by a small arrow. Figure 21shows a process graph that represents amachine with two states and four tran-sitions. The machine is nondeterminis-tic because the start_heating transitionmay or may not lead to another state.

Process graphs may have infinitelymany nodes and from any node, infi-nitely many edges may depart. They areused as interpretation structures forformal specifications in process algebraand dynamic logic [Baeten and Weijland1990; Harel 1979]. Infinite graphs arenot useful as drawing techniques andprocess graphs are not used in any ofthe methods reviewed in this survey.However, they are useful as a steppingstone for the discussion of the finite-statespecification techniques that follow.

3.5.2 JSD Process Structure Diagrams.Process structure diagrams (PSDs) are

used in Jackson Structured Programming(JSP) to represent the structure of filesand of regular programs [Jackson 1975],and in JSD to represent the behavior of asystem in a modular way (Appendix A.6).A PSD is a visual way to represent aregular expression by means of a treediagram. For example, Figure 22 repre-sents the same finite-state process as Fig-ure 21. The leaves of the tree representatomic actions; other nodes representnonatomic processes. Left-to-right order-

Figure 20. Schema for the Heat Cooking Tank use case.

Figure 21. A process graph.

484 • R. Wieringa


ing of nodes represents sequence, exceptif the nodes are labeled with an “o”, inwhich case the nodes represent alterna-tives. Iteration is specified by marking abox with an asterisk. PSDs are used inJSD to represent the lifecycle of entitiesas well as to specify functions of the sys-tem. For example, each process in theSND of Figure 11 would be specified by aPSD.

3.5.3 Finite State Diagrams. Processgraphs assume that the most interest-ing thing about a behavior is the transi-tions, and they do not make any as-sumption about the number of states ina system. State transition diagrams(STDs) assume that the states are atleast as interesting as the transitionsand contain labels for states as well asfor transitions. Finite STDs containonly finitely many states and transi-tions and this makes it possible, at leastin principle, to draw finite STDs on afinite piece of paper. If the number ofstates is very small, this can actually bedone in practice. Figure 23 shows anSTD. The initial state is pointed at by asmall arrow. We now know that thesystem starts in the IDLE state, astart_heating transition may lead the

system to the CONTROLLING state, atimeout transition causes it to iterateover the CONTROLLING state, and anend_time transition causes it to returnto the IDLE state.

3.5.4 Extended Finite State Diagrams.The number of states that can be shownin one STD is usually extremely smallcompared to the number of states inwhich a system can be. The number ofstates can be increased by introducingvariables that may be tested and up-dated by the finite state machine. Thestate of the system now is representedby the state of the STD plus the value of

Figure 23. A finite state transition diagram withlabeled states.

Figure 22. A process structure diagram.



the variables. We speak of the globalstate of the system that consists of theexplicit state, represented by the nodesof the STD, and the extended state, rep-resented by the values of the variables.

There are two ways to add variablesto an STD: by means of local variablesor by means of external variables. Alocal variable is declared together withthe specification of the STD. A methodemploying this technique must definescope rules for these variables. Usually,the scope of the variable is the entirestate machine specification, whichmeans that any transition can containtests and updates of these variables.Some methods allow variables whosescope is a single transition, where theyare used as temporary variables to com-pute a result. Some methods also allowvariables whose scope is a single state,where they are used to hold a resultthat can be used in the next possibletransition. In all these cases, the ex-plicit state represented by a node in thediagram stands for a set of globalstates, one for each possible value of thelocal state variables. Also, in all thesecases, the computations that access andchange the variables are specified aspart of the state machine specification.

The second way to add variables to anSTD is by means of external variables.An external variable is declared outsidethe specification of the STD but can beaccessed by means of special operationsthat act as an interface between thespecification and the variables. Compu-tations that access or update the vari-ables are now external to the state ma-chine. For example, in dataflow models,data stores are external variables withrespect to the control processes in theDFD. This means that a global statechange now requires communication be-tween the state machine and the exter-nal data stores. For example, in theDFD of Figure 7 the dashed circle repre-sents a control process that must bespecified as a finite state machine. Thedashed arrows between the dashed cir-cle and the other diagram componentsrepresent the communications required

to synchronize a transition of this statemachine and changes in the extendedstate.

Generally, object-oriented methodstend to choose the first option. A statemachine is associated with an object,whose local variables (often called in-stance variables or attributes of the ob-ject) act as local variables of the statemachine. SDL also chooses the first op-tion. With some stretch of the imagina-tion, JSD can also be interpreted aschoosing the first option, because eachPSD belongs to an entity, which canhave local variables (called attributes)that may be changed by the actions inthe PSD. Structured methods that usedataflow modeling choose the second op-tion. Statemate uses both options, be-cause statecharts allow local variablesbut activity charts allow data stores andregular activities to manipulate data.

The presence of variables (local orexternal) allows us to refine the specifi-cation of state changes in a number ofways. We list these ways here and giveexamples in Figures 27 to 29.

—A state transition may change thevalues of variables. We saw in Section3.4.3 that changes can be specified ina declarative or imperative way. Ifthe emphasis is on executable specifi-cations, such as for SDL and State-mate, then imperative specificationsare chosen.

—For each transition, a guard may bespecified that says when the transi-tion can occur. There are two inter-pretations of this. In a weak interpre-tation, the transition cannot occur ifthe guard is false. This means that ifthe transition occurred, then we knowthat the guard was true. However, ifthe guard is true, we do not knowwhether the transition can occur. Theguard is in this case a necessary con-dition for the possibility of occurrenceof the transition. In a strong interpre-tation, the transition can occur if andonly if the guard is true. The guard isin this case a necessary and sufficientcondition for the possibility of occur-

486 • R. Wieringa


rence of the transition. During theprocess of building up a specification,we usually specify guards with theweak semantics until we know thatwe have specified all conditions for atransition, at which time we interpretthe conjunction of all weak guards asa strong guard. One way of specifyinga guard is to say that the guard is theconjunction of all preconditions speci-fied for a transition. A guard for atransition may however be strongerthan this conjunction, in which casesome precondition is true of somestates in which the guard preventsthe transition from occurring. It is notdesirable for the guard to be weakerthan the conjunction of preconditions,because in that case there would bestates in which the guard allows thetransition but no precondition ap-plies.

—The presence of variables allows us toinclude tests in a state machine thatare used to determine what the nextstate will be. The next state is thendetermined by the value of the vari-ables. Tests can be used to resolvenondeterminism such as that of thestart_heating transition in Figure 23.The difference between a test and aguard is that a test determines whichof a set of possible transitions willoccur. A test consists of a guard foreach of the possible transitions.

3.5.5 Mealy Machines. State ma-chines never operate in isolation butmust communicate with their environ-ment. This is done by distinguishinginput events, which are received fromthe environment, from output actions,which are sent to the environment. Inall conventions, input events are associ-ated with a transition, meaning that aninput event occurrence triggers the

transition, provided that the transitionguard does not prevent this. The con-ventions for the definition of output ac-tions differ. In a Mealy machine, outputactions are associated with transitions.This is shown in the STD by separatingthe input events from the output actionsof a transition by a horizontal line or bya slash (Figure 24). We call an STD of aMealy machine a Mealy STD. If thereare variables and we wish to define aguard for a transition, this may beadded between square brackets behindthe action. The actions may be updatesof variables or output actions to theenvironment of the machine.

Figure 25 shows a Mealy state dia-gram with a decision state, followingthe YSM convention. The diagram re-fines the state diagram of Figure 23. Itspecifies the control process of Figure 7.The machine is initialized in the IDLEstate and, upon reception of the eventstart_heating, generates output actions,one that triggers the data process Com-pare with desired temperature and onethat enables a continuing data processthat monitors the deadline when theheating will be finished. The machinethen enters the state COMPARING, inwhich it awaits the outcome of the com-parison with the desired temperature.This is called a decision state. Thesestates are necessary because in this ex-ample, the machine cannot do any com-putations itself but must request exter-nal data processes to performcomputations. The outcome of the com-parison is either desired temperaturereached or desired temperature notreached. These trigger a transition tothe CONTROLLING state, turning theheater on or off according to the out-come of the test. The machine then peri-odically receives a timeout at which it

Figure 24. STD of a Mealy machine.



checks whether the desired temperatureis reached and turns the heater on or offaccordingly.

In YSM, there are actions to createand set named clocks. In addition, eachstate of a state machine has a clock thatcounts the time that has elapsed sincethe machine last entered that state. Theevent secs(CONTROLLING)510 is a tem-poral event generated by the state clockof CONTROLLING. It occurs 10 secondsafter the most recent entry in the CON-TROLLING state. When this occurs, themachine checks whether the end timehas been reached. If so, the machinestops monitoring the deadline, turns offthe heater, outputs a signal that heat-ing is finished, and returns to the IDLEstate. If the end time has not beenreached, another cycle of monitoring isinitiated. The condition end_time_reached is a continuous event flow usedin a guard for two transitions of theMealy machine.

If a Mealy machine has many statesor must react to many events, it may beimpractical to draw an STD for it. Onecan then draw a state transition table.There are various layouts for such atable but a commonly used technique isto set off events against states and showin the entries which actions are gener-ated and what the next state is [Hatleyand Pirbhai 1987, pp. 82–83].

3.5.6 Moore Machines. In a Mooremachine, outputs are associated with

states. The meaning is that actions areperformed upon entry of a state. Thismeans that all transitions entering astate will generate the same output. Ingeneral, for every Mealy machine thereis a Moore machine that has the sameinput-output behavior and vice versa[Hopcroft and Ullman 1979, p. 44]. Fig-ure 26 shows an STD of a Moore ma-chine that does the same as the ma-chine of Figure 25. We introduced astate for every output produced. Notethe output action finish controlling instate TURNING OFF, which triggers thetransition to the FINISHED state. Mooremachines are used in the Shlaer–Mellormethod for the specification of objectbehavior (Appendix B.1).

3.5.7 Statecharts. A statechart is hi-graph without intersection but withCartesian products, in which the nodesrepresent states and the directed hyper-edges represent state transitions.2 Nodeinclusion allows us to partition a stateinto substates. Cartesian products allowus to specify parallelism. In addition tothese features, actions can be specifiedalong transitions (Mealy), upon entry ofstates (Moore), and exit of states. Stat-echarts also use local variables to repre-sent an extended state.

2 There is a version of statecharts with intersec-tion, but this is not part of the Statemate lan-guage discussed in this survey [Harel and Kahana1992].

Figure 25. A Mealy machine with a decision state.

488 • R. Wieringa


Figure 27 shows a statechart for thejuice plant controller. In Statemate, astatechart corresponds to a control ac-tivity in an activity chart, just as inYSM a Mealy machine corresponds to acontrol process in a DFD. The MONI-TOR_TEMPERATURE state is parti-tioned into two or-states, HEATER_ONand HEATER_OFF. We assume that thecomparison of the current with the de-sired temperature is done externally byan activity in the activity chart, calledCompare_with_desired_temperature, justas in the DFD of Figure 7. The start_heating event causes a transition intoMONITOR_TEMPERATURE, whose ini-tial state is COMPARING, as indicatedby a small arrow. Upon entry of this

state, the machine starts the activitycompare_with_desired_temperature. Theanswer sent back by this activity deter-mines whether the heater is turned onor off. Note that these actions could alsohave been associated with the HEATER_ON and HEATER_OFF states. The time-out action takes the machine out of anysubstate of MONITOR_TEMPERATURE.The variable end-time must be madeavailable to the statechart as an inputdata flow in the corresponding activitychart, in which this statechart corre-sponds to a control activity.

It is possible that the timeout leavingMONITORING_TEMPERATURE occurs atthe same time as a timeout leavingHEATER_ON or HEATER_OFF. There are

Figure 26. STD of a Moore machine with a decision state.



different possible semantics to resolvethis conflict. The current Statemate se-mantics gives priority to the timeoutleaving the superstate.

Note that monitoring the end time isdone by the statechart itself. This iscontrasted with the DFD in Figure 7,where the activity Monitor deadline isexternal to the control process Controltemperature ramp.

The comparison between the currentand the desired temperature is done byan activity external to the statechart.This is analogous to the DFD of Figure7. Because statecharts allow the decla-ration and manipulation of local vari-ables, a different solution is possible, inwhich the current and desired tempera-tures are made available to the controlactivity through input flows and the

choice to turn the heater on or off ismade by means of a test.

If the control activity must performother jobs in parallel to monitoring thetemperature, then this can be specifiedby adding parallel components. For ex-ample, Figure 28 added a MONITOR_PRESSURE process in parallel to thetemperature monitoring process of Fig-ure 27. This parallel composition cannotbe specified conveniently in one Mealyor Moore machine. In YSM, the DFDwould have to specify a separate controlprocess, with its own Mealy machine,corresponding to the MONITOR_PRES-SURE process in Figure 28.

An action generated by a state transi-tion is broadcast to all parallel compo-nents in the same statechart. This maytrigger other transitions, which in turn

Figure 27. A statechart.

490 • R. Wieringa


may generate other actions. This pro-cess comes to a halt when no more tran-sitions are triggered.

Statemate has defined a large numberof special events, actions, and condi-tions that can be used in statecharts.An event dealing with real time is time-out(e, t), which occurs t time units afterthe most recent occurrence of event e.An action dealing with real time isschedule(e, t), which schedules the evente to occur t time units after now.

Formal semantics of statecharts aredefined by Harel et al. [1987] andPnueli and Shalev [1991]. Beeck [1994]lists over 20 different formal semanticsof statecharts. The semantics used byStatemate is described in an internali-Logix report [i-Logix 1991b]. A sum-mary of this is presented by Harel andNaamad [1996].

3.5.8 SDL State Diagrams. SDLstate diagrams are extended finite state

diagrams with input and output andtimers. They are used in SDL to specifythe behavior of processes in the leafblocks of a block diagram. Figure 29shows an SDL state diagram that de-clares two local variables and two tim-ers. A timer is an object that is ownedby the state machine in whose specifica-tion it is declared, and that can sendtimeout signals to the machine. Thetype Recipe must have been defined inan enclosing block as a record type. Themachine starts in the IDLE state. Whenit receives the input signal start_heat-ing, it initializes the variable desired_temperature by accessing a field of rec-ipe and sets the two timers. Theseinputs must be input signals of the pro-cess in the corresponding block dia-gram. It then tests the current temper-ature and sends out a signal to turn theheater on or off. The test is called adecision in SDL, represented by a dia-

Figure 28. A statechart with parallel substates.



mond. The machine then periodicallyreceives a timeout signal, at which itchecks the current temperature andsets a new timeout. An assignment tovariables or an update of a timer is donein an SDL task, represented by a rect-angle. States are represented by rectan-gles with rounded sides and inputs and

outputs by flag-like symbols, pointinginward or outward. The asterisk statein Figure 29 refers to any state in thecurrent diagram. It is used to specifythat upon reception of a signal of theEndtime timer, it turns off the heater,sends out a signal that heating is fin-ished, and returns to the IDLE state.

Figure 29. An SDL state diagram.

492 • R. Wieringa


Different processes in a block diagramcommunicate through signal routes(Section 3.3.7). An alternative means ofcommunication between processes is byexporting a variable from one processand importing it to another. By execut-ing an export statement, the exportingprocess makes the value of the variableavailable to any process that importsthe variable. When an importing pro-cess executes an import statement, thisreads the value that the variable had atthe most recently executed export state-ment. SDL diagrams have a formal se-mantics, defined as an ITU standard[ITU 1992].

3.5.9 Process Dependency Diagrams.Process dependency diagrams are di-rected hypergraphs in which the nodesrepresent ongoing activities, called pro-cesses, and the edges represent transi-tions between these activities. They areused in information engineering (Ap-pendix A.5) to represent precedence re-lations between activities. Figure 30shows a simple process dependency dia-gram. The event that triggers the pro-cesses in the diagram is represented bya large arrow. The hyperedge leavingstart temperature ramp represents paral-lel execution of the target processesmonitor deadline and turn on heater.There is also a convention for alterna-tive execution of processes. Process de-pendency diagrams allow the represen-tation of cardinality properties ofprecedence relationships. Figure 31shows that the process produce quality

report is preceded by one or more testbatch quality processes, using the tradi-tional crow’s foot notation to representthe cardinality one or more.

A process dependency diagram is sim-ilar to a dataflow diagram in that bothdiagrams represent a collection of re-lated processes. The difference is thatan edge in a process dependency dia-gram represents logical precedence andan edge in a dataflow diagram repre-sents a dataflow. Because of this, pro-cess dependency diagrams are closer tostate transition diagrams, in whichedges represent the transition from oneactivity to another activity. Process de-pendency diagrams can represent trig-gering events, parallelism, choice, andthe cardinality of process connections,none of which can be present in a data-flow diagram. However, process depen-dency diagrams can be extended withdata stores, giving them the appearanceof dataflow diagrams [Martin 1989b, p.271].

Related conventions are used in theMartin–Odell method (Appendix B.6)and in the UML (Appendix B.19). TheMartin–Odell method uses event dia-grams which are similar to process de-pendency diagrams but without event

Figure 30. A simple process dependency diagram.

Figure 31. A process dependency diagram withcardinality.



arrows and without the explicit repre-sentation of cardinalities [Martin andOdell 1995, pp. 118 ff.]. The exact na-ture of a dependency of one processupon previous processes can be specifiedin an event diagram by a control condi-tion. For example, a control conditioncan specify that a process can be per-formed if at least one of the immedi-ately preceding processes is finished, orif all of them are finished.

In the UML, activity diagrams, not tobe confused with SADT activity dia-grams (Section 3.3.3), are defined asstatecharts all of whose states representthe performance of activities and whosetransitions are triggered when an activ-ity is terminated. A similar technique isdefined in Mainstream Objects (Appen-dix B.15). The result is very similar toprocess dependency diagrams withoutcardinalities or events [Rational 1997a].Activity diagrams also allow the repre-sentation of input and output objects ofan activity.

3.5.10 Summary. There is consider-able similarity between the different no-tations reviewed in this section. All no-tations represent states by labelednodes and transitions by labeled di-rected (hyper)edges. The edge labelsrepresent the input event that triggersthe transition, the output actions gener-ated, and possibly the actions performedon local variables. All techniques exceptprocess dependency diagrams have aformal semantics. There is exactly onesemantics of SDL state diagrams laiddown in the standard [ITU 1992], butthere are many different possible se-mantics of statecharts [Beeck 1994].Statecharts are very popular in object-oriented methods but the varieties ofstatechart-like notations defined inthose methods do not all have a pre-cisely defined semantics.

Process dependency diagrams hardlyhave any semantics defined for them.For example, cardinality constraints be-tween processes require a theory ofequality between processes. The state-ment that one process of type P receives

messages from many processes of typeP9 is only meaningful in the presence ofa theory that says when processes arecounted equal and when they arecounted as different. This is the prov-ince of process algebra [Milner 1980;Baeten and Weijland 1990], which is farremoved from the realm of process de-pendency diagrams. Martin–Odell eventdiagrams and UML activity diagramslikewise contain constructs that, at thetime of this writing, are nowhere de-fined precisely. This means that, say,different case tool vendors can imple-ment different execution algorithms forthese diagrams and both claim to imple-ment the “right” semantics.

We skipped over the details of thesemantics of time in state machines.For example, one may choose a point orinterval semantics of time, use a dis-crete, dense, or continuous model oftime, and assume that transitions taketime or are instantaneous. Each of thesechoices leads to important differences inthe behavior specified by a state dia-gram. The semantics of time is carefullydefined in SDL and in the Statematesemantics of statecharts.

Related to this is the variety of com-munication semantics that one can use.We saw already in Section 3.3.10 thatsome methods are not very explicitabout the semantics of communicationdiagrams. The set of choices that can bemade increases if we realize that wemust specify whether input events arequeued upon reception, what happens ifan event cannot trigger a transition,and so on. Any method that employsthese notations must make these se-mantic choices clear. Again, these is-sues are explicitly dealt with in SDLand the Statemate semantics of state-charts.

4. ANALYSIS AND COMPARISON

Appendices A and B review how 6 struc-tured and 19 object-oriented methodsuse the techniques described in the pre-vious section. Tables A.I and A.II ofthose appendices give a quick survey of

494 • R. Wieringa


techniques used in the reviewed meth-ods. In this section, we summarize ourfindings. We start with the way inwhich external interactions and concep-tual decomposition are specified instructured and object-oriented methods.Next, we look at the way behavior andcommunication are specified in eachtype of method. Finally, we take a brieflook at the complexity reduction tech-niques used in the reviewed methods.

4.1 External Interaction Specification

The three relevant aspects of externalsystem interactions are external func-tions, communication and behavior.Looking at the first three columns ofTables A.I and A.II we see that most ofthe techniques employed by differentmethods to specify external interactionscan be freely combined. Structured tech-niques use event-response pairs to spec-ify system transactions (YSM) and afunction refinement tree that relatesthe transactions to the system mission(IE). Event-response pairs can be speci-fied declaratively by means of pre- andpostcondition pairs or imperatively bymeans of executable programs. A state-ment of purpose summarizes the func-tionality of the system by listing theresponsibilities of the system as well asthe functions that the system will nothave. At a greater level of detail, exter-nal communication and behavior can beillustrated with sequence diagrams(SDL), and the details of the dataflowsbetween the system and its environ-ment can be specified by a context dia-gram.

Object-oriented methods have little toadd to this. We noted already that usecase diagrams can be viewed as partialcontext diagrams that show which ex-ternal entities communicate with thesystem during particular functions (usecases). The other addition of object-ori-ented methods is the use of collabora-tion diagrams as an alternative to se-quence diagrams to illustrate externalbehavior and communication of the sys-tem. This pretty much exhausts the

techniques used in the 25 reviewedmethods for the specification of externalinteractions.

4.2 Decomposition Specification

4.2.1 Kinds of Components. The es-sential differences between structuredand object-oriented methods exist in theway they conceptually decompose thesoftware product. Structured analysisuses DFDs to specify system functions.When a DFD contains dataflows be-tween data processes then it actuallyshows a conceptual decomposition inwhich several data processes interact torealize an external function. When itcontains control processes, the DFDcontains event flows that show how thecontrol processes cooperate with otherprocesses to realize external systemfunctions. In both cases, what is shownis not a collection of external systemfunctions but a collection of communi-cating processes that work together torealize external system functions. Thisis why we listed DFDs as a technique tospecify a conceptual decomposition.This view of DFDs is even more justifiedif the DFD is hierarchical, for the DFDhierarchy then actually shows a concep-tual decomposition hierarchy.

Suppose we flatten a DFD hierarchyand reorganize its data processes sothat each data process corresponds toone atomic external system transaction.We ignore control processes for the mo-ment. Then there will be no interfacesbetween the data processes, because dif-ferent data processes correspond to dif-ferent system transactions. Such a DFDis partitioned according to the eventpartitioning principles introduced byMcMenamin and Palmer [1984]. Itshows only what the external transac-tions are and what their interfaces toexternal entities and system memory(data stores) are. Such a diagram stillshows a decomposition, that is, a decom-position of the system into data pro-cesses and data stores. Basically, this isthe separation between memory andprocessor typical of von Neumann com-



puters. We call this decomposition prin-ciple data process separation. In such adecomposition, there are two kinds ofcomponents: data stores that havememory but no activity and data pro-cesses that have activity and no mem-ory. The decomposition principle ofDFDs is actually a bit more complex,because only instantaneous data pro-cesses have no memory. Continuingdata processes may have memory. Nev-ertheless, data process separation is oneof the major decomposition principlesimposed by DFDs.

Data process separation is opposite tothe update encapsulation, in which in-stantaneous data processes are modeledby means of updates that are encapsu-lated with the state that is updated. Itis true that YSM actually uses the con-cept of abstract data type, which encap-sulates the specification of operationswith the operated upon data. Exampleabstract data types are integers, charac-ters, and parameterized types such aslists and sets of items. However, YSMdoes not extend this idea to the encap-sulation of updates with the state thatis updated. We can simulate objects in aDFD by a data store that contains thestate of all instances of an object class,and a number of instantaneous dataprocesses corresponding to the objectupdates that are the only processes toaccess the data store. This simulation isalso a vivid illustration of the differencebetween data process separation andupdate encapsulation.

Note as an aside that update encapsu-lation implies the need for a conceptlike object identity as that which re-mains invariant under all possiblechanges of state. Without such a con-cept, the concept of state change wouldbe meaningless.

Dataflow models are also character-ized by a second separation, that of dataprocesses from control processes. Wecall this the principle of control processseparation. This separation too is abol-ished in an object-oriented decomposi-tion, where a state machine can be spec-ified for each object class, with the

meaning that each instance of that classexecutes an instance of that state ma-chine. Data process separation and con-trol process separation jointly take careof the idea to use external variables forextended finite state machines. Thedata stores act as external variables forthe state machines, and data processesas external updates of these variables.

Putting all of this together, we getthat DFDs use four kinds of compo-nents; data stores, instantaneous dataprocesses, continuing data processes,and control processes. Object-orientedmethods use only one kind of compo-nent, the object, that encapsulates data(local state), updates (local operations),and control (local state machine).

Turning to the other structured meth-ods, we see that information engineer-ing uses DFDs and hence follows thesame decomposition principles as YSM.SADT only recognizes activities as con-ceptual components and hence does notapply the principle of data process sepa-ration or control separation. Statematecontains the principles of data processseparation and control separation, butit in addition allows the encapsulationof a local state with the control pro-cesses. If we drop activity charts fromStatemate models, all data processingmust be encapsulated in statechartsand we get a model that is very similarto object-oriented models. SDL does notcontain the principle of data processseparation or control separation. It doesnot contain separate data stores or dataprocesses at all. Note that althoughSDL state machines encapsulate up-dates, these are not named but are “pro-grammed” as tasks. This differs fromobject-oriented techniques that allowexternal access to object operations bytheir name only. JSD too does not con-tain a separate data store construct nordoes it distinguish data processes fromcontrol processes. Updates are called ac-tions and specified separately fromPSDs.

We conclude that data process separa-tion and control process separation aretypical for DFDs only and do not occur

496 • R. Wieringa


in structured methods that do not useDFDs. Moreover, Statemate, SDL, andJSD all encapsulate updates in theirstate machines, which puts them allclose to object-oriented methods. Be-cause Statemate and JSD do not sup-port the concepts of class or inheritance,we could call them object-based ratherthan object-oriented [Wegner 1992].SDL 92 has moved closer to object-ori-entation because it includes the conceptof inheritance [Møller-Pedersen et al.1987; Færgemand and Olsen 1994].

4.2.2 The Subject Domain. The de-composition of system memory is repre-sented in YSM in two ways, by a decom-position into data stores and by adecomposition into entities and rela-tionships, specified by an ERD. In ob-ject-oriented methods the conceptualdecomposition into objects is alwaysrepresented by a class diagram-likemodel, which is a close relative of theERD. Now, what do these diagrams rep-resent exactly? In Section 3.2.1 it isremarked that one cannot tell by look-ing at an ERD whether it represents adecomposition of the environment of thesystem or a conceptual decomposition ofthe system itself. This ambiguity is re-lated to a fundamental characteristicfeature of software, which we now makeexplicit.

A software system is a system thatmanipulates and stores data. The defin-ing characteristic of data items is thatthey refer to something. A data item is asymbol that has a meaning which is notgiven by nature but laid down in aconvention usually called a dictionary.We call the part of the world to whichthe data refers the subject domain ofthe data. Another frequently used termis universe of discourse (UoD), but westick to the term subject domain here.The subject domain always lies outsidethe software being specified, but it maylie outside or inside the computer.There are exceptional cases where wecan define a symbol that refers to itself,but for software specification thesecases are not interesting. For example,

the subject domain of a personnel data-base system consists of the relevant as-pects of the employees of a company,such as name, address, birth date, sal-ary, and the like, and the subject do-main of a juice plant control systemconsists of the relevant parts of thejuice plant, such as heating and storagetanks, heaters, temperature sensors,and the like. The subject domain of adatabase dictionary, however, is a data-base system, which resides inside acomputer. The subject domain of a soft-ware product may even be an abstractconceptual world that does not exist inthe physical world. For example, thesubject domain of a graph editor con-sists of the set of possible graphs thatcan be drawn.

The subject domain plays an impor-tant role in the decomposition principlesused in object-oriented methods, but thedistinction between the subject domainand the software product being specifiedis not made clearly in most methods.Exceptions are JSD (Appendix A.6),which is the first method in which thedistinction is made explicit, and Syn-tropy (Appendix B.14).

We noted that the meaning of a dataitem is not given by nature but by aconvention according to which peopleagree that a certain observable symboloccurrence stands for something else. Ifwe specify a software system, we mustinclude this meaning convention in ourspecification. This means that we mustinclude a dictionary in the softwarespecification that defines the meaningof data items. The data dictionary usedin dataflow modeling contains such in-formation, but it also contains addi-tional information about data types andrepresentation formats of data, whichhave no meaning in the subject domain.To make clear that we do not have thiskind of data dictionary in mind, we callthe meaning definition of the data itemsa conceptual model. Thus, a conceptualmodel of a software product is a defini-tion of the meaning of the data items interms of the subject domain.

In database modeling, the conceptual



model always takes the form of an ERDand then represents a decomposition ofthe subject domain. This ERD specifiesthe meaning of the data by simply spec-ifying the kinds of things (entities andrelationships) to which the data can re-fer. For every entity or relationship inthe subject domain there will be a corre-sponding surrogate in the database[Hall et al. 1976]. As a consequence, theERD represents a decomposition of thesubject domain as well as the concep-tual structure of the data in the data-base. Note that the ERD can be used torepresent an aggregation hierarchy ofentities and components in the subjectdomain, but that the surrogates thatrepresent these entities all reside at onelevel of the aggregation hierarchy of thesoftware product.

In the specification of control-inten-sive software systems, the subject do-main consists of the entities whose be-havior is to be registered and/orcontrolled. In this case, a decompositionspecification of the subject domain doesnot necessarily correspond with a con-ceptual decomposition of the softwaresystem, because the system does morethan store and remember all eventsthat occur in the life of the subject do-main entities. However, as shown in thefollowing section, one can use a decom-position criterion that produces an iso-morphy between the subject domain andat least part of the conceptual softwarecomponents. Here we note that even ifthere is no such isomorphy, the mean-ing of the data manipulations per-formed by the system must be definedin terms of actual and desired behaviorof entities in the subject domain. Wealways need a conceptual model of thesubject domain to define this meaning.

Note that since in object-orientedspecifications, operations are encapsu-lated with the data they operate on, aclass diagram not only represents themeaning of the data items but also themeaning of data manipulations in termsof the subject domain. For example, JSDmakes a model of the behavior of the

entities in the subject domain beforemaking a model of software objects.

In structured methods of the Yourdonschool, ERDs are used to represent theconceptual structure of the data manip-ulated by the system. The functions ofthe system are represented by a DFD[Flavin 1981; Yourdon 1989; YourdonInc. 1993]. In other structured methods,ERDs are not used. These methods areoriented towards systems that are notdata-intensive. In object-oriented meth-ods, class diagrams are used to repre-sent a conceptual decomposition of thesoftware where the decomposition prin-ciple is that objects in the subject do-main should correspond to conceptualobjects in the software. In JSD and Syn-tropy, the distinction between a subjectdomain decomposition and a softwarespecification is made fully explicit: thedecomposition of the subject domain ismodeled separately from the decomposi-tion of the software product, and thelink between the two is made explicit(Appendices A.6 and B.14).

4.2.3 Decomposition Criteria. Struc-tured and object-oriented methods seemto use quite different decomposition cri-teria for software. A closer look revealsthat this is not the case. We review anumber of decomposition criteria thatare used in structured and object-ori-ented methods.

—In functional decomposition, concep-tual components correspond to systemfunctions [DeMarco 1978]. In thiskind of decomposition, we choose alevel in the function refinement treeand decide that the functions at thatlevel are to be specified as conceptualcomponents. We thus map the hori-zontal dimension of a function decom-position table to the vertical dimen-sion. The result is that the allocationentries in the table appear on thediagonal.

—In event partitioning, each conceptualcomponent corresponds to the pro-cessing between an event and the re-sponse by the system [McMenamin

498 • R. Wieringa


and Palmer 1984]. This is a kind offunctional decomposition, but now wechoose the lowest level in the functionrefinement tree, that of atomic systemtransactions where each transactionconsists of a conceptually atomicevent-response pair. There will be oneconceptual component for each exter-nal system transaction.

—In device-oriented decomposition, oneconceptual component is defined foreach external device to be controlled;the task of the component is to controlthe device [Yourdon Inc. 1993, pp.329, 355, 509]. Since each device cangenerate more than one event towhich the system must respond, thisdecomposition is at a higher level ofgranularity than event partitioning.Unlike functional decomposition, itdoes not group event-response pairsinto more abstract functions, but itgroups them according to the devicethat originates the event.

—In subject domain-oriented decomposi-tion, one conceptual component is de-fined for each external entity aboutwhich data is to be stored or whosebehavior must be controlled [Jackson1983]. This differs from device-ori-ented decomposition, because a deviceconnected to the software system maynot itself be the entity whose behavioris to be controlled, but merely an in-termediary that lets the system andthe subject domain entity communi-cate with each other. Since one entitymay be observed by the systemthrough several devices, this maylead to a decomposition at a higherlevel of granularity. It is a decomposi-tion that in any case stays close to themeaning of the data manipulations ofthe system.

A more detailed exposition of these de-composition criteria is given by Cookand Daniels [1994], Gomaa [1993],Jackson [1983], and Shumate andKeller [1992].

All of these decomposition criteria arecompatible with object-oriented decom-position as well as with the separation

of data stores, updates (data processes),and control characteristics of DFDs.Functional decomposition, event parti-tioning, and device-oriented partition-ing all originate from structured analy-sis. The idea of subject domain-orientedpartitioning was already present inSimula [Dahl and Nygaard 1966], whichstands at the root of the tradition ofstructured programming. The idea led asleeping existence until 15 years laterwhen it became a central partitioningcriterion in JSD, which too has a back-ground in structured programming[Jackson 1975]. It is not difficult tostructure a YSM model according to theprinciple of subject domain partitioningand many examples in the structuredanalysis literature actually use this par-titioning without mentioning it. AllERDs given by Yourdon Inc. [1993] andGoldsmith [1993] use, for example, thisprinciple. To be fair, it should be notedthat they do not partition the data pro-cesses according to the same principle.Events that update the state of entitiesare not encapsulated in the specificationof those entities.

Conversely, object-oriented decompo-sition is compatible with all of the de-composition criteria mentioned previ-ously. It is perfectly possible to definesoftware objects that correspond totransactions, or to devices, to systemfunctions, or to subject domain entities.This is most explicit in Objectory (Ap-pendix B.5), where entity objects corre-spond with subject domain entities, con-trol objects with control functions, andinterface objects with devices. It is alsopresent in other object-oriented meth-ods, but there the distinction betweensoftware objects that represent subjectdomain entities and software objectsthat embody software functions isblurred. For example, Figure 6 is basedupon a class model given by Shlaer andMellor [1992, p. 90]. It includes the ob-ject class Temperature Ramp, which is acontrol process in the DFD of Figure 7.The temperature ramp object really cor-responds to the control process, for thestate diagram specified by Shlaer and



Mellor is equivalent to the state dia-gram of the control process (Figure 25).Nevertheless, the distinction betweensoftware objects that correspond to sub-ject domain entities and software ob-jects that correspond to control func-tions is not made by Shlaer and Mellor.The confusion is even greater in theFusion method (Appendix B.12), wherethe system is defined to be a part of thesubject domain. Magically, the systemcontains software objects whose func-tion is to represent subject domain enti-ties or to act as an interface with thoseentities. These software objects cannotpossibly be part of the domain. Theproblems in teaching Fusion, reportedby Eckert [1996, p. 282], are caused bythis confusion.

The compatibility of object-orienta-tion with different decomposition heu-ristics should not be surprising: usingobjects means that we encapsulate astate and updates of the state into littlesystems called objects. Using a particu-lar decomposition criterion means thatwe are guided in a certain way in choos-ing which objects we have in the sys-tem. The decision to use objects hasnothing to do with the decision of whichdecomposition criterion to use.

We conclude that the use of a particu-lar decomposition criterion is not thedistinguishing feature of structuredanalysis versus object-oriented analysis.The distinguishing feature is the encap-sulation of data, operations, and controlinto objects versus the separation ofthese elements in dataflow modeling.However, we repeat that this is a char-acteristic of DFDs. It follows that DFDsare incompatible with object-orientedtechniques. We already saw that State-mate, SDL, and JSD are structuredmethods that do not use DFDs. They alluse techniques that encapsulate dataprocessing in control processes and ac-cess to the state of control processes isregulated by flows, signals, channels,data streams, and state vector connec-tions.

4.3 Behavior Specification

For the specification of component be-havior we have the same repertoire oftechniques available as for the specifi-cation of external behavior. Generally,external behavior is defined implicitlyas the result of a collection of communi-cating component behaviors. For exam-ple, DFDs and activity charts defineexternal behavior by means of a collec-tion of control processes, SDL definesthe behavior of a system by means of acollection of communicating processesdefined for leaf blocks, JSD defines sys-tem behavior by means of communicat-ing surrogate processes and functionprocesses, and all object-oriented meth-ods define system behavior as the resultof a collection of communicating objects.There are a few exceptions to this.SADT does not define behavior bymeans of state diagrams and somemethods employ process dependency di-agrams to represent behavior that donot localize behavior to single compo-nents. Fusion does not define compo-nent behavior at all in the analysisphase.

Statemate and almost all object-ori-ented methods use statecharts or one oftheir many variants to define object be-havior. Statemate [i-Logix 1991b; Hareland Naamad 1996], Harel and Gery[1996], and Cook and Daniels [1994]give a precise semantics to the notation,including the behavior with respect totime. In all other cases, variants of thenotation are introduced for which pub-lished work does not define a semantics.As a consequence, when different usersof these notations interpret a diagramin different ways, there is no other wayto discover the “true” meaning of thediagram than to ask the original authorof the diagram—which defeats the pur-pose of using the diagram as a means ofcommunication between different peo-ple. Of course, the diagrams can still beuseful to record a half-baked idea fordiscussion, to be made more preciselater.

The semantics of SDL state machines

500 • R. Wieringa


is defined in terms of an underlyingvirtual machine that can execute SDLmodels [Belina et al. 1991]. Similarly,ROOM [Selic et al. 1994] gives a seman-tics to RoomCharts in terms of an un-derlying virtual machine that can exe-cute ROOM models.

4.4 Communication Specification

Communication specification techniquescan be used to specify the communica-tion of the system with external entitiesor to specify communications betweenthe components of the system. Struc-tured methods generally view a systemas a collection of communicating activi-ties. They represent the communicationbetween component activities by meansof a graph in which the nodes representactivities and the edges possible com-munications. Object-oriented methodsview a system as a collection of commu-nicating objects. Behind a confusing dif-ference in terminology, Table A.II showsan overwhelming agreement among ob-ject-oriented methods for the use of se-quence diagrams and collaboration dia-grams to represent sequences ofmessages between objects. The se-quences specified by these diagramsmust be consistent with the specifica-tion of object behavior.

Just as for behavior specification,there is a need for precision in the spec-ification of communication. The issuesinclude synchronous versus asynchro-nous communication, delayed versusimmediate arrival, ordering of messagespreserved or not, handshaking versusmulticast or broadcast, channel capac-ity, queueing of incoming messages, andso on. This precision is provided by thesame methods that define a precise be-havior semantics. Other methods do notgive a precise semantics of communica-tion in their published work. Again, thisdefeats the purpose of using the nota-tion for anything other than organizinghalf-baked ideas in a rough sketch, to beworked out later.

4.5 Complexity Reduction

Large models are simplified by intro-ducing hierarchy. SADT activity dia-grams, DFDs, Statemate activitycharts, and SDL block diagrams all in-troduce hierarchy in more or less thesame way information engineering sim-plifies large ERDs by partitioning theminto subject areas, Shlaer and Mellorintroduce domains, and in the UML,large class diagrams are simplified byparceling them into packages. An im-portant issue is whether the hierarchyis a convenient way of organizing alarge description or whether it repre-sents a hierarchy of subsystems. SDLallows both interpretations [Belina etal. 1991, p. 11]; the other techniquesview it as a convenient way of organiz-ing a large description. Shlaer and Mel-lor, Syntropy, and Octopus introducethe concept of a subsystem as a way ofpartitioning a large system into simplerparts.

5. DISCUSSION AND CONCLUSIONS

This survey has shown that systemsengineering offers a framework inwhich to integrate the techniques ofstructured and object-oriented softwarespecification. The framework simplysays that the system under develop-ment must be viewed as an aggregationhierarchy of subsystems, and is itself asystem in such a hierarchy. To specifyand design the system, we must specifydesired external interactions, specify adecomposition, and allocate external in-teractions to component interactions.An issue that seems to divide structuredfrom object-oriented design is the use offunctional decomposition versus sub-ject-domain decomposition. It is arguedin Section 4 that this is not an essentialdivision, as both heuristics can be usedin object-oriented as well as structuredmethods. The essential division lies inthe use of the DFD technique.

DFDs and their close relatives, activ-ity charts, are incompatible with theuse of object-oriented decomposition be-



cause of the presence of data processseparation and control separation. TheDFD technique forces the analyst to dis-tinguish, at some level of the aggrega-tion hierarchy, data stores from dataprocessing components and at thatlevel, we get a decomposition that isincompatible with the object-orientedphilosophy. All other reviewed tech-niques are compatible with the struc-tured as well as the object-oriented phi-losophy of software specification and,with the exception of SADT activity dia-grams, we encounter the same tech-niques in structured and object-orientedmethods. Note however that DFDs arealso recommended by a number of ob-ject-oriented methods. This blurs theline between structured and object-ori-ented methods even on this point.

The technique most congenial to ob-ject-oriented decomposition is the ex-tended finite state diagram, becausethis allows the specification of localstate, state transitions, and behavior.We have seen that this technique isused in some structured and most ob-ject-oriented methods. Again, this blursthe dividing line between structuredand object-oriented methods. The con-clusion is that object-oriented methodshave adopted structured techniques in anew guise. We can benefit from makingthis “technology transfer” explicit. Onebenefit is that this allows us to pinpointthe agreements and differences betweenstructured and object-oriented methods,as we have done in this article. Thisshould ease the transition from struc-tured to object-oriented techniques or,better still, it should ease the eclecticuse of techniques from both approaches.

Following up this last suggestion, howcan one get the best of both worlds?First, it has been shown here that struc-tured and object-oriented techniques forthe specification of external systemfunctionality can be easily combined.The statement of purpose, function re-finement tree, event-response list, de-clarative specification of input-outputrelations, use case diagram, and contextdiagram all express some interesting

property of the system. Also, the analy-sis in this article has at least madeplausible that the properties expressibleby these techniques are related in asimple manner and that it is feasible todefine a set of coherence rules that linkspecifications of different views of theseproperties. Definition of these coherencerules requires a more precise semanticsof the notations than is now availableand is the subject of current research. Itshould be emphasized that even whensuch a precisely defined set of coherencerules is available, that this does notmean that in all cases we should use allof these techniques at the same time.However, it does mean that in eachindividual specification we can use anyconvenient combination of these tech-niques.

In the case of conceptual system de-composition, there is more variety. Nev-ertheless, there is an overwhelmingagreement that the decomposition mustbe represented by a class diagram, com-ponent behavior by a statechart, andcomponent communication by sequenceor collaboration diagrams—more or lessthe UML way of specifying decomposi-tion. However, the sheer number ofmethods that propose something likethis structure indicates a problem: theyare all different methods. What makesthem different is that each method de-fines its own syntactic variation of someof the techniques, and gives its owninterpretation to it. Some of the syntac-tic idiosyncracies are quite complex, andsome of the methods only give a vagueindication of the semantics of their tech-niques and other methods do not give asemantics at all. Nor are the methodsvery clear about the way in which theirtechniques must be connected into onecoherent system specification.

The response of industry to this vari-ety has been to start a standardizationprocess [OMG 1996]. This led to theUnified Modeling Language (UML Ver-sion 1.1, see Appendix B.19), which con-sists of the original UML submission(Version 1.0) and elements of five othersubmissions. As standardization efforts

502 • R. Wieringa


go, the result of standardization is oftena compromise between parties with dif-ferent interests and this is usually notthe simplest possible solution.

The research issue that evolves fromthis is that current and future notationsshould be given a precise semantics.Each notation used in software specifi-cation should have an unambiguous de-clarative semantics that tells us what itmeans, and does not leave room for in-dividual variations in meaning that ex-ist only in the mind of the reader orwriter. Whenever such variations exist,something is bound to go wrong in thecommunication from user to analyst todesigner and programmer. A secondreason for having a precise semantics isthat the value of a specification is con-siderably enhanced if it can be executed.For this to take place, the notationshould have an operational semanticsthat is equivalent to its declarative se-mantics, and that can be used to de-scribe the behavior of the interpreter orcode generator. It is important thatthese semantics are formal, because am-biguities in this early specificationstage may lead to expensive errorslater. The only way to eliminate ambi-guity is to be formal.

We should add that this does not im-ply that the reader of the specificationmust know all the formal details of thesemantics. Meyer [1985] has shown thatformal descriptions can be translated inclear and unambiguous natural lan-guage descriptions that can be used tocommunicate the meaning of a specifi-cation to people not schooled in formalspecifications. Similarly, a diagram-matic specification that has a formalsemantics can be used to clearly andunambiguously communicate a meaningto people not schooled in formal specifi-cations. Diagram techniques with for-mal semantics combine the best of theworlds of semiformal and formal specifi-cation [Harel 1992].

Having argued for the need for for-mality underlying semiformal notationtechniques, it is only a small step toargue for simplicity as well. It is all too

easy to add numerous annotations,adornments, and extensions to graphi-cal techniques. However, every such ad-dition makes it more difficult to define aformal declarative or operational se-mantics of the notation. And until aformal semantics has been defined, theextension cannot be used for the job it isintended to perform, that is, communi-cate a meaning clearly and unambigu-ously from one person to another. Froma research point of view, the way to gois to define the simplest technique pos-sible that still is of use to the specifier,and give this a formal declarative andpossible operational semantics. One ad-vantage of simplicity is that it should berelatively easy to define such a seman-tics. Another advantage, not to be dis-counted, is that it should be easy forspecifiers to remember the meaning anduse of the notation—and for differentspecifiers to remember the same thing.Specifiers in real development projectshave enough to think about and shouldnot be bothered with overly complexspecification techniques. Not unlike in-cremental development of software sys-tems, the simple core notation could beincrementally extended to suit theneeds of the specifier, all the time tak-ing care that the extensions have a for-mal semantics. There is no reason toexpect that these incremental exten-sions will be universally useful. Morelikely, we can expect different exten-sions to emerge for different domains.

There are a few efforts to define aformal semantics for diagram notations.Most notable is the formal semantics ofstatecharts used in Statemate [i-Logix1991b; Harel and Naamad 1996] and ofa more recent object-oriented version ofstatecharts [Harel and Gery 1996,1997]. Another influential diagramtechnique with a formal semantics isSDL. Less widely used but very inter-esting is the formal semantics given toOMT models by Cook and Daniels[1994]. In addition, there are a numberof formalizations of structured tech-niques [France 1992; France and Lar-rondo-Petrie 1994] and of object-ori-



ented techniques [Bates et al. 1996;Bourdeau and Cheng 1995; Wieringa etal. 1993; Wieringa and Saake 1996]. Animportant unsolved point in the formal-ization of object-oriented class models isthe precise meaning of behavior special-ization. Preliminary investigations arepresented by Ebert and Engels [1997],McGregor and Dyer [1993], Schrefl andStumptner [1995], and Saake et al.[1994]. Møller-Pedersen et al. [1987] de-scribe the solution used in SDL92 andCook and Daniels [1994] define the so-lution used in Syntropy. However, it issafe to say that a satisfactory solutionhas not yet been found. We shouldstress that formalization of a diagramtechnique cannot be a useful goal initself. The formalization must always becombined with a motivation that thediagram technique is useful for somepurpose.

This brings us to another interestingresearch topic, the definition of criteriato choose among the techniques avail-able to the software engineer. It is clearthat specification of data-intensive soft-ware can benefit from the use of ERDsor class diagrams, and that the specifi-cation of control-intensive software canbenefit from the use of STDs and com-munication diagrams. To give more de-tailed advice, however, the semantics ofthe notations should be defined pre-cisely. Just as formalization should beguided by the potential uses of the nota-tion, the guidelines for using the nota-tion should be motivated by the formalsemantics.

APPENDIX A. A CATALOGUE OFSTRUCTURED SPECIFICATION METHODS

In this appendix and the next, we usethe bold font to indicate columns inTables A.I and A.II and italics to indi-cate entries in these columns.

A.1 SADT

Structured Analysis and Design Tech-nique (SADT) is a method to function-ally decompose the activities to be per-

formed by a system into subactivities[Marca and Gowan 1988; Ross 1977,1985]. SADT uses one diagram tech-nique, the activity diagram (Section3.3.3), for the representation of externalfunctions, conceptual components (ac-tivities), and communication betweenthose components. The highest-level ac-tivity diagram represents the overallfunctionality of the system, its inter-faces, and the mechanisms that it usesto realize its functionality. The lower-level diagrams describe the decomposi-tion into subactivities, their communi-cation by means of flows, and themechanisms used by the subactivities.The subactivities are recursively decom-posed until a clear understanding of theactivities to be performed by the systemis reached. We consider the activities tobe conceptual components, so that theactivity diagram shows a conceptual de-composition of the system into func-tional activities.

The original proposal for SADT envis-aged a duality of data and activities.Diagrams with the same syntax as ac-tivity diagrams were used to representdata and the way they are connected byprocesses [Ross 1977]. This kind of dia-gram does not seem to be used anymore, and it is not mentioned by Marcaand Gowan [1988].

A.2 The Yourdon Systems Method

The Yourdon approach to structuredanalysis started in the late 1970s withDeMarco [1978], Weinberg [1978], Your-don and Constantine [1979], and Ganeand Sarson [1979]. Flavin [1981] intro-duced data modeling concerns. Majoradvances were achieved by McMenaminand Palmer [1984], who introduced theheuristics of essential systems modelingand event partitioning, and Ward andMellor [1985], who introduced real-timespecification techniques. Yourdon[1989] summarized the method. TheYourdon Systems Method (YSM) is amore recent and extensive statement ofstructured analysis for real-time sys-tems [Yourdon Inc. 1993]. Other ver-

504 • R. Wieringa


sions of structured analysis for real-time systems are presented by Gomaa[1993], who gives a number of impor-tant design heuristics, and by Hatleyand Pirbhai [1987], who add system-level considerations. Shumate andKeller [1992] integrate the Hatley–Pirb-hai approach with other approaches tostructured analysis.

A YSM model of the external func-tions consists of an informal but con-cise specification of the system purpose,and an event-response list (Section3.4.2). In terms of the function decompo-sition table, the top row of the tablelists all the event-response pairs, eachof which is a system transaction. Exter-nal communications are representedby a context diagram (Section 3.3.2). Ifthere are too many external entities orinterfaces to show on one diagram, thenone can show a set of partial context

diagrams, one for each major subfunc-tion of the system.

The conceptual decomposition isrepresented by a dataflow diagram(Section 3.3.1), which represents theactivity performed during a systemfunction (an event-response pair). Theleftmost column of the function decom-position table thus lists all data stores,data processes, and control processes.In addition, an entity-relationship dia-gram (Section 3.2.1) shows the concep-tual structure of the data manipulatedduring this activity. Dataflow and enti-ty-relationship diagrams would be ac-companied by textual specifications not-ing the functions of the data processes,the contents of the dataflows and datastores, and the conceptual structure ofeach entity type and relationship. Thereis also a data dictionary that defines the

Table A.I. Structured Software Specification Methods



meaning of all names that occur in theDFD and ERD.

Different authors state different rulesfor connecting an ERD with a DFD in acoherent YSM model. The source mostexplicit about this, Yourdon Inc. [1993,

pp. 309–314], states merely that theERD must describe the conceptualstructure of all data manipulated by thesystem. One may set up the model insuch a way that for each entity type andrelationship there is a data store that

Table A.II. Object-Oriented Software Specification Methods

506 • R. Wieringa


contains the instances of that type. Thisis the way in which Figures 7 and 5 arerelated. However, there may be a many–many relationship between the compo-nents of an ERD and the data stores. Inaddition, an ERD may describe the con-

ceptual structure of the data that sur-vive a single system transaction (storedin a persistent data store) or that existonly during a transaction (passingthrough a dataflow or stored in a tempo-rary data store).

Table A.II. Continued



Only continuing data and control pro-cesses have behavior over time. In-stantaneous processes do not have aninternal state, so that they always givethe same response to the same input.The behavior of a continuing data pro-cess is specified by a minispec, whichcan follow any format, such as a pre- orpostcondition specification for the ini-tial action when the process is started,and a pre- or postcondition specificationfor the continuing transformation[Yourdon Inc. 1993, p. 250]. The inter-face of the transformation must corre-spond to the interface of the data pro-cess in the DFD. A continuing controlprocess is specified by a Mealy machine(STD or state transition table). Theevents and actions of the Mealy ma-chine must correspond to the interfaceof the control process in the DFD.

YSM also allows the specification ofthe behavior of entities. For each entitytype in the ERD, an entity state dia-gram can be defined, which is a Mealymachine that regulates the accessesmade to the instances of the entity type.

The functions of the conceptual com-

ponents are specified differently for dif-ferent kinds of components. There arealtogether five kinds of components ofDFDs: data stores, instantaneous andcontinuing data processes, and instan-taneous and continuing control pro-cesses. The functions offered by datastores are the ability to create, read,update, and delete records in the store.There is no need for a specification ofthese data store functions. Instanta-neous data processes compute the samefunction every time they are executed.This function is specified in a minispec,which may be declarative or imperative(Section 3.4.3). This technique can alsobe used for specifying continuing dataprocesses. The elementary functions of-fered by continuing control processesare the transitions in their state ma-chine and these are specified in an STDor a state transition table. An instanta-neous control process is simply a deci-sion table and can be specified as such.In all these cases, the interface of theminispec or decision table must matchthe interface of the corresponding pro-cess in the DFD. There is as yet no

Table A.II. Continued

508 • R. Wieringa


definitive precise formulation of this co-herence rule.

The communication between compo-nents is represented by the DFD. Wecan draw one DFD fragment for eachevent-response pair, which correspondsto one column in the function decompo-sition table. This is what is done inevent partitioning. Each such DFDshows the communications that takeplace between the conceptual compo-nents during the transaction.

The accesses that are made to a datastore during a system transaction aresummarized in YSM by a function-entitytable, which lists external functionsagainst entity types and relationships,and in the entries shows whether in-stances of these types are created, read,updated, or deleted during the transac-tion. This is a restriction of the functiondecomposition table to the data storecomponents.

A.3 Statemate

Statemate is a software toolkit and anotation for structured analysis. AStatemate specification consists of ac-tivity charts (Section 3.3.4), statecharts(Section 3.5.7), and module charts. Com-pared to the Yourdon school of struc-tured analysis, activity charts play therole of DFDs, statecharts play the roleof Mealy machines, and module chartsplay the role of architecture diagrams ofHatley and Pirbhai [1987] and Shumateand Keller [1992] (not treated in thissurvey). In the interest of executabilityof the specification, actions performedby statecharts are defined imperatively.The execution semantics of Statematemodels is defined formally [i-Logix1991b; Harel and Naamad 1996].

The language of statecharts is consid-erably richer than the Mealy machinenotation used in other methods of struc-tured analysis. Statemate does not con-tain a notation corresponding to ERDs.The way in which Statemate puts activ-ity charts and statecharts together intoa coherent model differs in details fromthe way this is done in other structured

analysis methods but on the whole, themodel structure is the same as the wayDFDs and Mealy machines are put to-gether in YSM. The general remarksmade for YSM, minus the discussion ofERDs, therefore also apply to Statemate.

A.4 SDL and Message Sequence Charts

The development of SDL (Specificationand Description Language) started in1972 and resulted in 1976 in a standardissued by the CCITT (InternationalTelegraph and Telephone ConsultativeCommittee). Since then, revisions andextensions were defined first by theCCITT and then by the ITU (Interna-tional Telecommunication Union) atfour-year intervals [Belina et al. 1991;Bræk and Haugen 1993]. Sarraco andTilanus [1987] and Belina and Hogrefe[1988–1989] give tutorials on SDL 88and Færgemand and Olsen [1994] onSDL 92. A rationale for the object-ori-ented features of SDL 92 is given byMøller-Pedersen et al. [1987]. SDL is alanguage, not a method. However, somemethod guidelines are published by theITU as an appendix to the SDL defini-tion [ITU 1993]. Saracco et al. [1989]and Turner [1993] give many examplesof and heuristics for the use of SDL.

The external behavior and exter-nal communication of a system can bedescribed by message sequence charts(MSC) [ITU 1994]. These are sequencediagrams (Section 3.3.8), used to de-scribe sequences of possible interactionsbetween the system and its externalentities. Each such sequence is an illus-tration of the behavior in which thesystem must be able to engage.

The conceptual decomposition of asystem is represented by a block dia-gram (Section 3.3.7). In the same wayas hierarchical DFDs, block diagramsrepresent the system as a hierarchicaldecomposition into blocks. Each leafblock in the block decomposition treecontains one or more processes. Aspointed out in Section 3.3.7, block dia-grams may be used to represent thesystem decomposition or they may be an



organizing principle of the specificationof external system behavior.

At each level, the component com-munication is represented by channelsbetween blocks or signal routes betweenprocesses. (SDL allows implicit signalroutes that are not represented visu-ally.) Communication through channelsmay involve delay. Communication be-tween processes goes through signalroutes, which experience no delay. How-ever, each process has an unboundedinput queue of messages that are wait-ing to be processed. Upon sending, asignal immediately arrives at the inputqueue of its receiver but may then haveto wait for some time before it is pro-cessed. As mentioned in Section 3.5.8,processes have an alternative means ofcommunication, defined by means of ex-ported variables.

The behavior of a process is definedby means of an SDL state diagram (Sec-tion 3.5.8). The interface of a state dia-gram must match the interface of thecorresponding process in the block dia-gram. The behavior of each leaf block isdefined totally by the joint behavior ofits processes and the way these are con-nected by signal routes to each otherand to the block environment. The be-havior of each nonleaf block follows fromthe behavior of its subblocks and the waythey are connected by channels to eachother and to the block environment.

The semantics of SDL models is de-fined in terms of an underlying virtualmachine upon which the model can beexecuted.

A.5 Information Engineering

Information engineering (IE) is a struc-tured method for modeling the informa-tion needs of a business, specifying in-formation systems that meet theseneeds, and designing, constructing andintroducing these systems in the busi-ness [Martin and Finkelstein 1981;Martin 1989a,b,c]. In this survey, wedeal with information system specifica-tion only. To deliver the information

systems that a business needs, IE firstabstracts from current and future sys-tems and identifies business functionsand their information needs indepen-dently from the way these are realized.This is represented by a function refine-ment tree (Section 3.4.1), which refinesthe business mission into business func-tions and refines these into businessprocesses. The subject domain of thebusiness—the part of the world that thebusiness must maintain data about—isrepresented by an entity-relationshipdiagram. The function tree and ER dia-gram are then correlated by means ofan entity-function table that shows theuse that each business process makes ofbusiness data. The table can be parti-tioned into coherent parts called busi-ness areas. Each business area is mod-eled in more detail by a processdependency diagram (Section 3.5.9) anda more detailed ER diagram (Section3.2.1). These more detailed processesand entities are correlated by an entity-process table. If the business area is toobig to be implemented by one informa-tion system, it is partitioned into sev-eral information systems called busi-ness systems.

Thus, the external functionality ofan information system is represented bya function refinement tree and its con-ceptual decomposition is specified byan ER diagram and a process depen-dency diagram. The process dependencydiagram also specifies the external be-havior of the information system. Itdoes not specify the behavior of the sys-tem components but shows how piecesof externally observable processes areordered in time. These processes arecomponents of the conceptual decompo-sition of the system. Finally, the processdependency diagram also shows howthese processes communicate.

An interesting phenomenon of IE isthat the conceptual decomposition of theinformation system corresponds to thedecomposition of the subject domain ofthe business. The conceptual decomposi-tion of the information supply functionof the business is found by decomposing

510 • R. Wieringa


the subject domain. The ERD of thesubject domain is then used to partitionthe information supply function intobusiness areas and these into businesssystems. This data-orientation is a cen-tral tenet of IE: whereas business proce-dures change rapidly, data types arerelatively stable [Martin 1989a, p. 58].This principle is also central to JSD,discussed next, and of object-orientedmethods.

A.6 Jackson System Development (JSD)

Jackson System Development (JSD) isan elaboration of Jackson StructuredProgramming (JSP) to the system level[Jackson 1975, 1983]. In JSD, the sub-ject domain of a software system is mod-eled as a set of communicating entities.Each subject domain entity is modeledas a finite state machine by means of aprocess structure diagram (Section3.5.2). Entities may have attributes,which can be updated only by an actionin the PSD of the entity. Entities com-municate synchronously by sharingcommon actions. Entities are alwaysclassified into types and the PSD isalways specified for a type.

In order to define a decompositionof the system, for each UoD entity, thesoftware product contains a surrogatethat performs the same process as theUoD entity. (“Surrogate” and “PSD” arenot JSD terms.) Each surrogate processis described initially by the same PSDas its corresponding subject domain en-tity. When system functions are speci-fied, these PSDs may be extended. Inaddition, the software product containsfunction processes, also described byPSDs. These communicate with the sur-rogate processes through various kindsof connections, represented by a systemnetwork diagram (SND) (Section 3.3.6).

There are thus two kinds of concep-tual components, surrogate processesand function processes. It is argued byJackson [1983, pp. 11–12] that this dis-tinction leads to more maintainable sys-tems than models based upon functional

decomposition. For example, changes tofunctions will often be constrained tothe function processes and leave thesurrogates unaffected.

The component functions are theatomic operations by which a surrogateparticipates in an external system func-tion; they are different from the atomicoperations by which a function processparticipates in an external function.During the execution of an external sys-tem function F, a surrogate s may per-form one action, which is a leaf node ofits PSD. This action is an atomic opera-tion that can stand on its own as anupdate transaction. During an externalfunction, on the other hand, a functionprocess may completely execute itsPSD. For example, if the function pro-cess is a query that should report on thestate of a number of surrogates, thenthe PSD for that function will specifyimperatively how the function willsearch through the surrogates. When-ever the function process does some-thing, this function executes its entirePSD. In other cases, a function processmay be long-running, so that each timeit does not execute its entire PSD butonly a part of it. In general, the actionsin a function process cannot stand ontheir own as system transactions butare only part of an imperative specifica-tion of a system transaction.

The behavior of a surrogate is speci-fied by a PSD that describes its life-cycle. Some function processes may alsobe long-running, in which case theirPSD also describes the behavior of thefunction process over time; that is, itorders several atomic pieces of behaviorof the function process in time.

Communication between compo-nents is represented by an SND, one foreach external system function. ThisSND corresponds to a column in thefunction decomposition table. The struc-ture of the SND is very similar to thestructure of an event-partitioned DFDthat could be drawn for the externalfunction.



APPENDIX B. A CATALOGUE OF OBJECT-ORIENTED SPECIFICATION METHODS

B.1 Shlaer–Mellor 1988, 1992

Shlaer and Mellor [1988] define an ob-ject-oriented variant of informationmodeling [Chen 1976; Flavin 1981].Shlaer and Mellor [1992] extend thiswith techniques for the specification ofobject behavior and object communica-tion, and add the concepts of domainand subsystem. Additional informationon the Shlaer–Mellor method is givenby Lang [1993], Shlaer and Mellor[1989], and Shlaer and Lang [1996].

Shlaer and Mellor partition complexsystems into domains, where a domainis defined as a part of the world with itsown conceptual space of rules and poli-cies. Example domains are the imple-mentation domain (programming lan-guages, operating system, databasemanagement systems, etc.), the servicedomain (containing utility functions foruser interfaces, data archiving, etc.),and the application domain (e.g., a juiceplant). The application domain is whatwe call the subject domain in this sur-vey. Large domains can be further par-titioned into subsystems that have closecohesion and loose coupling. Each sub-system is modeled as a collection ofcommunicating objects.

The decomposition into objects ofa subsystem is represented by an infor-mation model, which uses a variant ofthe ERD notation (Section 3.2.1). Thereare special objects called timers thatcan be created to count the time remain-ing to a deadline. Timers are not speci-fied in the information model.

Object behavior is represented by astate model, which is a Moore state ma-chine (Section 3.5.6). Thus, a transitionbetween states is triggered by an eventarriving at the object and upon arrivalin a state, an action may be performed.

Object operations are actions asso-ciated with a state. Each action is spec-ified by means of a piece of executablecode associated with the state (Section3.4.3). An action may read or update the

state of any object in the subsystem, itmay create an object, and it may sendan event to any object (including itself)or to an entity outside the subsystem[Shlaer and Mellor 1992, p. 45]. Actionstake time to execute in OOA. Each statemodel corresponds to a row in the func-tion decomposition table, for it showsthe behavior of a component.

In addition to the code associatedwith a state, an action dataflow model(ADFD) is specified for each action. Thisis a dataflow model that is used to spec-ify the data processing done by an ac-tion. A data store in an ADFD corre-sponds to an object class (it holds allinstances of the class), to a timer object,or to the current time. A process in theADFD corresponds to an elementarycomputation performed during the ac-tion. If an ADFD showed what one ob-ject action does, it would correspond to acell in the function decomposition table.However, the ADFD also shows howother objects are accessed (read orwrite), so it represents a part of whatgoes on in the life of other objects aswell. In fact, ADFDs are used to specifyobject actions in the same way as YSMuses a DFD to specify external systemfunctions. ADFDs thus introduce func-tional decomposition in the model,where the decomposition criterion isvery fine-grained: each action of eachobject is functionally decomposed intoan ADFD. This makes the model con-ceptually difficult, because each ADFDseparates data storage and data pro-cessing in a way that goes counter tothe object-oriented philosophy. The rea-son for introducing this difficulty is notclear, because actions are already speci-fied by means of code associated to astate.

Object communication is shown bymeans of two models. The object com-munication model (OCM) shows themessages sent and received by the statemachines of the objects. This is repre-sented by an object communication dia-gram (Section 3.3.5). Communicationbetween objects via events is asynchro-nous. Events received from one object

512 • R. Wieringa


are processed in the order in which theyare sent, but events received from dif-ferent objects may be processed in anyorder [Shlaer and Mellor 1992, p. 107].External entities are included in theOCM, so that it also shows the exter-nal communications of the system.Except for the representation of exter-nal entities, all information in the OCMcan be derived from the information inthe state model. There is one OCM forthe entire specification.

The second kind of communicationmodel is the object access model (OAM),which shows accesses to object datastores made by processes in the ADFDsfor the actions of an object. This is rep-resented by a directed graph in whichthe nodes represent object classes andthe edges represent synchronous accessof one object by another. These commu-nications are synchronous. The OAMcan be derived from the ADFDs. Thereis one OAM for the entire model.

B.2 Coad–Yourdon 1990

Coad and Yourdon [1990] use a kind ofclass diagram (Section 3.2.2) to repre-sent the conceptual decompositionof the system into objects. The samediagram is also used to specify objectcommunications. Large class dia-grams can be partitioned into chunkscalled subjects. A class icon contains thename of the class and the attributes andoperations (called services) of the ob-jects of the class. Service specificationsare declarative natural language de-scriptions of object operations.

B.3 Booch 1991, 1994

Booch represents the structure of a soft-ware system by means of a class dia-gram and the behavior of the objects bymeans of state diagrams. Booch [1991]uses simple state diagrams, whereasBooch [1994] uses a statechart-like no-tation. Communication is representedby Booch [1991] by timing diagrams andby Booch [1994] by sequence diagrams.Timing diagrams resemble sequence di-

agrams turned on their sides. We dis-cuss the 1994 version of the Booch nota-tion.

The conceptual decomposition ofthe software into objects is representedby a class diagram (Section 3.2.2).Booch uses a dotted cloud symbol torepresent the classes. As usual, this canbe annotated with the class name, at-tributes, and operations, possiblyadorned with symbols that indicate howthe class is to be implemented in aprogramming language. Classes can beparameterized and Booch distinguishesmetaclasses. The diagram can be anno-tated by various kinds of constraints.The full notation contains a consider-able number of icons and symbols, themeaning of which is informally ex-plained.

Object behavior is specified by astate transition diagram, for whichBooch uses a statechart-like notation(Section 3.5.7). Booch does not use Car-tesian products to represent parallelismbecause he claims that parallelism isalready sufficiently represented by theparallelism of objects. His notation istherefore not able to represent intra-object parallelism.

Classes can be specified textually in aprogramming language. Object opera-tion specifications are part of thisspecification.

Object communication is repre-sented in two ways. An object diagramis a collaboration diagram (Section3.3.9) that can be used to show the flowof messages during a scenario of thesystem’s behavior. They can be anno-tated with dataflows, the communica-tion mechanisms to be used, visibilityrelations between the objects, and con-straints on the links between the objectsin the diagram. Communication can besynchronous or asynchronous. Severalother kinds of communication are recog-nized. The other way to represent com-munication is by means of an interac-tion diagram, which is a sequencediagram (Section 3.3.8). These containroughly the same information as objectdiagrams.



B.4 OMT 1991, 1995

The object modeling technique (OMT)was introduced by Loomis et al. [1987]and popularized by Rumbaugh et al.[1991]. We refer to this version of OMTas OMT91. A significant update waspublished several years later [Rum-baugh 1995c,a,b). We refer to this asOMT95.

The decomposition of the systeminto objects is represented by the objectmodel, which is a class diagram (Section3.2.2). The behavior of instances ofclasses is represented by the dynamicmodel which is a statechart variant(Section 3.5.7). Events in the statemodel can be represented as operationsin the object model [Rumbaugh et al.1991, p. 110]. Statecharts are inheritedby subclasses but the precise mecha-nism by which this happens is not de-fined [Rumbaugh et al. 1991, p. 111].We already observed in Section 5 thatbehavior inheritance is one of the un-solved problems of object-oriented spec-ification.

Object operations are defined bythe functional model. This is a DFD(Section 3.3.1) that shows which compu-tations are performed by the systemduring an external system function.Just like ADFDs in the Shlaer–Mellormethod (Appendix B.1) the DFD intro-duces a functional decomposition intothe model. However, where Shlaer–Mel-lor advise us to define a functional de-composition for each action, OMT givesno heuristic for the functional decompo-sition. The connection between the func-tional model and the other two modelsis ill-defined. Objects in the objectmodel are viewed as components of thesystem, and object operations corre-spond to the processes in the DFD[Rumbaugh et al. 1991, p. 137], how-ever, objects in the object model areviewed as external entities in the func-tional model and object operations cor-respond to data flows to and from exter-nal entities [Rumbaugh et al. 1991, p.138]. This matter has never beencleared up and in OMT95, the func-

tional model as we know it from OMT91disappeared.

OMT95 can be viewed as a halfwaystation between OMT91 and the UML.The object model of OMT95 containssome extensions with respect to OMT91[Rumbaugh 1995b]. It now contains aclass diagram as well as object dia-grams, with which instances can be rep-resented. It also contains conventions torepresent parameterized classes and torepresent subsystems.

In the dynamic model, scenarios playa more prominent role and use caseshave been adopted. Event trace dia-grams can be annotated with con-straints on the time between twoevents. In the statecharts that describeobject behavior, states now can havelocal variables. Interobject concurrencyis described more explicitly as follows.Like an SDL process, each atomic objecthas a queue of input events, but unlikeSDL processes, OMT allows aggregateobjects that have an input queue foreach component object [Rumbaugh1995a, p. 10]. Two other extensions tothe state model are the inclusion ofentry and exit actions in states and oftiming marks along transitions.

The functional model has undergone amajor revision in OMT95 [Rumbaugh1995c]. For most system functions(called operations in OMT), a simpledeclarative pre- or postcondition specifi-cation in terms of the system objectswill do. For complicated functions,OMT95 offers object interaction dia-grams and object-oriented dataflow dia-grams (OODFDs). An object interactiondiagram is a kind of collaboration dia-gram and can be used to show the se-quence of messages that implement afunction. It corresponds to a column inthe function decomposition table. AnOODFD is a directed higraph that rep-resents objects as nodes. These containnodes that represent object functions(cells in our function decomposition ta-ble) and nodes that represent object at-tributes. Object attribute and functionnodes are connected by directed edgesthat show which attributes are read or

514 • R. Wieringa


written by an operation and what thedataflows between the operations are.These flows may cross object bound-aries. This certainly improves the defi-nition of the relationship between thefunctional model and the object model.Nevertheless, the meaning of OODFDsis still defined rather informally. In theUML, they have disappeared from thescene.

B.5 Objectory 1992, 1995

Objectory is the commercialized versionof object-oriented software engineering(OOSE) [Jacobson et al. 1992]. It is de-scribed in the documentation thatcomes with the Objectory Case tool [Ob-jectory AB 1995b,c].

External functions of the systemsare represented by use cases (Section3.4.4).

To prepare for a conceptual decom-position of the system, a domain objectmodel is made, which represents subjectdomain entities and their relationships.The domain object model also repre-sents communications between domainentities [Objectory AB 1995b, p. 82].The 1995 version of Objectory uses anonstandard notation for this, but it isto be expected that later versions of theUML will use the UML class diagramnotation. The conceptual decompositionof the system is represented by theanalysis object model. This distin-guishes three kinds of objects. Entityobjects contain information about somephenomenon in the subject domain, in-terface objects handle communicationwith the environment, and control ob-jects encapsulate use-case-specific be-havior. There is likely to be a closecorrespondence between objects in thedomain object model and entity objectsin the analysis model. Control objectsare similar to JSD’s function processes.

Atomic object operations are speci-fied informally by means of object speci-fications.

The behavior of objects can be speci-fied by an SDL-like state transition dia-

gram (Section 3.5.8), called the objectbehavior model.

Communication between objects canbe illustrated by means of sequence dia-grams (Section 3.3.8), called the objectinteraction model.

B.6 Martin–Odell 1992, 1995

The first version of the Martin–Odellmethod is described in a single book[Martin and Odell 1992]. The secondversion is described in three books, ofwhich Martin and Odell [1995] give anoverview of the notation used. An im-portant difference between the 1992and the 1995 description is that in thelatter, the description of the modelstructure is separated from a discussionof the different possible notations thatcould be used to express this structure.The bulk of the Martin and Odell [1995]uses object and event diagrams to repre-sent object structure and behavior, butin addition a variety of structure andbehavior diagraming techniques is dis-cussed.

The conceptual decomposition of asystem is represented by an objectmodel, which is a class diagram-liketechnique (Section 3.2.2).

Behavior is analyzed as a dynamicstructure of events that cause objects tochange state. Events are brought aboutby operations and may trigger other op-erations, provided that the guard forthese other operations is satisfied. Thisguard is called a control condition forthe triggered operation. The relation-ships between events, triggers, and op-erations is represented in an event dia-gram, which is in the same league asprocess dependency diagrams (Section3.5.9). Event diagrams do not show thebehavior of a single object but “mean-ingful” behavior structures that are notnecessarily localized into a single object[Martin and Odell 1995, p. 118]. As aresult, each event diagram representsan aspect of external system behavioras well as some of the communicationbetween objects. An event diagramcould, for example, be used to represent



the behavior of objects during the execu-tion of a system function (column of thefunction decomposition table) or of anentire use case.

Martin and Odell [1995] discuss theuse of various dialects of class diagramsto represent object structure, differentkinds of finite state diagrams to repre-sent object behavior, and various kindsof sequence and collaboration diagramsto represent object communication.

B.7 Embley 1992

Embley et al. [1992] represent the con-ceptual decomposition of a system bythe object-relationship model, which is akind of class diagram (Section 3.2.2).

Object behavior is represented bythe object-behavior model, which uses adiagram convention called state nets,that combine some features of Petri nets(not treated here) and Mealy state dia-grams (Section 3.5.5). A state net canalso be used to represent intra-objectconcurrency. A transition can requirean object to be in several states simulta-neously and it can lead to a set of simul-taneous states. A transition can alsorequire that an object must be in atleast one of a set of states and it canlead to one out of a set of possiblestates.

Object communication is repre-sented by interaction diagrams, whichare hypergraphs that can show synchro-nous and asynchronous message-pass-ing between objects. Communicationcan be binary (one sender and one re-ceiver) or broadcast, and unidirectionalor bidirectional.

Object behavior and interaction dia-grams can be annotated by timing con-straints. In the behavior diagram, onecan constrain the time that an objectcan reside in a state, the time it takesfor a trigger to take effect, the time ittakes to execute an action, the time thatan entire object transition can take, andthe time it takes to execute a scenariothrough the state machine. In the inter-action diagram, one can constrain the

time it takes for a message to arrive atits destination.

All diagrams can be abstracted tohigher-level overview diagrams. Thus,one can represent high-level objectclasses, relationship sets, state sets,transition sets, and interaction sets.

B.8 De Champeaux 1993

Champeaux et al. [1993] represent sys-tem decomposition by their ownbrand of class diagrams called a staticobject model. A special feature of theirobject model is that they recognize en-sembles, which are a kind of aggregateobjects that encapsulate their compo-nents. Ensembles are similar to ROOMactors that also have their own behaviordefined in addition to the behavior de-fined for their multiple components (Ap-pendix B.11). Object behavior is spec-ified by a Mealy-like notation extendedwith guards and object interaction. Ob-ject operations can be described ininformal text, formal pre- and postcon-ditions, or even DFDs [Champeaux etal. 1993, p. 69]. Object communica-tion is represented by directed graphscalled interaction diagrams. There arenotations for synchronized bidirectionalcommunication and asynchronous uni-directional communication.

B.9 Firesmith 1993

Firesmith [1993] defines an elaborateset of notations for specifying systems,subsystems, and objects. Systems andsubsystems are called assemblies andsubassemblies, respectively. Where theCoad–Yourdon notation (Appendix B.2)is by far the simplest of the reviewednotations, the Firesmith notation is themost complex of the reviewed notations.For each assembly, the external func-tions are described globally by a state-ment of purpose and the external com-munications are specified by means ofa context diagram. In addition, a decom-position into subassemblies is definedand for each subassembly, the purposeis specified. Table A.II lists the tech-

516 • R. Wieringa


niques for specifying subassemblies,plus the statement of purpose and con-text diagram for the entire assembly.

The decomposition of a subassem-bly into objects is represented by a di-rected graph called a general semanticnet, which shows individual objects andtheir relationships. This is supple-mented by a decomposition diagramthat shows aggregation hierarchies ofobjects. Object classes are shown in aseparate classification diagram. All ofthis can be supplemented by textualspecifications in a programming-lan-guage-like format.

Object behavior is specified by statetransition diagrams. Object communi-cation is specified by interaction dia-grams, which are directed graphs whosenodes represent individual objects. Theflow of data and control through objectscan be specified by a DFD-like notationcalled a control flow diagram. A se-quence of interactions can be illustratedby a timing diagram, which resembles asequence diagram (Section 3.3.8). Thediagram conventions are all differentfrom the notations reviewed in this sur-vey.

B.10 SOMA 1994

The Semantic Object Modeling Ap-proach (SOMA) defined by Graham[1994] is an extension of the Coad–Yourdon notation (Appendix B.2). Otheracknowledged influences are Booch[1994], Champeaux et al. [1993], Des-fray [1992], Jacobson et al. [1992], Hen-derson-Sellers and Edwards [1994], andRumbaugh et al. [1991].

The decomposition of the system isspecified by an extension of the Coad–Yourdon class diagrams. One extensionis that in addition to a class name,attributes, and operations, a class boxmay contain business rules applicableto instances of that class. Another ex-tension is that SOMA allows fuzzy ob-jects, which may have fuzzy attributevalues, fuzzy rule sets, and only partialinheritance from superclasses. As inCoad–Yourdon, class diagrams are also

used to specify communication be-tween objects (called usage in SOMA).

Object operations are specified us-ing any possible technique, rangingfrom state diagrams, JSD’s processstructure diagrams, or DFDs [Graham1994, p. 249]. No information is givenon how these techniques should be com-bined with class diagrams. Grahamdoes give the advice to use these tech-niques on an object-by-object basis andnot for global system description.

Object behavior is specified usingstate diagrams. SOMA allows Mealy di-agrams, statecharts, and PSDs as a no-tation.

B.11 ROOM 1994

The real-time object-oriented modeling(ROOM) method partitions the systeminto a hierarchical collection of compo-nents called actors [Selic et al. 1994].An actor is a logical component of asystem that can be active concurrentlyto the other actors in the system. If theactor is a software object, it has its ownthread of control. If it is a physicalobject, it can behave independently ofother objects. In both cases, it musthave a clearly defined purpose [Selic etal. 1994, pp. 66, 150]. If an actor A isdecomposed into subactors, interactionof another actor with these subactors isonly possible through A.

A ROOM model represents the de-composition of the system as a decom-position hierarchy of actors. This is rep-resented by means of actor classdiagrams, which are undirected hi-graphs in which the nodes representactors and the edges represent commu-nications. The communication links be-tween actors are called bindings. Actorclass diagrams are very much like SDLblock diagrams (Section 3.3.7), exceptthat actor class diagrams allow thespecification of behavior for blocks atany level in the hierarchy. Second, actorclass diagrams require the explicit spec-ification of the communication mecha-nisms for each binding [Selic et al. 1994,p. 159], something which is defined for



block diagrams by the SDL standard.Like SDL models, ROOM models areexecutable.

Like SDL, ROOM allows the parti-tioning of large systems into layers. Thedifference between layers and decompo-sition into subactors is that the actorsin a lower layer continue to exist whenactors in a higher layer are destroyed.By contrast, when a compound actor isdestroyed, its subactors are destroyedas well [Selic et al. 1994, p. 195].

Actor behavior is represented by astatechart-like technique called Room-Charts. Like SDL processes, each actorhas an unbounded queue of messagesthat have been received but not yetprocessed [Selic et al. 1994, pp. 219,292].

Communication between actors isrepresented by the actor class diagrams,mentioned previously, and can be illus-trated by message sequence charts (Sec-tion 3.3.8). Communication can be syn-chronous or asynchronous [Selic et al.1994, pp. 292–293]. In asynchronouscommunication, the sender continuesprocessing immediately after sending amessage. In synchronous communica-tion, the sender waits until it has re-ceived a reply from the receiver. Thisreply is treated with higher prioritythan other received messages; that is, itbypasses any messages waiting to beprocessed. After receiving the reply, thesender continues its own processing.

B.12 Fusion 1994, 1996

Fusion is a method defined after ananalysis of early object-oriented meth-ods like OMT, Booch, and Objectory[Bear et al. 1990; Coleman et al. 1992,1994; Hayes and Coleman 1991]. Thesemethods were analyzed using a dialectof the formal specification languageVDM as a tool. Significant updates toFusion were published in 1996[Coleman 1996; Malan et al. 1996].

Fusion defines a decomposition of asystem by first specifying a domainmodel, which is an ER-like diagram ofthe subject domain. The system decom-

position is then found by outline of thesystem boundary in the domain model.Everything inside the boundary is partof the system; everything outside theboundary is part of the environment.

External functions are called sys-tem operations in Fusion, and are speci-fied declaratively by means of pre- andpostcondition specifications (Section3.4.3), a technique borrowed from VDMspecification theory. The 1996 updateextends this with use case diagrams(Section 3.4.4) to describe external func-tionality.

External system behavior is repre-sented by means of regular expressionsover system operations. In the 1996 up-date these were replaced by system in-teraction diagrams, which are collabora-tion diagrams (Section 3.3.9) that showsequences of interactions between thesystem and the environment. Alterna-tively, sequence diagrams (Section3.3.8) can be used, which are calledscenario diagrams in Fusion. Togetherwith use case diagrams, these diagramsalso show aspects of external commu-nication).

Object behavior is not specified inFusion at the conceptual level. Instead,during design, external operations aredecomposed into object operations bymeans of collaboration diagrams, calledobject interaction graphs. These alsoshow the communication between ob-jects. Object operations are specifieddeclaratively by means of pre- and post-conditions.

B.13 MOSES 1994

“MOSES” stands for methodology forobject-oriented software engineering ofsystems (Henderson-Sellers and Ed-wards 1994] and defines a product life-cycle from initial conception to productmaturity, in which each change of theproduct is performed according to a pro-cess lifecycle. MOSES also defines nota-tions to be used for the deliverables ofthe process as well as activities thatyield these deliverables. The process isstructured according to the fountain

518 • R. Wieringa


model [Henderson-Sellers and Edwards1990] and consists of planning, investi-gation, specification, and review phases.The investigation phases yields a userrequirements specification and systemscenarios, both written in natural lan-guage. Both of these are a way of speci-fying external system functions.

The conceptual decomposition of asoftware system is specified using anobject/class model, which is a class dia-gram-like technique that can be used tospecify a decomposition into individualobjects or into classes of objects. Theinheritance structure can be specifiedseparately by an inheritance model.MOSES provides some extra notationsfor the object/class model to representprogramming language constructs suchas client-server and friend relation-ships, and exceptions.

Object operations are described byservice specifications, which can taketwo forms. Contracts specify a serviceoffered by an object by means of pre-and postconditions (Section 3.4.3). Al-ternatively, a service can be specifiedimperatively by means of a servicestructure model, which is a kind ofstructure chart adapted to object-ori-ented programming, proposed by Page-Jones et al. [1990]. Either way, a servicespecification specifies an individual ob-ject action, which corresponds to a cellin the function decomposition table.

Object behavior is represented byobjectcharts, which is a statechart-likenotation (Section 3.5.7). Object com-munication is specified by an eventmodel, which is a kind of collaborationdiagram (Section 3.3.9). Communicationis synchronous in MOSES [Henderson-Sellers 1992, p. 56]. There is a guidelinethat an event model should correspondto an external system function [Hender-son-Sellers 1992, p. 300]. An eventmodel thus corresponds to a column inthe function decomposition table.

Complex system specifications can besimplified by partitioning the specifica-tion into sheets and/or the system intosubsystems. Complexity can be furtherreduced by partitioning classes or sub-

systems into layers [Henderson-Sellers1992, p. 250].

B.14 Syntropy 1994

Syntropy [Cook and Daniels 1994] is acombination of OMT and statecharts,extended with some other notationsfrom Booch, all given a precise seman-tics by means of the formal specificationlanguage Z [Spivey 1989]. In the processof providing this semantics, many de-tails of these notations are clarified. Forexample, Syntropy is the only reviewedmethod that gives a semantics to behav-ior inheritance [Cook and Daniels 1994,pp. 206 ff.]. In addition, the notation issupplemented with modeling guidelinesand a particular view of the develop-ment process.

Syntropy distinguishes the essentialmodel, the specification model, and theimplementation model of a software sys-tem. The essential model is a model ofthe subject domain. This is modeled as acollection of objects and events. Objectsin the subject domain have properties,which can only change as the result ofan event in the subject domain. Eventsmay change the properties of more thanone object. Events are instantaneousand simultaneously observable every-where. The essential model consists of atype view, which represent the types ofobjects in the subject domain, and astate view, which represents the wayobjects change as a result of events. Thetype view is represented by an OMT-like object diagram, which is a kind ofclass diagram (Section 3.2.2), supple-mented with Z specifications for typesand invariants. In the state view, astate model is defined for each objecttype that provides the details of objectcreation, the list of events to which ob-jects of this type can respond, pre- andpostconditions of these events, and astatechart (Section 3.5.7) that showshow objects of this type respond toevents. Each event must appear in atleast one statechart but may appear inmore. The pre- and postconditions foreach event are specified in the formal



specification language Z. Preconditionsare the conditions that must exist forthe event to occur. In the essentialmodel, it is impossible for an event tooccur when the preconditions are notsatisfied.

The term “essential model” in Syn-tropy should not be confused with thesame term as used in Structured Analy-sis. In Structured Analysis, it is used torefer to an implementation-independentsoftware specification, which corre-sponds to the software specificationmodel of Syntropy.

The specification model of Syntropydescribes the states that the softwarecan be in and the way that it respondsto stimuli by changing state and produc-ing responses. Each stimulus is anevent that is broadcast to all objects inthe model simultaneously. As in the es-sential model, all events are instanta-neous. This means that all the conse-quences of an external stimulus arecompleted before any further externalstimuli occur. If an external stimulustriggers several events in several stat-echarts, these all occur in an unspeci-fied order before the next stimulus isrecognized. In contrast to the essentialmodel, if a precondition is not satisfied,the event may occur but its effect isundefined. The specification model isdescribed by the same techniques as theessential model, that is, a type view anda state view. The entries for Syntropy inTable A.II describe the specificationmodel. The type view of the specifica-tion model represents the conceptualdecomposition of the software into ob-jects and the state view represents ob-ject behavior.

The implementation model describesthe flow of control of the software. Stim-uli are mapped to messages and all mes-sage-passing and method executionstake time. The implementation modelmust deal explicitly with concurrency,persistence, finite resources, errors, ex-ceptions, and the like. The implementa-tion model uses collaboration diagramscalled mechanisms to specify the se-

quence of messages that implements ex-ternal system functions.

To build a specification model, thesystem boundary must be defined bydefining external entities, called agentsin Syntropy. These may be modeled aspart of the essential model. For eachevent in the essential model it must bedecided whether it is to be detected bythe software, generated by the software,or ignored. In addition, the specificationmodel shows how undesirable eventsare handled. These were simply impos-sible in the essential model.

To manage complexity, Syntropy par-titions the software into subsystemscalled domains. A concept domain is amodel of the subject domain. A softwaresystem may have more than one conceptdomain. An interaction domain providesthe mechanism for keeping the conceptdomain and the world in step and aninfrastructure domain provides general-purpose abstraction that can be used byobjects in the other domains. Agentswith which the system must communi-cate may be represented as softwareobjects in the specification model, forexample, in the interaction domain or ina concept domain. The type view of aconcept domain will be very similar tothe type view of the essential model[Cook and Daniels 1994, p. 262]. Thestate views of the essential and specifi-cation models usually differ. The reasonis that essential model statecharts showevent sequencing, whereas specificationmodel statecharts show how responsesare generated by software.

B.15 Mainstream Objects 1995

Mainstream Objects is a combination oftechniques from different object-ori-ented methods [Yourdon et al. 1995].External functions are modeled byuse cases (Section 3.4.4), called transac-tion sequences in this approach. Theconceptual decomposition of a sys-tem is represented by an object struc-ture diagram, which is a kind of classdiagram (Section 3.2.2). The overalldecomposition of the system into sub-

520 • R. Wieringa


systems is represented by a system over-view diagram. This shows the sub-systems and the services they offer toeach other. Object structure, behavior,and interaction are then shown for eachsubsystem.

Object behavior is represented byobject life cycle diagrams, which is astatechart-like formalism (Section 3.5.7).Object communication is specifiedusing sequence diagrams or collabora-tion diagrams, called fence and net in-teraction diagrams, respectively (Sec-tions 3.3.8 and 3.3.9). Finally, the flowof activities in the system can be repre-sented by an activity diagram, which isa kind of process dependency diagram(Section 3.5.9). These show behaviorover time, not restricted to any object.

B.16 Business Object Notation 95

In the business object notation (BON), anumber of textual structured naturallanguage specifications, called charts,are combined with two kinds of dia-grams [Walden and Nerson 1995]. Ex-ternal behavior is described by sce-nario charts, which are step-by-stepdescriptions of scenarios. Externalfunctions are described by a systempurpose chart. In addition to a descrip-tion of the system purpose, somewhatsimilar to YSM’s system purpose speci-fication, these specify a decompositionof the system into clusters of classes.Each cluster is briefly described. In ad-dition, system event charts list externalevents to which the system must re-spond and, for each event, the classesthat play a role in recognizing the eventand producing the response. These aresimilar to event-response specificationsof YSM but system event charts giveconsiderably less information.

The system decomposition is speci-fied in two parts. The decompositioninto clusters is shown on the systempurpose chart and the decomposition ofa cluster into classes is shown in clustercharts. Relationships between classescan be represented in a static structurediagram. This includes inheritance re-

lations between classes. Static structurediagrams are directed graphs but use anonstandard convention.

Communication between compo-nents is represented by dynamic dia-grams, which resemble collaboration di-agrams (Section 3.3.9). In addition, eachevent chart lists the classes that play arole in recognizing and responding tothe event, and there are object creationcharts that specify which classes of ob-jects can create which classes of objects.

B.17 Octopus 1996

Octopus is an extension of Fusion withnotions useful for the specification anddesign of embedded real-time systems[Awad et al. 1996]. Like Fusion 96, Oc-topus specifies external system func-tions by means of use cases, specifieddeclaratively by means of pre- and post-conditions. The use cases are not repre-sented by use case diagrams but byOMT-like object diagrams, that canshow aggregation relationships betweenuse cases. External communicationis specified by a context diagram, againusing an OMT-like object diagram. Thisallows one to show relationships be-tween external entities, such as aggre-gation and communication relation-ships.

Octopus borrows the domain conceptof the Shlaer–Mellor method to definesubsystems. Example domains are theapplication domain, the device domain,and the implementation domain. Octo-pus recognizes a special kind of sub-system called a hardware wrapper thathides the hardware from the applicationsubsystem. The partitioning into sub-systems is represented by an OMT-likeobject diagram, showing in particularthe aggregation relationships betweensubsystems. The Octopus entry in TableA.II lists the techniques to specify exter-nal communication and functions, andthe techniques to specify subsystems.

For each subsystem the decomposi-tion into objects is represented by anOMT-like object diagram. This resem-bles a class diagram (Section 3.2.2). The



subsystem responds to events by per-forming operations. The operations ofthe subsystem are described by declara-tive specifications called operationsheets. In addition to pre- and postcon-ditions, these also mention the objectsinvolved in responding to the event.Each event received by a subsystem isbroadcast to all objects in the systemand all ensuing processing is consideredto be instantaneous.

Subsystem behavior is described bya subsystem state model, which is a stat-echart (Section 3.5.7). Following the Fu-sion philosophy, statecharts are not de-fined for object types. Instead, astatechart is specified for every inter-esting aspect of subsystem behavior.Statecharts define subsystem states andshow the effect of events on this state.The external behavior entry for Octopusin Table A.II lists techniques to specifyexternal subsystem behavior, which iswhy statecharts are mentioned in thisentry.

For each event to which the sub-system must respond, an event signifi-cance table is made, which shows foreach possible state of the subsystemhow critical the event is. The more crit-ical an event is, the more urgent it isthat the subsystem respond immedi-ately when the event occurs.

As in Fusion, the mechanism bywhich objects implement a subsystemoperation is represented in the designphase by object interaction graphs,which are collaboration diagrams (Sec-tion 3.3.9).

Octopus has an interesting similaritywith YSM, used as a method to specifysubsystems. External subsystem behav-ior is specified in both by means of acontext diagram, pre- and postconditionspecifications of events to which thesubsystem must respond, and statetransition models of subsystem behavior(control processes in YSM). Even theERD in YSM plays a similar role to theobject diagram in Octopus. Both repre-sent the conceptual decomposition ofthe subsystem. The difference lies in theinterpretation of this as data stores in

YSM and as objects in Octopus. Fur-thermore, Octopus models do not con-tain data processes and they do notfocus on dataflows, as YSM models do.

B.18 OOram 1996

The central concept in object-orientedrole analysis and modeling (OOram) isthe concept of a role, defined as a posi-tion that a set of objects can occupy in apattern of collaborating objects [Reen-skaug et al. 1996, p. 22]. A role has anidentity and has behavior and state thatis encapsulated. It is an archetypicalrepresentation of the objects occupyingthe corresponding position in the objectsystem [Reenskaug et al. 1996, p. 7].The collaboration pattern characteristicfor a role is represented by a kind ofcollaboration diagram. This is called acollaboration view and can be used torepresent the collaboration of the sys-tem with its environment as well as thecollaboration of objects in the system torealize an external system function.Several collaboration patterns can bespecified for a system, one from eachrelevant point of view. These differentpatterns can then be synthesized into aoverall collaboration model of all objectsin the system performing all their dif-ferent functions. OOram offers a num-ber of synthesis operations for this.

OOram recognizes a number of sys-tem views, not all of which will beneeded in all projects. External behav-ior and communication are repre-sented by a sequence diagram (Section3.3.8) called the external scenario view.This can be supplemented by the exter-nal collaboration view, which uses col-laboration diagrams (Section 3.3.9). Thesame kind of diagram can also be usedto represent the communication be-tween objects in the system. Externalfunctions are represented by a globaldescription of the system purpose innatural language, called the area of con-cern view. System functions are de-scribed briefly in the stimulus-responseview, which consists of a list of stimuliand corresponding responses, annotated

522 • R. Wieringa


with brief comments. This resembles asimplified form of an event-response list(Section 3.4.2).

System decomposition into objectsas well as communication between ob-jects are represented by the internalcollaboration view, which is again a col-laboration diagram. As mentioned pre-viously, communication between compo-nents can also be represented bysequence diagrams. Object functionsare specified in a programming-lan-guage-like way called the interface view.This lists all the interfaces of all objects.In addition, a method specification viewcan be made, which extends the se-quence diagrams of the internal sce-nario view with annotations of themethods executed by an object as a re-sult of the reception of a message.

B.19 UML 1997

Version 1.0 of the Unified ModelingLanguage (UML) arose as a result of ajoint effort of Booch, Jacobson, andRumbaugh to unify the existing nota-tions for object-oriented software speci-fication. It combines the notations usedin the Booch method, Objectory, andOMT, applies some simplifications, andextends this with new features and dia-grams. However, the basic structure ofthe notations used in these methodsremains recognizable. The intention isthat it will be used as a diagram con-vention in those methods and probablyin other methods as well. In January1997, the UML version 1.0 was submit-ted to the Object Management Group(OMG) along with several other propos-als. The submitters then negotiated ajoint submission, which led to Version1.1 of the UML [Rational 1997b,c]. Thiswas accepted in November 1997 by theOMG as standard notation for object-oriented specifications.3 At the time ofthis writing, Booch, Jacobson, and Rum-baugh all announced books on UML 1.1and several companies announced that

they will adopt the UML as standardnotation in their method.

All of the diagrams used in the UMLhave been explained in Section 3. Here,we briefly review the terminology of theUML. External behavior and com-munication of a system is representedby collaboration and sequence diagrams(Sections 3.3.8 and 3.3.9), in which thesystem figures as one of the communi-cating entities. External functions arerepresented by use case diagrams andtheir attendant documentation. Thesealso illustrate a part of external systemcommunication. The conceptual de-composition is represented by a staticstructure diagram, which is a class dia-gram (Section 3.2.2) extended with thepossibility of representing individualobjects as well as classes. Componentbehavior is represented by statecharts(Section 3.5.7) adapted to object-ori-ented use, and communication be-tween components is represented by col-laboration and sequence diagrams(Sections 3.3.8 and 3.3.9). The UML de-fines a special kind of statechart calledan activity diagram to represent depen-dency between activities. This is similarto a process dependency diagram (Sec-tion 3.5.9). Activity diagrams can beused to specify procedure-like object be-havior, object operations, or use cases.

The total UML notation is quite com-plex. It contains by far the largest num-ber of icons and symbols for adorning,commenting, and otherwise labeling thediagrams. This makes the definition of aformal semantics a daunting task. Italso makes the notation hard to use.Methods that use this notation shouldgive heuristics for the good use of allthese features that are consistent withthe semantics of the notations—oncethese semantics are defined. The prob-lem is compounded by the fact that theUML contains constructs that allow dif-ferent methods to extend the notationwith new features. Even if we assumeeach method gives a precise semanticsto its UML extensions, this may cause aproliferation of UML dialects, under-stood only by their inventors.3 See http://www.omg.org for details.



Despite these misgivings, the surveyof this article has shown that there isconsiderable convergence in the nota-tions used by the different methods.Agreeing on a standard notation with awell-defined semantics would allowpractitioners to concentrate on solvingthe customer’s problem instead of onlearning yet another notation. The fu-ture will show whether the UML willdevelop into the standard that fits thisneed or whether it will turn out to be ageneric template whose meaning is inthe eye of the beholder and that can becustomized beyond recognition.

ACKNOWLEDGMENTS

The survey benefited from detailed comments byMichael Jackson and Frank Dehne. The anony-mous referees gave useful comments for furtherimprovement.

REFERENCES

AWAD, M., KUUSELA, J., AND ZIEGLER, J. 1996.Object-Oriented Technology for Real-TimeSystems: A Practical Approach Using OMTand Fusion. Prentice-Hall, Englewood Cliffs,NJ.

BAETEN, J. AND WEIJLAND, W. 1990. Process Al-gebra. Cambridge Tracts in Theoretical Com-puter Science 18, Cambridge, UniversityPress, New York.

BATES, B., BRUEL, J.-M., FRANCE, R., AND LAR-RONDE-PETRIE, M. 1996. Guidelines for theformalizing Fusion object-oriented analysismodels. In Advanced Information Systems En-gineering (CAiSE’96), P. Constantopoulos, J.Mylopoulos, Y. Vassiliou, Eds., LNCS 1080,Springer, 222–233.

BEAR, S., ALLEN, P., COLEMAN, D., AND HAYES, F.1990. Graphical specification of object-ori-ented systems. In Object-Oriented Program-ming: Systems, Languages and Applications/European Conference on Object-OrientedProgramming. Ottawa, ACM, N. Meyrowitz,Ed., SIGPLAN Not. 25, 10, 28–37.

BEECK, M. V. D. 1994. A comparison of State-charts variants. In Formal Techniques inReal-Time and Fault-Tolerant Systems, H.Langmaack, W. d. Roever, and J. Vytopil,Eds., LNCS 863, Springer, 128–148.

BELINA, F. AND HOGREFE, D. 1988–1989. TheCCITT-specification and description languageSDL. Comput. Netw. ISDN Syst. 16, 311–341.

BELINA, F., HOGREFE, D., AND SARMA, A. 1991.SDL with Applications from Protocol Specifi-cation. Prentice-Hall, Englewood Cliffs, NJ.

BLANCHARD, B. AND FABRYCKY, W. 1990. Sys-tems Engineering and Analysis. Prentice-Hall,Englewood Cliffs, NJ.

BOOCH, G. 1991. Object-Oriented Design withApplications. Benjamin/Cummings, RedwoodCity, CA.

BOOCH, G. 1994. Object-Oriented Design withApplications, Second Edition. Benjamin/Cum-mings, Redwood City, CA.

BORGIDA, A., MYLOPOULOS, J., AND REITER, R.1995. On the frame problem in procedurespecifications. IEEE Trans. Softw. Eng. 21,785–798.

BOURDEAU, R. AND CHENG, B. 1995. A formalsemantics for object model diagrams. IEEETrans. Softw. Eng. 21, 10, 799–821.

BRÆK, R. AND HAUGEN, Ø. 1993. EngineeringReal-Time Systems. Prentice-Hall, EnglewoodCliffs, NJ.

CHAMPEAUX, D. D. AND FAURE, P. 1992. A com-parative study of object-oriented analysismethods. J. Object-Oriented Programs, 21–33.

CHAMPEAUX, D. D., LEA, D., AND FAURE,P. 1993. Object-Oriented System Develop-ment, Addison-Wesley, Reading, MA.

CHEN, P.-S. 1976. The entity-relationshipmodel—toward a unified view of data. ACMTrans. Database Syst. 1, 9–36.

COAD, P. AND YOURDON, E. 1990. Object-OrientedAnalysis. Yourdon Press/Prentice-Hall, Engle-wood Cliffs, NJ.

COLEMAN, D. 1996. Fusion with use cases: Ex-tending Fusion for requirements modeling.Available at URL: http:/www.hpl.hp.com/fu-sion/index.html.

COLEMAN, D., ARNOLD, P., BODOFF, S., DOLLIN, C.,GILCHRIST, H., HAYES, F., AND JEREMAES,P. 1994. Object-Oriented Development: TheFUSION Method. Prentice-Hall, EnglewoodCliffs, NJ.

COLEMAN, D., HAYES, F., AND BEAR, S. 1992.Introducing Objectcharts or how to use Stat-echarts in object-oriented design. IEEETrans. Softw. Eng. 18, 1, 9–18.

COOK, S. AND DANIELS, J. 1994. Designing Ob-ject Systems: Object-Oriented Modelling withSyntropy, Prentice-Hall, Englewood Cliffs,NJ.

DAHL, O.-J. AND NYGAARD, K. 1966. SIMULA—an ALGOL-based simulation language. Com-mun. ACM 17, 7, 403–412.

DAVIS A. 1993. Software Requirements: Objects,Functions, States. Prentice-Hall, EnglewoodCliffs, NJ.

DEMARCO, T. 1978. Structured Analysis andSystem Specification. Yourdon Press/Prentice-Hall, Englewood Cliffs, NJ.

DESFRAY, P. 1992. Ingenerie des Objects Ap-proche Classe-Relation Applications a C11.Editions Massons, Paris.

524 • R. Wieringa


EBERT, J. AND ENGELS, G. 1997. Specializationof object life cycle definitions. Submitted.

ECKERT, G. 1996. Improving the analysis stageof the Fusion method. In Object-Oriented De-velopment at Work: Fusion in the Real World,R. Malan et al. Eds., Prentice-Hall, Engle-wood Cliffs, NJ, 276–313.

EMBLEY, D., JACKSON, R., AND WOODFIELD, S.1995. OO systems analysis: Is it or isn’t it.IEEE Softw. 12, 3, 19–33.

EMBLEY, D., KURTZ, B., AND WOODFIELD, S.1992. Object-Oriented Systems Analysis: AModel-Driven Approach. Prentice-Hall, Engle-wood Cliffs, NJ.

FÆRGEMAND, O. AND OLSEN, A. 1994. Introduc-tion to SDL 92. Comput. Netw. ISDN Syst. 26,1143–1167.

FICHMAN, R. AND KEMERER, C. 1992. Object-ori-ented and conventional analysis and designmethodologies: Comparison and critique.Computer 25, 22–39.

FIRESMITH, D. 1993. Object-Oriented Require-ments Analysis and Logical Design: A Soft-ware Engineering Approach. Wiley, NewYork.

FLAVIN, M. 1981. Fundamental Concepts of In-formation Modeling. Yourdon Press, Engle-wood Cliffs, NJ.

FOWLER, M. 1994. Describing and comparingobject-oriented analysis and design methods.In Object Development Methods, A. Car-michael, Ed., SIGS Books, Denville, NJ, 79–109.

FRANCE, R. 1992. Semantically extended dataflow diagrams: A formal specification tool.IEEE Trans. Softw. Eng. 18, 4, 329–346.

FRANCE, R. AND LARRONDO-PETRIE, M. 1994.From structured analysis to formal specifica-tion: State of the theory. In Proceedings of the1994 ACM Computer Science Conference.

GANE, C. AND SARSON, T. 1979. Structured Sys-tems Analysis: Tools and Techniques. Pren-tice-Hall, Englewood Cliffs, NJ.

GOLDSMITH, S. 1993. Real-Time Systems Devel-opment. Prentice-Hall, Englewood Cliffs, NJ.

GOMAA, H. 1993. Software Design Methods forConcurrent and Real-Time Systems. Addison-Wesley, Reading, MA.

GRAHAM, I. 1994. Migrating to Object Technol-ogy. Addison-Wesley, Reading, MA.

HALL, P., OWLETT, J., AND TODD, S. 1976.Relations and entities. In Modelling in Data-base Management Systems, G. Nijssen, Ed.,North-Holland, 201–220.

HAREL, D. 1979. First Order Dynamic Logic.LNCS 68, Springer.

HAREL, D. 1988. On visual formalisms. Com-mun. ACM 31, 514–530.

HAREL, D. 1992. Biting the silver bullet. Com-puter 25, 1, 8–20.

HAREL, D. AND GERY, E. 1996. Executable objectmodeling with statecharts. In Proceedings ofthe Eighteenth International Conference onSoftware Engineering, 246–257.

HAREL, D. AND GERY, E. 1997. Executable objectmodeling with statecharts. Computer 30, 7,31–42.

HAREL, D. AND KAHANA, C.-A. 1992. On state-charts with overlapping. ACM Trans. Softw.Eng. Methodol. 1, 4, 399–421.

HAREL, D. AND NAAMAD, S. 1996. The STATE-MATE semantics of statecharts. ACM Trans.Softw. Eng. Methodol. 5, 293–333.

HAREL, D. AND PNUELI, A. 1985. On the devel-opment of reactive systems. In Logics andModels of Concurrent Systems, K. Apt, Ed.,NATO ASI Series, Springer, 477–498.

HAREL, D., PNUELI, A., SCHMIDT, J., AND SHERMAN,R. 1987. On the formal semantics of state-charts. In Proceedings, Symposium on Logicin Computer Science, Computer Science Press,New York, 54–64.

HATLEY, D. AND PIRBHAI, I. 1987. Strategies forReal-Time System Specification. DorsetHouse, New York.

HAYES, F. AND COLEMAN, D. 1991. Coherentmodels for object-oriented analysis. In Object-Oriented Programming: Systems, Languagesand Applications/European Conference onObject-Oriented Programming, A. Paepcke,Ed., SIGPLAN Not. 25, 11, 171–183.

HENDERSON-SELLERS, B. 1992. A Book of Object-Oriented Knowledge. Prentice-Hall, Engle-wood Cliffs, NJ.

HENDERSON-SELLERS, B. AND EDWARDS, J. 1990.The object-oriented systems life cycle. Com-mun. ACM 33, 9, 143–159.

HENDERSON-SELLERS, B. AND EDWARDS, J. 1994.Book Two of Object-Oriented Knowledge.Prentice-Hall, Englewood Cliffs, NJ.

HODGSON, R. 1994. Contemplating the universeof methods. In Object Development Methods,A. Carmichael, Ed., SIGS Books, Denville,NJ, 111–132.

HOPCROFT, J. AND ULLMAN, J. 1979. Introduc-tion to Automata Theory, Languages andComputation. Addison-Wesley, Reading, MA.

HUTT, A. 1994a. Object Analysis and Design:Comparison of Methods. OMG/Wiley, NewYork.

HUTT, A. 1994b. Object Analysis and Design:Description of Methods. OMG/Wiley, NewYork.

I-LOGIX 1991a. The Languages of STATE-MATE. Tech. Rep., i-Logix Inc., Burlington,MA. To be published as D. Harel and M.Politi, Modeling Reactive Systems with Stat-echarts: The STATEMATE Approach.

I-LOGIX 1991b. The Semantics of statecharts.Tech. Report, i-Logix Inc., Burlington, MA.



IVARI, J. 1995. Object-orientation as structural,functional and behavioural modelling: A com-parison of six methods for object-orientedanalysis. Inf. Softw. Technol. 37, 3, 155–163.

ITU 1992. Specification and Description Lan-guage (SDL). International Telecommunica-tions Union (formerly CCITT), Revised recom-mendation Z.100.

ITU 1993. Z.100 Appendix I: SDL MethodologyGuidelines. Tech. Rep., International Tele-communication Union.

ITU 1994. Criteria for the Use and Applicabil-ity of Formal Description Techniques: MessageSequence Charts (MSC). International Tele-communication Union. Z.120 (03/93).

JACKSON, M. 1975. Principles of Program De-sign. Academic Press.

JACKSON, M. 1983. System Development. Pren-tice-Hall, Englewood Cliffs, NJ.

JACKSON, M. 1995. Software Requirements andSpecifications: A Lexicon of Practice, Princi-ples and Prejudices. Addison-Wesley, Read-ing, MA.

JACOBSON, I., CHRISTERSON, M., JOHNSSON, P., AND

OVERGAARD, G. 1992. Object-Oriented Soft-ware Engineering: A Use Case Driven Ap-proach. Prentice-Hall, Englewood Cliffs, NJ.

LANG, N. 1993. Shlaer–Mellor object-orientedanalysis rules. Softw. Eng. Not. 18, 1, 54–58.

LOOMIS, M., SHAH, A., AND RUMBAUGH, J.1987. An object modeling technique for con-ceptual design. In European Conference onObject-Oriented Programming, J. Bezivin,J.-M. Hullot, P. Cointe, and H. Lieberman,Eds. LNCS 276, Springer, Paris, 192–202.

MALAN, R., LETSINGER, R., AND COLEMAN, D.,EDS. 1996. Object-Oriented Development atWork: Fusion in the Real World. Prentice-Hall, Englewood Cliffs, NJ.

MARCA, D. AND GOWAN, C. 1988. SADT: Struc-tured Analysis and Design Technique.McGraw-Hill, New York.

MARTIN, J. 1989a. Information Engineering,Book I: Introduction. Prentice-Hall, Engle-wood Cliffs, NJ.

MARTIN, J. 1989b. Information Engineering,Book II: Planning and Analysis. Prentice-Hall, Englewood Cliffs, NJ.

MARTIN, J. 1989c. Information Engineering,Book III: Design and Construction. Prentice-Hall, Englewood Cliffs, NJ.

MARTIN, J. AND FINKELSTEIN, C. 1981. Informa-tion Engineering. Savant Institute, Carnforth,England.

MARTIN, J. AND MCCLURE, C. 1985. Diagram-ming Techniques for Analysts and Program-mers. Prentice-Hall, Englewood Cliffs, NJ.

MARTIN, J. AND ODELL, J. 1992. Object-OrientedAnalysis and Design. Prentice-Hall, Engle-wood Cliffs, NJ.

MARTIN, J. AND ODELL, J. 1995. Object-OrientedMethods: A Foundation. Prentice-Hall, Engle-wood Cliffs, NJ.

MCGREGOR, J. AND DYER, D. 1993. Inheritanceand state machines. Softw. Eng. Not. 18, 4,61–69.

MCMENAMIN, S. AND PALMER, J. 1984. EssentialSystems Analysis. Yourdon Press/Prentice-Hall, Englewood Cliffs, NJ.

MEYER, B. 1985. On formalism in specifica-tions. IEEE Softw. 6–26.

MILNER, R. 1980. A Calculus of CommunicatingSystems. LNCS 92, Springer.

MØLLER-PEDERSEN, B., BELSNES, D., AND DAHLE,H. 1987. Rationale and tutorial on OSDL:An object-oriented extension of SDL. Comput.Netw. ISDN Syst. 13, 97–117.

MONARCHI, D. AND PUHR, G. 1992. A researchtypology for object-oriented analysis and de-sign. Commun. ACM 35, 9, 35–47.

OBJECTORY AB 1995a. Objectory: Introduction,Version 3.6.

OBJECTORY AB 1995b. Objectory: RequirementsAnalysis, Version 3.6.

OBJECTORY AB 1995c. Objectory: RobustnessAnalysis, Version 3.6.

OMG 1996. Object analysis and design RFP-1.OMG TC Document ad/96-05-01—rev.1, 6/6/96. Available at URL http://www.omg.org/public-doclist.html.

PAGE-JONES, M., CONSTANTINE, L., AND WEISS, S.1990. Modeling object-oriented systems: Theuniform object notation. Comput. Lang. 7, 10,69–87.

PETERSOHN, C., HUIZING, C., PELESKA, J., AND DE

ROEVER, W.-P. 1994. Formal semantics forWard and Mellor’s TRANSFORMATIONSCHEMAS. In Sixth Refinement Workshop,Workshops in Computing, BCS-FACS, D. Till,Ed., Springer Verlag, 14–41.

PNUELI, A. AND SHALEV, M. 1991. What is in astep: On the semantics of statecharts. In The-oretical Aspects of Computer Software, T. Itoand A. Meyer, Eds. LNCS 526, Springer, 244–264.

RATIONAL 1997a. Unified Modeling Language:Notation Guide, Version 1.0. Rational Soft-ware Corporation, Santa Clara, CA. Availableat URL http://www.rational.com/ot/uml.html.

RATIONAL 1997b. Unified Modeling Language:Notation Guide, Version 1.1. Rational Soft-ware Corporation, Santa Clara, CA. Availableat URL http://www.rational.com.uml/1.1/.

RATIONAL 1997c. Unified Modeling Language:Semantics, Version 1.1. Rational SoftwareCorporation, Santa Clara, CA. Available atURL http://www.rational.com/uml/1.1/.

REENSKAUG, T., WOLD, P., AND LEHNE, O. 1996.Working with Objects: The OOram Software

526 • R. Wieringa


Engineering Methodology. Computer SocietyPress.

ROSS, D. 1977. Structured analysis (SA): A lan-guage for communicating ideas. IEEE Trans.Softw. Eng. SE-3, 1, 16–34.

ROSS, D. 1985. Applications and extensions ofSADT. Computer 18, 4, 25–34.

RUMBAUGH, J. 1995a. OMT: The dynamicmodel. J. Object-Oriented Program. 7, 9,6–12.

RUMBAUGH, J. 1995b. OMT: The functionalmodel. J. Object-Oriented Program. 8, 1, 10–14.

RUMBAUGH, J. 1995c. OMT: The object model.J. Object-Oriented Program. 7, 8, 21–27.

RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY,F., AND LORENSEN, W. 1991. Object-Orient-ed Modeling and Design. Prentice-Hall,Englewood Cliffs, NJ.

SAAKE, G., HARTEL, P., JUNGCLAUS, R., WIERINGA,R., AND FEENSTRA, R. 1994. Inheritanceconditions for object life cycle, diagrams. InFormale Grundlagen fur den Entwurf von In-formationsystemen, U. Lipeck and G. Vossen,Eds. Institut fur Informatik, Universitat Han-nover, Germany 79–88. Informatik-BerichteNr. 03/94.

SARACCO, R., SMITH, J., AND REED, R. 1989.Telecommunications Systems Engineering Us-ing SDL, North-Holland.

SARRACO, R. AND TILANUS, P. 1987. CCITT SDL:Overview of the language and its applications.Comput. Netw. ISDN Syst. 13, 65–74.

SCHREFL, M. AND STUMPTNER, M. 1995. Behav-ior consistent extension of object life cycles. InER’95.

SELIC, B., GULLEKSON, G., AND WARD, P. 1994.Real-Time Object-Oriented Modeling. Wiley,New York.

SHLAER, S. AND LANG, N. 1996. The Shlaer-Mel-lor method: The OOA96 report, version 1.0.Tech. Rep., Project Technology, Inc., Berkeley,CA 984710. Available at URL http://www-.projtech.com/cgi/pdf/ooa96.pdf.

SHLAER, S. AND MELLOR, S. 1988. Object-Orient-ed Systems Analysis: Modeling the World inData. Prentice-Hall, Englewood Cliffs, NJ.

SHLAER, S. AND MELLOR, S. 1989. An object-ori-ented approach to domain analysis. ACMSIGSOFT Softw. Eng. Not. 14, 5, 66–77.

SHLAER, S. AND MELLOR, S. 1992. Object Life-cycles: Modeling the World in States. Prentice-Hall, Englewood Cliffs, NJ.

SHUMATE, K. AND KELLER, M. 1992. SoftwareSpecification and Design: a Disciplined Ap-

proach for Real-Time Systems. Wiley, NewYork.

SPIVEY, J. 1989. The Z Notation: A ReferenceManual. Prentice-Hall, Englewood Cliffs, NJ.

SUTCLIFFE, A. 1991. Object-oriented systemsdevelopment: Survey of structured methods.Inf. Softw. Technol. 33, 6, 433–442.

TURNER, K., ED. 1993. Using Formal Descrip-tion Techniques: An Introduction to ES-TELLE, LOTOS and SDL. Wiley, New York.

WALDEN, K. AND NERSON, J.-M. 1995. SeamlessObject-Oriented Software Architecture: Analy-sis and Design of Reliable Systems. Prentice-Hall, Englewood Cliffs, NJ.

WARD, P. AND MELLOR S. 1985. Structured De-velopment for Real-Time Systems. Prentice-Hall/Yourdon Press, Englewood Cliffs, NJ.

WEGNER, P. 1992. Dimensions of object-ori-ented modeling. Computer 25, 10, 12–20.

WEINBERG, V. 1978. Structured Analysis. Your-don Press, Englewood Cliffs, NJ.

WIERINGA, R. 1996. Requirements Engineering:Frameworks for Understanding. Wiley, NewYork.

WIERINGA, R. AND SAAKE, G. 1996. A formalanalysis of the Shlaer–Mellor method: To-wards a toolkit for formal and informal re-quirements specification techniques. Req.Eng. 1, 106–131.

WIERINGA, R., JUNGCLAUS, R., HARTEL, P., SAAKE,G., AND HARTMANN, T. 1993. OMTROLL—object modeling in Troll. Proceedings of theInternational Workshop on Information Sys-tems—Correctness and Reusability (IS-CORE’93), Udo W. Lipeck and G. Koschorrek,Eds. Institut fur Informatik, Universitat Han-nover, Germany, 267–283.

WIRFS-BROCK, R., WILKERSON, B., AND WIENER,L. 1990. Designing Object-Oriented Soft-ware. Prentice-Hall, Englewood Cliffs, NJ.

YOURDON, E. 1989. Modern Structured Analy-sis. Prentice-Hall, Englewood Cliffs, NJ.

YOURDON, E. AND CONSTANTINE, L. 1979. Struc-tured Design: Fundamentals of a Discipline ofComputer Program and Systems Design.Prentice-Hall, Englewood Cliffs, NJ.

YOURDON, E., WHITEHEAD, K., THOMANN, J., OPPEL,K., AND NEVERMANN, P. 1995. MainstreamObjects: An Analysis and Design Approach forBusiness. Prentice-Hall, Englewood, Cliffs,NJ.

YOURDON, INC. 1993. Yourdon™ Systems Meth-od: Model-Driven Systems Development. Pren-tice-Hall, Englewood Cliffs, NJ.

Received May 1997; Accepted January 1998



A Survey of Structured and Object-Oriented Software ... › robin › web › virtualclassroom ›...

Documents

Transcript of A Survey of Structured and Object-Oriented Software ... › robin › web › virtualclassroom ›...