Software development with components
Download
1 / 39

Software development with components - PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on

Component composition [Sommerville], chap 19.3 Composition Issues: Architectural mismatch [CrnkovicBook], chap 9 [GarlanArticle] Predictable composition [CrnkovicBook], chap 9. Software development with components. Software development with components. Component composition

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Software development with components' - april


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software development with components

Component composition

[Sommerville], chap 19.3

Composition Issues:

Architectural mismatch

[CrnkovicBook], chap 9

[GarlanArticle]

Predictable composition

[CrnkovicBook], chap 9

Software development with components


Software development with components1
Software development with components

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

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
Example 1: Incompatible components

Figure 19.10 from [Sommerville]


Example 1 incompatible components1
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
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

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:


Example photo library composition
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

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.


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 components2
Software development with components

Component composition

[Sommerville], chap 19.3

Composition Issues:

Architectural mismatch

[CrnkovicBook], chap 9

[GarlanArticle]

Predictable composition

[CrnkovicBook], chap 9


Component integration
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


Component composition
Component Composition

  • Integrating (“wiring”) components is only a first step

  • Composition (making components “play well together”) is still difficult:

    • 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/archmismatch-icse17/archmismatch-icse17.pdf

Architectural mismatch


Component composition issues
Component composition issues 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.”

  • “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
Architectural mismatch examples 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.”

  • 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 Example 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.”

  • 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
Problems in AESOP integration (1) 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.”

  • 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
Problems in AESOP integration (2) 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.”

  • 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
Problems in AESOP integration (3) 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.”

  • 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
Problems in AESOP integration (4) 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.”

  • 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
Problems in AESOP integration (5) 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.”

  • 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
Problems in AESOP integration (6) 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.”

  • 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
Problems in AESOP integration (7) 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.”

  • 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
Consequences for Aesop 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.”

  • 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
Component integration issues 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.”

  • “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
Recommended practice 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.”

  • To avoid architectural mismatch:

    • Make assumptions explicit

    • Use orthogonal loosely-coupled components

    • Use bridging techniques to solve mismatches

    • Provide design and composition guidelines


Compressing proxy example
Compressing proxy example 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.”

  • 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 example1

Process 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.”

Function call interface

Component

UNIX pipe interface

Channel

Compressing Proxy

2

3

gzip

4

1

Pseudo Filter

(Adaptor)

Filter

Filter

Compressing proxy example

Figure 9.1 from [CrnkovicBook]


Compressing proxy issues
Compressing proxy issues 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.”

  • 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
Lessons learned 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.”

  • 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

  • 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
From Integration to Composition 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.”

  • 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
Predictable Assembly from Certifiable Components 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.”

  • 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?


Summary
Summary 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.”

  • Component-based development includes:

    • Component development (design for reuse)

    • System development (design with reuse)

  • System composition/integration may show problems:

    • Interface incompatibility

    • Architectural/ mismatch

    • Emergent properties of component assembly:

      • Certified component

      • Analysis techniques - compositional reasoning


ad