Component-Based Software Engineering Basic Concepts

1. Component-Based Software EngineeringBasic Concepts Dr. Eman M. Saleh Al-Maghary Email: e_saleh@asu.edu.jo – Ext. 1269 SE Department Faculty of Information Technology http://fit.asu.edu.jo – http://OpenCourse.asu.edu.jo

2. Component-Based Software Engineering 1302481 • Prerequisite: 1302386 • Course Description • Text Books: • “Building Reliable Component Based Software Systems, IvicaCrnkovic and Magnus Larsson, Artech House, 2002. • “Software Engineering, Ian Sommerville, 9th Ed., 2012.

3. Lecture Contents • Introduction • Goals and advantages of CBSE • Essentials of CBSE • Components definition and charactestics

4. Introduction • What is this course about ? • A journey in searching for the “holy grail” of software “integrated circuits”

5. Introduction • What is this course about ? • A journey in searching for the “holy grail” of software “integrated circuits”

6. Chapter 17 Software reuse Component-Based Software Engineering • Component-based software engineering (CBSE) is an approach to software development that relies on the reuse of entities called ‘software components’.

7. Chapter 17 Software reuse Component-Based Software Engineering • Component-based software engineering (CBSE) is The process of defining , implementing and integrating (or composing) loosely coupled, independent components into systems.

8. Chapter 17 Software reuse Component-Based Software Engineering • It 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 object classes and can be considered to be stand-alone service providers. They can exist as stand-alone entities.

9. CBSE (Component-Based Software Engineering) Definition • Component-based software engineering (CBSE) is a branch of software engineering, the priority of which is the separation of concerns in respect of the wide-ranging functionality available throughout a given software system • Developing new software from pre-built components. • Attempt to make an association between SE and other engineering disciplines. • It emerged from the failure of object-oriented development to support effective reuse.

10. Reuse via Components Catalogue of software components Customer requirements Component integrator Software application Component Providers

11. Why CBSE • Software systems contain many similar or even identical components that are developed from scratch over and over again has led to reuse existing components (reusability- lower cost) • Structuring a system into largely independent components make it easy to distribute the components among various engineers to allow parallel development (easier management - Work breakdown in PM) • Maintenance: Lower cost of maintenance, easier to replace and upgrade • Better quality and efficiency (next few slides) • Support distributed systems (next few slides) • Time-to-mark (next few slides)

12. Goals of CBSE1: Software construction Application Software construction vs. creation: application is developed as an assembly of “integrated circuits”

13. Goals of CBSE2: Reuse Application1 C1 C1 Application2 C1 Software “integrated circuits” are reusable entities It pays off to have as many applications that reuse an entity

14. Goals of CBSE 3: Maintenance & Evolution C1new C1 Application update Maintenance and upgrading can be done by replacing parts, maybe even at runtime

15. Improve Quality: • Idea: Assuming that a collection of high-quality components is available, assembling these should yield systems of high-quality. 1.The cost of establishing the high quality of components is amortized over multiple use. 2.Multiple use of a component increases the likelihood of finding and removing errors.

16. Time-to-market • If the reuse of a component requires less time than the development of a component, systems can be built faster.

17. Support Distributed system • A computer running several software components is often called an application server. Using this combination of application servers and software components is usually called distributed computing. The usual real-world application of this is in financial applications or business software that is placed in deferent departments and environment (for example, purchasing, sales, HR management ).

18. Integration of heterogeneous sources: • operating systems • programming language • network protocol • data representation

19. Components should provide services to clients running locally or remotely Remote CLIENTS EJB Container EJB Local CLIENTS Remote CLIENTS Remote CLIENTS

20. Chapter 17 sommerville 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 CBSE.

21. Chapter 17 Software 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.

22. Chapter 17 Software reuse 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;

23. Component definitions • 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. • 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.

24. Component Definition (Szyperski)

25. Component Definition (Szyperski)

26. Component Definition (Szyperski)

27. Component Definition (Szyperski) • What is independent deployment? • 􀃆no dependencies on peer-components • 􀃆never partially deployed

28. Chapter 17 Software reuse Component characteristics

29. Chapter 17 Software reuse Component characteristics

30. Chapter 17 Software reuse Component (Models) standards • Standards need to be established so that components can communicate with each other and inter-operate. • Unfortunately, several competing component standards were established: • Sun’s Enterprise Java Beans • Microsoft’s COM and .NET • CORBA’s CCM • In practice, these multiple standards have hindered the uptake of CBSE. It is impossible for components developed using different approaches to work together.

31. Chapter 17 Sommerville 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? • Higher initial cost to build (making it more general, more testing, etc

32. Sommerville,Chapter 17 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. • The component interface is expressed in terms of parameterized operations and its internal state is never exposed.

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

34. Component interfaces Note UML notation. Ball and sockets can fit together.

35. A model of a data collector component

36. Contracts • A more accurate specification of a component's behavior can be achieved through contracts. • A contract is comprised of: • The Invariant, the global constraints which the component will maintain; • The Pre-condition, the constraints which need to be met by the client; • The Post-condition, the constraints which the component promises to establish in return. • A contract specifies the interactions among components, in terms of: • The set of participating components; • The role of each component through its contractual obligations, such as type and casual obligations; • The invariant to be maintained by the components; • The specification of the methods which instantiate the contract.