Transcript F-16 Modular Mission Computer Application Software

Model Driven Architecture
and eXecutable UML:
The Next Evolutionary Step?
Allan Kennedy
Founder, Kennedy Carter Ltd
www.kc.com
KENNEDY CARTER
MDA: The Important Ideas
 Three primary viewpoints for modelling
 The Computation Independent Model (CIM)
 Precise business model, oriented to stakeholders, uncommitted to specific
algorithms or system boundary. Also known as a Domain Model.
 The Platform Independent Model (PIM)
 Precise, computationally complete (executable), uncommitted to any specific
platform (portable), oriented to stakeholders (prototyping) and developers (a
testable specification), a long life asset
 The Platform Specific Model (PSM)
 Precise, complete, conforms to constraints of a specific (class of) platform(s),
probably generated from a PIM, oriented to technology experts
 Interoperability defined at the model level, not the middleware level
 Models are integrated in order to construct complete systems
 Models are derived from other models by automated transformation
 So, MDA promises to be rigorous but lightweight, -> agile modelling
K
E
N
N
E
D
Y
C
Real Engineers Use A Rigorous Process
Construct the system from
large, reusable components
Establish a welldefined and
automated
construction
process
To build this
K
E
N
N
E
D
Y
C
Build precise,
predictive models
Subject the models to
rigorous testing before
implementation
MDA with eXecutable UML - What Real Software Engineers Need
Construct the system from
large, reusable components
SPECIFY DOMAINS
Identify new/reused domains
Establish a welldefined and
automated
construction
process
Build precise,
predictive models
Model system use cases
SPECIFY SYSTEM
CONSTRUCTION PROCESS
BUILD PLATFORM-INDEPENDENT MODELS
(PIMS)
Define/Buy PIM To PSI Mapping Rules
Model domain use cases
Build/Buy PIM compiler
Build Static Model - Class Diagram
Build Dynamic Model - State Charts & Interactions
Build Action Model - Operations & State Actions
Compile and debug PIMS
Subject the models to
rigorous testing before
implementation
To build this
GENERATE SYSTEM
VALIDATE PIMS
Apply PIM to PSI Mapping Rules
(Execute PIM Compiler)
Execute domain use cases
Perform target testing
K
E
N
N
E
D
Y
C
Execute system use cases
Projects Using MDA with eXecutable UML (and 100% Code Generation)












K
US DoD: Single Integrated Air Picture (C++, HLA/RTI)
Lockheed Martin Aeronautics: F16 MMC (Ada 83, Ada 95)
BAE Systems: Stingray torpedo MLU (Ada 95)
Thales: Nimrod MR4 crew trainers (C++)
GD Government Systems: ATM Switch for US Army (C)
Royal Netherlands Navy: combat systems (C++)
GCHQ: classified distributed application (C, objectstore)
BAE Systems: Management of obsolescence (Structured Analysis, Ada)
TRW Automotive: vehicle stability system (efficient C)
Siemens Metering: ‘intelligent’ gas meter (C)
Nortel Networks: Passport Voice Gateway (C++)
UK NHS: ebookings, patient control of access to medical records (C++)
E
N
N
E
D
Y
C
But Why MDA?
 The usual reasons - Faster, Better, Cheaper
 Faster better cheaper development processes that result in…
 …systems that can be ported readily to faster better cheaper platforms
as they become established
K
E
N
N
E
D
Y
C
MDA is about formalising your knowledge and expertise
 Whatever development method you follow, system development exposes and/or
generates a considerable quantity of knowledge about the actual and planned
architecture (at all levels) of a system or system of systems
 MDA promises to provide a set of languages for formalising that knowledge as
stakeholder-friendly models that can be verified for correctness…
 End-User knowledge about the enterprise
 Systems and IT knowledge about platforms
 Programmer knowledge about best development practice
 …and that can be leveraged to automate the production of downstream
deliverables.
 If, additionally, the models are PIM’s, then they have the potential to be
strategic long life assets.
K
E
N
N
E
D
Y
C
F-16 Modular Mission Computer
Application Software
Model Driven Architecture and Executable UML:
The Lockheed Martin Experience
Lauren E. Clark
Chief Engineer
F-16 Modular Mission Computer Software
Lockheed Martin Aeronautics Company
Terry Ruthruff
Staff Specialist
Software Engineering Core
Lockheed Martin Aeronautics Company
Bary D. Hogan
Methodology Lead
F-16 Modular Mission Computer Software
Lockheed Martin Aeronautics Company
Allan Kennedy
Managing Director
Kennedy Carter Limited
© 2001 Lockheed Martin Corporation
Lockheed Martin Aeronautics Company
F16 MMC Background
 F-16 originally designed as a lightweight air superiority fighter
 Jointly built by Belgium, Denmark, Netherlands, Norway, US
 First F-16A flew Dec 76, first operational Jan 1979
 More than 4,000 F-16s manufactured to date
 Modular Mission Computer (MMC) in post-July 1996 aircraft
 Also to be retrofitted to 1,000 earlier aircraft
 Replaces computers for Fire Control, Head-up display, Stores
