Model-Driven Development - Object Management Group

Model-Driven DevelopmentDefinitions, Challenges, Promises…

2© 2008 Artisan Software Tools Ltd. All rights reserved. 15 June 2008 OMG::Washington, DC::VanZandt

Talking Points

What is Model-Driven Development?

What is Difficult with Real-time & Embedded Systems?

Why does MDD™ often Fail?

What enables MDD™?

Comments on Various MDD Enablers

What is MARTE™?

When will MDD™ Succeed?

Concluding Remarks and Hand-over to the MARTE Examples Talk.


What is a Model?

Noun: from Latin modellus, diminutive form of modulus ‗small measure‘[1].

A simplified representation (usually mathematical) used to explain the

workings of a real world system or event.

− ―The computer weather model did not correctly predict the path of the

hurricane.‖

The structural design of a complex system.

− ―The team developed a sound business model.‖

A praiseworthy example to be copied, with or without modifications

− ―British parliamentary democracy was seen as a model for other

countries to follow‖


What is Development?

Noun: development[2]

The application of new ideas to practical problems

− ―Our development department has produced three new adhesives this

year.‖

The active placement of the pieces, or the process of achieving it

− ―White's development is good, but Black's has been hampered by the

pawn on e5.‖

QED: An active process of problem-solving via analysis and synthesis of

alternatives…


What is Model-Driven Development?

The ―rapid solutioning‖ of complex systems from Models which are smaller

and more abstract than are those synthesized systems

− Models which are larger and more complex than their solutions

suggests something has gone wrong!

The solving of problems using Models pervasively and using Models as the

inputs to parameterized implementation generators

Development Methodologies which regard Models as the Intellectual

Property

− Rather than those which (or who) regard the output artifacts as

irreplaceable


Why is Real-Time and Embedded Development Different?

Solutions are constrained by Time, Space, Cost, and Access

Consequences of failure include

− Loss of Revenue

− Loss of Systems

− Loss of Life

Verification by Inspection, Demonstration, or Test can be impractical

− Leaving just Verification by Analysis


Why does Model-Driven Development Fail?

Models are Incomplete

Models are Inconsistent

Models are Ambiguous

Models are Incomprehensible

Models are Unsharable

Models are Unverifiable

Models Ignore Multiform Time

Models lack Quantitative and

Qualitative Metrics

Model Development is too arduous

Model Development is too slow

Graphical Grammars are no more—

or are less—expressive than Text

Modeling Tool User Interfaces are

User Hostile

Modeling Tools are Buggy

Good Modeling is Subjective

Models are Cohesive, Coupled,

Complex, Rigid, and Fragile

− Like the epitome of bad code…


What Enables Model-Driven Development?

Standardized Methodologies

− Collections of Methods and

Processes

− Objective Metrics

Standardized Syntax, Notations,

Symbols

Standardized Semantics

―Models of Computation‖

Multiform Time

Formal Methods

Interfaces, Design by Contract

Variation and Sensitivity Analysis

Tradeoffs Analysis

Provers and Solvers

Collaboration

Isolated Modeling

Change Management

Workflow Integration

Design for Test


Quantitative Model Metrics

Number of Requirements? Use Cases? Classes? SysML Blocks?

− 5 are too few, 100,000 are too many—but are 500 just right?

Number of Diagrams?

Number of Steps per Interaction Diagram?

Number of Packages?

Number of elements per Package?

Number of Associations?

Currently, No Set of Objective, Quantitative Metrics


Qualitative Model Metrics

Requirements have been Refined? Derived? Satisfied? Verified?

Use Cases have Interaction Diagrams?

Model has a Package Structure supporting IPTs? Collaboration? Component

Sharing? Multiple Programming Languages?

―Evil Twins‖ are not Present?

Diagrams have White Space? Are Pretty? Have Comments?

Model has internal Documentation?

Model uses Design Patterns?

Model expresses Tradeoffs and Rationales?

Model is Executable? Verifiable? Reusable?

Currently, No Set of Objective, Qualitative Metrics


Standardized Symbols and Notations

Alphabets and Grammars (but not Sentences)

Mathematical Expressions

Mathematical and Logical Symbols

Set Theory

Predicate Calculus

Query and Constraint Languages

Domain-specific Engineering Notations

− Control, SCADA, HVAC, Electrical, Building, UML, MARTE…

Standardized Symbols Facilitate Comprehension


Domain-Specific Modeling

Specific versus General Modeling

Ideally More Abstract and More Expressive

Offers Reduction in Effort

Stylized Icons

Business Logic Constraint Enforcement

Approachable in UML™ with

− Stereotypes

− Tag Definitions

− Tool Behavior Modification via plugin Scripting


Formal Methods

Mathematically rigorous Techniques and Tools for

− the Specification, Design and Verification of Software and Hardware[3]

Systemic Usage yields Verifiable Systems Throughout Lifecycle

Example Languages

− Esterel and Lustre

− Vienna Development Method – Specification Language (VDM-SL)

− Temporal Logic of Actions (TLA+)

− Z(ed)


