F-16 Measured Mission PC Application Programming.


69 views
Uploaded on:
Category: Medical / Health
Description
Application Software. Accomplishing Cross-Platform Compatibility with Increased Productivity ... the application(s) for which the. inserted PC (i.e. subsystem) ...
Transcripts
Slide 1

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 Allan Kennedy Managing Director Kennedy Carter Limited Bary D. Hogan Methodology Lead F-16 Modular Mission Computer Software Lockheed Martin Aeronautics Company F-16 Modular Mission Computer Application Software Achieving Cross-Platform Compatibility with Increased Productivity and Quality utilizing the OMG\'s Model Driven Architecture

Slide 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 got from utilizing eXecutable MDA

Slide 3

Basic Software Components Software Application Software Application Software: High-level programming that is novel to the application(s) for which the implanted PC (i.e. subsystem) exists 80-90% of the aggregate programming (regarding long haul advancement cost) Application Software Interface Software Execution Platform Software Execution Platform: Low-level programming, the reason for which is to give benefits that permit the Application Software to keep running on the equipment Hardware

Slide 4

Software Execution Platform Application Software Application Software Interface Software Execution Platform Software Architecture Software Execution Platform: Low-level programming, the motivation behind which is to give benefits that permit the Application Software to keep running on the equipment Device Drivers Operating System Board Support Package/BIT Hardware

Slide 5

Software Architecture Software Architecture: Low-level programming giving the structure inside which the Application Software executes Provides execution control, information/message administration, blunder taking care of, and different bolster administrations to the Application Software Assumes a specific Application Software dialect Unique to the equipment; however, since it must bolster all necessities imposed by the Application Software, is not conveyed with the equipment Application Software Application Software Interface Software Execution Platform Software Architecture Software Architecture Device Drivers Operating System Board Support Package/BIT Hardware

Slide 6

Application Software Interface Application Software Application Software Interface: The limit between the Application Software and the Software Execution Platform The predetermined techniques by which the Application Software can make demands and utilize the administrations of the Software Execution Platform and the Software Execution Platform can give its administrations to the Application Software This interface is determined by the Software Execution Platform Application Software Interface Application Software Interface Software Execution Platform Software Architecture Device Drivers Operating System Board Support Package/BIT Hardware

Slide 7

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

Slide 8

Cross-Platform Compatibility Issues Application Software Can a steady Application Software Interface dependably be kept up? Consider… What if the dialect or working framework gets to be old? Imagine a scenario where it is important to port even a part of the Application Software to a legacy stage not having the assets to bolster the more up to date Software Execution Platforms. Application Software Interface Software Architecture Device Drivers Operating System Board Support Package/BIT Hardware Platform

Slide 9

Cross-Platform Compatibility Issues Application Software Even on the off chance that it were conceivable, would one generally need to keep up a consistent Application Software Interface? Consider… What if equipment or Software Execution Platform changes could give more Application Software capacity, however just by method for changing the Application Software Interface? Application Software Interface Software Architecture Device Drivers Operating System Board Support Package/BIT Hardware Platform

Slide 10

Cross-Platform Compatibility: The Goal Application Software The objective ought to be to give cross-stage similarity of Application Software regardless of any Implementation, or stage particular, changes : that is, changes to the Hardware Platform, the Software Execution Platform, or the Application Software Interface Application Software Interface Software Architecture Device Drivers Operating System Board Support Package/BIT Hardware Platform

Slide 11

eXecutable MDA: Application Software Development The eXecutable MDA Approach as bolstered by KC\'s iUML and iCCG Requirements Definition eXecutable UML Modeling Platform Specific Mapping (Design Tagging) Application Software Interface Definition Automatic Code Generation Integration & Test

Slide 12

eXecutable UML Modeling: Domain Model Domain Model (Package Diagram): The product application space is parceled into numerous stage free area models Mappings between the areas are characterized as contracts for required and gave administrations

Slide 13

eXecutable UML Modeling: Class Diagrams Class Diagrams: Within every stage autonomous area model, reasonable elements are displayed first: classes,attributes, and affiliations are disconnected Behavior, however considered, is not demonstrated expressly in this perspective

Slide 14

eXecutable UML Modeling: State Charts State Charts: Behavior is formalized amid state demonstrating Class lifecycles are displayed utilizing signal-driven state machines Class operations are characterized

Slide 15

eXecutable UML Modeling: Action Language Action Specification Language: State activities and class operations are determined utilizing Kennedy Carter\'s Action Specification Language (ASL) ASL is a higher request and much more straightforward dialect than a run of the mill high request dialect (e.g. C++) ASL manages UML ideas, not usage ideas ASL was a noteworthy impact on the recently embraced Precise Action Semantics for the UML

Slide 16

eXecutable UML Modeling: Simulation: Since an exact Action Specification Language is utilized, models are executable and along these lines might be reproduced Simulation highlights look like those of a high request dialect debugger Models might be approved much sooner than they are actualized

Slide 17

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

Slide 18

Design Tagging: Specifying the PIM to PSM Mapping Design Tagging: Design label values speak to usage particular configuration choices Design labeling is connected to, yet not implanted in, the xUML models (labels and label qualities might be incorporated or rejected) Code Generator expect the most standard usage, such that exclusive exemptions must be labeled

Slide 19

Automatic Code Generation: 3 Levels of Models Model of Platform Model of xUML ... Model of Application ... ... ... ... ... Level 3 Developed by Program Level 2 Supplied by Kennedy Carter Level 1 Developed by Program Implementation Elements: (e.g. Methodology, Array, Program, Event Queue, and so on.) xUML Elements: (e.g. Class, Attribute, Association, Tag, and so on.) Application Elements: (e.g. Air ship, Missile, Target, and so forth.)

Slide 20

Automatic Code Generation: Level 2 - Simulation Code Level 2 Supplied by Kennedy Carter Model of xUML Level 1 Developed by Program Model of Application ... ... xUML Elements: (e.g. Class, Attribute, Association, Tag, and so on.) ... Application Elements: (e.g. Air ship, Missile, Target, and so on.) ... When we say that "xUML models are executable" we imply that "executable code can be naturally created from them" Code Generation: Generation of Simulation Code for Development Platform (e.g. UNIX C Code) Step 1: Populate examples of xUML Metamodel with Model of Application

Slide 21

Automatic Code Generation: Level 3 - Target Code Level 3 Developed by Program Model of Platform Level 2 Supplied by Kennedy Carter Model of xUML Level 1 Developed by Program ... Model of Application ... Usage Elements: (e.g. Strategy, Array, Program, Event Queue, and so forth.) ... ... xUML Elements: (e.g. Class, Attribute, Association, Tag, and so on.) ... Application Elements: (e.g. Air ship, Missile, Target, and so on.) ... Code Generation: Generation of Source Code for Target (Embedded) Platform (e.g. Ada/C++ Code) Step 2: Populate examples of Model of Implementation with populated xUML Metamodel occasions Step 1: Populate occurrences of xUML Metamodel with Model of Application

Slide 22

Automatic Code Generation: The Code Generator Level 3 Developed by Program Model of Platform Level 2 Supplied by Kennedy Carter Model of xUML Level 1 Developed by Program ... Model of Application ... Execution Elements: (e.g. Method, Array, Program, Event Queue, and so forth.) ... ... xUML Elements: (e.g. Class, Attribute, Association, Tag and so forth.) ... Application Elements: (e.g. Flying machine, Missile, Target, and so on.) ... The Code Generator Generated Source Code for Target Platform The Code Generator incorporates all usage subordinate points of interest (those ward up

Recommended
View more...