The xUML Formalism
xUML is a subset of the Unified Modelling Language incorporating a complete Action Language that allows system developers to build executable domain models and then use these models to produce high quality code for their target systems.  

The xUML Development Process
The xUML process is a rigorous object-oriented system development method based upon experience with executable modelling that has been applied to many pioneering projects in sectors such as telecommunications, automotive, aerospace and defence, since 1994. It is founded on the principle of building a set of precise, testable models of the system to be developed, executing specific tests on these models and defining a systematic strategy by which the models will be used to produce code for the desired target system. The xUML process embodies these distinctive characteristics:

Precise, Complete Models that can be subjected to rigorous testing by simulation. Thus, xUML provides a strong analysis completion criterion, which is: "The model is complete when it successfully executes the tests designed for it".

Simple Notations, using the Unified Modelling Language organised into a coherent set of layers. This means that normal human beings, such as customers, hardware engineers and managers can read, understand and provide helpful feedback on the emerging models.

An Understandable and Repeatable Partitioning Strategy,
based upon the idea of Separation of Subject Matters. This means that both small and large system development projects can be partitioned in a way that avoids, for example, fruitless arguments about what constitutes analysis and what constitutes design.

A Conceptually Coherent Process, that provides a small but sufficient set of techniques to address all subject matters, including "design", in a uniform way.

Usable Models, which can be utilised by system designers and coders without the need for unreliable "interpretation" of the meaning of the models.

Implementation by Translation, in which the entire system can, if desired, be automatically generated from the models, using a set of rigorously specified rules that deliver a system with the required performance characteristics.

Large-Scale Reuse, in which entire sets of classes are reused as a single component.
iUML Modeller – Model Construction
 

 
iUML Simulator – Execute, Test and Debug
 

iCCG Configurable Code Generator – Use xUML to create the code generators
 

Off-the-shelf code generators (built with iCCG):
TA-5 – C++
TA-6 – Embedded C
 

The xUML Standard
Executable UML uses the Unified Modelling Language (UML) which is standardised by the Object Management Group (OMG). The OMG has recently issued a request for proposal (RfP) for a standardised Executable subset with rigorously defined semantics. Kennedy Carter is committed to working with the Object Management Group in creating this standard and has already started work. 

If you would like more information about Kennedy Carter's work on Executable UML Action Semantics please contact us and take a look at iUML and iCCG, the system development environment with xUML.

Customer Use Case Example:
Lockheed Martin
 
Lockheed Martin Aeronautics at Fort Worth, Texas has used the OMG's MDA to develop the F-16 Modular Mission Computer Application Software.

Their goal was to achieve cross-platform compatibility and increased productivity and quality, all in the context of the demanding environment of avionics software development. 
 

Background and Goals
The F-16 MMC team originally used traditional CASE tools with an OO modelling notation to specify the software before manually coding in Ada. When they migrated their development to Kennedy Carter's iUML tool, they gained the ability to use a UML action language which made their UML models executable. They could then test their UML models to verify their intended behaviour before hand-coding the implementation.

More recently they have used Kennedy Carter's iCCG product to specify, in Executable UML, an Ada code generator which can automatically generate 100% of the Ada implementation.

By this means they guarantee that their UML models are entirely platform independent and portable across any future platform.

In Lockheed Martin's case, what constitutes the platform ?
 
Figure 1 - F-16 Mission Software main architectural elements

Figure 1 shows the basis for the F-16 Mission Software architecture; it depicts the main architectural elements:

 Software that is unique to the application(s) for which the embedded computer exists, it represents some 80-90% of the total software (in terms of long-term development cost)
 Application Software Interface, the boundary between the Application Software and the Software Execution Platform. This provides the 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
 Software Execution Platform, low-level software, the purpose of which is to allow the Application Software to run on the hardware; The software execution platform incorporates device drivers, the built-in test and the RTOS.
 Hardware, the embedded system hardware for the F-16 Mission Management system.

The software execution platform effectively raises the abstraction level of the hardware to provide a platform on which code generated from Executable UML models can run directly. Lockheed Martin's goal of complete cross-platform compatibility implies a very strong form of platform independence whereby the UML models which specify the Application software behaviour can be ported without change even if the Application Software Interface changes.

The Approach - Model Driven Architecture using Executable UML
The use of MDA allows the mission software functionality to be formalised as Executable UML models (xUML); such models are Platform Independent Models (PIM) in MDA. Platform independence is essential if the goal of decoupling the models from any changes to the Software Execution Platform is to be achieved. xUML models are expressed using a UML action language based on the newly adopted precise action semantics for the UML (see http://www.omg.org/technology/documents/modeling_spec_catalog.htm#Action_Semantics).

Executable models support the MDA approach in two main ways. First, they allow early testing using simulation and debug tools. Secondly, since they are a full and formal specification of the system behaviour, they allow generation of the target code. Defining a mapping from the rigorously defined PIM (expressed in xUML) to the implementation is what is at the heart of MDA. Since xUML models are executable and rigorous they act as much more than a simple visual agenda for the software developers, they actually embody all the business logic required to execute and verify the system.
 
Figure 2 - Lockheed Martin's MDA process

Definition of the PIM to PSM Mapping
The basis of defining a mapping that allows full and automatic translation of the PIM models, expressed in xUML into the implementation is to build an xUML model of the translation system itself and execute it! The elegant conceptual coherence of employing xUML both in the business-modelling realm and in building the translator means that a minimum set of new skills has to be learned.

Figure 3 shows the basis for defining the mapping from PIMs (expressed in xUML) to their platform specific implementation. "Ordinary" analyst models (level 1) are used to populate the meta-model of xUML (level 2), which has all the necessary processing defined (remember it is an executable model in its own right) to populate a model of the implementation (level 3). This final model, which again is expressed in xUML, is executed to produce the implementation. The analyst models (level 1) are augmented with tags that act like "compiler directives" to the translation system and allow such facts as limited instance populations to be exploited in order to produce efficient target code.
 
Figure 3 - Mapping PIM to PSM

Tool Support
There are two main areas where tool support is vital in order to reap the full benefits of the MDA process. First, iUML is used to provide the modelling and simulation environment for the xUML models. This tool provides dedicated intelligent support for xUML and allows models to be simulated on host and "debugged" visually at the UML level of abstraction.

The second part of the tool-chain is the translation environment (level 2 in Figure 3 above) where application models are extracted from the iUML database and used to populate the translation engine. The translation engine is a specialisation of the intelligent Configurable Code Generator (iCCG). iCCG allows developers to capture their mapping rules as xUML models and so produce any target implementation of which they can conceive. The specification of a mapping from PIM to PSM in Executable UML is itself highly reusable, allowing any set of application models to be generated onto the target.

Benefits realized
The use of MDA with Executable UML has provided many benefits to the F-16 project:

 The application models are expressed in a completely platform independent way and so can be reused across multiple hardware and software platforms
 UML modelers are isolated from the software and hardware details and so can concentrate on a thorough exploration of the problem space
 The hardware and software platforms can be upgraded without impacting the application models
 Models can be tested at the earliest opportunity by executing them in the iUML Simulation environment
 Rework is reduced with validated models
 The mapping from PIM to PSM is specified in xUML with iCCG and is highly reusable
 Code generation eliminates manual coding and eliminates the defects traditionally introduced in the coding phase
 The xUML models are the primary source. Code is not maintained

Taken altogether these MDA benefits have reduced application development time by 20% on the F-16 MMC program in addition to helping them achieve complete cross-platform compatibility.

Acknowledgments
This article was based upon a presentation prepared by:

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