Component specification•Main bibliography:

–Ivica Crnkovic, Magnus Larsson (Eds.): Building reliable component-based systems

•Chapter 2: Specification of Software Components•Chapter 6: Semantic Integrity in Component Based DevelopmentSemantic Integrity in Component Based Development

•Other readings:–B.Meyer: Applying Design by Contract

–Mary Shaw, Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does

–Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, Damien Watkins: Making Components Contract Aware

What is a component comprised off ?

• Some Code… – The code represents the operations that the component will perform

when invoked

• An interface…– The interface tells the component-user everything he needs to know in

order to deploy the component

– The interface of a component should provide all the information needed by its users

• The specification of a component is therefore the specification of its interface

The Specification of an Interface

• This must consist solely of:– A precise definition of the component's operations.

– All context dependencies.

Need for component specifications

• For users, – The specification provides a definition of its interface, viz. its operations

and context dependencies.

– Since it is only the interface that is visible to users, its specification must be precise and complete.

• For developers, – The specification of a component also provides an abstract definition of

its internal structure.

Required and Provided Interfaces/Properties

• To be composable solely on the basis of its specification, a component needs to be equipped with:– Explicit declarations of functionality, synchronization and quality

• required properties

• provided properties

Component

Component specification levels

• Levels of a component specification:– Syntax: includes specifications on the programming

language level.– Semantic: functional contracts– Non-functional: deals with quality of service.

Component specification levels

• Levels of a component specification:– Syntax: includes specifications on the programming Syntax: includes specifications on the programming

language level.language level.– Semantic: functional contracts– Non-functional: deals with quality of service.

Components and Interfaces

• A component provides:– The implementation of a set of named interfaces, or types, each

interface being a set of named operations

• The following diagram is a UML metamodel – This model allows an interface to be implemented by several

different components, and an operation to be part of several different interfaces

Metamodel of the concepts used in syntactic specification of software components

Figure 2.1 from [Crnkovic]

Model explained

• The model presents a generic representation of:– The relationships between components, interfaces, and operations

• One can distinguish between:– Object Oriented specifications and

– Procedural specifications • Some differences may appear between different component technologies

– Ex: A component implements a set of classes, each implementing a set of interfaces (COM)

– Ex: A component is itself a class, implementing a interface

Example: component SpellChecker

«comp spec»SpellChecker

ISpellCheck

ICustomSpellCheck

Implementation as a COM component:• Uses an IDL

IDL Example

interface ISpellCheck : IUnknowninterface ISpellCheck : IUnknown{

HRESULT check([in] BSTR *word, [out] bool *correct[in] BSTR *word, [out] bool *correct);}; interface ICustomSpellCheck : IUnknowninterface ICustomSpellCheck : IUnknown{

HRESULT add([in] BSTR *word[in] BSTR *word);HRESULT remove([in] BSTR *word[in] BSTR *word);

}; library SpellCheckerLiblibrary SpellCheckerLib{

coclass SpellCheckercoclass SpellChecker{

[[default] interface ISpellCheck;default] interface ISpellCheck;interface ICustomSpellCheck;interface ICustomSpellCheck;

};};

Uses of Syntactic Specification

• The primary uses of syntactic specifications are:– Type checking (static of dynamic) of client code. – Base for interoperability between independently developed

components and applications. • Interoperability may be achieved in different ways:

– Binary format for interfaces– IDL to programming language mapings

• An important aspect of interface specifications is how they relate to substitution and evolution of components

Substitution

• Substituting a component Y for a component X is said to be safe if:– All systems that work with X will also work with Y

• From a syntactic viewpoint, a component can safely be replaced if:– The new component implements at least the same interfaces as

the older components, or

– The interface of the new component is a subtype of the interface of the old component.

Forms of syntactic specification

• All component models use syntactic specification of interfaces:– Programming language – IDL

• Examples – Microsoft’s Component Object Model (COM) – Common Object Request Broker Architecture (CORBA) – JavaBeans

