See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/242752098

Adapting UML for an object oriented systems engineering method (OOSEM)

Article in INCOSE International Symposium · July 2000

DOI: 10.1002/j.2334-5837.2000.tb00416.x

CITATIONS READS
72 2,136

3 authors, including:

Sanford Friedenthal Abraham Meilich

Worcester Polytechnic Institute Walden University
69 PUBLICATIONS 2,680 CITATIONS 8 PUBLICATIONS 154 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

conceptual modeling View project

Systems Modeling Language (SysML) v2 View project

All content following this page was uploaded by Abraham Meilich on 15 February 2016.

The user has requested enhancement of the downloaded file.

 Adapting UML for an Object Oriented Systems
Engineering Method (OOSEM)
Howard Lykins Sanford Friedenthal
Software Productivity Consortium Lockheed Martin Management & Data Systems
2214 Rock Hill Road 3201 Jermantown Road
Herndon, Virginia 20170-4227 Fairfax, Virginia 22030
[email protected] [email protected]
Abraham Meilich, Ph.D., C.C.P.
Lockheed Martin Mission Systems
700 N. Frederick Ave
Gaithersburg, MD 20879
[email protected]

adaptation if they are to fully benefit systems engineers.

Abstract. Object-oriented (OO) techniques have
Related work. OOSEM has evolved from several
been used predominately by software engineers. Why
initiatives at the Software Productivity Consortium (the
would systems engineers want to add OO techniques to
Consortium) and Lockheed Martin Corporation. The
their existing practices? How should such techniques be
Consortium developed the Integrated Systems and
adapted to be useful to systems engineers? This paper
Software Engineering Process (ISSEP) (Rose et. al
will show how an Object-Oriented Systems Engineering
1996; Rose and Scott 1997; Rose 1997), which
Method (OOSEM) addresses these questions and how
provides a process framework for integration of systems
the use of the Unified Modeling Language (UML) at the
and software engineering methods. Lockheed Martin
systems engineering (SE) level can facilitate capture of
Management & Data Systems (M&DS) used ISSEP as
system requirements and design information and ease
the process framework for the initial development of
communication between systems and software
OOSEM (Friedenthal 1998). Key elements of OOSEM
engineers. The techniques overviewed in this paper
were successfully applied to a development increment
have been applied to information systems and have
for the army global command and control system
allowed engineers to model system needs, requirements,
(Meilich and Rickels 1999).
architectural design, and their allocation to hardware,
Using OOSEM and other OO methods as inputs,
software, databases, and manual procedures. The
the Consortium is developing an integrated systems and
authors believe that OOSEM is applicable to
software engineering method. This method, tentatively
engineering of other types of systems as well.
named Object-Oriented Approach to Software-Intensive
BACKGROUND Systems (OOASIS), will provide UML-based modeling
at the systems and software engineering level.
Motivation for OOSEM. OO techniques have been Integration of non-OO model-based SE and OO
applied successfully by software engineers to software software engineering is discussed by Ali (1998).
development for years. However, systems engineering, The SE community also has indicated interest in
for the most part, continues to apply classical structured OO techniques independent of integration with
analysis techniques to define the system-level software-level OO. A recent book by Oliver, Kelliher,
requirements and design artifacts. The use of different and Keegan (1997) uses an OO modeling technique to
modeling techniques can result in incompatibilities and describe both the SE process and the results of the
communication problems between systems and software process. An approach for deriving an OO system design
engineering. OOSEM is motivated in part by the need from functionally-oriented customer requirements
to mitigate these incompatibilities. (Hopkins and Rhoads 1998) was presented at the 1998
This is not the only motivation for OOSEM. As Symposium of the International Council on Systems
evidenced by several recent books and articles, systems Engineering (INCOSE). The need for animating object
engineers are increasingly interested in the use of OO oriented models (Dockerill 1999) was discussed at the
modeling to more effectively capture, analyze, and 1999 Symposium, along with some cautionary notes
communicate system requirements and design about using OO models for SE (Cocks 1999).
information. However, it is the opinion of the authors
that software-level OO techniques will require
Schoening (1996) discusses use of object-based1 state, transient and persistent data, and performance
software to simulate complex systems. characteristics, such as response time, size, weight, and
cost.
OOSEM APPROACH The automated teller machine (ATM) example in
The OOSEM approach is characterized as follows: Figure 1 illustrates the OOSEM adaptation of UML
• It implements a well-defined SE process that classes, attributes, and operations. Stereotypes are used
encompasses the activities from needs analysis to categorize these artifacts by what they represent. For
through verification based on the ISSEP process example, a class with the stereotype <<System>>
model. represents the system under development, and <<IO>>
• It adapts UML Version 1.3 (Object Management designates an input/output entity that captures interface
Group 1999) to capture system requirements and information (described below). OOSEM uses attributes
design information. UML was selected because of of the <<System>> class to represent system state
the rigor of its syntax and semantics and because it variables, transient and persistent data stores, and
has become the de facto industry standard for OO system performance parameters.
software development.
• It maintains well-defined relationships between its
<<System>> <<IO>>
ATM Currency
models and components to ensure requirements <<state>> Operational <<phys>> 10 Bills
<<transient>> Trans Type <<phys>> 20 Bills
traceability and system design integrity. <<transient>> Acct ID

