The role of MDSD as an
Download
1 / 60

Markus Völter [email protected] voelter.de - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

The role of MDSD as an Architectural Catalyst. Markus Völter [email protected] www.voelter.de. About me. Markus Völter [email protected] www.voelter.de. Independent Consultant Based out of Heidenheim, Germany Focus on Software Architecture Middleware Model-Driven Software Development.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Markus Völter [email protected] voelter.de' - maude


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

The role of MDSD as an

Architectural Catalyst

Markus Vö[email protected]


About me
About me

Markus Völter

[email protected]

www.voelter.de

  • Independent Consultant

  • Based out of Heidenheim, Germany

  • Focus on

    • Software Architecture

    • Middleware

    • Model-Driven SoftwareDevelopment


C o n t e n t s
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


C o n t e n t s1
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


Model driven software development
Model-Driven Software Development

  • MDSD 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.


Mdsd on a slide
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

compile

semantics

Model

Ontology

interpret

no

precise/

Domain

roundtrip

executable

Specific

Language

graphical

Metamodel

textual


Mdsd in industry
MDSD in Industry

  • Model-Driven Development (MDSD)pragmatic technology, process building blocks

  • OMG’s Model-Driven Architecture (MDA)standardization effort, technology-focus, platform independence, m2m transformations

  • Microsoft’s Software Factories (SF)framework for domain-specific IDE tooling, DSLs are part of this approach

  • Generative Programming (GP)traditional small scale, technology focused

  • Language-Oriented Programming (LOP)integrate DSLs into IDE with editors, debuggers, symbolic integration


How mdsd works
How MDSD works

  • Developer develops model(s)based on certain metamodel(s), expressed using a DSL.

  • Using code generation templates, the model is transformed to executable code.

    • Alternative: Interpretation

  • Optionally, the generated code is merged with manually written code.

  • One or more model-to-model transformation steps may precede code generation.



C o n t e n t s2
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


Software architecture process on a slide
Software Architecture Process „on a slide“

…and actually, this is

a talk of its own…

  • Today‘s Problems:

    • Too much technology

    • Too many hypes and buzzwords

    • Too many standards too early

    • So: People don‘t 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


Architecture centric mdsd
Architecture-Centric MDSD

  • It is essential that, in a first step, you build an MDSD Infrastructure that consolidates your software architecture – architecture-centric MDSD.

    • Metamodels are on the abstraction level of the architectural concepts of the target architecture

    • Models express software structures (such as components, processes, etc).

    • On top of this infrastructure, additional, more specific layers can be cascaded (next slide)

  • This approach makes sure the software architecture receives the level of attention it deserves:building this basic MDSD infrastructure makes you think hard about the your system‘s architectural concepts



C o n t e n t s3
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


What is metamodelling i
What is Metamodelling I

  • In order to define a modelling language by specifying its metamodel, you‘ll need another language: This is typically called the metametamodelling language.

  • A metamodel is a modelof a modelling language.It is not „a model of a model!“

  • The OMG defines fourmetalevels, the meta-metamodel is called theMOF, or Meta ObjectFacility.



Example simple model metamodel
Example: Simple Model/Metamodel

  • We want to define a textual language to define interfaces/classes. Example:

  • The metamodel/AST for this kind of definition looks like the following:

class SomeClass { operation doSomething( i:int, j:int ):String; operation anotherOne(): boolean; attribute anAttr: String;};



How do i come up with a good metamodel
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 DSLs see below, Cascading


How do i come up with a good metamodel ii
How do I come up with a good metamodel? II

  • In order to continuously improve and validate the metamodel 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 sentence’s statement is just wrong

    • you have to update the meta model.

  • (Based on Eric Evans’ Ubiquitous Language)


How do i come up with a good metamodel iii
How do I come up with a good metamodel? III

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


C o n t e n t s4
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


