©1998 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

This is a copyrighted publication of the IEEE. Further information and access can be found at http://www.ieee.org

This version of the referenced work is the FINAL published version of the article; per allowable IEEE copyright policies, it is exactly the same as what is available at http://www.ieee.org

The final published reference for this work is as follows:

T. Bahill, A. Mack, K. Bharathan, J. Clymer, D.L. Dean, J. Duke, G. Hill, E. LaBudde, E. Taipale, and A.W. Wymore. (1998). “The Design-Methods Comparison Project,” IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, 28:1, February, pp. 80-103. !

My!vita!can!be!found!at!http://marriottschool.byu.edu/directory/details?id=5305!!!

80 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

The Design-Methods Comparison ProjectA. Terry Bahill, Fellow IEEE,Mack Alford, K. Bharathan,Member, IEEE,John R. Clymer,Member, IEEE,

Douglas L. Dean,Member, IEEE,Jeremy Duke, Greg Hill,Member, IEEE,Edward V. LaBudde,Member, IEEE,Eric J. Taipale,Member, IEEE,and A. Wayne Wymore

Abstract—Early in the system design process, a design methodmust be chosen. This choice is usually dictated by what methodsthe designer has previously used, not by an open selection process.In this paper, we provide descriptions of some available designmethods and examples of their use. In this project, we will developbenchmark problems that will be solved by a variety of designmethods and will identify characteristics of problems that mightmake one system design method more or less appropriate. Thetop-level question we wish to answer is “for which type of problemis each method best?”

If a system is to be built, then the system must ultimatelybe described as a collection of state machines. However, thesestate machines are often not created by the systems engineers.The systems engineers use some method to create a high-levelabstraction of the desired system. Then they turn this abstractionover to the specialty engineers who actually reduce it to acollection of state machines. In this paper, we present solutionsfor a simple design problem by using the following 11 high-levelsystem design methods: state transition diagrams, algorithmicstate machine (ASM) notation, model-based system engineering,Graphical Description Language, RDD-100, structured analysis(using entity relationship diagrams, data-flow diagrams, and statetransition diagrams with Ward–Mellor notation), functional de-composition, object-oriented analysis (OOA) with Shlaer–Mellornotation, OOA and object-oriented design (OOD) with Boochnotation, an operational evaluation modeling-(OpEM)-directedgraph, and IDEF0. Each method was used by an expert userof that method. The solutions presented make it obvious that thechoice of a design method greatly effects the resulting systemdesign.

Index Terms—Architecture, design methodology, logic design,object-oriented methods.

Manuscript received September 9, 1996; revised May 1, 1997. An earlierversion of this paper was published inProceedings of the IEEE InternationalConference on Systems, Man, and Cybernetics,Beijing, China, Oct. 14–17,1996 [1].

A. T. Bahill is with Systems and Industrial Engineering, University ofArizona, Tucson, AZ 85721-0020 USA (e-mail: terry@sie.arizona.edu).

M. Alford is an independent consultant, Fayetteville, TN 37334-6029 USA(e-mail: alford@netcom.com).

K. Bharathan is with the Department of Surgery, University of Arizona,Tucson, AZ 85721 USA (e-mail: bhara@sie.arizona.edu).

J. R. Clymer is with California State University at Fullerton, Placentia,CA 92670 USA (e-mail: jclymer@fullerton.edu).

D. L. Dean is with the Center for the Management ofInformation, University of Arizona, Tucson, AZ 85721 USA (e-mail:ddean@bpa.arizona.edu).

J. Duke is with Intel, Chandler, AZ 85226 USA (e-mail:jeremy_duke@ccm.ch.intel.com).

G. Hill is with IBM Corporation, Tucson, AZ 85744 USA (e-mail:hill@vnet.IBM.com).

E. V. LaBudde is with LaBudde Systems, Inc., Westlake Village, CA91362 USA (e-mail: elabudde@pobox.com).

E. J. Taipale is with Lockheed Martin Tactical Defense Systems, Eagan,MN 55121 USA (e-mail: eric.taipale@lmco.com).

A. W. Wymore is with SANDS, Tucson, AZ 85718 USA (e-mail:wayne@sie.arizona.edu).

Publisher Item Identifier S 1094-6977(98)01529-6.

I. INTRODUCTION

EARLY in the design process, engineers must choose amethod for designing the system. This choice is usually

dictated by the methods that the systems engineer’s boss haspreviously used, not by an open selection process. In thispaper, we provide descriptions of available design methodsand examples of their use in order to help systems engineersselect an appropriate design method.

In engineering, the two general types of systems arecalled static and dynamic. To a first approximation, asmall bridge is described with methods of statics, whereasa pendulum is described with methods of dynamics. Atypical equation of statics is

which expresses the concept that a moment is equal to theforce times the moment arm. Whereas, dynamic systems aretypically described with state equations like these

and

But, of course, the distinction between static and dynamic sys-tems is artificial, being created for heuristic purposes. We studystatics first, then we build on that to study dynamic systems.Therefore, we can consider statics to be a subset of dynamics.

In the literature about computers, these two types of systemsare called combinatorial and sequential, respectively. Staticsystems are synonymous with combinatorial systems, anddynamic systems are synonymous with sequential systems. Forcombinatorial systems, the output depends only on the presentinputs, whereas for sequential systems, the output depends onthe present inputs and the state of the system. The state of thesystem depends upon the starting state and the history of theinputs. But, once again, the distinction between combinatorialand sequential logic systems is artificial. We study combi-natorial systems first and then use this knowledge to studysequential systems. Therefore, we can consider combinatorialsystems to be a subset of sequential systems. So, without lossof generality, we can discuss only sequential logic systems,which is what we will do in this paper.

In 1936, Turing [29] stated that all solvable sequential logicproblems could be solved with a Turing machine (a statemachine). Therefore all buildable systems are state machines.So, for the last six decades, system designers have focusedtheir attention on designing state machines. But designingstate machines for big, complex systems can be difficult. So,

1094–6977/98$10.00 1998 IEEE

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 81

engineers and computer scientists have invented methods tohelp design state machines. This paper compares and contrastsmany of these methods.

If a system is to be actually built, then the system mustultimately be described as a collection of state machines.However, these state machines are often not created by thesystems engineers. The systems engineers use some method (ortool) to create a high-level abstraction of the desired system.Then they turn this abstraction (or design) over to the specialty(component) engineers who actually reduce it to a collectionof state machines. In this paper, most of our authors stoppedwith the high-level abstraction.

Two approaches have been taken for describing systemdesigns: 1) describe many systems and many design methods[20] and 2) describe one problem and many design methods[24], which is what this paper will do. In this project avariety of methods will be used to solve several benchmarkproblems. Therefore, a big part of the project is developingthese benchmark problems. Examples of benchmark problemsare on the World Wide Web [12], [25]. The top-level questionwe wish to answer is “for which type of problem is eachmethod best?”

This paper presents the beginning of a long project. Weintend to enlarge the project by including more methods andmore complex problems. Note that the problem presented inthis paper does not do justice to big tools like RDD-100,the Graphical Description Language [17], and object-orienteddesign, all of which were created for large, complex systems.It will seem as if these tools are cracking a walnut with asledgehammer.

In this paper we present one problem. Then, our 11 authorsuse 11 different methods to design solutions for this problem.The purpose is to provide a comparison of these methods.

Nomenclature:Most of these methods use data inputs,functions, states, control inputs, and objects. Data or materialinputs are transformed into outputs by functions. For example,burning paper transforms it into ash. Functions are usuallynamed with verb phrases. Functions are called processes bysome methods and activities by others. The state of the systemcaptures the history of the system. The present state and thesequence of future inputs allow computation of future states ofthe system. States should be named with historical statements.States are called modes with some methods. Control inputsturn functions on and off and trigger transitions between states.Objects are people, places, things, or transactions that sharecommon attributes and perform common functions. Objects areusually named with adjectives and nouns. Objects are calledentities with some methods and mechanisms with others.

II. STATEMENT OF THE TRAFFIC-LIGHT PROBLEM

There is an intersection between a seldom-used farmroadand a busy highway. A farmer has difficulty getting acrossthe highway, so we are to install a traffic-light system, asillustrated in Fig. 1. Design a controller for this traffic-lightsystem.

Normally, the highway light shall be green and the farmroadlight shall be red. When a sensor signals that a tractor is on

Fig. 1. The farmroad–highway intersection.

TABLE ICONVENIENT ABBREVIATIONS

the farmroad, the highway light shall change to yellow. Aftera short-time interval(STI, nominally 10 s), the highway lightshall change to red and the farmroad light shall change togreen. The farmroad light shall stay green until the tractorclears the sensor or after along-time interval(LTI, nominally50 s), whichever comes first. Then the farmroad light shallbecome yellow. After an STI, the farmroad light shall becomered and the highway light shall become green. The systemshall stay in that state for a least an LTI. After an LTI, thehighway light shall be switched when the sensor detects atractor. A timer that produces output signals after STI’s andLTI’s will be available. It can be restarted at anytime. Table Isuggests some abbreviations. This problem is based on Meadand Conway [9] and Katz [6].

82 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 2. State transition diagram.

III. SOLUTIONS TO THE TRAFFIC-LIGHT PROBLEM

A. Solution via State Transition Diagrams1

The following states are sufficient for this controller.

1) Highway-green commands the highway green and thefarmroad red lights to be on.

2) Highway-yellow commands the highway yellow and thefarmroad red lights to be on.

3) Farmroad-green commands the farmroad green and thehighway red lights to be on.

4) Farmroad-yellow commands the farmroad yellow andthe highway red lights to be on.

This Finite State Machine solution begins with a statetransition diagram where each oval represents a state. Thename of the state is in the top of the oval and the values of theoutputs are in the bottom. For the state transition diagram ofFig. 2, the six output numbers represent the values for CHWG,CHWY, CHWR, CFRG, CFRY, and CFRR, respectively. Allpossible state transitions are not shown: only those that areexpected to occur are shown. A bar on top of an inputabbreviation symbolizes negation. A dot () represents theBoolean AND function, and a plus sign () represents theBoolean OR function.

