72088af563d888d1377d6e67ae97b451.ppt
- Количество слайдов: 33
® IBM Software Group Model-Driven Development Bran Selic IBM Distinguished Engineer IBM Rational Software Cli
The $800 M Bombshell w Deeply embedded in the software for controlling long -distance phone traffic routing sat the following (kind of) code: § … switch (case. Index) { case‘A’: route = route. A; … break; … case‘M’: route = route. M; … case‘N’: route = route. N; … break; …} Missing “break” statement! w When this code ran (1990), the entire US Northeast lost 2 long-distance phone service IBM Software Group |
A Skeptic’s View of Software Models… PH reached X Current PH Monitor PH Control PH e bl ena ble Raise PH start a dis stop Input valve control “…bubbles and arrows, as opposed to programs, …never crash” -- B. Meyer “UML: The Positive Spin” American Programmer, 1997 3 IBM Software Group |
Models in Traditional Engineering w As old as engineering (e. g. , Vitruvius) w Traditional means of reducing engineering risk 4 IBM Software Group |
Engineering Models w Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint Modeled system Functional Model w We don’t see everything at once w We use a representation (notation) that is easily understood for the purpose on hand 5 IBM Software Group |
How Engineering Models are Used 1. 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. 2. To drive implementation 1. 6 The model as a blueprint for construction IBM Software Group |
Models versus Systems Differences due to: . . . • Idiosyncrasies of actual construction materials • Construction methods • Scaling-up effects • Skill sets/technologies • Misunderstandings 7 Can lead to serious errors and discrepancies in the realization IBM Software Group |
Characteristics of Useful Models w Abstract § Emphasize important aspects while removing irrelevant ones w Understandable § Expressed in a form that is readily understood by observers w Accurate § Faithfully represents the modeled system w Predictive § Can be used to answer questions about the modeled system w Inexpensive To be useful, engineering models must § Much cheaper to construct and study than the modeled satisfy system all of these characteristics! 8 IBM Software Group |
A Bit of Modern Software… SC_MODULE(producer) { sc_outmaster<int> out 1; sc_in<bool> start; // kick-start void generate_data () { for(int i =0; i <10; i++) { out 1 =i ; //to invoke slave; } } SC_CTOR(producer) { SC_METHOD(generate_data); sensitive << start; }}; SC_MODULE(consumer) { sc_inslave<int> in 1; int sum; // state variable void accumulate (){ sum += in 1; cout << “Sum = “ << sum << endl; } 9 SC_CTOR(consumer) { SC_SLAVE(accumulate, in 1); sum = 0; // initialize }; SC_MODULE(top) // container { producer *A 1; consumer *B 1; sc_link_mp<int> link 1; SC_CTOR(top) { A 1 = new producer(“A 1”); A 1. out 1(link 1); B 1 = new consumer(“B 1”); B 1. in 1(link 1); }}; Can you spot the architecture? IBM Software Group |
…and its UML Model «sc_link_mp» «sc_ctor» producer start «sc_ctor» link 1 out 1 in 1 consumer Can you spot the architecture? 10 IBM Software Group |
The Software and Its Model SC_CTOR(consumer) SC_MODULE(producer) { { SC_SLAVE(accumulate, in 1); sc_outmaster<int> out 1; sum = 0; // initialize sc_in<bool> start; // kick-start }; void generate_data () SC_MODULE(top) // container { { for(int i =0; i <10; i++) { producer *A 1; out 1 =i ; //to invoke slave; } consumer *B 1; } sc_link_mp<int> link 1; SC_CTOR(producer) SC_CTOR(top) { { SC_METHOD(generate_data); A 1 = new producer(“A 1”); sensitive << start; }}; A 1. out 1(link 1); SC_MODULE(consumer) B 1 = new consumer(“B 1”); { B 1. in 1(link 1); }}; sc_inslave<int> in 1; int sum; // state variable void accumulate (){ «sc_ctor» «sc_link_mp» sum += in 1; producer consumer link 1 cout << “Sum = “ << sum << start endl; } out 1 in 1 11 IBM Software Group |
Model Evolution: Refinement producer «sc_method» start producer out 1 void generate_data() {for (int i=0; i<10; i++) {out 1 = i; }} Not. Started producer start /generate_data( ) Not. Started start Started refine St 1 St 2 Started w Models can be refined continuously until the specification is complete 12 IBM Software Group |
The Remarkable Thing About 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 13 The model evolves into the system it was modeling IBM Software Group |
Model-Driven Style of Development (MDD) w An approach to software development in which the focus and primary artifacts of development are models (as opposed to programs) w Based on two time-proven methods (1) ABSTRACTION (2) AUTOMATION «sc_module» Realm of start modeling languages producer out 1 SC_MODULE(producer) {sc_inslave<int> in 1; int sum; // void accumulate (){ sum += in 1; cout << “Sum = “ << sum << endl; } 14 start producer out 1 Realm of tools SC_MODULE(producer) {sc_inslave<int> in 1; int sum; // void accumulate (){ sum += in 1; cout << “Sum = “ << sum << endl; } IBM Software Group |
OMG’s Model-Driven Architecture (MDA) w An OMG initiative § A framework for a set of open standards in support of MDD (1) ABSTRACTION (2) AUTOMATION «sc_module» start producer out 1 start MDA producer out 1 Standards for: • Modeling languages Open Standards • Model transformations • Software processes • Model interchange… 15 IBM Software Group |
ABSTRACTION: The Modeling Language Domain 16 IBM Software Group |
Modeling versus Programming Languages w Cover different ranges of abstraction high DHI: statecharts, interaction diagrams, architectural structure, etc. Level of Abstraction Programming Languages (C/C++, Java, …) low 17 Modeling Languages (UML, …) DLO: data layout, arithmetic al and logical operators, etc. IBM Software Group |
Covering the Full Range of Detail high Modeling Languages Level of Abstraction (UML, …) Programming Languages implementation level detail (application specific) 18 (C/C++, Java, …) (Any) Action Language low IBM Software Group | Fine-grain logic, arithmetic formulae, etc.
Example: Combination of Languages producer void generate_data() {for (int i=0; i<10; i++) {out 1 = i; }} Not. Started start /generate_data( ) Started St 1 St 2 w Combination of languages and representations 19 § Each optimized for its purpose Software Group | IBM
MDD Modeling Language Requirements w 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 w Adequate semantic precision and clarity § Models must be as accurate as their intended purpose requires § i. e. , from “sketching” through code generation 20 IBM Software Group |
Domain-Specific Languages w Where do we start? w 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 w Example: § SDL: a DSL for describing telecom protocols (refined since 1970) § Latest version: UML profile (Z. 109) 21 IBM Software Group |
The Languages of MDA w Set of modeling languages for specific purposes General Standard UML Meta Object Facility (MOF) For general OO modeling EAI profile Common Warehouse Metamodel (CWM) A modeling language for defining modeling languages 22 For exchanging information about business data etc. Real-Time profile Software process profile etc. IBM Software Group |
AUTOMATION: The Tools Domain 23 IBM Software Group |
Primary Forms of Automation for MDD w Model transformations § Code generation, for analysis, for selective viewing, … w Computer-based validation § Formal methods (qualitative and quantitative) w Computer-based testing § Automated test generation, setup, and execution w Computer-based model execution § Particularly execution of abstract and incomplete models -- when most of the important decisions are made 24 IBM Software Group |
What is Automatic Code Generation? w Automated translation into semantically equivalent programs «sc_ctor» producer start void generate_data() {for (int i=0; i<10; i++) {out 1 = i; }} out 1 Not. Started program (e. g. , C++) start /generate_data( ) main () { Bit. Vector type. Flags (max. Bits); Started char buf [1024]; St 1 cout << msg; St 2 while (cin >> buf) { for (int i = 0; i<max. Bits; i++) if (strcmp(type. Tbl[i], buf)==0) {type. Flags += i; break; } if. . . 25 Model transformer IBM Software Group |
Model Execution w By inspection ? § mental execution § unreliable w By formal analysis § mathematical methods § reliable (theoretically) § software is very difficult to model mathematically! w By experimentation (execution) § more reliable than inspection 26 X = cos (h + p/2) X =+ x*5 (h + p/2) cos + x*5 ? X = cos (h + p/2) X =+ x*5(h + p/2) cos + x*5 ? X = cos (h + p/2) X =+ x*5(h + p/2) cos + x*5 IBM Software Group |
Automatic Code Gen: State of the Art w Efficiency § performance and memory utilization: within ± 5 -15% of equivalent manually coded system w Scalability § compilation time (system and incremental change): within 5 -20% of manual process § system size: • Complete systems in the order of 4 MLOC have been constructed using full code generation • Teams of over 400 developers working on a common model 27 IBM Software Group |
Automating Engineering Analysis w Inter-working of specialized tools via shared standards Automatically Qo. S Annotations Overlay Model Editing Tool derived analysis model Model Analysis Tool 4 m 2. 5 3. 1 5 Inverse automated model conversion 28 IBM Software Group |
Example: Schedulability Annotations «SASituation» Sensors : Sensor. Interface «SAAction» {SAPriority=2, SAWorst. Case=(93, 'ms'), RTduration=(33. 5, 'ms')} A. 1. 1: main ( ) «SASchedulable» TGClock : Clock «SAAction» {RTstart=(16. 5, 'ms'), RTend=(33. 5, 'ms')} A. 1. 1. 1: write. Storage ( ) «SAResource» {SACapacity=1, SAAccess. Control=Priority. Inheritance} Sensor. Data : Raw. Data. Storage «SAAction» {RTstart=(3, 'ms'), RTend=(5, 'ms')} C. 1. 1. 1: read. Storage ( ) Telemetry. Displayer : Data. Displayer «SAResponse» {SAPriority=1, SAWorst. Case=(50. 5, 'ms'), RTduration=(12. 5, 'ms')} C. 1. 1 : main ( ) Result «SASchedulable» Telemetry. Gatherer : Data. Gatherer TGClock : Clock «SATrigger» {SASchedulable=$R 2, RTat=('periodic', 60, 'ms')} «SAResponse» {SAAbs. Deadline=(60, 'ms')} C. 1: display. Data ( ) «SATrigger» {SASchedulable=$R 1, RTat=('periodic', 100, 'ms')} «SAResponse» {SAAbs. Deadline=(100, 'ms')} A. 1: gather. Data ( ) «SAAction» {RTstart=(10, 'ms'), RTend=(31. 5, 'ms')} B. 1. 1. 1: read. Storage ( ) «SAResponse» {SAPriority=3, SAWorst. Case=(177, 'ms'), RTduration=(46. 5, 'ms')} B. 1. 1 : main ( ) «SASchedulable» Telemetry. Processor : Data. Processor Display : Display. Interface «SATrigger» {SASchedulable=$R 3, RTat=('periodic', 200, 'ms')} «SAResponse» {SAAbs. Deadline=(200, 'ms')} B. 1: filter. Data ( ) TGClock : Clock 29 IBM Software Group |
Example: Deployment Specification «SASchedulable» Telemetry. Displayer : Data. Displayer Telemetry. Gatherer : Data. Gatherer Telemetry. Processor : Data. Processor «GRMdeploys» «SAEngine» {SARate=1, SAScheduling. Policy=Fixed. Priority} : Ix 86 Processor 30 «SAOwns» «SAResource» Sensor. Data : Raw. Data. Storage IBM Software Group |
Example: Analysis Results «SASituation» «SAAction» {SAPriority=2, SAWorst. Case=(93, 'ms'), RTduration=(33. 5, 'ms')} A. 1. 1: main ( ) Sensors : Sensor. Interface «SASchedulable» Telemetry. Gatherer : Data. Gatherer «SASchedulable» «SAResource» {SACapacity=1, SAAccess. Control=Priority. Inheritance} Sensor. Data : Raw. Data. Storage «SAAction» {RTstart=(3, 'ms'), RTend=(5, 'ms')} C. 1. 1. 1: read. Storage ( ) Telemetry. Displayer : Data. Displayer «SAResponse» {SAPriority=1, SAWorst. Case=(50. 5, 'ms'), RTduration=(12. 5, 'ms')} C. 1. 1 : main ( ) TGClock : Clock «SAAction» {RTstart=(16. 5, 'ms'), RTend=(33. 5, 'ms')} A. 1. 1. 1: write. Storage ( ) TGClock : Clock «SATrigger» {SASchedulable=$true RTat=('periodic', 60, 'ms')} «SAResponse» {SAAbs. Deadline=(60, 'ms')} C. 1: display. Data ( ) «SATrigger» {SASchedulable=$true, RTat=('periodic', 100, 'ms')} «SAResponse» {SAAbs. Deadline=(100, 'ms')} A. 1: gather. Data ( ) «SAAction» {RTstart=(10, 'ms'), RTend=(31. 5, 'ms')} B. 1. 1. 1: read. Storage ( ) «SAResponse» {SAPriority=3, SAWorst. Case=(177, 'ms'), RTduration=(46. 5, 'ms')} B. 1. 1 : main ( ) «SASchedulable» Telemetry. Processor : Data. Processor Display : Display. Interface «SATrigger» {SASchedulable=$true RTat=('periodic', 200, 'ms')} «SAResponse» {SAAbs. Deadline=(200, 'ms')} B. 1: filter. Data ( ) TGClock : Clock 31 IBM Software Group |
Conclusion w 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. w We need to, can do, and have already done better! w MDA: 32 § Increased levels of abstraction § Increased levels of automation IBM Software Group |
QUESTION S? (bselic@ca. ibm. com) 33 IBM Software Group |
72088af563d888d1377d6e67ae97b451.ppt