Component Based Design and Reuse

屈建勤， 蔡浩
Components
 Many software managers envy hardware engineers
because of the ease in which they can construct
products from pre-existing components
 For example, electronic systems are built by plugging
together chips, boards or boxes that are widely interoperable
 A well-chosen set of components can have many possible
configurations, resulting in end products that can be made
quickly and reliably
 Over the last few years, the same thing has begun to
happen in software: word processors can talk to
spreadsheets, and graphs to databases, etc.
 Standards such as COM and CORBA permit components to
be `plugged together' in different languages and platforms
Component based development
 Component based development (CBD) is a buzz
word for the new millennium. However, how do
components differ from modules and objects?
 Some basic definitions:
Component based development: An approach to
software development in which all artefacts can be
built by assembling, adapting and "wiring" together
existing components in a variety of configurations
Component: A coherent package of software
artefacts that can be independently developed and
delivered as a unit and that can be composed with
other components to build something larger
Examples
 All the following conform to the above definitions:
 Using some user interface widgets, such a list boxes,
and connecting them to appropriate data sources
 Using a collection class in Java
 Using an off the shelf calendar package, word
processor and spreadsheet in an assemblage of
several components and writing scripts to link them
together
 Using a class framework, such as Java's Swing
components, to build the user interfaces for many
applications
 Using predefined language constructs, e.g. for (...) {...}
Implementation Components
 Although components can be artefacts at any level of
abstraction, it is most common to think of them at the
software level.
 In this case, a component is viewed as:
 a coherent package of software implementation that:
 can be independently developed and delivered (even sold!)
 has explicit and well-specified interfaces for the services it
provides
 has explicit and well-specified interfaces for services it expects
from others
 can be composed with other components, perhaps customizing
some of their properties, without modifying the components
Component Interfaces

Requires interface Component Provides interface

Component composition
 To assemble a larger component or
application the composer of a component:
 selects which component to compose
 connects required interfaces of one component to
provided interfaces of other component to plug
them together
 perhaps writes some glue using scripting or
adapters between components
 Note that composites often provide standard
service to expose their child structure at run-time
Components and binding
 Components are designed and built in one activity,
they are composed with other in a separate step.
 This can happen at:
 Coding time
 Compile time
 Link time
 Link time using dynamic linking (DLL's)
 Runtime
 Runtime using reflection
 The later that binding occurs, the more flexibility there
is in allowing composition of components.
Reflection
 Reflection is particularly interesting. It allows
components to dynamically query other
components services and invoke them.
 This gives the maximum degree of flexibility
in composing components.
 Reflection is very well supported by Java and
Smalltalk.
Components and standards
 If we are to build systems by assembling components, we need a set
of standards so that components can easily interoperate
 Some typical issues are those relating to interaction mechanisms,
security, distributed transactions and repositories.
 Some common implementation and definitions of such standards
include:
 Java Beans - used to build components in Java which permits
reflection of Java components
 Enterprise Java Beans - let you implement business functions as
Java Beans and then provides standard means of distributed these
functions across networks and distributed repositories
 COM/DCOM/COM+ - Microsoft's standard library of interface
mechanisms for components
 CORBA (Common Object Request Broker Architecture) – permits
open distributed communication between components across a wide
variety of platforms and languages. It is particularly widely used in
the banking/business sectors
 All of these have large books written about them!
CORBA
 CORBA is an international standard for an
Object Request Broker - middleware to
manage communications between distributed
objects
 CORBA objects can be viewed as components
 Several implementations of CORBA are
available
 DCOM is an alternative approach by Microsoft
to object request brokers
 CORBA has been defined by the Object
Management Group
CORBA Objects
 CORBA objects are comparable, in principle,
to objects in C++ and Java
 They MUST have a separate interface
definition that is expressed using a common
language (IDL) similar to C++
 There is a mapping from this IDL to
programming languages (C++, Java, etc.)
 Therefore, objects (components) written in
different languages can communicate with
each other
Object Request Broker
 The ORB handles object communications. It
knows of all objects in the system and their
interfaces
 Using an ORB, the calling object binds an IDL
stub that defines the interface of the called
object
 Calling this stub results in calls to the ORB
which then calls the required object through a
published IDL skeleton that links the interface
to the service implementation
Object Communication

o1 o2

S (o1) S (o2)

IDL IDL
stub skeleton

Object Request Broker

CORBA Services
 Naming and trading services
 These allow objects to discover and refer to other
objects on the network
 Notification services
 These allow objects to notify other objects that an
event has occurred
 Transaction services
 These support atomic transactions and rollback on
failure
Benefits of components
 Components form a basic unit for maintenance and
upgrading:
 Using components there should no longer be a need to
upgrade entire "systems". Instead, components get replaced
or added as required.
 Partitioning systems up into components enables parallel
development
 Interface-centric design gives scalable and extensible
architectures
 Components offer greater scope for standardisation, and
this benefits the development of systems (no need to keep
re-inventing the wheel as basic services are already built
into standards)
Reuse
 One of the most compelling reasons for
adopting component based development is
the promise of reuse
 In its broadest sense reuse = any situation in
which work done for one project is used to
help another
 Some questions:
 What can be reused and how?
 Why reuse?
 Why is reuse hard?
 Which components are generally reusable?
What can be reused, and how?
 The following are all things that can be
reused:
 Specifications
 Architecture
 Code
 Designs
 Documentation
 Tests
 Most effort has been geared towards reusing
single classes.
 For example, class libraries.
Why reuse?
 The bottom line is to save money. Reuse has the
benefit of:
 saving developers time.
 making products more reliable (someone else has ironed out
the bugs in the component already).
 reducing market cycle time. Faster product development is
essential in allowing a company to exploit new areas of work
quickly.
 encouraging developers to focus on the design of the
system as opposed to how it is to be implemented.
 this in turn can lead to more interesting and rewarding work
(not just programming all the time), which is good for
employer and employee.
 encouraging the development of more maintainable
systems.
Why is reuse difficult?
 Imagine you are a developer wishing to reuse
components:
 Even if a components exists, can you find it?
Large component libraries are hard to search.
 How can you be sure that the component will do
what you want? If it does not (highly likely) you will
need to adapt it (but how?)
 Do you trust it? How can you be sure it will do
what is claimed for it?
Frameworks
 Another widely used approach to reuse is the
frameworks approach
 A framework is a concrete, yet incomplete,
design of a system or software architecture
 Frameworks provide plug-in points for adding
concrete classes
Example – operating system framework
1 OperatingSystem
0..*
1
1 1
ProcessGroup
maximumPriority()

1 1..*
1
Kernel
1..* Resource
Bootstrap Loads
maxUsers : int
SystemProcessGroup UserProcessGroup 1 1 loadModule(m: Module)() 1 Controls Allocation of
unloadModule(m: Module)()
1 1
1
Controls, Allocates
Resources to CPU
Module I/O Device Memory
0..* kernelMode : Boolean
programCounter : long size : int
GeneralProcess
processID : int loadContext (pc : processContext)()
priority : int TemporaryMemory
programCounter : long Owns PermanentMemory
freeSpace : long
creationTime : long creationDate : date
usedSpace : long
CPUTimeUsed : long 1 1..*
IOTimeUsed : long
registerList : RegisterList 1 I/O Module

1
0..*
0..*
SystemProcess UserProcess
1
1..*
Note: I/O is given as an example. Kernel
I/O Policy 1 1..* I/O Mechanism will also include Scheduler Module,
Process Communication Module etc.
Uses to action Policy

Difference between System

Process and UserProcess is
System processes may execute in
"Kernel" Mode, defined by the Plug-point
ProcesGroup they belong to.
Components and OO
 What difference does OO make?
 Components need not be implemented using
OO, but it helps!
 OO provides facilities for describing interfaces
(methods) and plug-ins (subclassing of abstract
classes).
 it also emphasises high cohesion/low coupling,
which is important in building components.
Future
 Components are becoming an increasingly important
part of software engineering
 In fact they are a whole area of study in themselves
 Their use recognises the fact that system are no
longer built from scratch, and that reusing existing
components can save time and money
 While most CBD focuses on program components, it
is likely that more and more people will begin looking
at the reuse of other artefacts, e.g. specifications, in
the future
Bibliography
 Some useful books on CBD and reuse are:
 D'Souza and Wills: Objects, Components and
Frameworks with UML, Addison-Wesley,
1999.
 Ivar Jacobson: Software Reuse : Architecture
Process and Organization for Business
Success, Addison-Wesley 1997.
 Richard Monson-Haefel, Enterprise
JavaBeans. O-Reilly, 1999
 A source of online software components:
http://www.componentsource.com/