Transcript Component Based Softyware Engineering

Architectural Mismatch
or
Why it’s hard to build systems
out of existing parts
Bibliography
• Garlan, Allen, Ockerbloom: Architectural Mismatch or
Why it’s hard to build systems out of existing parts, in
ICSE 1995
– Article has been nominated as one of the “most influential” in a 25-years
retrospective of IEEE Software and had a follow-up:
• Garlan, Allen, Ockerbloom: Architectural Mismatch: Why
Reuse is Still So Hard, IEEE Software 2009
• Ivica Crnkovic, Magnus Larsson. Building reliable
component based software systems, Chapter 9:
Component Composition and Integration
Review: Component Integration
• Integrating components can be illustrated as a
mechanical process of “wiring” components
together to form assemblies (connecting required
and provided interfaces)
• Standardization in form of component models
reduces some of the integration problems
Review: Component Composition
• Integrating (“wiring”) components is only a first step
• Composition (making components “play well
together”) is difficult:
– We have seen that interface compatibility (both syntactic
and semantic) is needed
Component Composition Problems
• the problem goes beyond interface
compatibility (syntactic and semantic) and
could be due to the so called Architectural
mismatch
Architectural mismatch
“Architectural mismatch stems from mismatched
assumptions a reusable part makes about the structure
of the system it is to be part of. These assumptions
often conflict with the assumptions of other parts and
are almost always implicit, making them extremely
difficult to analyze before building the system.”
D. Garlan, R. Allen and J. Ockerbloom. “Architectural Mismatch: Why Reuse is
So Hard,” IEEE Software, 12(6):17-26, November 1995
http://www.cs.cmu.edu/afs/cs/project/able/ftp/archmismatchicse17/archmismatch-icse17.pdf
Component composition issues
• “Architectural mismatch stems from mismatched
assumptions a reusable part makes about the
structure of the system it is to be part of”
• four classes of structural assumptions
– The nature of components (infrastructure, control model,
and data model)
– The nature of connectors (protocols and data models)
– The architecture of the assemblies (constraints on
interactions)
– The run-time construction process (order of instantiations).
Architectural mismatch examples
• 2 case studies:
• D. Garlan, R. Allen and J. Ockerbloom “Architectural
Mismatch: Why Reuse is So Hard”
• AESOP
• P. Inverardi, A.L. Wolf, and D. Yankelevich, Static Checking of
System Behaviors Using Derived Component Assumptions
• Compressing proxy
Compressing proxy example
• Problem: adding data compression to a web server, in
order to improve performance
• Characteristics of web server:
– Standard CERN HTTP server
– Pipes-and-filters architecture
• Proposed solution:
– Add an external filter to compress data using gzip
– External compressing filter communicates with the web server
through Unix pipes (read and write data)
– A pseudo filter (adaptor) is added to work with the external
compressing filter
Compressing proxy example
Process
Function call interface
Component
UNIX pipe interface
Channel
gzip
Compressing Proxy
2
Filter
1
3
Pseudo Filter
(Adaptor)
4
Filter
Figure 9.1 from [CrnkovicBook]
Compressing proxy issues
• HTTP server filters are forced to read when data are
pushed at them
• Unix filters choose when to read data -> gzip may block
• Normal scenario:
– Adaptor passes the data from input filter to gzip, and when the
stream is closed, reads the data from gzip and writes in the
output filter
• Problematic scenario:
– If the input file is large, because gzip has a limited internal
buffer, it may attempt to write a portion of compressed data
before the adaptor is ready: => deadlock (gzip blocks and
adapter is blocked)
• Solution:
– Adaptor should handle data incrementally and use unblocking
read and write
Lessons learned from
Compressing Proxy
• Formal architectural description and analysis to uncover what
they call “behavioral mismatch”
• Not a component mismatch (components can be “wired”
together)
• Components must express behavioural properties:
–
assumptions made about it’s environment such as data formats or
buffer sizes
– Its effects on the environment
AESOP Example
• AESOP: developed by CMU, an environment that
generates development environments tailored for
systems of a particular style
• Development approach: integrate existing components
• Components:
– A object oriented database (OBST – public domain system)
– GUI toolkit (Interviews and Unidraw – Stanford university)
– An event-based tool-integration mechanism (SoftBench from
HP)
– A RPC mechanism (Mach RPC Interface Generator – CMU)
• Advantages:
– Stable tools, used in several other projects
– All tools implemented in C/C++ AND with source code available
Problems in AESOP integration (1)
• Assumptions about the components:
infrastructure:
– Components assume they have a certain infrastructure, but
it is not available
• Ex: SoftBench assumes all components have their own
GUI interfaces and hence have the X-library’s
communication primitives loaded => all components had
to load X library even if they do not need it otherwise =>
code bloat
– Components assume that they should provide a certain
infrastructure, which the application does not need
• Ex: OBST provides many functions, Aesop needs only
few of these
Problems in AESOP integration (2)
• Assumptions about the components:
control model:
– Different packages make different assumptions about which part
holds the main thread of control
• Ex: SoftBench, InterViews and MIG all use event loops that are
incompatible with each other => rewrite InterViews event loop
Problems in AESOP integration (3)
• Assumptions about the components: data
model:
– Different components assume different things about the nature
of data
• Ex: Unidraw maintain a hierarchichal model for its objects but
allows only top-level objects to be manipulated by users, Aesop
requires that both parent and child objects can be manipulated =>
rewrite Unidraw hierarchy
Problems in AESOP integration (4)
• Assumptions about the connectors: protocols
• SoftBench handles RPC by mapping it within the event
framework through 2 events (the request and the reply) => the
caller becomes more complicated => use Mach RPC instead of
Softbench
Problems in AESOP integration (5)
• Assumptions about the connectors: data
model
– Components have different assumptions on what comes
over a connection
• Ex: SoftBench: Strings; MIG: C data; OBST C++ data.
• translation between formats needed => performance
bottleneck
Problems in AESOP integration (6)
• Assumptions about the global
architecture
– OBST assumes that all communications occurs in a star
configuration, with itself in the center, Assumes independence
of client tools and provides a transaction protocol per single tool,
not per combination of tools
– Aesop’s communication structure is a more general graph
(tools cooperate also directly) => OBST’s transaction
mechanism can result in deadlock or database
inconsistency => write own transaction mechanism
Problems in AESOP integration (7)
• Assumptions about the building process
– Assumptions about the library infrastructure
– Assumptions about a generic language (C++)
– Assumptions about a tool specific language
• Some component A may have other expectations on the
generated code of another component B as B itself
Consequences for Aesop
• Effort:
– Estimated: one person-year
– Reality: 5 person-years
• Code bloat
• Poor performance: due to overhead of the tool-to-database
communication and excessive code
• Need to modify existing packages: ex. Event loop of SoftBench and
Interview
• Need to reimplement some existing functions: OBST transaction
mechanism, Hierarchical nested view management in InterView
Component integration issues
• “Architectural mismatch stems from mismatched
assumptions a reusable part makes about the
structure of the system it is to be part of”
• four classes of structural assumptions
– The nature of components (infrastructure, control model,
and data model)
– The nature of connectors (protocols and data models)
– The architecture of the assemblies (constraints on
interactions)
– The run-time construction process (order of instantiations).
Recommended practice
• To avoid architectural mismatch:
– Make assumptions explicit
– Use orthogonal loosely-coupled components
– Use bridging techniques to solve mismatches
– Provide design and composition guidelines