1 / 33

Model-Driven Development

Model-Driven Development. Bran Selic IBM Distinguished Engineer IBM Rational Software. The $800M Bombshell. Deeply embedded in the software for controlling long-distance phone traffic routing sat the following (kind of) code:

yori
Download Presentation

Model-Driven Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model-Driven Development Bran SelicIBM Distinguished EngineerIBM Rational Software

  2. The $800M Bombshell • Deeply embedded in the software for controlling long-distance phone traffic routing sat the following (kind of) code: • …switch (caseIndex) {case‘A’: route = routeA; … break; …case‘M’: route = routeM; …case‘N’: route = routeN; … break; …} Missing “break” statement! • When this code ran (1990), the entire US Northeast lost long-distance phone service

  3. A Skeptic’s View of Software Models… PH reached X start ControlPH MonitorPH Current PH enable stop disable RaisePH Input valvecontrol “…bubbles and arrows, as opposed to programs, …never crash” -- B. Meyer“UML: The Positive Spin”American Programmer, 1997

  4. Models in Traditional Engineering • As old as engineering (e.g., Vitruvius) • Traditional means of reducing engineering risk

  5. Engineering Models Functional Model Modeled system • Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint • We don’t see everything at once • We use a representation (notation) that is easily understood for the purpose on hand

  6. How Engineering Models are Used • To help us understand complex systems • Useful for both requirements and designs • Minimize risk by detecting errors and omissions early in the design cycle (at low cost) • Through analysis and experimentation • Investigate and compare alternative solutions • To communicate understanding • Stakeholders: Clients, users, implementers, testers, documenters, etc. • To drive implementation • The model as a blueprint for construction

  7. Models versus Systems . . . • Differences due to: • Idiosyncrasies of actual construction materials • Construction methods • Scaling-up effects • Skill sets/technologies • Misunderstandings • Can lead to serious errors and discrepancies in the realization

  8. Characteristics of Useful Models • Abstract • Emphasize important aspects while removing irrelevant ones • Understandable • Expressed in a form that is readily understood by observers • Accurate • Faithfully represents the modeled system • Predictive • Can be used to answer questions about the modeled system • Inexpensive • Much cheaper to construct and study than the modeled system To be useful, engineering models must satisfy all of these characteristics!

  9. A Bit of Modern Software… SC_MODULE(producer) { sc_outmaster<int> out1; sc_in<bool> start; // kick-start void generate_data () { for(int i =0; i <10; i++) { out1 =i ; //to invoke slave;} } SC_CTOR(producer) { SC_METHOD(generate_data); sensitive << start;}}; SC_MODULE(consumer) { sc_inslave<int> in1; int sum; // state variable void accumulate (){ sum += in1; cout << “Sum = “ << sum << endl;} SC_CTOR(consumer) { SC_SLAVE(accumulate, in1); sum = 0; // initialize }; SC_MODULE(top) // container { producer *A1; consumer *B1; sc_link_mp<int> link1; SC_CTOR(top) { A1 = new producer(“A1”); A1.out1(link1); B1 = new consumer(“B1”); B1.in1(link1);}}; Can you spot the architecture?

  10. …and its UML Model «sc_link_mp» link1 «sc_ctor»producer «sc_ctor»consumer out1 in1 start Can you spot the architecture?

  11. The Software and Its Model SC_MODULE(producer) { sc_outmaster<int> out1; sc_in<bool> start; // kick-start void generate_data () { for(int i =0; i <10; i++) { out1 =i ; //to invoke slave;} } SC_CTOR(producer) { SC_METHOD(generate_data); sensitive << start;}}; SC_MODULE(consumer) { sc_inslave<int> in1; int sum; // state variable void accumulate (){ sum += in1; cout << “Sum = “ << sum << endl;} SC_CTOR(consumer) { SC_SLAVE(accumulate, in1); sum = 0; // initialize }; SC_MODULE(top) // container { producer *A1; consumer *B1; sc_link_mp<int> link1; SC_CTOR(top) { A1 = new producer(“A1”); A1.out1(link1); B1 = new consumer(“B1”); B1.in1(link1);}}; «sc_ctor»producer «sc_ctor»consumer «sc_link_mp» link1 out1 in1 start

  12. Model Evolution: Refinement void generate_data(){for (int i=0; i<10; i++) {out1 = i;}} producer NotStarted producer start /generate_data( ) Started NotStarted refine start St1 St2 Started • Models can be refined continuously until the specification is complete «sc_method»producer out1 start

  13. The Remarkable Thing About Software Software has the rare property that it allows us to directly evolve models into full-fledged implementations without changing the engineering medium, tools, or methods! • This ensures perfect accuracy of software models; since the model and the system that it models are the same thing The model evolves into the system it was modeling

  14. Model-Driven Style of Development (MDD) (1) ABSTRACTION (2) AUTOMATION «sc_module»producer «sc_module»producer out1 out1 start start SC_MODULE(producer) {sc_inslave<int> in1; int sum; // void accumulate (){ sum += in1; cout << “Sum = “ << sum << endl;} • An approach to software development in which the focus and primary artifacts of development are models (as opposed to programs) • Based on two time-proven methods Realm of modelinglanguages Realm of tools SC_MODULE(producer) {sc_inslave<int> in1; int sum; // void accumulate (){ sum += in1; cout << “Sum = “ << sum << endl;}

  15. OMG’s Model-Driven Architecture (MDA) (1) ABSTRACTION (2) AUTOMATION «sc_module»producer «sc_module»producer out1 out1 start start OpenStandards • An OMG initiative • A framework for a set of open standards in support of MDD MDA • Standards for: • Modeling languages • Model transformations • Software processes • Model interchange…

  16. ABSTRACTION: The Modeling Language Domain

  17. Modeling versus Programming Languages high low • Cover different ranges of abstraction ModelingLanguages(UML,…) DHI:statecharts,interactiondiagrams,architecturalstructure, etc. Level of Abstraction ProgrammingLanguages(C/C++, Java, …) DLO:data layout, arithmeticaland logicaloperators,etc.

  18. Covering the Full Range of Detail high ModelingLanguages(UML,…) Level of Abstraction ProgrammingLanguages(C/C++, Java, …) implementation level detail (applicationspecific) low Fine-grainlogic,arithmeticformulae,etc. (Any) ActionLanguage

  19. Example: Combination of Languages void generate_data(){for (int i=0; i<10; i++) {out1 = i;}} producer NotStarted start /generate_data( ) Started St1 St2 • Combination of languages and representations • Each optimized for its purpose

  20. MDD Modeling Language Requirements • High expressive power • Concepts closer to domain and distant from the implementation technology “platform independent” concepts • Different domains need different concepts  need domain-specific languages • Adequate semantic precision and clarity • Models must be as accurate as their intended purpose requires • i.e., from “sketching” through code generation

  21. Domain-Specific Languages • Where do we start? • DSLs from “scratch” • Pro: - Highly optimized set of concepts • Con: - Need to reinvent many wheels (e.g., objects, interactions…)- Need to learn a new language for every domain- Need to provide full tool support for every domain • Example: • SDL: a DSL for describing telecom protocols (refined since 1970) • Latest version: UML profile (Z.109)

  22. The Languages of MDA GeneralStandard UML Real-Timeprofile Meta ObjectFacility (MOF) EAI profile Common Warehouse Metamodel (CWM) Softwareprocess profile A modeling language for defining modeling languages etc. etc. • Set of modeling languages for specific purposes For general OO modeling For exchanging information about businessdata

  23. AUTOMATION: The Tools Domain

  24. Primary Forms of Automation for MDD • Model transformations • Code generation, for analysis, for selective viewing,… • Computer-based validation • Formal methods (qualitative and quantitative) • Computer-based testing • Automated test generation, setup, and execution • Computer-based model execution • Particularly execution of abstract and incomplete models-- when most of the important decisions are made

  25. What is Automatic Code Generation? void generate_data(){for (int i=0; i<10; i++) {out1 = i;}} «sc_ctor»producer producer out1 start program(e.g., C++) NotStarted main () { BitVector typeFlags (maxBits); char buf [1024]; cout << msg; start /generate_data( ) Started while (cin >> buf) { for (int i = 0;i<maxBits;i++) if (strcmp(typeTbl[i],buf)==0) {typeFlags += i; break;} if ... St1 St2 Model transformer • Automated translation into semantically equivalent programs

  26. Model Execution • By inspection • mental execution • unreliable ? X = cos (h + p/2)+ x*5 X = cos (h + p/2)+ x*5 • By formal analysis • mathematical methods • reliable (theoretically) • software is very difficult to model mathematically! ? ? X = cos (h + p/2)+ x*5 X = cos (h + p/2)+ x*5 X = cos (h + p/2)+ x*5 X = cos (h + p/2)+ x*5 • By experimentation (execution) • more reliable than inspection • direct experience/insight

  27. Automatic Code Gen: State of the Art • Efficiency • performance and memory utilization: within ±5-15% of equivalent manually coded system • Scalability • compilation time (system and incremental change): within 5-20% of manual process • system size: • Complete systems in the order of 4MLOC have been constructed using full code generation • Teams of over 400 developers working on a common model

  28. Automating Engineering Analysis 4 3.1 m 5 • Inter-working of specialized tools via shared standards Automatically derived analysis model QoS Annotations Overlay Model Editing Tool Model Analysis Tool 2.5 Inverse automated model conversion

  29. Example: Schedulability Annotations «SAAction» {SAPriority=2, SAWorstCase=(93,'ms'), «SATrigger» RTduration=(33.5,'ms')} {SASchedulable=$R1, A.1.1:main ( ) RTat=('periodic',100,'ms')} «SAResponse» {SAAbsDeadline=(100,'ms')} A.1:gatherData ( ) «SASchedulable» Sensors TelemetryGatherer TGClock : Clock :SensorInterface :DataGatherer «SAAction» {RTstart=(16.5,'ms'), RTend=(33.5,'ms')} TGClock : Clock A.1.1.1: writeStorage ( ) «SAResource» «SATrigger» {SACapacity=1, {SASchedulable=$R2, SAAccessControl=PriorityInheritance} RTat=('periodic',60,'ms')} «SAResponse» SensorData «SAResponse» {SAPriority=3, {SAAbsDeadline=(60,'ms')} :RawDataStorage SAWorstCase=(177,'ms'), C.1:displayData ( ) RTduration=(46.5,'ms')} B.1.1 : main ( ) «SAAction» «SAAction» {RTstart=(3,'ms'), {RTstart=(10,'ms'), RTend=(5,'ms')} RTend=(31.5,'ms')} C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( ) «SASchedulable» «SASchedulable» TelemetryDisplayer TelemetryProcessor : DataDisplayer :DataProcessor «SATrigger» {SASchedulable=$R3, «SAResponse» RTat=('periodic',200,'ms')} Display {SAPriority=1, «SAResponse» :DisplayInterface SAWorstCase=(50.5,'ms'), {SAAbsDeadline=(200,'ms')} RTduration=(12.5,'ms')} B.1:filterData ( ) C.1.1 : main ( ) TGClock : Clock «SASituation» Result

  30. Example: Deployment Specification «SASchedulable» «SASchedulable» «SASchedulable» TelemetryDisplayer TelemetryGatherer TelemetryProcessor : DataDisplayer :DataGatherer :DataProcessor «GRMdeploys» «SAEngine» «SAOwns» «SAResource» {SARate=1, SensorData SASchedulingPolicy=FixedPriority} :RawDataStorage :Ix86Processor

  31. Example: Analysis Results {SASchedulable=$true, {SASchedulable=$true {SASchedulable=$true «SASituation» «SAAction» {SAPriority=2, SAWorstCase=(93,'ms'), «SATrigger» RTduration=(33.5,'ms')} A.1.1:main ( ) RTat=('periodic',100,'ms')} «SAResponse» {SAAbsDeadline=(100,'ms')} A.1:gatherData ( ) «SASchedulable» Sensors TelemetryGatherer TGClock : Clock :SensorInterface :DataGatherer «SAAction» {RTstart=(16.5,'ms'), RTend=(33.5,'ms')} TGClock : Clock A.1.1.1: writeStorage ( ) «SAResource» «SATrigger» {SACapacity=1, SAAccessControl=PriorityInheritance} RTat=('periodic',60,'ms')} «SAResponse» SensorData «SAResponse» {SAPriority=3, {SAAbsDeadline=(60,'ms')} :RawDataStorage SAWorstCase=(177,'ms'), C.1:displayData ( ) RTduration=(46.5,'ms')} B.1.1 : main ( ) «SAAction» «SAAction» {RTstart=(3,'ms'), {RTstart=(10,'ms'), RTend=(5,'ms')} RTend=(31.5,'ms')} C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( ) «SASchedulable» «SASchedulable» TelemetryDisplayer TelemetryProcessor : DataDisplayer :DataProcessor «SATrigger» «SAResponse» RTat=('periodic',200,'ms')} Display {SAPriority=1, «SAResponse» :DisplayInterface SAWorstCase=(50.5,'ms'), {SAAbsDeadline=(200,'ms')} RTduration=(12.5,'ms')} B.1:filterData ( ) C.1.1 : main ( ) TGClock : Clock

  32. Conclusion • The problem: • We cannot keep implementing our applications using the programming technologies of the late Fifties’ • The demands on functionality, reliability, dependability, availability, security, and performance demanded of modern software. • We need to, can do, and have already done better! • MDA: • Increased levels of abstraction • Increased levels of automation • Open standards

  33. QUESTIONS? (bselic@ca.ibm.com)

More Related