Architectural styles and patterns
Architectural Styles and Patterns

  • Architectural Patterns capture architectural blueprints or styles and describe their characteristics in the well-known pattern form.

  • Architectural patterns, if described right, imply a kind of „metamodel“ – a collection of (types of) artefacts that can be used to build an architecture with certain properties.

  • As such, architectural patterns can be the basis for you domain‘s architectural metamodel.


Architectural patterns the pipes and filters pattern
Architectural Patterns / The Pipes and Filters Pattern

  • Thumbnail:

    • The Pipes and Filters pattern provides a structure for systems that process a stream of data.

    • Each processing step is encapsulated in a filter component.

    • Data is passed through pipes between adjacent filters.

    • Recombining filters allows you to build families of related systems.

  • Known Uses:

    • Compilers (different stages)

    • UNIX shells

    • CMS Pipelines

    • Image Processing (ALMA)



C o n t e n t s5
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


Code generation vs platform
Code Generation vs. Platform

  • There is no point in generating 100% of an application’s code. You might want to generate 100% for a certain part/aspect, but other code will always be reused from a platform.

  • The ratio of generated code and platform code varies

    • From system to system

    • And also in one system over time

    • If the platform gets too complicated or too slow, generate more code.

    • If the generator gets too complicated or generates lots of identical code, move it to the platform

  • Generated code is often framework completion code – DSLs make frameworks easier to use!


Rich domain specific platform
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


C o n t e n t s6
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


The role of architecture ii
The Role of Architecture II

  • MDSD helps you come up with a good architecture, since it requires a few, well defined concepts; otherwise, the approach does not work.

    • The act of building a generator „point your nose“ to the architecturally important questions.

  • MDSD can also help you to enforce the architecture especially in large projects because

    • architectural issues can be controlled on the model level,

    • and the generator removes „degrees of freedom“ for developers.


Architecture enforcement using mdsd
Architecture „Enforcement“ using MDSD

  • Example:

  • Problem: How do you ensure that developers can actually only reference (use) those components, which are declared as being used in the model?


Typical solution without mdsd
Typical Solution, without MDSD

public class SMSAppImpl { public void tueWas() { TextEditor editor = Factory.getComponent(“TextEditor”); editor.setText( someText ); editor.show(); }}

  • Problems:

    • Developers can lookup, use, and thus, depend on whatever they like

    • Developers are not guided (by IDE, compiler, etc.) what they are allowed to access and what is prohibited


Improved solution with mdsd
Improved Solution, with MDSD

public interface SMSAppContext extends ComponentContext { public TextEditorIF getTextEditorIF(); public SMSIF getSMSIF(); public MenuIF getMenuIF();}

public class SMSAppImpl implements Component { private SMSAppContext context = null; public void init( ComponentContext ctx) { this.context = (SMSAppContext)ctx; } public void tueWas() { TextEditor editor = context.getTextEditorIF(); editor.setText( someText ); editor.show();} }

  • Better, because:

    • Developers can only access what they are allowed to…

    • … and this is always in sync with the model

    • IDE can help developer (ctrl+space in eclipse)

    • Architecture (here: Dependencies) are enforced and controlled


Relationship programming model model
Relationship Programming Model/Model

  • The programming model must be true to the model and the constraints checked therein:

    • If certain constraints on the model hold

    • Then the programming model must ensure that these constraints can’t be violated in the “real” code

    • Example:

      • constraints, saythere are no illegal dependencies in the model...

      • The programming model must then be sure that no illegal dependencies can be created in the manually written code

  • If this is not the case, constraint checks in the model don’t help you much!


Relationship programming model model ii
Relationship Programming Model/Model II

  • Conformance of the manually written code to guidelines implied by the generator (and thus, by the constraints) can be checked by using

    • compiler tricks such as static if-false blocks that cast types around or “call” methods

    • subsequent checks check the manually written code for consistency with the guidelines/programming model

public class SCMComponentBase ... {

static { if ( false ) { SCMComponentBase i = (SCMComponentBase) (new SCMBusinessComponent()); } }

}


