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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, email, web-page, database, presentation 27/11/2018 CBSE

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

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

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

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

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

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

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