7. Real Engineers Do It Rigorously The MDA process can be summarized as: SPECIFY DOMAINS Identify New/Reused Domains Model System Use Cases Establish a well-defined and automated construction process Build precise, predictive models Subject the models to rigorous testing before implementation To build this Construct the system from large, reusable components VALIDATE PIMS Execute Domain Use Cases Execute System Use Cases BUILD PLATFORM-INDEPENDENT MODELS (PIMS) Model Domain Use Cases Build Static Model - Class Diagram Build Behavioural Model - State Charts & Operations Build Action Model - State Actions & Methods Compile and Debug PIMS SPECIFY SYSTEM CONSTRUCTION PROCESS Define/Buy PIM To PSI Mapping Rules Build/Buy PIM Compiler GENERATE SYSTEM Apply PIM to PSI Mapping Rules (Execute PIM Compiler) Perform Target Testing
9. MDA Maturity Scale We will focus on this maturity level Code “ What’s a model?” Code Model Visualize Code Model Synchronize Code Model Synthesize Model “ What’s code?” Model Centric Code Centric
10. MDA Maturity Scale Productivity Code “ What’s a model?” Code Model Visualize Code Model Synchronize Code Model Synthesize Model “ What’s code?” Translation Process Elaboration Process
11. Translation-based Development The Executable MDA (xMDA) process represents an evolution of traditional development processes… Write High Level Language (C++/Ada/Java…) Define High Level Language Mapping Rules Translate High Level Language Machine Code Traditional Software Development Build Platform Independent Model (xUML) Define xUML Mapping Rules Translate xUML HLL (C++/Ada/Java…) xMDA Development High Level Language HLL Mapping Rules PIM xUML Mapping Rules
15. Pattern: Domains to Isolate Areas of Change Provides standard interface services Maps to standard interface services to technology-specific services Provides technology- specific interface services Technology Independent Domain Technology 1 Technology n
16. Pattern: Domains to Isolate Areas of Change User Interface Provides standard interface services Textual User Interface Maps to standard interface services to technology-specific services Graphical User Interface Provides technology- specific interface services displayIcon displayText display3DEntity
17. Plug and Play Weapons In a perfect world… It should be possible to load any of these weapons… … onto any of these airframes… … and make available a set of common core capabilities… … even if some weapon-specific capabilities are not available
18. Plug and Play Domain Architecture Software System Weapon specific plug-ins Comms specific plug-ins Language specific plug-ins Communications Future Comms Technology Existing Comms Technology Weapon Control Future Weapon Existing Weapon Target Hardware xUML Execution Platform Any Language Any Operating System Achieves weapon type independence Achieves execution platform independence Achieves comms platform independence
19. Counterparts Each real-world thing can be represented as different abstractions in various domains...the counterpart classes , linked via counterpart associations The Contact Class “ A correlated radar contact” The Aircraft Class “ A piloted aircraft in controlled airspace” The Icon Class A shape with context-sensitive pop-up menu options Air Traffic Control Graphical User Interface Radar Data Processing Aircraft Fuzed Track Icon The Class Class “ An encapsulation of data and operations” PIM-PSM Mapping Class
21. Primary xUML Artefacts 5. Define Class Interfaces Domain: Interaction Diagram 1. Capture Requirements System: Use Cases 2. Partition into Domains System: Domain Model 3. Define Domain Interfaces Use Case: Sequence Diagram 4. Specify Classes Domain: Class Model Class: State Model 6. Specify Behavior
22.
23.
24.
25.
26.
27.
28.
29. Operations and Methods Every operation has a method … …which can be specified using a standard 3GL, such as C++… …or a UML action language as in this example Find a set of objects Invoke an object-scoped operation Create a link
30.
31. The xUML Model Structure System Model Domains Classes Operations States xUML Model (PIM) Platform-Specific Configuration
35. Required Interface Attaching an association terminator to a class makes it eligible for participation in counterpart relationships The Required Interface consists of operations attached to <<terminator>> classes Air Traffic Control required interfaces User Interface provided interfaces bridge operations Air Traffic Control Domain (part of) Class Collaboration Diagram <<association terminator>> Air Traffic Controller Aircraft requestTaxi required operation
36. Provided Interface The Provided Interface consists of operations attached to domains or classes, and signals attached to classes Air Traffic Control required interfaces User Interface provided interfaces bridge operations User Interface Domain (part of) Class Collaboration Diagram Icon <<association terminator>> Client makeIconFlash provided operation
37. The “Wiring” Is Specified in a Build Set… Air Traffic Control System Build Set Counterpart associations can be established between classes with at least one association terminator Air Traffic Control Domain (part of) Class Collaboration Diagram <<association terminator>> Air Traffic Controller Aircraft requestTaxi required operation User Interface Domain {kl=UI} (part of) Class Collaboration Diagram Icon <<association terminator>> Client makeIconFlash provided operation CPR1 counterpart association bridge: requestTaxi counterpartIcon = this -> CPR1 $USE UI [ ] = ICN2:makeIconFlash[ ] on counterpartIcon $ENDUSE Bridge operation
39. The Code Generator: Domains Populate Generate System Model Code Generator Generated Code xUML Runtime Layer Generated System Adaptation Layer The code generator itself is a set of domain models expressed using xUML. The domains represent the various components of an xUML system. (Part of) Code Generator Domain Chart xUML Model (PIM) Platform-Specific Configuration xUML-Code Mappings Code Generator
40. The Code Generator: Classes and Methods (Part of) Configurable Code Generator Domain Chart Code Generator Code Generator xUML-Code Mappings (Part of) Executable UML Class Model the classes in each domain represent the elements that make up those components. Method to Generate Java Method to Generate Ada Method to Generate C++ Method to Generate C … $FORMAT header_file typedef struct C[I:this.class_ID]_struct { /* "[T:this.class_name]" Class Header */ struct s_object *next_instance; $ENDFORMAT … Each element contains operations which specify how to map that xUML element onto a specific target language.
41.
42. Instantiate the Formalism Metamodel Domain Instance Class Instances Attribute Instances Populated Executable UML Class Model When the Executable UML domain is populated with the PIM components, we see these instances… Populate xUML Model (PIM) Platform-Specific Configuration System Model xUML-Code Mappings Code Generator Code Generator
43. The Metamodels Embody the Code Generation Rules Domain.generateCode Class.generateCode Attribute.generateCode The task of translation involves iterating through these instances and generating suitable code from them. Code Generator Code Generator xUML-Code Mappings
44. Generate the Code Platform Independent Model : Class Diagram Generated C Code Generate Generate xUML-Code Mappings Code Generator Code Generator Generated Code xUML Runtime Layer Generated System Adaptation Layer
45. Code Generation Overview Populate Generate xUML Model (PIM) Platform-Specific Configuration System Model xUML-Code Mappings Code Generator Code Generator Generated Code xUML Runtime Layer Generated System Adaptation Layer PLATFORM SPECIFIC CONFIGURATION FILE PROCESS "Process One" ONE 1 127.0.0.1 1000 1600 PROCESS "Process Two" TWO 1 127.0.0.1 1001 1601 CLASS-PROCESS WM TGT ONE CLASS-PROCESS WM WPN TWO (part of) xUML Metamodel Domain Class Attribute owning_domain = this -> R2 $FORMAT header_file typedef struct D[I:owning_domain.domain_ID]_C[I:this.class_ID]_struct { /* "[T:this.class_name]" Class Header */ struct s_object *next_instance; /* Linked list of */ struct s_object *prev_instance; /* object instances */ struct s_object *rel_ptr; /* list of rel'ns */ struct s_object *cpr_ptr; /* list of cp rel'ns */ $ENDFORMAT {attributes_in_class} = this -> R3 for the_attribute in {attributes_in_class} do [] = ATT1:generateCode [header_file] on the_attribute endfor $FORMAT header_file }; $ENDFORMAT Multi-node multi-process runtime Windows Vista adaptation layer
47. Primary Artefacts 5. Define Class Interfaces Domain: Interaction Diagram 1. Capture Requirements System: Use Cases 2. Partition into Domains System: Domain Model 3. Define Domain Interfaces Use Case: Sequence Diagram 4. Specify Classes Domain: Class Model Class: State Model 6. Specify Behavior
48. MDA: Models, Metamodels and Mappings M2 M1 M0 Class UML Type Of Aircraft ATC Actual Aircraft <<instance of>> Air Force 1: Actual Aircraft ATC Objects <<instance of>> Radar Measurement RADAR Fuzed Track <<model time>> CPR Package Ada <<cgen time>> CPR Fuzed Track 50: Fuzed Track RADAR Objects <<instance of>> <<run time>> CPR
49. Maintainability vs. Executability PSM (UML) manually build a Platform Specific Model … manually code a Platform Specific Implementation PSI (Code) manually build a Platform Independent Model … PIM (UML) Elaborate Compromise between maintainability and executability In classic approaches, the PSI (code) must be built to be maintainable, typically by incorporating layering and encapsulation … …which have a detrimental effect on speed and size of the executing system PSI (Code) automatically generate a Platform Specific Implementation using PIM-PSI mappings manually build a Platform Independent Model … PIM (xUML) Translate Built for executability Built for maintainability In translation-based approaches, the maintained entity (the PIM) is built for maintainability with layering and encapsulation… … while the executable entity (the PSI) is optimized for execution efficiency
50. Key Facets of MDA with xUML Rigorous lightweight process Precise simple modelling formalism Separation of concerns Formalised design and implementation policies
51. The End Model Driven Architecture with Executable UML Cambridge, June 17 Chris Raistrick, Kennedy Carter [email_address]
Notas del editor
Don’t mix the ideas up (as you would in OMT for object).
Don’t mix the ideas up (as you would in OMT for object).