C4ISR Architectures: III. An Object-Oriented Approach for Architecture ...

Regular Paper

C4ISR Architectures: III. An Object-Oriented Approach for Architecture Design Michael P. Bienvenu,* Insub Shin, and Alexander H. Levis System Architectures Laboratory, C3I Center, MSN 4D2, George Mason University, Fairfax, VA 22030 C4ISR ARCHITECTURES. III

Received April 25, 2000; accepted July 14, 2000

ABSTRACT A UML-based process for developing C4ISR architectures is presented. The process demonstrates the feasibility of developing architecture descriptions that conform to the C4ISR Architecture Framework based on an Object-Oriented paradigm. The process is illustrated through the same example that is used in the companion paper to illustrate the Structured Analysis approach so that comparisons can be made.  2000 John Wiley & Sons, Inc. Syst Eng 3: 288–312, 2000

1. INTRODUCTION

work, Version 2.0 [C4ISR, 1997] includes only the necessary architecture documentation products, and specifically views development processes as out of scope. A description of the Architecture Framework, its associated products, and the methodological issues associated with the latter can be found in Levis and Wagenhals [2000]. However, the absence of a process specification in the Architecture Framework leaves the architecture developer in a bit of a quandary, especially since there are no well-defined and widely accepted processes in place that have the scope required by the Framework. However, this situation is also an opportunity for experienced architects, for they are free to define a process that best fits their own current project and prior experiences. In this paper, we will demonstrate a feasible approach to architecture definition that uses the Unified Modeling Language (UML). The key driver for this process is the requirement to develop architecture specifications which satisfy the C4ISR Architecture

The U.S. Department of Defense faces an intense challenge to develop and maintain interoperable systems in today’s environment of unprecedented rates of technology change. As part of meeting this challenge, standards for architecture specifications are being used throughout DoD and, in particular, for the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) domain. However, the relevant document, the C4ISR Architecture Frame-

*Author to whom all correspondence should be addressed. Grant sponsor: Office of Naval Research; grant number: N0001400-1-0267 Grant sponsor: Air Force Office for Scientific Research; grant number F49620-95-0134 Systems Engineering, Vol. 3, No. 4, 2000 © 2000 John Wiley & Sons, Inc.

288

C4ISR ARCHITECTURES. III

Framework product definitions. The primary purpose of the paper is to demonstrate that the object-oriented paradigm can in fact be used to develop the C4ISR products (not a foregone conclusion, since the C4ISR is strongly based on Structured Analysis). A secondary purpose is to provide a UML-based process to the analysis/development community which is addressing the architecture-specification problem. The process presented here is simply an existence proof—an example which demonstrates that such a process is indeed feasible and practical, and which can be used as a model for developing a tailored process for a particular project or organization. We present this process not as a methodology which a reader must choose over other existing methodologies. Indeed, in our past experience, real-world projects have taken existing methodologies and adapted, modified, and tailored them to fit the particulars of the project and the experience level of the personnel involved. In this light, we suggest that readers examine the process presented here and adapt their preferred methodologies as they see fit to ensure that all aspects required by the Framework are included. This paper is Part III of a three-part series. Part I provides an in-depth description of the C4ISR Architecture Framework and a discussion of the role of architectures and architecture definition in the overall system engineering process [Levis and Wagenhals, 2000]. The design of architectures using Structured Analysis is contained in Part II [Wagenhals et al., 2000]. The paper is organized into several sections. The remainder of Section 1 discusses the detailed goals of this work within the context of architecture development in general, and also discusses the intended audience. Section 2 presents only a brief discussion of UML, since it has been already the subject of a number of excellent descriptive books and papers. Section 3 presents the development process, step-by-step, through a sample problem. Section 4 summarizes, with an overall roadmap, the overall process. Section 5 presents some conclusions from the work.

1.1. Example Problem The example used for illustrative purposes is the fictional FastPass system used at OilCo gas stations. This fictional system is conceptually based on the Mobil Corp. Speedpass system. However, it must be pointed out that the work here does not represent the actual system architecture of the Mobil Speedpass system, nor have the authors had any role in the Speedpass system other than as customers. The architectural challenges that were faced in adding a new information-technology based capability on top of two

289

large “legacy” systems are exactly the challenges that the architecture specification process is intended to address. Granted, this is a somewhat simple example problem. Many issues (such as complex operator functions, system maintenance functions, or distributed, cooperative behavior) will not arise, or are not addressed. Concurrency could be examined by introducing multiple pumps at a station, with simultaneous customers; however, even this is not a particularly stressing form of concurrency. And the complexity of the human-system interface is minimal when compared with other real-world situations, such as air traffic control. The Fastpass example is, however, sufficiently complex to illustrate many of the points of the process, and, since we are working primarily at the architecture level (as opposed to the systems design level), many of the complex details will not be apparent. For example, an architectural-level description of the air traffic control system might not make the controller’s job appear as complex as it is in actual execution.

1.2. Goals of Architecture Definition The purpose of defining a C4ISR architecture specification is to assure that system-wide characteristics (such as mission effectiveness, interoperability, etc.) are achieved across the evolution or deployment phases of the systems that are build in conformance with the architecture. These systems may be related by timeevolution, by differing deployment options, or both. Time evolution of systems is common in the U.S. DoD, where individual systems that are interconnected in a large, distributed system are replaced by upgraded versions. Systems may also differ over deployment schemes, as in the case of large building security systems, which consist of a large number of component types, with specific deployments having varying mixes and numbers of components. The U.S. DoD has found numerous situations where such problems have arisen, and, in response, has developed the C4ISR Architecture Framework (AF) [C4ISR, 1997]. However, the C4ISR AF was designed primarily in conjunction with Structured Analysis concepts. While not precluding the use of object-oriented concepts, no specific guidelines for using OO to develop the C4ISR AF products were included. A list of the specified products is presented in the Appendix. This process is aimed primarily at architecture specification, which is a different problem than single-system analysis and design. The dividing line between the two regimes is admittedly vague—when developing an architecture specification, one should provide sufficient information to assure that component systems will “fit”

290

BIENVENU, SHIN, AND LEVIS

