1. 1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, haibinz@nipissingu.ca, http://www.nipissingu.ca/faculty/haibinz haibinz@nipissingu.ca

2. 2 Lecture 17 Component-Based Software Engineering Ref. Chap. 30

3. 3 The Idea of Reuse The initial idea of component-based development is learning from the hardware industry to reuse hardware components such as integrated circuits (IC), large- scale integrated circuit (LSI), very large scale integrated circuits (VLSI), chips, chip-sets, boards, etc The initial idea of component-based development is learning from the hardware industry to reuse hardware components such as integrated circuits (IC), large- scale integrated circuit (LSI), very large scale integrated circuits (VLSI), chips, chip-sets, boards, etc Reusing hardware components is well accepted, because in hardware engineering, to understand a component is much easier than to make it. Reusing hardware components is well accepted, because in hardware engineering, to understand a component is much easier than to make it. It is impossible for application developers to develop hardware components such as chips and boards. It is impossible for application developers to develop hardware components such as chips and boards.

4. 4 The Key Questions When faced with the possibility of reuse, the software team asks: When faced with the possibility of reuse, the software team asks: Are commercial off-the-shelf (COTS) components available to implement the requirement? Are commercial off-the-shelf (COTS) components available to implement the requirement? Are internally-developed reusable components available to implement the requirement? Are internally-developed reusable components available to implement the requirement? Are the interfaces for available components compatible within the architecture of the system to be built? Are the interfaces for available components compatible within the architecture of the system to be built? At the same time, they are faced with the following impediments to reuse... At the same time, they are faced with the following impediments to reuse...

5. 5 Impediments to Reuse Few companies and organizations have anything that even slightly resembles a comprehensive software reusability plan. Few companies and organizations have anything that even slightly resembles a comprehensive software reusability plan. Although an increasing number of software vendors currently sell tools or components that provide direct assistance for software reuse, the majority of software developers do not use them. Although an increasing number of software vendors currently sell tools or components that provide direct assistance for software reuse, the majority of software developers do not use them. Relatively little training is available to help software engineers and managers understand and apply reuse. Relatively little training is available to help software engineers and managers understand and apply reuse. Many software practitioners continue to believe that reuse is “more trouble than it’s worth.” Many software practitioners continue to believe that reuse is “more trouble than it’s worth.” Many companies continue to encourage of software development methodologies which do not facilitate reuse Many companies continue to encourage of software development methodologies which do not facilitate reuse Few companies provide an incentives to produce reusable program components. Few companies provide an incentives to produce reusable program components.

6. 6 Components Components provide a service without regard to where the component is executing or its programming language Components provide a service without regard to where the component is executing or its programming language A component is an independent executable entity that can be made up of one or more executable objects; A component is an independent executable entity that can be made up of one or more executable objects; The component interface is published and all interactions are through the published interface; The component interface is published and all interactions are through the published interface;

7. 7 Component-based development Component-based software engineering (CBSE) is an approach to software development that relies on software reuse. Component-based software engineering (CBSE) is an approach to software development that relies on software reuse. Components are more abstract than object classes and can be considered to be stand-alone service providers. Components are more abstract than object classes and can be considered to be stand-alone service providers.

8. 8 CBSE essentials Independent components specified by their interfaces. Independent components specified by their interfaces. Component standards to facilitate component integration. Component standards to facilitate component integration. Middleware that provides support for component inter- operability. Middleware that provides support for component inter- operability. A development process that is geared to reuse. A development process that is geared to reuse.

9. 9 CBSE and design principles Apart from the benefits of reuse, CBSE is based on sound software engineering design principles: Apart from the benefits of reuse, CBSE is based on sound software engineering design principles: Components are independent so do not interfere with each other; Components are independent so do not interfere with each other; Component implementations are hidden; Component implementations are hidden; Communication is through well-defined interfaces; Communication is through well-defined interfaces; Component platforms are shared and reduce development costs. Component platforms are shared and reduce development costs.