Interfaces and Contracts

Interfaces

− Delegate Interactions

− Separate Specification from

Implementation

− Decouple Components

− Enable Dynamic Substitution

− Enables Mocking for Testing

− Examples:− Provided and Required Interfaces

− Abstract Classes

Contracts

− Express Preconditions and

Postconditions

− Enable formal Verification

− Exploitable throughout the

System Specification and

Implementation

Contracts, written in Formal

Methods, are especially

powerful

− Examples:− Spark Ada

− Eiffel


Model Transformations

takes as input a model conforming to a given metamodel and produces as

output another model conforming to a given metamodel. …One of the

characteristics of a model transformation is that a transformation is also a

model[4]

Frequently only unidirectional

− Model-to-text or ―Code Generation‖

Powerful when bidirectional

− Traceable and Reversible

− E.g. Triple Graph Grammars

Automated Transformations

− Replace lengthy, error-prone manual transformations

− E.g. the Eclipse ATLAS Transformation Language (ATL)


Model to Text Transformations

Traditionally: ―Code Generation‖

Also: Document Generation, Testcase Generation, XMI, etc.

Typical Methods

− Model(s) → Query → XMI → XSLT → Formatted Output

− XMI → ATL → XMI → XSLT → Formatted Output

− Model(s) → Query → Configurable Procedures → Formatted Output

− Model(s) → Query → Parameterized Templates → Formatted Output


Design Patterns

A general, repeatable

solution to a commonly

occurring problem in

software design…

Not a finished design that

can be transformed directly

into code…

A description or template for

how to solve a problem that

can be used in many

different situations.[5]

Creational

− Factory

− Singleton

Structural

− Adapter

− Decorator

− Façade

− Proxy

Behavioral

− Broker

− Chain of

Responsibility

− Command

− Iterator

− Mediator

− Observer

− State

− Strategy

− Template

Method

− Visitor

Concurrency

− Active Object

− Scheduler

− Thread Pool


Models of Computation

Offer Design Patterns of

Component Interaction[6]

Express Semantics of

Concurrency and Time

Often Derived from Formal

Mathematics

No panacea ―MoC‖

− Foreach ―MoC‖− Useful when Circumstances are

Suitable

Component Interaction

− e.g. CORBA

Communicating Sequential

Processes

− E.g. Hoare, Occam

Discrete-Event

− E.g. Digital Hardware Simulation

Synchronous Dataflow

− E.g. Streams and Signal Processing

Synchronous/Reactive

− E.g. Esterel/Lustre


Collaboration and Isolation

Engineering Activities are either

− Collaborative

− Isolated

Collaborative when

− Brainstorming, Sharing, Presenting, Concurrent

− E.g. Systems Engineering

Isolated when

− Rapidly Prototyping, Refactoring, Analyzing, Verifying, Serialized

− E.g. Software Engineering

MDD Methodologies and Tools must Enable both forms of Engineering

− But most don‘t…


Collaboration and Workflow

Common, Referentially Consistent ―Data‖ Dictionary

Automatic Publication of

− Who Changed What

− Why and When

− In the larger Context

Management of Such Change

− Historical Variations

− Differencing

− Reversion Ability

Individual-centric Models and Manual Change Propagation impede MDD


Rapid Prototyping

Software (or Solid Form) Feature Implementation

Small Subset of Features

May be significantly different from Final Implementation

Enables Early Assessment

Requires an easily mutable modeling medium (like Text in Vi )

− Any rigid, coupled, time-consuming model would be an impediment

Requires isolated not collaborative engineering

− Mutual exclusion from conflicting, radical modifications

MDD Methodologies and Tools must Enable both forms of Engineering

− A few do…


Analysis

Noun: From Medieval Latin analysis from Ancient Greek ἀνάλυσις (analusis)

from ἀναλύω (analuō), ―‗I unravel, investigate‘‖) from ἀνά (ana), ―‗on, up‘‖) +

λύω (luō), ―‗I loosen‘‖)[7]

The action of taking something apart in order to study it.

The mathematical study of functions, sequences, series, limits, derivatives

and integrals.

The process of breaking a substance down into its constituent parts.

QED: Understanding a System by tearing it apart and studying the pieces


Simulation

Substitution for Analysis when Closed-Form Solutions aren‘t achievable

Enables Analysis by Execution

Enables Solvers, Provers, Tradeoff and Sensitivity Analysis

Without Requiring Actual Environment or System

In Compressed or Expanded Absolute Time

Requires Workload Specifications

Requires Non-Functional Property Value Specifications

Requires Instances Specifications

Requires Integrated Modeling and Simulation Tools


Unit Testing and Mocking

Testable Units (Packages of Models)

− Can be verified, trusted, reused earlier

But, Embedded Systems are Often

− Highly Coupled

− Intrinsically Complex

− Difficult to Decompose into Individually, Testable Units

Interfaces and Mocks enable Scriptable, Mocking Test Harnesses to

− provide Required services

− Record interaction and coverage

− Respond with proper Sequences

− Detect missing Expected Interactions