Typical state machines have either level outputs or pulseoutputs. This state machine is unusual because it has both.When the system is in the stateHighway-green, the outputcommand highway green light onand the outputcommandfarmroad red light onare both one (on). The other lightcommands are zero (off). These are level outputs; these outputsare associated with the states. State machines with leveloutputs are sometimes called Moore machines. The outputreset and start the timeris a pulse output; it is associated withthe transitions between states. It is only valid for a short time, apulse. State machines with pulse outputs are sometimes calledMealy machines [16].

We will now show two more views of this finite state-machine traffic-light controller. Use of these extra viewsenhances the probability of completeness, aids creation of adetailed design by specialty engineers, and provides a way tovalidate the design.

We wish to implement and validate the controller with TTLcircuitry and two JK flip-flops, which will be named A andB. First, we transform the state transition diagram into the

1A. T. Bahill.

state table shown in Table II. Each row of the table containsa transition from one state to another. Therefore, there will beone row in the table for each arrow in the diagram: exceptarrows labeled with Boolean OR functions require two rows.

Now we can write the Boolean equations for the flip-flopinputs and for the outputs we are controlling.

Now that we have built a circuit, we can validate it. We dothis by applying a multitude of input trajectories and lookingto see that the system produces appropriate output trajectories.For example, Table III shows one correct input–output pair.Time runs from top to bottom. Many input–output trajectories,such as this one, would be used to prove that the circuitperforms correctly.

After the technology was selected, this design was passedoff to the specialty design engineers. They implemented thestate transition diagram of Fig. 2 with the hardware shownin Fig. 3. In doing so, they did not change the design, butthey did require a clarification of whether the timer producedlevel or pulse outputs. Mixing of pulse and level outputs alsocaused some complication.

The strong point of state transition diagrams is that theyconveniently show the inputs, outputs, and states in a mannerthat is well suited for human visualization. They can be builtincrementally by using input–output trajectories, as shown inTable III.

B. Solution via Algorithmic State Machine (ASM) Notation2

ASM notation builds on the foundation of state transition di-agrams by providing a means to express the state trajectory asa conditional flow [13]. This is accomplished by incorporatingconditions, or decision points, and distinct output points withinthe ASM charts. ASM charts are composed of multiple ASMblocks, each block with exactly one state, at least one output,and exit conditions. ASM blocks have a single entry point, butcan have multiple exit paths. There is an unambiguous exitpath (state transition arrow) for each combination of inputs.Fig. 4 shows an example ASM block. Outputs are listed inthe state box or inside the ovals, depending on whether theyare associated with the state or with the transition betweenstates. The specified exit condition is checked on each clockcycle to determine the next state.

Fig. 5 shows the ASM chart for the traffic-light controller.In ASM charts,H.output means the specified output will beasserted high in the given state or transition. For example,

2This section is based on ch. 8 of Katz [16].

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 83

TABLE IISTATE TRANSITION TABLE.

NOTE: dc STANDS FOR DON’T CARE. IT MAKES NO DIFFERENCE WHETHER THESE ENTRIES

ARE ONE OR ZERO BECAUSE THEY WOULD NOT EFFECT A CHANGE OF STATE OR OUTPUT

Fig. 3. Implementation of the finite state machine.

in the stateHighway-green, the outputsCHWG and CFRRare asserted high, meaning these lights are turned on. Theunmentioned outputs are, by implication, not asserted, meaningthey are low or off. The Boolean function of LTI AND Sen iscontinually checked. If it is logic zero, then the machine staysin stateHighway-green. If it is logic one, then the machinegoes to the stateHighway-yellowand the outputRestart isasserted high during this transition.

This solution is very similar to the previous state transitiondiagram. However, ASM charts have some advantages overstate transition diagrams. ASM charts concentrate on the pathsand conditions for exiting a state. These exit conditions canbe built up incrementally and later combined into a singleBoolean condition. It is easy to understand the resulting designas an algorithm. ASM charts also partition the algorithmsinto fundamental building blocks, defining interfaces betweenthese blocks. This partitioning makes it easier to design more

Fig. 4. ASM block.

complex systems. This method transitions easily into HardwareDescription Languages, such as VHDL, that are used to designcomputers [16].

C. Solution via Wymorian Notation3

The traffic-light controller can be described as

Z (SZ, IZ, OZ, NZ, RZ) [5], [31], [32], where/* Items enclosed with/*’s like this are comments*//* Listing of the possible states*/

3A. T. Bahill.

84 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

TABLE IIISAMPLE INPUT–OUTPUT TRAJECTORIES

SZ Highway-green, Highway-yellow,Farmroad-green, Farmroad-yellow,

/* Listing of the four input ports and their legalvalues*/

IZ I1Z I2Z I3Z I4Z, whereI1Z(Initialize) , /*The legal values for thisport are 0 and 1. A 1 on this portwill put the controller in theinitial state.*/I2Z(Sen) , /*A 1 at this port means that thesensor has detected a vehicle on thefarmroad*/I3Z(STI) , /*A 1 at this port means that theSTI has expired*/I4Z(LTI) , /*A 1 at this port means that theLTI has expired*/

/* Listing of the seven output ports and their legalvalues*/

OZ O1Z O2Z O3Z O4Z O5Z O6Z O7Z,where

O1Z(CHWG) On, Off , /* Command highwaygreen light on or off*/

O2Z(CHWY) On, Off , /* Command highwayyellow light on or off*/

O3Z(CHWR) On, Off , /* Command highway redlight on or off */

O4Z(CFRG) On, Off , /* Command farmroadgreen light on or off*/

O5Z(CFRY) On, Off , /* Command farmroadyellow light on or off*/

O6Z(CFRR) On, Off , /* Command farmroad redlight on or off */

O7Z(Restart) , /* Reset and startthe timer*/

/*The next state function lists the transitions betweenstates. Each entry shows[a present state, (an inputcombination)] the next state. */NZ ([Highway-green, (LTI Sen)] Highway-green),([Highway-green, (LTI Sen)], Highway-yellow),([Highway-yellow, (STI)], Highway-yellow),([Highway-yellow, (STI)], Farmroad-green),([Farmroad-green, (LTI Sen)], Farmroad-green),([Farmroad-green, (LTI Sen)], Farmroad-yellow),([Farmroad-yellow, (STI)], Farmroad-yellow),([Farmroad-yellow, (STI)], Highway-green),([ANY-state, (Initialize)], Highway-green),/* The readout function lists the states and the outputsthat are appropriate for each*/RZ [Highway-green, (CHWG, CFRR, Restart)],[Highway-yellow, (CHWY, CFRR, Restart)],[Farmroad-green, (CHWR, CFRG, Restart)],[Farmroad-yellow, (CHWR, CFRY, Restart)].

This design might fail depending on whether the timer istriggered on the leading or trailing edge. This implementationhas difficulty handling both level outputs (Moore machines)and pulse outputs (Mealy machines). In this example, the

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 85

Fig. 5. ASM chart for the traffic-light problem.

light commands (e.g., CHWG) are level outputs, whereas theRestart signal is a pulse output, but the notation does notdistinguish between them.

Some advantages of this notation are that 1) it works forproblems with a large number of states, 2) its designs can beimplemented with a very simple text processor, a typewriteror even HTML, and 3) it is mathematically rigorous, so itsdesigns can be verified by computer.

D. Solution via Model-Based Systems Engineering4

The traffic-light controller can be described as

Z (SZ, IZ, OZ, NZ, RZ) where/* Listing of the possible states*/SZ Highway-green-initial, Highway-green-wait,

Highway-green, Highway-green-transition,Highway-yellow, Highway-yellow-transition,Farmroad-green, Farmroad-green-transition,Farmroad-yellow, Farmroad-yellow-transition,

/* In the state Highway-green-initial the systemrestarts the clock to ensure that the highwaygreen light is on at least for the long timeinterval, then transitions to the stateHighway-green-wait to wait for the long timeinterval to elapse, then transforms to the stateHighway-green, which means that the green highwaylight has been on for the LTI and the system cannow respond to a tractor input, Sen 1. *//*Listing of the four input ports and theirlegal values*/IZ I1Z I2Z I3Z I4Z,where IkZ for every k 1, 2, 3, 4 ,/* 1 at I1Z sets Z to the state Highway-green initial;1 at I2Z means a vehicle was detected1 at I3Z means a STI has expired;1 at I4Z means a LTI has expired.*//* Listing of the seven output ports and theirlegal values*/

4A. W. Wymore.

OZ O1Z O2Z O3Z O4ZO5Z O6Z O7Z,

where OkZ 0,1 for every k IJS[1, 7],/* Outputs from O1Z are commands to the highwaygreen light, 1 means on,Outputs from O2Z are commands to the highwayyellow light, 1 means on,Outputs from O3Z are commands to the highway redlight, 1 means on,Outputs from O4Z are commands to the farmroadgreen light, 1 means on,Outputs from O5Z are commands to the farmroadyellow light, 1 means on,Outputs from O6Z are commands to the farmroad redlight, 1 means on,Outputs from O7Z are commands to the timer, 1 meansreset and restart. *//* If the highway green or highway yellow lights

are on, then the farmroad red light should be on.Similarly, if the farmroad green or farmroad yellowlights are on the highway red light should be on.These conditions will be reflected in the definitionof RZ below.*/

/* The next state function lists the transitionsbetween states. In this function,representsa particular value for one of the input ports andrepresents a particular value for the state. Thus, thefourth next state entry in the following table can beread as ”The next state is Highway-green,” if(the present state) is Highway-green-wait ANDLTI(p)(the present value ofLTI ) is logic 1. */If p IZ, p [Initialize(p), Sen(p), STI(p),LTI(p)], and x SZ then NZ(x, p)

Highway-green-initialize if initial(p) 1;Highway-green-wait if x Highway-green

-initial;Highway-green-wait if x Highway-green

-wait AND LTI(p) 0;Highway-green if x Highway-green

-wait AND LTI(p) 1;Highway-green if x Highway-green

AND Sen(p) 0;Highway-green-transition if x Highway-green

