i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Markus Völter The role of MDSD as an Architectural Catalyst

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Markus Völter Independent Consultant Based out of Heidenheim, Germany Focus on Software Architecture Middleware Model-Driven Software Development About me

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst MDSD on a Slide Model Domain Specific Language Metamodel textual graphical Domain Ontology bounded area of knowlege/interest semantics precise/ executable multiple partial viewpoint subdomains composable Metametamodel target software architecture software architecture transform compile interpret multi-step single-step no roundtrip knowledge several design expertise

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Example Tool: openArchitectureWare Generator How it works:

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Software Architecture Process „on a slide“ 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 …and actually, this is a talk of its own…

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Cascaded MDSD

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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 model of a modelling language. It is not „a model of a model!“ The OMG defines four metalevels, the meta- metamodel is called the MOF, or Meta Object Facility.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst How does the MOF look like?

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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; };

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Example: The metamodel(s) of a typical enterprise app

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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)

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst How do I come up with a good metamodel? III 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. Example:

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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)

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst A selection of architectural styles

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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!

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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?

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Improved Solution, with MDSD public interface SMSAppContext extends ComponentContext { public TextEditorIF getTextEditorIF(); public SMSIF getSMSIF(); public MenuIF getMenuIF(); } 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 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(); } }

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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!

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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()); } } }

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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...

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst oAW Recipe Framework Screenshot

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Three Basic Viewpoints Type Model: Components, Interfaces, Data Types Composition Model: Instances, “Wirings” System Model: Nodes, Channels, Deployments

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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”

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Type Metamodel

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Type Metamodel II (Data)

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Composition Metamodel

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst System Metamodel

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Three Basic Viewpoints – Generated Stuff Base classes for component implementation Build-Scripts Descriptors Remoting Infrastructure Persistence …

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Cascading: Persistence

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Cascading: Processes

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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!

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Component Implementation II Remember the example of the process components from before: Various other implementation stragies 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!

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Aspect Models Often, the described three viewpoints are not enough, additional aspects need to be described. These go into separate aspect models, each describing a 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Example Aspect: Persistence The following example shows a possible metamodel for a persistence aspect:

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst SOA – Trivial Some people consider a well-done component-based system already a service-oriented architecture. Adopting this view, results in the following metamodel:

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst SOA – Refined

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst SOA – Refined II: QoS Another important aspect is quality of service and other provision/consumption data. The metamodel on the right shows how these aspects can be taken into account.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst 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.

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e © M a rk u s V ö l t e r MDSD‘s role as an architectural catalyst Some advertisement Völter, Stahl: Modellgetriebene Softwareentwicklung Technik, Engineering, Management dPunkt Verlag,