New_MDA.ppt 6636KB Jun 23 2011 12:14:54 PM

(1)

F-16 Modular Mission Computer

Application Software

Achieving Cross-Platform Compatibility with

Increased Productivity and Quality using the

OMG’s Model Driven Architecture

Lauren E. Clark

Lauren E. Clark

Chief Engineer

F-16 Modular Mission Computer Software

Lockheed Martin Aeronautics Company

Terry Ruthruff

Staff Specialist

Software Engineering Core

Software Engineering Core

Allan Kennedy

Managing Director

Kennedy Carter Limited

Bary D. Hogan

Methodology Lead

F-16 Modular Mission Computer Software

(2)

Agenda



The Platform



Cross-Platform Compatibility: The Goal



The eXecutable MDA Approach:



eXecutable UML Modeling



Platform Specific Mapping (Design Tagging)



Automatic Code Generation

(3)

Software

Basic Software Components

Hardware

Software Execution

Platform

Application Software Interface

Application Software:

 High-level software that is unique to

the application(s) for which the

embedded computer (i.e. subsystem) exists

 80-90% of the total software (in terms

of long-term development cost)

Application Software:

 High-level software that is unique to

the application(s) for which the

embedded computer (i.e. subsystem) exists

 80-90% of the total software (in terms

of long-term development cost)

Software Execution Platform:

 Low-level software, the purpose of

which is to provide services that allow the Application Software to run on the hardware

Software Execution Platform:

(4)

Software Execution

Platform

Board Support Package / BIT

Software Execution Platform

Hardware

Application Software Interface

Device Drivers Operating System

Software Architecture _{Software Execution Platform:}

which is to provide services that allow the Application Software to run on the hardware

Software Execution Platform:

(5)

Software Execution

Platform

Device Drivers Operating System Software Architecture

Software Architecture

Hardware

Application Software Interface

Software Architecture:

 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

Software Architecture:

 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

Board Support Package / BIT

Software Architecture

(6)

Application Software InterfaceApplication Software Interface

Application Software Interface

Software Execution

Platform

Device Drivers Operating System Software Architecture

Application Software Interface

Hardware

Application Software Interface:

 The boundary between the Application

Software and the Software Execution Platform

 The specified methods by which the

Application Software can make

requests and use the services of the Software Execution Platform and the Software Execution Platform can

provide its services to the Application Software

 This interface is specified by the

Application Software Interface:

 The boundary between the Application

Software and the Software Execution Platform

 The specified methods by which the

Application Software can make

requests and use the services of the Software Execution Platform and the Software Execution Platform can

provide its services to the Application Software

 This interface is specified by the

(7)

Hardware Platform #2

Board Support Package / BIT

Board Support Package / BIT

Device Drivers

Device Drivers Operating SystemOperating System Software Architecture

Software Architecture Application Software Interface

Hold Constant

Hardware

Cross-Platform Compatibility: The Usual Approach

Hardware Platform #1

Application Software Interface

Device Drivers Operating System Software Architecture

Maintain a constant Application Software Interface

(8)

Hardware Platform

Cross-Platform Compatibility Issues

Device Drivers

Can a constant

Application Software Interface

always be maintained?

Consider…

 What if the language or operating

system becomes obsolete?

 What if it is necessary to port even

a part of the Application Software to a legacy platform not having the resources to support the newer Software Execution Platforms?

Consider…

 What if the language or operating

system becomes obsolete?

 What if it is necessary to port even

(9)

Hardware Platform

Cross-Platform Compatibility Issues

Device Drivers

Even if it were possible, would one

always want to maintain a constant

Application Software Interface?

Consider…

 What if hardware or Software

Execution Platform changes could provide more Application Software capability, but only by means of changing the Application Software Interface?

Consider…

 What if hardware or Software

(10)

Hardware Platform

Cross-Platform Compatibility: The Goal

Device Drivers

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

(11)

eXecutable MDA: Application Software Development

eXecutable UML

Modeling

Requirements

Definition

Integration

& Test

Platform Specific

Mapping

(Design Tagging)

Automatic

Code Generation

Application

Software

Interface

Definition

The eXecutable

MDA Approach

as supported by as supported by

KC’s iUML and iCCG

(12)

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

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

(13)

eXecutable UML Modeling: Class Diagrams

Class Diagrams:

 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

Class Diagrams:

 Within each platform

independent domain model, conceptual entities

are modeled first: classes,attributes, and associations are abstracted

 Behavior, though considered, is

(14)

eXecutable UML Modeling: State Charts

State Charts:

 Behavior is formalized during

state modeling

 Class lifecycles are modeled

using signal-driven state machines

 Class operations are defined

State Charts:

 Behavior is formalized during

state modeling

 Class lifecycles are modeled

using signal-driven state machines

(15)

eXecutable UML Modeling: 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

the newly adopted Precise Action Semantics for the UML

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