AND Sen(p) 1;Highway-yellow if x Highway-green

-transition;Highway-yellow if x Highway-yellow

AND STI(p) 0;Highway-yellow-transition if x Highway-yellow

AND STI(p) 1;Farmroad-green if x Highway-yellow

-transition;Farmroad-green if x Farmroad-green

AND LTI(p) 0 ANDSen(p) 1;

Farmroad-green-transition if x Farmroad-greenAND LTI(p) 1 ORSen(p) 0;

86 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 6. Block diagram view.

Farmroad-yellow if x Farmroad-green-transition;

Farmroad-yellow if x Farmroad-yellowAND STI(p) 0;

Farmroad-yellow-transition if x Farmroad-yellowAND STI(p) 1;

Highway-green-wait if x Farmroad-yellow-transition.

/* Thereadout function RZ is a set of pairs of theform: [state, (CHWG, CHWY, CHWR,CFRG, CFRY, CFRR, Restart)]. */RZ [Highway-green-initial, (1,0,0,0,0,1,1)],

[Highway-green-wait, (1,0,0,0,0,1,0)],[Highway-green, (1,0,0,0,0,1,0)],[Highway-green-transition, (1,0,0,0,0,1,1)],[Highway-yellow, (0,1,0,0,0,1,0)],[Highway-yellow-transition, (0,1,0,0,0,1,1)],[Farmroad-green, (0,0,1,1,0,0,0)],[Farmroad-green-transition, (0,0,1,1,0,0,1)],[Farmroad-yellow, (0,0,1,0,1,0,0)],[Farmroad-yellow-transition,(0,0,1,0,1,0,1)].

This solution with model-based systems engineering no-tation [31] handles the so-called “pulse” output simply by

inserting a “transition” state, during which the “pulse” outputis generated. This way, the advantages of the Moore machinecan be enjoyed (Moore machines are absolutely essential fora useful theory of system coupling) and the fiction of theegregious, gratuitous “pulse” output is properly represented.With the model-based systems engineering notation, systemswith a large number, even an infinite number, of states can bedefined and manipulated efficiently [5], [31], [32].

E. Solution via Graphical Description Language 5, 6

1) Basic Concepts of the Method:The method uses fiveorthogonal graphical views of the system design [17].

Block Diagram View (Fig. 6):This is a modification ofa popular concept that relates inputs, outputs, and transferfunctions. Two special additions are included. First, all changesin functional behavior that are logic-dependent must be shownwith the use of a switch; the switch must show how func-tionality is changed. Second, it is assumed that all controllogic elements are separated from the process functions and

5Graphical Description LanguageTM and GDLTM are trademarks ofLaBudde Systems, Inc.

6E. V. LaBudde.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 87

Fig. 7. Mode matrix, state diagram, and timeline.

are located in a finite state-machine controller. The controllerexecutes the logic operations that change functionality.

Mode Matrix View (Fig. 7): The mode matrix view re-quires that every valid combination of switch settings be givena name and called a mode. Both lock step and concurrent(parallel) modes are represented this way. The switch settingfor every mode must be contained in the matrix.

State Diagram View (Fig. 7):The state diagram view re-quires a bubble for every mode (state) in the mode matrix table.In this paper, we will make no distinction between a mode anda state. A transition arrow for each possible transition betweenstates is also required. Each transition arrow is labeled with thecontrol conditions that must be true to enable that transition.

Timeline View (Fig. 7):The timeline view shows theevents that trigger changes in modes. Each event is a transitionarrow in the state diagram. The timeline must show whichmode occurs after the event and any responses that the systemgenerates. The timeline denotes the required sequence ofevents or inputs–outputs and any time requirements betweenobjects in the diagram. For every path through the statediagram, a timeline exists.

Performance View (not shown in any figure):Perfor-mance requirements are numerical requirements and can be

applied to any object in any other view. Thus, inputs, outputs,processes, modes, logic, and timing may all possess perfor-mance requirements. Performance requirements are usuallyderived by the use of math models. The math model isvisualized with a performance tree. The performance treedisplays how requirements are either decomposed into lowerrequirements (flow down) or how lower level requirements rollup to higher level requirements (flow up). Performance treesshow how the requirements are decomposed into parametersthat are displayed in the other views.

2) Physical Decomposition:These five views are used inall levels of the system hierarchy. In theMission Level(Fig. 8),the mission phases and scenarios are used to define user andsystem interfaces. TheSystem Levelshows all the interactionsbetween elements used to create a system. TheElement Levelshows all the interactions between the subsystems used to cre-ate an element. TheSubsystem Levelshows all the interactionsbetween functions used to create a subsystem. TheFunctionLevelshows all the interactions between subfunctions used tocreate a function. TheSubfunction Levelview shows all theinteractions between components used to create a subfunction.

3) Functional to Physical:The views are used to createboth a functional description (what it does and how it works)

88 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 8. Mission phases.

and a physical description (how it is made). The hand-off between the system engineer and the design engineerusually happens at the function level. The design engineertranslates a function into an assembly. The design engineerthen uses the same diagrams to define the physical assembly.Consequently, there is a requirement to make a functional-to-physical translation map. This is usually done by definingwhich functional elements are allocated to which physicalentity. It is at this level where the hardware and softwareallocations are usually made.

This process means two parallel representations of thesystem at the same level may exist (functional and physical).The system engineer maintains the functional and the designengineer maintains the physical, with the translation mapshowing traceability.

4) Hierarchical Decomposition:A totally top-down de-composition is not always possible or necessary. The use oforthogonal views and a hierarchy of decomposition allowsthe system development to be created with many parallelactivities. The views define how the components interact andallow for items at any level to be integrated into the systemdescriptions. This means that bottom-up development caneasily be integrated into top-down or horizontal structureswith complete traceability.

Block diagrams, mode matrices, state diagrams, and per-formance trees are hierarchical. This means that it is possibleto replace a black-box view of an object with a lower levelfunctional view (gray box) without going outside the boundaryof the higher level black box. If it is necessary to go outside theboundary, the views make it obvious that there is a functionalproblem with the higher level.

The timeline cannot be hierarchical. However, more detailsare created at lower levels. Timelines can diverge alongconcurrent (parallel operation) paths at lower levels. Un-fortunately, there can be an explosion of the timelines atlower levels due to all possible combinations of states andconcurrency, but this problem can be contained by the use ofsome rules in identifying the critical time paths and minimizinginteractions.

5) Functional Decomposition:Our method requires the de-composition to begin with the mission level. Here all phases ofthe system utilization must be laid out. The phase analysis mustshow the lifecycle of the mission. A sample phase diagram isshown in Fig. 8.

In eachphasethere can be more than one “scenario.” Ascenariomust show details of the interface between allsystemsandusersemployed in each phase. A sample scenario diagramis shown in Fig. 9.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 89

Fig. 9. Operating phase scenario.

In this scenario, we can see that there is considerableinteraction between the varioussystemsand manyinterfacecontrol documentswill be required to specify all the interfacerequirements. One of the obvious requirements is specifyingthe STI. Here we can see that the response time of the highwayuser is critical (shown in the timeline in Fig. 7). The operating-phase scenario illustrates the need to specify the following:

1) power system requirements;2) environmental conditions;3) user response characteristics;4) vehicle characteristics;5) road characteristics; and6) traffic-light optical properties.

When these items are specified, the time intervals can be deter-mined. The sample problem ignores all of these requirements.

System Level:After the scenario is defined, thesystemsthat are identified in the scenario are decomposed intoel-ements. The transportation system haselementsof highway(H/W), farmroad (F/R), and traffic lights.

Element Level:The traffic-light elementview is shownin Figs. 6 and 7. Theblock diagram, mode matrix, statediagram, and timeline are shown. There are noperformancetrees for this problem because of the lack of suitable higherlevel details in the problem statement. Because of the lackof problem statement detail (and to save space), the diagramsshown in Figs. 8 and 9 are functional only and do not show

all the requiredsubsystems, such as power supply, mechanicalstructure, cooling, interconnection, and similar items.

Functional to Physical:There are unlimited ways to im-plement the functional requirements: diode-relay logic, digitalelectronics, microcomputer and firmware, and so on. In theinterest of space, we will not show the functional-to-physicaltranslation for this sample problem. If we did, it would showthe physical circuits, devices, and hardware/software partitionand traceability to the functional design.

This system design methodology makes clear the missingrequirements in the sample problem and identifies how torectify the problem statement. The method is a true systemdesign tool, not tied to any specific design implementation(manufacturing technology) and ensures complete, accurate,and unambiguous statement of requirements. Additionally,the method is substantially more robust than the existingsystems and software representations, and it ensures thatallrequirements are captured and tracked. Not only is it easyto learn and use, but it can be implemented with low-costcommercial office automation software.

F. Solution via RDD-1007, 8

The RDD-100 model of the traffic-light problem shownin Fig. 10 uses the points in time at which signals change

7M. Alford.8RDD-100TM is a trademark of Assent Logic Corp., San Jose, CA.

90 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 10. The RDD-100 model.

as “trigger” messages that propagate through the model. Themodel uses a separate process for the sensor, the controller, thetimer, the highway light, and the farm light; these are shownas columns in Fig. 10, which are “concurrent branches” of agraph.

To help explain this model let us walk through a few stepsin one sequence of events. A tractor crosses the sensor, so the“tractor arrives” box in the upper left corner sends a signal“Sen ” to the “wait for tractor box.” The controller is thusreleased from this box and goes to the “turn highway red,farmroad green” box. During the transition, the CHWYsignal is sent to the highway light releasing it from the “showHG” box and allowing it to move to the “show HY” box. Atthe same time, a “start ” signal goes to the timer, releasingit from the “wait for timer reset box,” and so on.

The sensor iterates by sending Sen and Senmessages; for simulation purposes, one specifies the numberof iterations after which the sensor process delays, terminates,and then kills off all other processes.

The timer process is a loop that waits until a reset arrives,then delays until the STI is sent; it then waits until either

LTI is sent or a reset arrives. This cycles twice for everytime the controller cycles once. The farm and highway lightsloop through their green-yellow-red sequences as commandedby the controller.

