Kein Folientitel - PowerPoint PPT Presentation

About This Presentation
Title:

Kein Folientitel

Description:

Model-Driven Software Development www.mdsd-buch.de Some Essential Best Practices Markus V lter voelter_at_acm.org www.voelter.de About me Before we start – PowerPoint PPT presentation

Number of Views:101
Avg rating:3.0/5.0
Slides: 54
Provided by: MATHE206
Category:

less

Transcript and Presenter's Notes

Title: Kein Folientitel


1
Model-DrivenSoftware Development
www.mdsd-buch.de
Some Essential Best Practices
Markus Völtervoelter_at_acm.orgwww.voelter.de
2
About me
  • Markus Völter
  • voelter_at_acm.org
  • www.voelter.de
  • Independent Consultant
  • Based out of Heidenheim, Germany
  • Focus on
  • Software Architecture
  • Model-Driven SoftwareDevelopment
  • Middleware

3
Before we start I
  • Model-Driven Software Development is about making
    software development more domain-related as
    opposed to computing related. It is also about
    making software development in a certain domain
    more efficient.

4
Before we start II MDSD on a Slide
several
Metametamodel
target
subdomains
software
software
designexpertise
architecture
architecture
bounded area of
partial
knowlege/interest
composable
multiple
knowledge
viewpoint
multi-step
transform
Domain
single-step
semantics
compile
Model
Ontology
interpret
no
precise/
Domain
roundtrip
executable
Specific
Language
graphical
Metamodel
textual
5
Before we start III MDSD and MDA
MOF
several
Metametamodel
target
software
software
subdomains
architecture
architecture
designexpertise
bounded area of
partial
knowlege/interest
composable
PIM, PSM, ....
QVT
multiple
viewpoint
multi-step
transform
Domain
single-step
Model
semantics
compile
Ontology
interpret
no
precise/
Domain
roundtrip
executable
Specific
Language
OCL, Action Semantics
UMLProfiles
graphical
Metamodel
textual
  • Focus Platform Independence, (Tool) Interop

6
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
7
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
8
How do I come up with a good metamodel?
  • Incrementally!
  • Based on experience from previous projects, and
    by mining domain experts.
  • A very good idea is to start with a (typically)
    very well known domain the target software
    architecture (platform)? Architecture-Centric
    MDSD

9
Talk Metamodel
  • In order to continuously improve and validate the
    FORMAL META MODEL for a domain, it has to be
    exercised with domain experts as well as by the
    development team.
  • In order to achieve this, it is a good idea to
    use it during discussions with stakeholders by
    formulating sentences using the concepts in the
    meta model.
  • As soon as you find that you cannot express
    something using sentences based on the meta
    model,
  • you have to reformulate the sentence
  • the sentences statement is just wrong
  • you have to update the meta model.

10
Talk Metamodel II
  • Example
  • A component owns any number of ports.
  • Each port implements exactly one interface.
  • There are two kinds of ports required ports and
    provided ports.
  • A provided port provides the operations defined
    by its interface.
  • A required port provides access to operations
    defined by its interface.

11
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
12
Leverage the Model
  • The information captured in a model should be
    leveraged to avoid duplication and to minimize
    manual tasks.
  • Hence you may generate much more than code
  • user guides
  • help text
  • test data
  • build script
  • content, etc.
  • Find the right balance between the effort
    required for automating manual tasks and the
    effort of repetitively performing manual tasks
  • Make use of SELECT FROM BUY, BUILD, OR OPEN
    SOURCE in your assessment.

13
Separate Generated and Non-Generated Code
  • Keep generated and non-generated code in separate
    files.
  • Never modify generated code.
  • Design an architecture that clearly defines which
    artifacts are generated, and which are not.
  • Use suitable design approaches to join
    generated and non-generated code. Interfaces as
    well as design patterns such as factory,
    strategy, bridge, or template method are good
    starting points.

14
Separate Generated and Non-Generated Code II
  • A) Generated code can call non-generated code
    contained in libraries
  • B) A non-generated framework can call generated
    parts.
  • C) Factories can be used to plug-in the
    generated building blocks
  • D) Generated classes can also subclass
    non-generated classes.
  • E) The base class can also contain abstract
    methods that it calls, they are implemented by
    the generated subclasses(template method
    pattern)

15
Produce Nice-Looking Code whenever possible!
  • PRODUCE NICE-LOOKING CODE WHEREVER POSSIBLE!
  • When designing your code generation templates,
    also keep the developer in mind who has to at
    least to some extent work with the generated
    code, for example
  • When verifying the generator
  • Or debugging the generated code
  • Using this pattern helps to gain acceptance for
    code generation in general.
  • Examples
  • Comments
  • Use pretty printers/code formatters
  • Location string (generated from modelxyz)

16
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
17
Tools Overview
  • Many kinds of tools can be used in the context of
    model driven development
  • UML modelling tools
  • Metamodelling environments
  • (XMI) Repositories
  • Code Generators
  • Model verifiers
  • There is also a large amount of tools that are
    MDA certified. These range from completely
    integrated environments such as ArcStyler to
    simple code generators or technology specific
    generators (e.g. for J2EE).

