Lecture Building reliable component-based systems - Chapter 2: Specification of software components

Lecture Building reliable component-based systems - Chapter 2: Specification of software components. This chapter presents the following content: Current component specification techniques, specifying the semantics of components, specifying extra-functional properties of components.

Trang 1

Building Reliable Componentbased Systems

Chapter 2 Specification of Software Components

Chapter 2 Specification of Software Components Specification of Software Components

Trang 2

Overview

Current Component Specification Techniques

Specifying the Semantics of Components

Specifying Extra-Functional Properties of Components Summary

Trang 3

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

Trang 4

The Specification of an Interface

This must consist solely of:

A precise definition of the component's operations.

All context dependencies.

Trang 5

Usefulness of Component Specification

Trang 6

Current Component Specification Techniques

syntactic specifications

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

Trang 7

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

Trang 8

Components and Interfaces Illustrated

Component

Interface

Operation

* in-interfaces

InOutParameter

*

out-interfaces

*

Trang 9

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

Trang 10

HRESULT add([in] BSTR *word);

HRESULT remove([in] BSTR *word);

Trang 11

Specification 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

Trang 12

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

Trang 13

Specifying 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

Trang 14

Trang 15

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

Trang 16

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

Trang 17

Trang 18

Interface specification diagram

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

Trang 19

Semantic Specification in a UML metamodel

Trang 20

SUCCEEDED(result) implies correct = words->includes(word)

context ICustomSpellCheck::add(in word : String) : HRESULT pre:

word <> “”

post:

SUCCEEDED(result) implies words = words@pre->including (word)

context ICustomSpellCheck::remove(in word : String) : HRESULT pre:

word <> “”

post:

SUCCEEDED(result) implies words = words@pre->exluding(word)

Trang 21

Component specification diagram

«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.

Trang 22

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 SpellChecker

ISpellCheck::words = ICustomSpellCheck::words

Trang 23

Interface dependency

<<comp spec>>

SomeComponent

ISomeInterface IAnotherInterface

IUsedInterface

Trang 24

Realization 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

Trang 25

Specifying Extra-Functional Properties

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

Sufficient Complete Static Homogeneous

Trang 26

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

Trang 27

Trang 28

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.

Trang 29

Trang 30

Summary

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

Định dạng
Số trang	30
Dung lượng	305,73 KB