1 / 45

Meta-model based system design

Meta-model based system design. G ábor Privitzky Gabor.Privitzky @ericsson.com Gábor Zsolt Nagy Gabor. Zsolt.Nagy@ericsson.com. Table of contents. Today’s software design Analysis and design Elaboration modeling approach Meta-models Translation modeling approach

mahon
Download Presentation

Meta-model based system design

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. Meta-model based system design Gábor Privitzky Gabor.Privitzky@ericsson.com Gábor Zsolt Nagy Gabor.Zsolt.Nagy@ericsson.com

  2. Table of contents • Today’s software design • Analysis and design • Elaboration modeling approach • Meta-models • Translation modeling approach • Experiences at Ericsson Hungary

  3. MDA applied in Ericsson Hungary • MDA related activities since beginning of 2002 • Technology evaluation projects • Development of a C++ code generator • SNMP capabilities (network configuration protocol) • CORBA notification service • Trace, debug capabilities • Development of 2 sub-systems of a 3G mgmt. System • 90% of code was generated! • Common service domains (XML, Logging, etc.) • TTCN test bed, XMI export, HTML doc. generator, etc.

  4. Today’s software design • Productivity problems • Labor intensive • Rework • Portability problems • Emerging technologies • Heterogeneous implementation techniques • Maintenance problems • Quality problems • Changing requirements

  5. Traditional software development life cycle Requirements Text Analysis Text anddiagrams Design Text anddiagrams Coding Code Testing

  6. Traditional software development life cycle Requirements • Productivity problems • Tedious programming tasks • Late feedback Text Analysis • Portability problems • Non-formalized analysis • Design and Analysis are not separated • Decisions are made in coding Text anddiagrams 60-70% of the budget in coding! Design • Maintenance • Shortcuts • Documentation overhead Text anddiagrams Coding • Quality problems • Non-formalizedknowledge in heads Code Testing

  7. Way of writing specifications • Textual specification • ambiguous • difficult to verify • difficult to keep up-to-date • “we will sort it out during the design” • Graphical specifications • no semantic meaning defined • undefined relations between diagram types • difficult to verify

  8. Expectations HOW? • Formalized way of specification • Early verification and testing • Separate business logic analysis and implementation • Software reuse • Leverage the initial investment in an early phase

  9. Analysis and Design • Analysis • Defines what to do; application business logic • Captures requirements and functional decisions in a platform independent manner • Results in a Platform Independent Model (PIM) • Design • Defines how to do • Captures characteristic and interface requirements • Defines a specific platform (e.g. C++, Solaris, .NET, J2EE) • Results in a Platform Specific Model (PSM)

  10. PIM and PSM • PIM (Platform Independent Model) Expresses only business functionality and behavior • PSM (Platform Specific Model) Defines also technology-specific details e.g. Chained list, index tables Director Movie Actor 1 0..* 0..* 0..* directed by directs acts in played by

  11. MDA software development life cycle Requirements Text Analysis PIM Design PSM Coding Code Testing

  12. What is Model Driven Architecture? • MDA is an object-oriented software development method • Splits platform independent and platform specific decision • Holds decisions in models instead of documents • Based on Unified Modeling Language • 2 approaches: • Elaboration (model refinement) • Translation • CASE tools that support software life-cycle

  13. Elaboration approach • Elaborationist approach • middleware independence, an open, vendor neutral approach for interoperability • Booch, Rumbaugh and Jacobsen with UML • OMG, Rational • profiles • Translationist approach • platform independence • Steve Mellor and Sally Shlaer • meta-model based tools • xUML PIM PSM Code

  14. Modeling structure (classes, attributes & associations) Modeling behavior (FSMs) Elaboration approach Aids : Use Case Diagramming Sequence Diagramming Collaboration Diagramming Step 1 : During ‘analysis’, construct a model of the user application

  15. Elaboration approach … elaborate the model Step 2: During ‘design’, add control structures, data structures, GUI concepts, tasking mechanisms etc.

  16. Elaboration approach e.g. C++ header files (.h) Step 3 : Automated code generation converts structural model elements to target language

  17. e.g. C++ program files (.cpp) Elaboration approach Step 4 : Behavioral code is added manually, introducing model and code maintenance management demands.

  18. Problems of elaboration approach • PSM is an extended PIM • New model elements are sprinkled into the PIM • Some model elements removed, merged or split apart • Destroys the original PIM • Platform specific elements may seep into PIM • Boundary between PIM and PSM is fuzzy • It often needs reverse engineering

  19. PIM Code PSM Platform independent models using MDA • Elaborationist view • middleware independence, an open, vendor neutral approach for interoperability • Booch, Rumbaugh and Jacobsen with UML • OMG, Rational • profiles • Translationist view • platform independence • Steve Mellor and Sally Shlaer • meta-model based tools • xUML

  20. How does translation work? • OOA models can be simulated before implementation Characteristic and platformspecificRequirements • OOA models are translated by Model Compilers Simulator ModelTranslator Source Code OOAModel FunctionalRequirements Test Suits TestCases

  21. Meta-modeling concept • The “meta” prefix • indicates one level of abstraction higher than root • is used in a relative manner • A meta-model is a model of a model • The concept can be recursively applied to itself • a meta-meta-model is a model of a meta-model • a meta-meta-meta-model is a model of a meta-meta-model …  • Meta-models are often defined for specific technology domains • OMG is now using M0-M3 notation for modeling

  22. Meta layers M0 : User Objects {“Pulp Fiction”, 1994, “Quentin Tarantino”}{“Peter Smith”, 2004.12.23} Populates Defines M1 : Model Director, Actor, Movie Populates Defines M2 : Meta-model Class, Attribute, Association Populates Defines M3 : Meta-meta-model MOF::Class, MOF::Attribute

  23. 1 0..* 0..* 1 1 0..* Self recursive description • Concepts: • Class • Attribute • Relationship M2 (DSL) M3 • Attribute • name • Class • name • description • Relationship • side A multiplicity • side B multiplicity

  24. Potential of meta-modeling • Help others understand the problem domain by using the same language • Define a vocabulary for the elements in the problem domain • Manage complexity by raising the level of abstraction at which we think and design • Enables to develop solid knowledge-base in centralized model repositories

  25. How does C++ meta-model describes a system? Domain Class State Transition Attribute Parameter Attribute Operation Class Function Constructor Destructor What is the system architecture ? What are the charac-teristic requirements ? Active_alarm alarm_ID problem_cause ... IP_address Actor actor_ID AMD domain Client client_ID acknowledge cease_alarm factory Network_element IP_address ne_ID create_alarm cease_alarm factory Model translation How does PIM meta-model describes a system? PIM meta-model C++ meta-model What is the task? To create an alarm handling application PIM

  26. Domain Class State Transition Actor Attribute Active alarm Parameter Client Network element Attribute actor_ID Operation alarm ID Class Function acknowledge client ID create alarm IP address problem cause cease alarm cease alarm ne ID Constructor Destructor IP address factory factory Active_alarm alarm_ID problem_cause ... IP_address Actor actor_ID AMD domain Client client_ID acknowledge cease_alarm factory Network_element IP_address ne_ID create_alarm cease_alarm factory Model translation How does PIM meta-model describes a system? How does C++ meta-model describes a system? populated PIM meta-model AMD What is the system architecture ? What are the charac-teristic requirements ?

  27. Domain Class State Transition AMD AMD Actor Actor Attribute Active alarm Active alarm Parameter Client Client Network element Network element Attribute actor_ID actor_ID Operation alarm ID alarm ID Class Function acknowledge acknowledge client ID client ID create alarm create alarm IP address IP address problem cause problem cause cease alarm cease alarm cease alarm cease alarm ne ID ne ID Constructor Destructor IP address IP address factory factory factory factory Active_alarm alarm_ID problem_cause ... IP_address Actor actor_ID AMD domain Client client_ID acknowledge cease_alarm factory Network_element IP_address ne_ID create_alarm cease_alarm factory Model translation How does PIM meta-model describes a system? How does C++ meta-model describes a system? Model Translation What is the system architecture ? What are the charac-teristic requirements ?

  28. Domain Class State Transition AMD Actor Attribute Active alarm Parameter Client Network element Attribute actor_ID Operation alarm ID Class Function acknowledge client ID create alarm IP address problem cause cease alarm cease alarm ne ID Constructor Destructor IP address factory factory Active_alarm alarm_ID problem_cause ... IP_address Actor actor_ID AMD domain Client client_ID acknowledge cease_alarm factory Network_element IP_address ne_ID create_alarm cease_alarm factory Model translation How does PIM meta-model describes a system? How does C++ meta-model describes a system? Model Translation What is the system architecture ? What are the charac-teristic requirements ? C++ source code

  29. Definedmapping Definedmapping Definedmapping Definedmapping PSIM-M PSIM-M PIMM-M PSMM-M PSMM-M Generates Appliedmapping Appliedmapping PSM PSI Translation process Populates PIM Target Code

  30. Benefits of translation approach • Early verification and testing • Separates business logic analysis and implementation • Software reuse • PSM and PIM are independently maintained • Leverage the initial investment in an early phase

  31. Platform independentbusiness logic App2 App1 App3 App1 App3 App2 ModelCompiler for Platform v1 Platform v1

  32. App1 App3 App2 Platform independentbusiness logic App2 App1 App3 ModelCompiler for Platform v2 Platform v1 Platform v2 App1 App3 App2

  33. Potential of model translation • Code generation is just one possibility • Architectures can be used for: • Document generation • Model verification • Model simulation • KPI measurements • Building architectures

  34. Model translation techniques • Template based translation • Source code templates extended with model queries • Model based translation specified with • ASL • QVT • XSLT • some other query language • Code generation can be preceded by several model-to-model translations

  35. Traditional software development life cycle Requirements • Productivity problems • Tedious programming tasks • Late feedback Text Analysis • Portability problems • Non-formalized analysis • Design and Analysis are not separated • Decisions are made in coding Text anddiagrams Design • Maintenance • Shortcuts • Documentation overhead Text anddiagrams Coding • Quality problems • Non-formalizedknowledge in heads Code Testing

  36. MDA software development life cycle Requirements • Productivity problems • Keeping intellectual property in modelsand architectures • Automated code generation • Early verification • Portability problems • Splitting platform specific and platform independent decisions • Maintenance • Strict forward engineering technique • Documents and code are generated • No data redundancy • Quality • Uniform code quality • Early verification Text Analysis PIM Design PSM Coding Code Testing

  37. Project timelines Traditional Functional specs Test &verification Requirementanalysis Prototyping Design documentation Coding Deployment Kick-off MS1 MS3 MS4 MS2 Kick-off MS1 MS3 MS4 MS2 Requirementanalysis OOA & OOD Model testing Code generation Deployment Test & verification MDA

  38. Activity distribution of an MDA project Other activities 11% Testing 12% Analysis 49% Implementation 28%

  39. Trend diagram of an MDA project 160 140 Analysis Implementation 120 Testing 100 80 MHR 60 40 20 0 3 6 8 10 12 14 16 18 20 22 24 26 28 31 33 36 38 Week

  40. KPI comparison of “traditional” and MDA proj.

  41. Experiences • MDA is not a “silver button”. Doesn’t solve anything from itself… • …but offers a strict process with technology support • Using iterations. At feedback every affected part is modified • Sometimes difficult to decide between architecture and application modeling • Loosely connected areas (requirements, legacy codes) are hard to keep consistent • Model tests replaces basic and function tests (partly)

  42. Effects on the organization • Introduction of new technology needs initial investment • Time and money • Gradual technology shift • Fear and resistance from management side • Strong resistance from sw. developer side • High expectations • Balance of employees’ competence portfolio must change

  43. Conclusion • It works! • Doesn’t solve everything • Reduces budget and time-to-market significantly • Offers uniform quality (for generated part) • Replaces textual documentation • Can keep different areas consistent but it’s not trivial • Requirement analysis • Sw analysis, design and implementation • Testing • Quality measurements, project tracking

  44. Questions ?

More Related