Download
1 / 44
440 likes | 594 Views
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. Lecture 17 Component-Based Software Engineering Ref. Chap. 30.
E N D
COSC 4406Software 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
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 • 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.
The Key Questions • When faced with the possibility of reuse, the software team asks: • Are commercial off-the-shelf (COTS) 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? • At the same time, they are faced with the following impediments to reuse ...
Impediments to Reuse • 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. • 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 companies continue to encourage of software development methodologies which do not facilitate reuse • Few companies provide an incentives to produce reusable program components.
Components • 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; • The component interface is published and all interactions are through the published interface;
Component-based development • 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.
CBSE essentials • Independent components specified by their interfaces. • Component standards to facilitate component integration. • Middleware that provides support for component inter-operability. • A development process that is geared to reuse.
CBSE and 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; • Component implementations are hidden; • Communication is through well-defined interfaces; • Component platforms are shared and reduce development costs.
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 services offered by a component are made available through an interface and all component interactions take place through that interface.
Component interfaces • Provides interface • Defines the services that are provided by the component to other components. • Requires interface • Defines the services that specifies what services must be made available for the component to execute as specified.
Components and objects • Components are deployable entities. • Components do not define types. • Component implementations are opaque. • Components are language-independent. • Components are standardised.
Component models • A component model is a definition of standards for component implementation, documentation and deployment. • Examples of component models • EJB model (Enterprise Java Beans) • COM+ model (.NET model) • Corba Component Model • The component model specifies how interfaces should be defined and the elements that should be included in an interface definition.
Middleware support • Component models are the basis for middleware that provides support for executing components. • Component model implementations provide: • Platform services that allow components written according to the model to communicate; • 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.
Component development for reuse • 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). • For example, in a hospital stable domain abstractions are associated with the fundamental purpose - nurses, patients, treatments, etc.
Component development for reuse • Components for reuse may be specially constructed by generalising existing components. • Component reusability • Should reflect stable domain abstractions; • Should hide state representation; • Should be as independent as possible; • Should publish exceptions through the component interface. • 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.
Changes for reusability • Remove application-specific methods. • Change names to make them general. • Add methods to broaden coverage. • Make exception handling consistent. • Add a configuration interface for component adaptation. • Integrate required components to reduce dependencies.
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. • Generic components may be less space-efficient and may have longer execution times than their specific equivalents.
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.
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. • Requirements. Different groups of components will satisfy different requirements. • Validation. • 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?
Identifying Reusable Components • Is component functionality required on future implementations? • How common is the component's function within the domain? • Is there duplication of the component's function within the domain? • Is the component hardware-dependent? • Does the hardware remain unchanged between implementations? • Can the hardware specifics be removed to another component? • Is the design optimized enough for the next implementation? • Can we parameterize a non-reusable component so that it becomes reusable? • Is the component reusable in many implementations with only minor changes? • Is reuse through modification feasible? • Can a non-reusable component be decomposed to yield reusable components? • How valid is component decomposition for reuse?
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. • 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.
Qualification Before a component can be used, you must consider: • application programming interface (API) • 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 • service requirements including operating system interfaces and support from other components • security features including access controls and authentication protocol • embedded design assumptions including the use of specific numerical or non-numerical algorithms • exception handling
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.
Component composition • The process of assembling components to create a system. • Composition involves integrating components with each other and with the component infrastructure. • Normally you have to write ‘glue code’ to integrate components.
Types of composition • 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. • Additive composition where the interfaces of two components are put together to create a new component.
Interface incompatibility • 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 incompleteness where the provides interface of one component is a subset of the requires interface of another.
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.
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.
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.
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.
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 = Cs - Cr -Cd • Cs: the cost of the project if it were developed from scratch • Cr: the sum of the cost associated with reuse • Cd: the actual cost of the software delivered
CBSE problems • Component trustworthiness - how can a component with no available source code be trusted? • Component certification - who will certify the quality of components? • 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?
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. • 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 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.
Summary • Origin of Software Component • Component-Based Development • Identification • Adaptation • Composition • Standard examples • Reuse environment • Economics of CBSE • Difficulty of reusable components
