An Introduction to
Component Software
Robert Gallup
MSCS Candidate
Union College
16 May 2003
Agenda
•
•
•
•
•
Introduction
Software Components
Component-Based Development
Conclusion
Questions / Discussion
Introduction
Traditional Software
Custom-Made
•
Developed entirely from scratch
•
Advantages
•
– Uses only programming tools and
libraries
– May provide a competitive edge, as
it is optimized for a user’s business
model
– Takes advantage of In-House
proprietary knowledge or practices
Standard
•
Outsourced
•
•
•
Produced for a mass market
Strong trend toward Standard SW
Advantages
•
Disadvantages
Disadvantages
– Very expensive
– Often provides sub-optimal
solutions
– High risk of failure
– No guarantee of interoperability
with customers or business partners
– Standard software is purchased,
then modified to provide a solution
that is ‘close enough’ to what is
needed
– Can be parameterized to closely
match customer’s needs
– Retires Time-to-Market Risk
– Does not offer a competitive edge,
it’s available to competitors as well
– Cannot be quickly adapted to
changing needs
Traditional Software
Problems with Large Software Projects
• 1 in 3 Projects Cancelled Prior to Completion
• Average Project Suffers Schedule Overrun of 50%
• 1 in 8 Completed Projects Considered to be Successful
• 75% of Projects Fail to Perform According to Customer’s Requirements
Component Software
• Represents a Middle-Path between Custom and Standard
Software Development
• Makes it Easier to Customize Standard Software
• Component Assembly Allows Individual Price/Performance
Tradeoff Choices
• May be Combined with Custom-Made Components
• Eliminates the Need for Massive Upgrade Cycles
Software Components
Software Component: Executable unit of independent production,
acquisition, and deployment that can be composed into a functioning
system
Component Software: Composite systems composed of software
components
Current Technologies:
–
–
–
–
OMG CORBA
Microsoft COM, OLE, and ActiveX, Visual Basic
SUN JavaBeans, EJBs
Modern Operating Systems
• Sharing of File Systems, Common File Formats, use of Pipe and Filter
Composition
– Netscape and Plug-Ins (ie: Apple Quicktime)
– Applets
Spectrum Between Make-All
and Buy-All
Flexibility,
nimbleness,
competitive edge
Cost Efficiency
0
Custom
% Bought
100
Standard
Component Software Allows Customers to Set Priorities Based on
Budget Restraints, Performance Requirements, etc.
Analogies
Component Software Comparisons to Other
Engineering Disciplines
• Computer Hardware
– Integrated Circuits (Software IC)
– Plug and Play Technology
• Audio Equipment
• Mechanical Engineering
– Gears, nuts, and bolts
Why is Software Different?
• Software delivers a ‘blueprint’ for products, not the product itself
• Computers instantiate software blueprint
Component-Based
Development
Component Characteristics
• Unit of Deployment
– Isolatable part of a system
– Well separated from it’s environment and from other components
– Never partially deployed
• Unit of Third-Party Composition
– Components must interact through a well-defined interface
• Has No Persistent State
– Ex: Database server = component, database = object
• Typically Consists of a Collection of Related Classes
– May consist of a single class, but rare
– May contain traditional procedures and global variables
– May be implemented using functional languages, assembly language, or
any other approach
– A component’s objects may be visible to clients (usually other
components)
Client Access to Components
Component A
Client of A
• Component A consists
solely of objects, of which
A’s client has access to 2
Client of B
• Component B consists
solely of traditional
procedures (& possibly
global static variables)
Client of C
• Component C combines
objects & traditional
procedures. Client has
access only to objects &
cannot recognize that C is
“all O-O inside”
Object a
Object b
Object c
Component B
Procedure a
Procedure b
Procedure c
Component C
Object a
Object b
Procedure a
Components vs. Objects
• What is a Component?
– Characteristic properties
• a component is a unit of independent deployment
• a component is a unit of third-party composition
• a component has no persistent state
• What is an Object?
– Characteristic properties
• an object is a unit of instantiation; it has a unique identity
• an object has a state; this state can be a persistent state
• an object encapsulates its state and behavior
Blackbox vs Whitebox Abstraction
Visibility of an Implementation Behind it’s Interface
• Blackbox Abstraction
– Clients know only the interface and it’s specification
• Whitebox Abstraction
– The interface may still enforce encapsulation and limit
what clients can do
– Implementation is fully available
• Glassbox Abstraction
– Implementation details may be viewed only, not modified
• Graybox Abstraction
– A controlled part of their implementation is available
Blackbox vs Whitebox Reuse
• Blackbox Reuse
– Reuses implementations relying on nothing but their
interfaces and specifications
• Example: Application Programming Interfaces (APIs)
• Whitebox Reuse
– Uses a software fragment through it’s interfaces
– Relies on information gained from studying the actual
implementation
• Example: Class libraries and Frameworks
Component Interfaces
• A Component Interface Provides the Means for Components
to Connect
– Technically, it is a group of related functions that can be
invoked by clients
– Every operation must be specified
• The specification serves both providers implementing the
interface and clients using the interface
– A component may contain multiple interfaces
– An interface should be viewed independently of any
component that may implement or use it
• Terminology
– Provider – The component that implements the operations of
an interface
– Client – The user of the services provided by an interface
Interface Specification
• The Semantics (Behavior) of Each Operation in an Interface
is Given by a Specification
• This Specification Serves Both the Provider and the Client
– ie.:
• Provider – Specification defines the requirements for the behavior
to be implemented within the provider component
• Client – Specification defines the behavior that can be expected
from interactions with the Provider’s interface
• Interfaces are Specified Using an IDL (Interface Definition
Language)
– Current competitors:
• OMG IDL
• COM IDL
Direct and Indirect Interfaces
• Direct Interface
– Provided directly by a component
– Corresponds to procedural interfaces of traditional
libraries
• Indirect Interface
– Provided by objects made available to clients by a
component
– Corresponds to object interfaces
Direct and Indirect Interfaces
Direct Interface
Client of A
Component A
Procedure A
Procedure B
Procedure C
Indirect Interface
Client of B
Component B
Object B
Method B.a
Method B.b
Interfaces as Contracts
Interface Specifications Between Provider and Client
• Contracts State What a Client Needs to do to Use
an Interface
• Also State What Providers Must Implement to Meet
Services Promised by the Interface
• A Popular Method: Specifying Pre-Condition and
Post-Condition Specifications for an Operation
– Hoare triple convention:
• {precondition} operation {postcondition}
– Dijkstra’s weakest preconditions convention:
• wp(S,Q)
– wp = weakest precondition for which execution of S is
guaranteed to terminate while meeting postcondition Q
Pre and Post Conditions
• Specification of the Form: pre U, post V
– Means: Condition U must be satisfied by client upon method entry,
and condition V will be satisfied by provider upon method exit:
• Usually Specified Using Predicates
• Example: Queue interface
interface Queue {
boolean empty();
}
Queue enq(Object X);
@post { !this.empty() }
Post condition: Queue must not be empty after
executing enq()
Queue deq();
@pre { !this.empty() }
Pre condition: Queue must not be empty
before executing deq()
Substitutability
Ability of a Component B to Replace Component A Without
Breaking A’s Client(s)
• An Interface Must be Specified Carefully
– Should not require too much or too little from clients/providers
• ie: An interface should require no more than is essential for the
service to be provided
• Allows headroom for both client and provider to overfulfill their
contract
– Client may establish more than required by the pre-condition, and
expect less than is guaranteed by the post-condition
• In General:
– What is established by a certain client:
 Demanded by interface (precondition)
 Required by certain provider
