Pilot application of the Object Oriented System Engineering Method (OOSEM) using Rational Rose Real Time(RRT) to the Navy Common Command

and Decision (CC&D) Program Rick Steiner, Raytheon Naval & Maritime Integrated Systems

Sanford Friedenthal, Lockheed Martin Management & Data SystemsJerry Oesterheld, Naval Surface Warfare Center, Dahlgren Division

Gautam Thaker, Lockheed Martin Advanced Technology Laboratory

Abstract. The introduction of an object oriented systems engineering method and tool was assessed during a short duration pilot project on the Navy's Common Command and Decision (CC&D) program. The pilot determined that the method/tool offers significant benefit for specifying and designing a complex command and control system relative to traditional approaches. This paper describes the pilot approach, summarizes the object oriented methodology and tool evaluated, and presents some of the significant findings.

INTRODUCTIONThe Common Command & Decision (CC&D)

program is intended to provide a common, maintainable set of software elements across the two currently deployed major Naval surface combat systems, Aegis and Ship Self Defense System Mark 2 (SSDS Mk 2). The CC&D program is managed by NAVSEA PMS468, and includes representation from Lockheed Martin (Aegis), Raytheon (SSDS Mk 2), DSR, and Naval Surface Warfare Center Dahlgren Division (NSWC DD).

Toward the goal of maintainability and cycle time reduction for insertion of new technology, an object oriented (OO) approach toward system and software engineering is preferred.

Rational Rose Real Time (RRT) was selected early in the program as a standard OO software development tool. The value of using a common tool for both system engineering and software on a software intensive program cannot be overlooked. A pilot to evaluate the usefulness of this tool was suggested because of the lack of precedent in using it for systems engineering. Thorough evaluation demanded the selection of a credible OO systems engineering process. The C4ISR Architecting process from George Mason University (Levis, Bienvenu, Shin ‘00) unfortunately proved to contain insufficient detail to assure success. The OOSEM approach (Friedenthal, et al ‘00a) seemed

much more complete, and was adopted for the pilot.

PILOT APPROACHObjectives: The overriding objective of the pilot

was to assess applicability of OOSEM and Rational Rose Real Time (RRT) tool suite for application to CC&D program. This included 1) assessment of requirements traceability from needs analysis through allocated system design and verification, 2) ability to capture essential system requirements and design information, 3) ability to integrate system level with software level OO development, and 4) ability to scale the tool and method to accommodate program complexity. Another key objective of the pilot was to evaluate the tool/method’s ability to achieve design integrity of a distributed real time system.

The pilot did not address technical management, configuration management, tool deployment, or document generation issues. The principal focus was on capturing and organizing the intellectual artifacts of the systems engineering process.

Schedule: The program had a strong desire to drive to a conclusion as quickly as possible, and at minimum cost. This desire was balanced against the need to develop full set of OOSEM artifacts in order to evaluate the tool/method. The program management settled on a pilot activity of 4-week duration, which was conducted on non-consecutive weeks. An additional two weeks was incurred after the pilot to compile conclusions and recommendations, and to draft the final report. During the pilot, the team was co-located, but the location rotated from week to week to minimize each individual’s overall travel time. The pilot team utilized portable facilities (laptops, projectors, static self-sticking “whiteboard paper”). Management of the technical scope was a key issue during the pilot. The domain experts quickly decided to limit the technical scope of the pilot to address a limited system capability: “establishment and maintenance of the tactical picture across the battleforce”. This scope was broad enough

to expose the distributed, real time nature of the CC&D problem domain, yet with a few assumptions could be limited enough to allow timely completion of the pilot.

The short schedule of the pilot forced a very fast tempo. A minimal set of OOSEM artifacts was determined; each was alloted a set amount of time, and a daily agenda was established. This did provide for positive short-term milestones, but it did not allow for much depth in exploring technical issues.