Component specification levels

• Levels of a component specification:– Syntax: includes specifications on the programming

language level.– Semantics: functional contractsSemantics: functional contracts– Non-functional: deals with quality of service.

Contracts

“Applying Design by Contract,” B. Meyer, IEEE Computer, pp. 40-51, October 1992.

Design-by-contract background

• A Client-Server Design

• Server Objects– Provides services for client objects to use– The object whose methods are being invoked

• Client Object– Consumes the services offered by the supplier object– The object that invokes the methods of the supplier object

• Contract– A set of benefits and obligations that are mutually agreed upon by the

client and supplier

– In practice, specified by the supplier object

– Clients implicitly accept the contract by using objects of the supplier class

• Good contracts are always in writing!

Contracts in real life - Example

Table 1 from [Meyer]

What is a Contract?

• A contract between a client and a supplier protects both sides– It protects the client by specifying how much should be done to get the

benefit. The client is entitled to receive a certain result.

– It protects the supplier by specifying how little is acceptable. The supplier must not be liable for failing to carry out tasks outside of the specified scope.

• If a party fulfills its obligations it is entitled to its benefits– No Hidden Clauses Rule: no requirement other than the obligations

written in the contract can be imposed on a party to obtain the benefits

Contracts for softwareExample: add node to tree

Table 2 from [Meyer]

Informal description of contract:

Contracts for softwareExample: add node to tree

Fig. 2 from [Meyer]

More formal description of contract, as part of the routine’s text:

Contracts for components

• Pre-conditions• Post-conditions• Invariants

A Pre-condition

• Is an assertion that the component assumes to be fulfilled before an operation is invoked.

• Will in general be a predicate over the operation’s input parameters and this state

A Post-condition

• Is an assertion that the component guarantees will hold just after an operation has been invoked, provided the operation’s pre-conditions were true when it was invoked.

• Is a predicate over both input and output parameters as well as the state just before the invocation and just after

An Invariant

• Is a predicate over the interface’s state model that will always hold • A set of invariants may be associated with an interface.

Metamodel of the concepts used in semantic specification of software components

Figure 2.2 from [Crnkovic]

Semantic specification of components

• Semantic specification of a component comprises:– Specify component interfaces– For each interface, specify:

• Model of state and Invariants

• Operations with pre- and post-conditions

• The model allows that different interfaces act on the same state model

– Inter-interface constraints

Note that state models and operation semantics are associated with interfaces rather than with a component !

Component specificationExample: component SpellChecker

«comp spec»SpellChecker

ISpellCheck

ICustomSpellCheck

Specifying a component that provides interfaces

Similarly to interface specification diagrams, components specification diagrams are used to specify which interfaces components provide and require.

Interface specification diagram

Example: Interface ISpellCheck

• State: words• Operations:

– check (in word:String, out correct:Boolean):HRESULT;• Pre: the word to be checked is non-empty string

• Post: if the return value indicates success, then the value of correct is true if word was a member of words and false otherwise

Interface specification diagram Example: ICustomSpellCheck

• State: words

• Operations:– add (in word:String):HRESULT;

• Pre: the word to be added is non-empty string• Post: if the return value indicates success, then word has been added to words

– remove(in word:String):HRESULT;• Pre: the word to be removed is non-empty string• Post: if the return value indicates success, then word has been removed from

words

Inter-interface Constraints

• The component specification is completed by the specification of its inter-interface constraints, an example constraint is formulated in OCL below.

context SpellCheckercontext SpellChecker

ISpellCheck::words = ICustomSpellCheck::wordsISpellCheck::words = ICustomSpellCheck::words

This model allows the same state to be associated with several interfaces

Uses of Semantic Specification

• Tool support for component developers• Tool support for developers of component-based applications

Substitution extended with semantics

• Substituting a component Y for a component X is said to be safe if:– All systems that work with X will also work with Y