• It addresses the total system, including allocation of <<transient>> Cust ID

<<persistent>> Rem 10 Bills
requirements to hardware, software, databases (in <<persistent>> Rem 20 Bills
<<TPM>> Withdraw Time
<<IO>>
data-intensive projects), and manual procedures. <<TPM>> Weight
Receipt
<<TPM>> Power Consumption
<<data>> Customer ID
It should be emphasized that OOSEM does not <<cap>> 1. Withdraw Transaction() <<data>> Date/Time
<<data>> Trans Type
advocate replacing specialty engineering models with <<cap>> 1.1 Dispense Currency()
<<fun>> 1.1.1 Dispense 10s() <<data>> Approval
UML. Rather, it encourages use of OO models to <<fun>> 1.1.2 Dispense 20s() <<data>> Trans Amt
<<cap>> 1.2 Print Receipt()
capture system and component behavioral, <<cap>> 2. Deposit Transaction()
<<cap>> 3. Inquiry Transaction()
performance, and physical characteristics that provide
the basis for integrating other specialty engineering
models. Other traditional techniques and models are
required to fully capture the system requirements and Figure 1. Classes and I/O Entities
design information, such as performance timelines and Various component types and subtypes, such as
physical layouts. hardware, software, and data components, also can be
UML CONSTRUCTS USED BY OOSEM represented as class stereotypes.
Numbering indicates the hierarchy of system
This section summarizes the UML constructs most capabilities (<<cap>> stereotype) and functions
commonly used by OOSEM. Some constructs are used (<<fun>> stereotype). In Figure 1, Dispense Currency
without significant change; others must be adapted for and Print Receipt are subcapabilities of Withdraw
use in the systems context. Transaction. Dispense 10s and Dispense 20s are
Classes, attributes, and operations. A UML class is a functions of Dispense Currency. The distinction
template from which one or more objects is derived. between capabilities and functions is explained below.
OOSEM uses objects to represent input/output (I/O) Input/output entities, illustrated in Figure 1, are a
entities and abstract physical components that can: special type of class that are used to capture inputs and
• Store items such as data, energy, mass, or parts outputs of the system and its components. The I/O
• Perform sets of operations on inputs or stored entities have no operations but are characterized in
entities in response to a stimulus. terms of attributes. These attributes include data content
and their associated data type, frequency, size, and data
The class from which an object is derived specifies a set
transfer method (e.g., File Transfer Protocol [FTP] and
of attributes and operations associated with the object.
database transactions). The data content attributes
OOSEM uses UML operations to capture functional
represent input and output parameters to system
behavior associated with the system, its components, or
functions. These attributes can represent inputs and
external systems. Attributes are used to model system
outputs other than data, such as physical inputs for
mass, energy, or parts. Interface control documents and
1
Defined to mean “object oriented without interface requirements specifications are generally used
inheritance” to capture this information. Data attributes are identified
by the <<data>> stereotypephysical items such as
$10 and $20 bills dispensed by the ATM are identified <<System>>
ATM
by the stereotype <<phys>>. <<state>> Operational
<<transient>> Trans Type
OOSEM defines system capabilities as operations that <<transient>> Acct ID
produce or consume I/O entities. System functions <<transient>> Cust ID
<<persistent>> Rem 10 Bills
operate on individual attributes of I/O entities. <<persistent>> Rem 20 Bills
<<TPM>> Withdraw Time
Use case diagrams, illustrated in Figure 2, are used by <<TPM>> Weight
<<TPM>> Power Consumption
OOSEM to conceptualize system capabilities for both
the as-is system and the to-be system and provide the <<cap>> 1. Withdraw Transaction()
<<cap>> 1.1 Dispense Currency()
basis for defining detailed scenarios. They are initially <<fun>> 1.1.1 Dispense 10s()
defined at the system black-box level and further <<fun>> 1.1.2 Dispense 20s()
<<cap>> 1.2 Print Receipt()
elaborated to capture system functionality and <<cap>> 2. Deposit Transaction()
<<cap>> 3. Inquiry Transaction()
interaction between system components.

