Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II 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 Institut für Software- und Multimediatechnik 3. Model Mappings Gruppe Softwaretechnologie 4. Marked PIM http://st.inf.tu-dresden.de/teaching/swt2 5. Model Merging and Weaving Version 15-1.6, 15.10.15 1. MDSD with domain-specific tagging 1
References Softwaretechnologie II 2 Ø Obligatory: • www.omg.org/mda Model driven architecture. • MDA Guide. OMG (ed.). Reference document for MDA applications • AndroMDA toolkit for MDA § http://www.andromda.org/andromda-documentation/getting-started-java/ index.html Ø 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, Prof. U. Aßmann Germany, 1985. • F. L. Bauer, et al. The Munich Project CIP. Volume II: The Transformation System CIP-S. Springer-Verlag, LNCS 292, 1987.
Software Development in the V-Model Softwaretechnologie II 3 Ø The most simple software development process is the V-model Pre-Study Acceptance Test • Product concept catalogue (Lastenheft) Acceptance test cases Requirements Analysis Installation, Beta • Software Requirement Specification Test (SRS) System Test (in- Achitectural Design System house) test cases • Architecture (Grobentwurf) Component, Detailed Design Subsystem Test • (Feinentwurf) Unit test cases Contracts, Class Implementation Tests Prof. U. Aßmann
Problem: The Representation Schizophrenia Softwaretechnologie II 4 Ø Problem : Design Aging , one of the biggest problems in software maintenance Ø If a system 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 Ø Programmers “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 Prof. U. Aßmann
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II 30.1 PRODUCT LINES WITH MODULAR VARIABILITY Prof. U. Aßmann 5
Problem – Reuse in Product Lines (Product Families) Softwaretechnologie II 6 Ø 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? A pro A roduct ct lin line re require ires a a mo modula larit rity tech chniq ique ( (co comp mponent Prof. U. Aßmann mo model) )
Employ Modularity (Modular EAI): Addition of Modules in the Essential Modules Softwaretechnologie II 7 Ø 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 + + Prof. U. Aßmann 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 Softwaretechnologie II 8 Ø Be aware: This scheme works with all forms of modules, components, and architectural styles (see course CBSE) • Modules, Functions, Actions, Processes, Packages, etc in programs • Objects, slides in runtime systems • Data-flow diagrams, ECA-modules in models • Views in programs and models Prof. U. Aßmann
Modular EAI with Partial System Configurations of Modules or Components Softwaretechnologie II 9 Ø The development process of Modular EAI adds administration and infrastructure views to the essence Essence Admin Ad minist istra ratio ion + + Validated Essence: Essence + Administration Infra rast stru ruct cture re + + Prof. U. Aßmann Platform-specific: Essence + Administration + Infrastructure
What Are Platforms? Softwaretechnologie II 10 Ø Platforms are concerns 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+, JSF, Swing, etc. • Ontology of a domain (e.g., medicine, cars, insurance) § SNOMED ontology, Gene Ontology • Constraints of the system Ø Time Ø Memory Prof. U. Aßmann Ø Energy Ø Platforms define variability levels of a system, with variants that produce a variant of the specification
Modular EAI* with Partial System Configurations of Modules or Components Softwaretechnologie II 11 Ø The development process Modular EAI* adds several infrastructure views (platform views) to the essence 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 Prof. U. Aßmann Infra rast stru ruct cture re of of + + Pla Platform rm 2 2 Platform-specific 2: Essence + Administration + Infrastr. 1 + Infrastr. 2
Example: Variant 1: Modular EAI* of an OMS Softwaretechnologie II 12 Ø OMS is extended for platforms OpenERP and Java 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 + + Pla Platform rm OpenER ERP Platform-specific: OMS based on platform OpenERP Prof. U. Aßmann Infra rast stru ruct cture re of of + + Pla Platform rm Ja Java va Platform-specific: OMS on OpenERP on Java
Example: Variant 2: Modular EAI* of an OMS Softwaretechnologie II 13 Ø OMS is extended with platform views SAP and ABAP 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 Prof. U. Aßmann Infra rast stru ruct cture re of of + + Pla Platform rm ABAP ABAP Platform-specific: OMS on SAP on ABAP
Modular EAI*: Modular Variability with Partial System Configurations of Modules or Components Softwaretechnologie II 14 Ø Modular 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 Module Mo les s 1 + Pla Platform rm Descrip scriptio ion Mo Module le (PDM) (PD M) Platform-Specific Module Set 1 (PSMS 1) Platform Pla rm Ext Extensio sion Mo Module les s 2 + Platform-Specific Module Set 2 (PSIMS 2) Prof. U. Aßmann Handwrit ritten mo module les + Platform-Specific Implementation Module Set (PSIMS 3, Code)
Addition of Modules in the Modular EAI* Softwaretechnologie II 15 Ø The product’s components consist of • Platform-independent components • Platform-specific components / extensions Ø Modular EAI* adds platform-specific components later + + Prof. U. Aßmann
Multiple Platforms – Multiple Addition of Modules in the Modular EAI* Softwaretechnologie II 16 Ø The product’s components consist of • Platform-independent components • Platform-specific components / extensions Ø Modular EAI* adds platform-specific components later + + Prof. U. Aßmann + + + +
Exercise: Modular EAI* with GNU Packages Softwaretechnologie II 17 Ø 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? Prof. U. Aßmann
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II 30.2 TRANSFORMATIONAL DESIGN WITH THE MODEL-DRIVEN ARCHITECTURE (MDA) Prof. U. Aßmann 18
Recommend
More recommend
