Architectural Mismatch: Why Reuse Is So Hard David Garlan, Robert Allen, and John Ockerbloom Presented by Hoang Bao CSC 509 – Winter 2005

Authors David Garlan Assistant professor of CS at Carnegie Mellon University Coauthor with Mary Shaw of “Software Architecture: Perspectives on an Emerging Discipline” Robert Allen and John Ockerbloom Graduate students of CS at Carnegie Mellon University.

Introduction Software Architecture: the structure of the system; the different components that make the system.

Introduction (cont.) Future breakthroughs in software productivity depend on the ability to combine existing pieces of software to produce new application. There are several reasons why such breakthroughs are elusive: Lack of existing pieces or inability to locate them. Low level problems: incompatibilities in programming languagues, operating platforms, or database schemas. Architectural mismatch: mismatched assumptions a reusable part makes about the structure of the system it is to be a part of.

Aesop System An example of a system built from existing parts. Aesop produces a custom design environment when given a set of architectural-style descriptions. Each style contains descriptions of: An architectural design vocabulary (as a set of object types). Visualizations of design elements suitable for manipulation by graphical editor A set of architectural analysis tools to be integrated into the environment.

Aesop System (cont.)

The shared infrastructure is incorporated into each environment as a set of basic support services for architectural design. It includes: A design database for storing and retrieving designs A graphical user interface for modifying and creating new designs. A tool-integration framework A repository mechanism

Aesop System (cont.)

Wishful Thinking Article focuses on the challenges in creating the infrastructure. Developers want to reuse 4 standard pieces: 1. An object oriented database 2. A toolkit for constructing graphical user interfaces 3. An even-based tool-integration mechanism 4. A Remote Procedure Call (RPC) mechanism

Wishful Thinking (cont.) Criteria for choosing each piece: Able to process the systems using the same compilers Each piece has been used successfully in several development projects Each piece is compatible with the operating system and the machine platforms

Wishful Thinking (cont.) Choices for 4 subsystems: OBST, a public domain object-oriented database InterViews, a toolkit for constructing graphical user interfaces SoftBench, an event-broadcast mechanism from Hewlett-Packard Mach RPC Interface Generator (MIG), an RPC stub generator. All are written in C++ or C All have been used in projects All have available source code. ESTIMATION: the work would take 6 months and one person year.

Harsh Reality It took two years and nearly five-person years to finish the first Aesop prototype. Even then, prototype was huge, sluggish, and difficult to maintain.

Harsh Reality (cont.) Six main problems in integrating the subsystems: 1. Excessive code 2. Poor performance Overhead from tool-to-DB communication Excessive code contributed to the problem 3. Need to modify external package Subsystems need major modification to work together.

Harsh Reality (cont.) 4. Need to reinvent existing functions Example: had to build another transaction mechanism for the OBST database because the original one did NOT allow sharing transactions across multiple address spaces. 5. Unnecessarily complicated tools Interfaces to tools were more complex than they needed to be. 6. Error-prone construction process As the system was built, modifications became increasingly costly. Code size and interlocking code dependencies caused large recompilation time.

Harsh Reality (cont.) Underlying cause of the difficulties: architectural mismatch.

Understanding Architectural Mismatch View system as a configuration of components and connectors. Components: primary computational and storage entities. E.g. tools, databases, servers, etc. Connectors: determine the interactions between the components. E.g. client-server protocols, RPC links, pipes, etc.

Understanding Architectural Mismatch (cont.) Four main categories of assumptions: Assumptions about the nature of components Assumptions about the infrastructure, control model, and data model (the way environment manipulate data managed by component)

Assumptions about the nature of the connectors Assumptions about the protocols, and data model (kind of data communicated)

Assumptions about global architectural structure Assumptions about the presence or absence of particular components or connectors.

Assumptions about the construction process Assumptions about the order in which the pieces are instantiated and combined with the system.

Conflicting Assumptions Conflicting assumptions created the difficulties in creating Aesop. Conflicting assumptions about the nature of components Infrastructure – Each package assumed it had to provide considerable infrastructure, much of which were not needed. This was one of the reason for excessive code. Some packages made assumptions about what kind of components exist in the final product, therefore used infrastructure that did not match needs.

Control model – Assumptions about what part of software held the main thread of control. Each package uses a different event loop – which were incompatible with each other. This caused for extra works in modifying the code.

Data model – The package assumed certain things about the nature of the data they will be manipulating. Some of these assumptions were not acceptable and caused more modification works.

Conflicting assumptions of the nature of connectors Protocols – Tools that handled the request/reply protocol can be created as sequential program. SoftBench’s handling of the protocol forces these tools to handle concurrency – making the work unnecessarily more difficult.

Data model – Two communication mechanisms, Mach RPC and Softbench, made different assumptions about the data that will be communicated. Mach RPC – data in C based model Softbench – data represented as ASCII strings Translation routines were developed to fixed the problem; but they cost significant overhead.

Conflicting assumptions about global architectural structure OBST assumed that tools are completely independent of each other. However Aesop tools need to coordinate with each other to delegate computation. Forced developers to build a transaction manager.

Conflicting assumptions about the construction process Conflicting assumptions of the build process resulted in time-consuming and complicated construction.

The Way Forward Make architectural assumptions explicit Use orthogonal subcomponents Ideally, designers should be able to modify the architectural assumptions by substituting different modules for the one already there. Provide bridging techniques Modifying components and connectors Putting wrappers around components or connectors; wrappers provide convenient interfaces to the rest of the system. Develop sources of architectural design guidance The software community should construct principles and rules for software composition.