The controller loops through the sequence of commandingthe lights. The Sen message results in CHWY andreset of the timer. The CFRG and CHWR are sentwhen either Sen or STI arrive. All further Senmessages are then ignored. The timer is reset; the CFRYis sent; CFRR is sent when STI arrives; and thecycle repeats when LTI arrives. This model is executableand when executed, yields timelines and a demonstration ofdynamic consistency of inputs and outputs. To ensure that allof the requirements have been satisfied, each requirement is“traced to” some function that implements it. This verificationprocess revealed one possible ambiguity in the followingrequirement: “when a sensor signals that a tractor is on thefarmroad, the highway light shall change to yellow.” What is tooccur when the tractor does not move, and hence, the Sensignal is never sent—should the system cycle again? If so, thebehavior would have to be modified to reflect this decision.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 91

Fig. 11. Entity relationship diagram.

Fig. 12. Data-flow diagram.

The RDD-100 design was the first design of those presentedin this paper to be validated. This was done by runninga simulation and observing the input–output behavior. Thishighlights a very significant facet of systems engineeringdesign methods: ease of validation. RDD-100 has validationtools built into the design tool.

G. Solution via Structured Analysis9

There are three principal model views in most flavors ofstructured analysis [3], [9], [30]. Each of these views will beillustrated for the traffic-light problem. The first view of thesystem is the entity relationship diagram. This view depicts theprincipal tangible or logical entities in the problem domain,along with their relationships to each other. Relationships areusually of the typeshas-a, uses, is-a, performs, documents,controls, etc.The diagram may also contain cardinality infor-mation. In the entity relationship diagram of Fig. 11, a singleentity, controller, represents the solution to the traffic-lightcontroller. (At this stage, decomposing the solution into morethan one entity may suggest a preconceived design solution.)The entity relationship diagram shows the relation the systemwill have with the entities external to it in the problem domain.For instance, the controller entity uses one timer and twosensors: it controls two HWLights and two FRLights. If noline exists between two entities, then those two entities needknow nothing about one another. Partitioning relationships inthis manner makes the system design much easier.

The second view is a data-flow diagram, as shown inFig. 12. Each oval on the data-flow diagram represents aprocess that the system will be required to perform. A process

9E. J. Taipale.

Fig. 13. Ward–Mellor state transition diagram.

transforms an input into an output. In this paper, we will makeno distinction between a process and a function. The solidcircles with arrows represent data required by the process.The arrow indicates the direction in which the data flows. Theunfilled circles with arrows represent events that occur as aresult of the process each arrow points away from. In Fig. 12,the processesCommandHWLightandCommandFRLightbothrequire one piece of data, the color the light should turn. Theseprocesses also return data, either an acknowledgment that theprocess was successfully performed or an error message. TheprocessResetTimertakes one piece of data in, but returns nodata. Instead, this process notifies the processWaitForEventof two events for which it is responsible, STI and LTI. Thisdiagram illustrates two important aspects of this system: theflow of data from one process to another and an enumerationof processes that the system must perform. As with the entityrelationship diagrams, the lines connecting two processes areimportant because they effectively partition the functionalityof the system. Although intuitive in this case, this data-flowdiagram shows that the processResetTimerneed know nothingabout the processes for changing the color of the traffic lights.

The third view is a state transition diagram, as shown inFig. 13. This diagram uses the Ward–Mellor notation [30],a notation that is particularly effective in modeling event-driven systems. This view clearly represents the logical flow

92 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 14. Level 1 functional block diagram.

Fig. 15. Level 2 functional block diagram for theINIT function.

of system operation, detailing which events the system willand will not respond to under all circumstances as well asthe functions performed by the system at each point in itsoperation. The notation is simple and easily understood byconsulting the symbology legend on the figure.

Generally, events depicted on the state transition diagramcorrespond to events on the data-flow diagram, but theremay be some overlap between what is an event and whatis data in practice. For example, the eventsSensorTriggerand SensorClearon the state transition diagram correspondto different values of the data objectRoad Statusin the data-flow diagram. In this case, a particular change in value of theRoad Statusdata represents the occurrence of the event. Sincethe sensor will be polled, this is an accurate way to representsystem operation.

The structured analysis process is hierarchical. In the nextlayer of the hierarchy, the design team will assign func-tions from the data-flow diagram to subentities of the con-troller entity. These combinations will form requirements forsubsystem-level components of controller. The same threediagrams will be generated for each of the subsystems of thecontroller, and the process will continue until the subsystemshave been decomposed into tractable design problems (a resultdefined by the systems engineer or design team.)

Each view illustrates an important aspect of the system.Taken together, the three views provide a complete model ofthe system, in terms of the principal entities, data elements, andlogical operation of the system. However, structured analysishas some deficiencies. It does not provide a formal mechanismto recognize system components and operations that maybe shared between entities in the system. For example, thefarmroad light and the highway light are almost certainly verysimilar physical devices. Further, the functionality requiredin the controller to operate the two light devices is probably

very similar. Traditional structured analysis has no corollaryto the concept of subclassing or inheritance amongst entitiesthat would capture this type of information. Therefore, beyonda certain scope of design problem, structured analysis has thepotential to create more work for a design team. However, forproblems of small scope, such as the traffic-light problem, thestructured analysis methods work well.

H. Solution via Functional Decomposition10

The problem statement usually serves as the top-level func-tion [10], [22]. At the top level, the vocabulary of the prob-lem domain, not of a particular solution dominates. For thetraffic-light problem, the top-level function might be “controlthe traffic lights at the intersection.” This function is thendecomposed into smaller subfunctions. The decompositionprocess is hierarchical; each of the subfunctions may befurther decomposed into subsubfunctions until all functionsrepresent tractable design problems of appropriate scope, acondition defined by the systems engineering team. Functionaldecomposition generates a block diagram of the functionsperformed by a system, as shown in Fig. 14.

Arrowheads indicate that something, such as data or asignal, passes from the output of one function into the inputof the next. Vertical lines between the centers of two functionboxes indicate that the upper box function must start beforethe lower box function can start. Vertical lines extendingdownward from the right side of a box indicate that the lowerfunction begins after the top function has completed. Verticallines extending upwards from the left side of a box indicatethat the top function begins concurrently with the bottomfunction (this figure has no such lines). In general, the controlflow moves from left to right and top to bottom.

Each of the functions in this figure can be decomposedinto subfunctions. Functions that have been decomposed areindicated with an asterisk (*) after the function number. Forexample, theINIT function 1.* is decomposed in Fig. 15. TheINIT function performs the initialization routines the systemneeds prior to entering operational status. The numbering ofthe functions shows the parent-child relationships as well asthe level of the decomposition.

10E. J. Taipale.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 93

Fig. 16. Level 3 functional block diagram for the functionObtain controllerhardware-OK signal.

Fig. 17. Level 2 functional block diagram for the functionCommand HWlight yellow.

The level 2 decomposition of theINIT function shows thesubfunctions ofINIT. It also shows something the top-leveldiagram did not: an error condition. IfINIT can accomplish itssubfunctions successfully, the function flow moves from leftto right, as in the level 1 decomposition. If a subfunction fails,however, INIT will branch into a subfunction calledSignalERROR. Note that nothing flows out ofSignal ERROR, it is acontrol sink. If the system moves intoSignal ERROR, functionINIT will never be completed and the system will not beginoperational mode.

After the level 2 decomposition, it is again appropriateto determine whether another level of decomposition is nec-essary for each of the new subfunctions. For example, thesubfunctions involved in theINIT function are good candidatesfor further decomposition. The functionObtain controllerhardware-OK signalmight be decomposed, as in Fig. 16.

The level 2 decomposition of another function,CommandHW light yellow, would proceed, as shown in Fig. 17. Al-though this decomposition is trivial, it points out somethinginteresting in the design. The lines are vertical, indicating thatno signal ever passes to the controller to indicate whether thelights are actually turned off or on. Early in the design, thisdecomposition has already pointed out a potential flaw.

Determining when functions have been sufficiently decom-posed is a matter left to the discretion of the systems engineer.In some cases, a third-level decomposition of the problemmight be adequate. In other cases, the systems engineer mightwish to continue the process until subfunctions resemble linesof pseudocode or simple human or machine operations.

Functional decomposition became popular as a softwaremethod when software systems were generally of muchsmaller size than the systems of today. It is perhaps forthis reason that functional decomposition most effectivelymanages systems of small to moderate complexity. It scalesto this small problem nicely, in contrast to more formalmethodologies that would impose far more rigor (and effort)for marginal additional benefits. While it is clear that had thedecomposition of each function into subfunctions taken place,

Fig. 18. Example IM diagram.

Fig. 19. IM for the traffic-light problem.

a large number of diagrams would have been necessary; thereis not much overhead information included in the notationthat is not absolutely essential to the operation of the system.

On the other hand, in the absence of such overhead, thereis little information to reveal relationships and similaritiesbetween functions and the entities that perform those functions.For this reason, the functional decomposition process tendsto become more unwieldy when systems become large andcomplex. We have found functional decomposition to be themost difficult of the system design methods we have used.

I. Solution via Shlaer–Mellor Object-Oriented Analysis11

For the given problem statement, I will show a solutionbased on the Shlaer–Mellor [26], [27] flavor of object-orientedanalysis (OOA). My solution includes just some of the keyparts of Shlaer–Mellor OOA, which are quite sufficient fordealing with the complexity of this problem.

First, I will construct an information model (IM). The IMidentifies the real-world objects involved, subtype–supertypehierarchy, relationships, and cardinality. From the problemstatement, we can identify the objects as follows: highwaylight, farmroad light, tractor, sensor, and timer. (Objects werecalled entities in the structured analysis section.) Since thesensor and timer provide identical inputs (STI, LTI, and Sen)to both the highway light and farmroad light, we can generalizea supertype object of traffic-light, for which the highwaylight and the farmroad light are subtypes. We show therelationships common to both lights as relationships with thetraffic-light supertype object. The relationships are shown aslines connecting two objects and are identified by asymbolcontaining a unique number, such as . Text on each side ofthe symbol identifies the meaning of the relationship, andthe number of arrowheads indicates the cardinality. Fig. 18contains an example where one P sees many Q objects, ormany Q’s are seen by one P, and Fig. 19 contains the IM forthe traffic-light problem.