– What is established by a certain provider:
 Guaranteed by interface (postcondition)
 Expected by certain client
Substitutability Example
interface SimpleCounter {
int getValue();
void dec();
void inc();
}
interface PositiveCounter {
int getValue();
void dec();
@pre { this.getValue() > 0 }
void inc();
}
class Counter implements
SimpleCounter,
PositiveCounter
SimpleCounter / PositiveCounter : Identical interface
methods, different functionality
Contract Verification
•
Contract-Checking is Highly Desirable
–
Ideally, contracts checked against interface specification
•
–
•
Compiler or other automatic tool
Contract violators would be rejected
In Practice:
–
Fully formalized interface contracts are hard to achieve
•
•
•
Difficult and expensive
Efficient, general-purpose verifiers are not feasible
Current research focuses on theorem-provers using heuristics
–
–
•
Expensive
Requires expert manual assistance
Ultimate Goal: Develop automatic error-checking as early as
possible to prevent catastrophic faults
•
Preferred order of error checking:
1)
2)
3)
4)
Compile-Time
Load-Time
Run-Time
No Checking at All !
Memory Errors
•
Memory Error - A program reads a memory cell based on
a wrong assumption of what the cell contains
–
–
–
•
Can affect unrelated parts of a program
Are notoriously hard to track down
Can be arbitrarily destructive
A Way Around Memory Errors: A Type System
–
Group values of related semantics into sets, or types
•
•
•
–
–
Integers, Reals, Object References, etc.
Basic types (integers, reals) understood as sets of values
Objects and interfaces understood as a set of objects
implementing a certain interface
Helps ensure memory accesses are type compatible
Use with Automatic Memory Management and Runtime
Checks to Eliminate all Memory Errors
Types and Subtypes
• A Type Contains All of the Operations and Signatures
of an Interface
– Input parameters form a part of an operation’s preconditions
– Output parameters form a part of an operation’s postconditions
– NOTE: Other pre and post conditions may exist beyond an
operation’s signature
 A Type is an Interface with a Simplified Contract
