770 likes | 1.33k Views
The Invasive Software Composition System COMPOST. Dr. Uwe Aßmann Institut für Programmstrukturen Universität Karlsruhe Andreas Ludwig Rainer Neumann with contributions of Thomas Genssler Dirk Heuzeroth Ralf Reussner Volker Kuttruf. Overview. Introduction
E N D
The Invasive Software Composition System COMPOST Dr. Uwe Aßmann Institut für Programmstrukturen Universität Karlsruhe Andreas Ludwig Rainer Neumann with contributions of Thomas Genssler Dirk Heuzeroth Ralf Reussner Volker Kuttruf
Overview • Introduction • Well-known Problems in System Construction • Invasive Software Composition • Component Model: Boxes and Hooks • Composition Technique: Program Transformation • Composition Language • Results of Invasive Software Composition • The COMPOST system • Advantages • Visions
Decomposition and SawMill Linux • Decomposition is the most important design principle • Mechanical Engineering (VDI 2221) • Universal Design Theory • Decomposition builds on components/modules
Where are We Today? Component systems (CORBA, DCOM, Beans, OO-frameworks) provide a communication and standard service infrastructure. Todays component systems support modularity only in one dimension • No Extension • No Aspect Separation • No Scalable and Efficient Communication
1.1. Extensibility (here Compilers) • CoSy is a modular component framework for compiler construction [Alt/Aßmann/vanSomeren94] • Built in 90-95 in Esprit Project COMPARE • Sucessfully marketed by ACE bV, Amsterdam • Goal: extensible, easily configurable compilers • Extensions without changing other components • Plugging from binary components without recompilations • New compilers within half an hour
Optimizer I Optimizer II Parser Generated Factory Logical view Generated access layer
CoSy Repository-Architecture Transformation Semantics Parser Optimizer Lexer Codegen Blackboard
Extension with Views Optimizer I Parser Optimizer II
O-O Technology doesn’t fit Optimizer I Optimizer II K K Parser K'' K K''' K Optimizer III K' K'''' K = K' + K''.. Objects have to be allocated by the parser in base class format Fragile Base Class Extension Problem [IBM-SOM] Schema Evolution in OODB [OBST]
CoSy Solution: Extension Operators for Classes K Physical Layout is a merge of the logical views K + K + Every component keeps its logical view
View Mapping Layer Optimizer I Optimizer II Parser Generated Factory Logical view Generated access layer
Advantages of CoSy • Access level MUST be efficient: yes • Due to views, Cosy compilers can be extended easily $$ • Companies reduce costs (e.g. when migrating to a new chip) by improved reuse Is there a general solution to the extensibility problem?
1.2. Mixing in Code m (){ abc.. cde.. return; } m (){ print("enter m"); abc.. cde.. print("exit m"); return; } Method.entry Method.entry Method.exit Method.exit How to automize?
Aspect Separation • Aspekt-orientierted Programming (AOP) • [Kiczales et al, Xerox Parc. ECOOP 97] • Aspect separation is a fundamental interdisciplinary design principle • should contribute to a Universal Design Theory [Goos/Aßmann98]
Structure Electricity Water Gas Integrated building
Debugging aspect Algorithm Persistence aspect Weaver-Tool Debugging aspect Persistence aspect Debugging aspect Persistence aspect Debugging aspect
Advantages of Aspects • Locally concentrated specifications allow to group correlated things (concern concentration) • Weavers generate efficient programs • Easy extension "Es wächst zusammen, was zusammen gehört" Willy Brandt Problem: too many aspect languages
Subject-Oriented Programming (IBM) • Was earlier • Composition rules go further than AOP • very general composition semantics • based on C++/Java • simple • Instead on aspect languages, SOP concentrates on composition languages • Weavers can be written yourself • Hyperspaces are even more systematic, and model cross-cutting/extension very well
1.3. Scalable Efficient Communication m (){ // Events notifyObservers(d); e = listen_to(); } m (){ // Call e = p(d); } ??
Architecture Systems Architectural systems propose separation of architectural aspect by decoupling architectural and application code. Interface Port Component Connector Component
Ports Connectors Ports and Connectors
Evaluation of Architecture Languages • Architecture Languages are a research niche • Interfaces slow down systems • Delegation/Inheritance/Genericity: • Leads to indirections • Macropreprocessing insecure How do we combine abstract architecture and efficient connections?
Questions for Improved Composition • How to extend components flexibly (without expensive adapter levels)? • How to mix aspects into components without special systems? • How to model architecture but make efficient systems?
Software Composition Component Model Composition Technique Composition Language
Invasive Software Composition • View-oriented development • Aspect-oriented development Invasive Composition adapts and extends box components at hooks by program transformation
2.1 Component Model of Invasive Composition • The basic element is a box, a set of program elements • may be the representation • of a component • of an aspect • of a part of a component • a class • a package • a method
Boxes have Hooks Hooks are arbitrary program elements of the representation of a box which are subject to change • Examples: • Method Entries • Communications/calls • Generic Parameters • Generic Statements
2.1.1. Implicit Hooks Example Method Entry/Exit m (){ abc.. cde.. } Method.entry Method.exit
2.1.2. Declared Hooks Declared Hooks are declared by the box writer as variables in the hook’s code. All declared hooks form the Composition Interface of the box. Declarations
Declaration of hooks • Language Extensions (keywords..) • Standardized Names • Inheritance Relations • Comment Tags Class Set extends genericXSuperClass { } class Set /* @superClass */ X SuperClass
2.3 Composition Technique Invasive Composition transforms boxes during the embedding into a reuse context by program transformations of hooks. A composer is a program transformer from unbound to bound hooks composer: box with hooks box with code
Method Entry Method Entry Method Exit Method Exit m (){ abc.. cde.. } m (){ print(“enter m”); abc.. cde.. Print(“exit m”); } Method Exit methodEntryHook.extend(“print(\”enter m\”);”); methodExitHook.extend(“print(\”enter m\”);”);
Invasive Composition as Program Transformations Composer Invasively transformed code
Library Client Invasive composition Black box composition Subsystem Client Library Client Library Invasive connection Black box connection with glue code
Invasive Connection with CORBA import org.omg.CORBA.* import Library; public class Client extends CORBA.client { public order(String name) { // Initialize CORBA Broker ORB orb = ORB.init(args,new Properties()); // Get the seller Library farAway = orb.string_to_object(name); // Order farAway.schaueNach(); farAway.order(); } } import Library; public class Client { public order(String serverName) { // Get the seller Librarylibrary = getLibrary(); // Order library.selectIt(); library.buy(); } } hooks
Invasive Composition Removing Composition Interfaces Functional Interface Composition Interface with Hooks Invasive Composition
The Global Picture of the Invasive Composition Process Box components and hooks Composed Architecture Composition programs
Compositions as Static Meta-programs Client.coc (Java+hooks) Server.coc (Java+hooks) Composition Program in Java and COMPOST Composition/ Configuration Client.java Glue.java Server.java Compiler Compilation
All hooks of one component bound System with components and hooks More things bound and connected Composed system
Principle of Invasive Composition • Every box encapsulates a design decision of the application, hiding it behind a • composition interface which contains well-defined hooks which can be recognized and manipulated by composers • Parnas principle driven to the max!
Information Hiding • If only the composition interface is used for composition, • encapsulates this interface the box such that it can be exchanged to variants. Much more flexible as modules, frameworks, aspects!
Other Use Cases for Invasive Composers • Multiple inheritance • Mixin-based inheritance • Intrusive data functors • Generic type parameters • Generic program elements • Refactorings • Contract-checkers • Automated design patterns • Connectors
Composers Generalize Connectors boxes + composers + hooks boxes + connectors + ports
Hooks for Communications (Ports) Can be declared by calls to standard methods (as in Linda) m (){ // Aufruf e = p(d); } m (){ out(d); in(e); } Output port Input port m (){ // Ereignis notifyObservers(d); e = listen_to(); }
Inheritance vs. Delegation Library Client DCOM-Connector CORBA-Connector Client Library Client Library CORBA-Connection DCOM-Connection
Invasive Extension for CORBA import org.omg.CORBA.* import Library; public class Client extends CORBA.client { public order(String name) { // Initialize CORBA Broker ORB orb = ORB.init(args,new Properties()); // Get the seller Library farAway = orb.string_to_object(name); // Order farAway.schaueNach(); farAway.order(); } } import Library; public class Client { public order(String serverName) { // Get the seller Librarylibrary = getLibrary(); // Order library.selectIt(); library.buy(); } } hooks
Inheritance and Delegation are Composers K Extend invasively Inherit Delegate K-private K K K-subclass Invasive Komposition kann invasive Einbettung, Vererbung oder Delegation einsetzen