The purpose of the IM is to ensure that no real-world objectswere omitted in the analysis and that every object included

11G. Hill.

94 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 20. State model for the farmroad light.

in the IM really is an essential part of the system, i.e., nounrelated islands. Using the IM as a checklist, we evaluateeach object to determine if it is an active or passive object.Active objects have lifecycles in which they pass throughvarious states, and their behavior can be represented in a statemodel or state machine. Passive objects have no lifecycle.

For each nontrivial active object in the IM, we need to showthe state model behavior as a state machine. We also need todetermine if a single state machine for a supertype object willcorrectly represent the behavior of all its subtypes. If not, thena separate state machine is needed for each subtype object.

From the problem statement, we know that the highwaylight and the farmroad light do not have identical behavior.Therefore, we must have a separate state machine for each,rather than a single state machine for the traffic light. Also,from the problem statement, we know that a tractor is eitherpresent or absent in the eyes of the sensor, but since the sensordoes all the work of detecting, we can consider the tractor to bea passive object, and so it does not need a state machine. Thesensor can be either a trivial active object or a passive object.As a trivial active object, it passes back and forth between thetwo states of detecting presence and detecting absence of atractor. As a passive object, it is merely the owner of the globalSen input signal. In either case, it needs no state machine,since the highway light and the farmroad light both get allthe information they need about the sensor by recognizing theSen input signal. Similarly, the timer needs no state machine,since the highway light and the farmroad light both get allthe information they need about the timer from recognizingthe STI and LTI input signals. However, we must be surethat highway-light state machine and the farmroad-light statemachine both make correct use of the Sen, STI, and LTI inputsignals.

The state model behavior of the highway light and farmroadlight are shown in Figs. 20 and 21. In each state machine,states are shown as boxes and transitions are shown as arrowsfrom a source state to a destination state. The only exceptionto this (an arrow with no source state) is used to identify aninitial entry point or starting state in the state machines. Thestate boxes contain a state name, followed by the activities

that are executed when the object enters that state. At theconclusion of the activities, the object sits idle until an eventoccurs that causes a transition to the next state. The event isidentified near each arrow that shows a state transition. Thenotion of activities happening within states follows the theoryof Moore machines, whereas another theory (Mealy machines)has the activities associated with the transitions or arcs.

In the state machines of Figs. 20 and 21, the action “Restart”means that we toggle the output named restart so that thetimer starts counting over from zero. The action “signal X/Yto the other machine” means that we use some intermediate in-put–output signal to communicate between the state machines.For example, this intermediate signal could be a toggle actionon X or Y in these state machines.

If the introduction of new intermediate signals (X and Y)for interstate machine communication is not possible, thenwe could use the existing signals CHWG and CFRG asinput–output signals to accomplish the same thing. If theCHWG and CFRG signals cannot be used as input signals forinterstate machine communication, then we need to reduce thetwo state machines into a single state machine, which avoidsthe need for interstate machine communication. Although thesestate machines can be reduced to a single state machine withfive states, this trivializes the problem to a much simplerlevel. Not all problems reduce to one state machine so easily.One of the strengths of the Shlaer–Mellor flavor of OOAis its ability to handle more complex problems by usingconcurrently running state machines that signal events to eachother as the sole means of interstate machine communication.

J. Solution via OOA and Object-Oriented Design (OOD)12

OOA and OOD attempt to describe a system from a dif-ferent perspective than the more traditional functional designmethodologies. The OO approach defines the relationshipbetween things (the objects) in the problem with objects inthe solution domain, then defines the domain of these objects[4], [15], [23], [26], [27].

An OOA often begins with recognizing the differentclassesof objects in the problem domain. Table IV describes some ofthe classes that might be found in the traffic-light problem.

These classes can be graphically related in a class diagram,as in Fig. 22. Class diagrams can showinheritance rela-tionships between classes. Inheritance allows the designer toexpress commonality between classes. For example, a lion anda tiger are related in that they are both mammals. Inheritancealso allows the designer to present information in one placeand let it be used in many other places. For example, in thedescription of the classLight, we can specify the voltage,current, luminance, and heat produced. Then lights of any colorwould inherit these properties. This figure uses the notationof Booch [4], wherein a line with an arrow represents theinheritance relationship, e.g., a Red Light inherits all theproperties defined for the class “Light,” etc. This notationrepresents ausesrelationship with a line with an open circle,e.g., the Controller uses the Timer, the Pair Router, andthe Sensor. A line with a solid circle represents thehas-a

12K. Bharathan and J. Duke.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 95

Fig. 21. State model for the highway light.

TABLE IVCLASSES IN THE SOLUTION DOMAIN

relationship, e.g., a traffic light has-a Red Light, has-a GreenLight, and has-a Yellow Light.

State diagrams are created for each of the classes, describinghow their behavior changes with different inputs. One advan-tage of this OO approach is that only one state machine isneeded for the class “Light,” since none of its descendantsbehave differently.

After the problem domain classes have been identified andtheir general behaviors have been defined, the designer canthen start describing various scenarios where specific instancesof the classes (the objects) are “created” and allowed tointeract. These interaction diagrams can feed directly into thenext stage of the iterative design process. One of the diagramsuseful for showing these scenarios is the interaction diagram.Fig. 23 contains one of those diagrams where there are notmany cars waiting at the farmroad. In these diagrams, timeflows from top to bottom. The relevant objects are lined acrossthe top of the graph. As time progresses, objects send messagesto each other, represented by horizontal lines connecting theindividual objects’ lines. The objects HW Router and FRRouter are instances of the class Pair Router.

Fig. 22. Class diagram for one solution domain.

This figure shows just two scenarios. Many more could bewritten. Scenarios could be written for anomalous conditions.For example, a scenario could be written to show what thesystem does if the “HW Lights” do not return a “Confirmed”message to the HW Router. The number of scenarios neededto completely describe a system would depend on how manyanonymous conditions were considered.

The final phase of design involves writing state transitiondiagrams for those objects that are deemed active during thelifecycle of the system.

In contrast to the other designs in this project, this OOdesign distributes the intelligence, i.e., at certain times, theserver–client relationship changes. For example, the controllersends a message to the highway router object. The router thencommands the highway lights to change to red. Only afterthis change is confirmed does the router send a signal to thefarmroad router, instructing it to send a command to changethe farmroad lights to green. Then, at the appropriate time,the farmroad router takes “control” and instructs its lights tochange to red, gets the necessary confirmation, then commandsthe highway router to change its lights.

96 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 23. Interaction diagram for a scenario.

OOD offers a great deal of scalability that can be usefulin large-scale systems design. The scalability is availablethrough the good definition of classes, allowing the designto be composed of modular, hierarchical elements that canhave a one-to-one relationship with the physical elements inthe solution domain.

K. Solution via OpEM-Directed Graph Model13

An operational evaluation modeling-(OpEM)-directed graphmodel [6]–[8] of the traffic-light problem is shown in Fig. 24.The Begin event initializes the model and the Split Action op-erator in the upper left splits it into three concurrent processes.

The top process models the interarrival time for tractorsarriving to cross the highway. When a tractor arrives, a tractorobject is created and initialized in theWait-for-Greenstate.

The middle process models the operation of the tractor. TheWait-for-Greenstate represents an indeterminate period of timewhile the tractor waits for the farmroad light to turn green.A tractor motion process in theWait-for-Greenstate modelsthe signal (TRACTOR WAITING) that occurs when a sensordetects a tractor waiting to cross the highway. The tractorcrossing state (TR Crossing) models the time required for atractor to cross the highway. The tractor clear event (TerminateTR) provides a signal that indicates that the tractor is safelyacross the highway and deletes the tractor object, terminatingthe process. A duplicate of the tractor motion process is createdeach time a tractor arrives to cross the highway and is deletedwhen crossing is complete.

The bottom process models the operation of the traffic-light system. The process is initialized in theMin HyWayGrn state, which represents the minimum highway green-

13J. R. Clymer.

time controlled by the LTI timer. The next state,Green HWWait, describes an indeterminate period of highway green timethat persists until a tractor-waiting condition occurs. If thetractor waiting condition is true when the minimum highwaygreen timeout occurs, thenYellow HighWay state occursimmediately. Thus, the end ofGreen HW Waitis activatedby condition (TRACTOR WAITING) and executes actionCHWY, which resets all CHW* flags to zero and sets CHWYto one. TheYellow HighWay state represents a STI periodwhen the highway light is yellow. When the end of theYellowHighWay state occurs, the highway traffic control processexecutes actions CFRG and CHWR. The Farm Road Greenparallel process models a time period when either the tractorclear condition or a LTI period timeout can result in the end ofthe Farm Road Green condition. The event that ends the FarmRoad Green period resets the LTI counter and executes actionCFRY. TheYellow FRstate represents a STI period when thefarmroad light is yellow. The event that ends theYellow FRstate executes actions CHWG and CFRR and returns to theGreen HighWaystate.

The logical condition for the assemble event of the topprocess, that is used to assemble the three concurrent processesand end system operation, is that the last tractor has arrivedand has crossed the highway.

1) Benefits of the OpEM Language:Complex systemscomprise a collection of processes where each processin the system communicates data, knowledge (rules andfacts), and mission goals with one or more other processes.Collaboration, where two or more processes adapt theiroperations to achieve overall system goals, is much moredifficult to achieve than coordination, where only informationis exchanged. The system design and evaluation language usedto describe system operation must be capable of describing

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 97

Fig. 24. OpEM-directed graph model.

explicitly all process interactions required for collaboration.These include synchronization, deconfliction, and resourcecontention. A system design and evaluation methodology [8]based on OpEM diagrams [6] is summarized as follows.First, design each system process to work optimally toperform and adapt its activities, given information aboutthe current situation; Second, assume unconstrained processcommunication, and apply machine learning [8] to optimizecoordination and collaboration of processes by iteratively:1) adapting process operation to achieve overall systemgoals, 2) discovering essential knowledge sharing required toachieve such collaboration, and 3) allocating system processesto subsystems and define a subsystem coordination andcommunication method to connect each subsystem effectivelyto share essential information.

