MDSD Best Practices Markus Völter Note This tutorial

Скачать презентацию MDSD Best Practices Markus Völter Note This tutorial

21e895f6b19421e3a63561940a9aed9f.ppt

Количество слайдов: 72

MDSD Best Practices Markus Völter Note: This tutorial is an ongoing project. Updates of the slides can be found regularly at [email protected] org www. voelter. de/services/mdsd-tutorial. html Please check the site for updates, if you‘re interested. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

About me • • Independent Consultant • Focus on • Software Architecture • Middleware • Model-Driven Software Development Markus Völter [email protected] org www. voelter. de Based out of Heidenheim, Germany . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

CONTENTS • • Intro – What is MDSD Best Practices • Domain Construction & Code Generation • Tool Construction and Selection • Process • Testing • Versioning and Multi-Model/Multi-Site • End. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Model Driven Software Development Overview several target software architecture Metamodel subdomains design expertise Application 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 . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

MDA and Model Driven Software Development Overview several target software architecture MOF Metamodel subdomains design expertise Application PIM, PSM, . . QVT multi-step transform bounded area of knowlege/interest partial composable multiple viewpoint Domain single-step compile Model semantics Ontology no roundtrip interpret precise/ executable Domain Specific Language OCL, Action Semantics UML+ Profiles graphical Metamodel textual . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

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 other‘s 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. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

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 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) . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

