3.

Software components and interfaces

3.1 The component vision: rationalizing software development

3.2 The component concept
3.3 Components as software units
3.4 Interfaces
3.5 Specifying interfaces
3.6 Customizing components

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 1

3.1 The component vision: rationalizing software
production

Developing software products from existing components

• products become more realiable
• easier to construct products
• easier to train people
• component competition reduces prices

More or less standard practice in other engineering areas

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 2

 Exercise: Write down 5 characteristic
properties of a good software component

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 3

 Composing applications from components
Composing new applications from existing components
Visual component integration tools

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 4

 Example: BeanBox

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 5

 3.2 The component concept

Component = independent unit of software providing

services through a well-defined interface

Szyperski:
A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only.
A software component can be deployed independently and is
subject to composition by third parties.

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 6

 Issues related to components

• Degree of independence
• Deployment
• Size
• Standardization
• Technology-specific properties

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 7

 3.3 Components as software units

• Units of architecture
• Units of functionality – who is responsible of functionalites?
• Units of reuse – what remains common?
• Units of product configuration – what is included in a product?
• Units of deployment – what can be upgraded in isolation?
• Units of variance – what can be changed, how?
• Units of third-party software – what can be obtained from outside?
• Units of work division – what can be separated as tasks?

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 8

 3.4 Interfaces
History:
M interface
A X
B data
Y Z
C A
subroutine
B data data

C A A’
Subroutine library
B B’
Abstract service module
signature C C’
Service Module library class
implementation
Class library
Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 9
 Interfaces as first-class entities

Interface1

ComponentA
Interface2

Interface3

ComponentB
Interface4

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 10

Provided and required interfaces in UML 2.0

PowerSource
Car
required interface

PowerSource

Engine
provided interface

PowerSource

Car Engine

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 11

 Possible implementation in Java:

interface PowerSource { class Car ... {

void start(); ...
int temperature(); private PowerSource eng;
void stop(); ...
} public void setEng(PowerSource e) {
eng = e;
}
class Engine implements PowerSource ... {
public void run() {
...
...
public void start() {...}
eng.start();
public int temperature() {...}
...
public void stop() {...}
eng.stop();
}
...
}
}

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 12

 Ports in UML 2.0

Point of interaction between an object (component) and

its environment
Port
PowerSource
PowerSource
host
Engine
Engine

Warnings

Warnings

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 13

 3.5 Specifying interfaces: contracts

precondition: must hold,

when the service is called
service interface

design-by-contract
(Eiffel) Service
Client
provider

• defines the abstract semantics of the service

• allows exchange of participants,
as long as the interface and its pre-
and postconditions hold
• defines the responsibilities of checking
(no multiple checking, clear separation of
concerns)
postcondition: must hold,
when the service has been delivered,
assuming that the precondition held
when the service was called

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 14

 Class/component invariants

Person
age: int
toberetired: int
op1(...)
op2(...)
op3(...)
invariant
age > 0 &
age < toberetired

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 15

 Inheritance & contracts
pre' post'
pre post A

public oper(...)
pre pre post
post
pre' post' B

pre' post
public oper(...)
pre post' C
pre'
post'
pre post'
pre' post D
Which is correct (A,B,C,D)?

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 16

 Design by contract: example (1)
class Stack {
private Object [] storage;
private int top;
public Stack(int size) {
storage = new Object[size];
top = -1;
}
public int size() {return top+1}
public boolean full() {return top == storage.length;}
public void push(Object x) {
if (top < storage.length-1) {
storage[++top] = x;
}
else {
System.out.println("Overflow");
}
}
Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 17
 Design by contract: example (2)

public Object pop() {

if (top >= 0) {
return storage[top--];
}
else {
System.out.println("Underflow");
return null;
}
}
}

client: ... if s.size() > 0 then {s.pop();} else {... error handling ...} ...

Problems?

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 18

 Design by contract: example (3)
Idealistic interface Stack {
solution: …
Object pop()
// pre size() > 0;
// post size = old size –1;
}

class ArrayStack implements Stack {

…
public Object pop() {
return storage[top--];
}
…
}
Prove that the pre- and postconditions hold (?)
Produce run-time checks that the pre- and postconditions hold (?)
Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 19
 Pragmatic approach: exceptions
• exception = contractor is unable to fulfill its part of the contract
• method either fulfills the contract or throws an exception
• implies that the service provider is able to detect the unableness
• exceptions become part of the interface
• pre- and postconditions can be given informally
public Object pop() throws Underflow {
// pre: stack non-empty
// post: stack size reduced by one
// Underflow: stack is empty upon entry
if (top >= 0) {
return storage[top--];
}
else {
throw new Underflow(this);
}
}

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 20

 3.6 Customizing components

• Changing the initial state of a component

• Implementing required interfaces

• Subclassing

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 21

 Changing the initial state of a component

Client :Comp

ServicesI create
setProperty(...)
setProperty(...)
Comp
use

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 22

 In Java:
class Button extends Component ... {
...
String label;
public Button() {
...
}
public Button(String arg) {
label = arg;
...
}
public setLabel(String arg) {
label = arg;
}
...
}

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 23

 Implementing required interfaces

ActionListener

Button AppLogic

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 24

 Subclassing

Button

CompanyButton

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 25

 In Java:

class CompanyButton extends Button {

public CompanyButton(String arg) {
super(arg);
label = arg.toUpperCase();
}

public void setLabel(String arg) {

label = arg.toUpperCase();
}
}

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 26

 Fragile base class problem

Library Comp
component
"Innocent" modification of
the original component
can make the customized
component invalid

Customized
component Custom

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 27

 Example (1)

<<interface>>
Container
addContainer:
addElement(Object) List { ...addElement(...); ... }
addContainer(Container)

<<interface>>
CountedContainer
addElement:
getCount() CountedList { super.addElement(...);
counter++; }

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 28

 Example (2) addElement
no more called!

<<interface>>
Container
addContainer:
addElement(Object) List { ...}
addContainer(Container)

<<interface>>
CountedContainer
addElement:
getCount() CountedList { super.addElement(...);
counter++; }

Ohjelmistoarkkitehtuurit Syksy 2006 TTY Ohjelmistotekniikka 29