Your SlideShare is downloading. ×
0
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
MDA with Executable UML
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MDA with Executable UML

1,863

Published on

Provides an overview of the Model Driven Architecture process and the Executable UML notation for system modelling.

Provides an overview of the Model Driven Architecture process and the Executable UML notation for system modelling.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,863
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
59
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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).
  • Transcript

    • 1. Welcome Model Driven Architecture with Executable UML Cambridge, June 17 Chris Raistrick, Kennedy Carter [email_address]
    • 2. Agenda
      • The MDA Process
      • Domain Modelling
      • Executable UML
      • Integrating Models
      • System Generation
    • 3. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 Introduction
    • 4. Important TLAs
      • This presentation describes
      • a process for system development, known as
      • Model Driven Architecture (MDA)
      • which involves building
      • Platform-Independent Models (PIMs)
      • from which we derive
      • Platform-Specific Models (PSMs)
      • and/or
      • Platform-Specific Implementations (PSIs).
      • The models are represented using the notation known as the
      • Unified Modeling Language (UML).
      • Both the MDA process and the UML notation
      • are owned by the non-profit consortium known as the
      • Object Management Group (OMG).
      see omg.org/mda
    • 5. Platform Independent Model
      • A Platform Independent Model (PIM) is a technology agnostic model of some aspect of the system under study.
      • A PIM contains no information about any of the following:
        • Hardware Architecture
        • Operating System
        • Programming Language
        • Database Technology
        • Internal Communication Technology
      • It is therefore much simpler than a Platform-Specific Model (PSM)
      • PIMs built using xUML can be:
        • Executed to demonstrate compliance with functional requirements
        • Automatically translated into a complete Platform Specific Implementation using a suitable model translator
        • Used as executable specifications , forming the basis for contract-based procurement
    • 6. What is Special about MDA with xUML?
      • MDA with xUML provides an approach based upon building models that are:
        • precise
        • complete
        • platform-independent
        • testable.
      • Such models allow us to follow a process with some interesting qualities…
      • … which will be revealed as the afternoon progresses…
      • … and which put software engineering on a par with other engineering disciplines.
    • 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
    • 8. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 The MDA Process
    • 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
    • 12. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 Domain Modelling
    • 13. Definition
      • A domain is a separate real, hypothetical or abstract world inhabited by a distinct set of classes that behave according to the rules and policies characteristic of that domain.
      AIRCRAFT It is a policy of Air Traffic Control that I must remain at least 3 miles horizontally and 1000 feet vertically from all other aircraft Class in Air Traffic Control Domain (a “real” world) ICON It is a policy of this User Interface that I must become translucent if I am in front of another icon Class in User Interface Domain (an “abstract” world)
    • 14. A Standardised Domain Model Source: http://www.webopedia.com/img/OSI_Model.jpg
    • 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
    • 20. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 Executable UML
    • 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. Use Case Model
      • Use cases specify the capabilities to be provided by the system, and how they interact with humans (e.g. Pilot/Ground Crew) and equipment (e.g. Carriage/Weapon Hardware)
    • 23. Domain Model
      • Domains specify the subject matters , or areas of expertise, on our system.
      • Domains are organised into layers , each providing services to those above, and requiring services of those below.
      • For each domain we will build a Platform Independent Model
    • 24. Sequence Diagram
      • The Sequence Diagram helps identify the domain interfaces needed to support each Use Case
      Sequence Diagram for Use Case: Use Case Model Domain Model
    • 25. Classes
      • Classes identify the things that exist with a domain. Ideally, they represent things in the “real world” of that domain.
      • They establish the vocabulary of the domain, or area of expertise.
      • For example, the “Weapon Management” domain might contain this class…
    • 26. Attributes
      • Attributes specify what we know about each thing (or class).
      • They are analogous to data .
    • 27. Associations
      • Associations capture real-world connections between classes.
    • 28. Operations
      • Operations specify what we can do to each thing.
      • They are analogous to code .
    • 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. Internal and External Interfaces
      • The Class Interaction Model shows the interfaces within the system, and between the system and the outside world.
      • In this view, “Actors” are represented as <<terminator>> or <<interface>> classes.
      Class Interaction Model Internal interface External interface Use Case Diagram
    • 31. The xUML Model Structure System Model Domains Classes Operations States xUML Model (PIM) Platform-Specific Configuration
    • 32. Isn’t xUML with ASL Just Coding in Another Language?
      • Yes…but… …as xUML “programmers”, we do not need to clutter our minds or our models with:
        • Code distribution decisions, with consequential additional components such as inter-node communication skeletons and stubs
        • Data distribution and replication, with consequential additional components to manage the distributed collection
        • Data structure decisions, with consequential code to access the structures
        • Shared resource locking
      • … and we can easily change our minds about:
        • Static or dynamic memory management
        • Threading strategy
        • Data persistence
        • Target language
      • … without changing the xUML model
    • 33. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 Integrating Models
    • 34. Elements of a Domain’s Interfaces
      • Each domain can be thought of as an “integrated circuit” of classes (the black box)… …with a set of provided and required interfaces (the ports)… …that can be connected together into a system (the connectors)
      Air Traffic Control required interfaces User Interface provided interfaces bridge operations
    • 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
    • 38. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 System Generation
    • 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 { /* &quot;[T:this.class_name]&quot; 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. Build a PIM
      • The domain experts build PIMs using xUML, such as this one:
      Platform Independent Model : Class Diagram 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
    • 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 &quot;Process One&quot; ONE 1 127.0.0.1 1000 1600 PROCESS &quot;Process Two&quot; 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 { /* &quot;[T:this.class_name]&quot; 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
    • 46. Chris Raistrick [email_address] Model Driven Architecture with Executable UML Cambridge, June 17 Summary
    • 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]

    ×