Component Based Software Engineering

1. Component Based Software Engineering

2. What is Software Component • Have you Seen Software Component • Have You used Software Component • Have You Develop Software Component

3. Observations on the practice of SE • Systems should be built to facilitate change • easy removal and addition of functionality • It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.--Charles Darwin • About 80% of software engineering deals with changing existing software • Time to market is an important competitive advantage: incorporate successful innovations quickly

4. Problems of Software Engineering •The size & complexity of software increases rapidly •Single products become part of product families •Software is upgraded after deployment •The time-to-market must decrease significantly •The cost of products must be reduced

5. Consider this Scenario • You created a Chat component and it took you one week • Your friend told you that he his build a Chat component for his application • You told him that he can reuse it • He copied and pasted it • More people are now interested • You make email code along with a text file conations info on how to deploy and use (method names, functions, etc • More people outside your company so you need to make it according to a .Net standard COM

6. What is Software Component • An individual component is a software package, or a module, that encapsulates a set of related functions (or data). • All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). • Because of this principle, it is often said that components are modular and cohesive.

7. Component Definition • Components offering (via an interface) a predefined service and which is able to communicate with other components (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;

10. What is independent deployment? • 􀃆no dependencies on peer-components • 􀃆never partially deployed

11. Components general attributes • Non-context-specific: General • Composable with other components (May consist of other components) • Encapsulated (Uses precisely-defined interfaces to communicate with other components) • Represents one or more logical or organization-related processes or tasks (for example, purchasing, sales or management of master data) • Is more coarse-grained than single classes; in other words, a component usually consists of several logically coherent classes • Is unique from other components because a class can be assigned only once to a component. • Is independent of the release (components can be upgraded and distributed) and can be delivered separately • Frameworks form the underlying technology for components

12. 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.

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

14. 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)

19. 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.

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

21. 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 ).

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

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