UML Testing Profile offers Standardized Verification Modeling

MDD™ Requires Modular Models to Enable Unit Testing


History of MARTE™

Spawned from RT/E Software Engineers‘ Frustration with the Inability to

Express, Analyze, and Simulate Time and Resource Constrained Systems

− In any way other than implementing prototypes, executing those, and

observing their behavior

Motivated by the Inadequacies of the prior OMG Profile for Schedulability,

Performance, and Time (SPT)

Launched in Feb 2005 with the ProMARTE RFP Response[8]

Adopted Specification as of May 2008


Foundations of MARTE™

Non-Functional Properties

− Qualities

− Value Specification Language

Time

− Multiform Models of Time and

Events

− Causal, partial ordering

− Clocked, synchronous

− Absolute and Relative Physical

Time

Generic Resource Modeling

− Execution Platform

Generic Component Modeling

− Compositions

− SysML™ Blocks

− Interfaces, Flows, and

Interactions

Allocations

− Spatial Deployment

− Temporal Scheduling

− Based upon SysML™ Allocation


Using MARTE™ for Design

Software Resource Modeling

Hardware Resource Modeling

Real-time Embedded Models of Computation and Communication


Using MARTE™ for Analysis

Generic Quantitative Analysis Modeling

Schedulability Analysis Modeling

Performance Analysis Modeling


When MDD™ Will Succeed

Refinement of de facto Metrics

− Completeness, Objectivity

Adoption of Formal Methods

− Completeness, Consistency,

Verification

Improvement of Tools

− Consistency, Collaboration,

Modeling Fluency, Modeling

Duration, User Interfaces,

Model Modularity

Additional Research

− Graphical Expressiveness

− Metrics

Improved Education

− Consistency, Modeling Fluency,

Objectivity


References

[1] Wiktionary Contributors., "Wiktionary Definition of "Model"." Wiktionary: a wiki-based Open Content dictionary. [Online]

May 29, 2008. [Cited: June 14, 2008.] http://en.wiktionary.org/w/index.php?title=model&oldid=4661990.

[2] —. "Wiktionary Definition of "Development"." Wiktionary: a wiki-based Open Content dictionary. [Online] June 05, 2008.

[Cited: June 14, 2008.] http://en.wiktionary.org/w/index.php?title=development&oldid=4691164.

[3] Butler, Ricky W., "What is Formal Methods?" Langley Formal Methods. [Online] August 06, 2001. [Cited: June 13, 2008.]

http://shemesh.larc.nasa.gov/fm/fm-what.html.

[4] Wikipedia Contributors., "Model Transformation." Wikipedia, The Free Encyclopedia. [Online] October 03, 2007. [Cited:

June 15, 2008.] http://en.wikipedia.org/w/index.php?title=Model_transformation&oldid=139650456.

[5] —. "Design Pattern (Computer Science)." Wikipedia, The Free Encyclopedia. [Online] October 03, 2007. [Cited: June 15,

2008.] http://en.wikipedia.org/w/index.php?title=Design_pattern_%28computer_science%29&oldid=161755559.

[6] Lee, Edwards, et al., "Overview of the Ptolemy Project." Department of Electrical Engineering and Computer Science.

[Online] July 02, 2003. [Cited: June 15, 2008.]

http://www.ptolemy.eecs.berkeley.edu/publications/papers/03/overview/overview03.pdf. Technical Memorandum UCB/ERL

N03/25.

[7] Wiktionary Contributors., "Wiktionary Definition of "Analysis"." Wiktionary: a wiki-based Open Content dictionary. [Online]

May 23, 2008. [Cited: June 15, 2008.] http://en.wiktionary.org/w/index.php?title=analysis&oldid=4625313.

[8] ProMARTE Team., "UML Profile for MARTE RFP." MARTE Specification. [Online] February 04, 2005. [Cited: June 11,

2008.] http://www.omg.org/docs/realtime/05-02-06.pdf. realtime/05-02-06.


Speaker Biography

Lonnie VanZandt

Artisan Software Partner; Artisan Studio® user since 2000

Independent Consulting Systems Engineer (Predictable Response

Consulting) since 2000

Specialties include: Operating Systems kernels, Real-time Systems, Object

Oriented Systems, Network Protocols, UML™ Modeling, Artisan Studio®

Usage, Together© Usage

Career includes: AT&T Lucent Bell Labs, TimeSys Linux, Northrop

Grumman {Cleared}, DesignNet, …

Education: BS and MS, Computer Engineering, University of Illinois, Urbana


Copyright Notices

UML™, OMG™, MDA™, MDD™, SysML™, MARTE™, and the OMG MDA

Logo are either registered trademarks or trademarks of Object Management

Group, Inc. in the United States and/or other countries.

Artisan Studio® and the Artisan Studio® Logo are either registered

trademarks or trademarks of Artisan Software Tools Ltd. in the United

States and/or other countries.

Each slide within this presentation is Copyright © 2008 Artisan Software.

http://www.omg.org/mda/index.htm

Model-Driven Development - Object Management Group

Documents