1. Component-based Software Engineering
Motivations
Marcello Bonsangue
LIACS – Leiden University
Fall 2005

2. Component-based Software Engineering
Main concerns:
Development of software from pre-produced parts
Reuse of those parts in other applications
Easily maintaining and customizing those parts to produce new features
Goals (users’ demands)
Build more reliable software
Less time between versions
27/11/2018
CBSE

3. Component everywhere
Concerns and goals are similar in many other engineering disciplines
Precise assembly of reusable, well-documented, quality and trusted parts
For them components are well established
Civil engineering -> house prefab, …
Chemical engineering-> proteins, …
Electronic engineering-> circuit,…
Industrial engineering -> cars, …
27/11/2018
CBSE

4. Example: the automobile lesson
Car assembly was a costly, tedious and slow process
Henry Ford life’s goal:
Produce cars for the masses by building them faster
Ford’s method
The assembly line (1914)
Idea by reversing the process of beef- trolleys: butchers removed cuts from the carcass passed by until nothing remained.
27/11/2018
CBSE

5. But why not in Software engineering?
If the goals of CBSE are no different from industrial and civil engineering why is CBS an hype only now?
Industrial and civil engineering develop final products
Software is a generic meta-product that can be used to create families of instances
using different parametrizations
27/11/2018
CBSE

6. Standards
Industrial and civil engineering successfully develop components because of standards, regulations and laws.
Before the software crisis (1968) software had no standard.
27/11/2018
CBSE

7. Too less, too much Custom-made software Fully standard software
Flexible, competitive, if it works
Maintenance, interoperability are serious problems
Very long time to market
Fully standard software
Short time to market
Maintenance, interoperability and evolution are vendor business
Hard to be competitive, hard to adapt
27/11/2018
CBSE

8. Standard needed
Interaction standard for specifying the explicit context dependency on other software elements
Composition standard for defining how components can be composed to create a larger structure and how a producer can replace one existing component with another one.
27/11/2018
CBSE

9. What are components? (I)
A software component is not different from other software elements because of the programming language used to implement it
The difference must be in how software components are used
Components are not for real programmers.
They are for software users
Components are for composition
Parts can be reused by rearranging them
27/11/2018
CBSE

10. Software users
The PC revolution and the Internet have interjected a new heavy weight in the software arena: the software consumer.
Before consumerization of software:
Turn every user into a programmer.
After consumerization of software:
Turn every human into a software user.
27/11/2018
CBSE

11. Two approaches to reuse
Design a system monolithically and then find the parts (top-down)
Often parts are not reusable
Design the parts and then compose them into a system (bottom-up)
Parts must be general (to be really reusable)
but not too much (to remain practicable)
27/11/2018
CBSE

12. Software components A software components is a software element that
conforms to specific interactions and composition standards
can be independently deployed and composed without modification (according to a composition standard)
27/11/2018
CBSE

13. What is not a component The requirement for independence rules out
Type declarations
C macros
C++ templates
Smalltalk blocks
27/11/2018
CBSE

14. What could be a component
Procedures
Libraries
Classes (not objects)
Modules
27/11/2018
CBSE

15. What is a component Coarse grain Finer grain
Applications executing in the environment provided by an operating system
Finer grain
Web browsers’ plug-ins
Microsoft Office documents
Spreadsheet, document, , web-page, database, presentation
27/11/2018
CBSE

16. Neither custom nor fully-standard
Conformity to interaction and composition standards allow for
robust integration
fast time to market
and rules out custom-made software
Whereas independence is essential to allow for
multiple independent vendors
independent development
and rules out fully-standard software
27/11/2018
CBSE

17. Component abstraction levels
To design and develop the internals of a components we distinguish four levels of abstraction
Component specification
Component implementation
Component executable
Component deployment
The process can be carried out using techniques like UML and OO programming languages, and methodologies supporting component production.
27/11/2018
CBSE

18. Component specification
It includes the technology independent definition of the component but also information to facilitate the finding of a component (gap fulfilment)
It may derives from
Component producer’s desire
Solution builder’s specific needs
Industry standard for interactions and compositions
27/11/2018
CBSE

19. Component implementation
It defines the inside of a component, with its internal parts and collaborations.
It occurs after the decision of the programming language to use for the development
It must satisfies the specification
One-to-many relationship
27/11/2018
CBSE

20. Component executable
It is the real pluggable component used in the assembly of the application
Each executable may results in more than one version
There may be more than one executable per implementation
27/11/2018
CBSE

21. Component deployment
It is the deployment of the component executable on a number of nodes
There may be several deployment for the same executable.
27/11/2018
CBSE

22. Component production
A methodology for the production of components must support the four component abstraction levels
It is different from traditional software production
More time is spent for business rules, business process modelling, analysis, and design
Less time is spent in development
27/11/2018
CBSE