<<System>>
Withdraw Transaction ATM Variant

<<cap>> 4. Transfer Transaction()

Bank

Custom er
Deposit Transaction Figure 3. Inheritance

Analyze Needs. This activity characterizes the problem

space by defining as-is system operation, current
Inquiry Transaction deficiencies, mission/enterprise-level measures of
effectiveness, and required capabilities.
This activity applies use cases, scenarios, and other
Figure 2. Use Cases OOSEM models to describe the current system and its
processes. Various types of system users are
Inheritance is used to capture commonality in OOSEM characterized by UML actors and the use of inheritance.
as in other OO techniques. OOSEM also uses The general-purpose actor User, illustrated in Figure 4,
inheritance to capture potential requirements and design captures characteristics common to all users. Specific
variations. For example, in Figure 3, a variant of the types of user are modeled as subclasses that add their
ATM system adds a funds transfer capability. own unique characteristics. The use cases and scenarios
capture the key functionality of the current system.
Aggregation is used by OOSEM to decompose the
system into components and to decomposed I/O entities
into lower-level entities.
User
Deployment view. OOSEM uses class diagrams or
deployment diagrams to represent allocation of software
and data components to hardware components and
allocation of manual procedures to people or Customer Administrator Teller
organizational components.

OOSEM ACTIVITIES AND MODELS

Figure 4. User Classification
OOSEM includes the following development activities:
Analysis of as-is use cases is used to identify
• Analyze Needs
deficiencies of the current enterprise (that the new
• Define System Requirements system will correct) and preliminary measures of
• Define Logical Architecture effectiveness. A root cause analysis of these
• Synthesize Candidate Allocated Architectures deficiencies provides the basis for establishing the
• Optimize and Evaluate Alternatives needs for the improved system.
• Validate and Verify the System
 An Enterprise Model, illustrated in Figure 5, uses from external systems, the <<External>> stereotype is
classes and aggregation relationships to describe how an used for the latter.
enterprise is constructed from the system to be
developed and other, external systems. In the Enterprise <<External>>
External System
Model, the <<System>> class is shown as a component
of the <<Enterprise>> class. Additional classes denote <<IO>>
IO Entity 1
elements external to the system with which the system <<System>>
collaborates to accomplish its mission. Operations on System
<<state>> State Var.
the <<Enterprise>> class denote enterprise-level <<transient>> Trans. Data
<<persistent>> Persis. Data
capabilities (e.g., to withdraw money from the bank), <<TMP>> Perf. Measure