into the architecture, while simultaneously trying to avoid “overspecifying” the architecture and overly constraining the system designers. But perhaps the key motivation to requiring an architecture specification (as opposed to a single system) is the issue of evolution of a system. Systems today are being designed in a more modular form, with individual pieces being upgraded on different schedules, as needs and the technology base change. There is a strong and growing need to define the common aspect of the evolving system—what will be constant with respect to time. It is this role that the architecture attempts to fill. To demonstrate a process that supports a system under evolution, we will explore the FastPass example in both before and after configurations (“As Is” and “To Be”). In general, these systems consist of a set of physical entities, interconnected with communications links, which host (have located at them) certain functions (functional units). These functions are performed by mechanisms (personnel, devices, and software), and communicate with each other via data passing, messages, invoking remote operations, and/or signals. These systems can also have a number of replicated centers, basically performing the same functions independently and in parallel, with supporting communications assets. Significant tradeoff analyses consist of examining different mappings of functions/operations to different locations/nodes within the architecture. Different mappings will result in different workload at each location and in different bandwidth utilizations on the connecting links. A constantly recurring question involves the boundary between architecture definition and system design—where the boundary lies, how to determine it. At what level of detail does an architecture specification start to intrude on system design? Unfortunately, such a determination cannot be made precisely. In practice, the dividing line is often determined more by contractual issues than by technical ones, since the system designers can be in a different organization than the architect. Even within a project, there is often the problem of distinguishing where requirements specifications stop and detailed design work begins. The dividing line is always relative to the scope of the project, or projects, involved. In the example used in this paper, we define the architecture of the entire OilCo system. If this were a real project, there might also be the need to define a separate, lower-level architecture for the wide variety of pump models which would be deployed at the many stations all across the country. However, the architecture for the pump systems will probably be at a much greater level of detail than a system level architecture, since many of the mechanical, electrical, and plumbing interfaces would

have to be specified for the pump and these interfaces do not enter the scope of the system-level architecture. The boundary between architectures and design must always be viewed in the context of the individual project, and will vary across different projects of varying scope and context. As a possible rule of thumb, consider: If an independent system designer would view the architecture specification as intrusive into their design, then the architecture is at too low a level of detail. As a minimal guidance on the required level of detail of an architecture, one might expect that the architecture description would capture both the key structural and behavioral elements of the architecture as defined in the operational concept. Although it would be nice to specify that the architecture description does this unambiguously, it often seems that ambiguity is better seen in hindsight than in foresight.

2. BACKGROUND 2.1. UML Description Although there is no official standard for Object-Oriented languages or methodologies, the Unified Modeling Language (UML) has, without a doubt, become the leading and most widespread OO language. However, it is not a methodology—in fact, the authors (Object Management Group) specifically point out that a methodology is considered vital, but is project-specific, and therefore outside the scope of UML itself [UML, 1999]. This paper lays out (a) a UML-based methodology for developing architecture specifications for information systems and (b) procedures for developing C4ISR products from the UML descriptions. UML is a well-designed language, which has builtin extension mechanisms for customizing the language for specific applications. In addition, the language is sufficient and complete in that, through automated tools, compilable high-level software code (such as C++) can be automatically generated from a UML “model.” This allows compilation and execution of the model immediately, which is an invaluable tool for verifying the correctness of the architecture model. In reading the UML descriptions and specifications [UML 1999; Booch, Rumbaugh, and Jacobson, 1999; Quatrani, 1998], it is apparent that the language is primarily intended to support the design and development of software (or, at best, software-intensive systems). However, many architecture-specification projects need a more hardware–software hybrid orientation, and we have attempted to provide that in our process. The UML is a modeling language, but the Object Management Group considered the issue of an associated modeling methodology as outside the scope of the

C4ISR ARCHITECTURES. III

UML [UML, 1999]. The UML is limited to the definition of a set of diagram types, their component entities, and the metastructure that relates these entities to each other, thus forming an internally consistent and rigorously logical descriptive system, which also includes rules for extension of the language. Because UML is designed primarily for software and software-intensive systems, the constructs within the language may not always be the most suited for systems that are more hardware or organization oriented. Table I contains a brief description of the data elements that are found in the various UML Diagrams. There are a number of excellent references, tutorials and suggested software design methodologies available [Booch, Rumbaugh, and Jacobson, 1999; Quatrani, 1998]. UML has its roots in computer science and software engineering. Although the references often discuss “systems,” the overwhelming emphasis is on software. On the other hand, C4ISR systems, while they often have software-intensive components, usually have significant hardware aspects as well. Fighter aircraft, radar systems, satellites, or naval ships do not quite fit into the description of “software-intensive”—the hardware components are critical and key to their design and operation. Given this situation, why select UML as the basis for a systems engineering representation? One major motivation is continuity of design description throughout the systems engineering process. Often, different stages of a program are expressed in almost completely different forms, from text to data flow diagrams to psuedocode. The difficulty lies not with any one particular form of expression, but in the translation between different forms. As UML has become a dominant force in software engineering, it is not unreasonable to expect that the software portions of our systems will use UML for the design and possibly for the implementation. If top-level architecture and systems designs can be expressed in UML, then this will eliminate one translation from the overall process. The

291

option of using UML for the architecture work should be available to a program’s management.

3. THE ARCHITECTURE DEVELOPMENT PROCESS This section presents the architecture development process. Introductory comments and process-related discussion are presented in Section 3.1. We also discuss assumptions on the nature of the situation into which the process fits—i.e., what existing information is assumed, and what is assumed about the state of prior architecture or system definition. A brief overview of the entire process is in Section 3.2. Then, we present each of the steps in the process in sequence, with the corresponding part of the example problem, in Sections 3.3–3.9. Section 3.10 concludes the process with a summary of the UML-to-C4ISR product mapping.

3.1. Preamble to the Process Two major guidelines form the basis of our approach. The first is “top-down, breadth-first” and the second is a strong reliance on event-based interactions as a descriptive and analytic technique. These are discussed in more detail below. Top-Down, Breadth-First: The primary guideline is that the architecture specification process should follow a top-down, breadth-first scheme. “Top-down” means that the process starts by viewing the architecture as a black box, with connections or relationships to some external (out of scope) entities. Within that initial context, the architecture is then divided into its major components (“decomposed”), and then those components are further divided, and so on. The decomposition process expands geometrically with each additional level, which eventually puts a practical limit on the depth of decomposition that can be realistically handled on any project. “Breadth-first” means that the decomposition should be performed uniformly across the architecture as the depth increases—there should not be

Table I. Summary Description of UML Diagram Elements

292

BIENVENU, SHIN, AND LEVIS

any “stovepipes” of significantly deeper decomposition in any particular area of the architecture. The rationale behind this guideline is that uniform development topdown and across the breadth of the architecture is necessary to insure proper implementation of architecture and system requirements, to minimize reworkings made necessary by fixing stovepiped designs too early, and to avoid having one section of the architecture “drive” the requirements, interfaces, and behaviors of the other sections unnecessarily. Event-Based Interactions: The second guideline is that we rely strongly on event-based interactions between objects as a definition mechanism. Whether the object represents a complex system or a piece of software, the input/output events are a key method of specifying the object’s behavior. This behavior can be captured via the formalism of state charts [Harel 1987; Harel et al., 1987]. A key observation about inputs and outputs to a system can be found in Jonsson [1994] and Lynch and Tuttle [1987], where it is noted that a system has control only over its outputs—its inputs must be assumed to be under the control of the system’s environment (i.e., external to the system under consideration). The starting point for this process assumes that a system concept has already been developed. In C4ISR terminology, this would be the “Operational Concept Graphic (OV-1)” and its associated text, and the “Overview and Summary Information (AV-1).” This is the same assumed starting point as for the Structured Analysis process, presented in the companion paper [Wagenhals et al., 2000]. In some domains, very similar descriptions appear in the Concept of Operations and the Operational Requirements documents. We also assume that the architecture must be developed from scratch—that there is no pre-existing architecture specification. In practice, this is usually not the

