Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components and Reuse

Components and SW Reusability SW components support “black box” reuse SW components are like black boxes –they encapsulate functionality and provide services through well-defined interfaces Can be reused in many different applications or in building other larger components. Allow cross language reuse. Allow distributing reusable code in an executable format. Source code is not required. Can be interchanged with any other component that provides the same interfaces without breaking the system.

How Components Differ from Objects (1) Components –Can be written in any language –More loosely coupled than objects –Larger granularity than objects –Support multiple interfaces, and interface-oriented design –Support more forms of dynamic binding and dynamic discovery –Have better mechanisms for third party composition –More support for higher order services (security, transactions, etc.) –Designed to obey rules of the underlying component framework

How Components Differ from Objects (2) Objects –Bound to OO languages –Many tight dependencies such as impl. Inheritance, fragile base class –Fine-grained units of composition –Limited forms of connectors (method invocation) –Limited sets of supported services such as security, transactions, etc. –Designed to obey Object-Oriented principles

CBSD and OT (Object Technology) OT is a convenient starting point for CBSD OT does not express the full range of abstractions needed by CBSD It is possible to realize CBSD without employing OT OT is neither necessary nor sufficient for CBSD

CBSD Elements Bus Components Interfaces Component Model Component infrastructure Component Assembly

Software Component A package of software that provides some coherent functionality, can be independently developed and delivered as a unit, and provides its services through well-defined interfaces Adheres to the rules of a Component model

Interfaces (1) An interface is a specification of some behaviour. It contains only operation signatures, no implementation. An interface is a contract between the component and its client. As long as the interface remains the same, the component implementation of an interface can be changed without affecting clients. Programming to Interfaces allow clients to freely interchange components that support the same interface(s).

Interfaces (2) An interface is a collection of logically related operations that define some functionality. Interfaces are the mechanisms by which components describe what services they provide. –Interface description consists of only a specification of the operations. It does not contain any implementation. Interfaces are separated from component implementation of interfaces Client of components need to know only the interfaces of components to use them. –Implementation details of the interfaces by a component are completely hidden from clients.

Typical Component Types (1) UI components/controls: visual representation for business and infrastructure components –widgets, action menus and buttons, icons Business components: cross-organizational streams of activities, tasks and documents –ordering, trading financial instruments, scheduling Foundation components: technical components that provide basic programming and reuse services –linked lists, database index tables, exception handlers

Typical Component Types (2) Data management components: facilities for information exchange between existing application –data exchange and pipeline, format conversion utilities Infrastructure components: processes and entities defining the flow of activities, tasks and documents –files management, performance monitoring, message queuing, fault tolerance

Basic Elements of a Component Model (1) A component model defines standards for Defining interfaces Naming components and interfaces Metadata – information on components, interfaces and their relationships; APIs for accessing such information Interoperability among components – communication and data exchange among components developed by different vendors possibly on different platforms and/or using different languages

Basic Elements of a Component Model (2) Customization of components –Facility for a client to adapt a component prior to its installation or use Composition –Rules for combining components to create larger structures and for substituting and adding components to existing structures Evolution support –Rules and services for replacing components or interfaces by newer versions Packaging and deployment –Packaging implementation and resources needed for installing and configuring a component

Popular SW Component Models Microsoft’s COM (Component Object Model), DCOM, COM+,.NET Framework Sun’s JavaBeans, EJB (Enterprise Java Beans), J2EE specification OMG’s CORBA (Common Object Request Broker Architecture) specification

Component Infrastructure Provides components with services to –find components connected to the infrastructure –make reference to other components using some meaningful naming scheme –guarantee once-only delivery of messages between components –manage transactions consisting of multiple interactions among components –allow secure communication between components

Component Assembly Concerns how an application is composed and built from components First the Application architecture is designed –it describes the design of the application in terms of components –what interfaces are used –how components interact (via calls on operations on interfaces) to realize application functions The Application is then composed by wiring (connecting) together components Visual Application Builder tools make composing component-based applications easy –Examples: Visual Basic IDE, Sun’s BeanBox, etc. FINE