Basic Concepts of Component-Based

Software Development (CBSD)

Model-Based Programming and Verification

Motivation Conventional software engineering methods are less

and less usable to build large and complex systems.

Teams work in parallel on smaller projects to reduce development time.

These projects should be handled independently of each other for greater efficiency.

This concept led to the emergence of CBSD (Component Based Software Development).

Growing dependency of people on the proper functioning of computer systems demands new methods to increase the reliability and correctness of these systems.

Prerequisites

Component library Component model Software architecture

Three conditions need to be satisfied in order to use the driving forces of reuse and evolution for developing component-based systems:

Component library Software developers still tend to write

new components for a given problem domain rather than integrating already existing ones into a system.

On the other hand, the components available at online markets are usually for industrial not educational purposes.

A system cannot be considered correct if the components of it do not work properly, so only verified components should be allowed.

Verification methods

Testing Synthesis Model checking

Each of today’s most widely used verification methods have their own limitations. Students should be aware of these while trying to build their own components and verify them with any of the following methods:

Component models

CORBA DCOM Java/RMI

The most generally used component models in the commercial area to support the composition of applications based on standards are:

Software architecture

An abstract backbone is needed to support the process of building applications from the independent components.

The abstraction of a system does not only show the structure of the system and the interaction between its elements but is also transferable to other systems with similar quality and functional properties, also promoting the concept of reuse in large and complex systems.

Framework*

CBSD is ideally not more than putting pieces together. So there must be an environment in which that can be done, and that is a framework.

Unfortunately, even today most system developers consider writing an application from scratch as a greater challenge and therefore a greater recognition for them than developing an application using existing software components.

*Gross, Hans-Gerhard: Component-Based Software Testing with UML, Springer, 2005.

Component granularity

It is essential to find a balance between the factors of cohesion and coupling.

One of the main purposes of the educational framework is to support the students to practice these design decisions.

Independently of one specific component model? Once an application developer has decided to

follow one of the component models it becomes impossible to integrate a new component of another model into the application.

The introduction of a new level of a so-called “universal component” would solve the problem if the model specific IDL (Interface Definition Language) could be transformed into a “universal interface” given in a general language, possibly XML.

Components

Hopkins, J.: Component Primer, Comm. of the ACM, pp. 27-30, Vol. 43, October 2000.

“A software component is a physical packaging of executable software with a well-defined and published interface.”

Reuse and evolution Reuse: the use of already existing

software to build new systems. Evolution: enables the replacement

of certain components without affecting the functionality of other parts. (That is a major difference between CBSD and OOP.)

Testing not able to guarantee that there are no more

hidden errors left in the design or in the code. two distinct levels: testing of the components and

an integration testing of the assembled application. a component (standalone, physical software

package) is supposed to be tested independently either through a user interface or a “virtual test bench”.

completely impossible to detect timing errors in a system.

new testing methods are developed to overcome these shortcomings.

Model checking Model checking is an automatic – in practice

human assistance is usually needed – technique for verifying finite state concurrent systems.

The main challenge in model checking is dealing with the state space explosion problem. That problem occurs in systems with many components that can make transitions in parallel.

Software architecture

Bass, L., Clements, P., Kazmar, R.: Software Architecture in Practice (Second Edition), Addison-Wesley, 2003.

“The software architecture of the program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and relationships among them.”

Framework We consider framework as “a skeleton of an

application which can be customized by an application developer”.

The relationship between frameworks and components is also important.

A component is identified as “an atomic part that can be used (and not changed) within the framework”.

Johnson, R. E.: Frameworks = (Components + patterns), Comm. of the ACM, Vol. 40, October 1997.

Component granularity Defining the range of component granularity

can also be difficult because several factors (level of abstraction, likelihood of change, complexity of a component, etc.) have to be considered while designing components.

A component should not be too small as the interaction between smaller components requires more time and resource, on the other hand a too large component provides more complex interfaces, is subject to more frequent changes and makes a system less flexible.