Components and SW Reusability

1
(No Transcript)
2
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.

3
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

4
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

5
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
6
CBSD Elements

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

7
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

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

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

10
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

11
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

12
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

13
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

14
Popular SW Component Models

• Microsofts COM (Component Object Model), DCOM,
  COM, .NET Framework
• Suns JavaBeans, EJB (Enterprise Java Beans),
  J2EE specification
• OMGs CORBA (Common Object Request Broker
  Architecture) specification

15
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

16
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, Suns BeanBox, etc.