1 / 12

Component-Based Design

Component-Based Design. Brown and Wallnau (1998) Component Based Software Engineering (CBSE) in IEEE Software, that: ‘CBSE is coherent engineering practice, but we still haven’t fully identified just what it is.’ Brown and Short (1997) describes a component as:

ketan
Download Presentation

Component-Based Design

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. Component-Based Design

  2. Brown and Wallnau (1998) Component Based Software Engineering (CBSE) in IEEE Software, that: • ‘CBSE is coherent engineering practice, but we still haven’t fully identified just what it is.’ • Brown and Short (1997) describes a component as: • ‘an independently deliverable set of reusable services’ • Heineman and Council (2001) • ‘ a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.’ • the component model that incorporates ‘specific interaction and composition standards’; and • the composition standard, that ‘defines how components can be composed to create a larger structure’.

  3. characteristic properties of a component • Szyperski (1998) • ‘a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition.’

  4. Characteristics of a software component.

  5. Key roles in CBSE

  6. 1. Component providers. Suppliers of components are needed in order to create a component marketplace. Such marketplaces do exist within large organizations, Providers of components need to be able to index and describe their products; to meet any certification standards; and to maintain these in the sense of adapting them to new technologies and platforms aswell as extending their functionality as necessary. 2. Component integrators. The integration role is where the major technical challenges are likely to occur. 3. Customers. The role of the customer is (as usual) one of identifying the needs and acting as the end-user.

  7. Designing with components • Finding components • horizontal roles in a system (distributing the overall system functionality between them) and also vertical roles (providing ‘layers’ of services through mechanisms) • Decisions about vertical structuring choices can be thought of as forming the architectural design element,whereas the horizontal structuring can be thought of as being the detailed design element, not least because they only make sense in that order • When seeking components two possible strategies that might be employed • to identify the general needs of the problem, and then to search for a set of components that collectively match that functionality, finally bringing these together to form a system • to decompose the problem into fairly well-defined subproblems and then seek a set of components that will fit the needs of the individual subproblems

  8. Fitting components together • In composing a system from a set of components, the designer needs to be able to model and predict their aggregate behavior and functionality and, in so doing, to identify the potential for the occurrence of any of the problems

  9. Predicting system behavior • A system that is created by assembling a set of components can be expected to have properties that are in some way an aggregation of the properties of the individual elements.

  10. Designing components • Those that deal with general properties of a component • those that are specific to the needs of a particular architectural style • In general • possesses well-defined functionality; • provides a set of well-defined interfaces; • clearly specifies any explicit dependencies

  11. Some of the particular issues that the case study identifies are as follows: • the benefits of large components that are easy to reuse in preference to smaller ones that could be developed in-house; • the high cost of maintaining backward compatibility with early installations • the need to separate out those features of a component that depend upon platform interactions in order to assist with ease of change

More Related