ComponentBased Software Development

1
Component-Based Software Development
2
Why Components?

• Contemporary context of enterprise software
• large, complex distributed systems
• shared use of preexisting software and data
  assets
• changing requirements
• short development schedules
• incremental and decentralized development
• economic pressures to increase productivity
• Creates needs
• strong encapsulation ( information hiding )
• easy reuse, composition, and replacement of
  modules
• persistence, transactions, security etc.

3
Encapsulation (Information Hiding)

• The implementation of a component should be
  separated from its interface and hidden from the
  clients of the component.
• The interface specifies what operations the
  component does, not how the component carries out
  those operations.

4
What is a Component?

• George T. Heineman and William T. Councill
• A software component is a software element that
  conforms to a component model and can be
  independently deployed and composed without
  modification according to the composition
  standard.
• Clemens Szyperski
• A software component is a unit of composition
  with a contractually specified interface and
  explicit context dependencies only. A software
  component can be deployed independently and is
  subject to composition by third parties.

5
Software Component
required interfaces
required interfaces
provided interfaces
provided interfaces
interface
Component implementation
Component1
Component2
6
Interfaces

• Provided interface component contains an
  implementation of all operations defined by that
  interface
• Required interface component requests an
  interaction defined in that interface and expects
  another component to support that interface

7
Component Model

• Component model defines specific interaction and
  composition standards.
• Example Enterprise Java Beans
• Component model implementation is the dedicated
  set of executable software elements required to
  support the execution of components that conform
  to the model.
• Example JBoss EJB application server

8
Component Model (contd.)

• Operates on two levels
• - defines how to create individual component
• - enforces behavioral rules for interaction of
  components within system
• Defines mechanisms for creating connections among
  components
• Specifies customization mechanisms to extend
  components without modification
• Defines coding formats and documentation
  standards
• Responsible for transactions and persistence in
  components

9
Component Model Implementation

• Consists of the software elements necessary to
  support execution of components within a
  component model
• Executes as thin layer on top of OS
• Allows execution of components conforming to the
  component model
• Based on a particular component model
• Example JBoss application server for Enterprise
  JavaBeans

10
Interaction Standard

• Specifies the types of context dependencies that
  a component may have
• Defines an interface standard the component must
  follow

11
Context Dependencies

• Explicitly specify all assumptions about
  components execution environment
• operating system
• processor architecture
• external devices
• other software systems (e.g. database systems)
• other components or libraries
• performance expectations
• data files, etc.

12
Interface Standard

• Gives mandatory requirements employed to enable
  software elements to interact directly
• Declares of what an interface can consist
• Specifies information that can cross the
  interface boundary
• - syntax
• - semantics

13
InterfaceSyntax and Semantics

• Syntax structure of the information
• in Java, public method signatures and public
  variables
• Semantics functionality (meaning) of the
  operations
• pre-conditions, post-conditions, invariants,
  etc.

14
InterfaceDesign by Contract

• Precisely specify WHAT an interface must do
• Separate consideration of HOW it is implemented
• Helps develop components that are
• Reliable
• Pluggable into component framework

15
InterfaceDesign by Contract

• Semantics of Operations
• Pre-conditions for correct use
• Assumptions that must be satisfied for correct
  use
• For example, valid range for argument values
• Post-conditions for correct result
• Minimum output expected
• For example, how the value returned relates to
  argument values
• Invariants for consistent state
• - Holds before and after operations

16
Composition Standard

• Composition When two or more components are
  combined together, they yield component behavior
  at a different level of abstraction
• Composition standard
• - Specifies rules for composition
• - Indicates replacement policy

17
Component and Object Comparison
18
Objects

• Entities that encapsulate state and behavior and
  have a unique identity
• Behaviors and structures defined by classes that
• Implement concept of abstract data type (ADT)
• Provide abstract descriptions of behavior of
  objects
• Provide concrete implementation of object
  behavior
• Enable creation of objects instances of the
  class