24. CBSE problems • Higher initial cost to build (making it more general, more testing, etc • Component certification - who will certify the quality of components? • Requirements trade-offs - how do we do trade-off analysis between the features of one component and another? When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. • software development organizations and information services (IS) departments are often in competition with closely guarded proprietary processes.

25. Trust-based Certification

26. Background on Software CBSE • Since early 1990’s, so-called Componentware or Component-Based Software Engineering (CBSE) have emerged • However, the use of COTS (Commercial Off-The-Shelf) software promoted the CBSE in the development business applications. • Furthermore, quick evolution of the Internet technology such as Web and Java-based technologies even open up new possibilities of CBSE such as network distribution of components, and the reuse and interoperation of components over the Internet. • Now, a few set of technologies have been widely deployed and are still evolving. They include ActiveX/DCOM from Microsoft. CORBA from OMG and JavaBeans from SUN Microsystems. • Components are considered to be part of the starting platform for service orientation throughout software engineering, for example Web Services, and more recently, Service-Oriented Architecture (SOA) - whereby a component is converted into a service

27. Time Line Cloud Computing Web Services RMI DCOM C O V E R A G E MOM CORBA RPC Subroutine 1970’s 1980’s 1990’s 2000

30. If you have used visual component assembly tools such Visual Basic, you are familiar with the notion of software components. • Custom controls are packaged with design-time information (properties and methods) that allow builder tools to determine their capabilities. (which allows builder tools to query components and ask them what kinds of properties they define, as well as what kinds of events they can generate or respond to) • Design time allows Customization (e.g. change color, height) • Run time allows only execution (e.g click button)

31. For example, the builder tool above shows a calculator component that is built from • 16 button components, • a text field component • and a panel upon which the buttons and a text display are placed. • you can see five invisible components. These specific components • hold values or strings used by the calculator for intermediate calculations, • operation codes, • display strings, • as well a boolean flag to • determine when evaluation of • a new expression is started. Components can be nested. For example, a calculator built from components becomes, itself, a component. Custom-built components are easily added to builder tool palettes.

32. More complex components include barcharts

33. Identifying Business Components Business Component represent the key business concepts supported by the system, including real-word objects (e.g. ‘customer’, ‘account’, ‘product’) and real-world transactions (e.g. ‘booking’, ‘deposit’, ‘order’).

34. Components and objects • Components are more abstract than objects and can be considered to be stand-alone service providers. • scale reusable entities: Component = many objects in collaboration • Single object classes are too detailed and specific to be reused. • Components are deployable entities. • Components do not define types. • Component implementations are hidden. • Components are language-independent. • Components are standardised.

35. Component Abstractions • Functional Abstractions • component implements a single function • component is part of a loosely related functions (add student, add account, add book, etc) • Can be obtained from Requirement Specification Document • Data Abstractions • abstract data types or objects • Can be obtained from ERD or Database Schema • Cluster Abstractions • component from group of cooperating objects • Can be obtained from Class Diagram • System Abstraction • component is a self-contained system • Can be obtained from Structural Chart Diagram

36. CBSE vs. Traditional SE • CBSE views the system as a set of off-the-shelf components integrated within an appropriate architecture. • SE seeks to create a system from scratch.

37. CBSE vs. Traditional SE-cont.. • CBSE does not have any standard development models like UML for SE. • CBSE is young, therefore long term maintainability is largely unknown. • SE can fulfill requirements more easily. • CBSE fulfillment of requirements is based on the available components. [4]

38. CBSE vs. Traditional SE-cont.. Outline Requirement • Process starts by Developing outline requirements; before Searching for components then usually modifying these requirements according to available functionality

39. 3- Component Creating process Component Specification • A component producer starts by identifying the discrete requirements of the component specification. • more component specification may come from the component producer's desire to provide a generic component • As well as the customer's component specification, there may also be industry standards to apply which map to the concepts of quality, performance, error handling. • Typically, the design and development of the internals of the component will be carried out using techniques such as the Unified Modeling Language (UML)

40. Component Implementation • Tools for design and code generation may be used within a specific framework . E.g. .NET. • Testing, debugging, and compilation generally are applied. • Component Deployment • The producer will need to publish accurate information about a component, such as its available interfaces and its services (this can be done by using the framework wizard.

41. Commercial Off-the-Shelf Software repository • COTS repository usually have a complete applications library the offering an applications programming interface (API) • Building large systems by integrating COTS components is a viable development strategy for some types of systems (e.g. E-commerce or video games) • What do thing the component entry page look like ?

43. Background on Software CBSE

44. Component Warehouse • reuse before you buy, and before you build. • Warehouse organization is important, as cataloguing helps to manage and locate components. • software components, required information, often referred to as meta data • Metadata is a component description in a form of XML ( safety, accessibility ) representation in a standard way • The standard is a way to support multiple sites and interacting levels of warehouses integration

45. 3 invoke XML XML XML Metadata Metadata Metadata CCI CCI CCI DB ERP CRM SC Provider SC Provider SC Provider <Title ="CIFP"> <Description=“this component is"> <service id="exampleService"> <service type="void"/> <category t="0.01s"/> </service> </Description> </title> Consumer Search Engine

46. COTS Integration Problems • Lack of developer control over functionality and performance • Problems with component interoperability as • COTS vendors make different user assumptions • COTS vendors may not offer users any control over the evolution of its components • Vendors may not offer support over the lifetime of a product built with COTS components

47. Legacy system componentization • Existing legacy systems that fulfil a useful business function can be re-packaged as components for reuse. • This involves writing a wrapper component that implements provides and requires interfaces then accesses the legacy system. • Although costly, this can be much less expensive than rewriting the legacy system. • Only a top-down, shallow understanding of the existing system is required.

48. Add a new component layer to the existing system without change to the underlying source code. • Break one big black box into a number of smaller conceptual black boxes, each representing a high-level business component and business services. • Present the existing system to the outside world as a number of software components.