case: there is usually some form of architecture at least for component systems. On the other hand, there have been situations where no prior architecture documentation existed for systems where an upgrade was necessary.

3.2. Process Overview The primary iterative nature of the overall process is shown in Figure 1. The primary input and output of the iterative cycles is the behavior of the system, with “as desired” as the input and “as modeled” as the output. In both cases, system behavior is expressed through the use of the UML Sequence Diagrams. Note that other techniques and methodologies also refer to the same basic diagram type by other names, such as Event Trace Diagrams [Rumbaugh et al., 1991], Message Sequence Charts [Selic, Gullekson and Ward, 1994], and possibly other names as well. The basics of the iteration loop are: • Define some behavior in terms of a Sequence Diagram. This is the “desired” behavior. This will involve object instances, not classes. • Construct new object classes (for the object instances from the preceding step) and their associated state diagrams, or modify some existing ones. • Exercise the model to produce behavior (again, in terms of a Sequence Diagram) for all Use Cases. This is the “as modeled” behavior. • Compare the “desired” to the “as modeled.” If there is a match, then proceed to a new behavior to be modeled, or proceed to the next level of object decomposition to be modeled. If the match is insufficient, the object classes and their state diagrams may need to be reengineered. Alternatively, it can happen that the “as desired” behavior

Figure 1. The overall development process is an iterative cycle, based on the desired behavior of the system.

C4ISR ARCHITECTURES. III

has been poorly specified, or needs to be redesigned. The overall process is illustrated in Figure 2. The Operational Concept can give rise to several Use Cases. For each Use Case, there is an iterative process of developing sequence, object class, and state diagrams to instantiate the desired behavior at some desired level of detail. These diagrams are then used as a starting point when incorporating the new behavior in the form of the next Use Case. For the initial Use Case, the first step is the translation of the Use Case diagram into a top-level sequence diagram, which primarily involves the sequencing of the information exchanges (messages) between the external Actors and the System (viewed as a monolithic entity). Initial object class diagrams and state diagrams can be derived at this point which will produce the desired behavior (as embodied in the Sequence Diagram). These initial diagrams represent a first iteration. Successive iterations are begun by decomposing one or more objects on the Sequence and Object Diagrams,

293

defining more elaborate (detailed) behavior on the Sequence Diagrams and implementing that behavior through modifications or additional state diagrams. These iterations continue, addressing additional levels of detail, until the Use Case requirements are satisfied. When addressing subsequent Use Cases, it may be necessary to take the behavioral definitions to additional levels of detail. The following sections discuss these steps in more detail, and present the corresponding illustrations of the example FastPass problem. It must be realized that the resulting class and state diagrams represent a union of the behavior captured though all Use Cases and Sequence diagrams. The process of integrating additional behaviors into existing sets of state diagrams can sometimes be a challenge, yet may be key in understanding how a multi-tasking system will need to be configured. On an additional note, many practitioners have criticized the UML Use Case diagram, since it seems hardly Object-Oriented at all (except for the external actors, it appears more functionally oriented than Object-Oriented). However, its value lies in properly setting the

Figure 2. The Operational Concept gives rise to several Use Cases, each of which is analyzed via a process that results in UML Sequence, Class, and State Diagrams.

294

BIENVENU, SHIN, AND LEVIS

context for the analysis that will follow, and providing a convenient view of the external message interfaces.

3.3. Step 1: Use Cases The OO process for C4ISR starts with the same information available to the Structured Analysis process— the Operational Concept and system operational descriptions. This is embodied in the Operational Concept Graphic (C4ISR AF OV-1). Starting from this initial system concept, the first step is to develop a UML Use case representing the basic system “use.” A UML Use case consists of external “Actors” and their interaction with the system. “A Use Case describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actors) with the system itself (and its key abstractions)” [Booch, Rumbaugh, and Jacobson, 1999, p. 220]. The illustrative example is the same one used in Wagenhals et al. [2000]. The description of the problem is repeated here for completeness. The Operational Concept Graphic is shown in Figure 3. The process can be described as follows. A driver pulls up in an OilCo gas station and proceeds to one of the Self-Serve fuel pumps equipped with the FastPass system. If his car is equipped with the FastPass tag, then the sensor on the pump senses its presence and reads the information on the tag. If the driver has a key-chain tag, he waves the tag in front of the sensor (1–2 in. away) and the sensor reads the information. The sensor lights up. The information read from the FastPass tag or key chain is decoded at the pump and is then sent from the pump, through the LAN at the gas station, to the FastPass Central database where the relevant credit card information is retrieved. The authorization request, along with the credit card data, is then transmitted to the financial institution issuing the credit card. If the request is approved, the fuel pump is enabled and the driver can pump gas. If the request is denied, the pump is not enabled, and the process terminates with the FastPass light going off. (Note that a simpler alternative is for the central database to maintain a current list of invalid credit card numbers, check the request against them, and issue an authorization accordingly.) If enabled, the driver selects the grade of gas he desires and pumps gas until he turns off the pump by throwing a switch. Then the cost of the sale is computed at the pump and the amount is transmitted back to the financial institution where it is entered as a charge in the driver’s corresponding credit card account. A receipt is issued at the pump. The data about the sale are entered in the electronic ledger of the gas station. The pump returns to the idle state.

Real gas stations have multiple bays, with each bay having two double-sided pumps. All bays but one are usually in the Self-Serve mode. The other one is in Full Service mode and does not include the FastPass service. For simplicity, we shall consider the operation of a single pump equipped with the FastPass system. The FastPass service is a new alternative to the traditional payment services: pay cash, pay by credit/debit card inside the station, pay by credit/debit card at the pump. As a result, the architect need not worry about the details of the electronic accounting system used by the gas station. He need only consider that these functions have been implemented and are available to be parts of the FastPass system. Given the basic Operational Concept Graphic (Fig. 3), we can represent this as the Use Case in Figure 4—the externals are illustrated as the stick figures and “the System” is represented as the ellipse. We recommend labeling the ellipse with the basic system functionality that is being exercised in this particular Use Case. (Other major system uses, or functions, should be represented as separate Use Cases.) The unidirectional lines between an Actor and the ellipse represent basic interactions between the Actor and the System (e.g., see Fig. 4: “performCreditCardGasSale”). A significant amount of the value of Use Case diagrams is in the textual descriptions that accompany the graphics. These diagrams correlate well with the “concept of operations” diagrams found in many system and architecture descriptions, as well as in the military domain.

