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

net/publication/236881537

Model Driven Architecture for Systems Engineering

Article · January 2008

CITATIONS READS
9 1,852

1 author:

Robert Cloutier
University of South Alabama
76 PUBLICATIONS   788 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Robert Cloutier on 22 February 2016.

The user has requested enhancement of the downloaded file.

Paper #220

Model Driven Architecture for Systems Engineering

Robert Cloutier, Ph.D.
Stevens Institute of Technology
Castle Point on Hudson
Hoboken, NJ 07060
[email protected]

Abstract
Model Driven Architecture (MDA) is a primary initiative within the Object Management Group
(OMG) that includes a model based approach for software design and a set of key principles that
are intended to improve software interoperability, reusability, portability, maintainability, and
reliability. The approach incorporates model abstractions, which specify specific levels of the
software system from concept to implementation. This paper reviews the key MDA principles as
defined by the OMG, and then evaluates their potential applicability to the systems engineering
discipline, along with the potential benefits to systems architecture and system design concepts
of large scale systems development. The paper will identify potential MDA practices that could
significantly advance the practice of systems engineering, to include the application of system
design patterns to a logical architecture and the mapping to a physical architecture.

1.0 Introduction
According to the Object Management Group (OMG), Model Driven Architecture (MDA)
is a collection of OMG specifications and guidelines to establish an approach for software devel-
opment [MDA]. The current MDA guideline is version 1.0.1, dated 12 June 2003. In practice,
the purpose of MDA is to enable the design and analysis of a new software product at a level that
is generic enough to implement on a number of different compute platforms (combination of
hardware, operating system, and middleware). Using a technique referred to by software engi-
neers as abstraction, the designer removes enough specificity from the problem of interest, mod-
eling only the essence of the design. The model is generic enough to do analysis without worry-
ing about the computing platform in which the software system will execute. This approach,
sometimes referred to the separation of concerns – separates the business functionality from the
implementation details of the application. The compute independent viewpoint should capture
the business view from the stakeholder’s perspective.
The platform independent viewpoint looks at how the system should operate, but not to
the point that it gets into the specific implementation details. In other words, it is the description
of the system leaves out the details on the implementation of how to deliver the product for a
specific computing system. This is a useful view to create prototypes from – the details of how
the system works are less important than how the system will look to the stakeholders.
Finally, there is the platform specific viewpoint builds on the platform specific viewpoint,
and adds the details necessary for the specific computing platform in which the application will
be run. While it is true these viewpoints can be created manually using pen and pencil, or even
using PowerPoint or Visio, the real value of MDA comes when using advanced computer based
tools such as Enterprise Architect, TAU, Rhapsody, or any of the other UML tools available to-
day to represent these viewpoints.

2.0 Engineering and Modeling a System

During system architecture and design, a number of documents, sketches, and diagrams
which attempt to capture stakeholder visions and goals. From those visions, sketches and docu-
ments, the system specification then defines what the system must do to accomplish the system
objectives. For many systems today, this specification matures into a complex hierarchy of “shall
statements” that guide the systems engineers to partitioning the system into smaller and smaller
parts that are more manageable. At some point, the continued design of the smaller parts be-
comes the responsibility of the hardware engineers, software engineers, and human factors engi-
neers. Within the context of software, software engineers take those specifications, and using the
OMG’s Unified Modeling Language (UML) and MDA, design the software for the system of
interest.
Systems engineers have traditionally captured the customer requirements of what the de-
sired capability of the system and transformed those into the system specifications. For large sys-
tems, this may represent two different documents, for smaller systems both the requirements and
system specifications may be captured in different place of the same document. Many companies
today manage these requirements using a requirements management tool such as Telelogic
Doors. Those requirements are then normally analyzed, and partitioned and/or decomposed into
smaller and smaller chunks of information to gain better understanding, and to begin the archi-
tecture and design. Today, Microsoft PowerPoint and/or Visio seem to be the tools of choice for
this systems engineering work, and block diagrams of various types are used (IDEF0, Functional
Flow Block Diagrams, State diagrams, etc). As a new requirement for the system is identified
while architecting/designing the system, it is added to those already in the requirements man-
agement tool. There is no formal linking between the requirements database and the architec-
ture/design documents, unless it is manually done using a tool like Doors. Additionally, there is
may be no formal linking between the elements on any of the block diagrams. Arguably, it could
be surmised that the logical unit of reasoning for the system engineer is a block (which repre-
sents some capability of the system as captured in the specification).
Tools like Vitech’s Core have come along to provide a combined requirements manage-
ment capability and a graphical drawing tool to provide a formal approach to link the diagrams to
the system specification, allowing for direct traceability of the design back to the customer re-
quirements. UML tools now provide a similar capability, but they tend to provide a method to
link the diagrams to a requirements management tool such as Doors. As a disclaimer, this is not a
total list of the modeling tools used by systems engineers to understand the system being de-
signed – simulation tools, performance modeling tools, math modeling tools, and a host of other
models (such as CADAM) may be necessary to model a complex system. This discussion is pur-
posefully being limited here.

