F-16 Modular Mission Computer Application Software

Transcription

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 Chief Engineer F-16 Modular Mission Computer Software Bary D. Hogan Methodology Lead F-16 Modular Mission Computer Software Terry Ruthruff Staff Specialist Software Engineering Core Allan Kennedy Managing Director Kennedy Carter Limited 2001 Lockheed Martin Corporation

2 Agenda The Platform Cross-Platform Compatibility: The Goal The executable MDA Approach: executable UML Modeling Platform Specific Mapping (Design Tagging) Automatic Code Generation Benefits derived from using executable MDA

3 Basic Software Components Application Software Software Application Software: High-level software that that is is unique unique to to the the application(s) for for which which the the embedded computer (i.e. (i.e. subsystem) exists exists 80-90% of of the the total total software (in (in terms terms of of long-term development cost) cost) Application Software Interface Software Execution Platform Hardware Software Execution Platform: Low-level software, the the purpose of of which which is is to to provide provide services that that allow allow the the Application Software to to run run on on the the hardware

4 Software Execution Platform Application Software Application Software Interface Software Execution Platform Device Drivers Software Architecture Board Support Package / BIT Hardware Operating System Software Execution Platform: Low-level software, the the purpose of of which which is is to to provide provide services that that allow allow the the Application Software to to run run on on the the hardware

5 Software Architecture Application Software Application Software Interface Software Architecture Software Execution Platform Device Drivers Operating System Board Support Package / BIT Software Architecture: Low-level software providing the the framework within within which which the the Application Software executes Provides execution control, control, data data // message management, error error handling, and and various various support services to to the the Application Software Assumes a particular Application Software language Unique Unique to to the the hardware; but, but, since since it it must must support all all requirements levied levied by by the the Application Software, is is not not delivered with with the the hardware Hardware

6 Application Software Interface Application Software Application Software Interface Software Execution Platform Device Drivers Software Architecture Operating System Board Support Package / BIT Application Software Interface: The The boundary between the the Application Software and and the the Software Execution Platform The The specified methods by by which which the the Application Software can can make make requests and and use use the the services of of the the Software Execution Platform and and the the Software Execution Platform can can provide provide its its services to to the the Application Software This This interface is is specified by by the the Software Execution Platform Hardware

7 Cross-Platform Compatibility: The Usual Approach Maintain a constant Application Software Interface Application Software Portable Application Software Application Software Interface Software Architecture Hold Constant Application Software Interface Software Architecture Device Drivers Operating System Device Drivers Operating System Board Support Package / BIT Hardware Hardware Platform #1 Board Support Package / BIT Hardware Platform #2

8 Cross-Platform Compatibility Issues Application Software Application Software Interface Device Drivers Software Architecture Operating System Board Support Package / BIT Hardware Platform Can a constant Application Software Interface always be maintained? Consider What What if if the the language or or operating system system becomes obsolete? What What if if it it is is necessary to to port port even even a part part of of the the Application Software to to a legacy legacy platform not not having having the the resources to to support the the newer newer Software Execution Platforms?

9 Cross-Platform Compatibility Issues Application Software Even if it were possible, would one always want to maintain a constant Application Software Interface? Application Software Interface Device Drivers Software Architecture Operating System Board Support Package / BIT Consider What What if if hardware or or Software Execution Platform changes could could provide provide more more Application Software capability, but but only only by by means means of of changing the the Application Software Interface? Hardware Platform

10 Cross-Platform Compatibility: The Goal Application Software Application Software Interface Device Drivers Software Architecture Operating System Board Support Package / BIT Hardware Platform 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

11 executable MDA: Application Software Development Requirements Definition executable UML Modeling The executable MDA Approach as supported by KC s iuml and iccg Platform Specific Mapping (Design Tagging) Application Software Interface Definition Automatic Code Generation Integration & Test

12 executable UML Modeling: Domain Model Domain Model Model (Package Diagram): The The software application space space is is partitioned into into multiple platform independent domain domain models models Mappings between the the domains are are defined defined as as contracts for for required and and provided services

13 executable UML Modeling: Class Diagrams Class Class Diagrams: Within Within each each platform independent domain domain model, model, conceptual entities entities are are modeled first: first: classes,attributes, and and associations are are abstracted Behavior, though though considered, is is not not modeled explicitly in in this this view view

14 executable UML Modeling: State Charts State State Charts: Behavior is is formalized during during state state modeling Class Class lifecycles are are modeled using using signal-driven state state machines Class Class operations are are defined defined

15 executable UML Modeling: Action Language Action Action Specification Language: State State actions actions and and class class operations are are specified using using Kennedy Carter s Action Action Specification Language (ASL) (ASL) ASL ASL is is a higher higher order order and and much much simpler simpler language than than a typical typical high high order order language (e.g. (e.g. C++) C++) ASL ASL deals deals with with UML UML concepts, not not implementation concepts ASL ASL was was a major major influence on on the the newly newly adopted Precise Action Action Semantics for for the the UML UML

16 executable UML Modeling: Simulation Simulation: Since Since a precise precise Action Action Specification Language is is used, used, models models are are executable and and therefore may may be be simulated Simulation features resemble those those of of a high high order order language debugger Models Models may may be be validated long long before before they they are are implemented

17 Design Tagging: Specifying the PIM to PSM Mapping Design Design Tags Tags xuml Models Class Class Allocation Program Allocation Max Max Instance Count Count Event Event Rate Rate Event Event Queue Queue Throw Throw Away Away Initialization Source Source Type Type Subtype of of etc. etc. Defines Automatic Code Generator Software Execution Platform Specific Language Specific Source Code Files Application Software Interface Definition

18 Design Tagging: Specifying the PIM to PSM Mapping Design Design Tagging: Design Design tag tag values values represent implementation-specific design design decisions Design Design tagging tagging is is applied applied to, to, but but not not embedded in, in, the the xuml xuml models models (tags (tags and and tag tag values values may may be be included or or excluded) Code Code Generator assumes the the most most standard implementation, such such that that only only exceptions must must be be tagged tagged

19 Automatic Code Generation: 3 Levels of Models Level 1 Model of Application Developed by by Program Level 2 Model of xuml Supplied by by Kennedy Carter Level 3 Model of Platform Developed by by Program Application Elements: (e.g. Aircraft, Missile, Target, etc.) xuml Elements: (e.g. Class, Attribute, Association, Tag, etc.) Implementation Elements: (e.g. Procedure, Array, Program, Event Queue, etc.)

20 Automatic Code Generation: Level 2 - Simulation Code Level 1 Model of Application When we say that xuml models are executable we mean that executable code can be automatically generated from them Developed by by Program Level 2 Model of xuml Supplied by 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.) xuml Elements: (e.g. Class, Attribute, Association, Tag, etc.) Step 1: Populate instances of xuml Metamodel with Model of Application

21 Automatic Code Generation: Level 3 - Target Code Level 1 Model of Application Developed by by Program Level 2 Model of xuml Supplied by by Kennedy Carter Level 3 Model of Platform Developed by 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.) xuml Elements: (e.g. Class, Attribute, Association, Tag, etc.) Step 1: Populate instances of xuml Metamodel with Model of Application Implementation Elements: (e.g. Procedure, Array, Program, Event Queue, etc.) Step 2: Populate instances of Model of Implementation with populated xuml Metamodel instances