3.4. Step 2: Sequence Diagrams Given one or more Use Cases, the next step is to convert the Use Cases into top-level Sequence Diagrams. Sequence Diagrams in UML are one of the two forms of Interaction Diagrams (Collaboration Diagrams being the other type). The two types of Interaction Diagrams are completely interchangeable and convertible from one to the other with no loss of information. Therefore, the choice of which to use is more stylistic than technical. However, the Sequence Diagram form has seen more usage in other tools and methodologies, and will be used in our approach. Readers should be aware that, if desired, Collaboration Diagrams could be used in place of Sequence Diagrams in most points in this process. Sequence Diagrams represent time-ordered sequences of events or message exchanges between entities, and, in this particular step, the entity set should be restricted to the external Actors from the Use Case and a single entity representing the entire “System.” Sequence Diagrams can have external Actors and object class instances on them, represented by vertical

C4ISR ARCHITECTURES. III

295

Figure 3. Operational Concept Graphic (C4ISR OV-1) illustrates the basic concepts of operation.

lines, labeled with the Actor or class instance on the top. The vertical lines for each entity are called “lifelines,” and time runs from the top to the bottom. Events or messages exchanged between actors/instances are shown by the horizontal unidirectional arrows (see Fig. 5). The first Sequence Diagrams should have only a single “System” instance plus the necessary external Actors on them, in order to focus attention on the top-level system interfaces to the outside world. Having constructed the Use Case, it is usually easy to determine the sequence of messages necessary to build a Sequence Diagram that embodies the Use Case. The entities on Sequence Diagrams represent instances of classes, not classes themselves. The horizontal uni-

Figure 4. An initial, top-level Use Case illustrates the relationships between the external Actors and “the System” as a monolithic entity.

296

BIENVENU, SHIN, AND LEVIS

Figure 5. The Use Case of Figure 4 can be directly transformed into a Sequence Diagram by time-ordering the interactions between the entities.

directional arrows represent Events, which can include message (data) exchanges and/or method calls (the CORBA paradigm). In general, we advise viewing Events as messages sent from one entity and received by another. If it is desired to adhere more closely to the CORBA paradigm, one can view the event as calling a method on the receiver in order to receive the desired message or data. Thus, the same result is achieved in either technique. Sequence Diagrams follow a causal pattern, in that an entity (within the System) should not be generating events without causal stimuli. Figure 6 illustrates the meanings of “causal” and “noncausal” as used in this paper. The two exceptions to the “causality” rule are (1) external Actors (being external and therefore of arbitrary behavior) are allowed to generate arbitrary events

at arbitrary times (a characteristic that can be used to examine error handling and interrupt capabilities within the System) and (2) the System and components within the System may employ internal timers that, when activated, can generate events for reception by system objects. One top-level Sequence Diagram should be constructed for each Use Case, and in each case, the entire “System” should be simply represented as a single entity on the Sequence Diagram. Sequence diagrams are themselves C4ISR AF products, specifically, OV-6c—Operational Event/Trace Descriptions—and SV-10c—Systems Event/Trace Descriptions—depending on the set of objects being represented.

Figure 6. The sequence on the left is “noncausal” in that events are not necessarily being generated in a stimulus-response (causal) manner. The right-hand side sequence adheres strictly to the causality rules.

C4ISR ARCHITECTURES. III

3.4.1. Step 2a: Extracting Information Object Classes The next step is to extract the initial System View or Operational View Information objects from the Sequence Diagrams just created. The events on the Sequence Diagram that represent events or information can be used directly to create the initial (information) object classes. These will be on the object class hierarchy. The initial object classes are shown in Figure 7. An initial set of associations can be created between information object classes based on the Sequence Diagram by viewing the events in terms of stimulus–response pairs, and adding an association between each stimulus and corresponding response. Note that, in many situations, the response to the first stimulus will also serve as the second stimulus, so that the causality chain can be followed through the object class diagram (although the class diagram associations are nondirectional). The associations between the classes are developed partially by inspection of the Sequence Diagram (inputs/outputs are usually related by an association), but also by taking into account the operational concept of the system. Thus, the CreditCharge object is somewhat central, and “spawns” several other classes.

297

The resulting UML object class diagram showing the information objects (events/messages) is the beginning of the C4ISR Logical Data Model (OV-7) product. As additional sequence diagrams are developed, the class diagram will be revised and expanded. When the class diagram is complete, it can serve as the Logical Data Model with no further changes or modifications (i.e., no additional changes are required for a UML class diagram to satisfy the requirements of the OV-7 product). 3.4.2. A Note On the Use of Object Classes Object classes can be used to represent both information nodes (types of data) as well as physical nodes (command centers). Associations (relationships between classes) can be of different types, depending on the kinds of things represented by the object classes. When the objects are data classes (information), then the relationships represent data transfer, signals, or operation invocations. When the objects are large physical nodes, the associations can represent physical communications links. What we see is that there are two parallel sets of possible object associations that can be devel-

Figure 7. The object classes are extracted directly from the Events on the initial, top-level Sequence Diagram, and will be modified later in the process.

298

BIENVENU, SHIN, AND LEVIS

oped—one focusing on the data objects in the system and their transformations, and one focusing on the physical components (centers, computers, etc.) and the interconnecting communications. In terms of mapping the object classes and their associations to physical systems and the information messages, one successful technique is to draw associations between classes such that, when following the association lines, one has the sequence “system–message–system.” This technique emphasizes the message object classes as the interfaces between the system object classes. An alternative technique is to use the UML construct “Link Attribute,” which allows a class definition to be applied to a relationship. Thus, the type of interface becomes a class, and the message types carried by that interface can be represented as components (using aggregation) of that interface. 3.4.3. Step 2b: Augmenting the Sequence Diagram One more operation can be performed with the Sequence Diagrams as they exist at this point, and that is to begin derivation of the functional hierarchy (decomposition). The ellipse on the original Use Case was labeled with a function-type name (a verb/action phrase). We return to the Sequence Diagrams and look

at the System lifeline. Between receipt by the System of its first Event, and generation of its first output Event, the System must perform some sort of action or function. Although not supported by UML, we recommend adding functional names to the lifelines at this point in the process in between the input and output Events. By viewing the object, the stimulus and the response, it is usually fairly straightforward to conceive of the function necessary to achieve the desired output based on the input. For example, Figure 8 shows a portion of the Sequence Diagram, and an activity model (IDEF0-like) representation of the function, with input, output, and mechanism lines shown. By adding functions all along the System object’s lifeline (note that it is not important to define functions along the Actors’ lifelines, since they are external to the system and therefore out of scope), one has basically defined the subfunctions that together achieve the higher level function which was named on the Use Case—in other words, the top-level function has been decomposed via this Sequence Diagram-based technique. An annotated Sequence Diagram and the resulting functional hierarchy are shown in Figure 9. The modified sequence diagram is referred to as an Augmented Sequence Diagram (ASD).