management
 Multiple MIPS R3000 64-bit CPUs, 60 MB memory, 155 MIPs
 30x throughput & memory at 60% weight, volume & power
K
E
N
N
E
D
Y
C
Agenda
 The Platform
 Cross-Platform Compatibility: The Goal
 Implementing MDA with eXecutable UML:
 Platform Independent Modeling
 Platform Specific Mapping (Design Tagging)
 Configurable 100% Code Generation
 Benefits derived from using MDA
K
E
N
N
E
D
Y
C
Software Architecture
Software Architecture:
Application Software
Application Software Interface
Software Architecture
Software Execution
Operating System
Platform
Device Drivers
Board Support Package / BIT
Hardware
K
E
N
N
E
D
Y
C

Low-level software providing the
framework within which the Application
Software executes

Provides execution control, data /
message management, error handling,
and various support services to the
Application Software
 Assumes
a particular Application
Software language

Unique to the hardware; but, since it
must support all requirements levied
by the Application Software, is not
delivered with the hardware
Cross-Platform Compatibility: The Usual Approach
Maintain a constant Application Software Interface
Portable
Application Software
Application Software
Hold
Constant
Application Software Interface
Application Software Interface
Software Architecture
Software Architecture
Device Drivers
K
E
N
Operating System
Device Drivers
Operating System
Board Support Package / BIT
Board Support Package / BIT
Hardware
Hardware
Platform #1
Hardware Platform #2
N
E
D
Y
C
Cross-Platform Compatibility: The Goal
Application Software
Application Software Interface
Software Architecture
Device Drivers
Operating System
Board Support Package / BIT
Hardware Platform
K
E
N
N
E
D
Y
C
The goal
should be to provide
cross-platform compatibility
of Application Software
despite any
Implementation,
or platform specific, changes:
that is, changes to
the Hardware Platform,
the Software Execution Platform,
or the
Application Software Interface
MDA with eXecutable UML: Development Process
as supported by
KC’s iUML and iCCG
Requirements
Definition
eXecutable UML
Modeling
Platform Specific
Mapping
(Design Tagging)
Application
Software
Interface
Definition
K
E
N
N
E
D
Automatic
Code Generation
Y
C
Integration
& Test
MDA with eXecutable UML - What Real Software Engineers Need
Construct the system from
large, reusable components
SPECIFY DOMAINS
Identify new/reused domains
Establish a welldefined and
automated
construction
process
Build precise,
predictive models
Model system use cases
SPECIFY SYSTEM
CONSTRUCTION PROCESS
BUILD PLATFORM-INDEPENDENT MODELS
(PIMS)
Define/Buy PIM To PSI Mapping Rules
Model domain use cases
Build/Buy PIM compiler
Build Static Model - Class Diagram
Build Dynamic Model - State Charts & Interactions
Build Action Model - Operations & State Actions
Compile and debug PIMS
Subject the models to
rigorous testing before
implementation
To build this
GENERATE SYSTEM
VALIDATE PIMS
Apply PIM to PSI Mapping Rules
(Execute PIM Compiler)
Execute domain use cases
Perform target testing
K
E
N
N
E
D
Y
C
Execute system use cases
eXecutable UML Modeling: Domain Model
Domain Model
(Package Diagram):
The software application space
is partitioned into multiple
platform independent domain
models
 Mappings between the
domains are defined as contracts
for required and provided
services

K
E
N
N
E
D
Y
C
MDA with xUML: Class Diagrams
Class Diagrams:
K
E
N
N
E
D
Y
C

Within each platform
independent domain model,
conceptual entities
are modeled first:
classes,attributes, and
associations are abstracted

Behavior, though considered, is
not modeled explicitly in this
view
MDA with xUML: State Charts
State Charts:
K
E
N
N
E
D
Y
C

Behavior is formalized during
state modeling

Class lifecycles are modeled
using signal-driven state
machines

Class operations are defined
MDA with xUML: Action Language
Action Specification Language:

State actions and class
operations are specified using
Kennedy Carter’s Action
Specification Language (ASL)
 ASL
is a higher order and much
simpler language than a typical
high order language (e.g. C++)
 ASL
deals with UML concepts,
not implementation concepts
 ASL
was a major influence on
Precise Action Semantics for the
UML adopted with UML 1.5
K
E
N
N
E
D
Y
C
MDA with xUML: Testing PIM’s
Simulation:
K
E
N
N
E
D
Y
C