(16)

eXecutable UML Modeling: Simulation

Simulation:

 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

Simulation:

 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

(17)

Design Tags

 Class Allocation  Program Allocation  Max Instance Count  Event Rate

 Event Queue  Throw Away  Initialization  Source Type  Subtype of  etc.

Design Tags

 Class Allocation

 Program Allocation

 Max Instance Count

 Event Rate

 Event Queue

 Throw Away

 Initialization

 Source Type

 Subtype of

 etc.

Design Tagging: Specifying the PIM to PSM Mapping

Source Code Files

...

Automatic

Code Generator

xUML Models

...

Application Software Interface Definition

Software Execution Platform Specific

Software Execution Platform Specific

Language Specific

(18)

Design Tagging: Specifying the PIM to PSM Mapping

Design Tagging:

 Design tag values represent

implementation-specific design decisions

 Design tagging is applied to,

but not embedded in, the xUML models (tags and tag values may be included or excluded)

 Code Generator assumes the

most standard implementation, such that only exceptions must be tagged

Design Tagging:

 Design tag values represent

implementation-specific design decisions

 Design tagging is applied to,

but not embedded in, the xUML models (tags and tag values may be included or excluded)

 Code Generator assumes the

(19)

Model of Platform

...

Automatic Code Generation: 3 Levels of Models

Model of xUML

...

xUML Elements:

(e.g. Class, Attribute, Association,

Tag, etc.)

xUML Elements:

(e.g. Class, Attribute, Association, Tag, etc.) Model of Application

...

Application Elements:

(e.g. Aircraft, Missile, Target, etc.) Application Elements:

(e.g. Aircraft, Missile, Target, etc.)

Implementation Elements:

(e.g. Procedure, Array, Program, Event

Queue, etc.)

Implementation Elements:

(20)

Model of xUML

...

xUML Elements:

Tag, etc.)

xUML Elements:

(e.g. Class, Attribute, Association, Tag, etc.) Level 2 Level 2 Supplied by Kennedy Carter Supplied by Kennedy Carter

Automatic Code Generation: Level 2 - Simulation Code

Step 1:

Step 1: Populate instances Populate instances of

of xUML Metamodel withxUML Metamodel with

Code Generation: Code Generation: Generation of Generation of Simulation Code Simulation Code for Development for Development Platform Platform

(e.g. UNIX C Code)

(e.g. UNIX C Code) Model of Application

...

(e.g. Aircraft, Missile, Target, etc.) Level 1 Level 1 Developed by Program Developed by Program

When we say that “xUML models are executable” we mean that

(21)

...

Queue, etc.)

Implementation Elements:

(e.g. Procedure, Array, Program, Event Queue, etc.) Level 3 Level 3 Developed by Program Developed by Program Model of xUML

...

xUML Elements:

Tag, etc.)

xUML Elements:

(e.g. Class, Attribute, Association, Tag, etc.) Level 2 Level 2 Supplied by Kennedy Carter Supplied by Kennedy Carter

Automatic Code Generation: Level 3 - Target Code

Step 1:

of xUML Metamodel withxUML Metamodel with

Model of Application

...

(e.g. Aircraft, Missile, Target, etc.) Level 1 Level 1 Developed by Program Developed by Program Step 2:

of Model of ImplementationModel of Implementation

with

with populated xUMLpopulated xUML Metamodel instances Metamodel instances Code Generation: Code Generation: Generation of Generation of Source Code Source Code for Target for Target (Embedded) (Embedded) Platform Platform

(e.g. Ada/C++ Code)

(22)

The Code Generator The Code Generator

...

Queue, etc.)

(e.g. Procedure, Array, Program, Event Queue, etc.) Level 3 Level 3 Developed by Program Developed by Program Model of xUML

...

xUML Elements:

Tag etc.)

xUML Elements:

(e.g. Class, Attribute, Association, Tag etc.) Level 2 Level 2 Supplied by Kennedy Carter Supplied by Kennedy Carter

Automatic Code Generation: The Code Generator

Model of Application

...

(e.g. Aircraft, Missile, Target, etc.) Level 1 Level 1 Developed by Program Developed by Program Generated Generated Source Code Source Code for Target for Target Platform Platform

The Code Generator includes all implementation-dependent details

(23)

Automatic Code Generation: Code Generator Development

Configurable Code Generator:

 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

Configurable Code Generator:

 Code Generator is developed

using the same eXecutable MDA strategy

 Kennedy Carter supplies a

(24)

Automatic Code Generation: Code Generator Development

Code Generator Development:

 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 ment may be performed

concurrently

Code Generator Development:

 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 ment may be performed

(25)

Automatic Code Generation: Summary

 _{Automatic code generation is simply an}_{Automatic code generation is simply an}

extension of the code generation technique

extension of the code generation technique

used for simulation of the eXecutable UML

models on the development platform, this

extension being for the target (embedded)