Figure 8. A functional context diagram can be developed based on the top-level sequence diagram.

C4ISR ARCHITECTURES. III

299

Figure 9. The top-level sequence diagram for “As Is” architecture augmented with the major system function names.

A key analytical question must be asked here: Given an activity or function, are the inputs shown sufficient to “activate” or satisfy the function? If not, then the missing data flows (and events on the Sequence Diagrams) must be added to the architecture model. Initialization data, such as is used to “fill” databases at the beginning of a system’s operation, are often overlooked, but should be included, as well as updates to that data. Since the activity (the ellipse) on the top-level Use Case diagram was labeled with a function name, it follows that the functions used to augment the Sequence Diagram in Figure 8 are in fact the subfunctions of the Use Case activity. The functional hierarchy constructed from the system object sequence diagrams will serve as the C4ISR Activity Diagram (OV-5). The functional hierarchy (and the Activity Diagram) will gain additional leaf nodes with each iteration of object decomposition, so it will not be “complete” until the object decomposition

process is halted. Note that we have essentially constructed the UML Activity Diagram here. The point we wish to stress is that the functional hierarchy was constructed by derivation from the sequence diagrams and not by an independent inspection of the system alone.

3.5. Step 3: Object Decomposition The process will proceed from this point by decomposing “the System” entity into its major components. As the process proceeds, we will develop essentially two sets of interrelated object classes—one set roughly corresponding to the Operational View from Structured Analysis, the other set roughly corresponding to the System View. This can be easily done via the UML class diagram, and is illustrated in Figure 10 for the FastPass system (remember that we are still focusing on the legacy system before the introduction of FastPass). The figure shows that the OilCoSystem class is made up of two major components: a single OilCoHQ and many OilCoStations. This step can be iterated on either of the

300

BIENVENU, SHIN, AND LEVIS

Figure 10. The OilCo System is composed in the System View of numerous OilCo stations and one headquarters, and simultaneously in the Operational View a GasDispensingSystem and a FinancialSystem.

been achieved because two different objects perform parts of A1. At this point, the decomposition process has been carried out to one level. If a sufficient level of detail has been reached, then construction of the state diagrams for the object classes can begin; otherwise, another level of decomposition should be developed. The process is clearly an iterative one. The last Sequence Diagram for the legacy or “As Is” system is presented in Figure 13. This diagram incorporates another level of component decomposition and is also augmented with the function names.

3.6. Step 4: State Diagrams new component objects to get the next level down, and iterated to whatever depth of object decomposition is desired or needed. The two components of the OilCoSystem—OilCoStation and OilCoHQ—can also be substituted for OilCoSystem in the Sequence Diagram (Fig. 5) as well. The events that previously passed between the actors and OilCoSystem should now be connected to either OilCoHQ or OilCoStation.1 New events may also be added between the OilCoStation and OilCoHQ—note that these events would not be visible on the top-level Sequence Diagram (Fig. 5), since these are completely internal events. When modifying the preexisting events and adding the new events, causality should again be observed, and functions can be added to the new object lifelines, which leads to the Augmented Sequence Diagram shown in Figure 11. By comparing the ASDs of Figures 9 and 11, it can be seen that the top-level functions (Fig. 9) have been replaced by the functional decomposition of Figure 11. Translating this information to a more standard functional hierarchy results in Figure 12. Note, however, that only function A1 has been decomposed because only this function was distributed between the new objects (OilCoStation and OilCoHQ) that were introduced into the Sequence Diagram. Function A2 is performed entirely by the OilCoStation, and function A3 is performed solely by OilCoHQ. Therefore, in introducing those two new objects in place of OilCoSystem, and being unable (at this point) to see “inside” of either of those objects, we still have no information about the decomposition of A2 and A3. Increased visibility into A1 (in the form of knowledge of its subfunctions) has 1 There are situations where a message is “broadcast” to multiple recipients (for example, via radio broadcast or network mechanisms), but the analyst should assure that broadcast constructs are not unintentionally introduced.

State diagrams in UML are based strongly on Harel Statecharts [Harel, 1987; Harel et al., 1987], and have also been used in a variety of other object oriented methodologies such as Booch [1991], OMT [Rumbaugh et al., 1991], and ROOM [Selic, Gullekson, and Ward, 1991], as well as in Structured Analysis. State diagrams will need to be developed for all object classes that have behavior. Behavior, in the context of this paper, means the pattern of stimulus-response that instances of a class must exhibit. A key feature of the process presented here is that a class’s behavior will be determined by analysis of the desired system behavior, as expressed in sequence diagrams. State charts will be constructed so that an object will properly respond to the stimuli as denoted on the sequence diagrams. Note that in Object-Oriented approaches, as well as Structured Analysis ones, behavior can be unambiguously specified via the state chart mechanism. In Object-Oriented realms, state diagrams or charts are defined for individual object classes, and each instance of a class will get a copy of that state diagram (as a state machine). Each instance of a particular class will utilize its state machine independently from all other instances of that class. State diagrams will need to be developed for all system object classes that have instances on one or more Sequence Diagrams. The process of developing a state diagram for a given class begins with the augmented Sequence Diagrams. The object with the most complex behavior (based solely on the number of input/output events) in Figure 13 is the pump, so the example will develop the state diagram for the Pump object class. Extracting the pump object lifeline and all associated input/output events from the Sequence Diagram yields Figure 14, and this is the starting information for the Pump class state diagram. Any extracted lifeline will have a number of input and output events tied to it. The general rules for con-

C4ISR ARCHITECTURES. III

301

Figure 11. The ASD after decomposition of the OilCoSystem object and augmentation with function names. Key to functions: (A1) approveCreditSale; (A2) manageSale; (A3) handleBilling.

verting this sequence of events to a state diagram are as follows. Input events will become associated with a transition leaving some state. The input event will be the triggering event that causes the transition to fire. Therefore, the lifeline can be further annotated by adding the name of the object’s state just prior to the triggering event. This technique is not supported by UML, but has been implemented by other methodologies and tools, and may be supported in the new real-time subset of UML (UML-R/T).

Figure 12. The functional decomposition is derived from Figures 5, 9, and 11.