2.1 MDA and Productivity Improvements

There are several published reports/studies on the value of MDA to the software commu-
nity and are discussed briefly.
 a) Compuware (a professional services company) commissioned The Middleware Company
in 2004 to evaluate the claims of MDA productivity improvement1. Working from a sin-
gle specification, two independent teams of three designed and wrote a web-based Pet-
Store application. Results of the 5-week effort demonstrated a 35% productivity gain by
the team using an MDA approach and tool. Their lessons learned, which may be of
greater interest, are:
¾ Took time for the MDA team to mentally grasp the new paradigm
¾ Took time to ramp up on using a UML tool to perform MDA
¾ Underestimated the learning curve of the paradigm shift
¾ Productivity gains come in an S-curve fashion, slow at first, and grow as team is
more comfortable with the approach
¾ One benefit cited to applying MDA at a higher level of abstraction is that the
UML tool enabled a consistent application of architect-endorsed patterns.
b) Lockheed Martin F-16 program implemented MDA on the mission computer software,
representing 80-90% of the total software on the aircraft. They were migrating from OO
software written in ADA to an executable UML approach. LM found a 20% reduction in
application development time while achieving cross platform compatibility. Benefits
sited include early validation of models through model execution, reduced rework with
validated models, and a high degree of usability.2
c) DaimlerChrysler’s Large Truck Business Unit in Europe /Latin America designed and
implemented their electronic production planning (ePeP) system using MDA. They had
planned for a 10% improvement but achieved a 15% increase in development productiv-
ity in the first year, with the expectation of a 30% productivity increase in the second
year (I believe this is due to the learning S-curve mentioned above). One of their more
significant successful goals was to realize architectural consistency in the complex ePeP
system across all technical and functional layers of the system.3
d) Finally, the Joint Single Integrated Air Picture Systems Engineering Organization
(JSSEO) is using an MDA approach to develop their product. However, they did the Op-
eration Views in an IDEF tool, and then had to convert to UML. There does not seem to
be any published productivity claims for this project as of the time of this writing.
Other benefits cited or that can be inferred from these studies include might be:
¾ Improved documentation – most modeling tools will auto-generate documentation
in RTF or HTML format
¾ Model consistency through the modeling language and tools (as opposed to
PowerPoint engineering)
¾ Patterns mined from the individual business or product lines can be implemented
in the tool for consistent application, reducing risk and complexity
¾ Facilitation of a product line strategy implementation through model reuse
¾ Modeling language facilitates partitioning of work by model packages
While these published studies claim a 15% to 35% efficiency improvement, they are in the
highly creative software domain. The SE domain is also highly creative, but there is more to SE

1
http://www.middleware-company.com/casestudy/
2
http://www.omg.org/mda/mda_files/LockheedMartin.pdf, http://www.omg.org/mda/mda_files/Lockheed-KC_MDA.pdf
3
http://www.omg.org/mda/mda_files/SuccesStory_DC_TSS_MDO_English.pdf
than simply creating models and auto-generating software. However, it seems reasonable to hy-
pothesize that the application of MDA may provide 10-20% efficiency increase in the SE effort
over using what have become the SE tools of choice – PowerPoint, Word and Excel. For a $20M
engineering project, with SE representing 10% of the overall effort, the improved efficiency
might range from $200k - $400k.

