architectural mismatch: why reuse is so hard
Post on 14-Jan-2016
19 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related