Since a precise Action
Specification Language is used,
models are executable and
therefore may be simulated

Simulation features resemble
those of a high order language
debugger

Models may be validated long
before they are implemented
MDA with xUML: Integrating Models
Air Traffic Control System Build Set
counterpart
association
CPR1
counterpartIcon = this -> CPR1
$USE UI
[ ] = makeIconFlash[ ] on
counterpartIcon
$ENDUSE
Bridge
operation
requestPermission
ToTaxi
Aircraft
required
operation
<<required
interface>>
Air Traffic
Controller
Air Traffic Control Domain
K
E
N
N
E
D
Y
C
<<provided
interface>>
Client
makeIcon
Flash
Icon
provided
operation
User Interface Domain
MDA with eXecutable UML - What Real Software Engineers Need
Construct the system from
large, reusable components
SPECIFY DOMAINS
Identify new/reused domains
Establish a welldefined and
automated
construction
process
Build precise,
predictive models
Model system use cases
SPECIFY SYSTEM
CONSTRUCTION PROCESS
BUILD PLATFORM-INDEPENDENT MODELS
(PIMS)
Define/Buy PIM To PSI Mapping Rules
Model domain use cases
Build/Buy PIM compiler
Build Static Model - Class Diagram
Build Dynamic Model - State Charts & Interactions
Build Action Model - Operations & State Actions
Compile and debug PIMS
Subject the models to
rigorous testing before
implementation
To build this
GENERATE SYSTEM
VALIDATE PIMS
Apply PIM to PSI Mapping Rules
(Execute PIM Compiler)
Execute domain use cases
Perform target testing
K
E
N
N
E
D
Y
C
Execute system use cases
MDA with xUML: PIM to PSM Mappings
 xUML Process supports fully automatic transformation to PSMs
 Mapping rules can be specified …
(part of)
xUML
(part of)
Design Metamodel
(object-based)
(part of)
Ada 83 Metamodel
Class
Class
Package
Attribute
PrivateDatum
BodyVariable
Signal
PublicMethod
SpecSubprogram
Define
Mapping
xUML
Metamodel
K
E
N
N
E
D
Y
C
Design
Metamodel
Define
Mapping
Implementation
Metamodel
MDA with xUML: Mark-ups
Design Tags
Class Allocation
 Program Allocation
 Max Instance Count
 Event Rate
Software Execution
 Event Queue
Platform Specific
 Throw Away
 Initialization
 Source Type
Language
 Subtype of
Specific
 etc.

xUML Models
...
...
Defines
Automatic
Code Generator
Application Software Interface Definition
K
E
N
N
E
D
Y
C
Source Code Files
...
...
...
...
Automatic Code Generation: Simulation Code
When we say that “xUML models are executable” we mean that
“executable code can be automatically generated from them”
Model
of
Application
Developed
by
Program
Model
of
xUML
Supplied by
Kennedy
Carter
...
Code Generation:
Generation of
Simulation Code
for Development
Platform
(e.g. UNIX C Code)
...
...
...
Application
Elements:
(e.g. Aircraft, Missile,
Target, etc.)
K
E
N
N
E
D
Y
C
xUML Elements:
(e.g. Class, Attribute,
Association,
Tag, etc.)
Step 1: Populate instances
of xUML Metamodel with
Model of Application
Automatic Code Generation: Target Code
Model
of
Application
Developed
by
Program
Model
of
xUML
Supplied by
Kennedy
Carter
Model
of
Platform
Developed
by
Program
...
Code Generation:
Generation of
Source Code
for Target
(Embedded)
Platform
(e.g. Ada/C++ Code)
...
...
...
...
...
Application
Elements:
(e.g. Aircraft, Missile,
Target, etc.)
K
E
N
N
E
D
Y
Implementation
Elements:
(e.g. Procedure, Array,
Program, Event
Queue, etc.)
C
xUML Elements:
(e.g. Class, Attribute,
Association,
Tag, etc.)
Step 1: Populate instances
of xUML Metamodel with
Model of Application
Step 2: Populate instances
of Model of Implementation
with populated xUML
Metamodel instances
Automatic Code Generation: The Code Generator
Model
of
Application
Developed
by
Program
Model
of
xUML
Supplied by
Kennedy
Carter
Model
of
Platform
Developed
by
Program
...
Generated
Source Code
for Target
Platform
...
...
...
...
...
Application
Elements:
(e.g. Aircraft, Missile,
Target, etc.)
K
E
N
N
E
D
Y
Implementation
Elements:
(e.g. Procedure, Array,
Program, Event
Queue, etc.)
C
xUML Elements:
(e.g. Class, Attribute,
Association,
Tag etc.)
The Code Generator
The Code Generator includes all implementation-dependent details
(those dependent upon the Application Software Interface – specific to the
Hardware, the Software Execution Platform, the Implementation Language)
The iCCG Framework
Configurable Code Generator:
K
E
N
N
E
D
Y
C