2) The OpEM Systems Engineering Tool Kit:This hasbeen developed during the past ten years to implement therequired system design and evaluation methodology neededfor complex systems. This toolkit can be downloaded fromhttp://ECS.Fullerton.edu/ JClymer/. Modules in the OpEMtool kit include the following:

1) discrete event/continuous simulation that manages eventoccurrences in simulated time;

2) object movement and interaction that models the physi-cal motion of objects and their spatial relationships andstores object state information;

3) adaptive fuzzy expert system controller that provides therule-based part of decision making;

4) fuzzy rule tree induction that discovers decision-makingrules during simulation of a system;

5) an evolutionary algorithm that is designed to work withsimulation generated fitness values; and

6) a run-time user interface that displays event-state tracesand allows modification of rules and fuzzy facts whilethe simulation is running.

L. Solution via IDEF014

The termIDEF comes fromICAM (Integrated Computer-Aided Manufacturing) andDEFinition language [14], [18].The IDEF0 method was formalized by the Air-Force ICAMproject. It is based on the Structured Analysis and DesignTechnique (SADT) developed by Douglas Ross and others atSofTech in the early 1970’s [21]. An IDEF0 model consistsof a hierarchy of activities (or functions) with attending linksand constraints. In this paper, we will make no distinctionbetween an activity and a function.

Activities are bounded byInputs, Controls, Outputs, andMechanisms (referred to in aggregate as ICOM’s). ICOM’sshow the information and physical objects that link and con-strain activities. When viewed in IDEF0 diagrams, activities

14D. L. Dean.

98 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

Fig. 25. IDEF0 model.

are represented as boxes and ICOM’s are represented asarrows. Activities and ICOM’s are also textually defined ina glossary to reduce ambiguity. An input is converted by anactivity into an output. A control is a constraint that governs anactivity (e.g., policies, when to start/stop, how many, how fast,etc.). Outputs serve as inputs or controls for other activities.Mechanisms represent the physical resources (people, devices,or systems) that perform the activity. In this paper, we willmake no distinction between mechanisms and objects.

As shown in the symbol legend of Fig. 25, inputs enterthrough the left side of activities, controls enter the top, outputsexit from the right, and mechanisms enter from the bottom.This specific ICOM placement convention is very useful. Areader of a diagram knows the content of an arrow by theposition of the arrow on the activity.

The differentiation between inputs and controls is useful. Ithelps the designer and reader differentiate between controlsthat govern an activity from inputs that are changed by anactivity into outputs. The traffic-light problem is a control-centric problem by definition. Much of what is passed betweenthe activities is control information, such as messages from thecontroller to the traffic lights signaling a change of color. Incontrast, a manufacturing environment has fewer controls andmore input–output conversions. For a manufacturing model, itis also helpful to differentiate between a control on an activityand an input to the activity. The IDEF0 method allows thatdistinction to be made.

Another strength of the IDEF0 method is that it encouragesthe designer to differentiate between controls that are generated

internally and those that are externally imposed. For example,the duration of a STI and a LTI are dictated by “IntervalDuration Policy,” an externally imposed control on activityA2. This external control allows the controller to merelyrequest that the timer generate an STI or an LTI withouthaving to pass an STI or LTI interval duration parameter tothe timer. An externally imposed control on activity A3 is“Light Control Policy.” It could, for example, specify that ifthe highway green or yellow lights are on, then the farmroadred light must be on. The understanding of which controlsare externally imposed has implications for the design. Whentrying to improve an existing design, it is important to examinethe assumptions in the external controls. Sometimes changingthese assumptions will improve the design. Moreover, theexplicit statement of external controls makes it easier for thedesigner to remember that the external controls may change,suggesting the need to keep components flexible.

When the mechanisms are known a priori, as in the traffic-light problem, it is easier for the designer to conceptualizeand separate out activities that specifically correspond toeach mechanism. The designer may also benefit by deferringthe definition of mechanisms until after derivation of animplementation-independent model. This allows the designerto postpone premature involvement with issues regardingwho or what machine will perform an activity until after anunderstanding of the activity has been achieved.

Since the objective of this traffic-light problem was todesign a control system, the model could have stopped at A3,showing the outputs that control the physical traffic lights.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 99

However, the light projection activities are easily includedin the diagram so that the reader can contemplate the entiretraffic-light system.

The IDEF0 method is better than data-flow diagrams be-cause it is easier for the reader to know where to begin. Thestructure of IDEF0 diagrams shows the reader where to beginand in what order to proceed. However, IDEF0 diagrams arenot purely sequential, because concurrency is depicted.

As admitted in the introduction to this paper, small problemsdo not demonstrate the power of some modeling methods thatscale well to larger, more complex problems. Much humanfactor engineering has gone into IDEF0 to make it scalewell to larger problems. The hierarchical decomposition ofIDEF0 allows parent activities to be broken down into childdiagrams, but in a disciplined way. The numbering of theactivity boxes shows the tree structure of the decomposition.Each activity is broken down into three to six child activities.The upper limit of six is within the well-known 7-plus-or-minus-2 guideline. The lower limit is based on not having adecomposition unless there is enough information to justify anew diagram. Moreover, any side of an activity is limited to sixarrows. These limits help the analyst manage the complexity ofa problem by encouraging purposeful decomposition. Detailsof the model are pushed downward into lower levels wherethey belong. Moreover, consistent levels of abstraction tend tobe found horizontally across any level of the model hierarchy.Unlike IDEF0, some forms of structured analysis allow a largenumber of transforms or actions to happen on one diagram.This may lead to cluttered diagrams that are hard to understandand that cognitively overload the reader. Such diagrams maycontain too much content at the same level of abstraction orhold content of very different levels of abstraction. In thetraffic-light problem, as in many other machine control typeproblems, it would be appropriate to prepare a state transitiondiagram to complement the IDEF0 model.

IV. DISCUSSION

We have presented solutions for a simple design problemby using 11 different methods. Each method was used byan expert with that method. We did not create a numericalranking of the methods because we do not want our experts tofine-tune their solutions to fit our problem and metrics. Fromthe presentation of these 11 methods, we hope the reader canunderstand the methods. Then, if he or she wants to use aparticular method, appropriate references can be consulted.

A. Implementation

We stated that the systems engineer should use a high-level method for the high-level design. Then, he or she shouldwork in conjunction with the specialty design engineers toproduce the low-level or state machine implementation ofthe system. Sometimes the design changes when it goesfrom the high-level design to the low-level implementation.We created a hardware simulation of the highway–farmroadintersection in our laboratory with switches, LED’s, TTLcircuits, and a BASIC Stamp II microcontroller. Then, for threeof our designs, we implemented the high-level designs on this

hardware. For the state transition diagram solution, the design(Fig. 2) did not change when it was implemented (Fig. 3).Likewise, the design did not change for Taipale’s Ward–Mellorstyle solution. The state machine (Fig. 13) was translated intoa BASIC program and downloaded to the microcontroller.The implementation required no changes to the design. TheDuke–Bharathan OOD (Fig. 22) was implemented in C++[28] and was downloaded to the microcontroller. This designproved difficult to implement, primarily due to difficultieswith multiple active objects on the single-threaded operatingsystem resident in the Basic Stamp II microcontroller. Thedesign had to be changed significantly to accommodate thisproblem once it was presented to the specialty engineers. Thismerely confirms that the method used substantially effects theimplementation.

We have also written a model of the highway–farmroadintersection in the Java language. Then, we used Java to im-plement the state transition diagrams of Figs. 2 and 13 and thefunctional decomposition of Fig. 14. These implementationsare available at http://www.sie.arizona.edu/sysengr/methods,and they can be run as applets.

B. Characteristics of the Benchmark Problems

The traffic-light problem had a mixture of pulse outputs(Mealy machine) and level outputs (Moore machine). Thiscaused difficulty for a few of the methods. But all wereeventually able to handle this complexity. Also, all methodswere capable of either showing all possible state transitionsor only those that were expected to occur. So this did notdistinguish between our methods.

We will try to identify other characteristics of problems thatmight make one system design method more or less appro-priate. The second problem in our Methods Analysis Projectis the design of a small restaurant. It involves schedulingand performance figures of merit. But the main distinguishingcharacteristic is concurrency of processes. The chef preparesthe food, the oven bakes the food, the waiter delivers the foodand people eat the food, all at the same time. We expect tohave solutions to this problem in about one year.

C. Benchmark Problem Number 2: The Caf´e Problem

Please model the following system so that we can control it.Assume you are the new proprietor of a small cafe. Your

new cafe has five tables that can each seat four people at atime. You have a kitchen unit that has a refrigerator, a freezer,a counter to store prepared but uncooked dishes, a stove withfour grills, an oven that can hold two pans at a time, a foodwarmer to keep cooked dishes warm, and a shelf for holdingplates of food for delivery to customers. You have no morecapital, and you have no prospects to get any. So you cannotexpect to buy more kitchen units.

Since your business is new, you have decided to restrictyour menu to only two entrees and two desserts. Your firstentree, grilled chicken breast, requires 5 min of preparation,followed by 10 min on a grill. Your second entree, peppersteak, requires 10 min of preparation, followed by 5 min on agrill. Your first dessert, a chocolate souffle, requires 5 min of

100 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

preparation, followed by 15 min on a pan in the oven. Yoursecond dessert, ice cream, requires 5 min of preparation.

Each grill can hold only one entree and the chef can bepreparing only one dish at a time. Food does not need tobe prepared or cooked in the sequence the customers placedtheir orders. Desserts should be delivered at an appropriatetime. Taking orders and delivering dishes each takes 1 minper customer. Your cafe will need to receive orders fromcustomers, prepare and cook the ordered food, deliver the foodfrom the kitchen to the customers, and receive payment fromthe customers.