which are allocated to both the system (e.g., ATM) and <<cap>> 1. Capability()
<<cap>> 1.1 Capability()
to the external systems (e.g., bank). Operations on the <<fun>> 1.1.1 Function()
<<fun>> 1.1.2 Function()
<<System>> class (shown in Figure 1), on the other <<cap>> 1.2 Capability()
<<cap>> 2. Capability()
hand, will describe system capabilities. Detailed
elaboration of these capabilities will be captured in the <<IO>>
Output Entity
Define System Requirements activity. Performance
attributes of the <<Enterprise>> class (e.g., amount of
User
time to make a withdrawal) are effectiveness measures
(<<moe>> stereotype), which are allocated to the
system (ATM) and external systems (e.g., bank, user).
Figure 6. Elaborated System Context
<<Enterprise>>
Banking Enterprise
Diagram
<<moe>> Wait Time
<<moe>> Transaction Cost
<<moe>> Theft Probability
This activity also identifies system design
Deposit()
constraints, which limit the solution space. Examples
Withdraw()
Balance Inquiry() are pre-identified hardware and software commercial
off-the-shelf (COTS) products and legacy databases.
The constraints are captured in a constraints list
(external to the UML models) and used as an input to
the system architecture activities. Requirements
<<External>> <<System>> <<External>>
Network ATM Security Mechanisms variation is also captured and quantified in terms of a
Customer
Bank Administrator
probability of change. A typical examples is a system
interface that is likely to change because the other side
of the interface is still under development. The
requirements and verification traceability (RVT)
Figure 5. Enterprise Model database is initiated during this activity, and traces each
system functional, interface, and performance
Define System Requirements. This activity treats the requirement to a system-level use case.
system as a black box to characterize system stimulus- Scenarios are captured using UML sequence,
response behavior and performance requirements. The collaboration, or activity diagrams. The purpose of
system, external systems, and users are defined as these scenarios is to illustrate how the system will
individual classes as previously described in the interact with actors and external systems on the context
enterprise model. The system operational concept diagram. The scenarios show only the system, actors,
defines a set of system-level use cases and scenarios and external systems that produce or consume I/O
based on the needs analysis. This operational concept is entities and attributes, thus providing the foundation for
used to derive the system functional, interface, data, and defining the detailed functional, interface, performance,
performance requirements. The functional requirements and storage requirements. Interactions among system
are grouped into system capabilities. System components are described in the next two activities.
states/modes and related system control information are
also defined (e.g., using state machines). The resulting Define Logical Architecture. This activity decomposes
system requirements information is captured in an the system into its logical components, defines their
elaborated system context diagram, as illustrated in interactions, and allocates system requirements to each
Figure 6. In the elaborated context diagram and logical component. OOSEM guidelines for
elsewhere in OOSEM, the <<Actor>> stereotype is decomposing the <<System>> class into logical
used to denote human users. To distinguish humans components are different from traditional functional
decomposition guidelines, emphasizing, among other • Reliability and maintainability
concerns, planning for change. The interaction between • Environmental considerations
logical components is captured in data flows • Allocation of development work to subcontractors
(represented using associations and I/O entities) and
logical system threads. Partitioning criteria are Synthesize Candidate Allocated Architecture. This
established and used as a basis for partitioning the activity maps each logical component to hardware,
logical components to address component cohesiveness, software, data, and/or manual procedures. The resulting
design for change, performance, and other design allocated components form the basis for a multilayer
considerations. System functional, interface, data, and system architecture, which typically includes layers for
performance requirements are allocated to logical the mission application, a services layer (i.e., functions
components and captured in the RVT database. common to multiple mission applications), and
The Define Logical Architecture activity uses operating system and resources. The allocated
aggregation relationships to describe a hierarchical view components are used to derive the corresponding
of the system logical architecture, as illustrated in hardware, software, and data architectures. The
Figure 7. The system is decomposed into logical software architecture is captured using the full range of
components, which may be further decomposed into UML diagrams and features. The hardware architecture
lower-level logical components. Each logical uses UML class diagrams for defining hardware
component is an abstraction of a set of possible system hierarchy; the architecture also uses interconnection and
components (e.g., hardware, software, databases, traditional hardware depictions such as physical layouts.
manual procedures), any one of which will meet the The data architecture uses class diagrams to capture
requirements allocated to the logical component. An data hierarchy and relationships, along with table
example of a logical component is a user interface. The specifications and other traditional data architecture
potential corresponding elements in the allocated depictions. Figure 8 illustrates the OOSEM deployment
architecture (developed in the next activity) may be a view, using a class diagram to depict the allocation of
Web browser with associated screen representations on software and data components to hardware components.
a PC client. In the ATM example, a money dispenser <<System >>
C lient-S erver S ystem
may be a logical component that could be implemented
in the allocated architecture in many different ways. C lient Application S erver

Sequence, collaboration, and activity and state diagrams

are used to describe interactions among logical B row s er()
O S ()
A pp lic 1 ()
A pp lic 2 ()
U se r
components. A pp lic n ()

<<System>>
Local Area Netw ork
System P eripheral