Team Composition: The pilot team consisted of 8 participants: three Raytheon systems engineers, three Lockheed Martin systems engineers, one NSWC systems engineer, one OSEC systems engineer. Of these, one served as pilot leader/architect, one as facilitator/methodologist, two as domain experts, one as real time development/OO expert, and three as modelers/tool experts. This mix provided a broad base of domain, systems engineering and software development talent. The facilitator/methodologist became a pivotal member of the team, because he was able to keep the individual artifacts being developed in perspective, and think ahead to the next artifact. The following team members participated.Name Company RoleRick Steiner Raytheon Leader/architectSandy Friedenthal

Lockheed Martin

Methodologist/ facilitator

Jerry Oesterheld

NAVSEANSWCDD

Domain specialist

Jim Gaston OSEC Domain specialist

Gautam Thaker Lockheed Martin

RT and OO specialist

Bob Cantrell Raytheon System modelerMatthew Jones Lockheed

MartinTool specialist

Adrienne Miller Raytheon Tool SpecialistTable 1: OOSEM Pilot Team Composition

In addition to these pilot team members, Rational provided telephone access to senior support staff familiar with RRT.

OVERVIEW METHOD AND TOOLOOSEM Overview: Lockheed Martin developed

OOSEM in conjunction with the Software Productivity Consortium (SPC). The reader is referred to previous publications for an overview of OOSEM (Friedenthal, et al, ‘00a) and detailed tutorial (Friedenthal, et al, ‘00b).

As seen in Figure 1, the pilot project was intended to address the systems engineering process, as separate from the software development and system integration processes.

Figure 1: SE process contextAs seen in Figure 2, the 6 basic steps of OOSEM

(Friedenthal, et al ’00b) were divided into three stages during the pilot: “Black Box” specification (1. Analyze Needs, 2. System Requirements), “White Box” architecture development (3. Logical Architecture, 4. Allocated Architecture), and “Refinement” (5. Test & Validation, 6. Analysis & Optimization). The pilot concentrated on developing a complete set of artifacts for “black box” and “white box” stages, with only cursory investigation of the “refinement” stage.

Figure 2: Three stages of OOSEM for pilotThe Black Box stage of OOSEM concentrated on

development of a credible system requirements model. Artifacts created in this stage included the Elaborated Context Diagram, context level Use Case scenarios, context level Interface Definition Table, context level Event Matrix, Event Activation Matrices, and the context level State Transition Diagram. This stage concluded with development of the context level Executable Model. Examples of some of these artifacts as captured in RRT will be discussed later.

The White Box stage of OOSEM concentrated on development of logical and allocated architecture. Artifacts created in this stage included Logical Decomposition, Logical data model, Logical Scenarios,

Logical Events & STDs, Logical Executable Model, Multi-layer Architecture, Hardware Architecture, and Data Architecture. Specialty Architecture and Deployment Architecture would also have been developed in this stage, if time allowed.

RRT Overview: Rational Rose Real Time(RRT) borrows OOA methods from Rational Rose 98 (R98) and OOD methods from ObjecTime. The OOA portion at first glance seems identical to R98, consisting of Use Case and Logical “views”, or directories, each of which have unique restrictions of which diagrams are supported. For OOD, RRT uses “capsules” vice classes to characterize system. A capsule is a special type of class with ports and embedded state machine capabilities to support code generation. A “package” feature is provided to allow the user to develop more detailed directory structures. RRT requires the user to establish ports, protocols, signals, & data types to characterize interfaces. Strong interface typing and control is provided. The model is further refined when the user develops state charts and inserts C++/Java routines/operation definition where appropriate. RRT can then compile and execute the specified system model, animate the state charts, allow the user to inject signals, and generate trace diagrams similar in form to Sequence Diagrams.

OOSEM had previously only been used with R98, a tool that is fundamentally different from RRT. R98 (and it’s successor, Rose 2000 (R2K)) is based largely on UML, and is intended to generate coding frames or templates rather than executable code. RRT is intended to generate executable code directly, and is based on the Real Time Object Oriented Modeling (ROOM) methodology (Selec ‘94).

USE OF RRT WITH OOSEMTransition from R98 to RRT: The pilot

