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 President Kennedy Carter Limited 2001 Lockheed Martin Corporation
Agenda Basic Software Components Cross-Platform Compatibility: The Goal The executable MDA Approach: executable UML Modeling Platform Specific Mapping (Design Tagging) Automatic Code Generation Advantages of the executable MDA Approach
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 allow allow the the Application Software to to run run on on the the hardware
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 allow allow the the Application Software to to run run on on the the hardware
Board Support Package / Built-In Test Application Software Application Software Interface Software Execution Platform Device Drivers Software Architecture Board Support Package / BIT Hardware Operating System Board Board Support Package: Lowest-level boot boot software // firmware that that allows allows all all other other software (including the the Operating System) to to be be loaded loaded into into memory and and begin begin executing Unique Unique to to the the hardware; and and usually usually delivered with with the the hardware (located in in some some type type of of ROM) ROM) Built-In Test Test (BIT): (BIT): Low-level software that that detects detects and and reports reports hardware errors errors Unique Unique to to the the hardware; and and usually usually delivered with with the the hardware
Operating System Application Software Application Software Interface Software Architecture Software Execution Platform Device Drivers Operating System Board Support Package / BIT Operating System: Low-level software that, that, once once booted, booted, manages all all other other software (this (this management involving such such things things as as multitasking, memory sharing, I/O I/O interrupt handling, error error and and status status reporting, etc.) etc.) Unique Unique to to the the hardware (i.e. (i.e. it it must must at at least least be be ported ported to to each each new new hardware platform); and and sometimes delivered with with the the hardware Hardware
Device Drivers Application Software Application Software Interface Software Architecture Software Execution Platform Device Drivers Operating System Board Support Package / BIT Device Device Drivers: Low-level software that that manages the the input input from from and and output output to to the the various various external devices in in support of of the the Application Software Unique Unique to to the the hardware; but but usually usually not not delivered with with the the hardware Hardware
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 to to the the hardware; but, but, since since it it must must support support all all requirements levied levied by by the the Application Software, is is not not delivered with with the the hardware Hardware
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
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
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 support the the newer newer Software Execution Platforms?
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
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
executable MDA: Application Software Development Requirements Definition executable UML Modeling The executable MDA Approach Platform Specific Mapping (Design Tagging) Application Software Interface Definition Automatic Code Generation Integration & Test
executable UML Modeling: Domain Model Domain Model Model (Package Diagram): The The software application space space is is partitioned into into multiple platform independent models models (or (or domains) Mappings between the the domains (bridges) are are defined defined
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
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
executable UML Modeling: ASL Action Action Specification Language: State State actions actions and and class class operations are are specified using using a precise precise 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 object object oriented concepts, not not implementation concepts ASL ASL conforms to to the the UML UML Precise Precise Action Action Semantics
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
executable UML Modeling: Summary executable UML Modeling xuml models are a complete representation of the application space (not a top-level or preliminary design) Modeling is performed using a Unified Modeling Language (UML) representation Modeling makes use of a precise Action Specification Language (ASL) and is therefore executable (providing early validation of the models) Each xuml model is a Platform Independent Model (PIM), or completely implementation- independent (i.e. independent of the hardware platform, the software execution platform, and the application software interface)
Design Tagging: Specifying the PIM to PSM Mapping 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
Design Tagging: Specifying the PIM to PSM Mapping 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
Design Tagging: Summary Platform Specific Mapping (Design Tagging) Whereas xuml modeling is implementation- independent, Design Tagging is implemen- tation-dependent (i.e. specific to a particular Application Software Interface) Implementation-specific design decisions (only those needed to support code generation) are made during Design Tagging, and are represented with design tag values that are applied to the xuml models The most standard implementation is always assumed by the code generator, such that only exceptions must be tagged Design Tagging is overlaid on (not embedded in) the xuml models, such that it may be included or excluded
Automatic Code Generation: 3 Levels of Models Level 1 Model of Application Developed by by Program Level 2 Model of xuml Supplied by by Tool Vendor Level 3 Model of Implementation 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.)
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 Tool Vendor 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
Automatic Code Generation: Level 3 - Target Code Level 1 Model of Application Developed by by Program Level 2 Model of xuml Supplied by by Tool Vendor Level 3 Model of Implementation 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
Automatic Code Generation: The Code Generator Level 1 Model of Application Developed by by Program Level 2 Model of xuml Supplied by by Tool Vendor Level 3 Model of Implementation 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)
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 The The Tool Tool Vendor Vendor 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
Automatic Code Generation: Code Generator Development Code Code Generator Development: The The Configurable Code Code Generator 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 developmentmay may be be performed concurrently ment
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: 1-21 2 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
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
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)
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
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 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
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 President Kennedy Carter Limited Lauren.E.Clark@lmco.com (817) 763-2748 Terry.Ruthruff@lmco.com (817) 763-3525 3525 Bary.D.Hogan@lmco.com (817) 763-2620 allan@kc kc.com (+44) 1483 483 200