Www.xtUML.org © 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
-
Upload
ariel-benson -
Category
Documents
-
view
221 -
download
0
Transcript of 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
www.xtUML.org© 2012 xtUML.org
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
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 2012
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
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 2012
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
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 20125
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
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 20126
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
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 20127
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
www.xtUML.org© 2012 xtUML.org
8
Domain Engineer
s
Integrated Team
Requirements
Development of the model(s)
BC, Inside xtUML 1, October 2012
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
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 20129
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
www.xtUML.org© 2012 xtUML.org
10
ExecutableSpecification
Tests
ExecutableSpecification
Drive Implementation
BC, Inside xtUML 1, October 2012
SoftwareHardwar
e
Concept
TestsSoftware
Development
HardwareDevelopme
nt
www.xtUML.org© 2012 xtUML.org
11
ExecutableSpecification
Virtual Platform
BC, Inside xtUML 1, October 2012
HW/ /SWVirtual Platform
Virtual Platform
SoftwareHardwar
e
Concept
SoftwareHardwar
eSoftware
Hardware
Tests
Tests
SoftwareDevelopme
nt
HardwareDevelopme
nt
www.xtUML.org© 2012 xtUML.org
BC, Inside xtUML 1, October 201212
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
www.xtUML.org© 2012 xtUML.org
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
BC, Inside xtUML 1, October 2012
The evolution of a MDD model from requirements to prototype and then
production
www.xtUML.org© 2012 xtUML.org
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
BC, Inside xtUML 1, October 2012
www.xtUML.org© 2012 xtUML.org
xtUML.org
The Open Source Initiative for xtUML
BC, Inside xtUML 1, October 201215