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

© 2012 xtUML.org What is Model-Driven Development? BC, Inside xtUML 1, October There are many terms used with Model… Key characteristics of Model Driven Development (MDD) The model is the design The model will grow, evolve and extend There is a flow from abstraction to abstraction Implementation is directly derived from the model Model Driven Engineering Model Based … Model Driven Development

© 2012 xtUML.org System Design Challenges BC, Inside xtUML 1, October 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

© 2012 xtUML.org Attributes of Embedded Systems BC, Inside xtUML 1, October 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

© 2012 xtUML.org A B C users – the design team has many roles BC, Inside xtUML 1, October 2012 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 5

© 2012 xtUML.org 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 BC, Inside xtUML 1, October

© 2012 xtUML.org Concept to Solution – exploring the space BC, Inside xtUML 1, October 2012 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 Solution Models Requirements Looking at the Problem Internal-external “thought” exchange Concept Model Looking at Performance Requirements 7

© 2012 xtUML.org Domain Engineers Integrated Team Development of the model(s) BC, Inside xtUML 1, October 2012 Concept Model Solution Models System Model Requirements Architectural Model Subsystem Models Implementation Model Target Model Looking at the Problem Looking at Performance Internal-external “thought” exchange Elaboration from Solution Models based on system performance 8

© 2012 xtUML.org Executable Specification Demonstrate – with an Executable Specification BC, Inside xtUML 1, October 2012 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 Model Derive further Requirements Evolve the Model Derive further Requirements 9 Create a demonstration of the requirements, in an active form, that can be assessed and adjusted

© 2012 xtUML.org Executable Specification Tests Executable Specification Drive Implementation BC, Inside xtUML 1, October 2012 Software Hardware ConceptConcept Tests Software Development Hardware Development 10

© 2012 xtUML.org Executable Specification Virtual Platform BC, Inside xtUML 1, October 2012 HW/ /SW Virtual Platform Virtual Platform Software Hardware ConceptConcept Software Hardware Software Hardware Tests Software Development Hardware Development 11

© 2012 xtUML.org Essential Model Abstractions BC, Inside xtUML 1, October 2012 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 12

© 2012 xtUML.org 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 13

© 2012 xtUML.org 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 xtUML.org xtUML.org The Open Source Initiative for xtUML BC, Inside xtUML 1, October