©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 Project A. 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 method must be chosen. This choice is usually dictated by what methods the designer has previously used, not by an open selection process. In this paper, we provide descriptions of some available design methods and examples of their use. In this project, we will develop benchmark problems that will be solved by a variety of design methods and will identify characteristics of problems that might make one system design method more or less appropriate. The top-level question we wish to answer is “for which type of problem is each method best?” If a system is to be built, then the system must ultimately be described as a collection of state machines. However, these state machines are often not created by the systems engineers. The systems engineers use some method to create a high-level abstraction of the desired system. Then they turn this abstraction over to the specialty engineers who actually reduce it to a collection of state machines. In this paper, we present solutions for a simple design problem by using the following 11 high-level system design methods: state transition diagrams, algorithmic state machine (ASM) notation, model-based system engineering, Graphical Description Language, RDD-100, structured analysis (using entity relationship diagrams, data-flow diagrams, and state transition diagrams with Ward–Mellor notation), functional decomposition, object-oriented analysis (OOA) with Shlaer–Mellor notation, OOA and object-oriented design (OOD) with Booch notation, an operational evaluation modeling-(OpEM)-directed graph, and IDEF0. Each method was used by an expert user of that method. The solutions presented make it obvious that the choice of a design method greatly effects the resulting system design. Index Terms—Architecture, design methodology, logic design, object-oriented methods. Manuscript received September 9, 1996; revised May 1, 1997. An earlier version of this paper was published in Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, Beijing, China, Oct. 14–17, 1996 [1]. A. T. Bahill is with Systems and Industrial Engineering, University of Arizona, Tucson, AZ 85721-0020 USA (e-mail:
[email protected]). M. Alford is an independent consultant, Fayetteville, TN 37334-6029 USA (e-mail:
[email protected]). K. Bharathan is with the Department of Surgery, University of Arizona, Tucson, AZ 85721 USA (e-mail:
[email protected]). J. R. Clymer is with California State University at Fullerton, Placentia, CA 92670 USA (e-mail:
[email protected]). D. L. Dean is with the Center for the Management of Information, University of Arizona, Tucson, AZ 85721 USA (e-mail:
[email protected]). J. Duke is with Intel, Chandler, AZ 85226 USA (e-mail:
[email protected]). G. Hill is with IBM Corporation, Tucson, AZ 85744 USA (e-mail:
[email protected]). E. V. LaBudde is with LaBudde Systems, Inc., Westlake Village, CA 91362 USA (e-mail:
[email protected]). E. J. Taipale is with Lockheed Martin Tactical Defense Systems, Eagan, MN 55121 USA (e-mail:
[email protected]). A. W. Wymore is with SANDS, Tucson, AZ 85718 USA (e-mail:
[email protected]). Publisher Item Identifier S 1094-6977(98)01529-6.
I. INTRODUCTION
E
ARLY in the design process, engineers must choose a method for designing the system. This choice is usually dictated by the methods that the systems engineer’s boss has previously used, not by an open selection process. In this paper, we provide descriptions of available design methods and examples of their use in order to help systems engineers select an appropriate design method. In engineering, the two general types of systems are called static and dynamic. To a first approximation, a small bridge is described with methods of statics, whereas a pendulum is described with methods of dynamics. A typical equation of statics is which expresses the concept that a moment is equal to the force times the moment arm. Whereas, dynamic systems are typically described with state equations like these and
But, of course, the distinction between static and dynamic systems is artificial, being created for heuristic purposes. We study statics 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 systems are called combinatorial and sequential, respectively. Static systems are synonymous with combinatorial systems, and dynamic systems are synonymous with sequential systems. For combinatorial systems, the output depends only on the present inputs, whereas for sequential systems, the output depends on the present inputs and the state of the system. The state of the system depends upon the starting state and the history of the inputs. But, once again, the distinction between combinatorial and sequential logic systems is artificial. We study combinatorial systems first and then use this knowledge to study sequential systems. Therefore, we can consider combinatorial systems to be a subset of sequential systems. So, without loss of 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 logic problems could be solved with a Turing machine (a state machine). Therefore all buildable systems are state machines. So, for the last six decades, system designers have focused their attention on designing state machines. But designing state machines for big, complex systems can be difficult. So,
1094–6977/98$10.00 1998 IEEE
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
engineers and computer scientists have invented methods to help design state machines. This paper compares and contrasts many of these methods. If a system is to be actually built, then the system must ultimately be described as a collection of state machines. However, these state machines are often not created by the systems engineers. The systems engineers use some method (or tool) 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 collection of state machines. In this paper, most of our authors stopped with the high-level abstraction. Two approaches have been taken for describing system designs: 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 a variety of methods will be used to solve several benchmark problems. Therefore, a big part of the project is developing these benchmark problems. Examples of benchmark problems are on the World Wide Web [12], [25]. The top-level question we wish to answer is “for which type of problem is each method best?” This paper presents the beginning of a long project. We intend to enlarge the project by including more methods and more complex problems. Note that the problem presented in this paper does not do justice to big tools like RDD-100, the Graphical Description Language [17], and object-oriented design, all of which were created for large, complex systems. It will seem as if these tools are cracking a walnut with a sledgehammer. In this paper we present one problem. Then, our 11 authors use 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 material inputs are transformed into outputs by functions. For example, burning paper transforms it into ash. Functions are usually named with verb phrases. Functions are called processes by some methods and activities by others. The state of the system captures the history of the system. The present state and the sequence of future inputs allow computation of future states of the system. States should be named with historical statements. States are called modes with some methods. Control inputs turn functions on and off and trigger transitions between states. Objects are people, places, things, or transactions that share common attributes and perform common functions. Objects are usually named with adjectives and nouns. Objects are called entities with some methods and mechanisms with others. II. STATEMENT OF THE TRAFFIC-LIGHT PROBLEM There is an intersection between a seldom-used farmroad and a busy highway. A farmer has difficulty getting across the highway, so we are to install a traffic-light system, as illustrated in Fig. 1. Design a controller for this traffic-light system. Normally, the highway light shall be green and the farmroad light shall be red. When a sensor signals that a tractor is on
81
Fig. 1. The farmroad–highway intersection. TABLE I CONVENIENT ABBREVIATIONS
the farmroad, the highway light shall change to yellow. After a short-time interval (STI, nominally 10 s), the highway light shall change to red and the farmroad light shall change to green. The farmroad light shall stay green until the tractor clears the sensor or after a long-time interval (LTI, nominally 50 s), whichever comes first. Then the farmroad light shall become yellow. After an STI, the farmroad light shall become red and the highway light shall become green. The system shall stay in that state for a least an LTI. After an LTI, the highway light shall be switched when the sensor detects a tractor. A timer that produces output signals after STI’s and LTI’s will be available. It can be restarted at anytime. Table I suggests some abbreviations. This problem is based on Mead and Conway [9] and Katz [6].
82
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
state table shown in Table II. Each row of the table contains a transition from one state to another. Therefore, there will be one row in the table for each arrow in the diagram: except arrows labeled with Boolean OR functions require two rows. Now we can write the Boolean equations for the flip-flop inputs and for the outputs we are controlling.
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 the farmroad red lights to be on. 2) Highway-yellow commands the highway yellow and the farmroad red lights to be on. 3) Farmroad-green commands the farmroad green and the highway red lights to be on. 4) Farmroad-yellow commands the farmroad yellow and the highway red lights to be on. This Finite State Machine solution begins with a state transition diagram where each oval represents a state. The name of the state is in the top of the oval and the values of the outputs are in the bottom. For the state transition diagram of Fig. 2, the six output numbers represent the values for CHWG, CHWY, CHWR, CFRG, CFRY, and CFRR, respectively. All possible state transitions are not shown: only those that are expected to occur are shown. A bar on top of an input abbreviation symbolizes negation. A dot ( ) represents the Boolean AND function, and a plus sign ( ) represents the Boolean OR function. Typical state machines have either level outputs or pulse outputs. This state machine is unusual because it has both. When the system is in the state Highway-green, the output command highway green light on and the output command farmroad red light on are both one (on). The other light commands are zero (off). These are level outputs; these outputs are associated with the states. State machines with level outputs are sometimes called Moore machines. The output reset and start the timer is a pulse output; it is associated with the transitions between states. It is only valid for a short time, a pulse. State machines with pulse outputs are sometimes called Mealy machines [16]. We will now show two more views of this finite statemachine traffic-light controller. Use of these extra views enhances the probability of completeness, aids creation of a detailed design by specialty engineers, and provides a way to validate the design. We wish to implement and validate the controller with TTL circuitry and two JK flip-flops, which will be named A and B. First, we transform the state transition diagram into the 1 A.
T. Bahill.
Now that we have built a circuit, we can validate it. We do this by applying a multitude of input trajectories and looking to 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 circuit performs correctly. After the technology was selected, this design was passed off to the specialty design engineers. They implemented the state transition diagram of Fig. 2 with the hardware shown in Fig. 3. In doing so, they did not change the design, but they did require a clarification of whether the timer produced level or pulse outputs. Mixing of pulse and level outputs also caused some complication. The strong point of state transition diagrams is that they conveniently show the inputs, outputs, and states in a manner that is well suited for human visualization. They can be built incrementally by using input–output trajectories, as shown in Table III. B. Solution via Algorithmic State Machine (ASM) Notation2 ASM notation builds on the foundation of state transition diagrams by providing a means to express the state trajectory as a conditional flow [13]. This is accomplished by incorporating conditions, or decision points, and distinct output points within the ASM charts. ASM charts are composed of multiple ASM blocks, each block with exactly one state, at least one output, and exit conditions. ASM blocks have a single entry point, but can have multiple exit paths. There is an unambiguous exit path (state transition arrow) for each combination of inputs. Fig. 4 shows an example ASM block. Outputs are listed in the state box or inside the ovals, depending on whether they are associated with the state or with the transition between states. The specified exit condition is checked on each clock cycle 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 be asserted high in the given state or transition. For example, 2 This
section is based on ch. 8 of Katz [16].
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
NOTE: dc STANDS FOR DON’T ARE ONE OR ZERO BECAUSE
83
TABLE II STATE TRANSITION TABLE. CARE. IT MAKES NO DIFFERENCE WHETHER THESE ENTRIES THEY WOULD NOT EFFECT A CHANGE OF STATE OR OUTPUT
Fig. 3. Implementation of the finite state machine.
in the state Highway-green, the outputs CHWG and CFRR are asserted high, meaning these lights are turned on. The unmentioned outputs are, by implication, not asserted, meaning they are low or off. The Boolean function of LTI AND Sen is continually checked. If it is logic zero, then the machine stays in state Highway-green. If it is logic one, then the machine goes to the state Highway-yellow and the output Restart is asserted high during this transition. This solution is very similar to the previous state transition diagram. However, ASM charts have some advantages over state transition diagrams. ASM charts concentrate on the paths and conditions for exiting a state. These exit conditions can be built up incrementally and later combined into a single Boolean condition. It is easy to understand the resulting design as an algorithm. ASM charts also partition the algorithms into fundamental building blocks, defining interfaces between these blocks. This partitioning makes it easier to design more
Fig. 4. ASM block.
complex systems. This method transitions easily into Hardware Description Languages, such as VHDL, that are used to design computers [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 */ 3 A.
T. Bahill.
84
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
TABLE III SAMPLE INPUT–OUTPUT TRAJECTORIES
SZ
Highway-green, Highway-yellow, Farmroad-green, Farmroad-yellow , /* Listing of the four input ports and their legal values */ IZ I1Z I2Z I3Z I4Z, where I1Z(Initialize) , /*The legal values for this port are 0 and 1. A 1 on this port will put the controller in the initial state.*/ I2Z(Sen) , /*A 1 at this port means that the sensor has detected a vehicle on the farmroad */ I3Z(STI) , /*A 1 at this port means that the STI has expired */ I4Z(LTI) , /*A 1 at this port means that the LTI has expired */ /* Listing of the seven output ports and their legal values */ OZ O1Z O2Z O3Z O4Z O5Z O6Z O7Z, where O1Z(CHWG) On, Off , /* Command highway green light on or off */ On, Off , /* Command highway O2Z(CHWY) yellow light on or off */ O3Z(CHWR) On, Off , /* Command highway red light on or off */ On, Off , /* Command farmroad O4Z(CFRG) green light on or off */
O5Z(CFRY)
On, Off , /* Command farmroad yellow light on or off */ O6Z(CFRR) On, Off , /* Command farmroad red light on or off */ O7Z(Restart) , /* Reset and start the timer */ /*The next state function lists the transitions between states. Each entry shows [a present state, (an input combination)] 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 outputs that are appropriate for each */ [Highway-green, (CHWG, CFRR, Restart)], RZ [Highway-yellow, (CHWY, CFRR, Restart)], [Farmroad-green, (CHWR, CFRG, Restart)], [Farmroad-yellow, (CHWR, CFRY, Restart)] . This design might fail depending on whether the timer is triggered on the leading or trailing edge. This implementation has difficulty handling both level outputs (Moore machines) and pulse outputs (Mealy machines). In this example, the
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
85
OZ
Fig. 5. ASM chart for the traffic-light problem.
light commands (e.g., CHWG) are level outputs, whereas the Restart signal is a pulse output, but the notation does not distinguish between them. Some advantages of this notation are that 1) it works for problems with a large number of states, 2) its designs can be implemented with a very simple text processor, a typewriter or even HTML, and 3) it is mathematically rigorous, so its designs 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 system restarts the clock to ensure that the highway green light is on at least for the long time interval, then transitions to the state Highway-green-wait to wait for the long time interval to elapse, then transforms to the state Highway-green, which means that the green highway light has been on for the LTI and the system can now respond to a tractor input, Sen 1. */ /*Listing of the four input ports and their legal 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 detected 1 at I3Z means a STI has expired; 1 at I4Z means a LTI has expired. */ /* Listing of the seven output ports and their legal values */ 4 A.
W. Wymore.
O1Z O2Z O3Z O4Z O5Z O6Z O7Z, where OkZ 0,1 for every k IJS[1, 7], /* Outputs from O1Z are commands to the highway green light, 1 means on, Outputs from O2Z are commands to the highway yellow light, 1 means on, Outputs from O3Z are commands to the highway red light, 1 means on, Outputs from O4Z are commands to the farmroad green light, 1 means on, Outputs from O5Z are commands to the farmroad yellow light, 1 means on, Outputs from O6Z are commands to the farmroad red light, 1 means on, Outputs from O7Z are commands to the timer, 1 means reset 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 yellow lights are on the highway red light should be on. These conditions will be reflected in the definition of RZ below. */ /* The next state function lists the transitions between states. In this function, represents a particular value for one of the input ports and represents a particular value for the state. Thus, the fourth next state entry in the following table can be read as ”The next state is Highway-green,” if (the present state) is Highway-green-wait AND LTI(p) (the present value of LTI ) 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 AND Sen(p) 1; Farmroad-green-transition if x Farmroad-green AND LTI(p) 1 OR Sen(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-yellow AND STI(p) 0; Farmroad-yellow-transition if x Farmroad-yellow AND STI(p) 1; Highway-green-wait if x Farmroad-yellow -transition. /* Thereadout function RZ is a set of pairs of the form: [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 notation [31] handles the so-called “pulse” output simply by
inserting a “transition” state, during which the “pulse” output is generated. This way, the advantages of the Moore machine can be enjoyed (Moore machines are absolutely essential for a useful theory of system coupling) and the fiction of the egregious, gratuitous “pulse” output is properly represented. With the model-based systems engineering notation, systems with a large number, even an infinite number, of states can be defined and manipulated efficiently [5], [31], [32]. E. Solution via Graphical Description Language
5, 6
1) Basic Concepts of the Method: The method uses five orthogonal graphical views of the system design [17]. Block Diagram View (Fig. 6): This is a modification of a popular concept that relates inputs, outputs, and transfer functions. Two special additions are included. First, all changes in functional behavior that are logic-dependent must be shown with the use of a switch; the switch must show how functionality is changed. Second, it is assumed that all control logic elements are separated from the process functions and
TM
5 Graphical Description Language LaBudde Systems, Inc. 6 E.
V. LaBudde.
and GDL
TM
are trademarks of
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 controller executes the logic operations that change functionality. Mode Matrix View (Fig. 7): The mode matrix view requires that every valid combination of switch settings be given a name and called a mode. Both lock step and concurrent (parallel) modes are represented this way. The switch setting for every mode must be contained in the matrix. State Diagram View (Fig. 7): The state diagram view requires a bubble for every mode (state) in the mode matrix table. In this paper, we will make no distinction between a mode and a state. A transition arrow for each possible transition between states is also required. Each transition arrow is labeled with the control conditions that must be true to enable that transition. Timeline View (Fig. 7): The timeline view shows the events that trigger changes in modes. Each event is a transition arrow in the state diagram. The timeline must show which mode occurs after the event and any responses that the system generates. The timeline denotes the required sequence of events or inputs–outputs and any time requirements between objects in the diagram. For every path through the state diagram, a timeline exists. Performance View (not shown in any figure): Performance 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 performance requirements. Performance requirements are usually derived by the use of math models. The math model is visualized with a performance tree. The performance tree displays how requirements are either decomposed into lower requirements (flow down) or how lower level requirements roll up to higher level requirements (flow up). Performance trees show how the requirements are decomposed into parameters that are displayed in the other views. 2) Physical Decomposition: These five views are used in all levels of the system hierarchy. In the Mission Level (Fig. 8), the mission phases and scenarios are used to define user and system interfaces. The System Level shows all the interactions between elements used to create a system. The Element Level shows all the interactions between the subsystems used to create an element. The Subsystem Level shows all the interactions between functions used to create a subsystem. The Function Level shows all the interactions between subfunctions used to create a function. The Subfunction Level view shows all the interactions between components used to create a subfunction. 3) Functional to Physical: The views are used to create both 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 handoff between the system engineer and the design engineer usually happens at the function level. The design engineer translates a function into an assembly. The design engineer then uses the same diagrams to define the physical assembly. Consequently, there is a requirement to make a functionalto-physical translation map. This is usually done by defining which functional elements are allocated to which physical entity. It is at this level where the hardware and software allocations are usually made. This process means two parallel representations of the system at the same level may exist (functional and physical). The system engineer maintains the functional and the design engineer maintains the physical, with the translation map showing traceability. 4) Hierarchical Decomposition: A totally top-down decomposition is not always possible or necessary. The use of orthogonal views and a hierarchy of decomposition allows the system development to be created with many parallel activities. The views define how the components interact and allow for items at any level to be integrated into the system descriptions. This means that bottom-up development can easily be integrated into top-down or horizontal structures with complete traceability.
Block diagrams, mode matrices, state diagrams, and performance trees are hierarchical. This means that it is possible to replace a black-box view of an object with a lower level functional view (gray box) without going outside the boundary of the higher level black box. If it is necessary to go outside the boundary, the views make it obvious that there is a functional problem with the higher level. The timeline cannot be hierarchical. However, more details are created at lower levels. Timelines can diverge along concurrent (parallel operation) paths at lower levels. Unfortunately, there can be an explosion of the timelines at lower levels due to all possible combinations of states and concurrency, but this problem can be contained by the use of some rules in identifying the critical time paths and minimizing interactions. 5) Functional Decomposition: Our method requires the decomposition to begin with the mission level. Here all phases of the system utilization must be laid out. The phase analysis must show the lifecycle of the mission. A sample phase diagram is shown in Fig. 8. In each phase there can be more than one “scenario.” A scenario must show details of the interface between all systems and users employed in each phase. A sample scenario diagram is 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 considerable interaction between the various systems and many interface control documents will be required to specify all the interface requirements. One of the obvious requirements is specifying the STI. Here we can see that the response time of the highway user is critical (shown in the timeline in Fig. 7). The operatingphase scenario illustrates the need to specify the following: 1) 2) 3) 4) 5) 6)
power system requirements; environmental conditions; user response characteristics; vehicle characteristics; road characteristics; and traffic-light optical properties.
When these items are specified, the time intervals can be determined. The sample problem ignores all of these requirements. System Level: After the scenario is defined, the systems that are identified in the scenario are decomposed into elements. The transportation system has elements of highway (H/W), farmroad (F/R), and traffic lights. Element Level: The traffic-light element view is shown in Figs. 6 and 7. The block diagram, mode matrix, state diagram, and timeline are shown. There are no performance trees for this problem because of the lack of suitable higher level details in the problem statement. Because of the lack of problem statement detail (and to save space), the diagrams shown in Figs. 8 and 9 are functional only and do not show
all the required subsystems, such as power supply, mechanical structure, cooling, interconnection, and similar items. Functional to Physical: There are unlimited ways to implement the functional requirements: diode-relay logic, digital electronics, microcomputer and firmware, and so on. In the interest of space, we will not show the functional-to-physical translation for this sample problem. If we did, it would show the physical circuits, devices, and hardware/software partition and traceability to the functional design. This system design methodology makes clear the missing requirements in the sample problem and identifies how to rectify the problem statement. The method is a true system design 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 existing systems and software representations, and it ensures that all requirements are captured and tracked. Not only is it easy to learn and use, but it can be implemented with low-cost commercial office automation software. F. Solution via RDD-1007, 8 The RDD-100 model of the traffic-light problem shown in Fig. 10 uses the points in time at which signals change 7 M.
TM is a trademark of Assent Logic Corp., San Jose, CA.
Alford.
8 RDD-100
90
Fig. 10.
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
The RDD-100 model.
as “trigger” messages that propagate through the model. The model uses a separate process for the sensor, the controller, the timer, the highway light, and the farm light; these are shown as columns in Fig. 10, which are “concurrent branches” of a graph. To help explain this model let us walk through a few steps in one sequence of events. A tractor crosses the sensor, so the “tractor arrives” box in the upper left corner sends a signal ” to the “wait for tractor box.” The controller is thus “Sen released from this box and goes to the “turn highway red, farmroad green” box. During the transition, the CHWY signal is sent to the highway light releasing it from the “show HG” box and allowing it to move to the “show HY” box. At ” signal goes to the timer, releasing the same time, a “start it from the “wait for timer reset box,” and so on. and Sen The sensor iterates by sending Sen messages; for simulation purposes, one specifies the number of 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, is sent; it then waits until either then delays until the STI
LTI is sent or a reset arrives. This cycles twice for every time the controller cycles once. The farm and highway lights loop through their green-yellow-red sequences as commanded by the controller. The controller loops through the sequence of commanding message results in CHWY and the lights. The Sen and CHWR are sent reset of the timer. The CFRG or STI arrive. All further Sen when either Sen messages are then ignored. The timer is reset; the CFRY is sent; CFRR is sent when STI arrives; and the arrives. This model is executable cycle repeats when LTI and when executed, yields timelines and a demonstration of dynamic consistency of inputs and outputs. To ensure that all of the requirements have been satisfied, each requirement is “traced to” some function that implements it. This verification process revealed one possible ambiguity in the following requirement: “when a sensor signals that a tractor is on the farmroad, the highway light shall change to yellow.” What is to occur when the tractor does not move, and hence, the Sen signal is never sent—should the system cycle again? If so, the behavior would have to be modified to reflect this decision.
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
Fig. 11.
Entity relationship diagram.
Fig. 12.
Data-flow diagram.
The RDD-100 design was the first design of those presented in this paper to be validated. This was done by running a simulation and observing the input–output behavior. This highlights a very significant facet of systems engineering design methods: ease of validation. RDD-100 has validation tools built into the design tool. G. Solution via Structured Analysis9 There are three principal model views in most flavors of structured analysis [3], [9], [30]. Each of these views will be illustrated for the traffic-light problem. The first view of the system is the entity relationship diagram. This view depicts the principal tangible or logical entities in the problem domain, along with their relationships to each other. Relationships are usually of the types has-a, uses, is-a, performs, documents, controls, etc. The diagram may also contain cardinality information. In the entity relationship diagram of Fig. 11, a single entity, controller, represents the solution to the traffic-light controller. (At this stage, decomposing the solution into more than one entity may suggest a preconceived design solution.) The entity relationship diagram shows the relation the system will have with the entities external to it in the problem domain. For instance, the controller entity uses one timer and two sensors: it controls two HWLights and two FRLights. If no line exists between two entities, then those two entities need know nothing about one another. Partitioning relationships in this manner makes the system design much easier. The second view is a data-flow diagram, as shown in Fig. 12. Each oval on the data-flow diagram represents a process that the system will be required to perform. A process 9 E.
J. Taipale.
91
Fig. 13. Ward–Mellor state transition diagram.
transforms an input into an output. In this paper, we will make no distinction between a process and a function. The solid circles with arrows represent data required by the process. The arrow indicates the direction in which the data flows. The unfilled circles with arrows represent events that occur as a result of the process each arrow points away from. In Fig. 12, the processes CommandHWLight and CommandFRLight both require one piece of data, the color the light should turn. These processes also return data, either an acknowledgment that the process was successfully performed or an error message. The process ResetTimer takes one piece of data in, but returns no data. Instead, this process notifies the process WaitForEvent of two events for which it is responsible, STI and LTI. This diagram illustrates two important aspects of this system: the flow of data from one process to another and an enumeration of processes that the system must perform. As with the entity relationship diagrams, the lines connecting two processes are important because they effectively partition the functionality of the system. Although intuitive in this case, this data-flow diagram shows that the process ResetTimer need know nothing about the processes for changing the color of the traffic lights. The third view is a state transition diagram, as shown in Fig. 13. This diagram uses the Ward–Mellor notation [30], a notation that is particularly effective in modeling eventdriven systems. This view clearly represents the logical flow
92
Fig. 14.
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
Level 1 functional block diagram.
very similar. Traditional structured analysis has no corollary to the concept of subclassing or inheritance amongst entities that would capture this type of information. Therefore, beyond a certain scope of design problem, structured analysis has the potential to create more work for a design team. However, for problems of small scope, such as the traffic-light problem, the structured analysis methods work well. Fig. 15.
Level 2 functional block diagram for the INIT function.
H. Solution via Functional Decomposition10 of system operation, detailing which events the system will and will not respond to under all circumstances as well as the functions performed by the system at each point in its operation. The notation is simple and easily understood by consulting the symbology legend on the figure. Generally, events depicted on the state transition diagram correspond to events on the data-flow diagram, but there may be some overlap between what is an event and what is data in practice. For example, the events SensorTrigger and SensorClear on the state transition diagram correspond to different values of the data object Road Status in the dataflow diagram. In this case, a particular change in value of the Road Status data represents the occurrence of the event. Since the sensor will be polled, this is an accurate way to represent system operation. The structured analysis process is hierarchical. In the next layer of the hierarchy, the design team will assign functions from the data-flow diagram to subentities of the controller entity. These combinations will form requirements for subsystem-level components of controller. The same three diagrams will be generated for each of the subsystems of the controller, and the process will continue until the subsystems have been decomposed into tractable design problems (a result defined 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 of the system, in terms of the principal entities, data elements, and logical operation of the system. However, structured analysis has some deficiencies. It does not provide a formal mechanism to recognize system components and operations that may be shared between entities in the system. For example, the farmroad light and the highway light are almost certainly very similar physical devices. Further, the functionality required in the controller to operate the two light devices is probably
The problem statement usually serves as the top-level function [10], [22]. At the top level, the vocabulary of the problem domain, not of a particular solution dominates. For the traffic-light problem, the top-level function might be “control the traffic lights at the intersection.” This function is then decomposed into smaller subfunctions. The decomposition process is hierarchical; each of the subfunctions may be further decomposed into subsubfunctions until all functions represent tractable design problems of appropriate scope, a condition defined by the systems engineering team. Functional decomposition generates a block diagram of the functions performed by a system, as shown in Fig. 14. Arrowheads indicate that something, such as data or a signal, passes from the output of one function into the input of the next. Vertical lines between the centers of two function boxes indicate that the upper box function must start before the lower box function can start. Vertical lines extending downward from the right side of a box indicate that the lower function begins after the top function has completed. Vertical lines extending upwards from the left side of a box indicate that the top function begins concurrently with the bottom function (this figure has no such lines). In general, the control flow moves from left to right and top to bottom. Each of the functions in this figure can be decomposed into subfunctions. Functions that have been decomposed are indicated with an asterisk (*) after the function number. For example, the INIT function 1.* is decomposed in Fig. 15. The INIT function performs the initialization routines the system needs prior to entering operational status. The numbering of the functions shows the parent-child relationships as well as the level of the decomposition. 10 E.
J. Taipale.
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
93
Fig. 18. Example IM diagram.
Fig. 16. Level 3 functional block diagram for the function Obtain controller hardware-OK signal.
Fig. 19. IM for the traffic-light problem. Fig. 17. Level 2 functional block diagram for the function Command HW light yellow.
The level 2 decomposition of the INIT function shows the subfunctions of INIT. It also shows something the top-level diagram did not: an error condition. If INIT can accomplish its subfunctions successfully, the function flow moves from left to right, as in the level 1 decomposition. If a subfunction fails, however, INIT will branch into a subfunction called Signal ERROR. Note that nothing flows out of Signal ERROR, it is a control sink. If the system moves into Signal ERROR, function INIT will never be completed and the system will not begin operational mode. After the level 2 decomposition, it is again appropriate to determine whether another level of decomposition is necessary for each of the new subfunctions. For example, the subfunctions involved in the INIT function are good candidates for further decomposition. The function Obtain controller hardware-OK signal might be decomposed, as in Fig. 16. The level 2 decomposition of another function, Command HW light yellow, would proceed, as shown in Fig. 17. Although this decomposition is trivial, it points out something interesting in the design. The lines are vertical, indicating that no signal ever passes to the controller to indicate whether the lights are actually turned off or on. Early in the design, this decomposition has already pointed out a potential flaw. Determining when functions have been sufficiently decomposed is a matter left to the discretion of the systems engineer. In some cases, a third-level decomposition of the problem might be adequate. In other cases, the systems engineer might wish to continue the process until subfunctions resemble lines of pseudocode or simple human or machine operations. Functional decomposition became popular as a software method when software systems were generally of much smaller size than the systems of today. It is perhaps for this reason that functional decomposition most effectively manages systems of small to moderate complexity. It scales to this small problem nicely, in contrast to more formal methodologies that would impose far more rigor (and effort) for marginal additional benefits. While it is clear that had the decomposition of each function into subfunctions taken place,
a large number of diagrams would have been necessary; there is not much overhead information included in the notation that is not absolutely essential to the operation of the system. On the other hand, in the absence of such overhead, there is little information to reveal relationships and similarities between functions and the entities that perform those functions. For this reason, the functional decomposition process tends to become more unwieldy when systems become large and complex. We have found functional decomposition to be the most 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 solution based on the Shlaer–Mellor [26], [27] flavor of object-oriented analysis (OOA). My solution includes just some of the key parts of Shlaer–Mellor OOA, which are quite sufficient for dealing with the complexity of this problem. First, I will construct an information model (IM). The IM identifies the real-world objects involved, subtype–supertype hierarchy, relationships, and cardinality. From the problem statement, we can identify the objects as follows: highway light, farmroad light, tractor, sensor, and timer. (Objects were called entities in the structured analysis section.) Since the sensor and timer provide identical inputs (STI, LTI, and Sen) to both the highway light and farmroad light, we can generalize a supertype object of traffic-light, for which the highway light and the farmroad light are subtypes. We show the relationships common to both lights as relationships with the traffic-light supertype object. The relationships are shown as lines connecting two objects and are identified by a symbol containing a unique number, such as . Text on each side of the symbol identifies the meaning of the relationship, and the number of arrowheads indicates the cardinality. Fig. 18 contains an example where one P sees many Q objects, or many Q’s are seen by one P, and Fig. 19 contains the IM for the traffic-light problem. The purpose of the IM is to ensure that no real-world objects were omitted in the analysis and that every object included 11 G.
Hill.
94
Fig. 20.
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
State model for the farmroad light.
in the IM really is an essential part of the system, i.e., no unrelated islands. Using the IM as a checklist, we evaluate each object to determine if it is an active or passive object. Active objects have lifecycles in which they pass through various states, and their behavior can be represented in a state model or state machine. Passive objects have no lifecycle. For each nontrivial active object in the IM, we need to show the state model behavior as a state machine. We also need to determine if a single state machine for a supertype object will correctly represent the behavior of all its subtypes. If not, then a separate state machine is needed for each subtype object. From the problem statement, we know that the highway light 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 either present or absent in the eyes of the sensor, but since the sensor does all the work of detecting, we can consider the tractor to be a passive object, and so it does not need a state machine. The sensor can be either a trivial active object or a passive object. As a trivial active object, it passes back and forth between the two states of detecting presence and detecting absence of a tractor. As a passive object, it is merely the owner of the global Sen input signal. In either case, it needs no state machine, since the highway light and the farmroad light both get all the information they need about the sensor by recognizing the Sen input signal. Similarly, the timer needs no state machine, since the highway light and the farmroad light both get all the information they need about the timer from recognizing the STI and LTI input signals. However, we must be sure that highway-light state machine and the farmroad-light state machine both make correct use of the Sen, STI, and LTI input signals. The state model behavior of the highway light and farmroad light are shown in Figs. 20 and 21. In each state machine, states are shown as boxes and transitions are shown as arrows from a source state to a destination state. The only exception to this (an arrow with no source state) is used to identify an initial entry point or starting state in the state machines. The state boxes contain a state name, followed by the activities
that are executed when the object enters that state. At the conclusion of the activities, the object sits idle until an event occurs that causes a transition to the next state. The event is identified near each arrow that shows a state transition. The notion of activities happening within states follows the theory of 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 the timer starts counting over from zero. The action “signal X/Y to the other machine” means that we use some intermediate input–output signal to communicate between the state machines. For example, this intermediate signal could be a toggle action on X or Y in these state machines. If the introduction of new intermediate signals (X and Y) for interstate machine communication is not possible, then we could use the existing signals CHWG and CFRG as input–output signals to accomplish the same thing. If the CHWG and CFRG signals cannot be used as input signals for interstate machine communication, then we need to reduce the two state machines into a single state machine, which avoids the need for interstate machine communication. Although these state machines can be reduced to a single state machine with five states, this trivializes the problem to a much simpler level. Not all problems reduce to one state machine so easily. One of the strengths of the Shlaer–Mellor flavor of OOA is its ability to handle more complex problems by using concurrently running state machines that signal events to each other 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 different perspective than the more traditional functional design methodologies. The OO approach defines the relationship between things (the objects) in the problem with objects in the solution domain, then defines the domain of these objects [4], [15], [23], [26], [27]. An OOA often begins with recognizing the different classes of objects in the problem domain. Table IV describes some of the 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 show inheritance relationships between classes. Inheritance allows the designer to express commonality between classes. For example, a lion and a tiger are related in that they are both mammals. Inheritance also allows the designer to present information in one place and let it be used in many other places. For example, in the description of the class Light, we can specify the voltage, current, luminance, and heat produced. Then lights of any color would inherit these properties. This figure uses the notation of Booch [4], wherein a line with an arrow represents the inheritance relationship, e.g., a Red Light inherits all the properties defined for the class “Light,” etc. This notation represents a uses relationship with a line with an open circle, e.g., the Controller uses the Timer, the Pair Router, and the Sensor. A line with a solid circle represents the has-a 12 K.
Bharathan and J. Duke.
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
Fig. 21.
95
State model for the highway light.
CLASSES
TABLE IV SOLUTION DOMAIN
IN THE
Fig. 22. Class diagram for one solution domain.
relationship, e.g., a traffic light has-a Red Light, has-a Green Light, and has-a Yellow Light. State diagrams are created for each of the classes, describing how their behavior changes with different inputs. One advantage of this OO approach is that only one state machine is needed for the class “Light,” since none of its descendants behave differently. After the problem domain classes have been identified and their general behaviors have been defined, the designer can then start describing various scenarios where specific instances of the classes (the objects) are “created” and allowed to interact. These interaction diagrams can feed directly into the next stage of the iterative design process. One of the diagrams useful for showing these scenarios is the interaction diagram. Fig. 23 contains one of those diagrams where there are not many cars waiting at the farmroad. In these diagrams, time flows from top to bottom. The relevant objects are lined across the top of the graph. As time progresses, objects send messages to each other, represented by horizontal lines connecting the individual objects’ lines. The objects HW Router and FR Router are instances of the class Pair Router.
This figure shows just two scenarios. Many more could be written. Scenarios could be written for anomalous conditions. For example, a scenario could be written to show what the system does if the “HW Lights” do not return a “Confirmed” message to the HW Router. The number of scenarios needed to completely describe a system would depend on how many anonymous conditions were considered. The final phase of design involves writing state transition diagrams for those objects that are deemed active during the lifecycle of the system. In contrast to the other designs in this project, this OO design distributes the intelligence, i.e., at certain times, the server–client relationship changes. For example, the controller sends a message to the highway router object. The router then commands the highway lights to change to red. Only after this change is confirmed does the router send a signal to the farmroad router, instructing it to send a command to change the farmroad lights to green. Then, at the appropriate time, the farmroad router takes “control” and instructs its lights to change to red, gets the necessary confirmation, then commands the 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 useful in large-scale systems design. The scalability is available through the good definition of classes, allowing the design to be composed of modular, hierarchical elements that can have a one-to-one relationship with the physical elements in the solution domain. K. Solution via OpEM-Directed Graph Model13 An operational evaluation modeling-(OpEM)-directed graph model [6]–[8] of the traffic-light problem is shown in Fig. 24. The Begin event initializes the model and the Split Action operator in the upper left splits it into three concurrent processes. The top process models the interarrival time for tractors arriving to cross the highway. When a tractor arrives, a tractor object is created and initialized in the Wait-for-Green state. The middle process models the operation of the tractor. The Wait-for-Green state represents an indeterminate period of time while the tractor waits for the farmroad light to turn green. A tractor motion process in the Wait-for-Green state models the signal (TRACTOR WAITING) that occurs when a sensor detects a tractor waiting to cross the highway. The tractor crossing state (TR Crossing) models the time required for a tractor to cross the highway. The tractor clear event (Terminate TR) provides a signal that indicates that the tractor is safely across the highway and deletes the tractor object, terminating the process. A duplicate of the tractor motion process is created each time a tractor arrives to cross the highway and is deleted when crossing is complete. The bottom process models the operation of the trafficlight system. The process is initialized in the Min HyWay Grn state, which represents the minimum highway green13 J.
R. Clymer.
time controlled by the LTI timer. The next state, Green HW Wait, describes an indeterminate period of highway green time that persists until a tractor-waiting condition occurs. If the tractor waiting condition is true when the minimum highway green timeout occurs, then Yellow HighWay state occurs immediately. Thus, the end of Green HW Wait is activated by condition (TRACTOR WAITING) and executes action CHWY, which resets all CHW* flags to zero and sets CHWY to one. The Yellow HighWay state represents a STI period when the highway light is yellow. When the end of the Yellow HighWay state occurs, the highway traffic control process executes actions CFRG and CHWR. The Farm Road Green parallel process models a time period when either the tractor clear condition or a LTI period timeout can result in the end of the Farm Road Green condition. The event that ends the Farm Road Green period resets the LTI counter and executes action CFRY. The Yellow FR state represents a STI period when the farmroad light is yellow. The event that ends the Yellow FR state executes actions CHWG and CFRR and returns to the Green HighWay state. The logical condition for the assemble event of the top process, that is used to assemble the three concurrent processes and end system operation, is that the last tractor has arrived and has crossed the highway. 1) Benefits of the OpEM Language: Complex systems comprise a collection of processes where each process in the system communicates data, knowledge (rules and facts), and mission goals with one or more other processes. Collaboration, where two or more processes adapt their operations to achieve overall system goals, is much more difficult to achieve than coordination, where only information is exchanged. The system design and evaluation language used to describe system operation must be capable of describing
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
Fig. 24.
97
OpEM-directed graph model.
explicitly all process interactions required for collaboration. These include synchronization, deconfliction, and resource contention. A system design and evaluation methodology [8] based on OpEM diagrams [6] is summarized as follows. First, design each system process to work optimally to perform and adapt its activities, given information about the current situation; Second, assume unconstrained process communication, and apply machine learning [8] to optimize coordination and collaboration of processes by iteratively: 1) adapting process operation to achieve overall system goals, 2) discovering essential knowledge sharing required to achieve such collaboration, and 3) allocating system processes to subsystems and define a subsystem coordination and communication method to connect each subsystem effectively to share essential information. 2) The OpEM Systems Engineering Tool Kit: This has been developed during the past ten years to implement the required system design and evaluation methodology needed for complex systems. This toolkit can be downloaded from http://ECS.Fullerton.edu/ JClymer/. Modules in the OpEM tool kit include the following: 1) discrete event/continuous simulation that manages event occurrences in simulated time; 2) object movement and interaction that models the physical motion of objects and their spatial relationships and stores object state information;
3) adaptive fuzzy expert system controller that provides the rule-based part of decision making; 4) fuzzy rule tree induction that discovers decision-making rules during simulation of a system; 5) an evolutionary algorithm that is designed to work with simulation generated fitness values; and 6) a run-time user interface that displays event-state traces and allows modification of rules and fuzzy facts while the simulation is running. L. Solution via IDEF014 The term IDEF comes from ICAM (Integrated ComputerAided Manufacturing) and DEFinition language [14], [18]. The IDEF0 method was formalized by the Air-Force ICAM project. It is based on the Structured Analysis and Design Technique (SADT) developed by Douglas Ross and others at SofTech in the early 1970’s [21]. An IDEF0 model consists of a hierarchy of activities (or functions) with attending links and constraints. In this paper, we will make no distinction between an activity and a function. Activities are bounded by Inputs, Controls, Outputs, and Mechanisms (referred to in aggregate as ICOM’s). ICOM’s show the information and physical objects that link and constrain activities. When viewed in IDEF0 diagrams, activities 14 D.
L. Dean.
98
Fig. 25.
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
IDEF0 model.
are represented as boxes and ICOM’s are represented as arrows. Activities and ICOM’s are also textually defined in a glossary to reduce ambiguity. An input is converted by an activity into an output. A control is a constraint that governs an activity (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 will make no distinction between mechanisms and objects. As shown in the symbol legend of Fig. 25, inputs enter through the left side of activities, controls enter the top, outputs exit from the right, and mechanisms enter from the bottom. This specific ICOM placement convention is very useful. A reader of a diagram knows the content of an arrow by the position of the arrow on the activity. The differentiation between inputs and controls is useful. It helps the designer and reader differentiate between controls that govern an activity from inputs that are changed by an activity into outputs. The traffic-light problem is a controlcentric problem by definition. Much of what is passed between the activities is control information, such as messages from the controller to the traffic lights signaling a change of color. In contrast, a manufacturing environment has fewer controls and more input–output conversions. For a manufacturing model, it is also helpful to differentiate between a control on an activity and an input to the activity. The IDEF0 method allows that distinction to be made. Another strength of the IDEF0 method is that it encourages the 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 “Interval Duration Policy,” an externally imposed control on activity A2. This external control allows the controller to merely request that the timer generate an STI or an LTI without having to pass an STI or LTI interval duration parameter to the timer. An externally imposed control on activity A3 is “Light Control Policy.” It could, for example, specify that if the highway green or yellow lights are on, then the farmroad red light must be on. The understanding of which controls are externally imposed has implications for the design. When trying to improve an existing design, it is important to examine the assumptions in the external controls. Sometimes changing these assumptions will improve the design. Moreover, the explicit statement of external controls makes it easier for the designer 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 trafficlight problem, it is easier for the designer to conceptualize and separate out activities that specifically correspond to each mechanism. The designer may also benefit by deferring the definition of mechanisms until after derivation of an implementation-independent model. This allows the designer to postpone premature involvement with issues regarding who or what machine will perform an activity until after an understanding of the activity has been achieved. Since the objective of this traffic-light problem was to design 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
However, the light projection activities are easily included in the diagram so that the reader can contemplate the entire traffic-light system. The IDEF0 method is better than data-flow diagrams because it is easier for the reader to know where to begin. The structure of IDEF0 diagrams shows the reader where to begin and in what order to proceed. However, IDEF0 diagrams are not purely sequential, because concurrency is depicted. As admitted in the introduction to this paper, small problems do not demonstrate the power of some modeling methods that scale well to larger, more complex problems. Much human factor engineering has gone into IDEF0 to make it scale well to larger problems. The hierarchical decomposition of IDEF0 allows parent activities to be broken down into child diagrams, but in a disciplined way. The numbering of the activity 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-orminus-2 guideline. The lower limit is based on not having a decomposition unless there is enough information to justify a new diagram. Moreover, any side of an activity is limited to six arrows. These limits help the analyst manage the complexity of a problem by encouraging purposeful decomposition. Details of the model are pushed downward into lower levels where they belong. Moreover, consistent levels of abstraction tend to be found horizontally across any level of the model hierarchy. Unlike IDEF0, some forms of structured analysis allow a large number of transforms or actions to happen on one diagram. This may lead to cluttered diagrams that are hard to understand and that cognitively overload the reader. Such diagrams may contain too much content at the same level of abstraction or hold content of very different levels of abstraction. In the traffic-light problem, as in many other machine control type problems, it would be appropriate to prepare a state transition diagram to complement the IDEF0 model. IV. DISCUSSION We have presented solutions for a simple design problem by using 11 different methods. Each method was used by an expert with that method. We did not create a numerical ranking of the methods because we do not want our experts to fine-tune their solutions to fit our problem and metrics. From the presentation of these 11 methods, we hope the reader can understand the methods. Then, if he or she wants to use a particular method, appropriate references can be consulted. A. Implementation We stated that the systems engineer should use a highlevel method for the high-level design. Then, he or she should work in conjunction with the specialty design engineers to produce the low-level or state machine implementation of the system. Sometimes the design changes when it goes from the high-level design to the low-level implementation. We created a hardware simulation of the highway–farmroad intersection in our laboratory with switches, LED’s, TTL circuits, and a BASIC Stamp II microcontroller. Then, for three of our designs, we implemented the high-level designs on this
99
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–Mellor style solution. The state machine (Fig. 13) was translated into a BASIC program and downloaded to the microcontroller. The implementation required no changes to the design. The Duke–Bharathan OOD (Fig. 22) was implemented in C++ [28] and was downloaded to the microcontroller. This design proved difficult to implement, primarily due to difficulties with multiple active objects on the single-threaded operating system resident in the Basic Stamp II microcontroller. The design had to be changed significantly to accommodate this problem once it was presented to the specialty engineers. This merely confirms that the method used substantially effects the implementation. We have also written a model of the highway–farmroad intersection in the Java language. Then, we used Java to implement the state transition diagrams of Figs. 2 and 13 and the functional decomposition of Fig. 14. These implementations are 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). This caused difficulty for a few of the methods. But all were eventually able to handle this complexity. Also, all methods were capable of either showing all possible state transitions or only those that were expected to occur. So this did not distinguish between our methods. We will try to identify other characteristics of problems that might make one system design method more or less appropriate. The second problem in our Methods Analysis Project is the design of a small restaurant. It involves scheduling and performance figures of merit. But the main distinguishing characteristic is concurrency of processes. The chef prepares the food, the oven bakes the food, the waiter delivers the food and people eat the food, all at the same time. We expect to have 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 caf´e. Your new caf´e has five tables that can each seat four people at a time. You have a kitchen unit that has a refrigerator, a freezer, a counter to store prepared but uncooked dishes, a stove with four grills, an oven that can hold two pans at a time, a food warmer to keep cooked dishes warm, and a shelf for holding plates of food for delivery to customers. You have no more capital, and you have no prospects to get any. So you cannot expect to buy more kitchen units. Since your business is new, you have decided to restrict your menu to only two entrees and two desserts. Your first entree, grilled chicken breast, requires 5 min of preparation, followed by 10 min on a grill. Your second entree, pepper steak, requires 10 min of preparation, followed by 5 min on a grill. Your first dessert, a chocolate souffl´e, 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. Your second dessert, ice cream, requires 5 min of preparation. Each grill can hold only one entree and the chef can be preparing only one dish at a time. Food does not need to be prepared or cooked in the sequence the customers placed their orders. Desserts should be delivered at an appropriate time. Taking orders and delivering dishes each takes 1 min per customer. Your caf´e will need to receive orders from customers, prepare and cook the ordered food, deliver the food from the kitchen to the customers, and receive payment from the customers. We will use performance figures of merit, such as throughput (in customers/h), difference in delivery time between the first and last entree at each table, difference in delivery time between the first and last dessert at each table, number of times the chef is interrupted while preparing a dish, the time each dish has spent waiting to be cooked, the time each dish has spent waiting to be served, the number of ice cream dishes that 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 caf´e problem and the third problem. Eleven experts using 11 different methods have already solved the traffic-light problem and those solutions are in this paper. The caf´e problem has been formulated, and we have three trial solutions. But none of our experts have solved this problem yet. The third problem has not been formulated yet. D. Other Potential Metrics for Comparing the Methods A metric that we considered for evaluating our methods was handoff-ability. The system designer produces a toplevel design for the system. This design must then be given to specialty engineers for implementation. If the specialty engineers are not familiar with the method used by the system designer, then it will be difficult to handoff the design. This metric was hard to evaluate because it depends as much on the company’s organization and the training of their engineers as it does on the method itself. Another metric we have considered is complexity. The number of inputs, outputs, states, and interface connections could quantify this. But of course this is circular reasoning because the numbers of inputs, outputs, states, and interfaces will depend on which design and implementation methods are used. Condensability means the model can be simplified for certain presentations. This could be accomplished by organizing the elements into hierarchies, wherein elements at a particular level could be condensed into one block and later expanded. This is the organizational style for RDD-100, model-based systems engineering, functional decomposition, and IDEF0 solutions. However, state transition diagrams and ASM solutions are almost never decomposed into hierarchies. Reducing the number of transitions shown could also simplify presentations, for example, by not showing all possible state transitions, but only those that were expected to occur. Most methods have provision for showing only expected inputs. Finally, ASM charts introduced the concept of not showing all outputs, but showing only those that are turned on.
We have also considered the following metrics for the methods: simplicity, ease of design alteration, learning effort, implementability, design changes necessary for implementation, comprehensiveness, size of the documentation, transparency, understandability, communicability, scalability between small and large problems, and ease of handling concurrent processes. E. Shortcomings This project has many shortcomings. We would like to add more tools and methods to this project, such as CORE, colored Petri nets, Slate, fuzzy-neural systems, SilverRun, the Objectory, VHDL, and Sim Factory. But so far we do not have expert authors. The first and foremost tasks of systems engineers are stating the problem and discovering the requirements [2]. For this traffic-light problem, we did not give our authors an opportunity to do this. We forced them to solve a very tightly constrained problem. We asked them to design a controller for the traffic-light system. We did not allow them to consider the problem of getting the farmer across the road, which might be solved better with a bridge. However, it is interesting to note the variability in these solutions. All the authors were given the same written statement of the problem (Section II) and the same two-page constraint. But some of the solutions are detailed, whereas others are abstract. Indeed, some are not solutions at all, but are mere models of the problem space. Perhaps this indicates that not only does the choice of the method effect the solution, but also the choice of the designer. In future work, we will have a specific battery of questions that each author will have to address after his or her design has been completed. Candidate questions include the following: how did you define the system boundaries? What were the inputs, outputs, functions, and states? How were they modeled? How was the physical system modeled and decomposed? Did the method identify missing requirements? Was discovery of these missing requirements a result of the method or the experience of the engineer? How did the method address certain specific issues, such as pulse versus level outputs, concurrent versus serial processing, and distributed versus centralized control? F. Commonalties of the Methods For most of these methods, we think that the best way to describe what the system is supposed to do is to help the customer construct sequences of events that describe desired and acceptable input–output behavior. This paper has shown two examples in Table III and Fig. 23. Such descriptions of behavior as a function of time are called trajectories, behavioral scenarios, use cases, threads, operational scenarios, logistics, functional-flow block diagrams, or interaction diagrams. After many such behavioral scenarios have been collected, the designers can define the control inputs, data inputs, outputs, objects, functions, and states. Most of these methods differentiate between control and data inputs. The problem statement specified the following four control inputs: Initialize, Sensor, STI, and LTI. Various solutions have used the following data (or material) inputs: tractor, electric power, heat, and repair parts.
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
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 as HW Light Green, Then Sen Received, Now Waiting for LTI. And functions are usually named with verb phrases, e.g., DetectTractor. In this paper, the functions were sometimes called processes or activities. OO methods concentrate on objects and seem to ignore functions and states. But although they do not emphasize functions and states, they do consider them. For example the object Sensor (Fig. 22) has the function DetectTractor (which would be described in the documentation), and the object Farmroad Light (Fig. 19) has the states Farmroad_Light_R, Farmroad_Light_G, and Farmroad_Light_Y (Fig. 20). In contrast, state transition diagrams focus on states and seem to ignore functions and objects. However, they are there. While in the state Highway-green (Fig. 2), the functions Command Highway Green Light On and Command Farmroad Red Light On are preformed. The system objects could be shown in an -squared diagram, as in Fig. 26. -squared ( ) diagrams are often used to evaluate interfaces between subsystems. Sometimes, instead of using arrows to show interfaces, an X is merely placed in the box to indicate an interface between the subsystems in that row and column. The functional decomposition method focuses on the functions. In Fig. 27, the functions (verb phrases) are inside the boxes. But these functions have inputs and outputs that are objects (nouns). However, this method seems to ignore the states. The IDEF0 diagram of Fig. 25 explicitly shows the objects (called mechanisms), such as Road Sensor and Timer. It also explicitly shows the functions (called activities), such as Monitor Farm Road Traffic and Count Down Time Intervals. However, it seems to ignore the states.
101
Structured analysis uses a different method to focus on each of these three aspects. It uses entity relationship diagrams to focus on the objects, data-flow diagrams to focus on the functions, and state transition diagrams to focus on the states. So which of these methods is the best? It depends on the problem. For modeling existing physical systems (like the patient referral system in a hospital), Bharathan and Bahill have found OO methods to be best. They found that nonengineers, like physicians and nurses, relate to objects more readily than to functions. Physicians and nurses can visualize objects like nurse, managing physician, and patient record easier than they can functions like obtain committee approval or request referral. In this case, it seems that the human mind relates to objects better than functions. Similarly, archeologists studying Stonehenge and Machu Pichu easily describe 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 matter which method is used, in order to communicate your design, all of the objects, functions, and states must eventually be identified. ACKNOWLEDGMENT The authors thank F. Dean for his support, B. Bentz for help with the manuscript, and the anonymous reviewers for insightful comments. REFERENCES [1] A. T. Bahill et al., “The systems engineering design tools analysis project,” 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 System Requirements. Sandia Nat. Lab., Albuquerque, NM, SAND961620 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, Engineering Modeling and Design. Boca Raton, FL: CRC, 1993. [6] J. R. Clymer, P. D. Corey, and N. Nili, “Operational evaluation modeling,” in Simulation, San Diego, CA: Soc. Comput. Simulation Int., 1990, pp. 261–270. [7] J. R. Clymer, “Role of reductionism and expansionism in system design and evaluation,” in Proc. 4th Ann. Int. Symp., Nat. Council Syst. Eng., San Jose, CA, Aug. 10–12, 1994, pp. 323–332. [8] , “Expansionist/context sensitive methodology: Engineering of complex 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 Engineering, E. N. Yourdon, Ed. New York: Yourdon, 1979, pp. 43–48. [11] P. A. Fishwick, Simulation Model Design and Extraction. Englewood Cliffs, 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 Standards Pub. 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: Benjamin Cummings, 1994.
102
IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 28, NO. 1, FEBRUARY 1998
TM
[17] E. V. LaBudde, “Graphical description language a solution for the system-software interface problem,” in Proc. 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 and Enterprise 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. Englewood 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. Lorenson, 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. , “Model problems in software architecture,” http:// [25] www.cs.cmu.edu/ Compose/html/ModProb/index.html, Nov. 1996. [26] S. Shlaer and S. Mellor, Object-Oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, NJ: Prentice-Hall, 1988. , Object Lifecycles: Modeling the World in States. Englewood [27] Cliffs, 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 the Entscheidungsproblem,” in Proc. Lond. Math. Soc., vol. XLII, 1936, pp. 239–265, with a correction in ibid., vol. XLIII, 1937, pp. 544–546. [30] P. T. Ward and S. J. Mellor, Structured Development for Real-Time Systems, 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 from the University of Arizona, Tucson, in 1967, the M.S.E.E. degree from San Jose State University, San Jose, CA, in 1970, and the Ph.D. degree in electrical engineering and computer science from the University of California, Berkeley, in 1975. He has been a Professor of Systems Engineering at the University of Arizona since 1984. In the last few years, he has spent 20 months working at 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 Idaho National Engineering and Environmental Laboratory, Idaho Falls. He has presented seminars on Systems Engineering and has helped each company describe its systems engineering process. He is the author of Bioengineering: Biomedical, Medical, and Clinical Engineering (Englewood Cliffs, NJ: Prentice-Hall, 1981), Keep Your Eye on the Ball: The Science and Folklore of Baseball, with R. G. Watts (San Francisco, CA: Freeman, 1990), Verifying and Validating Personal Computer-Based Expert Systems (Englewood Cliffs, NJ: Prentice-Hall, 1991), Linear Systems Theory, with F. Szidarovszky (Boca Raton, FL: CRC, 1992), Engineering Modeling and Design, with W. L. Chapman and A. W. Wymore, (Boca Raton, FL: CRC, 1992), and Metrics and 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, modeling physiological systems, eye–hand–head coordination, validation of knowledgebased systems, quality improvement, business process redesign, and systems design. He has tried to make the public appreciate engineering research by applying his scientific findings to the sport of baseball. Dr. Bahill has served as Vice-President of the IEEE Systems, Man, and Cybernetics Society as well as Associate Editor, as Program Chairman for the 1985 conference in Tucson, and as Conference Co-Chairman for the 1988 conference in Beijing and Shenyang, China. He served as an Associate Editor for the IEEE Computer Society’s magazine, IEEE Expert. He holds United States Patent 5 118 102 for the Bat Chooser, a system that computes the Ideal Bat Weight for individual batters. He is a Registered Professional Engineer and the Editor of the CRC Press Series on Systems Engineering.
Mack Alford received the B.A. degree with honors in mathematics in 1962 and the M.A. degree in mathematics and statistics, both from the University of California at Los Angeles (UCLA), in 1966. He performed graduate work at UCLA in computer science as a TRW Fellow from 1969 to 1974. He is now an independent consultant. He spent 25 years with TRW and was the founding technologist for Ascent Logic Corp., San Jose, CA, which builds 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 University of Delhi, New Delhi, India, in 1973, the M.A. degree in economics from Jawaharlal Nehru University, New Delhi, India, in 1975, the M.Phil. degree in economics from the University of Madras, Madras, India, in 1979, the Ph.D. degree in economics from the University of Madras in 1990, and the M.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 Arizona Medical Center. He was a Systems Engineer at Bahill Intelligent Computer Systems in Tucson, AZ, from 1992 to 1996. He was on the faculty of the Madras Institute of Development Studies until 1988, and prior to that, he was on the faculty of the Madras Christian College, Madras, India, from 1976 through 1978. His research interests include systems engineering theory, the design, verification, and validation of expert systems, the knowledge extraction process, and object-oriented systems engineering. Dr. Bharathan is a member of the IEEE Computer Society, the IEEE Systems, Man, and Cybernetics Society, and the American Medical Informatics Association.
John R. Clymer (M’68) is a Professor of Electrical Engineering at California State University at Fullerton (CSUF), Placentia, and consults in the area of systems engineering by using simulation and artificial intelligence. In addition to consulting, he presents intensive short courses on systems engineering and simulation at various locations around the United States and Taiwan. His research interest currently is intelligent, complex adaptive system architectures, such as multiagent systems. Topics include simulation, adaptive-fuzzy expert system controller, machine learning, evolutionary programming, and general problem solvers and planners. Dr. Clymer is a founding member of the Applied Research Center for Systems Science (ARCSS) at CSUF and is a member of SCS and INCOSE.
Douglas L. Dean (M’97) received the M. A. degree in information system consulting 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 a number of topics, including electronic meeting systems (EMS), collaborative business process reengineering methods, and collaborative systems analysis and design methods. He has helped develop group-enabled activity and data modeling software to support technical and nontechnical users. He also developed structured meeting methods for use with these tools. The activity model software has since been made commercially available through Ventana Corporation, Tucson. His research interests include electronic meeting support of process and data modeling, business process reengineering, systems analysis and design, and group elicitation of information systems requirements.
Jeremy Duke received the B.S. degree in systems (software) engineering in 1994 and the M.S. degree in systems engineering in 1996, both from the University of Arizona, Tucson. He is currently working as a Project Leader and Software Engineer at Intel Corporation, Chandler, AZ, writing requirements for designing and implementing real-time, mission critical station controllers in the Assembly/Test area of manufacturing. His current interests are in software testing and requirements validation techniques.
BAHILL et al.: DESIGN-METHODS COMPARISON PROJECT
Greg Hill (M’80) received the B.S. degree in nuclear engineering in 1976 and the M.S. degree in computer science in 1978, both from the University of Arizona, Tucson. Since 1978, he has been an Advisory Engineer at the IBM Tucson Laboratory. At IBM, he has held a variety of technical assignments in the planning, analysis, design, and implementation of software tools, microcode development and analysis tools, and project management tools. His latest assignments were in the development of tape device microcode and storage control 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 Michigan State University, East Lansing, in 1968 and the M.B.A. degree from Alabama A&M University, Normal, in 1978. He has more than 30 years of experience in advanced development and has extensive experience in entrepreneurial leadership roles for product and organizational development projects. He holds more than 30 patents and has published numerous papers on various engineering topics. Mr. LaBudde is a member of INCOSE and SPIE.
103
Eric J. Taipale (S’93–M’97) received the B.E.E. degree from the University of Minnesota, Minneapolis–St. Paul, in 1994 and the M.S. degree in systems engineering from the University of Arizona, Tucson, in 1996. He is currently a Staff Engineer in the Advanced Programs group at Lockheed Martin Tactical Defense Systems, Eagan, MN. His current interests are automated signal feature extraction and target classification systems.
A. Wayne Wymore received the B.S. and M.S. degrees from Iowa State University, 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 Systems Engineering and the first Director of the Computing Center. While managing, teaching, researching, and consulting internationally, he authored A Mathematical Theory of Systems Engineering: The Elements, 1967, Systems Engineering Methodology for Interdisciplinary Teams, 1976, and Model-Based Systems Engineering, 1993. System Functional Analysis and System Design, Phase 2 of model-based systems engineering is forthcoming.