18
Tools Vendor Lock-in
  • Because a lot of issues are not yet standardized,
    it is hard to integrate tools. Open issues
    include
  • Some XMI aspects
  • Specification of model transformation rules
  • Code generation
  • ...
  • As a consequence, integrated MDD/MDA tooling is
    currently impossible to achieve without vendor
    lock-in.
  • Alternatively, building/integrating your own
    tooling based on open source can be done, but
    requires compromises.
  • Many tools are exemplified in the context of code
    generation (see other presentation). Build Tools
    are also important. UML tools (such as Rational
    XDE) also develop in the direction of supporting
    MDA.

19
Tools The Ideal One
  • MOF Based Metamodelling, including OCL
  • Usage of thses metamodels for subsequent modeling
    of M1
  • Metamodel specific repositoriy
  • GUI adapted to metamodel
  • Model Validation based on metamodel
  • Also including OCL
  • Transformation rules based on user-defined
    metamodels
  • Flexible Code Generation
  • Test support

20
Implement the Metamodel
  • Implement the meta model in some tool that can
    read a model and check it against the meta model.
  • This check needs to include everything including
    declared constraints.
  • Make sure the model is only transformed if the
    model has been validated against the meta model.
  • The meta model implementation is typically part
    of the transformation engine or code generator
    since a valid model is a precondition for
    successful transformation.

21
Ignore Concrete Syntax
  • Define transformations based on the source and
    target meta models.
  • The transformer uses a three phase approach
  • first parse the input model into some in-memory
    representation of the meta model (typically an
    object structure),
  • then transforms the input model to the output
    model (still as an object structure)
  • and finally unparse the target model to a
    concrete syntax

22
Transformations as first class citizens
  • Transformations (and Templates) are central
    assets in MDSD. You should treat them
    accordingly.
  • Transformations should be versioned.
  • Refactor transformations to keep them current and
    well organized.
  • Modularize transformations, e.g. using
    object-oriented concepts such as encapsulation,
    polymorphism, inheritance, etc.

23
Modular, Automated Transforms
  • In order to more easily reuse parts of a
    transformation, it is a good idea to modularize a
    transform.
  • Note that in contrast to the OMG, we do not
    recommend looking at, changing or marking the
    intermediate models.
  • They are merely a standardized format for
    exchanging data among the transformations.
  • Example Multi-Step transformation from a
    banking-specific DSL to Java via J2EE

24
External Model Markings (AO-Modelling)
  • In order to allow the transformation of a source
    model into a target model (or to generate code)
    it is sometimes necessary to provide support
    information that is specific to the target meta
    model.
  • Example Entity Bean vs. Type Manager
  • Adding these to the source model pollutes the
    source model with concepts specific to the target
    model.
  • MDA proposes to add model markings, but this
    currently supported well by only very few tools.
  • Instead, we recommend keeping this information
    outside of the model (e.g. in an XML file) the
    transformation engine would use this auxiliary
    information when executing the transformations.

25
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
26
Example Tool openArchitectureWare Generator
  • Open Source, quite active project http//www.open
    architectureware.org
  • Core Features
  • Can Read any model (XMI from various UML tools,
    UML, textual, JDBC, Java classes )
  • Can generate any kind of output
  • Explicit Domain-Metamodel (implemented in Java)
  • Semi-Declarative Metamodel Constraints,
    Functional Programming
  • Simple, efficient template language
  • Template Polymorphism and Template overwriting
  • Multi-Model (Merging-Support)

27
Example Tool openArchitectureWare Generator
  • Core Features contd
  • Inter-Model References among various model
    syntaxes (i.e. UML to XML)
  • Support for Aspects in the metamodel and in the
    templates
  • Arbitrary Namespace Models can be supported
  • Plugin-Based Generator configuration (ant-based)
  • Additional Features
  • Syntax-Highlighting Template Editor for Eclipse
  • Metamodel can be generated from UML model, incl.
    DTD, HTML Docs, etc.
  • Graphical GEF-Based Editors can be generated
  • Dialog-Based Editors can be generated
  • Framework for building IDEs based on this
    Generator
  • Future Features
  • EMF Integration, Visio Integration

28
Example Tool openArchitectureWare Generator
  • How it works

29
Example Tool openArchitectureWare Generator
  • Usage Examples
  • Web Development (J2EE, Servlets, Struts)
  • Banking, Insurances
  • Mobile Phone Software (C QT, J2ME Java)
  • Embedded Software (C, CANbus, Osek)
  • Automotive Component Middleware
  • (Interactive) Web sites
  • Architectural Management, Entertainment)
  • Multi-Platform Middleware (XML, C, Java, )
  • Radioastronomy