10. 10 Component as a service provider The component is an independent, executable entity. It does not have to be compiled before it is used with other components. The component is an independent, executable entity. It does not have to be compiled before it is used with other components. The services offered by a component are made available through an interface and all component interactions take place through that interface. The services offered by a component are made available through an interface and all component interactions take place through that interface.

11. 11 Component characteristics 1

12. 12 Component characteristics 2

13. 13 Component interfaces Provides interface Provides interface Defines the services that are provided by the component to other components. Defines the services that are provided by the component to other components. Requires interface Requires interface Defines the services that specifies what services must be made available for the component to execute as specified. Defines the services that specifies what services must be made available for the component to execute as specified.

14. 14 Component interfaces

15. 15 A data collector component

16. 16 Components and objects Components are deployable entities. Components are deployable entities. Components do not define types. Components do not define types. Component implementations are opaque. Component implementations are opaque. Components are language-independent. Components are language-independent. Components are standardised. Components are standardised.

17. 17 Component models A component model is a definition of standards for component implementation, documentation and deployment. A component model is a definition of standards for component implementation, documentation and deployment. Examples of component models Examples of component models EJB model (Enterprise Java Beans) EJB model (Enterprise Java Beans) COM+ model (.NET model) COM+ model (.NET model) Corba Component Model Corba Component Model The component model specifies how interfaces should be defined and the elements that should be included in an interface definition. The component model specifies how interfaces should be defined and the elements that should be included in an interface definition.

18. 18 Elements of a component model

19. 19 Middleware support Component models are the basis for middleware that provides support for executing components. Component models are the basis for middleware that provides support for executing components. Component model implementations provide: Component model implementations provide: Platform services that allow components written according to the model to communicate; Platform services that allow components written according to the model to communicate; Horizontal services that are application-independent services used by different components. Horizontal services that are application-independent services used by different components. To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations. To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations.

20. 20 Component model services

21. 21 Component development for reuse Components developed for a specific application usually have to be generalised to make them reusable. Components developed for a specific application usually have to be generalised to make them reusable. A component is most likely to be reusable if it associated with a stable domain abstraction (business object). A component is most likely to be reusable if it associated with a stable domain abstraction (business object). For example, in a hospital stable domain abstractions are associated with the fundamental purpose - nurses, patients, treatments, etc. For example, in a hospital stable domain abstractions are associated with the fundamental purpose - nurses, patients, treatments, etc.

22. 22 Component development for reuse Components for reuse may be specially constructed by generalising existing components. Components for reuse may be specially constructed by generalising existing components. Component reusability Component reusability Should reflect stable domain abstractions; Should reflect stable domain abstractions; Should hide state representation; Should hide state representation; Should be as independent as possible; Should be as independent as possible; Should publish exceptions through the component interface. Should publish exceptions through the component interface. There is a trade-off between reusability and usability There is a trade-off between reusability and usability The more general the interface, the greater the reusability but it is then more complex and hence less usable. The more general the interface, the greater the reusability but it is then more complex and hence less usable.

23. 23 Changes for reusability Remove application-specific methods. Remove application-specific methods. Change names to make them general. Change names to make them general. Add methods to broaden coverage. Add methods to broaden coverage. Make exception handling consistent. Make exception handling consistent. Add a configuration interface for component adaptation. Add a configuration interface for component adaptation. Integrate required components to reduce dependencies. Integrate required components to reduce dependencies.

24. 24 Reusable components The development cost of reusable components may be higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost. The development cost of reusable components may be higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost. Generic components may be less space-efficient and may have longer execution times than their specific equivalents. Generic components may be less space-efficient and may have longer execution times than their specific equivalents.

25. 25 The CBSE process When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. This involves: This involves: Developing outline requirements; Developing outline requirements; Searching for components then modifying requirements according to available functionality. Searching for components then modifying requirements according to available functionality. Searching again to find if there are better components that meet the revised requirements. Searching again to find if there are better components that meet the revised requirements.

