1. Architectural Mismatch: Why reuse is so hard? Garlan, Allen, Ockerbloom; 1994

2. Two kinds of mismatch Low level problems of interoperability as: –incompatibilities in programming languages/platforms/da ta bases More discussed Architectural mismatch: –mismatch assumptions on the architecture of the system.

3. Project: Aesop System Environment generator for architecture styles Input: Style and a shared infrastructure Output: An environment which consists of: –tools that access the design database (OO) –GUI for modifying and creating new designs –repository of previous designs

4. Requirements for interaction with DB Tools may access the DB through RPC (invoking methods on objects in the DB) Support for event broadcasting: Tools can register to be notified about changes in DB or announce events to other tools.

5. Wishes on reusable parts An OO Database -> OBST A toolkit for constructing GUIs -> InterViews from Stanford University An event-based tool-integration mechanism -> SoftBench from HP An RPC mechanism -> Mach RPC Interface Generator All in C++ or C, available source code.

6. Discovered Integration Problems 1Excessive code 2Poor performance: save took several minutes, start overhead 3Need to modify external packages to work together. 4Need to reinvent existing functions 5Unnecessarily complicated tools 6Error-prone construction process: recompilation took time, code dependencies

7. Architectural overview of the system A system is a configuration of components and connectors. –Components: Entities of the system as tools, DB, servers, filters, etc –Connectors determine the interaction between components as client-server protocols, RPC, pipes.

8. Four main assumptions that can lead to arch.mismatch Nature of components Nature of connectors Global architectural structure Construction process

9. Nature of components Infrastructure: Nature of the underlying support they need, additional infrastructure that they provide or use. Here all components provided additional. Control model: Assumptions on what part of the system holds the main thread of control. Data model: Nature of the data that components manipulate. E.g. InterViews has a hierarchical data structure where one object is part of another and can be modified only by the parent.

10. Nature of Connectors Protocols: E.g. SoftBench forces the clients to implement multiple threads of control; one for each request. Data model: Assumptions about data that is communicated over connectors. E.g. MAC RPC supports data passes through procedures while SoftBench assumes passing of files.

11. Global structure E.g. OBST requires that tools are totally independent of each other. In Aesop, tools can delegate part of their computation to other tools.

12. Construction Process Dependencies between packages to compile, assumptions in each component on the structure of the code

13. Solutions Make architectural assumptions explicit Construct large systems using orthogonal subcomponents Provide bridging Develop architectural design guidelines

14. Make Assumptions Explicit Document assumptions Develop description vocabulary and languages for software architecture

15. Use Orthogonal Subcomponents Components with clear dependencies, easy to replace with other modules, easy to reconfigure

16. Bridging Techniques Mediators components that take over some of the tasks. Smart connectors that translate data in multiple protocols. Wrapper around a component or connector to offer a convenient interface Negotiated interfaces: Components and connectors that handle several styles and can configure themselves dynamically.

17. Design Guidance Find rules and principles for composition Develop guidance for certain application domains