successfully transitioned OOSEM from the class based notation used previously to the capsule based notation required by RRT. Most of the artifacts previously captured in R98 were successfully captured in RRT. RRT lacks several OOA capabilities that have been incorporated into later versions of R98/R2K; of note to OOSEM was the lack of support for activity diagrams, which are particularly helpful in developing system threads.

Requirements Linkage: Systems Engineering often requires an arbitrarily deep level of requirement linkage to elements of the system model. For example, OOSEM requires generation of numerous tables (Interface Definition Table, Event Matrix, Event Activation Matrices, etc.) that must be consistent with attributes of system model elements in RRT. In addition, it is necessary to link requirements in the customer’s Operational Requirements Document (ORD) to attribute level information in RRT.

Rational’s own Requisite Pro requirements management tool as provided could only provide linkage to RRT at the Use Case level, and not directly to the capsule or attribute level. As a result, the pilot team elected to use DOORS(http://www2.telelogic.com/doors) in combination with a Metex Rose RealTime DOORS Link (http://www.metex.com). The DOORS/Metex combination provided adequate granularity of linkage without excessive tool modification. Figure 3 shows one example of a table generated by extracting model information from RRT (capsules, use cases, actors, etc), displaying it as a table in DOORS, and then providing linkage to other requirements in DOORS.

Figure 3: All RRT model elements represented and linked to requirements in

DOORS using Metex bridge. This success in accessing RRT data from

DOORS provided assurance that the desired tables, matrices, and specification documents could be created in this manner.

Enterprise Models, Use Cases, and Problem Definition: As shown in Figure 4, capsules proved adequate for capturing the As-is and To-be enterprise models. The enterprise models were built as class diagrams within packages in the RRT “logical view”.

Figure 4: RRT supports capture of As-Is Enterprise Model using capsules. (Pink color

is used to indicate linkage to a source requirement in DOORS.)

Operator were captured within the RRT Use Case View. Use Case diagrams were also straightforward, and actors could be dragged directly from the operator hierarchy on to use case diagrams and sequence diagrams. Use case interaction with capsules defined in the enterprise model proved problematic, however… dragging capsules from the RRT “logical view” into use case diagrams in the “use case view” caused a data corruption problem. Prohibiting “cross-view” drag-and-drop limited further data corruption problems.

Problem definition (fishbone) diagrams are not possible in RRT, so they were generated in Visio (see Figure 5) and imported into the RRT file structure.

Figure 5: Problem Definition (fishbone) diagram, captured in Visio & stored in RRT file

structure.Elaborated Context Diagram: The principal

OOSEM artifact from requirements definition is the Elaborated Context Diagram (ECD). As depicted in Figure 6, the ECD provides a graphical representation of external systems, the subject system, and the interface mechanisms. The OOSEM concept of I/O Entities as class stereotypes was successfully applied in RRT for generation of the ECD. These I/O Entities were later used to define signal data types prior to model execution. This same approach to I/O definition was applied at the Logical Architecture level in what the pilot defined as Logical “data flow” diagrams.

Figure 6: RRT supports capture of the Elaborated Context Diagram and I/O Entities.

Scenarios & System Threads: As stated earlier, RRT does not support activity diagrams, so the pilot was restricted to using sequence diagrams to represent behavior. In OOSEM, this expression of behavior is essential to the adequate definition of system interfaces and derived requirements. Unfortunately, RRT includes no inherent support for conditional branching within sequence diagrams, nor does it provide a mechanism for hierarchical representation of behavior. After initially populating a small set of “primitive” use cases within the technical scope of the pilot, it became desirable to concatenate some of these use cases into a “system thread” to show end-to-end system behavior. The high level operational concept graphic “OV1” (C4ISR ‘97) depiction of the system thread in Figure 7 proved useful.

Figure 7: “OV1” depiction in Visio used for development of System Threads.

Capturing this behavior in sequence diagrams proved to be a difficult exercise, and involved replication of much of the information previously

developed in the “primitive” use cases. It is important to recognize that use of OOA

(sequence diagrams) to specify this behavior, as opposed to OOD (state transition diagrams (STDs)), is fundamental to OOSEM. Development of system activation and control strategies, especially for complex systems, is not to be entered into lightly, or performed ad-hoc while generating STDs. The OOSEM approach logically groups system functions/operations, categorizes them by events, links them to I/O entities, and provides a graphical mechanism for sorting out appropriate system states. This cannot be performed adequately without first defining the complete desired system behavior, using activity diagrams or sequence diagrams.

To provide a system thread aggregation of lower level Use Cases, a new Use Case Diagram was used showing the alternative branches (see Figure 8). To provide an ad-hoc capability for Sequence Diagram conditional branching, the “notes” feature of RRT was utilized to provide a hyperlink capability to alternative branches. An example showing this notes linkage may be seen in Figure 9.

Figure 8: System Thread Diagram (Use Case Diagram)

Capturing Sequence Diagrams: The desire to generate executable code to serve as an executable system model forced a particular approach to developing Sequence Diagrams. RRT requires that each capsule only use signals to invoke functions/methods in other capsules (message based, no function calls allowed). This is facilitated by the definition of ports on each capsule, reusable protocols or signal lists between ports, signals used as triggers between capsules, and user defined data types (I/O entities) applied to signals. As mentioned earlier, this provides strong interface definition and control, which is inherently attractive for systems engineering.

The approach to developing Sequence Diagrams for OOSEM had to facilitate this underlying RRT capability. The pilot utilized a two step approach for development of Sequence Diagrams: First, a

“functional sequence diagram” was developed by using the “function call” relationship, and the appropriate function invoked at the receiving capsule. As shown in Figure 9, “function calls” are represented by full arrows. This required the discipline of manually adding the function (operation) to the capsule, then using a pull down menu to show the function being invoked in the sequence diagram.

Second, the functional sequence diagram is transformed into an “event sequence diagram”, by creating a protocol for use by the sending and receiving capsule, specifying a signal (event), and applying a data type (I/O Entity) to the signal (note that OOSEM events were represented by signals in RRT). This requires the discipline of updating the ECD or Logical “Data Flow Diagram” with I/O entities, and maintaining separate diagrams for capsule ports, protocols, and signals. The sequence diagram can then be updated to a signal (event) definition, represented in Figure 9 with a half-arrow.

Figure 9: Sequence Diagram showing Function Sequence, Event Sequence, and

Conditional Branching using NotesModel Execution: Model execution, while

consistent with the OOSEM initial concept, has not previously been integrated with it. George Mason University (Levis, Wagonhals ‘00) and many others have described the benefits of system model execution. It was generally felt that these benefits would outweigh the effort of building an executable model, and would justify the use of RRT over R2K. The restrictions and complexities of building executable code in RRT unfortunately proved overwhelming!

System model execution is conducted for the purpose of checking consistency and verifying behavior. The fact that a system executable model “compiles” at run time provides a measure of static consistency. The fact that the system model executes error free is a measure of dynamic consistency. The fact that the system model executes in the “correct” sequence is a measure of dynamic verification. Usually, execution of the system model will result in some additional insight into system operation or unforeseen emergent behavior.

After functional sequence diagrams and event

sequence diagrams were complete for all applicable scenarios, the framework for model execution was nearly complete. Focus then shifted to the control strategy, and specification of system states. The OOSEM Event Matrix and the Activation Matrix (Friedenthal, et al ‘00b) are tables indicating how events (signals in RRT) relate to I/O entities, functions, and ultimately states. The rules for establishing states for a given capsule were not fully explored in the pilot, but a structured, repeatable approach to state development is an essential part of a viable systems engineering process. For purpose of the pilot, complex state mappings were not necessary. These state mapping rules would be essential to establishing a coherent logical architecture in more detailed development.

Functions (operations) and events were defined and mapped to the State Transition Diagram (STD) for each capsule in the scenario. For external systems, these STDs were deliberately kept simple. Code was developed for each of the state transitions (C++ in the case of the pilot), corresponding to the receipt of each signal (event). Functions were appropriately developed in C++ to handle the data received from the I/O entities. A significant amount of effort was required just to make the code execute effectively, including insertion of test points, and development of appropriate data types/arrays for internal capsule data. The pilot used the Microsoft Visual C++ compiler, and executed locally on a Windows laptop. To facilitate development of the executable model, a splinter group of pilot participants was established to concentrate on building it, while the rest continued to develop OOSEM artifacts.

The model achieved successful execution at the context level by the end of the pilot period, lagging the context level specification by about two weeks. Within two weeks after the end of the pilot period, a logical level executable model was completed. In both cases, traces were generated that corresponded to the originating Sequence Diagrams. Some insight was gained into system operation as a result of the executable model development, but most of the effort was focused on modeling concepts as opposed to system concepts. The overall value of model execution in RRT will be discussed in following paragraphs.

OBSERVATIONSAssessment of OOSEM as a Formal SE Process:

Of utmost importance, the pilot made clear that specifying a system as complex as CC&D demands a formalized SE method. This method must provide a vehicle to clearly validate Navy needs, and establish an unambiguous system baseline for the contractors to implement.

The OOSEM approach to systems engineering was universally accepted by the pilot team as being superior

to the traditional functional analysis approach for the scope of the pilot program. The pilot provided confidence that system engineering can effectively embrace OO concepts, capturing essential system requirements and design information, providing object centered system design early in the program, and establishing a maintainable, understandable relationship with software. The cost of OOSEM (vice a traditional functional approach) for CC&D is schedule risk associated with lack of linkage to short term deliverable products (specification documents), lack of training, lack of strong precedent on a large program, and need to resolve some representations for system behavior.

The initial enforcement of a “black box” approach for needs analysis and requirements specification was generally felt by the pilot team to provide a comprehensive understanding of system requirements and operation. This approach was particularly relevant considering the architect’s insistence in the distributed nature of the system… “Designed at the battle force level, and implemented at the platform level”. The context of CC&D as a battleforce entity, instantiated on naval platforms, but not including sensors or weapons, was a difficult concept to codify. The enterprise model, ECD, and context level scenarios were critical in gaining this understanding.

RRT Support of OOSEM: The pilot successfully proved that RRT, in conjunction with DOORS and the Metex bridge, does support an OOSEM implementation. Most of the OOSEM artifacts were captured in RRT with moderate level of efficiency.

However, systems engineering was made difficult in RRT for a number of reasons: The OOA capability in RRT lacks the richness of expression in diagrams found in R2K (particularly activity diagrams). The non-standard use of UML in RRT created problems for many of the reviewers. The basic systems engineering need for conditional branching and hierarchical behavior forced a rather contrived approach to diagrams, using notes to link between them.

Although the Requisite Pro to RRT requirement linkage capability proved to be inadequate, the DOORS/Metex bridge successfully maintained traceability between selected model elements and the requirements database. Visibility of requirement linkage was visible in one direction only, however, which was not judged to be practical for large projects.

Model Executability: The pilot proved that executable system models are possible using OOSEM and RRT. The executable model was time consuming and difficult to generate in RRT, however. Its potential value was not fully realized for several reasons:

First, developing an executable model from a “complete” set of OOSEM artifacts required significantly more effort than a comparable model developed in a system modeling tool, such as Statemate

or Core. Each operation, transition, and state for each capsule had to be typed in C++, and could not easily be reviewed in a single place. These C++ statements could not be treated as objects (no inheritance or polymorphism), and were very awkward to manage. This was judged by the pilot team as a rather counter intuitive representation of system behavior.

Second, the degree of insight into system operation afforded by the executable model in RRT was limited by its lack of any meaningful timing parameters. Code generated by RRT is not a system simulation; it is simply a .exe file and a set of associated animated diagrams. There is no inherent time scale associated with system execution. Traditional system modeling tools, like Statemate, Extend, RDD-100, Core, etc. contain a simulation engine that handles simulation time automatically.

The benefits of model execution in RRT; the model consistency, credibility, and insight, were not on the whole thought to outweigh the rather high labor cost. A recommendation along these lines can be found in following paragraphs.

Evaluation of Distributed Real Time Issues using RRT: CC&D is a system distributed across multiple ships in the battle force, with real time track management and weapon control functionality. OOSEM provided the means to define such functionality and capture real time requirements. RRT, however, did not provide an adequate vehicle to analyze these requirements.

Because of the lack of an underlying simulation, real time issues like latency and senescence aren’t addressable directly in RRT. External tools for real time analysis, such as RapidRMA from Tri-Pacific (http://www.tripac.com) and Timewiz from Timesys (http://www.timesys.com), are just becoming available for linkage to RRT. The direction of evolution of these tools is unclear, especially in view of Real-time UML extensions and Model Driven Architecture initiatives at OMG. Likewise, the impact that they may have on OOSEM artifacts in RRT is not clear.

Distributed issues may not be addressable directly in RRT, due to the lack of an inherent ability to generate multi-process executables. An interface to the Connexis multi-process framework is available (http://www.rational.com/products/rosert/connexistables.jsp), but its use was problematic during the pilot.

Taken together, distributed real time analysis support in RT analysis tools is at best unproven and not sufficient reason in itself to recommend use of RRT for systems engineering.

RECOMMENDATIONSThe following selected recommendations were

made to the CC&D program office as a result of the pilot, listed in order of importance.

1. Adopt OOSEM for the program, but reconcile it with customer’s expectations for deliverables. The internal (software) and external (Navy) customer is expecting functionally derived documents and reviews, in accordance with EIA-632, and may not readily understand OO derived requirements and architecture. Reconciling OOSEM artifacts with C4ISR Framework views (C4ISR ’97) is also recommended. It will be necessary to expend additional effort in custom templates and extraction routines to produce these documents and review materials from an OO system model. The overall system engineering approach, tools, artifacts, and templates should be documented in the SEMP.

2. Logical architecture is not functional architecture, and the partitioning rules for logical components need to be defined, socialized, and applied uniformly. Early attention by the system architect on these logical partitioning rules, carefully tailored to the CC&D domain, is necessary for a successful design. It is strongly recommended that the pilot OOSEM logical and allocated architecture artifacts be evaluated for usefulness directly by software developers, and that the role of software developers in conducting OOSEM be explicitly defined.

3. Pay particular attention to incorporation of performance analysis and simulation results. Previous system analysis on CC&D was largely functional in nature, and will require interpretation before it can be applied OO system characterization.

4. Develop a tighter integration of executable models with OOSEM artifacts and system control strategy. Define the purpose and expectations of executable system models on the program, and reconcile these expectations with all stakeholders. The domain experts, software developers, and systems engineers all had different expectations of the executable system model prior to the pilot. Limiting expectations to dynamic consistency checking and verification seemed to provide an appropriate focus for system model execution at the context and logical architecture level.

5. Use R2K vice RRT for both software development and systems engineering on CC&D. This was a difficult decision; the notational limitations and the clumsiness of building the executable counteracted the strong interface control and executable modeling capability of RRT. The main driver for the recommendation was the strong desire of software developers to use R2K vice RRT. Since RRT files are not easily translated into R2K compatible format, this dictated the use of R2K across the program. Use of R2K for OOSEM

seems low risk, due to previous experience with R98. A related recommendation is to explore use of external system modeling tools (e.g. StateMate, Core) to provide the executable system model.

6. Explore approaches to analyzing real time, distributed performance. Key real time parameters will need to be incorporated into object attributes in the system model, but real time analysis will need to be conducted using external tools. Approaches to distributed analysis need further investigation, and may need to be considered as part of an integrated analysis plan.

7. Validate the performance and stability of a requirement management solution. For RRT, use of DOORS with a Metex bridge appeared to provide adequate performance. An evaluation of requirements management tools that interface with R2K remains to be conducted, and should include 1) extraction of tabular OOSEM artifacts from the system model, and 2) generation of portions of appropriate specifications (SSS, SSDD).

8. Conduct follow-up short duration pilot activities to: a) validate the approach to executable model development, b) resolve remaining notational and control specification issues, and c) ensure traceability to software design and implementation.