26. 26 The CBSE process

27. 27 The component identification process

28. 28 Component identification issues Trust. You need to be able to trust the supplier of a component. At best, an untrusted component may not operate as advertised; at worst, it can breach your security. Trust. You need to be able to trust the supplier of a component. At best, an untrusted component may not operate as advertised; at worst, it can breach your security. Requirements. Different groups of components will satisfy different requirements. Requirements. Different groups of components will satisfy different requirements. Validation. Validation. The component specification may not be detailed enough to allow comprehensive tests to be developed. The component specification may not be detailed enough to allow comprehensive tests to be developed. Components may have unwanted functionality. How can you test this will not interfere with your application? Components may have unwanted functionality. How can you test this will not interfere with your application?

29. 29 Identifying Reusable Components Is component functionality required on future implementations? Is component functionality required on future implementations? How common is the component's function within the domain? How common is the component's function within the domain? Is there duplication of the component's function within the domain? Is there duplication of the component's function within the domain? Is the component hardware-dependent? Is the component hardware-dependent? Does the hardware remain unchanged between implementations? Does the hardware remain unchanged between implementations? Can the hardware specifics be removed to another component? Can the hardware specifics be removed to another component? Is the design optimized enough for the next implementation? Is the design optimized enough for the next implementation? Can we parameterize a non-reusable component so that it becomes reusable? Can we parameterize a non-reusable component so that it becomes reusable? Is the component reusable in many implementations with only minor changes? Is the component reusable in many implementations with only minor changes? Is reuse through modification feasible? Is reuse through modification feasible? Can a non-reusable component be decomposed to yield reusable components? Can a non-reusable component be decomposed to yield reusable components? How valid is component decomposition for reuse? How valid is component decomposition for reuse?

30. 30 Ariane launcher failure In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off. In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off. The problem was due to a reused component from a previous version of the launcher (the Inertial Navigation System) that failed because assumptions made when that component was developed did not hold for Ariane 5. The problem was due to a reused component from a previous version of the launcher (the Inertial Navigation System) that failed because assumptions made when that component was developed did not hold for Ariane 5. The functionality that failed in this component was not required in Ariane 5. The functionality that failed in this component was not required in Ariane 5.

31. 31 Qualification Before a component can be used, you must consider: application programming interface (API) application programming interface (API) development and integration tools required by the component development and integration tools required by the component run-time requirements including resource usage (e.g., memory or storage), timing or speed, and network protocol run-time requirements including resource usage (e.g., memory or storage), timing or speed, and network protocol service requirements including operating system interfaces and support from other components service requirements including operating system interfaces and support from other components security features including access controls and authentication protocol security features including access controls and authentication protocol embedded design assumptions including the use of specific numerical or non-numerical algorithms embedded design assumptions including the use of specific numerical or non-numerical algorithms exception handling exception handling

32. 32 Adaptation The implication of “easy integration” is: (1) that consistent methods of resource management have been implemented for all components in the library; (2) that common activities such as data management exist for all components, and (3) that interfaces within the architecture and with the external environment have been implemented in a consistent manner.

33. 33 Component composition The process of assembling components to create a system. The process of assembling components to create a system. Composition involves integrating components with each other and with the component infrastructure. Composition involves integrating components with each other and with the component infrastructure. Normally you have to write ‘glue code’ to integrate components. Normally you have to write ‘glue code’ to integrate components.

34. 34 Types of composition Sequential composition where the composed components are executed in sequence. This involves composing the provides interfaces of each component. Sequential composition where the composed components are executed in sequence. This involves composing the provides interfaces of each component. Hierarchical composition where one component calls on the services of another. The provides interface of one component is composed with the requires interface of another. Hierarchical composition where one component calls on the services of another. The provides interface of one component is composed with the requires interface of another. Additive composition where the interfaces of two components are put together to create a new component. Additive composition where the interfaces of two components are put together to create a new component.

