Kein Folientitel - voelter

Kein Folientitel - voelter

Model-Driven Development of Distributed, Component-Based Systems Model-Driven Development of component-based, Distributed systems Markus Vlter [email protected] www.voelter.de ingenieurbro fr sof twaretechnologie . w w w.voelter.de -1- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems About me Independent Consultant Based out of Heidenheim, Germany Focus on Software Architecture

Middleware Model-Driven Software Development ingenieurbro fr sof twaretechnologie Markus Vlter [email protected] www.voelter.de . w w w.voelter.de -2- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Overview These slides are composed of three parts. All parts are rather pragmatic and based on actual experience from many projects, in various (enterprise and embedded) domains. Part 1, Introduction to MDSD Introduces Model-Driven Software Development and teaches a couple of essential best practices. Part 2, Software Architectural Approach Explains how (I think) software architecture should be addressed in non-trivial projects. Illustrated with a component-based application from the enterprise world.

Part 3, A Components Reference Metamodel This section introduces a way to describe component based systems in a way that allows for all-aspect code generation. The description is introduced in the form of a metamodel. ingenieurbro fr sof twaretechnologie . w w w.voelter.de -3- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems CONTENTS PART 1: Introduction to MDSD ingenieurbro fr sof twaretechnologie . w w w.voelter.de -4- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 1, Introduction to MDSD What is MDSD Benefits

Mechanics and Tooling Process Issues Some Essential Best Practices ingenieurbro fr sof twaretechnologie . w w w.voelter.de -5- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 1, Introduction to MDSD What is MDSD Benefits Mechanics and Tooling Process Issues Some Essential Best Practices ingenieurbro fr sof twaretechnologie . w w w.voelter.de -6- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Domain Driven Development Domain Driven 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. Domain Concepts Domain Concepts mental work of developers Software Technology Concepts ingenieurbro fr sof twaretechnologie Software Technology Concepts . w w w.voelter.de -7- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD on a Slide several Metametamodel target software architecture design

expertise subdomains composable multi-step multiple knowledge transform bounded area of knowlege/interest partial viewpoint Domain single-step compile Model semantics Ontology no roundtrip interpret precise/

executable Domain Specific Language graphical Metamodel textual ingenieurbro fr sof twaretechnologie . w w w.voelter.de -8- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD Core Values We prefer to validate software-under-construction over validating software requirements We work with domain-specific assets, which can be anything from models, components, frameworks, generators, to languages and techniques. We strive to automate software construction from domain models; therefore we consciously distinguish between building software factories and building software applications We support the emergence of supply chains for software development, which implies domain-specific specialization

and enables mass customization ingenieurbro fr sof twaretechnologie . w w w.voelter.de -9- 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD Core Building Blocks domain analysis meta modelling model-driven generation (and: model transformation) template languages domain-driven framework design the principles for agile software development the development and use of Open Source infrastructure ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 10 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

DSLs in Industry Model-Driven Development (MDSD) pragmatic technology, process building blocks OMGs Model-Driven Architecture (MDA) standardization effort, technology-focus, platform independence, m2m transformations Microsofts 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 ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 11 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Reasons for using DSLs

You want to provide a way for your domain-experts to formally specify their knowledge, and to provide a way for your technology people to define how this is implemented (using model transformations). You might want to provide different implementations (i.e. more concrete models) for the same model, perhaps because you want to run it on different platforms (.NET, Java, CORBA). You may want to capture knowledge about the domain, the technology, and their mapping in a clear, uncluttered format. In general, you dont want to bother with implementation details when specifying your functionality. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 12 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 1, Introduction to MDSD What is MDSD Benefits Mechanics and Tooling Process Issues

Some Essential Best Practices ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 13 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD Benefits I Models are free of implementation artifacts they directly represent domain knowledge and are thus reusable. Implementations for various platforms can be generated in principle the technology change problem is adressed to some extend. Technology freaks and domain experts can take care of their business (transformations and models, respectively) and need to care of each others problems only in a limited way. Domain experts can play a direct role in development since they can more easily understand models expressed with a DSL as opposed to implementation code. Domain Experts play the central role they deserve! ingenieurbro fr sof twaretechnologie . w w w.voelter.de

- 14 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD Benefits II Development becomes more efficient since repetitive implementation code can be generated automatically. Architectural contraints/rules/patterns can more easily be enforced, since the they are embedded in the templates rather than just being documented (and ignored). This is especially important in really large teams, often in the context of Product-Line Engineering and Software System Families. Transformer/Generator can address cross-cutting concerns (just like an aspect weaver) ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 15 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Benefits for Software Quality DSLs, if they describe software structure/architecture requires

an explicit, well-defined architecture. Defining an architecture this way improves the quality of the system (indpendent of whether it is generated or not). Transformations capture expert knowledge. The generated code reflects this expert knowledge uniformly. An DSL-based Archtitecture defines a strict programming model for the manually developed parts again, uniformity and constrained-ness improves quality. Generator does not produce accidental errors either things are always right or always wrong. This makes finding errors easier! ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 16 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Benefits for Software Quality II In general, defining a DSL forces you to take care of many good things, which youd like to have in any application development project: Domain/Application Scoping Variability Management

Well-Defined Software Architecture, Architecture Metamodelling Trying to build a DSL/generator for a domain/target architecture enables your understanding of the domain/target architecture. This in itself is a huge benefit. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 17 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems DSL/Code Generation Financial Benefits Information Gain Normal Implementation Effort ion entat m e l Imp si De Goal gn

Effort is ys l a An Level of Detail Start Result of Analysis ingenieurbro fr sof twaretechnologie virtual or real Implementation model . w w w.voelter.de Implementation - 18 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems DSL/Code Generation Financial Benefits II Information Gain Realistic DSL based Implementation Effort A'

B Automation enImplem tation Goal M od el lin g A Savings because of Generation An al ys is Effort Savings based on the use of a semantically rich platform Level of Detail

Start Results of Analysis ingenieurbro fr sof twaretechnologie virtual or real implementation model . w w w.voelter.de Implementation - 19 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems DSL/Code Generation Financial Benefits III Information Gain Ideal DSL based Implementation Effort A' B Automation Goal ing A

Mo de ll Savings because of generation An aly sis Effort Savings based on the use of a semantically rich platform Level of Detail Start Results of Analysis ingenieurbro fr sof twaretechnologie virtual or real implementation model . w w w.voelter.de Implementation - 20 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

