Architectural Mismatch: Why Reuse Is So Hard

1
Architectural Mismatch Why Reuse Is So Hard

• David Garlan, Robert Allen, and John Ockerbloom
• Presented by Hoang Bao
• CSC 509 Winter 2005

2
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.

3
Introduction

• Software Architecture
• the structure of the system the different
  components that make the system.

4
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.

5
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.

6
Aesop System (cont.)
7
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

8
Aesop System (cont.)
9
Wishful Thinking

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

10
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

11
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.

12
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.

13
Harsh Reality (cont.)

• Six main problems in integrating the subsystems
• Excessive code
• Poor performance
• Overhead from tool-to-DB communication
• Excessive code contributed to the problem
• Need to modify external package
• Subsystems need major modification to work
  together.

14
Harsh Reality (cont.)

• 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.
• Unnecessarily complicated tools
• Interfaces to tools were more complex than they
  needed to be.
• Error-prone construction process
• As the system was built, modifications became
  increasingly costly. Code size and interlocking
  code dependencies caused large recompilation time.

15
Harsh Reality (cont.)

• Underlying cause of the difficulties
  architectural mismatch.

16
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.

17
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)

18

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

19

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

20

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

21
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.

22

• 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.

23

• 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.

24

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

25

• 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.

26

• 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.

27

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

28
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.