22 Automatic Code Generation: The Code Generator Level 1 Model of Application Developed by by Program Level 2 Model of xuml Supplied by by Kennedy Carter Level 3 Model of Platform Developed by by Program Generated Source Code for Target Platform Application Elements: (e.g. Aircraft, Missile, Target, etc.) xuml Elements: (e.g. Class, Attribute, Association, Tag etc.) Implementation Elements: (e.g. Procedure, Array, Program, Event Queue, 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)

23 Automatic Code Generation: Code Generator Development Configurable Code Code Generator: Code Code Generator is is developed using using the the same same executable MDA MDA strategy Kennedy Carter Carter supplies a set set of of xuml xuml models models (known (known as as the the Configurable Code Code Generator) that that serve serve as as a generic generic translation framework

24 Automatic Code Generation: Code Generator Development Code Code Generator Development: The The Configurable Code Code Generator (iccg) (iccg) may may be be adapted to to the the meet meet the the requirements of of any any Platform Specific Implementation (i.e. (i.e. of of any any Application Software Interface) Code Code Generator and and Application Software development may may be be performed concurrently ment

25 Automatic Code Generation: Summary Automatic Code Generation Automatic code generation is simply an 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) platform The code generator is developed within the same environment as the application software using the same executable MDA strategy Development cost: architects Nearly all implementation-specific design tasks (all but the design decisions represented by design tag values) are performed by the code generator, not the software developers

26 Portable Application Software Products executable UML Models The Portable Products (and therefore the Configured Products to be placed in an Enterprise-Level Software Reuse Library) Program Specific Mapping (Design Tag Values) Application Software Interface Automatic Code Generator Source Code

27 Advantages of the executable MDA 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)

28 Advantages of the executable MDA 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

29 Advantages of the executable MDA 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( 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 is Attainable with the executable MDA Approach

30 executable MDA: Summary of Key Themes The platform is an xuml virtual machine (but platform independent models can t t assume anything about the interface) To validate PIMS as long-life life assets we need executable UML executable UML needs an action language, not a 3GL Systems are integrated from multiple platform independent models PIMS offer contracts for required and provided services 100% code generation is essential to make MDA a lightweight process But don t t worry its just another type of expert knowledge to formalise in xuml It works It makes sense Its proven

31 Projects Using executable MDA with KC s 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 UK NHS: patient control of access to medical records

32 Contact Information Lauren E. Clark Chief Engineer F-16 Modular Mission Computer Software Terry Ruthruff Staff Specialist Software Engineering Core Bary D. Hogan Methodology Lead F-16 Modular Mission Computer Software Allan Kennedy Managing Director Kennedy Carter Limited (817) (817) (817) (+44)