CBSD – Component Based Software Development

1. CBSD – Component Based Software Development - Introduction -

2. Current Challenges of the Software Industry • Constant innovation in hard- and software • Applications are growing larger and more complex • Many applications tend to be monolithic • Programming models are not consistent • Knowledge is wasted by tedious programming routines

3. Goals • Components that can be easily taken out of one context and be put into another • Reuse of existing code and expertise • Easier maintenance of existing programs • Changing / Updating of parts of the program without interfering with other parts

4. Analogies • Lego Game AnalogyComponents bought for a specific use (e.g. building a castle) can be used to build ships, airplanes etc. • House Building AnalogyPlumbers, Masons, etc all have their very well defined roles, not having to bother with other problems.

5. Components – Definition - • A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. • A software component can be deployed independently and is subject to composition by third parties. (Szyperski)

6. Characteristics of a Component • Well defined purpose • Context free • Portability • Self descriptive • “Plug and play” • Reusable • Reliability • Modular • Interface and Implementation are independent

7. Components vs Objects • Components and Objects are related, Components CAN be made of objects. • Components have one instance only in a system. • Components can be easily taken out of their context, whereas objects generally can not

8. Interfaces Abstract definition of services the compontent offers, (e.g. public variables, methods); input and output. Interface definitions should be separate from implementation. • ProvidedInterfaces a component offers • RequiredInterfaces a component depends on

9. Interfaces II • Interfaces should require only what is essential for solving the problem • A well defined Interface is crucial, especially as component design can be completely independent. Two (or more) components can rely on each other while having completely different developers.

10. Design by Contracts • Interfaces as “Contracts” between the interface provider and the client • Formal specification of the Interface • Functional requirementsPrecondition, Postcondition etc • Non functional requirementsPerformance, resources • Components (further revisons e.g) can only require less or deliver more once the contract is in place

11. Distributed Components • Components can be purchased from the developer and are made available e.g. over the internet • Transparency: The client does not need to know where a component is, it always functions the same. Client can use the component wherever he or the component may be • Components can be run on specialized Hardware that the client can profit from without having to purchase the hardware himself

12. Composition and Reuse • FrameworksCollection of Interface specifications and rules to specify and enforce the interaction of components • Architectures • Blackbox reuseRe-user knows only the specified interfaces. The possible reuse of a component is thus dependent on a clear specification • Glass box reuseRe-user can “look inside” the component and inspect the Implementation, he can however not alter it. • White box reuseRe-user can modify the component

13. Outlook… • ComponentsSold, rented, “Pay per use” • ToolsComponent design, testing, compositionvisual tools, maintenance • ServicesComponent System Architects, Assembly Consultants