extension being for the target (embedded)

platform

 _{The code generator is developed within the}_{The code generator is developed within the}

same environment as the application

software using the same eXecutable MDA

strategy

 _{Development cost: 1-2 architects}_{Development cost: 1-2 architects}

 _{Nearly all implementation-specific design}_{Nearly all implementation-specific design}

tasks (all but the design decisions

tasks (all but the design decisions

represented by design tag values) are

performed by the code generator, not the

software developers

(26)

Automatic Code Generator

Portable Application Software Products

Source Code

Application

Software

Interface

eXecutable UML

Models

Program Specific

Mapping

(Design Tag Values)

Automatic Code Generator

Program Specific

Mapping

(Design Tag Values)

Source Code

Application

Software

Interface

eXecutable UML

Models

The Portable Products

(and therefore the Configured Products (and therefore the Configured Products to be placed in an Enterprise-Level to be placed in an Enterprise-Level Software Reuse Library)

(27)

Advantages of the eXecutable MDA Approach

 _{The majority of software developers are}_{The majority of software developers are}

isolated from implementation details,

isolated from implementation details,

allowing them to focus on a thorough

analysis of the application space

 _{Maintenance of the application source code}_{Maintenance of the application source code}

is eliminated, while maintenance of the xUML

models is ensured

models is ensured

 _{Defect injection (and the resulting rework) is}_{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}_{On a typical program, after Requirements} Definition approximately 2/3 of the defects

Definition approximately 2/3 of the defects

are injected during implementation

(coding)

Increased Quality

(28)

 _{Rework is reduced}_{Rework is reduced}

 _{Early validation through simulation}_{Early validation through simulation}

reduces rework

reduces rework

 _{Increase in eXecutable UML modeling span}_{Increase in eXecutable UML modeling span}

time is more than offset by decrease in

Integration & Test span time

 _{Higher quality implementation (due to}_{Higher quality implementation (due to}

automation) reduces rework

automation) reduces rework

 _{Software development span time is reduced}_{Software development span time is reduced}

by automating the implementation phase

 _{Application Software development}_{Application Software development}

schedule is reduced by at least 20%

schedule is reduced by at least 20%  _{The code generator, not each software}_{The code generator, not each software}

developer, performs the majority of

developer, performs the majority of

implementation-specific design tasks

Increased Productivity

(29)

 _{One Application Software xUML Model}_{One Application Software xUML Model}

database may be reused (as is) on any

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}_{xUML models are compatible with any} hardware platform, any Software

hardware platform, any Software

Execution Platform, and any Application

Execution Platform, and any Application

Software Interface

 _{xUML models are compatible with any}_{xUML models are compatible with any} implementation language

implementation language

Cross-Platform Compatibility

The Goal of Cross-Platform Compatibility of Application Software

The Goal of Cross-Platform Compatibility of Application Software

is Attainable with the eXecutable MDA Approach

The Goal of Cross-Platform Compatibility of Application Software

is Attainable with the eXecutable MDA Approach

(30)

eXecutable MDA: Summary of Key Themes

 _{The platform is an xUML virtual machine (but platform independent}_{The platform is an xUML virtual machine (but platform independent}

models can’t assume anything about the interface)

models can’t assume anything about the interface)

 _{To validate PIMS as long-life assets we need eXecutable UML}_{To validate PIMS as long-life assets we need eXecutable UML}  _{eXecutable UML needs an action language, not a 3GL}_{eXecutable UML needs an action language, not a 3GL}

 _{Systems are integrated from multiple platform independent models}_{Systems are integrated from multiple platform independent models}  _{PIMS offer contracts for required and provided services}_{PIMS offer contracts for required and provided services}

 _{100% code generation is essential to make MDA a lightweight process}_{100% code generation is essential to make MDA a lightweight process}  _{But don’t worry – its just another type of expert knowledge to formalise}_{But don’t worry – its just another type of expert knowledge to formalise}

in xUML

in xUML

 _{It works}_{It works}

(31)

Projects Using eXecutable MDA with KC’s Tools



BAE Systems: Stingray torpedo MLU



TRW Automotive: vehicle stability system



Siemens Metering: ‘intelligent’ gas meter



Thales: Nimrod MR4 crew trainers



GD Government Systems: ATM Switch for US Army



Royal Netherlands Navy: combat systems



Nortel Networks: Passport Voice Gateway



GCHQ: classified distributed application

(32)

Contact Information

Lauren E. Clark

Lauren E. Clark

Chief Engineer

Terry Ruthruff

Staff Specialist

Software Engineering Core

Software Engineering Core

[email protected]

(817) 763-2748

Bary D. Hogan

Methodology Lead

Lockheed Martin Aeronautics Company

(817) 763-3525

(817) 763-2620

Allan Kennedy

Managing Director

Kennedy Carter Limited

allan

allan[email protected][email protected] (+44) 1483 226 180