Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie 30 Transformational Design with Essential Aspect Decomposition: Model-Driven Architecture (MDA) 1. EAI* for Modular Product Lines Prof. Dr. U. Aßmann 2. Model-Driven Architecture Technische Universität Dresden 3. Model Mappings Institut für Software- und Multimediatechnik 4. Model Merging and Weaving Gruppe Softwaretechnologie 5. MDSD with domain-specific tagging http://st.inf.tu-dresden.de Version 13-1.1, 22.01.14
References Ø Obligatory: • www.omg.org/mda Model driven architecture. • MDA Guide. OMG (ed.). Reference document for MDA applications Ø Optional: • J. Frankel. Model-driven architecture. Wiley. Excellent book on the concepts of MDA, including the MOF, model mappings. • Manfred Nagl, editor. Building tightly integrated software development environments: the IPSEN approach, volume 1170 of Lecture Notes in Computer Science. Springer-Verlag Inc., New York, NY, USA, 1996. • CIP Language Group. The Munich Project CIP, volume 1 of Lecture Notes in Computer Science. Springer-Verlag, 1984. • Bauer et al. The Munich project CIP. Volume 1: The wide spectrum language CIP-L, volume 183 of Lecture Notes in Computer Science. Springer-Verlag, Berlin, Germany, 1985. • F. L. Bauer, et al. The Munich Project CIP. Volume II: The Transformation System CIP-S. Springer-Verlag, LNCS 292, 1987. MDA TU Dresden, Prof. U. Aßmann 2
Problem: The Representation Schizophrenia Ø Problem: Design Aging , one of the biggest problems in software maintenance Ø If an artifact has several representations, such as design, implementation, documentation, and code: always the code is modified, and the other become inconsistent Ø Usually, a design specification ages faster than implementation, because the programmers are tempted to change the implementation quickly, due to deadlines and customer requests Ø They “forget” to update the design Ø Solution: Ø XP: Single-source principle Ø don't represent in other ways that code Ø “clean code that works” Ø MDA: Generate the code from models, enable a round-trip to solve the problem MDA TU Dresden, Prof. U. Aßmann 3
30.1 PRODUCT LINES WITH MODULAR VARIABILITY
Problem – Reuse in Product Lines (Product Families) Ø Many products must be produced in variants for different platforms (portability problem): Ø Machines ranging from PDA over PC to host Ø Component models from .NET over CORBA to EJB Ø Technical spaces such as Java vs .NET vs. Python Ø How to develop a product line with products for all these platforms? Ø How to reuse common parts of products (programs)? Ø How to reuse common parts of models? MDA TU Dresden, Prof. U. Aßmann 5
Employ Modularity (Modular EAI): Addition of Modules in the Essential Modules Ø The product’s modules consist of essence, administration, infrastructure (EAI aspects) Ø Modular design adds administration and infrastructure components later (remember Parnas’ principle of information hiding) E E E E E E A A E E E E E E E E I I E E E E E E A A A A I I I I + + E E E E E E A A E E E E E E E E E E A A E E E E E E E E I I E E E E E E E E E E I I E E E E E E
Corollar: EAI-based Product Lines are Independent of the Component Model Ø Be aware: This scheme works with all forms of modules, component models and architectural styles (see course CBSE) • Modules, Functions, Actions, Processes, Packages, etc • Objects • Data-flow diagrams • ECA-modules • Aspects MDA TU Dresden, Prof. U. Aßmann 7
Modular EAI with Partial System Configurations of Modules or Components Essence Admin Ad minist istra ratio ion + + Validated Essence: Essence + Administration Infra rast stru ruct cture re + + Platform-specific: Essence + Administration + Infrastructure TU Dresden, Prof. U. Aßmann 8
What Are Platforms? Ø Platforms are concerns (aspects) on the infrastructure, describing the environment on which a system runs • Platforms slice a system into platform-independent (aspect-independent) and platform-dependent parts (aspect-related) Ø Possible platforms: • Abstract machines Ø Libraries, such as JDK, .NET • Implementation languages Ø Java, Eiffel, C# • Component models Ø CORBA, Enterprise Java Beans (EJB), .NET-COM+, etc. • Ontology of a domain (e.g., medicine) • Constraints of the system Ø Time Ø Memory Ø Energy Ø Platforms define variability levels of a system, with variants that produce a variant of the specification MDA TU Dresden, Prof. U. Aßmann 9
Modular EAI* with Partial System Configurations of Modules or Components Essence Admin Ad minist istra ratio ion + + Validated Essence: Essence + Administration Infra rast stru ruct cture re of of + + Pla Platform rm 1 1 Platform-specific: Essence + Administration + Infrastructure Infra rast stru ruct cture re of of + + Pla Platform rm 2 2 Platform-specific 2: Essence + Administration + Infrastr. 1 + Infrastr. 2 TU Dresden, Prof. U. Aßmann 10
Example: Variant 1: Modular EAI* of an OMS Essence: Order Management System (OMS) Ad Admin minist istra ratio ion + + Validated Essence: OMS with Contract Checking Infra rast stru ruct cture re of of + + Platform Pla rm OpenER ERP Platform-specific: OMS based on platform OpenERP Infra rast stru ruct cture re of of + + Pla Platform rm Ja Java va Platform-specific: OMS on OpenERP on Java TU Dresden, Prof. U. Aßmann 11
Example: Variant 2: Modular EAI* of an OMS Essence: Order Management System (OMS) Admin Ad minist istra ratio ion + + Validated Essence: OMS with Contract Checking Infra rast stru ruct cture re of of + + Pla Platform rm SAP SAP Platform-specific: OMS based on platform SAP Infra rast stru ruct cture re of of + + Pla Platform rm ABAP ABAP Platform-specific: OMS on SAP on ABAP TU Dresden, Prof. U. Aßmann 12
EAI*: Modular Variability with Partial System Configurations of Modules or Components Ø EAI* is an development style for modular product lines, in which several infrastructural aspects (“platform-specific aspects”) are distinguished Validated Essence: Platform- Independent Module Set (PIMS) Pla Platform rm Ext Extensio sion Mo Module les s 1 + Pla Platform rm Descrip scriptio ion Mo Module le (PD (PDM) M) Platform-Specific Module Set 1 (PSMS 1) Pla Platform rm Ext Extensio sion Mo Module les s 2 + Platform-Specific Module Set 2 (PSIMS 2) Handwrit ritten mo module les + Platform-Specific Implementation Module Set (PSIMS 3, Code) TU Dresden, Prof. U. Aßmann
Addition of Modules in the Modular EAI* Ø The product’s components consist of • Platform-independent components • Platform-specific components / extensions Ø Modular EAI* adds platform-specific components later + + MDA TU Dresden, Prof. U. Aßmann 14
Multiple Platforms – Multiple Addition of Modules in the Modular EAI* Ø The product’s components consist of • Platform-independent components • Platform-specific components / extensions Ø Modular EAI* adds platform-specific components later + + + + MDA TU Dresden, Prof. U. Aßmann
Exercise: Modular EAI* with GNU Packages Ø Download a C-based GNU package Ø Identify essential, adminstrational, platform-specific modules Ø How many platforms are distinguished? Ø Analyse the “configure” script and its input “configure.in” • Can you identify the platforms and their variants? Ø How does configure achieve platform variability? MDA TU Dresden, Prof. U. Aßmann 16
30.2 MODEL-DRIVEN ARCHITECTURE (MDA) MDA TU Dresden, Prof. U. Aßmann 17
Remember: Refinement-based Modelling Ø Refinement-based design and transformative design (with GRS) are an old idea. • Broadband languages, such as CIP or IPSEN did this in the 70s already Ø Refinement starts with some simple model Ø Apply refinement steps: Ø Elaborate (more details – change semantics) Ø Add platform-specific details Ø Semantics-preserving operations Ø Restructure (more structure, but keep requirements and delivery, i.e., semantics) Ø Split (decompose, introduce hierarchies, layers, reducibility) Ø Coalesce (rearrange) Ø TransformDomains (change representation, but keep semantics) MDA TU Dresden, Prof. U. Aßmann 18
Recommend
More recommend