9. Continue dialog with Rational for improvement of the RRT and R2K tool for OO systems engineering.

10. Establish a dialog in INCOSE and other systems engineering forums to further refine/add value to the OO systems engineering approach applied to CC&D.

CONCLUSIONSThe nature of the CC&D program emphasizes the

need for a distributed, maintainable, upgradable, modular system. It also dictates that the software architecture avoid tight coupling to hardware. It appears unlikely that these objectives can be met without an Object Oriented approach to system definition.

Through this pilot activity, OOSEM proved to be a valuable approach for specifying and defining complex systems. The RRT tool, while adequate to the task, proved somewhat awkward in dealing with conditional branching & hierarchical behavior, and incurred substantial overhead in the development of an executable system model. An alternative approach, using R2K, is currently under consideration.

REFERENCESC4ISR Architecture Working Group, “C4ISR

Architecture Framework Version 2.0”, 18 December 1997

(http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/pdfdocs/fw.pdf)

Friedenthal, Sanford, Meilich, Abe, and Lykins, Howard, “Adapting UML for an Object Oriented System Engineering Method (OOSEM)”, Proc. Tenth Int’l Symposium, INCOSE, 2000

Friedenthal, S.,, Meilich, A., and Lykins, H., OOSEM tutorial, presented at INCOSE 2000.