We will use performance figures of merit, such as through-put (in customers/h), difference in delivery time between thefirst and last entree at each table, difference in delivery timebetween the first and last dessert at each table, number of timesthe chef is interrupted while preparing a dish, the time eachdish has spent waiting to be cooked, the time each dish hasspent waiting to be served, the number of ice cream dishesthat melt before being delivered, and profit.

We would also like you to validate your model.Our project involves at least three benchmark problems: the

traffic-light problem, the cafe problem and the third problem.Eleven experts using 11 different methods have already solvedthe traffic-light problem and those solutions are in this paper.The cafe problem has been formulated, and we have three trialsolutions. But none of our experts have solved this problemyet. The third problem has not been formulated yet.

D. Other Potential Metrics for Comparing the Methods

A metric that we considered for evaluating our methodswas handoff-ability. The system designer produces a top-level design for the system. This design must then be givento specialty engineers for implementation. If the specialtyengineers are not familiar with the method used by the systemdesigner, then it will be difficult to handoff the design. Thismetric was hard to evaluate because it depends as much onthe company’s organization and the training of their engineersas it does on the method itself.

Another metric we have considered is complexity. Thenumber of inputs, outputs, states, and interface connectionscould quantify this. But of course this is circular reasoningbecause the numbers of inputs, outputs, states, and interfaceswill depend on which design and implementation methods areused.

Condensability means the model can be simplified forcertain presentations. This could be accomplished by orga-nizing the elements into hierarchies, wherein elements ata particular level could be condensed into one block andlater expanded. This is the organizational style for RDD-100,model-based systems engineering, functional decomposition,and IDEF0 solutions. However, state transition diagrams andASM solutions are almost never decomposed into hierarchies.Reducing the number of transitions shown could also simplifypresentations, for example, by not showing all possible statetransitions, but only those that were expected to occur. Mostmethods have provision for showing only expected inputs.Finally, ASM charts introduced the concept of not showingall outputs, but showing only those that are turned on.

We have also considered the following metrics for the meth-ods: simplicity, ease of design alteration, learning effort, im-plementability, design changes necessary for implementation,comprehensiveness, size of the documentation, transparency,understandability, communicability, scalability between smalland large problems, and ease of handling concurrent processes.

E. Shortcomings

This project has many shortcomings. We would like toadd more tools and methods to this project, such as CORE,colored Petri nets, Slate, fuzzy-neural systems, SilverRun, theObjectory, VHDL, and Sim Factory. But so far we do nothave expert authors.

The first and foremost tasks of systems engineers arestating the problem and discovering the requirements [2]. Forthis traffic-light problem, we did not give our authors anopportunity to do this. We forced them to solve a very tightlyconstrained problem. We asked them to design a controller forthe traffic-light system. We did not allow them to consider theproblem of getting the farmer across the road, which might besolved better with a bridge.

However, it is interesting to note the variability in these so-lutions. All the authors were given the same written statementof the problem (Section II) and the same two-page constraint.But some of the solutions are detailed, whereas others areabstract. Indeed, some are not solutions at all, but are meremodels of the problem space. Perhaps this indicates that notonly does the choice of the method effect the solution, butalso the choice of the designer.

In future work, we will have a specific battery of ques-tions that each author will have to address after his or herdesign has been completed. Candidate questions include thefollowing: how did you define the system boundaries? Whatwere the inputs, outputs, functions, and states? How werethey modeled? How was the physical system modeled anddecomposed? Did the method identify missing requirements?Was discovery of these missing requirements a result of themethod or the experience of the engineer? How did the methodaddress certain specific issues, such as pulse versus leveloutputs, concurrent versus serial processing, and distributedversus centralized control?

F. Commonalties of the Methods

For most of these methods, we think that the best way todescribe what the system is supposed to do is to help thecustomer construct sequences of events that describe desiredand acceptable input–output behavior. This paper has showntwo examples in Table III and Fig. 23. Such descriptions of be-havior as a function of time are called trajectories, behavioralscenarios, use cases, threads, operational scenarios, logistics,functional-flow block diagrams, or interaction diagrams. Aftermany such behavioral scenarios have been collected, thedesigners can define the control inputs, data inputs, outputs,objects, functions, and states.

Most of these methods differentiate between control anddata inputs. The problem statement specified the followingfour control inputs: Initialize, Sensor, STI, and LTI. Varioussolutions have used the following data (or material) inputs:tractor, electric power, heat,and repair parts.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 101

Fig. 26. N -squared diagram for the traffic-light problem.

Fig. 27. Segment of a functional block diagram.

Most of these methods used objects, states, and functions.Objects are usually named with adjectives and nouns, e.g.,Red Light. States should be named with historical statements,such asHW Light Green, Then Sen Received, Now Waiting forLTI. And functions are usually named with verb phrases, e.g.,DetectTractor. In this paper, the functions were sometimescalled processes or activities.

OO methods concentrate on objects and seem to ignorefunctions and states. But although they do not emphasizefunctions and states, they do consider them. For example theobjectSensor(Fig. 22) has the functionDetectTractor(whichwould be described in the documentation), and the objectFarmroad Light (Fig. 19) has the statesFarmroad_Light_R,Farmroad_Light_G, andFarmroad_Light_Y(Fig. 20).

In contrast, state transition diagrams focus on states andseem to ignore functions and objects. However, they arethere. While in the stateHighway-green(Fig. 2), the functionsCommand Highway Green Light OnandCommand FarmroadRed Light Onare preformed. The system objects could beshown in an -squared diagram, as in Fig. 26.

-squared ( ) diagrams are often used to evaluate inter-faces between subsystems. Sometimes, instead of using arrowsto show interfaces, an X is merely placed in the box to indicatean interface between the subsystems in that row and column.

The functional decomposition method focuses on the func-tions. In Fig. 27, the functions (verb phrases) are inside theboxes. But these functions have inputs and outputs that areobjects (nouns). However, this method seems to ignore thestates.

The IDEF0 diagram of Fig. 25 explicitly shows the objects(called mechanisms), such asRoad Sensorand Timer. Italso explicitly shows the functions (called activities), such asMonitor Farm Road Trafficand Count Down Time Intervals.However, it seems to ignore the states.

Structured analysis uses a different method to focus on eachof these three aspects. It uses entity relationship diagramsto focus on the objects, data-flow diagrams to focus on thefunctions, and state transition diagrams to focus on the states.

So which of these methods is the best? It depends onthe problem. For modeling existing physical systems (likethe patient referral system in a hospital), Bharathan andBahill have found OO methods to be best. They found thatnonengineers, like physicians and nurses, relate to objectsmore readily than to functions. Physicians and nurses canvisualize objects likenurse, managing physician, andpatientrecord easier than they can functions likeobtain committeeapproval or request referral. In this case, it seems that thehuman mind relates to objects better than functions. Similarly,archeologists studying Stonehenge and Machu Pichu easilydescribe the objects, but have difficulty defining the functions.

In summary, some system design methods focus on objects,some on functions, and some on states. However, no matterwhich method is used, in order to communicate your design,all of the objects, functions, and states must eventually beidentified.

ACKNOWLEDGMENT

The authors thank F. Dean for his support, B. Bentz forhelp with the manuscript, and the anonymous reviewers forinsightful comments.

REFERENCES

[1] A. T. Bahill et al., “The systems engineering design tools analysisproject,” in Proc. 1996 IEEE Syst. Man, Cybern. Conf.,Beijing, China,Oct. 14–17, pp. 2370–2385 and 2392–2393.

[2] A. T. Bahill, B. Bentz, and F. F. Dean,Discovering SystemRequirements. Sandia Nat. Lab., Albuquerque, NM, SAND96-1620 UC-706, 1996. This paper is also available at http://www.sie.arizona.edu/sysengr/requirements.

[3] N. C. C. Blackwell, Structured Systems Analysis and Design Method(SSADM) Specification.1990.

[4] G. Booch,Object-Oriented Analysis and Design.Redwood City, CA:Benjamin Cummings, 1994.

[5] W. L. Chapman, A. T. Bahill, and A. W. Wymore,EngineeringModeling and Design. Boca Raton, FL: CRC, 1993.

[6] J. R. Clymer, P. D. Corey, and N. Nili, “Operational evaluationmodeling,” in Simulation, San Diego, CA: Soc. Comput. SimulationInt., 1990, pp. 261–270.

[7] J. R. Clymer, “Role of reductionism and expansionism in system designand evaluation,” inProc. 4th Ann. Int. Symp., Nat. Council Syst. Eng.,San Jose, CA, Aug. 10–12, 1994, pp. 323–332.

[8] , “Expansionist/context sensitive methodology: Engineering ofcomplex adaptive systems,”IEEE Trans. Aerosp. Electron. Syst.,vol.33, Apr. 1997.

[9] T. DeMarco,Structured Analysis and System Specification.New York:Yourdon, 1979.

[10] E. W. Dijkstra, “Structured programming,”Classics in Software Engi-neering,E. N. Yourdon, Ed. New York: Yourdon, 1979, pp. 43–48.

[11] P. A. Fishwick,Simulation Model Design and Extraction.EnglewoodCliffs, NJ: Prentice-Hall, 1995.

[12] B. Fox and M. Ringer, “Planning and scheduling benchmarks,”http://www.neosoft.com/�benchmrx/default.html, Nov. 1996.

[13] D. Green, Modern Logic Design. Reading, MA: Addison-Wesley,1986.

[14] Integration Definition for Function Modeling (IDEF0),Comput. Syst.Lab., Nat. Inst. Standards Technol., Fed. Inform. Processing StandardsPub. 183, 1993.

[15] I. Jacobson, M. Ericsson, and A. Jacobson,The Object Advantage:Business Process Reengineering with Object Technology.New York:Addison-Wesley, 1995.

[16] R. H. Katz, Contemporary Logic Design.Redwood City, CA: Ben-jamin Cummings, 1994.

102 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998

[17] E. V. LaBudde, “Graphical description languageTM a solution forthe system-software interface problem,” inProc. 6th Ann. Int. Symp.INCOSE,Boston, MA, July 7–11, 1996, pp. 673–678.

[18] D. A. Marca and C. L. McGowan,IDEF0/SADT: Business Process andEnterprise Modeling. San Diego, CA: Eclectic, 1993.