MDSD Predjudices • MDSD does not require UML – any kind of modelling language is ok, graphical or textual • Precise and complete models… • … are not the same as „visualized code“ – the abstraction level is higher • … are not the same as analysis models – analysis models are not computational • MDSD does not require – not even recommend – a waterfall. Development of the generative infrastructure is iterative and incremental. • You do not need big and expensive tools – a lot of small and useful open source tools are available. • You don‘t need to generate 100% of the code – it is ok, to also code some aspects in a 3 GL. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Believe in Re-Incarnation • The final, implemented application should be built by a build process that includes re-generation of all generated/transformed parts. • …which includes more than just code – see LEVERAGE THE MODEL • As soon as there is one manual step, or one line of code that needs to be changed after generation, then sooner or later (sooner is the rule) the generator will be abandoned, and the code will become business-as-usual. • Note that this pattern does not receommend to generate as much stuff as possible. • You should use a RICH DOMAIN-SPECIFIC PLATFORM, • And SELECT FROM BUILD, BUY OR OPEN SOURCE . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Separate Generated and Non-Generated Code • • • Keep generated and non-generated code in separate files. • Use suitable design approaches to “join” generated and non-generated code. Interfaces as well as design patterns such as factory, strategy, bridge, or template method are good starting points. Never modify generated code. Design an architecture that clearly defines which artifacts are generated, and which are not. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Separate Generated and Non-Generated Code II • A) Generated code can call non-generated code contained in libraries • B) A non-generated framework can call generated parts. • C) Factories can be used to „plug-in“ the generated building blocks • D) Generated classes can also subclass non-generated classes. • E) The base class can also contain abstract methods that it calls, they are implemented by the generated subclasses (template method pattern). ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Rich Domain-Specific Platform • Define a rich domain-specific application platform consisting of • Libraries • Frameworks • base classes • interpreters, etc. • The transformations will “generate code” for this domain-specific application platform. • As a consequence, the transformations become simpler. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Technical Subdomains • 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 META CLASSES, i. e. meta model elements that occur in several meta models to help you join the different aspects together. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Gateway Metaclasses • Using TECHNICAL SUBDOMAINS results in different meta models as well as different concrete syntax for the different subdomains. • Example: workflow/using activity diagrams, Layout/ textual, XML-like language. • If you want to generate a system from these different specifications, your generator needs a mechanism to get from one model to the other: • you need model elements that are present in the meta models of both TECHNICAL SUBDOMAINS. IGNORING CONCRETE SYNTAX in your generator makes this simpler. • The second thing you need is a common meta model. For example, Java classes to be used as the meta model for all meta models. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Generator-based AOP • Implement the handling of cross-cutting concerns with the help of the generator. • You can either take advantage of the generator’s integral features (e. g. consider that it generates many instances of a meta model element with the help of one transformation/template), or • Weave various “aspect models” in the generator • use the generator to implement proxies, interceptors and other AOP-addressing design patterns in the generated system. • Consider the cross-cutting concern a TECHNICAL SUBDOMAIN and provide a suitable DSL for it. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Generator-based AOP II • Example: . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Produce Nice-Looking Code … whenever possible! • • PRODUCE NICE-LOOKING CODE … WHEREVER POSSIBLE! • Using this pattern helps to gain acceptance for code generation in general. • Examples: • Comments • Use pretty printers/code formatters • Location string („generated from model: : xyz“) When designing your code generation templates, also keep the developer in mind who has to – at least to some extent – work with the generated code, for example • When verifying the generator • Or debugging the generated code . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Descriptive Metaobjects • The generated application often needs information about some model elements at run time to control different aspects of the applicaton plaform. • Use the information available at generation time to codegenerate meta objects that describe the generated artifacts. • Provide a means to associate a generated artifact with its meta object. • You add a get. Meta. Object() operation to the generated artifact. • You can also use a central registry that provides a lookup function Meta. Registry. get. Meta. Object. For(an. Artefact). The implementation for the operations will be generated, too. • Make sure the meta objects have a generic interface that can be accessed by the RICH DOMAIN-SPECIFIC PLATFORM. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Descriptive Metaobjects II • Example: . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Generated Reflection Layer • • You can even go one step further and generate an “interpreter”, a reflection layer that allows you to • “script” the system • build IDEs Since the reflection layer is separate from the core classes, it can be excluded from the „real“ system for (performance reasons) . ingenieurbüro für sof twaretechnologie public interface RClass { // initializer – associates with // base-level object public set. Object( Object o ); // retrieve information about //the object public ROperation[] get. Operations(); public RAttribute[] get. Attributes(); // create new instance public Object new. Instance(); } public interface ROperation { // retrieve information about op public RParameter[] get. Params(); public String get. Return. Type(); // invoke public Object invoke(Object params) } public interface RAttribute { // retrieve information about op public String get. Name(); public String get. Type(); // set / get public Object get(); public void set( Object data ); } w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

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. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Leverage the Model • • The information captured in a model should be leveraged to avoid duplication and to minimize manual tasks. Hence you may generate much more than code: • user guides • help text • test data • build script • content, etc. • Find the right balance between the effort required for automating manual tasks and the effort of repetitively performing manual tasks • Make use of SELECT FROM BUY, BUILD, OR OPEN SOURCE in your assessment. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Select from Buy, Build or Open Source • It is typically not a good idea to re-invent the wheel, even in case the wheel is generated. • Don't be blinded and ignore the potential of well-proven off-the-shelf products and robust Open Source infrastructure that is used by thousands of organizations! • However, do LEVERAGE THE MODEL and don't compromise hard-earned domain knowledge that has gone into your domain-specific frameworks and generators by replacing them with unrefined and blunt off-the shelf tools. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Tools: Overview • Many kinds of tools can be used in the context of model driven development: • UML modelling tools • Metamodelling environments • (XMI) Repositories • Code Generators • Model verifiers • There is also a large amount of tools that are „MDA certified“. These range from completely integrated environments such as Arc. Styler to simple code generators or technology specific generators (e. g. for J 2 EE). . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Tools: Vendor Lock-in • Because a lot of issues are not yet standardized, it is hard to integrate tools. Open issues include: • Some XMI aspects • Specification of model transformation rules • Code generation • . . . • As a consequence, integrated MDD/MDA tooling is currently impossible to achieve without vendor lock-in. • Alternatively, building/integrating your own tooling based on open source can be done, but requires compromises. • Many tools are exemplified in the context of code generation (see other presentation). Build Tools are also important. UML tools (such as Rational XDE) also develop in the direction of supporting MDA. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Tools: Examples • Rational XDE • Andro. MDA • Velocity • XML + XSLT • open. Architecture. Ware • Xdoclet • Arc. Styler • i. UML . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Tools: The Ideal One • MOF Based Metamodelling, including OCL • Usage of thses metamodels for subsequent modeling of M 1 • Metamodel specific repositoriy • GUI adapted to metamodel • Model Validation based on metamodel • Also including OCL • Transformation rules based on user-defined metamodels • Flexible Code Generation • Test support . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Implement the Metamodel • Implement the meta model in some tool that can read a model and check it against the meta model. • This check needs to include everything including declared constraints. • Make sure the model is only transformed if the model has been validated against the meta model. • The meta model implementation is typically part of the transformation engine or code generator since a valid model is a precondition for successful transformation. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Ignore Concrete Syntax • Define transformations based on the source and target meta models. • The transformer uses a three phase approach: • first parse the input model into some in-memory representation of the meta model (typically an object structure), • then transforms the input model to the output model (still as an object structure) • and finally unparse the target model to a concrete syntax . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Transformations as first class citizens • Transformations (and Templates) are central assets in MDSD. You should treat them accordingly. • Transformations should be versioned. • Refactor transformations to keep them current and well organized. • Modularize transformations, e. g. using object-oriented concepts such as encapsulation, polymorphism, inheritance, etc. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Modular, Automated Transforms • In order to more easily reuse parts of a transformation, it is a good idea to modularize a transform. • Note that in contrast to the OMG, we do not recommend looking at, changing or marking the intermediate models. • They are merely a standardized format for exchanging data among the transformations. • Example: Multi-Step transformation from a banking-specific DSL to Java via J 2 EE . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Modular, Automated Transforms II • Example cont’d: Now consider a Call-Center application; only the first step needs to be adapted. • If both should be transformed to. NET, only the backend needs to be exchanged. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Build an IDE • Model-Driven Software Development often includes a wealth of input, intermediate and output artifacts. • Users (application developers) can easily be confused by these many artifacts. • To improve acceptance of the approach, you should consider building an IDE for application developers which • Hides unnecessary intermediate artifacts • Provides editors/support for “programming” with the DSL • Integrates all the validation, generation, build, etc. • Eclipse, for example, is a good toolkit for building these kinds of IDEs. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Two-Stage Build • Separate the generation run into two stages: • the first stage reads some kind of configuration and prepares the actual generator for the core transformation. • The second stage is the execution of the transformer and uses the preparations done in the first stage. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Two-Stage Build II • Example: . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Iterative Dual Track Development • Develop Domain Architecture and at least one application at the same time. • Establish rapid feedback from application developers to domain architecture developers. • Develop both aspects iteratively and incrementally. Use strict timeboxing. • Infrastructure develops iteration n+1 whereas application developers use iteration n. • Introduce new Domain Architecture releases only at the beginning of iterations. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

MDSD Process II • Domain Architecture Development . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Scope Trading • Use a formal scope trading workshop at the beginning of each iteration (for Domain Architecture as well as for application development). • All relevant stakeholders (including end users) need to be represented in the workshop. • Document results and make sure everybody understands and agrees. • Set priorities in the upcoming iteration based on the results of the workshop. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Validate Iterations • Each timebox is concluded with a formal iteration validation workshop to confirm progress • Let an end user that acted as the on-site customer drive the demonstration of implemented features. • Explicitly communicate to the end user and stakeholder community that new requirements can be brought up at any point. • Encourage exploration of "what-if" scenarios— stakeholders may develop a new idea while watching the demonstration • Similarly the architect may want to raise issues that may have escaped the requirements elicitation process and that have been uncovered by the development team. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Extract the Infrastructure • Before starting ITERATIVE DUAL-TRACK DEVELOPMENT, Extract the transformations from manually developed application. • Either, start by developing this prototype conventionally, then build up the MDSD infrastructure based on this running application, • Or extract the code from applications developed in the respective domain before doing MDSD (but only if the quality is sufficiently good!) . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

The Role of Testing in SW Development • In all but very few cases, the correctness of software cannot be verified theoretically or formally. • Thus the only way of verifying a system does what it should do is by testing it extensively. • There are different kinds of things that can be tested: • Ensuring that the software does what the developer wanted it to do • Ensuring that what the developer programmed is actually what the system should do (i. e. what the customer wants) • Ensuring that the system performs and scales adequately • Ensuring that other non-functional properties work as specified (such as transactions, security, . . . ) • Ensuring that the tools and technologies used in the implementation work together well • We will now look at each of these in the context of MDD. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Unit Testing • Ensuring that the code does what the developer wants is called Unit Testing. • Tools such as JUnit provide a framework to implement and repeatedly execute unit tests • They are written by the developer as he develops his code. • Typically, they test functionality, not nun-functional properties • In the context of MDD, unit tests can be generated from models, too • Tests for static properties can be generated directly from the model. • For behavioral aspects, It should be a different model – because if tests are created from the same model as the implementation code, tests will always pass. • Additional Testcases can also be generated from OCL expressions (invariants, as well as pre- and postconditions). • When the code is generated, we can even embed OCL constraint evaluation into the generated code and check these at runtime. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Unit Testing Example • Consider the following model: • This could result in the following code: class Vehicle {. . . public void set. Driver( Person p ) { if (driver. get. Age() < 18 ) throw new Constraint. Violated(); } } • A similar approach could be taken for the invariant in Person. • In case of the invariant, it is easy to automatically create a set of unit tests that check ages like 0, 16, 78, 120, -1, 3. 4 and see if the system behaves accurately. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Requirements Testing • Here we want to make sure that the system does what the customer (or the requirements) say. • We use the same technical approach here as for unit testing. However, here the test cases are written by domain experts and not by the developer. • If models are annotated with OCL constraints, they are significantly more rich that „typical“ requirements. A lot of test cases can be generated from these models. • If we have a suitable, high-level modeling notation (such as a UML profile), the domain expert can even specify test models himself, or with some support by a technical person. • Because of the domain-specific notation, developer/ customer communication about tests is simplified. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Performance and Scalability Testing • This kind of testing basically works by simulating a certain number of clients and then measuring response times and resource consumption. • Running such tests always requires a setup of an environment similar to the production environment. This is typically done manually, although some deployment artifacts can be generated from models. • The simulated clients can often be generated completely. The input is basically • Which operations to call • At which sequence and intervals • In how many parallel threads or processes • And where to store the timing measurements and in which format . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Performance and Scalability Testing Example • A statechart can be used to specify this behaviour: • Note that we do not care about errors and functional testing here. This is done in other test! • This statechart can be code generated into a client. • An additional (textual) specification defines how many parallel threads and processes we have. • Tools for this task are also available outside MDD. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Testing non-functional properties • In contrast to functional unit tests, these kinds of tests cannot be run in a simplified testing environment, because non-functional problems only show up under realistic circumstances (many parallel users, database crashes, . . . ) • Many kinds of tests can only be done manually, for example trying to „hack“ into a system to test its security. • Some tests can be automated based on constraints, however. There is an example on the next page. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Testing non-functional properties: Example • Consider the following model: • While the constraint may look like a purely functional constraint, it is actually a non-functional constraint with regards to transactions in a real-world scenario. • It can be verified in tests that run against the deployed system while power outages, database crashes, etc. are simulated. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Tools and Technology Testing • Tools in this context are for example, Databases, Middleware, Application Servers, etc. • Tools and Technology testing deals with questions such as whether the system delivers the expected performance and reliability when deployed using the tool. • Many of these things can be tested automatically using unit or performance testing. • There is an important additional aspect, though: Many problems with tools and technology arise from developers using the tool in a way different than anticipated. • These kinds of errors are minimized if the code that uses the tools is generated. The generator – once correctly implemented – always uses the tools in the same, correct way. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Additional Tests: 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, although there are „UML VMs“. • However, it is easily possible to verify design constraints in the model before model transformation or code generation steps are done. Example: generate(TENA_class) { [. . . ] foreach Config. Param p { if p. type != „string“ { error „only strings allowed“+ „for configparams“ } else { generate(p) } } }. ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Model Verification Example • Again the metamodel introduced before: . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Additional Tests: Model Verification II • This template is used to generate IDL code from the model: «DEFINE Root FOR TENAInterface» «IF is. In. Package» package «Package. Name» { «ENDIF» interface «Name» «IF has. Super. Class» : «FOREACH Generalization. Super. Class AS sc EXPAND USING SEPARATOR ", "» «sc. Name» «ENDFOREACH» «ENDIF» { «EXPAND Operation: : Declaration FOREACH Operation USING SEPARATOR "n"» }; // generated code «IF is. In. Package» }; «ENDIF» «ENDDEFINE» . ingenieurbüro für sof twaretechnologie package omtest { interface Controllable { TENA_string initialize( TENA_string start( ); TENA_string stop( ); }; }; w w w. vo ); © 2 0 0 4 M a rk u s V ö l t e r

Additional Tests: Model Verification III • Metaclass used in the generator, this has model verification code in it: public class TENAInterface éxtends Class { [. . . } public String Check. Constraints() throws Design. Exception { Checks. ensure( this, Checks. contains. Only. NElements( Attribute, 0, Messages. INTERFACE_NO_ATTRIBUTES ) ); Checks. ensure( this, Checks. contains. Only. Specific. Realization. Types( this, TENAInterface. class, Messages. INTERFACE_NOT_IMPLEMENT_INTERFACES ) ); Checks. ensure( this, Checks. contains. Only. Specific. Super. Class. Types( this, TENAInterface. class, Messages. INTERFACE_EXTEND_OTHER_INTERFACES ) ); Checks. ensure( this, Checks. not. Contains. Specific. Operation. Types( this, TENALocal. Operation. class, Messages. INTERFACE_NO_LOCAL_OPERATIONS ) ); return super. Check. Constraints(); } } . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Additional Tests: Generator Testing • Many if not all of the previous statements on testing were based on the assumption that the generator works fine. • Of course, this has to be tested also, at least in the early stages of the generator or the metamodel. • Over time, however, the generator will become a stable asset that works reliably. Or you can buy one and trust it. . Just as you trust C++/Java/etc. compilers. • The effort to develop/adapt reliable generators is of course considerable. This goes back to the issue on reuse, software system families and economical aspects discussed earlier. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Generator Testing: 2 Channel Concepts • In safety-critical systems, the concept of independent channels • It is used to ensure that a failure in a system cannot go undetected by a second channel; • and to ensure that is is very unlikely that a failure does not affect both channels at the same time. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Generator Testing: 2 Channel Concepts II • If one generator or configuration fails, it is assumed that the other one does not fail and will thus detect the failure. • This does not detect failures in the model, of course. To detect those, we would need to extend the 2 channel concept to include the model. . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

Some advertisement • • Völter, Stahl, Bettin • Ein Leitfaden für die pragmatische Arbeit mit der Model Driven Architecture (MDA) • • d. Punkt 2004 Modellgetriebene Softwareentwicklung Not yet published… . ingenieurbüro für sof twaretechnologie w w w. vo © 2 0 0 4 M a rk u s V ö l t e r

The End. <Thanks <Questions? <Comments? <Criticism? . ingenieurbüro für sof twaretechnologie w w w. The End.