C O N T E N T S: Part 1, Introduction to MDSD What is MDSD Benefits Mechanics and Tooling Process Issues Some Essential Best Practices ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 21 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems How DSLs are usually used based on certain metamodel(s), expressed using a DSL. Using code generation templates, the model is transformed to executable code. Alternative: Interpretation Model Model Model

Metamodel Transformer Tranformation Rules Model Metamodel Transformer Code Generation Templates Generated Code Manually Written Code optional, can be repeated Developer develops model(s) Optionally, the generated code is merged with manually written code. One or more model-to-model transformation steps may precede code generation. optional

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 22 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Example Tool: openArchitectureWare Generator How it works: specification (model) metamodel instance of model parser metamodel instance written in terms of ingenieurbro fr sof twaretechnologie template engine output code templates

. w w w.voelter.de - 23 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems How Transformations Work Transformations (Model-2-Model as well as Model-2-Code) are at the heart of MDSD. However, due to limitations in space and time, I cannot provide details on how these work, except: For M2M Transformations, various textual or graphical languages exist (or are being worked on), some of them rulebased, others imperative. The simplest thing that could possibly work are 3GL procedures (e.g. in Java) that work on model elements directly. This works well in practice if metamodel API is good. For Code Generation, almost all generators use template- based approaches, where template control code is intertwined with to-be-generated code; the to-be-generated code is parametrized by properties that get their values from the underlying model. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 24 - 2 0 0 4 M a rk u s V l t e r

Model-Driven Development of Distributed, Component-Based Systems How Transformations Work II - Example Template (oAW) ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 25 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 1, Introduction to MDSD What is MDSD Benefits Mechanics and Tooling Process Issues Some Essential Best Practices ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 26 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems DSLs/Generation and Agility

Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. DSL-based Models are no paperwork, they are the code which is translated to executable code automatically Agility does not oppose tools in general compilers are ok, model transformers are a kind of compiler ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 27 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD and Agility II Project automation (ant, cruisecontrol) is ok in agile minds, so is automation of the writing of repetitive code Automation of the development process makes responding to change easier and faster (single source principle).

Changes in the model respond to changes in the functional requirements Changes in the templates/transformations can be used to evolve the architecture The customer on-site can be integrated better, if we have languages that are better related to domain concepts as opposed to 3GL code or the like. Pair programming between developer and domain expert is more realistic. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 28 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems MDSD and Agility III Tests can still be written manually (even before generation), generators can help is building mocks or scenarios We have done Test-Driven, Model-Driven Development We do not recommend a waterfall that first builds metamodel/ DSL/generators and then builds apps, rather, both are iteratively evolved in parallel. Domains Architectures are based on experience, not based on big design upfront Developers can do what they can do best: Some deal with applications and customer requirements,

Others deal with technical architecture, platforms and generators So: There is no conflict between Agility and DSLs/Generation! ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 29 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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.

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 30 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Teaming issues II - Roles Not all of these roles are necessary in every project, of course However, as an example, there is a fundamental difference between those who understand the domain and its abstractions (left branch) compared to those who know how to best use Customer some platform technology (right branch) Domain Analyst Domain Architect Domain Expert Language Designer Prototype Developer

ingenieurbro fr sof twaretechnologie . w w w.voelter.de Reference Implementor - 31 - Platform Developer Transformation Developer 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Iterative Dual Track Development Develop DSL/Generator 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 n+1 whereas application developers use iteration n. Introduce new DSL/Generator

releases only at the beginning of iterations. ingenieurbro fr sof twaretechnologie Application Development (n) Integration and Feedback feedback Infrastructure Development (n+1) . w w w.voelter.de - 32 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Iterative Dual Track Development II - Roles Note that the men in the diagram on the right are roles, you can easily have some of them be handled by the same person! Application Engineering

Domain Engineering Application Developer Project Manager Product Manager Test Engineer Customer Application Architect Domain Analyst Domain Expert Tester Domain Architect Requirements Analyst ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 33 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 DSL/Generator 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!) Metamodel DSL(s) Manually Developed Prototype Infrastructure Development Transformations Platform(s) Application Development Application Model ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 34 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 1, Introduction to MDSD What is MDSD Benefits Mechanics and Tooling Process Issues Some Essential Best Practices ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 35 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 36 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 sentences statement is just wrong you have to update the meta model. (Based on Eric Evans Ubiquitous Language) ingenieurbro fr sof twaretechnologie . w w w.voelter.de

- 37 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems How do I come up with a good metamodel? III Example: owns * Port implements 1 Interface Component Required Port Provided Port provides operations defined by provides access to operations defined by 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. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 38 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 Partitions of these with the same DSL. You will need to come up with separate DSLs that have to be connectable in order to build the complete system GUI Processes S

Y S T E M Persistence ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 39 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems One DSL is not enough II Structure your system into several technical subdomains such as persistence, GUI, deployment. Each subdomain should have its own meta model and specifically, its own suitable DSL. Define a small number of gateway metaclasses, i.e. meta model elements that occur in several meta models to help you join the different aspects together. Technical Subdomain 1 (e.g. Business logic) Metamodel 1

DSL 1 Technical Subdomain 2 (e.g. Persistence) Metamodel 2 ingenieurbro fr sof twaretechnologie DSL 2 . w w w.voelter.de Technical Subdomain 3 (e.g. GUI) Metamodel 3 - 40 - DSL 3 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems One DSL is not enough III - Example Persistence Column Business Objects * Type Table

type * maps * Entity Attribute Mapping represents represents Key Attribute Pages, Forms and Workflow Form Layout target Page * Form Form Layout * Button FormField

Tabular Layout Simple Layout [...] [...] ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 41 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Rich Domain-Specific Platform Define a rich domain-specific application platform consisting of Libraries Frameworks base classes interpreters, etc. Generated Applications The transformations will generate code for this domain-specific application platform.

As a consequence, the transformations become simpler. Domain Platform - Core Domain Classes (Entities, Value Types, ...) - Business Rules - Business Services - ... Technical Platform/ Middleware - Persistence - Transactions - Distribution - Scheduling - Hardware Access - ... Programming Language Operating System DSLs and Frameworks are two sides of the same coin ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 42 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Rich Domain-Specific Platform II - Integration A) Generated code can call non-generated code contained in libraries B) A non-generated framework can call generated parts. b) C) Factories can be used to plug-in the generated building blocks D) Generated classes can also subclass non-generated classes. a) E) The base class can also

