110 likes | 225 Views
Component-based Software Engineering. CBSE seminar, Oslo, 4 Feb. 2005 Christian Bunse Christian.Bunse@iese.fraunhofer.de Phone: +49 (0) 6301 707 211 Fax: +49 (0) 6301 707 200. based on a presentation by Ian Sommerville. Objectives.
E N D
Component-based Software Engineering CBSE seminar, Oslo, 4 Feb. 2005 Christian Bunse Christian.Bunse@iese.fraunhofer.dePhone: +49 (0) 6301 707 211 Fax: +49 (0) 6301 707 200 based on a presentation by Ian Sommerville
Objectives • To show that Component-based Software Engineering (CBSE) is concerned with composing systems with standardized components • To give a short glimpse on components • To show the principal activities in the CBSE process
Component-based development • Component-based software engineering (CBSE) is an approach to software development that relies on software reuse. • CBSE emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific. • Components are more abstract than objects and classes. Thus, they can be considered to be stand-alone service providers. • CBSE requires knowledge, careful planning, and methodological support.
Component definitions • Szyperski: • 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. • Councill and Heinmann: • A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.
Component Characteristics • Standardised – Following a standard component model • Independent – Usable without Adapators • Composable – External interactions use public interface • Deployable – Stand-alone entity • Documented – Full Documentation
CBSE and design principles • Apart from the reuse, CBSE is based on sound software engineering principles: • Components are independent→do not interfere with each other; • Component implementations are hidden; • Communication is through well-defined interfaces; • Component platforms are shared and reduce development costs. • Component interfaces and application are „standardized“ to ease application
CBSE problems • Component trustworthiness - how can a component with no available source code be trusted? • Component certification - who will certify the quality of components? • Property prediction - how can the emergent properties of component compositions be predicted? • Component Dependability – how do we handle components which depend on other components or systems to work properly • Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?
The CBSE process • When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. • This involves: • Developing outline requirements; • Searching for components then modifying requirements according to available functionality. • Searching again to find if there are better components that meet the revised requirements.
The CBSE process From a presentation by Ian Sommerville
Key points • A component is a software unit whose functionality and dependencies are completely defined by its interfaces. • A component model defines a set of standards that component providers and composers should follow. • CBSE is a reuse-based approach to define and implement loosely coupled components into systems. • During the CBSE process, the processes of requirements engineering and system design are interleaved. • Truly applying CBSE is not easy. One has to think about potential risks and carefully to plan ahead