CBSD – Component Based Software Development - Introduction -

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

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

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

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)

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

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

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

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.

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

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

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

Outlook… Components Sold, rented, “Pay per use” Tools Component design, testing, composition visual tools, maintenance Services Component System Architects, Assembly Consultants