2.2 UML and SysML

The OMG, collaborating with the International Conference of Systems Engineers
(INCOSE) has worked to improve the acceptance of system modeling by creating a subset of
UML – the System Modeling Language, or SysML to assist systems engineers in modeling the
entire system [SysML]. However, since it is a subset of UML, it would be a mistake to believe
that SysML is a very immature modeling language. While there are improvements needed, par-
ticularly in some of the added or enhance capabilities, much of the underlying language builds on
the successes of UML. What is immature is the understanding of how to use the language to
model a system, and the understanding of systems engineers in using the tool.
SysML contains a few new diagrams necessary for systems engineering, and removes
many of the software specific diagrams that are not of use when modeling a complex system.
Therefore, what remains is to reconsider the definitions of the CIM and PIM, in the context of a
complex system, and to discuss the diagrams that might be useful in applying SysML to MDA
when describing a complex system and its architecture. The diagrams included in SysML shown
in the following diagram [SysML].
When one applies MDA to the broader system, instead of just the software portion of the
system, the context broadens. In addition to the software and the operator (if required to operate
or interact with the software), hardware, or other subsystems may be introduced as part of the
system. The CIM takes on the broader context, and this context and systems engineers typically
handle system design.

Figure 1 - The OMG SysML Diagram Structure4

4
http://www.omgsysml.org/)
3.0 An Systems Engineering MDA Approach
Early in the MDA documentation, the CIM is introduced and defined, but then never de-
veloped later in the guideline. In an SE MDA approach, the CIM plays a critical role. The CIM is
used to capture and model the concept of operations for the system (CONOPS), taking a black-
box view of the system, and detailing how the system will interact other systems and external
actors. Other considerations to be included as part of the CIM are goals of the system, the re-
quirements for the system in context, the system stakeholders needs, business rules that impact
the system, etc.
This is accomplished using a SysML modeling tool, using use case diagrams and activity
diagrams to document the mission use cases and mission scenarios. This CIM model is analo-
gous to an operational architecture. The diagrams created as part of the CIM are then “trans-
formed” to the next lower level of detail, providing more detail (Figure 2). If the CIM defined
WHAT the system would do as it interacted with the “outside” world, the PIM will define HOW
it performs those capabilities or functions at the system level. While it would be desirable for this
to be an automated transformation in the future, in the near-term future, this transformation will
be a manual process.
The PIM level of the model will represent the system architecture, and the allocation of
customer requirements to the system requirements. While not explicitly discussed in the current
MDA Guideline, it may be necessary to create a multi-level PIM to capture the necessary levels
of detail to represent the complexity of the entire system while not providing too much detail in
any single model. For the SE, the PIM does not represent the computing platform, but rather the
complete deployment platform (tank, aircraft, ship, etc). In the PIM, the SE decomposes the
business rules and system requirements and they are transformed into a more specific detailing of
the system. Staying away from the specific programming languages and target platforms, the ma-
jor parts of the system begin to take form, as the capabilities of the system are more thoroughly
defined and derived. Common capability groups (allocated from the system specifications) and
logical subsystems begin to emerge from these groupings.

Figure 2 - MDA for SE Proposed Concept

 Another important concept in the MDA guideline is the use of patterns. A pattern is an
abstraction of a concept or design which has been used a number of times, and is valuable
enough to use on similar, future efforts. The pattern discussion in the MDA guideline discusses
the use of software patterns. Work is beginning to emerge on patterns for systems and systems
architecture [Cloutier, 2006a, Cloutier, 2006b] which will enable the application of a high level
system pattern to the CIM, and the decomposition of that pattern applied at the PIM.

3.1 A Brief SE MDA Example

