1. 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

2. 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

3. 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.

4. 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.

5. 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

6. The CBSE process Design with reuse
When reusing components, it is essential to make trade- offs 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.

7. The CBSE process
The software development process must be adapted to reusing components
Fig from [Sommerville]

8. 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:
Developing outline requirements: stakeholders should be as flexible as possible in defining requirements.
Identify candidate components
Requirements are refined and modified early in the process depending on the components available.
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
Identify candidate components again - Searching again to find if there are better components that meet the revised requirements and the established architecture
System development – composition process where the selected component are integrated.

9. The component identification process
Component identification involves a number of subactivities
Component search: Where to find components:
Locally (inside software development organization)
Component marketplace
Component selection:
Complicated if there is not a direct mapping of requirements to components
Component validation
Check that the component behaves exactly as advertised
Fig from [Sommerville]

10. 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

11. 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.

12. 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

13. 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.

14. 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.

15. Types of composition
Figure 19.9 from [Sommerville]

16. 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.

17. Example 1: Incompatible components
Figure from [Sommerville]

18. 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

19. 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)

20. 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 from [Sommerville]

21. 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:

22. 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 from [Sommerville]

23. Example - formal description of photo library
Figure from [Sommerville]

24. 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.

25. 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?

26. Example: Data collection and report generation
A system can be created through 2 alternative compositions
Figure from [Sommerville]

27. 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.

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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).

38. 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

39. 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

40. Compressing proxy example
Filter
Pseudo Filter
(Adaptor)
gzip 1 2 3 4
Compressing Proxy
Process
Component
Channel
Function call interface
UNIX pipe interface
1 contains a graphical representation of the Compressing Proxy. Data to be transmitted over the Web enters the proxy by way of the filter on the left. It is then fed into another filter that acts as an adaptor which supports the use of the gzip application, which performs data compression. Careful analysis revealed the potential for deadlock because the adaptor blocked while supplying data to gzip. The adaptor could not then receive any compressed data until all the data had been read by gzip. Gzip was not allowed to offload zipped data over connection 3 until all the data had been read from the adaptor via connection 2. This meant that any attempt to process a file larger than the capacity of the gzip buffer would cause the system to deadlock. Based on this finding the adaptor was replaced by a non-blocking version and the proxy functioned as intended.
Figure 9.1 from [CrnkovicBook]

41. 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

42. 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

43. 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
Component composition goes one step further than integration in that the resulting composition can be a part of larger assemblies. Composition is based on the ability to assign properties to the whole based on the properties of the parts.
composition is distinguished from integration primarily by the fact that composition also focuses on emergent assembly-level behaviour, making certain that the assembly will perform as desired and that it could be used as a building block in a larger system. The constituent components must not only plug together, they must play well together.
In analogy, consider the incompatibility of connecting a very powerful audio amplifier to low wattage speakers. The speakers will plug in with no problem, and at low volumes will probably function acceptably but if the volume is raised the speakers will most likely be destroyed.

44. 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?
These three questions are interdependent. The types of compositional reasoning which can be accomplished ultimately depend upon the types of component properties which can be measured. Conversely, it is the reasoning techniques which determine what component properties are material in the first place. Therefore, the answers to these three questions, which are mutually informing (and constraining), will provide a foundation for a sustainable improvement in predicting the properties of component assemblies and for confidence in the software components which make up these assemblies. However, answering these questions will be an ongoing process: new prediction models will require new and/or improved component measures, which will in turn lead to more accurate prediction, and to a demand for better or additional prediction models, more precise component measures, and so forth.

45. 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.

46. Prediction-Enabled Component Technology
Model
Analysis
assumptions
interpretation
PECT
not connected
specializes
influences
The PECT approach is based on two fundamental premises: first, that system quality attributes are emergent properties that are associated with patterns of interaction among components, and, second, that software component technology provides a means of enforcing predefined and designed interaction patterns, thus facilitating the achievement of system quality attributes by construction.

47. 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