Meta-model based system design

1
(No Transcript)
2
Meta-model based system design

• Gábor Privitzky
• Gabor.Privitzky_at_ericsson.com
• Gábor Zsolt Nagy
• Gabor.Zsolt.Nagy_at_ericsson.com

3
Table of contents

• Todays software design
• Analysis and design
• Elaboration modeling approach
• Meta-models
• Translation modeling approach
• Experiences at Ericsson Hungary

4
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.

5
Todays software design

• Productivity problems
• Labor intensive
• Rework
• Portability problems
• Emerging technologies
• Heterogeneous implementation techniques
• Maintenance problems
• Quality problems
• Changing requirements

6
Traditional software development life cycle
Requirements
Text
Analysis
Text anddiagrams
Design
Text anddiagrams
Coding
Code
Testing
7
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
8
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

9
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

10
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)

11
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
12
MDA software development life cycle
Requirements
Text
Analysis
PIM
Design
PSM
Coding
Code
Testing
13
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

14
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
15
Elaboration approach
Aids Use Case Diagramming Sequence
Diagramming Collaboration Diagramming
Step 1 During analysis, construct a model of
the user application
16
Elaboration approach
elaborate the model
Step 2 During design, add control structures,
data structures, GUI concepts, tasking mechanisms
etc.
17
Elaboration approach
e.g. C header files (.h)
Step 3 Automated code generation
converts structural model elements to target
language
18
Elaboration approach
Step 4 Behavioral code is added manually,
introducing model and code maintenance management
demands.
19
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

20
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

21
How does translation work?

• OOA models can be simulated before implementation

Characteristic and platformspecificRequirements

• OOA models are translated by Model Compilers

Simulator
Source Code
ModelTranslator
OOAModel
FunctionalRequirements
Test Suits
TestCases
22
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

23
Meta layers
M0 User Objects
Pulp Fiction, 1994, Quentin
TarantinoPeter 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
MOFClass, MOFAttribute
24
Self recursive description

• Concepts
• Class
• Attribute
• Relationship

M2 (DSL)
M3

• Class
• name
• description

• Attribute
• name

• Relationship
• side A multiplicity
• side B multiplicity

25
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

26
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
27
Model translation
How does C meta-model describes a system?
How does PIM meta-model describes a system?
populated PIM meta-model
AMD
What is the system architecture ?
What are the charac-teristic requirements ?
28
Model translation
How does C meta-model describes a system?
How does PIM meta-model describes a system?
Model Translation
What are the charac-teristic requirements ?
What is the system architecture ?
29
Model translation
How does C meta-model describes a system?
How does PIM meta-model describes a system?
Model Translation
What are the charac-teristic requirements ?
What is the system architecture ?
C source code
30
Translation process
Populates
PIM
Target Code
31
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

32
ModelCompiler for Platform v1
Platform v1
33
Platform independentbusiness logic
App2
App1
App3
ModelCompiler for Platform v2
Platform v1
Platform v2
App1
App3
App2
34
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

35
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

36
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
37
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
38
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
39
Activity distribution of an MDA project
Other activities
11
Testing
12
Analysis
49
Implementation
28
40
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
41
KPI comparison of traditional and MDA proj.
Traditional MDA
Implemented requirements 48 83
Not implemented requirements 52 18
Cost (mhrs) 6800 3440
Analysis TRs 0 12
Implementation TRs 37 7
Architecture TRs 0 2
42
Experiences

• MDA is not a silver button. Doesnt 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)

43
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

44
Conclusion

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

45
Questions ?