Levis, A., Bienvenu, M., Shin, I., “C4ISR Architectures III: An Object Oriented Approach to Architecture Design”, Systems Engineering: The Journal of INCOSE, Vol. 3 No. 4, 2000.

Levis,A., Wagonhals L., “C4ISR Architectures I: Deeloping a Process for C4ISR Architecture Design”, Systems Engineering: The Journal of INCOSE, Vol. 3 No. 4, 2000.

Selic, B., Gullekson, G., and Ward, P., "Real-Time Object-Oriented Modeling," John Wiley & Sons, New York, NY, 1994.

BIOGRAPHYRick Steiner has been a Systems Engineer with

Raytheon (legacy Hughes) for 17 years. His experience has been principally in the area of Naval Command & Control, Maritime System Integration, Sonar, and Naval Combat Systems. Rick is an employee of Naval & Maritime Integrated Systems (N&MIS) in San Diego, CA. He is an active member of the INCOSE Model Driven System Development Working Group (MDSDWG), and has been active in the INCOSE technical review of ISO STEP AP233.

Sanford Friedenthal has over 25 years of experience in systems engineering and related engineering areas. His experience includes the full life cycle from conceptual design, through development and production on a broad range of systems including missile systems, electro-optical navigation and targeting systems, and information systems. Mr. Friedenthal was most recently the functional manager for systems engineering at Lockheed Martin M&DS (WMA) responsible for ensuring systems engineering processes are implemented on the programs, and enhancing overall systems engineering capability. He has also been involved in developing advanced systems engineering processes and methods including the Lockheed Martin Systems Engineering Process (LM-SEP), the SPC Integrated Systems and Software Engineering Process (ISSEP), and the Object-Oriented Systems Engineering (OOSEM) Methodology.

Jerry Oesterheld has over 19 years of experience in software/system engineering with emphasis on real-time control systems. He has worked on a diverse set of programs consisting of Command and Control systems, EW systems, and various Intel systems. He has authored and taught numerous courses related to Ada, Ada95, and C++. He holds a BS (80) from Mary

Washington College and has taken numerous graduate courses related to software engineering.

Gautam Thaker has over 23 years of exprience in computer networks and parallel and distributed object oriented systems with emphasis on real-time systems. He has worked on various protocol validation and real-time scheduling tools and has contributed to architecture and design of numerous DoD C2 systems. He has been active in OMG's Real-time CORBA SIG and is a member of the Distributed Real-time Specification for Java Exept Group. He holds a BSEE (75) and MSEE (77) from Clemson University and spent a year at MIT as a Visiting Scientist in 85-86.