Markus Völter voelter@acm voelter.de

1. The role of MDSD as an Architectural Catalyst Markus Völtervoelter@acm.orgwww.voelter.de

2. About me Markus Völter voelter@acm.org www.voelter.de • Independent Consultant • Based out of Heidenheim, Germany • Focus on • Software Architecture • Middleware • Model-Driven SoftwareDevelopment

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

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

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

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

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

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

9. Example Tool: openArchitectureWare Generator • How it works:

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

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

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

13. Cascaded MDSD

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

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

16. How does the MOF look like?

17. 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;};

18. Example: The metamodel(s) of a typical enterprise app

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

20. 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)

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

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

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

24. 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)

25. A selection of architectural styles

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

27. 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!

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

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

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

31. 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?

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

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

34. 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!

35. 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()); } } }

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

37. oAW Recipe Framework Screenshot

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

39. Three Basic Viewpoints • Type Model: Components, Interfaces, Data Types • Composition Model: Instances, “Wirings” • System Model: Nodes, Channels, Deployments

40. 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”

41. Type Metamodel

42. Type Metamodel II (Data)

43. Composition Metamodel

44. System Metamodel

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

46. Three Basic Viewpoints – Generated Stuff • Base classes for component implementation • Build-Scripts • Descriptors • Remoting Infrastructure • Persistence • …

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

48. Cascading: Persistence

49. Cascading: Processes

50. 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!