« IO »
D ata/File S tore D ata/File S erver
Log Comp 1 Log Comp n
...
D ata S e t 1 : T ype 1
D ata S e t 2 : T ype 2 R D B M S ()
F ile M gr.()

Log Comp 1.1 Log Comp 1.m

... Log Comp n.1
Figure 8. Allocated Architecture
Figure 7. Hierarchical Decomposition Functional, interface, and performance
requirements are allocated to component classes of
Example hardware, software, data, and manual procedures. All
The partitioning heuristics in this activity take the system requirements are allocated to system
following into consideration: components in this activity. Traceability is maintained
• Design for changes in needs, requirements, and between the logical and allocated components and
design decisions captured in the RVT database.
• Encapsulation of detailed component behavior and Process engineers and software, database, and
performance characteristics hardware developers use the allocated architecture and
• Reuse considerations, including use of COTS items associated component requirements as an input to their
• Timing and other performance considerations development activities. Alternatively, components in the
allocated architecture can be procured off the shelf.
Continued feedback to the system designers is provided
to ensure traceability between the system requirements, Tester
system architecture, and component design. Traceability <<IO>> <<IO>>
Test Commands Test Feedback
is maintained between the allocated architecture and the
component design in the RVT database.
<<Test System>>
Test System
Optimize and Evaluate Alternatives. This activity is
invoked throughout the other OOSEM activities to
optimize the candidate architectures and conduct trade <<IO>>
Test Excitation
<<IO>>
Test Response
studies to select the preferred architecture. Parametric
models for characteristics such as performance,
<<System>>
reliability, availability, and life-cycle cost are used to System

analyze and optimize each candidate architecture to the