• From a semantic viewpoint, a component can safely be replaced if:– A client that satisfies the preconditions for X must always satisfy the

preconditions specified for Y– A client that can rely on postconditions ensured by X can also be

ensured it can rely on Y

• Conditions for component Y:– Interfaces of Y can have weaker preconditions on operations– Interfaces of Y can have stronger postconditions on operations– State models of X and Y need not be identical

Levels of Formalism for Semantic Specifications

• The levels of formalism, in an increasing order of formalism: – No semantics

– Intuitive semantics

– Structured semantics

– Executable semantics

– Formal semantics

Weak and strong contracts

• Postconditions • specify the exit conditions guaranteed by an operation at its end provided

the precondition was satisfied at the entry in the operation• The outcome when the precondition was not satisfied is explicitly left

undefined [Meyer]

• Strong contract:– the precondition specifies conditions for success– postcondition need to spercify only the outcome in the well-defined situations– Back-end-components usually have strong contracts

• Weak contract: – the precondition is uncomplete, the component must be able to filter out invalid

uses– The postconditions will specify also the outcome of the invalid uses – Front-end-components (such as GUI-components) usually have weak contracts

An Example

• Component RandomAccess– controlls the access to random access file of a record type R

– records of a fixed size

– access to the file is by record number, numbers start from 0.

– It is assumed that the file is continuous, thus record numbers go up to the current maximum number, called the high water mark

• Operations:– addRecord

– getRecord

– delRecord

– getHighWaterMark

The contract

• Operation getRecord – retrieves a record with a given number

• The precondition for – the single input parameter of the operation is the number of the

record concerned, which must exist in the file. • The post-condition

– If an unrecoverable system error occurs (file system error) the operation indicates a failure

• Weak part of the contract: client does not have to check file status before

– the result of the operation is the required data record of type R.• Strong part of the contract: assumes that record number is always

correctly given

Level 0: No Semantics

• The following definition of the operation getRecord illustrates how a purely syntactic specification would be given:

public R getRecord(int number) throws IOException

Level 1: Intuitive Semantics

• Plain text, unstructured description and comments about a component and its parts

• An intuitive specification of the operation getRecord:

The operation getRecord retrieves a record by its number, returning the record requested. If an error occurs, such as a disk read error or a file system error, the an I/O error is returned.

Level 2: Structured Semantics

• The semantics is presented in a structured way but needs not be in accordance with any particular syntax or formalism

• A structured specification of the operation getRecord:

getRecord returns a record identified by its number. Parameters: number: the number of the record to retrieve, counted from zero Precondition: number >= 0 and number <= the high water mark Postcondition: the record with the given number is returned, unless a file system error occurs, in which case a file system error is reported and the value returned is undefined.

Level 3: Executable Semantics • The semantics is expressed in a way that can be executed and

controlled by the system during run-time. • The executable specification is included in the implementation

of the component• Limitation: not all conditions can be expressed in an executable

way

Executable specification for getRecord:

getRecord returns a record identified by its number.Parameters:number: the number of the record to retrieve, counted from zeroPrecondition: (0 <= number) && (number <= hwm())Postcondition: throw IOException || (result == record(number))

Examples of executable semantics

• Assertions:– Java:

http://download.oracle.com/javase/6/docs/technotes/guides/language/assert.html

• OCL (Object Constraint Language) • Contract4J http://www.contract4j.org/contract4j• MSDN: Code Contracts

http://research.microsoft.com/en-us/projects/contracts/

• General rules: – The execution of the assertions should not add functionality !– Assertions serve to detect coding errors and should not try to

handle or compensate for them

Trapping Offending Calls

• For debugging purposes, the component itself may use the executable precondition to trap offending calls:

