DF14900
Component Based Software
Peter Bunus
Department of Computer and Information Science
Linköping University, Sweden
peter.bunus@liu.se
Copyright © Peter Bunus 2008
Object Oriented Technology
Properties and Limitation of
Component Based Design
OOP-Object Oriented Programming
! Object-oriented programming (OOP) is a programming paradigm using
"objects" – data structures consisting of data fields and methods
together with their interactions – to design applications and computer
programs.
! Fundamental Concepts in OO Programming
•  Classes and instances. Encapsulation of code and data
–  Enable programmer to group data and subroutines (methods) together hiding irrelevant data
from users.
•  Inheritance
•  Polymorphism and dynamic method dispatch
2
Simple Class Example in Java
public class Bicycle {
// the Bicycle class has three fields
public int cadence;
public int gear;
public int speed;
// the Bicycle class has one constructor
public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
We have
grouped data
and subroutines
(methods)
together hiding
irrelevant data
from users.
}
// the Bicycle class has four methods
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}
}
3
Interfaces
! Classes provide a type system
•  Type conformance issues
•  Method signatures provide a well-defined interface
(at least at the syntactic level) !
! Interfaces = means by which components connect:!
•  Set of named operations that can be called by clients!
•  With specified semantics!
•  To be respected both by component provider and by client!
! Do we have an interface for the Bicycle class?!
4
The Concept of Inheritance
! Inheritance : Enable a new abstraction (i.e derived class) to be defined as
an extension of an existing abstraction retaining key characteristics
public class MountainBike extends Bicycle {
// the MountainBike subclass has one field
public int seatHeight;
// the MountainBike subclass has one constructor
public MountainBike(int startHeight, int startCadence,
int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
// the MountainBike subclass has one method
public void setHeight(int newValue) {
seatHeight = newValue;
}
}
5
Why Inheritance
! Extensibility
•  Reuse of older definitions
•  More operations can be added to an interface
! The Replacement Principle
•  If B extends A then any object of B can be safely used
in a context where an object A is expected
! Do we have an interface for the Mountain
Bike class?!
•  Yes the interface is provided “indirectly” by the object
instantiated from the MountainBike class !
6
Dynamic Dispatch Example
public class Bicycle {
public String printName() { return “I’m a bicycle!”; }
}
public class MountainBike extends Bicycle{
public String printName() { return “I’m a Mountain Bike!”; }
public static void main(String args[]) {
Bicycle a = new MountainBike();
MountainBike b = new MountainBike ();
System.out.println(a.printName(),b.printName());
}
}
I’m a Mountain Bike! I’m a Mountain Bike!
Dynamic dispatch (also known as dynamic binding) is the process of
mapping a message to a specific sequence of code (method) at runtime.
This is done to support the cases where the appropriate method cannot
be determined at compile-time (i.e. statically)
7
Problem 1 with OOP
! Implementation inheritance and dynamic method dispatch break
encapsulation (is white-box reuse; but components are ”black
boxes”)!
8
Interfaces in UML
! Component Diagram
Component (a specialized class)!
spellCheck
synonyms
Dictionary
supplement
Provided interfaces!
Required interface!
spellCheck
Dictionary
synonyms
WordProcessor
supplement
9
Interfaces in UML
A component diagram that shows how the Order
System component depends on other components
10
Component Contract
•  A Component is specified in terms of in terms of interfaces it provides
and the interfaces it requires
•  Is the component diagram sufficient to use and build a component?
John Daniels – Components Contracts – TOOLS Europe 2000
11
Sequence Diagrams for Specifying Details
! A complete specification must contain sufficient information for the
component to be built and used
! We can ad more information by adding a sequence diagram
John Daniels – Components Contracts – TOOLS Europe 2000
12
Two distinct Contracts
John Daniels – Components Contracts – TOOLS Europe 2000
13
Specifying the usage contract
John Daniels – Components Contracts – TOOLS Europe 2000
14
Contracts
[Meyerʼ88]!
! A contract is the set of requirements
that a use of an object has on a declaration of its class.!
•  Functional specification for each module before coding
!
! An interface is a contract between the client of the interface and the
provider of the implementation!
Contracts – beyond type conformance!
!
Hoare triplets:
{precondition} operation {postcondition}
[Hoareʼ69]
!
! Preconditions of an operation:!
•  True on invocation!
•  Calleeʼs / providerʼs requirements!
! Postconditions of an operation:!
•  True on return!
•  Calleeʼs / providerʼs promise to caller / client !
! May be formulated e.g. in UML-Object Constraint Language OCL
!
! ”Demand no more, provide no less”:!
•  Contract precondition must imply providerʼs precondition!
•  Providerʼs postcondition must imply contract postcondition!
Sorts of inheritance
!
Multiple inheritance
•  Class has multiple superclasses
!
Principal reasons:
•  Merge interfaces of different sources
(Multiple interface inheritance)
•  Merge implementations of sources
(Multiple implementation inheritance)
2012-05-13
An Introduction to
17
Components
Multiple Interface inheritance
!
Used to establish compatibility with multiple independent contexts
!
Supported by many languages (OMG IDL, Java, C#, C++)
!
Not more complicated then single interface inheritance (more on this
later)
2012-05-13
An Introduction to
18
Components
Multiple implementation inheritance
!
Mixing implementations from different sources (superclasses)
!
Not a problem if sources are disjoint (do not relate to each other in any
way by inheritance) and if name clashes are properly resolved
!
Possible problem if they are not
2012-05-13
An Introduction to
19
Components
Why inheritance?
! Inheritance allows for extension reusing implementations from different
sources (super-classes)
! Not a problem if sources are disjoint and if name clashes are properly
resolved
! Possible problems if they are not
2012-05-13
An Introduction to
20
Components
Multiple inheritance
! The diamond inheritance problem
A
B2
B1
C
o  State problem: Do B1 and B2 share the state of superclass A, or
do they get their own copy?
o  Behavior problem: If B1 and B2 override an A method, what
behavior should C have?
2012-05-13
An Introduction to
21
Components
State problem
! Do B1 and B2 share the state of superclass A, or
do they get their own copy?
! If they share state, they are coupled, and thus the
encapsulation principle no longer holds
! If they do not share state, then the consistency of
C is in danger
2012-05-13
An Introduction to
22
Components
DIP: Behavior problem
!
If B1 and B2 override some of A s methods, what behavior should C
have?
!
Solution approaches:
•  Prescribe some inheritance order (CLOS)
•  Allow only single implementation inheritance (Java, CLR)
2012-05-13
An Introduction to
23
Components
Multiple inheritance: mixin
! Combining subtype with inheritance
Interface I
m1()
m2()
Abstr class A1
Implements I
m1() =…
Abstr class A2
Implements I
m2()=…
Class C
Extend A1,A2
2012-05-13
In object-oriented programming languages, a mixin is a
class that provides a certain functionality to be inherited by
a subclass, while not meant for instantiation (the
generation of objects of that class). Inheriting from a mixin
is not a form of specialization but is rather a means of
collecting functionality. A class may inherit most or all of its
functionality from one or more mixins through multiple
inheritance.
An Introduction to
24
Components
More problems with inheritance
!
Can a base class evolve without breaking independently evolved
subclasses?
!
Potentially tight dependency of independently developed subclasses on
their base class is called the fragile base class problem
2012-05-13
An Introduction to
25
Components
Fragile Base Class Problem
!
Syntactic problem
•  binary compatibility of subclasses with new releases of superclasses
!
Semantic problem
•  how can a subclass remain valid when the superclasses evolve?
2012-05-13
An Introduction to
26
Components
Syntactic FBC Problem
!
A Class should not need recompilation if one or more superclasses
undergo only syntactic changes
!
Solution: initialising method dispatch tables at load time
2012-05-13
An Introduction to
27
Components
Semantic FBC Problem
!
A compiled class should remain stable even if the interfaces or
implementation of a superclass has changed
!
Inheritance break encapsulation
•  Semantic change of superclasses most likely breaks subclasses
•  Analogy with the callback problem
2012-05-13
An Introduction to
28
Components
Inheritance: conclusions
! Inheritance is a powerful extension mechanism
! Programming with inheritance requires very
disciplined methods.
! It is not suitable for independent extension
! Inheritance should not cross the component
borders
2012-05-13
An Introduction to
29
Components
Covariance example!
interface View {
...
Model getModel();
}
interface TextView extends View
...
TextModel getModel();
}
interface GraphicsView extends View {
...
GraphicsModel getModel();
}
! Clients that only care about
View will get a generic Model
as result type when asking for
the view model.!
! Clients that know that they
are dealing with a TextView
object will get a TextModel.
!