Component-based Software Engineering

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 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, … 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. 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 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. CBSE

7. Too less, too much • Custom-made 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 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. 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 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. 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) 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) CBSE

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

14. What could be a component • Procedures • Libraries • Classes (not objects) • Modules CBSE

15. What is a component • Coarse grain • Applications executing in the environment provided by an operating system • Finer grain • Web browsers’ plug-ins • Microsoft Office documents • Spreadsheet, document, email, web-page, database, presentation 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 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. 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 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 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 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. 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 CBSE