Output events are generated by some action (i.e., method, operation, function) taken by the object. As per the Harel statechart rules, actions can be associated with a transition, or with entering or exiting a state (via some transition) [Harel, 1987; Selic, Gullekson, and Ward, 1994]. Entry and exit code, as it is called, can be useful in some behaviorally complex situations, but will not be addressed in this paper. The discussion can be limited to a restricted subset where actions are assumed to be associated only with transitions without loss of generality. Even in software development practice, one could implement systems with this restriction and only incur a penalty of some redundant coding. The lifeline should be examined for cyclic patterns. Not all objects will have cyclic patterns. Often, datatype objects (information objects) will have transient existence, and these can often be implemented with no cycles in their state behavior diagrams. On the other hand, many objects will exhibit cycles in their state diagrams, since they will be expected to perform the same task over and over again. If cyclic patterns do exist, then the number of states in the cycle can be determined by counting the number of input events in the cyclic pattern from the Sequence Diagram. Note that there is an initialization transition and a “ready” state also in the state machine. We recommend beginning all state diagrams with these constructs—they represent the activities necessary to bring

302

BIENVENU, SHIN, AND LEVIS

Figure 13. The ASD after another level of component substitution.

the object to an operational state at the beginning of its existence. Initialization processing is often key in software-intensive systems, but it is also very useful to explicitly recognize this kind of start-up operation when dealing with larger scale hardware/software systems as well. For example, OilCo command centers can have an extensive setup procedure that must be executed before the center is up and ready to process data, as well as shut-down procedures that must be done in order to prepare to pack up and move again. Attention to the transient behavior of objects is often overlooked, and yet is often critical. Figure 15 illustrates the set of states that compose the state cycle for the Pump class. The initial state is used as the “ready” state, where an object waits to start

its next cycle of operation. The input events become the triggers for the corresponding transitions, and the class methods (functions) that were used to augment the Sequence Diagrams will be implemented within the appropriate transition. Table II summarizes the input events, transitions fired, states exited and then entered, and output events generated for the Pump state diagram. The UML State diagrams for the object classes directly comprise the C4ISR Products Operational State Transition Description (OV-6b) and Systems State Transition Description (SV-10b), again, depending on whether the object classes are from the operational or system side. The related C4ISR products, Operational Rules Model (OV-6a) and Systems Rules Model (SV10a), can be derived directly from the state diagrams.

C4ISR ARCHITECTURES. III

303

3.7. Step 5: Message-Interface Mapping A second version of the system object class diagram can be constructed, with the specific intent of using the UML association construct to indicate physical interfaces, and this is shown in Figure 16. Another useful UML construct used here is the “link attribute” (also known as the “association as a class”), and this construct is used to indicate that the associations between the system objects (such as Pump and GasStationOffice) are actually classes (of interfaces) in their own right. Thus, the Pump–GasStationOffice interface is the LAN object. Given the class structure of Figure 16, and the full sequence diagram of Figure 13, all of the information is available to correlate events and messages against system interfaces, and this is done in Figure 17. This figure is not a UML-standard diagram; it has been created explicitly to display information required by the C4ISR AF. We call it a Message-Interface Mapping Diagram, or Message-Interface Map. Such correlations are critical in order to support systems analyses that include communications bandwidth requirements, or user-interface/human factors issues.

Figure 14. Extracting the Pump object from the system sequence diagram allows us to focus on its behavior.

Figure 15. A state diagram which would produce the behavior specified by the sequence diagram of Figure 14. Note that this does not represent the only solution. The syntax for the transition labels is / ^ .

304

BIENVENU, SHIN, AND LEVIS

Table II. Correlation of Sequence Diagram Events to State Diagram Transitions

3.8. Step 6: Class Diagrams for System Evolution As stated earlier, one of the major motivations for constructing architectures is to handle the problems inherent in an evolving system. In this section, we demonstrate a feasible technique for handling a timephased system design using UML diagrams. The technique is based on the use of class diagrams, and the proper structuring of subclasses (specialization/generalization). We rely also on whether an object class is instantiable. High-level classes (parent or superclasses) are, by definition, more abstract than their children (subclasses), and define the common characteristics of those children. As such, one cannot instantiate (make a concrete example of) a high level abstract class. Note that there will be occasions where a parent class is instantiable. For example, we could have one class for a generic F-16 aircraft, and subclasses for specialized F-16s. One could instantiate any of these classes, parent or child. On the other hand, a class for “Human” (with subclasses “FemaleHuman” and

“MaleHuman”) is not instantiable—only the subclasses can be made real, since any human must be one or the other (the subclasses are mutually exclusive and together completely span the set “Human”). The strategy for using the instantiable subclasses is to identify/create a set of subclasses (or possibly several sets of subclasses under different parents) such that there is a subclass for each phase of the system. We create families of classes, where each family has a single parent and a child for each system phase. To apply this strategy to the current OilCo system example, we return to the Operational Concept, the top-level Use Case, and the associated top-level Sequence Diagram. From a system and External viewpoint, the only event difference is that the Customer presents a FastPassID instead of a CreditCard. The interface between the OilCoSystem and the FinancialInstitution does not change—the FastPassID has no meaning to the bank. Now, examine the next level of detail, bringing the new Customer-OilCo interface into the picture. The legacy sequence diagram is modified to handle the FastPass operations concept, and Figure

Figure 16. The UML class diagram can be used to delineate physical interfaces between the major system components. Interface classes are indicated with bold names.

C4ISR ARCHITECTURES. III

305

Figure 17. Message-Interface Mapping Diagram for the example system allows correlation of low-level message events to physical system interfaces.

18 results (after functional augmentation). We see that there are new functions and new messages added at the beginning of the overall process, but after the Authori-

zation event (creditDB to stationOffice), the sequence is the same.

Figure 18. The sequence diagram for the Phase II (FastPass) system differs from the Phase I system (Fig. 13) in only some details. The remainder of the sequence (not shown) is identical to the Phase I sequence.

306

BIENVENU, SHIN, AND LEVIS

Figure 19. Phase II Object classes use subclassing to implement different deployment configurations.

What factors determine whether an object class needs to be refined into Phase-specific subclasses? When one or more of the following conditions is met2

class, but only the OilCoHQ_Ph2 has the functionality necessary to maintain a FastPassDB.

3.9. Step 7: Architecture Model Validation • Interfaces added/deleted to an object (class) • Messages added/deleted to an interface of an object class • Changes in an object’s response to a given stimulus • Changes in the allowed ranges for an object class’s attributes. In our example, the object classes that satisfy these conditions are: Pump, StationOffice, and OilCoHQ. This results in a set of subclasses, built upon the original object classes that appear in Figure 19. So, the “To Be” architecture is distinguished from the “As Is” architecture in that certain positions within the structure are filled by different versions (subclasses) of a higher-level class, and the operations are represented by different sets of sequence diagrams. Within the new object classes, behavior may be governed by new state diagrams, and information may flow along new interfaces, or new messages may flow along old interfaces. The left side of Figure 19 captures the basic relationships of the “As Is” and “To Be” architectures (before and after Fastpass). The diagram indicates that both the architectures are “kinds of” OilCoSystems. Each is composed of many (*) OilCoStations and one headquarters object (OilCoHQ), although different subclasses of headquarters. The right part of the diagram shows how the different subclasses of OilCoHQs are related—both inherit a CreditDB from their parent 2 Note that simply adding an attribute or operation to a class or deleting from it, while technically requiring the definition of a new subclass, is basically meaningless if none of the above conditions is also satisfied. Conversely, any of the four conditions will probably require addition/deletion of either attributes, operations or state behavior (states/transitions).

