chapter 2 specification of software components

Building Reliable Component-based Systems Chapter 2 -Specification of Software Components

Chapter 2Chapter 2

Specification of Software ComponentsSpecification of Software Components


OverviewOverview

Current Component Specification Techniques Specifying the Semantics of Components Specifying Extra-Functional Properties of Components Summary


What Is a Component Comprised of?What Is a Component Comprised of?

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 InterfaceThe Specification of an Interface

This must consist solely of: A precise definition of the component's operations. All context dependencies.


Usefulness of Component SpecificationUsefulness of Component Specification

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.


Current Component Specification TechniquesCurrent Component Specification Techniques

syntactic specifications Microsoft’s Component Object Model (COM) Common Object Request Broker Architecture (CORBA) JavaBeans


Components and InterfacesComponents 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


Components and Interfaces IllustratedComponents and Interfaces IllustratedComponent

Interface

Operation

*

in-interfaces*

*

*

Name

1

1

1 11

1

Parameter

1

*

Type1 *

OutParameterInParameter

InOutParameter

*

out-interfaces

*


Model explainedModel 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


IDL ExampleIDL Exampleinterface 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;

};};


Specification UsesSpecification Uses

the primary uses of such specifications are: Type checking of client code. A base for interoperability between independently

developed components and applications. An important aspect of interface specifications is how

they relate to substitution and evolution of components


SubstitutionSubstitution

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.


Specifying the Semantics of ComponentsSpecifying the Semantics of Components

Current component technologies assume that the user of a component is able to make use of such semantic information.

COM dictates that the error codes produced by an operation are immutable, i.e. changing these is equivalent to changing the interface


Interfaces Interfaces

A component: Implements a set of interfaces that each consists of a

set of operations. In addition, a set of pre-conditions and post-conditions is

associated with each operation.


A Pre-conditionA 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-conditionA 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 InvariantAn Invariant

Is a predicate over the interface’s state model that will always hold

A set of invariants may be associated with an interface.


Interface specification diagramInterface specification diagram

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

«interface type»ISpellCheck String

1

words

*

add(in word : String) : HRESULTremove(in word : String) : HRESULT

«interface type»ICustomSpellCheck

1

words

*

String

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


Semantic Specification in a UML metamodelSemantic Specification in a UML metamodel

Interface

Component

*

in-interfaces*

*

out-interfaces

*

State1 *

Constraint

*

*

* 1

Invariant

1

*

1

*

Operation

*

*

Parameter

1

*

PreCondition* 1

PostCondition1 *

1

*

InParameter OutParameter

*

*

*

*

*

*

*

2


Interface SpecificationInterface 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)


Component specification diagramComponent specification diagram

«comp spec»SpellChecker

ISpellCheckICustomSpellCheck

Specifying a component that provides interfaces

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


Inter-interface ConstraintsInter-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 SpellCheckerISpellCheck::words = ICustomSpellCheck::wordsISpellCheck::words = ICustomSpellCheck::words


Interface dependencyInterface dependency

<<comp spec>>SomeComponent

ISomeInterface

IAnotherInterface

IUsedInterface


Realization ContractsRealization Contracts

We can also specify realization contracts using collaboration interaction diagrams.

1: op1

/IUsedInterface

1.1: op2

/ISomeInterface

Whenever the operation op1 is called, a component supporting this operation must invoke the operation op2 in some other component


Specifying Extra-Functional PropertiesSpecifying Extra-Functional Properties

Conventional software doctrine is the view that software specifications must be:

Sufficient Complete Static Homogeneous


Credentials Credentials

A 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 Attributes in .NET

A component developer can associate attribute values with a component and define new attributes by sub-classing an existing attribute class.


Architectural component Architectural component

Structural properties Governing how a component can be composed with

other components. Extra-functional properties

Such as performance, capacity, and environmental assumptions.

Family properties Specifying relations among similar or related

components.


Ensemble Ensemble

In Ensemble, a set of credentials may be associated with a single technology, product, or component, or with a group of such elements

A UML metamodel with the concepts of syntactic specification augmented with credentials is shown in the following slide.


Extra-functional PropertiesExtra-functional PropertiesComponent

Interface

Operation

*

in-interfaces*

*

*

AttributeValueCredibilityIsPostulate : Boolean

Credential

*1

* 1

*

1

Parameter

1

*

Type1 *

*

out-interfaces

*


SummarySummary

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

specify components only syntactically. The use of UML and OCL to specify components

represents a step towards semantic specifications. 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

chapter 2 specification of software components

Documents

interface chapter

component x

component y

new component

components operations

different interfaces

interfacethe interface

different components