level needed to compare the alternatives. The
parametric models use architectural components defined Figure 9. Test System Context Diagram
in the logical and allocated architectures and their
associated performance parameters. Trade studies are SOFTWARE OO LIMITATIONS AND
used to evaluate each alternative architecture based on OOSEM RESPONSES
defined criteria and weighting, which are traceable to
the system requirements and measures of effectiveness. This section summarizes some key limitations of
The parametric models tend to use their own software-level OO techniques for use at the system level
unique syntax and descriptions. OOSEM architectural and discusses how OOSEM addresses each limitation.
models provide a common definition of the OO Limitation. “Flat” (i.e., nonhierarchical) models,
components, performance and physical attributes, and such as class, collaboration, and sequence diagrams,
their interfaces, which is used by the parametric models. inhibit the systems engineer from capturing the
Validate and Verify the System. This activity includes decomposition and traceability of a complete system
the development of verification plans, procedures, among heterogeneous architectural components.
methods (e.g., inspection, demonstration), and analysis OOSEM Response: hierarchical decomposition. A
of verification data. System-level use cases, scenarios, key feature of OOSEM is that it decomposes the system
and associated requirements are key inputs to the into logical components then decomposes the logical
development of the test cases and associated components into subcomponents, continuing the
procedures. A powerful verification technique is for the decomposition until each logical component can be
systems engineer to include the definition of the allocated as a whole to an element of the allocated
test/verification systems that implement the verification architecture. This is in contrast to some existing OO
methods. As illustrated in Figure 9, the test/verification techniques that do not take advantage of hierarchical
system can be represented in terms of the OOSEM decomposition. The fragment of a logical architecture in
artifacts, beginning with a high-level context diagram Figure 7 is an example of hierarchical decomposition.
for the test/verification system. The RVT database is OO Limitation. Lack of comprehensive definition of
further elaborated during this activity to trace the interfaces between the system and its external
system requirements and design information to the environment.
system verification methods, test cases, and results. OOSEM Response: elaborated context diagram.
This is the OO equivalent of the context diagram in
classical structured analysis. It replaces the system
transformation with a system object characterized in
terms of multiple types of attributes and operations that
denote system capabilities, functions, and other
characteristics. Data flows are replaced by I/O entities,
and terminators are replaced by UML actors and
<<external>> classes that represent external interfaces.
Two lessons learned apply here: First, the context
diagram is just as indispensable in OO analysis as in
structured analysis. Second, a context diagram can be
captured effectively in an OO notation.
OO Limitation. Inability to characterize performance the hardware, software, data, and procedural
and other non-behavioral characteristics components in the allocated architecture. Rules for
OOSEM Response: multiple attribute categories. As creating classes and objects are well-defined in the
shown in Figures 1 and 6, OOSEM uses attributes to method. This explicitness is in marked contrast to
capture required performance characteristics and guidelines in other methods such as “Look for the nouns
requirements for transient data and persistent data. in the problem statement to identify your classes.”
Attributes in software-level OO models tend to be items
Disciplined use of associations. A key feature of
that will appear directly in the implementation. OOSEM
OOSEM is that it constrains the use of UML
uses attributes in this manner but also uses them to
associations (relationships between classes) to a well-
characterize key requirements and implementation
defined set. The most commonly used associations are
characteristics. The effect is to make performance
inheritance and aggregation. Certain other associations,
requirements explicit and to facilitate trade studies by
such as those on the context diagram connecting I/O
specialty engineering.
entities to the system and external actors, are also
OO Limitation. Inability to integrate systems and allowed. However, the constraints on OOSEM
specialty engineering models. associations are intended to ensure that every
OOSEM Response: application of OO models as a association is implementable and traceable.
common framework for integrating engineering
Allocated architecture. OOSEM uses a combination of
models. According to accepted SE maturity models
OO concepts and multilayer architectures to capture
such as EIA/IS 731 (EIA 1999), it is the responsibility
allocation of system requirements and design decisions
of SE to integrate engineering and specialty disciplines.
to hardware, software, databases, and manual
OOSEM facilitates this by using OO modeling to
procedures.
capture behavioral, performance and physical
characteristics, and interfaces, which are common to SUMMARY
other engineering models. OOSEM can be used to
communicate key information among many disciplines. OOSEM incorporates OO concepts and modeling
approaches using UML with classical, top-down SE.
OTHER UNIQUE FEATURES OF OOSEM The method is intended to facilitate communication
among system, software, and other engineering
System-level use cases and scenarios. UML use cases
disciplines. In addition, the method provides an
are used to capture system-level capabilities and to
effective means to capture system requirements and
develop scenario-based requirements, which include
design information.
functional, interface, and performance requirements.
OOSEM encompasses the broad scope of SE
System-level use cases are the basis for system
activities for defining system requirements and design
scenarios, which show sequences of events and actions
and allocating the requirements to system components.
performed by the system, external systems, and users.
OOSEM includes activities for needs analysis,
These scenarios are further decomposed and allocated
requirements analysis, logical and allocated architecture
during logical architecture design to illustrate
design, alternative evaluation, validation, and
interactions among logical components of the system.
verification.
These scenarios also provide the basis for the
OOSEM adapts UML and, by extension, similar
interactions among the physical components in the
OO modeling notations. The adaptations include
allocated architecture and are used as a basis for test
defining an elaborated, system-level class with
cases in the validation and verification (V&V) process.
additional attributes representing performance
I/O entities. OOSEM explicitly captures inputs and characteristics and defining I/O classes to capture
outputs in terms of I/O entities and their attributes. critical interface information. Logical decomposition of
OOSEM models captured in computer-aided the <<System>> class provides the basis for a logical
systems/software engineering (CASE) tools use the architecture. OOSEM also addresses various component
stereotype <<IO>> to distinguish I/O entities from other types, including hardware, software, data, and
types of classes. Use of I/O entities is a marked procedural components, which provide the basis for the
improvement over OO methods that do not make inputs allocated architecture and allocated requirements.
and outputs explicit (or easy to find) in the model. Future work includes refining and formalizing
OOSEM guidelines, refining and improving
Disciplined use of classes. OOSEM uses a systematic
adaptations of UML, integrating the method with a
approach for identifying classes and objects and their
UML-based method for software engineering, and
relationships. Classes can represent the system, users,
evaluating tool support for the method.
external systems, I/O entities, logical components, and
 REFERENCES design through development and production, on a broad