After completing an iteration through the preceding steps, it can be useful, and possibly even crucial, to validate the work done up to this point. Many architecture models may have a large number of object classes in them, and the lowest level (leaf) classes should have their own state diagrams as well. Evaluating the correctness of such a large model can be exceedingly labor-intensive if not supported by some sort of computer-aided process. Luckily, since OO techniques are primarily in the realm of software engineering, there are a number of tools that can take a complete model and, in essence, directly construct an executable model (or, in computer terms, an executable file). Given models of any significant complexity, the power of automated execution becomes invaluable in assuring that the different portions of the model are in fact consistent. It must be stressed that an executable model is not required by the C4ISR Architecture Framework document. However, it is our strong conviction that, whether using Structured Analysis or Object-Oriented techniques, an executable model should be constructed, preferably in an automated manner, from the architecture model, and that the overall model integrity and internal consistency will be difficult, if not impossible, to verify reliably without the construction and exercise of the executable version. Current CASE tools often include a set of consistency rules for checking the syntactic correctness of the diagrams, a property also referred to as concordance. However, there are usually practical limits to the scope of these rules in that it is impractical to embed in static rules the desired behavioral sequences. Additionally, when there are hundreds of object classes, each with its own state diagrams, and multiple instances of those

C4ISR ARCHITECTURES. III

classes, the task of tracking behavior through the state diagrams either via static rules or manually becomes untenable very quickly. Also, given a large set of object instance state diagrams with complex interactions, it is difficult if not impossible to detect race and/or deadlock conditions via purely static rules checking. An executable version of the model can solve this problem by exercising the object interactions and their state diagrams in a rigorous, accurate and automated fashion. While syntax rules will catch semantic errors, the executable will catch design errors—errors in designing the ensemble behavior of the individual object classes. The ensemble, or composite, behavior of the collected objects can be syntactically correct, yet not properly reflect the desires or needs of the originating organization. In summary, in order to determine whether a model of an architecture instantiates the appropriate and desired behavior, an executable version of the model is advisable because: 1. Only through execution can the instantiated behavior of a complex model be efficiently determined (as opposed to the desired or required behavior). 2. Only through analysis of the instantiated behavior can it be determined whether the instantiated behavior is appropriate. The first reason is due to the complexity of a large model, while the second requires the analysis of the model by the architects in conjunction with the operators (i.e., the users or customers). These reasons are the primary motivation behind the development of the behavioral iteration process as illustrated in Figure 1. From the preceding discussion, it is apparent that a key requirement on the executable version of the model is that it accurately reflect the structure and behavior of the architecture, and this has strong implications for the process of developing the executable version. Specifically, the accuracy depends strongly on the executable’s development process, and it is for this reason that an automated process is strongly recommended. Any process that involves a manual translation of architecture model elements into executable elements adds a degree of configuration risk which can lead to a disconnect between the architecture and executable contents. An automated process also means that all of the information necessary to construct the executable must be present in the architecture models themselves. These issues can also be viewed as traceability issues, but also touch on the area of configuration management. When there is no automatic linkage between the architecture model and the executable version, one

307

can find that the executable (or the simulation or prototype) begins to take on its own life, and is modified and enhanced on its own, independently of the originating architecture model. In time, one finds that the architecture model is left behind, and falls into disuse as it no longer represents the most up-to-date version of the system. In addition, the cycle of executable construction, evaluation, and model modification should be rapid enough to support an iterative cycle. The process outlined above, and the executable version of the architecture, can be used in an iterative prototyping cycle that closely follows Figure 1. The use of the executable model in an iterative fashion with user/customer involvement within the systems definition process has been discussed in more detail previously [Bienvenu and Daniel, 1996]. In summary, the process involves iterative building and refinement of the architecture model, with the executable behavior (usually in the form of the Sequence Diagrams) as the feedback mechanism between the architecture/executable builders and the user/customers. The key concept here is to avoid swamping the user/customers with numerous diagrams of classes or states (or, in Structured Analysis, functional decompositions and entity relationships), but rather, to condense down the architecture model into a more straightforward description of the architecture’s behavior.

4. PROCESS SUMMARY: UML-C4ISR MAP This section summarizes how the C4ISR products are derived from the UML diagrams and entities. These derivations occur incrementally throughout the process, and the overall map is illustrated in Figure 20. The central role of the UML Sequence Diagrams is evident in this view, as many other UML diagram types and C4ISR products derive in some fashion from the Sequence Diagram. The AV, OV, and SV products are defined in the Appendix and are described more fully in Levis and Wagenhals [2000]. The overall process is summarized below: Step 1: Create the top-level overview descriptions. Domain knowledge is used to create the top-level overview descriptions, AV-1 (Overview and Summary Information) and OV-1 (High-level Operational Concept Graphic). Step 2: Develop the UML Architecture Description. This is an iterative process, iterating over all the Use Cases, creating Sequence and Augmented Sequence Diagrams, and integrating the informa-

308

BIENVENU, SHIN, AND LEVIS

Figure 20. The overall derivation process shows the notional flow of C4ISR products from the UML diagram types.

tion from all of these into a common set of class diagrams and state diagrams for those classes. Step 3: Derive C4ISR Products from the UML Architecture Description. Tables IIIa, IIIb, and IIIc illustrate which portion of the UML Architecture Description is the source for the various C4ISR products. Note that some of the C4ISR products cannot be derived from the UML description. Note that the two Technical View products have not been mentioned here. We have not yet addressed these products in our research. These products have to do with the technologies supporting the actual instances of the object classes involved in the architecture. These issues are usually not covered in an object-oriented analysis, and technology forecasts (the subject of TV-2) would likely be based almost completely on domain knowledge. This makes the TV products difficult to develop accurately, regardless of the overall approach adopted. The construction and validation of the Object-Oriented model is “contained” within the behavior-based iterations shown in Figure 1. The derivation of the C4ISR products should be withheld until the basic

Figure 1 iterations are complete, or at least, have reached a desired degree of stability or a project milestone.

5. CONCLUSIONS A process for developing architecture descriptions via an Object-Oriented approach has been presented. It was shown that these descriptions contain the information necessary to generate the products required by the C4ISR Architecture Framework. Using the Unified Modeling Language, an Object-Oriented description can be constructed in a top-down fashion via the process outlined here, and products satisfying the C4ISR AF can be generated as well. The purpose is to demonstrate the feasibility of using Object-Oriented languages to generate a C4ISR-compatible architecture description, and the process here satisfies that goal. This is not the sole solution to this problem, merely one in a potentially large solution space, but it does serve as proof of feasibility, and can be offered as a guide to others seeking to