A Subtype is a Type Derived From a Base Interface
– Subtypes may be formed in 2 ways
• Interface Inheritance
– Similar to class inheritance
• Structural Subtyping
– Implementation of base interface is copied from derived interface
Types and Subtypes Example
• View is a type:
interface View {
void close();
void restore(int left, int top, int right, int bottom);
}
• TextView is a subtype of View (via interface inheritance):
interface TextView extends View {
int caretPos();
void setCaretPos(int pos);
}
• TextView1 is a subtype of View (via structural subtyping):
interface TextView1 {
void close();
void restore(int left, int top, int right, int bottom);
int caretPos();
void setCaretPos(int pos);
}
• TextView and TextView1 can be used wherever View is
expected
Inheritance
• Three Facets of Inheritance
– Substitutability
• Can a subclass replace it’s superclass without breaking the
system?
– Subtyping (Interface Inheritance)
• Can the subclass use or conform to the interface of the
superclass?
– Subclassing (Implementation Inheritance)
• Can the subclass use the implementation of the
superclass?
• Interface Inheritance is Generally Preferred Over
Implementation Inheritance
Multiple Inheritance
• Two Principle Reasons for Supporting MI
– To merge interfaces from different sources (Multiple
Interface Inheritance)
– To merge implementations from different sources
(Multiple Implementation Inheritance)
• Multiple Interface Inheritance
– Does not generate major technical problems
– Supported by OMG IDL and Java
• Multiple Implementation Inheritance
– May cause problems if superclasses come from disjoint
inheritance graphs
Diamond Inheritance
• The Diamond Inheritance Problem
– Superclasses may inherit code from a shared superclass
further up the inheritance graph
• Issues with State
– Do classes B1 and B2 share A’s state?
• Yes – Breaks encapsulation
• No – Which state does class C see?
• Issues with Behavior (or Method
Implementations)
– If B1 and B2 both override A’s
methods, which version does C see?
• Java’s Solution:
– Support multiple interface inheritance,
but only single implementation
inheritance
Fragile Base Class Problem
• Can a Base Class Evolve?
• Syntactic Fragile Base Class Problem
– Compatibility of compiled classes with new binary
releases of superclasses
– Unrelated to the semantics of inherited code
• Semantic Fragile Base Class Problem
– Can a subclass remain valid when the implementation of
it’s superclass is changed?
Avoiding FBC Issues
• Disciplined Inheritance
– Define Rules to Allow Subclass Construction Based on a
Superclass Specification
• Allows subclasses to remain valid if superclass
implementation changes
• Object Composition
– Messages are forwarded to other related objects
– Outer objects (requestor)
– Inner objects (helper)
• Supports late composition (can be recompiled without
recompiling it’s outer object)
Conclusion
• Component Software is an Evolution of ObjectOriented Software
• Implements Code Reusability
• Addresses Traditional Software Development
Issues
• Provides Customers with Price/Performance
Tradeoff Choices
Questions / Discussion