19
Component and Object Similarities

• All component models based on the object-oriented
  programming paradigm
• Components define object behavior and create
  objects component instances
• Both make functionality available through
  abstract behavior descriptions called interfaces

20
Component and Object Differences

• Implementation of component is generally
  completely hidden and sometimes only available in
  binary
• Component may be implemented in many ways single
  class, multiple classes, or traditional
  nonobject oriented procedures
• Component names not used as type names. Type and
  implementation completely separated
• Components conform to standards defined by
  component model

21
Basic Elements of Component Model
22
Basic Elements of Component Model (contd.)
23
Basic Elements of Component Model (contd.)
24
Basic Elements of Component Model (contd.)
25
Interface

• Specifies component behavior and properties using
  an Interface Description Language (IDL)
• Serves as contract between component and its
  clients.
• Specifies services a client may request from a
  component. The component provides an
  implementation of these services
• Includes constraints on usage of these services
• Interface specifications are a central element in
  a component model.
• Consists of the elements
• Name of each operation
• Parameters of each operation
• Type of each parameter
• Return type for each operation

26
Naming

• Globally unique names for names for interfaces
  and components
• Naming schemes
• - Unique identifiers
• Generated by tools that use combination of
  specific data to guarantee uniqueness
• For example, Global Unique Ids (GUIDs) used by
  COM/DCOM/COM
• Hierarchical name spaces
• Guaranteed to be unique if top-level names are
  uniquely registered with global naming authority.
• For example Java-based components

27
Meta Data

• Information about components, interfaces, and
  their relationships API to services providing
  such information
• Many ways of providing metadata
• -Interface and implementation repositories
• CORBA-based systems
• -Type libraries
• COM-based systems
• -Introspection
• Java-based systems

28
Interoperability

• Communication and data exchange among components
  from different vendors, implemented in different
  language
• For example, Enterprise Java Beans written in
  Java, can be deployed across various platforms
  and application servers
• Remote interoperability based on remote procedure
  calls (RPCs)
• For example, Simple Object Access Protocol (SOAP)
  for Windows, Remote Method Invocation (RMI) for
  Java- based systems, serve as remote method
  specifications

29
Customization

• Interfaces for customizing components. User
• friendly customization tools will use these
• interfaces.
• For example,
• Two similar EJB components can be customized
  differently by using different deployment
  descriptors for each component

30
Composition

• Interfaces and rules for
• combining components to create larger structures
• substituting and adding components to existing
  structures.
• registration of component with component/service
  for notification of pre-defined events
• Component composition is combination of two or
  more software components that yields a new
  component behavior
• Basic types of component interactions
• Client/server remote method invocation
• Publish/subscribe
• Messaging
• Glue languages
• Support component composition at a higher level
  of abstraction than all-purpose programming
  language
• Disadvantage of composition language
• Glue code has to be written or graphically
  specified from inception

31
Evolution Support

• Rules and services for replacing components or
  interfaces by newer versions.
• New version may have different implementation or
  provide extended or new interfaces
• Ideally existing clients should be minimally
  affected by later versions

32
Packaging and Deployment

• Packaging implementation and resources needed for
  installing and configuring a component.
• For example, a deployment descriptor provides
  information about contents of the package and
  deployment information

33
Component Infrastructure

• Design
• separation of concerns
• avoidance of unnecessary coupling between
  components
• introduction of layers with different preset
  responsibilities
• change in one layer independent of other layers
• Common Layers
• User interface
• User dialog
• System services
• Business services

34
Layered Architecture of Component Infrastructure
35
References

• This presentation was based on
• George T. Heineman and William T. Councill.
  Component Models and Component Services
  Concepts and Principles, Component-Based
  Software Engineering Putting the Pieces
  together, Addison Wesley, 2001.
• J. Cheesman and J. Daniels. UML Components A
  Simple Process for Specifying Component-Based
  Software, Addison Wesley, 2001.