[19] C. Mead and L. Conway,Introduction to VLSI Systems.Reading, MA:Addison-Wesley, 1980.

[20] J. A. Moody, W. L. Chapman, F. D. Van Voorhees, and A. T. Bahill,Metrics and Case Studies for Evaluating Engineering Designs.Engle-wood Cliffs, NJ: Prentice-Hall, 1997.

[21] D. T. Ross, “Douglas Ross talks about structured analysis,”IEEE Trans.Comput.,vol. C-18, pp. 80–88, July 1985.

[22] D. T. Ross, J. B. Goodenough, and C. A. Irvine, “Software engineering:Process, principles, and goals,”IEEE Trans. Comput.,vol. C-8, pp.17–27, May 1975.

[23] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Loren-son, Object-Oriented Modeling and Design.Englewood Cliffs, NJ:Prentice-Hall, 1991.

[24] M. Shaw, “Comparing architectural design styles,”IEEE Trans. Softw.Eng., pp. 27–41, Nov. 1995.

[25] , “Model problems in software architecture,” http://www.cs.cmu.edu/�Compose/html/ModProb/index.html, Nov. 1996.

[26] S. Shlaer and S. Mellor,Object-Oriented Systems Analysis: Modelingthe World in Data. Englewood Cliffs, NJ: Prentice-Hall, 1988.

[27] , Object Lifecycles: Modeling the World in States.EnglewoodCliffs, NJ: Prentice-Hall, 1992.

[28] B. Stroustrup,The C++ Programming Language,2nd ed. New York:Addison-Wesley, 1993.

[29] A. Turing, “On computable numbers with an application to theEntscheidungsproblem,” inProc. Lond. Math. Soc.,vol. XLII, 1936,pp. 239–265, with a correction inibid., vol. XLIII, 1937, pp.544–546.

[30] P. T. Ward and S. J. Mellor,Structured Development for Real-TimeSystems,vols. 1–3. New York: Yourdon, 1985.

[31] A. W. Wymore,Model-Based Systems Engineering.Boca Raton, FL:CRC, 1993.

[32] , System Functional Analysis.Boca Raton, FL: CRC, 1998.

A. Terry Bahill (S’66–M’68–SM’81–F’92) received the B.S.E.E. degree fromthe University of Arizona, Tucson, in 1967, the M.S.E.E. degree from SanJose State University, San Jose, CA, in 1970, and the Ph.D. degree in electricalengineering and computer science from the University of California, Berkeley,in 1975.

He has been a Professor of Systems Engineering at the University ofArizona since 1984. In the last few years, he has spent 20 months workingat Hughes Missile Systems, Tucson, AZ, Sandia National Laboratories,Albuquerque, NM, Lockheed Martin Tactical Defense Systems, Eagan, MN,Boeing Information, Space and Defense Systems, Kent, WA, and IdahoNational Engineering and Environmental Laboratory, Idaho Falls. He haspresented seminars on Systems Engineering and has helped each companydescribe its systems engineering process. He is the author ofBioengineer-ing: Biomedical, Medical, and Clinical Engineering(Englewood Cliffs, NJ:Prentice-Hall, 1981),Keep Your Eye on the Ball: The Science and Folkloreof Baseball, with R. G. Watts (San Francisco, CA: Freeman, 1990),Verifyingand Validating Personal Computer-Based Expert Systems(Englewood Cliffs,NJ: Prentice-Hall, 1991),Linear Systems Theory, with F. Szidarovszky (BocaRaton, FL: CRC, 1992),Engineering Modeling and Design, with W. L.Chapman and A. W. Wymore, (Boca Raton, FL: CRC, 1992), andMetricsand Case Studies for Evaluating Engineering Designs, with J. A. Moody, W.L. Chapman, and D. F. Van Voorhees, (Englewood Cliffs, NJ: Prentice-Hall,1997). His research interests are in the fields of systems engineering, modelingphysiological systems, eye–hand–head coordination, validation of knowledge-based systems, quality improvement, business process redesign, and systemsdesign. He has tried to make the public appreciate engineering research byapplying his scientific findings to the sport of baseball.

Dr. Bahill has served as Vice-President of the IEEE Systems, Man, andCybernetics Society as well as Associate Editor, as Program Chairman forthe 1985 conference in Tucson, and as Conference Co-Chairman for the 1988conference in Beijing and Shenyang, China. He served as an Associate Editorfor the IEEE Computer Society’s magazine,IEEE Expert. He holds UnitedStates Patent 5 118 102 for the Bat Chooser, a system that computes the IdealBat Weight for individual batters. He is a Registered Professional Engineerand the Editor of the CRC Press Series on Systems Engineering.

Mack Alford received the B.A. degree with honors in mathematics in 1962and the M.A. degree in mathematics and statistics, both from the Universityof California at Los Angeles (UCLA), in 1966. He performed graduate workat UCLA in computer science as a TRW Fellow from 1969 to 1974.

He is now an independent consultant. He spent 25 years with TRW andwas the founding technologist for Ascent Logic Corp., San Jose, CA, whichbuilds the RDD-100 System Designer.

K. Bharathan (M’93) was born in Madras, India, on January 22, 1951.He received the B.A. degree with honors in economics from the Universityof Delhi, New Delhi, India, in 1973, the M.A. degree in economics fromJawaharlal Nehru University, New Delhi, India, in 1975, the M.Phil. degreein economics from the University of Madras, Madras, India, in 1979, thePh.D. degree in economics from the University of Madras in 1990, and theM.S. degree in systems engineering from the University of Arizona, Tucson,in 1991.

He is a Research Assistant Professor of Surgery at the University of ArizonaMedical Center. He was a Systems Engineer at Bahill Intelligent ComputerSystems in Tucson, AZ, from 1992 to 1996. He was on the faculty of theMadras Institute of Development Studies until 1988, and prior to that, he wason the faculty of the Madras Christian College, Madras, India, from 1976through 1978. His research interests include systems engineering theory, thedesign, verification, and validation of expert systems, the knowledge extractionprocess, and object-oriented systems engineering.

Dr. Bharathan is a member of the IEEE Computer Society, the IEEE Sys-tems, Man, and Cybernetics Society, and the American Medical InformaticsAssociation.

John R. Clymer (M’68) is a Professor of Electrical Engineering at CaliforniaState University at Fullerton (CSUF), Placentia, and consults in the area ofsystems engineering by using simulation and artificial intelligence. In additionto consulting, he presents intensive short courses on systems engineering andsimulation at various locations around the United States and Taiwan. His re-search interest currently is intelligent, complex adaptive system architectures,such as multiagent systems. Topics include simulation, adaptive-fuzzy expertsystem controller, machine learning, evolutionary programming, and generalproblem solvers and planners.

Dr. Clymer is a founding member of the Applied Research Center forSystems Science (ARCSS) at CSUF and is a member of SCS and INCOSE.

Douglas L. Dean(M’97) received the M. A. degree in information systemconsulting from Brigham Young University, Provo, UT, in 1989 and the Ph.D.degree in management information systems from the University of Arizona,Tucson, in 1995.

He is a Research Scientist at the Center for Management Information,University of Arizona. He provides consulting and research services on anumber of topics, including electronic meeting systems (EMS), collaborativebusiness process reengineering methods, and collaborative systems analysisand design methods. He has helped develop group-enabled activity anddata modeling software to support technical and nontechnical users. He alsodeveloped structured meeting methods for use with these tools. The activitymodel software has since been made commercially available through VentanaCorporation, Tucson. His research interests include electronic meeting supportof process and data modeling, business process reengineering, systems analysisand design, and group elicitation of information systems requirements.

Jeremy Duke received the B.S. degree in systems (software) engineering in1994 and the M.S. degree in systems engineering in 1996, both from theUniversity of Arizona, Tucson.

He is currently working as a Project Leader and Software Engineer atIntel Corporation, Chandler, AZ, writing requirements for designing andimplementing real-time, mission critical station controllers in the Assem-bly/Test area of manufacturing. His current interests are in software testingand requirements validation techniques.

BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT 103

Greg Hill (M’80) received the B.S. degree in nuclear engineering in 1976and the M.S. degree in computer science in 1978, both from the Universityof Arizona, Tucson.

Since 1978, he has been an Advisory Engineer at the IBM TucsonLaboratory. At IBM, he has held a variety of technical assignments in theplanning, analysis, design, and implementation of software tools, microcodedevelopment and analysis tools, and project management tools. His latestassignments were in the development of tape device microcode and storagecontrol unit microcode.

Mr. Hill is a member of the ACM and the IEEE Computer Society.

Edward V. LaBudde (M’82) received the B.S.E.E. degree from MichiganState University, East Lansing, in 1968 and the M.B.A. degree from AlabamaA&M University, Normal, in 1978.

He has more than 30 years of experience in advanced development andhas extensive experience in entrepreneurial leadership roles for product andorganizational development projects. He holds more than 30 patents and haspublished numerous papers on various engineering topics.

Mr. LaBudde is a member of INCOSE and SPIE.

Eric J. Taipale (S’93–M’97) received the B.E.E. degree from the Universityof Minnesota, Minneapolis–St. Paul, in 1994 and the M.S. degree in systemsengineering from the University of Arizona, Tucson, in 1996.

He is currently a Staff Engineer in the Advanced Programs group atLockheed Martin Tactical Defense Systems, Eagan, MN. His current interestsare automated signal feature extraction and target classification systems.

A. Wayne Wymore received the B.S. and M.S. degrees from Iowa StateUniversity, Ames, and the Ph.D. degree from the University of Wisconsin,Madison, all in mathematics.

He is Professor Emeritus of Systems Engineering, University of Arizona,Tucson, where he was the first Chairman of the Department of SystemsEngineering and the first Director of the Computing Center. While man-aging, teaching, researching, and consulting internationally, he authoredAMathematical Theory of Systems Engineering: The Elements, 1967, SystemsEngineering Methodology for Interdisciplinary Teams, 1976, andModel-BasedSystems Engineering, 1993. System Functional Analysis and System Design,Phase 2 of model-based systems engineering is forthcoming.