Basic Concepts of Component-Based Software Development (CBSD)

1. Basic Concepts of Component-Based Software Development (CBSD) Model-Based Programming and Verification

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

3. Prerequisites • Component library • Component model • Software architecture Three conditions need to be satisfied in order to use the driving forces of reuse and evolutionfor developing component-based systems:

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

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

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

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

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

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

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

14. Components “A software component is a physical packaging of executable software with a well-defined and published interface.” Hopkins, J.: Component Primer, Comm. of the ACM, pp. 27-30, Vol. 43, October 2000.

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

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

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

20. Software architecture “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.” Bass, L., Clements, P., Kazmar, R.: Software Architecture in Practice (Second Edition), Addison-Wesley, 2003.

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

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