Scribd
Upload
144 views19 pages

Build Systems Off-The-Shelf Components: Introduction To Software Architecture

This document discusses how off-the-shelf components impact software architecture design and how to address interface mismatches between components. It notes that selecting components constrains the architecture and that the architect must understand components' assumptions. It describes techniques for repairing interface mismatches, such as using wrappers to translate interfaces, bridges to reconcile incompatible assumptions, and mediators to provide a unified interface. The key is identifying components' assumptions early and prototyping to discover mismatches before integration.

Uploaded by

Sandeep Varma Sunkari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
144 views19 pages

Build Systems Off-The-Shelf Components: Introduction To Software Architecture

This document discusses how off-the-shelf components impact software architecture design and how to address interface mismatches between components. It notes that selecting components constrains the architecture and that the architect must understand components' assumptions. It describes techniques for repairing interface mismatches, such as using wrappers to translate interfaces, bridges to reconcile incompatible assumptions, and mediators to provide a unified interface. The key is identifying components' assumptions early and prototyping to discover mismatches before integration.

Uploaded by

Sandeep Varma Sunkari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Build Systems Off-the-shelf

Components
Introduction to Software Architecture
Jay Urbain, Ph.D.
Credits: Bass, et al., Software Architecture in Practice
1

Quality attributes & Architecture


Emphasize the connection between desired quality
attributes and architecture.
Assuming control over system design means control
over the qualities achieved.
Increasingly this is not the case as the use of off-theshelf components has increased.

Off-the-shelf Components
Components
Change the design process
Constrain the architecture
Embody architectural (and quality) assumptions
Architect must ensure assumptions are the right ones.
Whether you use components or not, you need to
understand how to incorporate them into your system.

Component Selection Process


Component selection can be thought of as a discovery
process.
Need to:
Identify assemblies of compatible components.
Understand how they can achieve the desired quality
attributes.
Decide if they should be incorporated into the system
being built.

Reusable Assets (cont.)


Focus on common-sense light weight approach:
Hypothesize what it means for the components you have chosen to
work.
Build simple prototypes to test your hypotheses.
Evolve what works
Maintain backup plan (Plan B) if things dont work out.

Key insight:
Choosing and selecting single components is not enough.
Need to choose and test assemblies of components that need to work in
concert.
COTS not necessarily a silver bullet need to determine importance of
function and quality attributes for important functions of system!

Example: AOLbyPhone/Quack.com with 34M users elevated availability and


performance as primary business drivers.
5

Impact of components on
architecture
Lets say youre hired to design a sophisticated piece of control
software for a manufacturing plant.
The requirements call for a high-end GUI graphically showing the
state of manufacturing subsystems.
You are able to find off-the-shelf components for building the GUI:
graphics plotting package, UI components, Swing, VB, etc.
What impact does this have on the architecture of your system?
Need to evaluate component quality assumptions.

Impact of components on
architecture
System has to adopt VB/Swing callback-centered-style _or_ the
operator portion has to be isolated from the rest of the system.
Adopt AJAX from graphics plotting scalability, availability, security?
Web framework Rails, Spring, PHP, Swing, etc.
Major structural decision can be driven by the choice of a single
component!!!
All but the simplest components have an assumed architectural
pattern that is difficult to violate.
Selecting architecture prior to selecting components can be difficult.
Understanding of components and their interactions must be
established prior to/while selecting architecture.

Architectural Mismatch
Architectural mismatch - Impediment to successfully
integrating component-based systems.
Mismatch between assumptions embodied in separately
developed components.
Can manifest architecturally
Often shows up at integration time
Often due to interface assumptions

Interfaces:
Names of methods and parameters say nothing about behavior.
Side effects: consumption of global resources, timing, etc.

Interface Assumptions
Provides Assumptions
Describes assumptions a component provides to its clients.

Requires Assumptions
Describes services or resources that a component must have in
order to correctly function.

What you can do:


Avoid components if necessary by careful inspection.
Detect cases you have not avoided by careful qualification of
component use.
Repair those cases you have detected by adapting the
components.

Repairing Interface Mismatch


First categorize component tactics and qualities.
Changing code of offending components not always possible, or
desirable.
Usually more desirable to insert code that reconciles component
interaction to reconcile mismatch.
Wrappers
Bridges
Mediators

10

Wrapper
Wrapper
Implies some form of encapsulation.
Clients access component service only through
wrapper interface.
Provides interface translation:
Translate element of component interface into
alternative element.
Hide element of component interface
Preserve element of component interface without
change.
E.g. OpenGL; Fortran library of components made
available to network clients through distributed object
interface (CORBA, Enterprise Java Beans, .Net)

11

Wrapper
Implement Wrapper with Adaptor pattern

12

Bridge
Bridge
Translate some requires assumptions of one component to some
provides assumptions of another component.
Key difference between a bridge and a wrapper is that the repair
code constituting a bridge is independent of any particular
component.
Also, the bridge must be explicitly invoked by some external agent
possibly (but not necessarily) one of the components the bridge
spans.
Bridges are usually transient, i.e., specific translation is defined at the
time of bridge construction.
13

Study declares 12.8% of California bridges 'structurally


deficient'

Bridge

Bridge Pattern
Decouple an abstraction from its implementation so that the two can
vary independently.

Abstraction - defines the abstract interface, maintains the Implementor reference


RefinedAbstraction - extends the interface defined by Abstraction
Implementor - defines the interface for implementation classes
ConcreteImplementor - implements the Implementor interface

14

Bridge (cont.)
Bridge
Typically focus on narrower range of interface
translations than wrappers because bridges address
specific assumptions.
Tradeoff: the more assumptions a bridge tries to address,
the fewer components it can be applied to.
Bridges often work for filter/pipe styles.
Example, need component to display PostScript or PDF.
Solution: create bridge to translate PostScript to PDF

Example, need to draw shapes

15

Mediators
Mediators
Provides a unified interface to a set of interfaces in a subsystem.
This pattern is considered to be a behavioral pattern due to the way
it can alter the program's running behavior.
Major distinction between Bridges and Mediators:
Mediators incorporate a planning function that results in runtime
determination of the translation.
Bridges establish this translation at construction time.

Mediators provide run-time assembly of sequences (e.g., bridges) to


integrate components whose integration requirements arise at
runtime.
Example: Fusion information retrieval system

16

Strategy Pattern
Strategy pattern
Allows algorithm selection at runtime.

17

Detecting Interface Mismatch


Prototype integration to discover subtle forms of
interface mismatch.
Were tacitly acknowledging our poor understanding.
Need to discover all requires assumptions of the component for
each service
Make sure that each requires assumption is satisfied by some
provides assumption in the system.

18

Avoiding Interface Mismatch


Identify/specify as early in the design as possible as many of the
assumptions about a components interface as possible.
Important to think of interface as set of assumptions, not just an API.
Prototype.

19

You might also like