To this point, this paper has provided some background on the original intent of MDA,
some new, enabling technologies in terms of systems engineering, and proposed how systems
engineers might apply MDA. This section will walk the reader through an overly simplistic rep-
resentation of a very complex problem of anti-submarine warfare. The “Hunt for Red October”
example is very incomplete and limited example of the application of MDA concepts to a sys-
tems engineering problem. However, the intent should be readily observable.
The land of Calimar has decided to build a new ship for their navy, and it must have the
ability to defend against a submarine attack. Several contractors are bidding on this new ship.
One company, SimpleShips, Inc. has decided to use the OMG’s new SysML and MDA for Sys-
tems Engineering approach during the system architecture and design phase of the proposal. The
team decides to model the anti-submarine warfare (ASW) mission to understand the capability
the new ship must possess.

MDA for SE Applied - Red October Scenario

uc Defend Against Submarine Threat
The Red October has left the
Green Sea, and is heading toward the
Nam e: Defend Against Submarine Threat
Package:
Version:
Computation Ind ependent Model
1. 0
nation of Calimar. The nation of Calimar
Author: Robert Clou tier, Ph.D. has a force capable of defending against
a submarine threat, and the force com-
Red Oc tober
(from Actors)
mander given the order to station their
Navy, modeled as the blue force, be-
Force Commander tween Calimar and the Red October to
National Assets
(from Actors) Defend Against Submarine
Threat (from Actors)
defend against this submarine threat. The
use case diagram for this is shown in
Figure 3.
The blue force commander has a
number of assets available to perform the
mission of homeland protection from this
Blue Forces Neutral Shipping
(from Actors) (from Actors) submarine. They include ships, aircraft,
Env ironment or other submarines. This is modeled as a
(from Actors) block definition diagram (Figure 4).

Figure 3 – Defend Against Submarine Threat

bdd Computation Independent Model [ASW Blue Forces]

Nam e: ASW Blue Forces

Package: Computation Ind ependent Model
Version: 1. 0
Author: R. Clouti er, Ph.D.

«block»
Blue AS W Force

«block»
Surfac e Ship Figure 4 –
Blue Force
directs
BDD
Orders «block» «block»
Searches for
ASW Commander directs Attack Submarine
Status

Red Oc tober
Force Commander
directs (from Actors)
(from Actors)

«block»
ASW Aircraft

act Defend Against ASW Threat

Using the Calimar naval
Nam e: Defend Against ASW Threat
Package: Computation Ind ependent Model tactics in place for performing
Version: 1. 0
Author: Robert Clou tier, Ph.D. ASW, the team knows develops
Blue Forces :Blue Forces Threat :Red October
the activity diagram (Figure 5) to
model the force defending against
Start
the Red October. Analyses of cur-
rent tactics allow that any combi-
Prepare ASW ASW Battle Plan
Battle Plan nation of ASW ships or ASW air-
craft can perform this important
mission. The Blue Force Conduct
Implement ASW
Battle Plan underwater search activity is de-
composed by first identifying the
use cases in the Conduct under-
Conduct
underw ater
search
water search activity.
On further consideration,
Contact Report
the team discovers that all ships in
Detect, Track &
Classify
Perform counter
detection activ ities
the Calimar force perform ASW
the same way, using the same
Track Number
technologies, and “Perform ASW
Search” pattern can be used here.
Enga geme nt
At the most basic level, there is a
Engage
Report
piece of ASW equipment, an
contact (from System) equipment operator, and someone
in charge. This basic pattern is
Assess ment
Report
added to the modeling tool for
Assessment
reuse in the future (Figure 6).
Rather than reinventing
this use case, they are in-
Figure 5 - Defend Against ASW Threat
uc Conduct Underw ater Search [Conduct Underw ater Search]

Nam e: Conduct Underwater Search corporated into whatever modeling tool

Package: Conduct Underwater Search
Version: 1. 0
they are using, as a pattern. The “Defend
Author: R. Clouti er, Ph.D.
Against ASW” activity diagram is then
tagged using either the tagging mecha-
nism identified by some future version
ASW equipment operator
(from Actors)
of the SysML specification, or a tagging
Perform ASW Search mechanism implemented by the tool
Command Authority
vendor, tagging the activity diagram to
(from Actors)
automatically apply the Perform Under-
«flow» water Search pattern during the model
«block» transformation from one level to the
ASW equipment
next using the more specific use cases
shown in Figure 7.

Figure 6 - Perform ASW Search Mission Pattern