35. 35 Types of composition

36. 36 Interface incompatibility Parameter incompatibility where operations have the same name but are of different types. Parameter incompatibility where operations have the same name but are of different types. Operation incompatibility where the names of operations in the composed interfaces are different. Operation incompatibility where the names of operations in the composed interfaces are different. Operation incompleteness where the provides interface of one component is a subset of the requires interface of another. Operation incompleteness where the provides interface of one component is a subset of the requires interface of another.

37. 37 OMG/ CORBA The Object Management Group has published a common object request broker architecture (OMG/CORBA). An object request broker (ORB) provides services that enable reusable components (objects) to communicate with other components, regardless of their location within a system. Integration of CORBA components (without modification) within a system is assured if an interface definition language (IDL) interface is created for every component. Objects within the client application request one or more services from the ORB server. Requests are made via an IDL or dynamically at run time. An interface repository contains all necessary information about the service’s request and response formats.

38. 38 Microsoft COM The component object model (COM) provides a specification for using components produced by various vendors within a single application running under the Windows operating system. COM encompasses two elements: COM interfaces (implemented as COM objects) a set of mechanisms for registering and passing messages between COM interfaces.

39. 39 Sun JavaBeans The JavaBeans component system is a portable, platform independent CBSE infrastructure developed using the Java programming language. The JavaBeans component system encompasses a set of tools, called the Bean Development Kit (BDK), that allows developers to analyze how existing Beans (components) work customize their behavior and appearance establish mechanisms for coordination and communication develop custom Beans for use in a specific application test and evaluate Bean behavior.

40. 40 The Reuse Environment A component database capable of storing software components and the classification information necessary to retrieve them. A library management system that provides access to the database. A software component retrieval system (e.g., an object request broker) that enables a client application to retrieve components and services from the library server. CBSE tools that support the integration of reused components into a new design or implementation.

41. 41 Reuse Economics Quality: 0.9 defects per KLOC for reused code 4.1 defects per KLOC for newly developed code For a project with 68% of reused code, we get 2.0 defects per KLOC and obtain 51% improvement. Productivity: 30 ~ 50% reused can result in productivity improvements in the 25~40% range. Cost: net cost saving = C s - C r - C d C s : the cost of the project if it were developed from scratch C r : the sum of the cost associated with reuse C d : the actual cost of the software delivered

42. 42 CBSE problems Component trustworthiness - how can a component with no available source code be trusted? Component trustworthiness - how can a component with no available source code be trusted? Component certification - who will certify the quality of components? Component certification - who will certify the quality of components? Emergent property prediction - how can the emergent properties of component compositions be predicted? Emergent property prediction - how can the emergent properties of component compositions be predicted? Requirements trade-offs - how do we do trade-off analysis between the features of one component and another? Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?

43. 43 The Difficulties of Components It is possible for application developers to develop software components such as a program segment, a function, or even a class. It is possible for application developers to develop software components such as a program segment, a function, or even a class. In the software industry, a software component either is too simple or has too complicated specifications. In the software industry, a software component either is too simple or has too complicated specifications. If it is too simple, the programmers believe that they can make it by themselves. If it is too simple, the programmers believe that they can make it by themselves. If the specifications are too complex, the situation is that, after understanding the component’s specification, the programmers believe that they can make a better one by themselves. If the specifications are too complex, the situation is that, after understanding the component’s specification, the programmers believe that they can make a better one by themselves. The key difficulty is to make specifications much simpler than the implementation logic. The key difficulty is to make specifications much simpler than the implementation logic.

44. 44 Summary Origin of Software Component Origin of Software Component Component-Based Development Component-Based Development Identification Identification Adaptation Adaptation Composition Composition Standard examples Standard examples Reuse environment Reuse environment Economics of CBSE Economics of CBSE Difficulty of reusable components Difficulty of reusable components