Software Contracts
G. Ntinolazos
A software contract can represent different things at different levels/scope.
Interaction Contract
A contract can be thought of as a collaboration between different software elements, with
each element playing a particular role(s). This view of contract is analogous to business
contracts between multiple parties where each party has certain responsibilities. (It
corresponds to CORBA IDL files and patterns/collaborations in UML).
This type of contract also deals with interaction protocol constraints; for example the order in
which operations can be called.
Service Contract
One of the characteristics common to objects, components, and services is encapsulation –
this means that external software dependencies may only be on the specification, not the
implementation. The specification is by means of Interfaces, and here the interface is the
contract. It consists of a set of operation specifications with invariants, and pre- and postconditions.
Component Specification Contract
Another form of contract is the component specification (UML2, UMLComponents). The
component specification defines all its interfaces, and inter-interface constraints, and any
component dependencies which act as implementation constraints.
This rest of this document focuses on Service Contracts.
Service Contracts
The different aspects of a contract [ CBDi]
Contract
Logical
Contract
Syntax/
Signature
Semantics/
Logic
QoS
Contract
Commercial
Contract
Semantics/
Vocabulary
Syntax
The syntax level contract is defined at the operation signature level and is based on the
operation’s name, parameters and data types.
out
*
1
*
Interface
Operation
Parameter
*
in
Data Type
Semantics
Bertrand Mayer’s Design by Contract and the Catalysis Approach [Catalysis] extend this
notion of a contract to include the semantics of the service. At the semantics level we have a
set of pre- and post-conditions which define the behaviour of the operation. Pre- and postconditions are defined against operation signature elements and the information model1.
Syntax
out
*
1
*
Interface
Operation
Parameter
Data Type
*
in
Pre-/PostCondition
Information
Model
1
1
1
Query
Semantics
Information
Type
Information Model
The abstract definition of any information or state that is retained between client requests by
an object supporting the interface, and any constraints on that information [UMLComponents,
p.19]
Example
An Interface Information Model diagram for the IAddress interface is shown in the figure
below.
<<Interface>>
IAddress
getAddresses(context : Context, streetname : String) : dAddress[]
createAddress(context : Context, address : dAddress) : void
<<DataType>>
dAddress
HouseNo : String
Streetname : String
Postcode : String
1
0..*
+Addresses
<<InfoType>>
Address
HouseNo : String
StreetName : String
Postcode : String
IAddress interface information model
The IAddress interface is responsible for managing a set of address types. The IIM diagram
shows the interface, its operations and their parameters and types and result type, but does not
show pre-/post-conditions. These would normally be expressed in a text form using a
language like OCL.
References
[Catalysis] Desmond D’Souza, Alan Cameron Wills “Objects, Components and Frameworks
with UML: The Catalysis Approach”. ISBN 0201310120
[CBDi] Richard Veryard, “Modeling for SOA”, CBDi Journal, February 2003
[UMLComponents] John Cheesman, John Daniels. “UML Components”, ISBN 0201708515