uc Perform Surface ASW [Perform Surface Ship ASW Search]

uc Perform Aircraft ASW [Perform Aircraft ASW]

Nam e: Perform Surface Ship ASW Search

Package: Perform Surface ASW Nam e: Perform Aircraft ASW
Version: 1. 0 Package: Perform Aircraft ASW
Author: R. Clouti er, Ph.D. Version: 1. 0
Author: R. Clouti er, Ph.D.

MAD operator

Sonar O fficer
Sonar O perator
Perfor m Air ASW «block»
(from Actors)
(from Actors) Sea rch Radar
Surface Ship Sea rch for
Subma rine Pil ot
«block»
Sonar

«block»
Sonobuoy
Command Authority
«block»
Radar (from Actors)

Radar O perator
Sonobuoy Operator
(from Actors)

Figure 7 - Perform ASW Search Pattern Application

Therefore, when the CIM is “transformed” to the PIM as discussed earlier (and shown in
Figure 2), this pattern will be applied, depending on how the model was tagged. If the generic
Perform ASW Search use case model was tagged to use a surface ship, the use case would be
expanded by applying the Surface Ship Search for Submarine use case pattern. If the model was
tagged to use an aircraft, the Perform Air ASW Search pattern would be used. As is proposed in
this MDA for SE approach, if the CIM represents the CONOPS via a SysML model, then the
PIM models the system requirements and system architecture, and the allocation of those system
requirements to the subsystems. Some may argue this approach does not adhere to the spirit of
platform independence. However, the system and subsystem architecture at this point is still a
logical architecture, and is implementable on any number of ship or aircraft physical platforms.
 4.0 Conclusions
While this paper began by briefly reviewing the current model driven architecture con-
cepts, the real purpose was to discuss MDA in the context of modeling the systems architecture
and design of a system. The gains in the software community have been impressive for those or-
ganizations willing to adopt MDA as part of their software engineering methodology. This paper
hypothesizes that MDA may provide a 10-20% efficiency improvement of existing systems en-
gineering efforts once the methodology is understood and adapted for systems engineering. If the
systems engineering effort for complex systems costing hundreds of millions amounts to 5 to
10%, the resulting savings could be between 500K and 2M, in addition to the software engineer-
ing savings.
A simplified example applying MDA concepts was demonstrated using simple SysML
models. A discussion and demonstration of the application of a system level pattern was also
presented.

References
Cloutier and Verma, Applying Pattern Concepts to Enterprise Architecture, Enterprise Architec-
ture Journal 2(2), May 2006, pgs 34–50.
Cloutier, Applicability of Patterns to Architecting Complex Systems, Doctoral Dissertation, Ste-
vens Institute of Technology, 2006
Cloutier and Verma, Applying the Concept of Patterns to Systems Architecture, Systems Engi-
neering, Wiley Periodicals, Inc., Vol. 10, No. 2, 2007.
INCOSE, Systems Engineering Handbook, International Council on Systems Engineering, ver-
sion 2a, June, 2004.
MDA Guide Version 1.0.1, Document Number: omg/2003-06-01, dated 12th June 2003. Avail-
able at: http://www.omg.org/cgi-bin/doc?omg/03-06-01.
SysML, Systems Modeling Language (OMG SysMLTM) Version 1.0, Document Number: for-
mal/2007-09-01, dated 07-09-01, downloaded from http://www.omg.org/cgi-
bin/doc?formal/2007-09-01

Robert Cloutier (Rob) has over 20 years experience in systems engineering, soft-
ware engineering, and project management in both commercial and defense in-
dustries. His research interests include Systems Engineering Patterns, MDA and
SOA for systems engineering. Rob received his Ph.D. in Systems Engineering
from Stevens Institute of Technology, and also holds an M.B.A. from Eastern
University, and a B.S. from the United States Naval Academy. Rob belongs to the
International Council on Systems Engineering (INCOSE), is a member of the Technical Leader-
ship Team. He is also an active member of the Association of Enterprise Architects, and IEEE.
Finally, he and his wife raise puppies for The Seeing Eye to serve as guide dogs to the blind.

View publication stats