public R getRecord(int number) throws IOException{ System.assert((0 <= number) && (number <= hwm())); // the implementation of the method}

(The example here just assumes that the System class contains an assert method)

Ensuring a Correct Call

• The client code may also take advantage of the executable assertions by checking the precondition before the call, as illustrated below:

if ((0 <= number) && (number <= theFile.hwm())){ try { record = theFile.getRecord(number); // record == the record requested } catch (IOException e) { /* unrecoverable IO error */ }}

OCL

• The Object Constraint Language (OCL) is a declarative language for describing rules that apply to UML models

• OCL can be used– to describe constraints

• A constraint is a restriction on one or more values of a model or system.

• A constraint is an expression that evaluates to true or false– as a query language

• Queries are expressions that evaluate to a value (true, false and other values)

• Can be used to define new attributes and operations• OCL expressions are always associated with a UML

model– OCL expressions can be associated with any model element

in UML

OCL Constraints vs. Queries

• Examples of constraints:– Duration of a flight is the same as the difference between the arrival

and departure times– The maximum number of passengers on a flight must be less than

1,001– The origin of a flight must be different than its destination

• Examples of queries:– Return all the departing flights from a given airport– Return all the flights departing from a given airport with a departure

time after 4p.m.– Derive the arrival time by adding the duration of the flight to the

departure time.

Airport

Flight

*

*

departTime: Time/arrivalTime: Timeduration : IntervalmaxNrPassengers: Integer

origin

desti-nation

name: String

arrivingFlights

departingFlights

1

1

Different kinds of OCL constraints

• Class invariant– a constraint that must always be met by all instances of the class

• Precondition of an operation – a constraint that must always be true BEFORE the execution of the

operation

• Postcondition of an operation – a constraint that must always be true AFTER the execution of the

operation

• Constraint context: the element that the constraint restricts – Every OCL expression is bound to a context

– Own context may be denoted by “self”

Example: SpellChecker component

«comp spec»SpellChecker

ISpellCheck

ICustomSpellCheck

Example: OCL Interface Specification

context ISpellCheck::check(in word : String, out correct : context ISpellCheck::check(in word : String, out correct : Boolean): HRESULTBoolean): HRESULT

pre:pre:word <> “”post:post:SUCCEEDED(result) implies correct = words->includes(word)implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULTcontext ICustomSpellCheck::add(in word : String) : HRESULTpre:pre:word <> “”post:post:SUCCEEDED(result) impliesimplies wordswords = = words@pre->including (word)words@pre->including (word) context ICustomSpellCheck::remove(in word : String) : HRESULTcontext ICustomSpellCheck::remove(in word : String) : HRESULTpre:pre:word <> “”post:post:SUCCEEDED(result) implies words = words@pre->exluding(word)implies words = words@pre->exluding(word)

Example: OCL Inter-interface constraints

• The component specification is completed by the specification of its inter-interface constraints, an example constraint is formulated in OCL below.

context SpellCheckercontext SpellChecker

ISpellCheck::words = ICustomSpellCheck::wordsISpellCheck::words = ICustomSpellCheck::words

Assertions vs Contract4J Example

import ...PhoneNumber; import ...Address;

class SearchEngine { ... PhoneNumber search (String first, String

last, Address streetAddress) { assert first != null : "bad first name"; assert last != null : "bad last name"; assert address != null : "bad address";PhoneNumber result = doSearch (first,

last, streetAddress); assert result != null && result.isValid() > 0 :

"bad phone number"; return result; } ... }

import ...PhoneNumber; import ...Address; import com.contract4j5.contract.*; @Contract public class SearchEngine { ...@Pre @Post("$return != null &&

$return.isValid()") public PhoneNumber search (String first,

String last, Address streetAddress) { PhoneNumber result = doSearch (first,

last, streetAddress); return result; } ... }

MSDN: Code Contracts Example

Level 4: Formal Semantics

• With formal semantics programs can be proven to have consistent and sound semantics

• Formal specification languages:– VDM– Z– Lambda

Formal Semantics Example

• The visible state of the random access component is defined in a Z state schema called RandomAccess

• The term records represent all the records in the file and R is the record data type.

• The variable hwm (for 'high water mark') shows how much of the file is in use.

• The formula expresses the invariant

RandomAccessrecords: N Rhwm: N

i : 0..hwm { records(i) }

Formal Semantics Example Continued

• The file operation is defined as a state schema called getRecord and is illustrated below:

getRecord RandomAccessnumber?: Nrecord!: Rstatus!: {OK, FileSystemError}

number? hwm((status! = OK) record! = records(number?)) (status! = FileSystemError)

Component specification levels

• Levels of a component specification:– Syntax: includes specifications on the programming

language level.– Semantic: functional contracts– Non-functional: deals with quality of service.Non-functional: deals with quality of service.

Quality-of-service specification• What:

• Non-functional (extra-functional) properties (associated more with component implementations rather than interfaces)

• Examples: Reusability, Configurability, Distributeability, Availability, Confidentiality, Integrity, Maintainability, Reliability, Safety, Security, Affordability, Accessibility, Administrability, Understandability, Generality, Operability, Simplicity, Mobility, Nomadicity, Hardware independence, Software independence, Accuracy, Footprint, Responsiveness, Scalability, Schedulability, Timeliness, CPU utilization, Latency, Transaction, Throughput, Concurrency, Efficiency, Flexibility, Changeability, Evolvability, Extensibility, Modifiability, Tailorability, Upgradeability, Expandability, Consistency, Adaptability, Composability, Interoperability, Openness, Heterogenity, Integrability, Audibility, Completeness, , Conciseness, Correctness, Testability, Traceability, Coherence, Analyzability, Modularity, …

• Who:

• Credentials

• Why needed:

• Selection between semantic equivalent components

• Negotiation possibilities

Credentials

•Mary Shaw, Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does, Proceedings of the 8th International Workshop on Software Specification and Design, pp. 181-185, 1996•http://www.cs.cmu.edu/afs/cs/project/vit/www/paper_abstracts/Credentials.html

•Credential is a triple <Attribute, Value, Credibility>•Attribute: is a description of a property of a component•Value: is a measure of that property•Credibility: is a description of how the measure has been obtained

•A specification technique based on credentials must include:•a set of registered attributes•notations for specifying their value and credibility•provisions for adding new attributes. A technique could specify some attributes as required and others as optional.

Metamodel of the concepts used in extra-functional specification of software components

Figure 2.7 from [Crnkovic]

Component specification – another view

• Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, Damien Watkins: Making Components Contract Aware, IEEE Computer Magazine, vol. 32, no. 7, pp. 38-45, July, 1999

• Component specification should be done at 4 levels:– Syntax: includes specifications on the programming language

level.– Behavior: relates to contracts.– Synchronization: describes the dependencies between services

provided by a component.– Quality of service: deals with quality of service.

Figure from [Beugnard+]

Summary

• A component has two parts: an interface and some code • In current practice, component specification techniques specify

components only syntactically. • There are many steps towards semantic specifications:

– Executable semantics: (Contracts, OCL, Contracts4J)

– Formal semantics

• Specification of extra-functional properties of components is still an open area of research, and it is uncertain what impact it will have on the future of software component specification

Component specification conclusion

•Software specification in a Conventional software doctrine :•Sufficient and complete: provide everything a user needs to know and may rely on in using the software•Static : written once and frozen•Homogeneous: written in a single notation

•Specification of architectural components:•Incomplete:

•To use an architectural component successfully, information about more than just its functionality is required. •It is not realistic to expect specifications to be complete with respect to all such properties, due to the great effort this would require. (Nor is it realistic to expect that the developer of a component could anticipate all aspects of the component in which its user might be interested.)

•Extensible:• Because we cannot expect software components to be delivered with specifications that are sufficient and complete, and because developers are likely to discover new kinds of dependencies as they attempt to use independently developed components together

•Heterogeneous: •since the diversity of properties that might be of interest is unlikely to be suitably captured by a single notation.