Relationship programming model model iii
Relationship Programming Model/Model III

  • The openArchitectureWare RecipeFramework can be used to subsequently check manually written code

    • During the generator run, we generate the generated code;

    • in addition, based on the model, we instantiate checks that need to be verified later on the manually-written code

    • In the IDE, the failed checks are shown to the user hinting at “problems” with the manualy code that need to be fixed.

    • Once a problem is fixed, the complaint goes away.

    • For many failed checks, a “fix this” button can be activated to fix the problem automatically.

  • A fairly small number of such Checks can get you a long way...



C o n t e n t s7
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


Three basic viewpoints
Three Basic Viewpoints

  • Type Model: Components, Interfaces, Data Types

  • Composition Model: Instances, “Wirings”

  • System Model: Nodes, Channels, Deployments


Viewpoint dependencies
Viewpoint Dependencies

  • Dependencies between Viewpoint Models are only allowed in the way shown below in order to

    • Be able to have several compositions per type model

    • And several system models per composition

  • This is important to be able to have several “systems”,

    • Several deployed locally for testing, using only a subset of the defined components,

    • And “the real system”






Variants
Variants

  • Many many variants of this metamodel are necessary in practice. These concern

    • Separate Interfaces

    • Component Types and Layering

    • Component Signatures

    • Hierarchical Components

    • Configuration Parameters

    • Asynchronous Communication

    • Events

    • Subsystems and Business Components

    • (Dynamic) Wiring

    • Container Types and Networks

    • Versioning

  • I have skipped them for reasons of brevity.


Three basic viewpoints generated stuff
Three Basic Viewpoints – Generated Stuff

  • Base classes for component implementation

  • Build-Scripts

  • Descriptors

  • Remoting Infrastructure

  • Persistence


Generated stuff ii
Generated Stuff II

  • From these diagrams,

    • we can generate a skeleton component class

    • all the necessary interfaces.

  • Developers simply inherit from the generated skeleton and implement the operations defined by the provided interfaces.




Component implementation
Component Implementation

  • We have not yet talked about the implementation code that needs to go along with components.

    • As a default, you will provide the implementation by a manually written subclass

  • However, for special kinds of components (“component kind” will be defined later) can use different implementation strategies -> Cascading!


Component implementation ii
Component Implementation II

  • Remember the example of the process componentsfrom before:

  • 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!


Aspect models
Aspect Models

  • Often, the described three viewpoints are not enough, additional aspects need to be described.

  • These go into separateaspect 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


Example aspect persistence
Example Aspect: Persistence

  • The following example shows a possible metamodel for a persistence aspect:


C o n t e n t s8
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA


Soa trivial
SOA – Trivial

  • Some people consider a well-done component-based system already a service-oriented architecture. Adopting this view, results in the following metamodel:


Soa the essence
SOA – The Essence

  • Contract First!

  • However, I consider a SOA to be a component architecture with the following important differences:

    • The core focus is on the messages and interactions

    • A registry that knows the services and their metadata is available

    • Multi-Language/Multi-Platform

  • For those reasons, MDSD and SOA go together extremely well – you almost have to use MDSD if you want to do “real” SOA.



Soa refined ii qos
SOA – Refined II: QoS

  • Another importantaspect is quality ofservice and other provision/consumptiondata.

  • The metamodel on the right shows how theseaspects can be takeninto account.


C o n t e n t s9
C O N T E N T S

  • Brief intro to MDSD

  • Architecture – Dehyped

  • Architectural Metamodels

  • The role of patterns

  • Platform vs. code generation

  • Architecture vs. the Programming Model

  • More specific: MDSD and CBD

  • More specific: MDSD and SOA

THE END.


Some advertisement
Some advertisement

  • Völter, Stahl: Modellgetriebene SoftwareentwicklungTechnik, Engineering, ManagementdPunkt Verlag, 2005www.mdsd-buch.de


ad