Www.xtUML.org © 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering

www.xtUML.org© 2012 xtUML.org

Bill Chown – Mentor Graphics

Model Driven Engineering


BC, Inside xtUML 1, October 2012

What is Model-Driven Development?

2

There are many terms used with Model… Key characteristics of Model Driven Development

(MDD)

The model is the design

The model will grow, evolveand extend

There is a flow from abstraction to abstraction

Implementation is directly derived from the model

Model Driven Engineering

Model Based …

Model Driven Development



System Design Challenges

3

Design requirements are becoming more complex— Lower cost, lower power, lower weight— Increased performance, reliability, or safety

Convergence of multiple disciplines— Everything has to work together:

Digital, Analog, Software, Mechanical, etc. — Multi-company, distributed supply chains— Complicated communication via a number of

domain-specific file formats, tools, and protocols

Design optimization— More than just getting a design to ship, a successful

project relies on predictable schedules, and optimization of Reliability, Performance, Manufacturing Cost, and Life-cycle Cost



Attributes of Embedded Systems

4

Domain-specific

Highly heterogeneous

Distributed over networks

Highly interactive with physical world

Require multiple disciplines to implement

Validated mainly through physical prototyping

System integration and test organizations are

pivotal

Subject to rigorous quality, certification,

qualification rules



A B C users – the design team has many roles

A: Architect or Systems Engineer— Needs flexibility, tradeoffs— Requirements modeling, system architecture choices— active requirements validation as an Executable

Specification

B: Component Designer, hardware or software— Discipline-specific factors become the focus— Narrower domain, not directly controlled by other

domains— Representative execution environment for design and

debug— efficient implementation pathway to hardware and/or

software

C: System Integrator— Multi-domain connections, communications— Real world timing, behavior, interactions— Powerful virtual platforms address both hardware and

software



The Key System Design Questions

Am I building the right thing?— Validating the design against the specification— Optimizing design goals and performance— System Level Design and Validation

Am I building it correctly?— Verifying no functional errors in design blocks— And that reused blocks are integrated properly— Implementation-Based Platform Verification

Am I considering the right costs?— Lifecycle costs— Supply chain interactions— Cost of change



Concept to Solution – exploring the space

Initial ideas are often no more than conceptual proposals— A Concept model allows exploration of the problem or need

From a “Concept” model to [a set of] potential solutions— Explore and define requirements— Propose solution architectures and content— Demonstrate and exchange ideas with stakeholders— Consider and trade-off needs and costs— Create development-oriented derived requirements

– Actionable, concrete, executable, traceable & implementable

SolutionModels

Requirements

Looking at the Problem

Internal-external

“thought”

exchange

ConceptModel

Looking at Performance

Requirements


8

Domain Engineer

s

Integrated Team

Requirements

Development of the model(s)


ConceptModel

SolutionModels

SystemModel

Requirements

ArchitecturalModel

SubsystemModels

ImplementationModel

TargetModel

Looking at the Problem

Looking at Performance

Internal-external “thought” exchange

INTEGRATION │ VALIDATION │ VERIFICATION

DEMONSTRATION

Elaboration from Solution Models based

on system performance

Iteration



ExecutableSpecification

Demonstrate – with an Executable Specification

Deliver on the two key topics — Show what we have— Enable initial questions to be asked

Lead on to a successful design Build an effective design process

— Can be reused time and again on the path to implementation

????

Requirements

What?

Why?

How?Derived

Evolve the ModelDerive further Requirements

Create a demonstration of the requirements, in an active form, that can be assessed and adjusted


10


Tests


Drive Implementation


SoftwareHardwar

e

Concept

TestsSoftware

Development

HardwareDevelopme

nt


11


Virtual Platform


HW/ /SWVirtual Platform

Virtual Platform

SoftwareHardwar

e

Concept

SoftwareHardwar

eSoftware

Hardware

Tests

Tests

SoftwareDevelopme

nt

HardwareDevelopme

nt



Essential Model Abstractions

Platform Independent Model— Function, architecture, interfaces, interactions— Demonstrate requirements are understood and met

Platform Dependent Models— Hardware architecture, virtual prototypes— Software architecture, partitions, data— Determine resources, performance goals— Hardware-software co-design, before physical

implementation

Platform Specific Models— Implementations— Verification— Test— Deliverables


13

Implementation

Models can and should drive implementation In software, models generate code

— Ready to run, configured for RTOS, etc.

Now hardware flows are emerging— C to RTL synthesis flows— UML to SystemC for simulation / validation

Test languages also support direct generation


The evolution of a MDD model from requirements to prototype and then

production


14

Best practices in adopting MDD solutions

Consider the full flow context Start small

Identify a top question to answer earlier in the flow Contain the application of new flows to a

measurable scale

Look for cycle time improvements Look for data continuity rather than re-entry Look for early design iterations – not in

implementation



xtUML.org

The Open Source Initiative for xtUML


Documents

Www.xtUML.org © 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering