Architectural Mismatch: Why Reuse Is So Hard

David Garlan, Robert Allen, and John Ockerbloom

Presented by Hoang BaoCSC 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.)

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 database2. A toolkit for constructing graphical user

interfaces3. An even-based tool-integration mechanism4. 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 code2. 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.