Transcript Component Based Softyware Engineering

Software development with
components
• The CBSE Process
– [Sommerville], chap.19.2
• Component composition
– [Sommerville], chap 19.3
• Composition Issues:
– Architectural mismatch
• [CrnkovicBook], chap 9
• [GarlanArticle]
– Predictable composition
• [CrnkovicBook], chap 9
Software development with
components
• The CBSE Process
– [Sommerville], chap.19.2
• Component composition
– [Sommerville], chap 19.3
• Composition Issues:
– Architectural mismatch
• [CrnkovicBook], chap 9
• [GarlanArticle]
– Predictable composition
• [CrnkovicBook], chap 9
The software process
•
A structured set of activities required to develop a
software system
– Specification;
– Design;
– Validation;
– Evolution.
•
A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.
Generic software process models
•
The sequential/waterfall model
– Separate and distinct phases of specification and development.
•
Evolutionary development
– Specification, development and validation are interleaved.
– Development of system is done gradually in many repetitive stages
• Each stage increases the knowledge of the system requirements and/or the
system functionality
– Models:
•
•
•
•
•
Iterative model
Incremental model
Prototyping model
Rational Unified Process model
Component-based software engineering
– The system is assembled from existing components.
Component-Based Development
• Design for reuse (Domain Engineering): Component
Development
– Producing reusable components
• Design with reuse (Application Engineering): System
Development
– Using components to compose and integrate systems
The CBSE process
• Design with reuse
• When reusing components, it is essential to make tradeoffs between ideal requirements and the services
actually provided by available components.
• This involves:
– Developing outline requirements;
– Searching for components then modifying requirements
according to available functionality.
– Searching again to find if there are better components that meet
the revised requirements.
The CBSE process
•
The software development process must be adapted to reusing
components
Fig. 19.6 from [Sommerville]
The CBSE process
•
When reusing components, it is essential to make trade-offs between
ideal requirements and the services actually provided by available
components.
•
Design stages with CBSE:
1.
Developing outline requirements: stakeholders should be as flexible as
possible in defining requirements.
2.
Identify candidate components
3.
Requirements are refined and modified early in the process depending on the
components available.
4.
Architectural design: at latest in this stage (if not earlier) you decide on a
component model and establish the high-level organization of the system
5.
Identify candidate components again - Searching again to find if there are
better components that meet the revised requirements and the established
architecture
6.
System development – composition process where the selected component
are integrated.
The component identification process
Component identification involves a number of subactivities
1.
Component search: Where to find components:
•
Locally (inside software development organization)
•
Component marketplace
2.
Component selection:
•
3.
Complicated if there is not a direct mapping of requirements to components
Component validation
•
Check that the component behaves exactly as advertised
Fig. 19.7 from [Sommerville]
Component identification issues
• Trust. You need to be able to trust the supplier of a component. At
best, an untrusted component may not operate as advertised; at
worst, it can breach your security.
• Requirements. Different groups of components will satisfy different
requirements.
• Validation.
– The component specification may not be detailed enough to allow
comprehensive tests to be developed.
– Components may have unwanted functionality. How can you test this
will not interfere with your application?
• Consequence of these issues:
– component search is often confined to a software development
organisation
– No viable component marketplace
Ariane launcher failure
• In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster
when the launcher went out of control 37 seconds after take off.
• The problem was due to a reused component from a previous
version of the launcher (the Inertial Navigation System) that failed
because assumptions made when that component was developed
did not hold for Ariane 5.
• The functionality that failed in this component was not required in
Ariane 5.
Software development with
components
• The CBSE Process
– [Sommerville], chap.19.2
• Component composition
– [Sommerville], chap 19.3
• Composition Issues:
– Architectural mismatch
• [CrnkovicBook], chap 9
• [GarlanArticle]
– Predictable composition
• [CrnkovicBook], chap 9
Component composition
• The process of assembling components to create a system.
• Composition involves integrating components with each other and
with the component infrastructure.
• The ways in which components are integrated with this
infrastructure are specific for each component model
• Normally you also have to write ‘glue code’ to integrate components.
Types of composition
•
Sequential composition where the composed components are executed in
sequence. This involves composing the provides interfaces of each
component.
– Glue code: calls component A, collects result, then calls component B with that
result as parameter
•
Hierarchical composition where one component calls on the services of
another. The provides interface of one component is composed with the
requires interface of another.
•
Additive composition where the interfaces of two components are put
together to create a new component.
Types of composition
A
A
B
A
B
(a)
B
(b )
(c)
Figure 19.9 from [Sommerville]
Interface incompatibility
•
When you desig components specially for composition, interfaces are
designed to be compatible and composition is easy.
•
When the components are developed independently for reuse, interfaces
may be incompatible:
–
Parameter incompatibility where operations have the same name but are of different types.
–
Operation incompatibility where the names of operations in the composed interfaces are
different.
–
Operation incompleteness where the provides interface of one component is a subset of the
requires interface of another
•
Interface incompatibility is addressed by writing adaptors
•
Adaptors address the problem of component incompatibility by reconciling the
interfaces of the components that are composed.
•
Different types of adaptor are required depending on the type of composition.
Example 1: Incompatible components
strin g lo cation (string p n)
p ho neDatabase (string co mman d)
ad dressFin der
strin g own er (strin g pn )
strin g pro per tyTy pe (string p n)
d isp lay Map (string p ostCo d e, scale)
map DB (string co mmand )
map per
p rin tMap (strin g po stCod e, scale)
Figure 19.10 from [Sommerville]
Example 1: Incompatible components
• addressFinder component: finds the address that matches a phone
number
• mapper component: takes a post code and displays a street map of
the area
• emergency operator: receives an emergency phone call, identifies
the calling number and displays the street map of the address to
send there an emergency vehicle
– Realised by composing an addressFinder with a mapper
– Problem: addressFinder returns a string describing the complete
address, but the mapper needs only the post code
• An adaptor component called postCodeZipper takes the location data from
address Finder and strips out the post code
Example 1: Composition through an adaptor
• The component postCodeStripper is the adaptor that facilitates the
sequential composition of addressFinder and mapper components.
address = addressFinder.location (phonenumber) ;
postCode = postCodeStripper.getPostCode (address) ;
mapper.displayMap(postCode, 10000)
Example 2: Adaptor for data collector
• There is an incompatibility between the provides interface of the
sensor component with the requires interfaces of the data collection
component
sen sorMan agemen t
ad dSenso r
remo veSenso r
star tSen sor
star t
sen sor
stop
g etd ata
Ad apter
Data co llecto r
sen sorData
stop Sen sor
testSenso r
initialise
rep or t
listAll
Figure 19.11 from [Sommerville]
Interface semantics
• Component composition assumes you can tell from the component
documentation whether the interfaces are compatible
– Syntactic compatibility: operation names and parameter types
– Semantic compatibility: the meaning of parameters is right
• You have to rely on component documentation to decide if
interfaces that are syntactically compatible are actually compatible.
• Example: Consider an interface for a PhotoLibrary component:
public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc)
public Photograph retrieve (Identifier pid) ;
public CatalogEntry catEntry (Identifier pid) ;
Example: Photo library composition
• Compose a system that downloads images from a digital camera and
stores them in a photograph library . The system user can provide
additional info to catalog and describe the images
g etImag e
ad dItem
Imag e
Man ager
ad aptor
Pho to
Lib rary
retriev e
catEn try
g etCatalog En try
User
In ter face
Figure 19.12 from [Sommerville]
Example - formal description of photo library
Figure 19.13 from [Sommerville]
Example - Photo library conditions explained
• As specified, the OCL associated with the Photo Library component
states that:
– There must not be a photograph in the library with the same identifier as
the photograph to be entered;
– The library must exist - assume that creating a library adds a single item
to it;
– Each new entry increases the size of the library by 1;
– If you retrieve using the same identifier then you get back the photo that
you added;
– If you look up the catalogue using that identifier, then you get back the
catalogue entry that you made.
Composition trade-offs
• When composing components, you may find conflicts between
functional and non-functional requirements, and conflicts between
the need for rapid delivery and system evolution.
• You need to make decisions such as:
– What composition of components is effective for delivering the
functional requirements?
– What composition of components allows for future change?
– What will be the emergent properties of the composed system?
Example: Data collection and report generation
•
A system can be created through 2 alternative compositions
(a)
(b )
Data
co llection
Data
co llection
Repo r t
g enerator
Data
manag ement
Repo r t
Data b ase
Repo r t
Figure 19.14 from [Sommerville]
CBD Key points
• During the CBSE process, the processes of requirements
engineering and system design are interleaved.
• Component composition is the process of ‘wiring’ components
together to create a system.
• When composing reusable components, you normally have to write
adaptors to reconcile different component interfaces.
• When choosing compositions, you have to consider required
functionality, non-functional requirements and system evolution.
Software development with
components
• The CBSE Process
– [Sommerville], chap.19.2
• Component composition
– [Sommerville], chap 19.3
• Composition Issues:
– Architectural mismatch
• [CrnkovicBook], chap 9
• [GarlanArticle]
– Predictable composition
• [CrnkovicBook], chap 9
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 like EJB, CORBA
and COM: reduces some of the integration problems
• Still Difficult to make components play well together:
– Problem goes beyond interface compatibility (syntactic and
semantic)
– In many cases mismatches may be caused by low-level problems
of interoperability, such as incompatibilities in programming
languages, operating platforms, or database schemas.
– Architectural mismatch results from implicit and conflicting
assumptions that designers of components make about the
environment in which these components will operate
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
Architectural mismatch examples
• 2 Cases
• 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
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)
• 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
• Different packages make different assumptions about which
part holds the main thread of control: SoftBench, InterViews
and MIG all use event loops that are incompatible with each
other => rewrite InterViews event loop
• Different components assume different things about the nature
of data: 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 (2)
• Problems related to connectors:
– Event broadcast, RPC
• 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
• SoftBench’s event mechanism and Mach RPC assume
different things about the nature of data to be transmitted:
ASCII strings vs C data types => translation between formats
=> performance bottleneck
Problems in AESOP integration (3)
• OBST assumes that all communications occurs in a star
configuration, with itself in the center, but 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
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 architectural assumptions explicit
– Use orthogonal loosely-coupled components
– Use bridging techniques to solve mismatches
– Provide design and composition guidelines
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
• Formal architectural description and analysis to uncover what
they call “behavioral mismatch”
• Not a component mismatch (components can be plugged
together)
• Components must express behavioural properties:
–
assumptions made about it’s environment such as data formats or
buffer sizes
– Its effects on the environment
• The success of a component marketplace depends on:
– Having trustworthy claims for component properties
– Having global analysis techniques to support reasoning about the
emergent properties of assemblies
From Integration to Composition
• All assemblies are potential subsystem
• Predicting the emergent behavior of assemblies
• The result of component composition is a component assembly
which can be used as a part of a larger composition
• Composition goes beyond integration by allowing prediction of
the emergent behavior of assemblies
• Compositional reasoning: if we know the properties of
components c1 and c2, then we can define a reasoning
function f such that f(c1,c2) yields a property of an assembly
comprising c1 and c2
Predictable Assembly from
Certifiable Components
• What types of system quality attributes are developers
interested in predicting?
• What types of analysis techniques support reasoning about
these quality attributes, and what component property values
do they require as input parameters?
• How are these component properties specified, measured, and
certified?
Prediction-Enabled Component
Technology
• A prediction-enabled component technology consists of a
component model and an associated analysis model
• PECT integrates ideas from research in the areas of:
– software architecture-based analysis,
– component certification
– software component technology
• Prediction-enabled component technologies exploit the
relationship between structural restrictions and assumptions of
analysis models to compute properties of assemblies based on
trusted properties of the assembly’s constituent components.
Prediction-Enabled Component Technology
Component
Model
Analysis
Model
PECT
interpretation
Component
Model
Analysis
Model
assumptions
not connected
specializes
influences
Summary
• Component-based development includes:
– Component development (design for reuse)
– System development (design with reuse)
• Component based system development:
–
evolutionary process model: sequence of outlining requirements,
finding, selecting and validating components - > repeated as
needed
• System composition/integration may show problems:
– Interface incompatibility
– Architectural/ mismatch
– Emergent properties of component assembly:
• Certified component
• Analysis techniques - compositional reasoning