Code Generator is developed
using the same eXecutable
MDA strategy

Kennedy Carter supplies a
set of xUML models (known
as the Configurable Code
Generator) that serve as a
generic translation framework
MDA with xUML: PIM-PSM Mapping Rules in ASL
 Systematic Mappings are expressed by Action Language operating
on the xUML (meta)model:
has
Class
R2
name
keyLetter
is provided
by
Mapping Rules in ASL
0..*
{allClasses} = find-all Class
for eachClass in {allClasses} do
$FORMAT code_file
class Class[T:eachClass.name]
{
public:
$ENDFORMAT
{theOperations} = eachClass -> R2
for eachOperation in {theOperations} do
$FORMAT code_file
[T:eachOperation.type] [T:eachOperation.name]();
$ENDFORMAT
endfor
$FORMAT code_file
private:
static char *[T:eachClass.name];
static char *[T:eachClass.keyLetter];
$ENDFORMAT
endfor
K
E
N
N
E
D
Y
C
0..*
Operation
Name
type
C++ Code Archetype
class Class<ClassName>
{
public:
<returnType1> <operationName1>();
<returnType2> <operationName2>();
//……….
private:
static char *className;
static char *classKeyLetter;
//…….
<attribute1Type> <attributeName1>;
<attribute2Type> <attributeName2>;
<attribute3Type> <attributeName3>;
<attribute4Type> <attributeName4>;
//…….
};
Extending iCCG with a Platform Model
Code Generator Development:
K
E
N
N
E
D
Y
C

The Configurable Code
Generator (iCCG) may be
adapted to the meet the
requirements of any Platform
Specific Implementation (i.e.
of any Application Software
Interface)

Code Generator and
Application Software development may be performed
concurrently with the same
methods and tools
Configurable Code Generation -Summary
{allClasses} = find-all Class
for eachClass in {allClasses} do
$FORMAT code_file
class Class[T:eachClass.name]
{
public:
$ENDFORMAT
{theOperations} = eachClass -> R2
for eachOperation in {theOperations} do
$FORMAT code_file
[T:eachOperation.type] [T:eachOperation.name]();
$ENDFORMAT
endfor
$FORMAT code_file
private:
static char *[T:eachClass.name];
static char *[T:eachClass.keyLetter];
$ENDFORMAT
endfor
Class
R2
name
keyLetter
Operation
Name
type
iCCG Provided
Metamodels
iCCG
Code
Generator
Project’s
code
Project written mappings in ASL
Generate an executable
using an existing code
generator
Wheel
R17
number
current speed
Valve
number
state
Project
Code
Generator
Project domain models
K
E
N
N
E
D
Y
C
Can support very sophisticated mappings
Portable Application Software Products
The Portable Products
eXecutable UML
Models
(and therefore the Configured Products
to be placed in an Enterprise-Level
Software Reuse Library)
Program Specific
Mapping
(Design Tag Values)
Automatic Code Generator
Source Code
K
E
N
N
E
D
Y
C
Application
Software
Interface
Advantages of the MDA with xUML Approach
Increased Quality
 The majority of software developers are
isolated from implementation details, allowing
them to focus on a thorough analysis of the
application space
 Maintenance of the application source code is
eliminated, while maintenance of the xUML
models is ensured
 Defect injection (and the resulting rework) is
reduced by automating the software phase in
which most defects are injected
 On a typical program, after Requirements
Definition approximately 2/3 of the defects
are injected during implementation (coding)
K
E
N
N
E
D
Y
C
Advantages of the MDA with xUML Approach
Increased Productivity
 Rework is reduced
 Early validation through simulation reduces
rework
 Increase in eXecutable UML modeling span
time is more than offset by decrease in
Integration & Test span time
 Higher quality implementation (due to
automation) reduces rework
 Software development span time is reduced by
automating the implementation phase
 Application Software development schedule
is reduced by at least 20%
 The code generator, not each software
developer, performs the majority of
implementation-specific design tasks
 40-60% of physical source code
K
E
N
N
E
D
Y
C
Advantages of the MDA with xUML Approach
Cross-Platform Compatibility
 One Application Software xUML Model
database may be reused (as is) on any platform
for which a mapping is defined (ie: a code
generator is developed)
 xUML models are compatible with any
hardware platform, any Software Execution
Platform, and any Application Software
Interface
 xUML models are compatible with any
implementation language
The Goal of Cross-Platform Compatibility of Application Software
is Attainable with the OMG’s MDA supported by eXecutable UML
K
E
N
N
E
D
Y
C
Further Reading:
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
K
E
N
N
E
D
Y
C