Architectural Mismatch: Why Reuse Is So Hard EEE465 2001 References: GAO94,Sha95

1
Architectural MismatchWhy Reuse Is So
HardEEE465 2001References GAO94,Sha95

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Component Software

• The goal
• increase productivity
• allow for the creation of larger systems
• reduce overall defect densities
• The strategy
• allow for reuse of large-grain components in new
  systems
• provide a suite of such components
• The problem
• assumptions made by the parts either dont
  match their environment of use, or conflict with
  assumptions of other parts

3
Traditional Barriers to Reuse

• incompatibilities in
• programming languages
• operating systems
• database schemas
• distribution technologies
• lack of appropriate libraries
• hard to develop appropriate components to meet
  very-high-level abstractions
• difficult to navigate those libraries that exist
• organizational issues
• incentive to reuse
• incentive to develop reusable components

4
Architectural Barriers to Reuse

• mismatched assumptions a reusable part makes
  about the structure of the system it is to be
  part of
• assumptions are often implicit, making them
  difficult to analyze before starting
• issue is packaging, not functionality

5
Case Study AESOP

• AESOP is an experimental software design
  environment developed at CMU
• Desire to minimize development effort by maximum
  reuse of existing components for the four major
  subsystems
• object-oriented database OBST
• toolkit for building drawing editors UniDraw,
  Interviews
• framework for event-based tool integration
  Hewlett-Packard SoftBench
• remote procedure call generator Mach RPC
  Interface Generator (MIG)
• All written in C and C, all with source code
  available

6
What Happened

• Being written by professional software engineers,
  within a software engineering research group
• Expectation
• six months
• one person-year
• small, fast, clean system
• Reality
• two years
• five person-years
• initial prototype only
• big, slow, difficult to maintain

7
Integration Problems

• excessive code
• UI alone was over 3 MB, database over 2.3 MB
• small tools ballooned
• e.g., 20 SLOC expanded to 600,000 SLOC when
  integrated
• poor performance
• tool-to-database communication expensive
• many seconds to save a small design (20 objects)
• size contributed to slowness, especially in a
  distributed environment (Andrew File System)
• three minute startup time

8
Integration Problems (II)

• need to modify existing packages
• many systems needed major modification to work
  together at all
• SoftBench, InterViews, and MIG all expected to
  own the event loop
• OBST did not allow object handles to be
  communicated to external tools
• need to reinvent existing functions
• InterViews didnt allow external access to nested
  drawings
• had to recreate nested drawing editor
• OBST didnt allow transactions to be shared
  across multiple address spaces
• had to reimplement transaction mechanism

9
Integration Problems (III)

• unnecessarily complicated tools
• many desired tools were simple, single-threaded,
  sequential
• infrastructure assumed multi-threading, so tools
  had to be built to account for multi-threading
• error-prone construction process
• time to recompile extremely long
• large code size
• interlocking code dependencies
• simple changes would break automated build
  routines

10
Root Causes

• reusable subsystems were designed for reuse, and
  generally considered well-designed
• development team was experienced and well-trained
• problems were primarily structural in nature
• nature of components
• assumptions about infrastructure, control model,
  data model
• nature of connectors
• assumptions about protocols, data models
• global architectural structure
• assumptions about topology, presence or absence
  of other components or connectors
• construction process
• components make assumptions about order in which
  each is instantiated

11
Nature of Components

• Infrastructure
• assumptions about available infrastructure, or
  whether component provides own infrastructure
• OBST expected to be infrastructure, provided many
  unnecessary object classes
• SoftBench assumed all tools would have UI, and
  communicated using X-Windows library many AESOP
  tools were non-graphical but had to include
  X-Windows for communications
• Control model
• assumptions about which component is in control
• SoftBench, Interviews, MIG each had a different,
  incompatible event loop
• since they were in the same process, loops
  couldnt easily be bridged
• had to modify Interviews event loop to look for
  SoftBench events

12
Nature of Components (II)

• Data model
• assumptions about how data is to be manipulated
• UniDraw provided hierarchical drawings, but
  expected that only the top-level objects would be
  manipulated
• didnt match application semantics, had to
  reimplement

13
Nature of Connectors

• Protocols
• SoftBench was event based, used notify, request,
  reply messages
• all handled uniformly
• request required two messages system might
  interleave a notify in between
• so, all tools had to support multi-threading,
  even when unnecessary or otherwise inappropriate
• Data model
• Mach based on C structs and arrays, SoftBench on
  ASCII strings
• translation overhead between models for every
  database access

14
Global Architectural Structure

• OBST assumes star, with database at center
• no direct interaction between tools
• concurrency between tools seen as conflict, not
  cooperation
• didnt match AESOP model of cooperating tools
• had to build transaction manager layer on top of
  OBST

15
Construction Process
Assumed dependencies SoftBench, MIG, OBST
application- specific code
depends on
generic package code
depends on
infrastructure (package supplied)
16
Summary

• problems were primarily structural in nature
• nature of components
• assumptions about infrastructure, control model,
  data model
• nature of connectors
• assumptions about protocols, data models
• global architectural structure
• assumptions about topology, presence or absence
  of other components or connectors
• construction process
• components make assumptions about order in which
  each is instantiated

17
Solutions

• standardize on a single component technology,
  with its assumptions
• CORBA, DCOM, Java Beans, Enterprise Java Beans,
  etc
• develop tools and techniques to bridge different
  component models
• next slide
• develop techniques to develop components with
  fewer assumptions
• Robert DeLine. Avoiding packaging mismatch with
  Flexible Packaging. In Proc. ICSE 1999. pp
  97106. http//research.microsoft.com/users/rdelin
  e/

18
Coping with Mismatched Parts
Introduce intermediate form
Give B an import/export converter
Change A to match Bs form
A
B
Transform on the fly
Make B multi-lingual
Publish abstraction of A
Attach wrapper to A
Maintain parallel consistent versions of A and B
19
Next ClassDesign Exercise