1 / 13

Introduction to Component-Based Software Development: Challenges and Goals

This document explores the fundamentals of Component-Based Software Development (CBSD), highlighting its significance in addressing current challenges in the software industry. It discusses the need for innovative solutions due to the increasing size and complexity of applications, where monolithic structures become inefficient. Key goals include enhancing code reusability, facilitating easier maintenance, and allowing independent updates of software components. Using analogies like Lego and house building, it illustrates how well-defined components improve software architecture and design, promoting modularity and reliability.

indiya
Download Presentation

Introduction to Component-Based Software Development: Challenges and Goals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related