Lesson 2 – Components and Reuse

Software Engineering Module 1 - Components Teaching unit 3 – Advanced development

Ernesto Damiani

Free University of Bozen - Bolzano

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

• Bus Components • Interfaces • Component Model • Component infrastructure • Component Assembly

CBSD Elements

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