Table IIIa. UML Information Sources for All View (AV) C4ISR Products

C4ISR ARCHITECTURES. III

Table IIIb. UML Information Sources for Operational View (OV) C4ISR Products

Table IIIc. UML Information Sources for System View (SV) C4ISR Products

309

310

BIENVENU, SHIN, AND LEVIS

Table AI. All View Products

either develop their own process or tailor a pre-existing one to their own needs. The process was demonstrated via an example, and results show that all C4ISR products that could be generated via the Structured Analysis can also be generated via the Object-Oriented approach. Current work is addressing the question of derivation of the Petri Net executable models that meets specific user needs in the C4ISR domain and developing an associated architecture quality evaluation process.

APPENDIX

low in Tables AI, AII, and AIII. For a description, see C4ISR [1997] or Levis and Wagenhals [2000].

ACKNOWLEDGMENTS The authors gratefully acknowledge the contributions of Daesik Kim and Mengtao Tao on object orientation and its relationship to Petri Nets. We also thank the reviewers, who contributed very useful and challenging comments. And finally, thanks go to Rational Corporation for providing the Rational Rose 98 Enterprise Edition software tool and to the University of Aarhus for the Design/CPN Petri Net tool.

The architecture products defined in the C4ISR Architecture Framework document, Version 2, are listed be-

Table AII. Operational Architecture View Products

C4ISR ARCHITECTURES. III

311

Table AIII. System Architecture View Products

REFERENCES M.P. Bienvenu and C.H. Daniel, BMD-NA BM/C3 Information Architecture Executable Representation, Proc 1996 Summer Comput Simulation Conf, July 21–25 1996, Society for Computer Simulation, Portland, OR, pp. 295– 300. G. Booch, Object oriented design with applications, Benjamin/Cummings, Redwood City, CA, 1991. G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language user guide, Addison Wesley, Reading, Massachusetts, 1999. C4ISR Architecture Working Group, C4ISR Architecture Fr amework, Version 2.0, December 18, 1997 http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/ index.htm D.G. Firesmith, Object-oriented requirements analysis and logical design, Wiley, New York, 1993. D. Harel, Statecharts: A visual formalism for complex systems, Sci Comput Program 8 (July 1987), 231–274. D. Harel, A. Pnueli, J.P. Schmidt, and R. Sherman, On the formal semantics of statecharts, Proc Second IEEE Symp Logic Comput Sci, Dorset House, New York, 1987, pp. 54–64.

B. Jonsson, Composition specification and verification of distributed systems, ACM Trans Program Lang Syst 16(2) (March 1994), pp. 259–303 A.H. Levis and L.W. Wagenhals, 4ISR architectures. I: Developing a process for architecture design, Syst Eng 3, 225–247 (2000). N.A. Lynch and M.R. Tuttle, Hierarchical correctness proofs for distributed algorithms, Proc Sixth Annu ACM Symp Principles Distributed Comput, 1987, Vancouver, Canada, pp. 137–151. T. Quatrani, Visual modeling with rational rose and UML, Addison-Wesley, Reading, MA, 1998. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-oriented modeling and design, Prentice Hall, Englewood Cliffs, NJ, 1991. B. Selic, G. Gullekson, and P.T. Ward, Real-time object-oriented modeling, Wiley, New York, 1994. UML 99, OMG (Object Management Group) Unified Modeling Language Specification, Version 1.3, Rational Software Corp., Copertino, CA, June 1999 [www.rational.com/uml/index.jtmpl]. L.W. Wagenhals, I. Shin, D. Kim, and A.H. Levis, C4ISR architectures. II: Structured Analysis approach for architecture design, Syst Eng 3, 248–287 (2000).

312

BIENVENU, SHIN, AND LEVIS

Michael P. Bienvenu is a Visiting Research Scientist with the System Architectures Laboratory of the C31 Center. He joined the Center in August of 1999. He was educated at William Marsh Rice University in Houston, TX, where he received the B.A. (1976), M.E.E. (1977), M.S. (1979), and Ph.D. (198 1) degrees in Electrical Engineering, specializing in solid-state physics and non-linear optics. He was with the System Planning Corporation from 1981 to 1985, working on simulations, probability analyses and commandrnd control problems. From 1985 to 1999 he was with SPARTA, Inc., where he specialized object-oriented systems analysis and design, primarily for large-scale, distributed systems. He worked extensively in battle management, command, control, and communications analysis and simulation for national and theater missile defense systems. Dr. Bienvenu is a member of the System Dynamics Society and the IEEE. Dr. Bienvenu’s research interests include complex system dynamics, distributed intelligent systems, objectoriented software methodologies, and large-scale system and software development processes.

Insub Shin is a Ph.D. student in the doctoral program in Information Technology at George Mason University. He is currently conducting research at the System Architectures Laboratory in the Center of Excellence in Command, Control, Communications, and Intelligence. His education includes B.S. in Mechanical Engineering from the Korea Military Academy (1985) and an M.S. in Telecommunications System Management from the US Naval Postgraduate School (1990). He has over 10 years of experience with the Korean Army as a signal officer. He has taught information and communications technology in the Korean Army Signal School (1992-1994) and participated in the development of tactical C3 systems. His research interests include the design and evaluation of C3 information system architectures, modeling command and staff organizations for the infon-nation warfare era, and systems integration.

Alexander H. Levis is University Professor of Electrical, Computer, and Systems Engineering. He is associated with the C31 Center, where he heads the System Architectures Laboratory. He served as Chair of the Systems Engineering Department in 1992-1994, and then again in 1996-1997. He was educated at MIT where he received the B.S. (1965), M.S. (1965), M.E. (1967), and Sc.D. (1968) degrees in Mechanical Engineering with control systems as his area of specialization. He also attended Ripon College where he received the A.B. degree (1963) in Mathematics and Physics. He taught systems and control theory at the Polytechnic Institute of Brooklyn from 1968 to 1973 and, for the following six years, he was with Systems Control, Inc. of Palo Alto, CA, where he was manager of the systems research department. From 1979 to 1990 he was a Senior Research Scientist at the MIT Laboratory for Information and Decision Systems. He joined George Mason University and the C31 Center in 1990. In 1992, he received the Distinguished Faculty award. Dr. Levis is a Fellow of the Institute of Electrical and Electronic Engineers (IEEE) and past president of the IEEE Control Systems Society from which he received in 1987 the Distinguished Member award. He is also a Fellow of the American Association for the Advancement of Science (AAAS), a member of AFCEA, and a senior member of AIAA. Dr. Levis’ research interests for the last fifteen years include architectures for command and control, organization theory and design, human decision making, and distributed intelligence systems. He has published more than 130 papers and many book chapters and has co-edited three volumes on The Science of Command and Control published by AFCEA.