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/data 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
Excessive code
Poor performance: save took several minutes, start overhead
Need to modify external packages to work together.
Need to reinvent existing functions
Unnecessarily complicated tools
Error-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