contain abstract methods that it calls, they are implemented by the generated subclasses (template method pattern) ingenieurbro fr sof twaretechnologie c) d) generated code . w w w.voelter.de e) non-generated code - 43 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 44 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Testing through Model Verification In many cases it is possible to detect design errors already in the models. This step is called model verification. The most extreme form is to interpret and simulate the whole model; this is however, not simple to achieve. However, it is easily possible to verify design constraints in the model before model transformation or code generation steps are done. So, a DSL definition includes checks (constraints) that determine if a model is correct. Note that those constraints report errors in a language that is on the same abstraction level as the DSL i.e. no low level compiler errors!

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 45 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Testing through Model Verification II - Example Example Metamodel ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 46 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Testing through Model Verification III Example contd Verifications in the metamodel (Implemented) public class ECInterface extends generatorframework.meta.uml.Class { public String CheckConstraints() { Checks.assertEmpty( this, Attribute(), "must not have attributes." ); } // more }

public class Component extends generatorframework.meta.Class { public String CheckConstraints() { Checks.assertEmpty( this, Operation(), "must not have attributes." ); Checks.assertEmpty( this, Generalization(), "must not have superclasses or subclasses." ); Checks.assertEmpty( this, Realization(), "must not implement any interface." ); Checks.assertUniqueNames( this, Port(), "a component's ports must have unique names." ); } // more } ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 47 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems CONTENTS PART 2: Software Architectural Approach ingenieurbro fr sof twaretechnologie . w w w.voelter.de

- 48 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 49 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate!

Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 50 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems The Problem I think the craft of software architecture in current industrial practice is not what it should be. As a consequence, software development is too complicated too expensive hard to test has to change too much if technology changes Specifically, Software architecture is too much technology driven. It is to be a slave to hypes and buzzwords Standards are used in too eagerly

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 51 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Problem: Technology-Driven You hear statements such as we have a web-service architecture, EJB Architectures, Thin Client Architecture. Such a this statement is stupid because it describes only one aspect of the overall system, And focuses on the implementation technology for that aspect. An early commitment to a specific technology usually results in blindness for the concepts a too tight binding to the particular technology. a complicated programming model, bad testability and no flexibility to change the technology, as QoS requirements evolve. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 52 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Problem: Hype and Buzzwords It is good practice to characterize an architecture as implementing a certain architectural style or pattern. But some of the buzzwords used today are not even clearly defined. A service oriented architecture is a classic. Nobody knows what this really is, and how it is different from well-designed componentbased systems. And there are many misunderstandings. People say SOA, and others understand web service A hype-based architecture often leads to too early (and wrong) technology decisions see previous slide! ingenieurbro fr sof twaretechnologie . w w w.voelter.de

- 53 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Problem: Industry Standards Standard definition, good old times. Standard definition, today: try a couple of alternatives; see which one is best; set up a committee that defines the standard the standard is usually close to the solution that worked best. Standards are often defined by a group of (future) vendors. Either they already have tools, which the standard must consider or there is no practical previous experience and the standard is defined from scratch. Standards are often not usable because there was no previous experience, or they are overly complicated because it must satisfy all the vendors. Thus, if you use standards for too many aspects of your system, your system will be complicated! ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 54 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Problem: Architecture Degradation It is one thing to define a good architecture (assuming we know what good means for a project) It is, however, much more complicated to make sure the architecture is lived in the project. Communication Competence Ignorance The goal: We (the team, architects, dictator) want to make architectural decisions when we see the need to decide Then we want to ensure that everybody respects and follows the decision until we find the decision has to be revised which is when we change it but then, again, everybody has to follow the new decision ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 55 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Problem: Politics I would be the first Idcompany rather one in the the blue to useprefer web service Database over standards the red one. Die Gerd Show / Elmar Brandt ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 56 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Phase 1: Elaborate!

This section outlines best practices and approaches which I think are important and applicable for all kinds of projects you don't want to go without these. This first elaboration phase should be handled by a small team, before the architecture is rolled out to the team as a whole. We want to build an enterprise system that contains various subsystems such as customer management, billing and catalogs. In addition to managing the data using a database, forms and the like, we also have to manage the associated long-running business processes. We will look at how we can attack this problem below. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 57 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate!

Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 58 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology-Independent Architecture Context: You have to define a software architecture for a non-trivial system Problem: How do you define a software architecture that is well-defined, long-lived and feasible for use in practice? The architecture has to be reasonable simply and explainable on a beer mat. Forces Architectural concepts must be communicated to

stakeholders and developers Implementation of functional requirements should be as efficient as possible. The architecture must survive a long time, longer than the typical hype or technology cycles The architecture might have to evolve with respect to QoS levels such as performance, resource consumption or scalability. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 59 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology-Independent Architecture II Solution: Define the archtitectural concepts independent of specific technologies and implementation strategies. Clearly define concepts, constraints and relationships of the architectural building blocks a glossary or an ARCHITECTURAL METAMODEL can help here. Define a TECHNOLOGY MAPPING in a later phase to map the the artefacts defined here to a particular implementation platform. Use the well-known architectural styles and patterns here. Typically these are best practices for architecting certain kinds of systems independent of a particular technology. They provide a reasonable starting point for defining (aspects of) your systems's architecture.

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 60 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology-Independent Architecture III We decide that our system will be built from components. Each component can provide a number of interfaces. It can also use a number of interfaces (provided by other components). Communication is synchronous, Communication is also restricted to be local We design components to be stateless. In addition to components, we also explicitly support business processes. These are modelled as a state machine. Components can trigger the state machine by supplying events to them. Other components can be triggered by the state machine, resulting in the invocation of certain operations. Communication to/from processes is asynchronous, remote communication is supported. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 61 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology-Independent Architecture IV Rationale and Consequences: You can focus more on the structure, responsibilities and collaborations among the parts of your systems. Implementation of functionality becomes more efficient. And you don't have to educate all developers with all the details of the various technologies that you'll eventually use. So, how much technology is in a technology- independent architecture? All technologies or approaches that provide additional expressive concepts are useful in a TECHNOLOGYINDEPENDENT ARCHITECTURE. AOP is such a candidate. The notion of components is also such a concept. Message queues, pipes and filters and in general, architectural patterns are also useful. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 62 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology-Independent Architecture V

Rationale and Consequences contd: When documenting and communicating your TECHNOLOGY-INDEPENDENT ARCHITECTURE models are useful. Simple box and line diagrams, layer diagrams, sequence, state or activity charts can help to describe what the architecture is about. They are used for illustrative purposes, to help reason about the system, or to communicate the architecture. For this very reason, they are often drawn on beer mats, flip charts or with the help of Visio or Powerpoint. While these are not formal, you should still make sure that you define what a particular visual element means intuitively boxes and lines with no defined meaning are not very useful, even for non-formal diagrams. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 63 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model

Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 64 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Programming Model Context: You have defined a TECHNOLOGY INDEPENDENT ARCHITECTURE. Problem: The architecture is a consequence of non-functional requirements

and the basic functional application structure, which might make the architecture non-trivial and hard to comprehend for developers. How can you make the architecture accessible to (large numbers of) developers? Forces You want to make sure the architecture is used correctly to make sure its benefits can actually materialize. You have developers of different qualifications in the project team. All of them have to work with the architecture. You want to be able to review application code easily and effectively. Your applications must remain testable. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 65 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Programming Model II Solution: Define a simple and consistent programming model. A programming model describes how an architecture is used from a developers perspective. It is the

architecture API. The programming model must be optimized for typical tasks, but allow for more advanced things if necessary. Note that a main constituents of a programming model is a How-To Guide that walks developers through the process of building an application. The programming model uses a simple IOC approach la Spring to define component dependencies on an interface level. An external XML file takes care of the configuration of the instances. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 66 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Programming Model III The following piece of code shows the implementation of a simple example component. Note how we use Java 5 annotations public @component class ExampleComponent implements HelloWorld { // provides HelloWorld private IConsole console; public @resource void setConsole( IConsole c ) { this.console = c; // setter for console

} // component public void sayHello( String s ) { console.write( s ); } } Processes engines are components like any other. For triggers, they provide an interface w/ void operations They also define interfaces with the actions that those components can implement that want to be notified of state changes. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 67 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Programming Model IV Process Component Implementation Example public @process class SomeProcess implements ISomeProcessTrigger { private IHelloWorld resource; public @resource void setResource( IHelloWorld w ) { this.resource = w; } public @trigger void T1( int procID ) { SomeProcessInstance i = loadProcess( procID ); if ( guardG1() ) { // advance to another state } }

public @trigger void T2( int procID ) { SomeProcessInstance i = loadProcess( procID ); // resource.sayHello( "hello" ); } } ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 68 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Programming Model V Rationale and Consequences: The most important guideline when defining a programming model is usability and understandability for the developer. Frameworks, libraries, and domain-specific languages are useful Platform might have consequences for the programming model. For example, if you want to be able to deploy something as an enterprise bean, you should not create objects yourself.

Therefore: Always develop against interfaces, not implementations Never create objects yourself, always use factories Use factories to access resources (such as database connections) Stateless design is a good idea in enterprise systems Separate concerns: make sure a particular artifact does one thing, not five. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 69 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel

Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 70 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology Mapping Context: You have defined a TECHNOLOGY INDEPENDENT ARCHITECTURE and a PROGRAMMING MODEL. Problem: Your software has to deliver certain QoS levels. Implementing QoS as part of the project is costly. You might not even have the appropriate skills on the team. Also, your system might have to run with different levels of QoS, depending on the deployment scenario. Forces You don't want to implement QoS stuff yourself. You want to keep the conceptual discussions, as well as the PROGRAMMING MODEL free from technical issues. You might want to run the system with various levels of QoS, with minimal cost for each. ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 71 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology Mapping II Solution: Map the TECHNOLOGY-INDEPENDENT ARCHITECTURE to a specific platform that provides the requires QoS. Make the mapping to the technology explicit. Define rules how the conceptual structure of your system (the metamodel) can be mapped to the technology at hand. Define those rules clearly to make them amenable for GLUE CODE GENERATION. Decide about standards usage here, not earlier. But keep in mind: First solve the problem. Then look for a standard. Not vice versa. Use technology-specific Design Patterns here. Use them as the basis for the TECHNOLOGY MAPPING. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 72 - 2 0 0 4 M a rk u s V l t e r

Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology Mapping III For the remote communication between business processes we will use web services. From the interfaces such as IHelloWorld, we generate a WSDL file, and the necessary endpoint implementation. We use on of the many available web service frameworks. Spring will be used as long a no advanced load balancing and transaction policies are required. Once this becomes necessary, we will use Stateless Session EJBs. The necessary code to wrap our components inside beans is easy to write. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 73 - 2 0 0 4 M a rk u s V l t e r

Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology Mapping IV Persistence for the process instances like any other persistent data is managed using Hibernate. To make this possible, we create a data class for each process. Since this is a normal value object, using Hibernate to make it persistent is straight forward ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 74 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Technology Mapping V Rationale and Consequences: The question is, which technology do you chose? In general, this is determines by the QoS requirements you have to fulfill. Platforms are good at handling technical concerns such as transactions, distribution, threading, load-balancing, failover or persistence.

You don't want to implement these yourself. So, always use the platform that provides the services you need, in the QoS level you are required to deliver. Often this is deployment specific! ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 75 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de

- 76 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Mock Platform Context: You have a nice PROGRAMMING MODEL in place. Problem: Developers have to be able to run (parts of) the system locally, at least to run unit tests. How can you make sure developers can run "their stuff" locally without caring about the TECHNOLOGY MAPPING and its potentially non-trivial consequences for debugging and test setup? Forces Developers have to run their code as early as possible You want to minimize dependencies on other project members, specifically those caring about the TECHNOLOGY MAPPING. You have to make sure developers can efficiently run unit tests. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 77 - 2 0 0 4 M a rk u s V l t e r

Model-Driven Development of Distributed, Component-Based Systems PATTERN: Mock Platform II Solution: Define the simplest TECHNOLOGY MAPPING that could possibly work. Provide a framework that mocks or stubs the architecture as far as possible. Make sure developers can test their application code without caring about QoS and technical infrastructure. Since we are already using a PROGRAMMING MODEL that resembles Spring, we use the Spring container to run the application components locally. Stubbing out parts is easy based on Springs XML configuration file. Since persistence is something that Hibernate takes care of for us, the MOCK PLATFORM simply ignores the persistence aspect. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 78 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

PATTERN: Mock Platform III Rationale and Consequences: This is essential for unit testing! Testing one's business logic is simply if you have your system well modularized. If you stick to the guidelines given in the PROGRAMMING MODEL pattern (interfaces, factories, separation of concerns) it is easy to mock technical infrastructure and other artifacts developed by other people. Note that it's essential that you have a clearly defined programming model, otherwise you TECHNOLOGY MAPPING will not work reliably. Note that the tests you run on the MOCK PLATFORM will not find QoS problems QoS is provided by the execution platform. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 79 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate!

Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 80 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Vertical Prototype Context: You have a TECHNOLOGY INDEPENDENT ARCHITECTURE, a PROGRAMMING MODEL as well as a TECHNOLOGY MAPPING. The first implementations of functionality are available and tested using the MOCK PLATFORM. Problem: QoS depends on the technology platform, you selected only recently in the TECHNOLOGY MAPPING. How do you make sure you dont run into dead-ends?

Forces You want to keep your architecture as free of technology specific stuff as possible. However, you want to be sure that you can address all the non-functional requirements. You want to make sure you dont invest into unworkable technology mappings ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 81 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Vertical Prototype II Solution: Make sure you test the non-functional requirements! Build a prototype application that uses all of the above and implements it only for a very small subset of the functional requirements. This specifically includes performance and load tests. Work on performance improvements here, not earlier. It is bad practice to optimize design for performance from the beginning, since this often destroys good architectural practice. In certain domains, there are patterns to realize

certain QoS properties (such as stateless design for large-scale business systems). You shouldn't ignore these intentionally at the beginning. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 82 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Vertical Prototype III The vertical prototype includes parts of the customer and billing systems. For creating an invoice, the billing system uses normal interfaces to query the customer subsystem for customer details. The invoicing process is based on a long-running process. A scalability test was executed and resulted in two problems: For short running processes, the repeated loading and saving of persistent process state had become a problem. A caching layer was added. Second, web-service based communication with process components was a problem. Communication was changed to CORBA for remote cases that were inside the company ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 83 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 84 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Phase 2: Iterate!

Now that you have the basic mechanisms in place you should make sure that they actually work for your project. Therefore, iterate over the previous steps until they are reasonable stable and useful. Spring was intended for the production environment. New requirements (versioning!) have made this infeasible. Spring does not support two important features: Dynamic installation/de-installation of components, and isolations of components from each other(classloaders). Eclipse has been chosen as the new execution framework. The PROGRAMMING MODEL did not change; the TECHNOLOGY MAPPING, however, had to be adapted. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 85 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems CONTENTS The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping

Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 86 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Phase 3: Automate! The steps outlined above are useful in any kind of project. In case your project is really large (i.e. you have a large number of developers), or in case your TECHNOLOGY MAPPING or the PROGRAMMING MODEL is too tedious to use, you should consider automating the development. The next set of patterns describes how. ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 87 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 88 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Architecture Metamodel

Context: You have a TECHNOLOGY-INDEPENDENT ARCHITECTURE. You want to automate various tasks of the software development processes. Problem: To automate, you have to codify the rules of the TECHNOLOGY MAPPING Thus, you have to be very clear and precise about the artifacts defined in your TECHNOLOGY-INDEPENENT ARCHITECTURE. Forces Automation cannot work if you can't formalize translation rules. An architecture based on prose text is not formal enough. You want to be able to check models for architectural consistency. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 89 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Architecture Metamodel II Solution: Define a formal architecture metamodel. An architecture metamodel formally defines the concepts

of the TECHNOLOGY-INDEPENDENT ARCHITECTURE. Ideally this metamodel is also useful in the transformers/ generators that are used to automate development. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 90 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Architecture Metamodel III if a component B is a new version of a component A, then B has to have the same interfaces, additional provided interfaces, fewer required interfaces or new version of interfaces of A a new version of an interface has to have the same return type and the same parameters - or parameters with subtypes. newVersionOf 0..n 1 providedInterface

0..n 0..n Component Operation Interface 1..n requiredInterface 0..n 0..n 0..n returnType 1 newVersionOf Parameter Container Characteristic type 0..n Type Process Component

Container Service 0..n PrimitiveType ComplexType State Machine State 1..n to 0..n from 0..n Transition 0..1 ingenieurbro fr sof twaretechnologie . w w w.voelter.de Trigger Operation - 91 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Architecture Metamodel IV Rationale and Consequences: Formalization is a

double-edged sword. While it has some obvious benefits, it also requires a lot more work than informal models. The only way to justify the extra effort is if the metamodel is really used by tools in the development process, such as as part of the code generation in DSL-BASED PROGRAMMING MODELS and ARCHITECTURE-BASED MODEL VERIFICATION ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 92 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach S The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation

Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 93 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Glue Code Generation Context: You have a TECHNOLOGY INDEPENDENT ARCHITECTURE, as well as a working TECHNOLOGY MAPPING. Problem: The TECHNOLOGY MAPPING if sufficiently stable is typically repetitive and thus tedious and error prone to implement. Often information that is already defined in the artifacts of the PROGRAMMING MODEL have to be repeated in the TECHNOLOGY MAPPING code (method signatures are typical examples). Forces A repetitive, standardized technology mapping is good since it is a sign of a well though-out architecture Repetitive implementations always tend to lead to errors and frustration. ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 94 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Glue Code Generation II Context: Based on the specifications of the TECHNOLOGY MAPPING, use code generation to generate a glue code layer, and other adaptation artifacts such as descriptors, configuration files, etc. To make that feasible you might have to formalize your TECHNOLOGY INDEPENDENT ARCHITECTURE into an ARCHITECTURAL METAMODEL. In order to be able to get access to the necessary information for code generation, you might have to use a DSL-BASED PROGRAMMING MODEL. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 95 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

PATTERN: Glue Code Generation III Our scenario has several useful locations for glue code generation. We generate the Hibernate mapping files We generate the web service and CORBA adapters based on the interfaces and data types that are used for communication. The generator uses reflection to obtain the necessary type information. Finally, we generate the process interfaces from the state machine implementations. In the programming model, we use Java 5 annotations to mark up those aspects that cannot be derived by using reflection alone. Annotations can help a code generator to "know what to generate" without making the programming model overly ugly. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 96 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Glue Code Generation IV Rationale and Consequences: Build and test

automation is an established best practice in current software development. The natural next step is to automate programming at least those issues that are repetitive and governed by clearly defined rules. Generating these artifacts has several advantages. It's simply more efficient. The requirement to "implement" the TECHNOLOGY MAPPING in the form of a generator helps refine the TECHNOLOGY MAPPING rules. Code quality will typically improve, since a code generator doesn't make any accidental errors Developers are relieved from having to implement tedious glue code over and over again ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 97 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach S The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype

PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 98 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model Context: You have a PROGRAMMING MODEL defined. Problem: Your PROGRAMMING MODEL is still too complicated, with a lot of domain-specific algorithms implemented over and over again. It is hard for your domain experts to use the PROGRAMMING MODEL in their everyday work. And the GLUE CODE GENERATION needs information about the program structure that is hard or derive from the code Forces The code-based PROGRAMMING MODEL cant use domain-specific notations

Parsing code in order to gain information on what kind of glue code to generate is tedious, and the code also does not have the necessary semantic richness. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 99 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model II Solution: Define Domain-Specific Languages that developers use to describe application structure and behavior in a brief and concise manner. Generate the lower-level implementation code from these models. Generate a skeleton against which developers can code those aspects that cannot be completely generated from the models. We use DSLs for components, interfaces and dependencies. Describing this aspect in a model has two benefits: First, the GLUE CODE GENERATION can use a more semantically rich model as its input, and the model allows for very powerful MODEL-BASED ARCHITECTURE VALIDATION (see below). ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 100 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model III IConole <> HelloWorld {persistent} IHelloWorld <> StdOutConsole 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. <> <> SomeInterface <>

<> SomeInterface.java <> <> Some Component Base.java SomeComponent ingenieurbro fr sof twaretechnologie <> . w w w.voelter.de SomeComponent.java - 101 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model IV A second place is the processes. State machines can be drawn using UML state machines.

To integrate processes with other components, these can easily be rendered by blackboxing the state machine with a component and using it in component diagrams. The component is derived from the state chart automatically. ingenieurbro fr sof twaretechnologie sd SomeProcess s1 [valid] T1 [invalid] T1 s3 s2 T2/someAction cd SomeProcessComponent . w w w.voelter.de <> ISomeProcessTrigger <> SomeProcessComponent isValid()

isInvalid() triggerT1() triggerT2() <> ISomeProcessResource someAction() - 102 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model V Type Model <> <> AddressManager Person person name: String firstName: String 0..n addressStore <> <> AddressStore

Address <> CustomerManager addOrUpdateContact( p: Person) : void addAddress( p: Person, a: Address) : void getAddresses( p: Person ) : Address[] street: String zip: String City: String Composition Model System Model

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 103 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model VI <> SomeEntity <> <> <> SomeEntityDAO <> SomeEntityDAO.java <>

<> <> <> SomeEntityDAOBase .java SomeEntityDAO <> <> <> SomeEntity.java ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 104 - <> SomeEntityDAO.java 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model VII <> AProcess

1 <> sm AProcess s1 * <> AProcessInterface <> s2 <> AProcessData attributes... s3 <> <> operations... <> <> <> AProcessBase .java

<> AProcessProcBase.java AProcessData.java 1 data guard operations... (abstract) action methods... (abstract) <> AProcess.java ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 105 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model VIII Rationale and Consequences: Defining useful DSLs, providing a suitable editor, and implementing an generator creates efficient code is a non-trivial task. So this step only makes sense if the generator is reused often, the "normal" PROGRAMMING MODEL is so intricate, that a DSL boosts productivity,

or if you want to do complex MODEL-BASED ARCHITECTURE VALIDATION. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 106 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: DSL-based Programming Model IX Rationale and Consequences contd: The deeper your understanding of the domain becomes, the more expressive your DSL can become (and the more powerful your generators have to be). Input Models In order to manage the complexity, you should build cascades of DSL/Generator pairs. The lowest layer is basically the GLUE CODE GENERATOR; higher layers provide more and more powerful DSL-BASED PROGRAMMING MODELS. ingenieurbro fr sof twaretechnologie

... ... ... ... ... ... MDSDInfrastructure Output Model Model for Domain 1 Model for Domain 2 DSL-based prog. model 1 DSL-based prog. model 2 . w w w.voelter.de Programming Model Artifacts Glue Code Generation Code for Target Platform - 107 - 2 0 0 4 M a rk u s V l t e r

Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 108 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Model-Based Architecture Validation Context: You have all the things from above in place and you roll out your architecture to a larger number of developers. Problem: You have to make sure that the PROGRAMMING

MODEL is used in the intended way. Different people might have different qualifications. Using the programming model correctly is also crucial for the architecture to deliver it QoS promises. Forces: Checking a system for architectural compliance is critical! Using only manual reviews does not scale Since a lot technical complexity is taken away from developers (it is in the generated) these issues need not be checked. Checking the use of the PROGRAMMING MODEL on source level is complicated ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 109 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Model-Based Architecture Validation II Solution: Make sure critical architectural things are either specified as part of the DSL-BASED PROGRAMMING MODEL, or the developers are restricted in what they can do be the generated skeleton, into which they add their 3GL code.

Architectural verifications can then be done on model level, which is quite simple: it can be specified against the constraints defined in the ARCHITECTURE METAMODEL. It is checked that for triggers in processes there is a component that calls the trigger. Dependency management: It is easy to detect circular dependencies among components. Components are assigned to layers (app, service, base) and dependencies are only allowed in certain directions. The component signature generated from the model prevents developers from creating dependencies to components that are not described in the model . 2 0 0 4 M a rk u s V l t e r - 110 ingenieurbro fr sof twaretechnologie w w w.voelter.de Model-Driven Development of Distributed, Component-Based Systems PATTERN: Model-Based Architecture Validation III Another really important aspect in our example system is

evolution of interfaces: <> SomeCompV1 <> SomeInterface soSomething(int, ValueObject) <> <> ValueObject <> AnotherInterface <> SomeCompV2 <> <> <> <> SomeInterfaceV3 <> SomeCompV3 <> ValueObjectV3 soSomething(int, ValueObjectV2) anAdditionalOperation() ingenieurbro fr sof twaretechnologie

. w w w.voelter.de - 111 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Model-Based Architecture Validation IV Rationale and Consequences: In larger projects, you have to be able to verify the properties of your system (from an architectural point of view) via automated checks. Some of them can be done on code level (using metrics, etc.). However, if you have the system's critical aspects described in models, you have much more powerful verification and validation tools at hand. It is essential that you can use the ARCHITECTURE METAMODEL to verify models/specifications. Good tools for model-driven software development

(such as the openArchitectureWare generator) can read (architecture) metamodels and use them to validate input models. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 112 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems PATTERN: Model-Based Architecture Validation V Rationale and Consequences contd: This way, a metamodel is not just documentation, it is an artifact used by development tools. The following illustration shows how this tool works. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 113 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Part 2, Software Architectural Approach The Problem

PHASE 1: Elaborate! Technology-Independent Architecture Programming Model Technology Mapping Mock Platform Vertical Prototype PHASE 2: Iterate! PHASE 3: Automate! Architecture Metamodel Glue Code Generation DSL-based Programming Model Model-based Architecture Validation Summary ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 114 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Summary The approach to software architecture described in this papers is a tried and trusted one. However, it is often not used Why? People think it is too complicated to use. And it's not "standard". To some extend this is true. Defining your own PROGRAMMING MODEL certainly means, that not all

developers will learn each and every J2EE detail. While this might be considered a problem by some developers (for their CVs), it is certainly a good thing wrt. productivity. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 115 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems CONTENTS PART 3: Components Reference Metamodel ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 116 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels

Component Implementation Aspect Models Variants Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 117 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels Component Implementation Aspect Models Variants Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 118 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Why?

Based on my experience, the core asset in model-driven component based development is not a generator that generated some J2EE code, rather, the right selection of models and viewpoints is essential. So these slides contain exactly this: a reference metamodel that has been used in many, many different projects. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 119 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels Component Implementation Aspect Models Variants Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 120 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Three Basic Viewpoints Type Model: Components, Interfaces, Data Types Composition Model: Instances, Wirings System Model: Nodes, Channels, Deployments Type Model <> <> AddressManager person Person name: String firstName: String 0..n addressStore <> <> AddressStore Address <> CustomerManager

addOrUpdateContact( p: Person) : void addAddress( p: Person, a: Address) : void getAddresses( p: Person ) : Address[] street: String zip: String City: String Composition Model System Model

ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 121 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Three Basic Viewpoints Generated Stuff Base classes for component implementation Build-Scripts Descriptors Remoting Infrastructure Persistence ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 122 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Type Metamodel * Component

providedInterface name Interface name * required Interface Component Interface Requirement Operation name * Parameter name target returnType Type name name exception type

* Exception ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 123 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Type Metamodel II (Data) Type name Complex Type Entity Reference name isBidirectional targetMultiplicity sourceMultiplicity * attribute Attribute type name Primitive

Type * ref src Entity target ingenieurbro fr sof twaretechnologie Data Transfer Object . w w w.voelter.de - 124 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Composition Metamodel * Component providedInterface name name *

type Interface required Interface Component Interface Requirement target name Component Stuff Composition Stuff cireq Configuration name * instance Component Instance Wire * name name

target context ComponentInstance inv: foreach of types ComponentInterfaceRequirements there must be a Wire of the same name ingenieurbro fr sof twaretechnologie . w w w.voelter.de context Wire inv: the type of the target instance must provide the Interface pointed to by the Wires cireqs target - 125 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems System Metamodel Configuration Component Instance * instance name

* Wire name name Composition Stuff * System Stuff System name * Node name ingenieurbro fr sof twaretechnologie Container * name . w w w.voelter.de - 126 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 Composition Model Composition Model System Model(s) Composition Model Composition Model(s) ingenieurbro fr sof twaretechnologie . w w w.voelter.de Type/Data Model - 127 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels Component Implementation Aspect Models Variants

Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 128 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 <> <> SomeInterface.java SomeInterface <> <> <> SomeComponent <>

Some Component Base.java <> SomeComponent.java However, for special kinds of components (component kind will be defined later) can use different implementation strategies -> Cascading! ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 129 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Component Implementation II Remember the example of the process components from before: sm AProcess <> 1 AProcess

s1 <> AProcessData s2 * attributes... s3 <> <> AProcessInterface <> operations... <> Various other implementation stragies can be used, such as: Rule-Engines Procedural DSLs or action semantics <> <> <>

AProcessBase .java AProcessProcBase.jav a AProcessData.java 1 data guard operations... (abstract) action methods... (abstract) <> AProcess.java Note that, here, interpreters can often be used sensibly instead of generating code! ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 130 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels Component Implementation Aspect Models

Variants Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 131 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems 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 ingenieurbro fr sof twaretechnologie . w w w.voelter.de A spect

S y s te m M odel (s ) 4 A spect - 132 - 1 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels Component Implementation Aspect Models Variants Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 133 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

Separate Interfaces You might not need separate Interfaces Operations could be annotated directly to components Dependencies would be to components, not to interfaces Relationships between interfaces are often needed, if you require this interface, you also have to provide that one ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 134 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Component Types Often different kinds of Components are needed. To manage dependencies, And to define implementation strategies context ApplicationComponent inv: No provided interfaces are allowed Component name Service Component DAO Component

Domain Component <> Application Component <> Legcy Adapter Component <> GUI Component Facade Component <> <> <> ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 135 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

Component Layering Alternatively you can simply annotate each component with a layer * Component name layer: LayerType providedInterface * required Interface Component Interface Requirement Interface name layer: LayerType target name ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 136 -

<> LayerType domain gui facade ... 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Component Signatures You might need to provide several implementations (i.e. components) for the same signature (i.e. provided/required interfaces). So you need to separate implementation from signature * Component Signature name implemented Signature providedInterface Interface name Component Interface Requirement *

required Interface target name required Interface Component Implementation name ingenieurbro fr sof twaretechnologie ConfigParam * default . w w w.voelter.de - 137 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Hierarchical Components Component type name

* may have additional properties that define how interface is used Port Interface p2 name name port HierarchicalComponent RequiredPort ProvidedPort * ComponentInstance name * PortInstance name p1 context ConnectingWire inv: One of the port instancess ports must be a provided port, the other a required port. Interfaces of the two ports must be the same

p1 p2 Connecting Wire * Delegating Wire Wire name ingenieurbro fr sof twaretechnologie context DelegatingWire inv: p2's owning component must be the same as p1's instances owning hierarchical component . w w w.voelter.de - 138 - context DelegatingWire inv: If p1's port is a ProvidedPort, then p2 must also be a ProvidedPort. Similar

for RequiredPorts. Interface of p1's Port must be same as p2's interface 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Hierarchical Components II This allows an infinite nesting of component structures It requires the concept of ports Note that the clear boundaries between type and composition models are blurted (which makes this approach a bit more advanced!) Example: HierarchicalComponentA Component InstanceB ComponentD I1 Component InstanceC bPort aPort I1 ingenieurbro fr sof twaretechnologie .

w w w.voelter.de - 139 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Configuration Parameters Parameters allow for dynamic configuration of components. There is a wide variety of potential value definition scopes * ConfigParam Component name Attribute default name Component Stuff Composition Stuff type Configuration name * instance

* Component Instance ConfigParam Value name context ComponentInstance inv: foreach of types ConfigParams there must be a ConfigParamValue ingenieurbro fr sof twaretechnologie StaticConfig ParamValue value . w w w.voelter.de Dynamic ConfigParam Value - 140 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Behaviour Different (types of) Components typically have different lifecycles

The threading model is typically different, too. Also, some components might be stateless, while others are stateful (with persistent state, or not) Service Component <> ThreadingType <> LifecycleType SingleThread ThreadSafe lifecycle: LifecycleType threading: ThreadingType Simple WithInit Active 0..1 Complex Type Component State isPersistent ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 141 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Asynchronous Communication Some components might need asynchronous communication with others Note that this has to be specified in the type model since it affects the API! * Component providedInterface name Interface <> CommType name * required Interface Component Interface Requirement

sync async-oneway async-syncWS async-poll async-callback target name comm: CommType context ComponentInterfaceRequirement inv: if oneway or syncWithServer is used, all operations in the target interface must be void, and not throw any exceptions! ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 142 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Events Events are a way to signal information from a component to another, asynchronously. Sometimes it is useful to allow for violations of the (otherwise rigidly enforced) dependency rules Complex Type

Component name * * attribute Attribute name Event producer * consumer ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 143 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Subsystems and Business Components If the number of components grows, additional means to organize them are required. The internal structure of subsystems or business components can be defined by enforcing certain policies

wrt. Component types For example, each business component must have exactly one facade context BusinessComponent inv: Must contain exactly one FacadeComponent * Entity * Interface * Service Component Subsystem Business Component ingenieurbro fr sof twaretechnologie Facade Component . w w w.voelter.de GUI Component

- 144 - ... 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Data More elaborate data structures are often required Typical example is based on entities and dependent types DAOComponents are used to manage the entities and their associated dependent types Ownership and Scope of data types is essential Indirect dependency management Complex packaging Type Component * Entity usedEntity name Dependent Type Value Type *

baseType DAO Component ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 145 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Wiring Optional wires might be useful Dynamic Wires dont specify the target instance, but rather a set of properties based on which at runtime, the target can be found Important for dynamic systems, e.g. P2P a) b) Component Instance Wire * name

name Component Instance * Wire name query name target backupTarget ingenieurbro fr sof twaretechnologie Interface . w w w.voelter.de - 146 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Container Types and Networks This allows for more specific description of hardware, Networks and network types describe means to communicate Whereas container types are important to distinguish various execution environments (server, local, ) Configuration

Component Instance * instance name Wire * * <> NodeType name ... name Composition Stuff * System Stuff System name * hosts Node

<> ContainerType Container * name name type: NodeType ... type: ContainerType node1 node2 * * <> NetworkType Network ... name type: NetworkType ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 147 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Versioning Capturing versioning and type evolution information explicitly in the model allows for definitive statements about component compatibility and system evolution. newVersionOf 0..1 * 0..1 * Component providedInterface name Interface name * 0..1 * required

Interface Component Interface Requirement * target name newImplementationOf ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 148 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems C O N T E N T S: Components Reference Metamodel Why? Three basic Viewpoints and their Metamodels Component Implementation Aspect Models Variants Code Generation revisited ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 149 -

2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Code Generation Revisited The discussions previously have only discussed how we want to describe our system we did not talk about how these things are implemented. This mights sound odd. However, coping with complexity starts with finding solid means to describe what we want to developer a good description is thus essential! Only then we want to use good platforms, that provide many of the (runtime) services we require, this can include J2EE CORBA Spring Osek ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 150 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems

Code Generation Revisited II In case we have to build the infrastructure ourselves, e.g. since, for the respective target environment, no infrastructure is available (embedded, e.g.), we have a wide range of patterns to select from: POSA 1, 2 and 3 Server Component Patterns Remoting Patterns Good Luck THE END. Questions? Criticism? ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 151 - 2 0 0 4 M a rk u s V l t e r Model-Driven Development of Distributed, Component-Based Systems Some advertisement For those, who happen to speak (or rather, read) german: Vlter, Stahl: Modellgetriebene Softwareentwicklung Technik, Engineering, Management dPunkt Verlag, 2005

www.mdsd-buch.de For all others: A translation (with Wiley) is under way. ingenieurbro fr sof twaretechnologie . w w w.voelter.de - 152 - 2 0 0 4 M a rk u s V l t e r

Recently Viewed Presentations

  • Chemical Nomenclature - Elgin High School

    Chemical Nomenclature - Elgin High School

    Chemical Bonding Ionic and Metallic Chemistry Elements Some elements never exist by themselves These are called diatomic molecules There are seven of them and they make a seven on the periodic table The Diatomic Molecules These would still be said...
  • Metodologi Penelitian - Yola

    Metodologi Penelitian - Yola

    Arial Garamond Times New Roman Wingdings Comic Sans MS Tahoma Courier New Arial Black Stream Echo Crayons Default Design Clip Equation MS Organization Chart 2.0 METODOLOGI PENELITIAN MODUL - 1 MANUSIA MENCARI KEBENARAN PROSES SEKULARISASI ALAM Berbagai Cara Mencari Kebenaran...
  • Pronunciation 2 - A Collection of TESL resources

    Pronunciation 2 - A Collection of TESL resources

    ♫Beat and Rhythm ♫ I was talking to Brian when I ran into Sue. I was waiting for Jack when I saw Mary Lou. They were cleaning the house when I knocked at the door.
  • Famous Australians - University of New England

    Famous Australians - University of New England

    A very famous hurdler is Sally Pearson. Steve Irwin. Steve Irwin, was known as the crocodile hunter. He protected and cared about the crocodiles but sadly he died from a sting-ray sting. This is a sting-ray. ... Who are these...
  • Interactive Student Notebook What is an Interactive Student

    Interactive Student Notebook What is an Interactive Student

    Frayer Model Foldable. The Diamond 4 Door or "Quilt" 1. Fold the top edge of the paper . so that . it is even with the side edge of . the paper. Fold the remaining flap of . paper even...
  • Business Process Reengineering Concepts

    Business Process Reengineering Concepts

    * A business process may be defined as "a set of logically related tasks performed to achieve a defined business outcome" (Davenport, 1990) OR "activities that takes one or more kinds of input and create an output that is of...
  • Artificial System of Plant Classification

    Artificial System of Plant Classification

    Class determined by Stamen Order by Pistils Problems Controversial Before Linnaeus Naming practices varied Artificial vs. Natural Artificial taxonomy was a system of grouping unrelated plant species by a common criteria (i.e. a flowers sexual organs) Natural classification reflects evolutionary...
  • The Development Assistance Committee of the OECD

    The Development Assistance Committee of the OECD

    Aid to LDCs has risen sharply since 2000 …led by steep rises in aid from the United States …as well as from IDA and the EC But smaller donors give higher shares of their aid to LDCs Nine donor countries...