30
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
31
Teaming issues
  • Using DSLs is not very different from normal
    programming every developer can basically do
    it.
  • Defining DSLs is, however, something completely
    different
  • Finding the right abstractions, defining
    metamodels, keeping the various metalevels
    sorted, etc. is not everybodys business.
  • Some of the tools to define metamodels, DSLs,
    generators and model-2-model transformations are
    not (yet) intuitively usable.
  • Therefore I recommend to keep DSL/generator
    development to a limited group of people in your
    project.

32
Iterative Dual Track Development
  • Develop Domain Architecture and at least one
    application at the same time.
  • Establish rapid feedback from application
    developers to domain architecture developers.
  • Develop both aspects iteratively and
    incrementally. Use strict timeboxing.
  • Infrastructure develops iteration n1 whereas
    application developers use iteration n.
  • Introduce new Domain Architecture releases only
    at the beginning of iterations.

33
Extract the Infrastructure
  • Before starting ITERATIVE DUAL-TRACK DEVELOPMENT,
    Extract the transformations from manually
    developed application.
  • Either, start by developing this prototype
    conventionally, then build up the MDSD
    infrastructure based on this running application,
  • Or extract the code from applications developed
    in the respective domain before doing MDSD (but
    only if the quality is sufficiently good!)

34
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
35
One DSL is not enough
  • Most systems can be structured into various
  • partitions functional subsystems
  • subdomains technical aspects
  • It is hardly possible to describe each of these
    with the same DSL.
  • You will need to come up withseparate DSLs
  • that have to be connectablein order to build
    the complete system

36
One DSL is not enough II - Example
37
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
38
Rich Domain-Specific Platform
  • Define a rich domain-specific application
    platform consisting of
  • Libraries
  • Frameworks
  • base classes
  • interpreters, etc.
  • The transformations will generate code for
    this domain-specific application platform.
  • As a consequence, the trans-formations become
    simpler.
  • DSLs and Frameworks are two sides of the same
    coin

39
Software Architecture Process on a slide
and actually, this is
a talk of its own
  • Todays Problems
  • Too much technology
  • Too many hypes and buzzwords
  • Too many standards too early
  • So People dont focus on architectural concepts
  • PHASE 1 Elaborate!
  • Technology-Independent Architecture
  • Programming Model
  • Technology Mapping
  • Mock Platform
  • Vertical Prototype
  • PHASE 2 Automate!
  • Architecture Metamodel
  • Glue Code Generation
  • DSL-based Programming Model
  • Model-based Architecture Validation

40
MDSD and CBD the three viewpoints
  • Type Model Components, Interfaces, Data Types
  • Composition Model Instances, Wirings
  • System Model Nodes, Channels, Deployments

41
Component Implementation
  • Componentimplementation should be based on
    notationsspecific to the kind of component
  • Various other implementationstragies can be
    used, such as
  • Rule-Engines
  • Procedural DSLs or action semantics
  • Note that, here, interpreters can often be used
    sensibly instead of generating code!

42
Aspect Models
  • Often, the described three viewpoints are not
    enough, additional aspects need to be described.
  • These go into separate aspect models, each
    describinga well-defined aspect of the system.
  • Each of them uses a suitable DSL/syntax
  • The generator acts as a weaver
  • Typical Examples are
  • Persistence
  • Security
  • Forms, Layout, Pageflow
  • Timing, QoS in General
  • Packaging and Deployment
  • Diagnostics and Monitoring

43
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Multi Model
  • Architecture and CBD
  • Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
44
Adopting MDSD prerequisites
  • Well-practices MDSD builds on several mature
    other practices, among them
  • Well-defined software architecture
  • Iterative software development and requirements
    management
  • Mature project automation (regression testing,
    automatic builds, etc.)

45
Adopting MDSD process
46
Levels of MDSD
  • You would typically start with architecture-centri
    c MDSD where the abstractions of the DSL
    correspond to the core concepts of the technical
    platform.
  • This automates many aspects of the technical
    aspects
  • Results in a wide platform/infrastructure
  • Many projects can be handled with the
    infrastructure
  • In later phases, functional MDSD infrastructures
    will be built on this technical one, resulting in
    cascaded MDSD.

47
Levels of MDSD
48
Levels of MDSD III M2M Transformations
49
Levels of MDSD III M2M Transformations II
50
Levels of MDSD III M2M Transformations III
51
PATTERN DSL-based Programming Model
52
C O N T E N T S
  • Domain Architecture
  • Domain Metamodelling
  • Code Generation
  • Tools
  • Features And Structure
  • An Example
  • Process
  • Testing
  • Multi Model
  • Adopting MDSD

Questions?
The End.
53
Some advertisement ?
  • For those, who happen to speak(or rather, read)
    german Völter, Stahl Modellgetriebene
    SoftwareentwicklungTechnik, Engineering,
    ManagementdPunkt, 2005www.mdsd-buch.de
  • For all othersA updated translation isunder
    wayModel-Driven Software Development, Wiley,
    Q2 2006www.mdsd-book.org
Write a Comment
User Comments (0)
About PowerShow.com