Ali, Michael, “Model-Based Systems Engineering and range of systems, including missile systems, electro-
Object-Oriented Software Engineering: An optical navigation and targeting systems, and
Integrated Approach,” in Proc. Eighth Int. Symp. information systems. Most recently, Mr. Friedenthal
INCOSE, 1998. was a functional manager for SE at Lockheed Martin
Cocks, Dan, “The Suitability of Using Objects for M&DS, responsible for ensuring that SE processes were
Modeling at the Systems Level” in Proc. Ninth Int. implemented on the programs, and enhancing overall
Symp. INCOSE, 1999. SE capability. He has also been involved in developing
Dockerill, Kevin, “The Importance of Animation witgh advanced SE processes and methods, including the
UML” Proc. Ninth Int. Symp. INCOSE, 1999. Lockheed Martin Systems Engineering Process (LM-
Electronic Industries Alliance (EIA), Systems SEP) and the Lockheed Martin Integrated Engineering
engineering capability EIA/IS 731, Process (LM-IEP).
http://www.geia.org/eoc/G47/731dwnld.htm, 1999. Abraham Meilich. Dr. Abe Meilich is employed as
Friedenthal, Sanford, “Object Oriented Systems a Certified System Architect at Lockheed Martin
Engineering,” in Process Integration for 2000 and Mission Systems. He has a B.S. in Engineering from
Beyond: Systems Engineering and Software UCLA, an M.S.M.E. from Stanford, an M.S. in Systems
Symposium. New Orleans LA: Lockheed Martin Management from USC, a Ph.D. in Systems
Corporation 1998. Management from Walden University, and a Certified
Hopkins, Frank W. and Rhoads, Russel P., “Object Computing Professional (C.C.P.) Certification. His
Oriented Systems EngineeringAn Approach” in career spans 30 years in the mechanical, electrical,
Proc. Eighth Int. Symp. INCOSE, 1998. computer, aerospace, and information SE domains. He
Meilich, Abe and Rickels, Michael, “An Application of is an adjunct professor at the University of Maryland
Object Oriented Systems Engineering to an Army Graduate Program in Technology Management,
Command and Control System: A New Approach Systems Acquisition, and Information Systems. He is
to Integration of Systems and Software past Secretary and Newsletter Editor and past Director
Requirements and Design,” in Proc. Ninth Int. of the Washington Metropolitan Area Chapter of
Symp. INCOSE, 1999 INCOSE. His current focus is on the application of SE
Object Management Group, OMG Unified Modeling principles and best practices in systems architecture
Language Specification. Version 1.3, June 1999. development to the design of command and control
http://www.rational.com/uml/index.jtmpl systems for the U.S. Army and government information
Oliver, David, Kelliher, Timothy P. and Keegan, James systems.
G., Jr., Engineering Complex Systems with Models Howard Lykins. Howard Lykins is a senior
and Objects. McGraw-Hill, New York, 1997. member of the technical staff at the Software
Rose, Susan and Scott, Peter, “Integrated Development Productivity Consortium and has over twenty-five years
for Computer-Based Systems” in Proceedings of of experience. Since joining the Consortium in 1991,
the IEEE Technical Committee on Engineering Mr. Lykins has developed or contributed to a number of
Computer Based Systems, 1997. software engineering and SE processes and methods.
Rose, Susan, “Engineering Harmony Between Systems His recent accomplishments include adapting the Object
and Software” in Proc. Seventh Int. Symp. Modeling Technique for development of embedded
INCOSE, 1997. real-time control software and tailoring ISSEP for
Rose, Susan, Finneran, Lisa, Friedenthal, Sanford, component-based development. He holds a B.A. from
Lykins, Howard and Scott, Peter, Integrated Transylvania University and an M.S. in Computer
Systems and Software Engineering Process. SPC- Science from Washington University in St. Louis. Mr.
96001-CMC, version 01.00.04. Herndon, Virginia: Lykins is Co-Chair of the INCOSE Model-Driven
Software Productivity Consortium, 1996. System Design Working Group.
(Available to the general public)
Schoening, William, “Using Object-Based Simulations ACKNOWLEDGMENT
for Exploring and Testing Complex Systems,” in Rational Software provided a gratis copy of Rational
Proc. Sixth Int. Symp. INCOSE, 1996. Rose 2000 Enterprise Edition to the Consortium for
research and development use. This tool was used to
BIOGRAPHIES
generate all figures in this paper except for Figure 8.
Sanford Friedenthal. Mr. Friedenthal has over 25 years The authors and the Consortium gratefully acknowledge
of experience in SE and related engineering areas. His their support.
experience includes the full life cycle, from conceptual

View publication stats