SPECIFICATI

ON OF Lecture 3
Building reliable

SOFTWARE
component-based
software systems by
Ivica Crnkovic,

COMPONENT
Magnus Larsson

S
INTRODUCTION
 In its simplest form a software component contains some code (that can be executed on
certain platforms) and an interface that provides (the only) access to the component.
 The code represents the operations that the component will perform when invoked.
 The interface tells the component user everything he needs to know in order to deploy
the component.
 Components can of course be deployed in many different contexts
 . Ideally, components should be black boxes, to enable users to (re)use them without
needing to know the details of their inner structure.
 In other words, the interface of a component should provide all of the information needed
by its users. Moreover, this information should be the only information they need.
 Consequently, the interface of a component should be the only point of access to the
component.
 Therefore, it should contain all of the information that users need to know about the
component’s operations (that is, what its code enables it to do) and its context
dependencies (that is, how and where the component can be deployed).
 The code, on the other hand, should be completely inaccessible (and invisible) if a
component is to be used as a black box.
 The specification of a component is therefore the specification of its
interface.
 This must consist of a precise definition of the component operations and
context dependencies and nothing else. Typically, the operations and
context dependencies will contain the parameters of the component
 The specification of a component is useful to both component users and
component developers.
 For users, the specification provides a definition of its interface, namely,
its operations and context dependencies. Because 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. Although this should be
invisible to users, it is useful to developers (and maintainers), at least as
documentation of the component.
 CURRENT COMPONENT SPECIFICATION
TECHNIQUES
 The specifications of components used in practical software development
today are limited primarily to what we will call syntactic specifications.
This form of specification includes the specifications used with
technologies such as COM , the Object Management Group.s Common
Object Request Broker Architecture (CORBA) , and Sun.s JavaBeans.
 First, we take a closer look at the relationships between components and
interfaces. A component provides the implementation of a set of named
interfaces, or types, each interface being a set of named operations. Each
operation has zero or more input and output parameters and a syntactic
specification associates a type with each of these.
 Many notations also permit a return value to be associated with each
operation, but for simplicity we do not distinguish between return values
and output parameters. In some specification techniques it is also
possible to specify that a component requires some interfaces, which
must be implemented by other components.
 The interfaces provided and required by a component are often called
the incoming and outgoing interfaces of the component, respectively
 Note that instances of the classes shown on the diagram will be
entities such as components and interfaces, which can themselves be
instantiated.
 The model is therefore a UML metamodel, (figure 2.1) which can be
instantiated to produce other models. It is worth noting that this model
allows an interface to be implemented by several different
components, and an operation to be part of several different interfaces.
 This independence of interfaces from the component implementations
is an essential feature of most component specification techniques.
 The possibility of an operation being part of several interfaces is
necessary to allow inheritance, or subtyping, between interfaces. The
model also allows parameters to be simultaneously input and output
parameters.
Syntatic specification
 As an example of a syntactic specification, we now
consider the specification of a COM component. Below we
provide a slight simplification of what might be the
contents of an IDL file.
 First, two interfaces are specified, including a total of
three operations that provide the functionality of a simple
spell checker.
 Both interfaces inherit from the standard COM interface
IUnknown. (All COM interfaces except IUnknown must
inherit directly or indirectly from IUnknown. All
operations return a value of type HRESULT, which is
commonly used in COM to indicate success or failure.
 A component is then specified (called a library in COM
specifications), thus implementing one COM class,
which in turn implements the two interfaces previously
specified. This component has no outgoing interfaces.
 Relating this specification to the model above, there is
one instance of Component, which is associated with
two instances of Interface. Taking a closer look at the
first interface, it is associated with a single instance of
Operation, which is itself associated with one instance
of InParameter and two instances of OutParameter,
representing the two named parameters and the
return value.
interface ISpellCheck : IUnknown
{
HRESULT check([in] BSTR *word, [out] bool *correct);
};
interface ICustomSpellCheck : IUnknown
{
HRESULT add([in] BSTR *word);
HRESULT remove([in] BSTR *word);
};
Library SpellCheckerLib
coclass SpellChecker
{
[default] interface ISpellCheck;
interface ICustomSpellCheck;
};
};
 The information that can be obtained from a component specification such as the
above is limited to what operations the component provides and the number and
types of their parameters.
 In particular, there is
no information about the effect of invoking the operations,
except for what might be guessed from the names of operations and parameters.
 Thus, the primary uses of such specifications are type checking of client code and as
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. Evolution can be seen as a special case of substitution in
which a newer version of a component is substituted for an older version.
 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, in traditional object-oriented terminology, if the interface
of the new component is a subtype of the interface of the old component.
 For substitution to be safe, however, there are also constraints on the way that the
semantics of operations can be changed, as we will see in the next section.
Specifying the Semantics of Components
 Although syntactic specifications of components are the only form of
specifications in widespread use, it is widely acknowledged that
semantic information about a component’s operations is necessary to
use the component effectively.
 Several techniques for designing component-based systems that
include semantic specifications are provided in the literature. In this
section, we examine the specification technique presented in , which
uses UML and the Object Constraint Language (OCL) to write
component specifications. OCL is included in the UML specification.
Another well-known method that uses the same notations is Catalysis.
 The concepts used for specification of components in these techniques
can be seen as an extension of the generic model of syntactic
specification presented in the previous section. Thus, a component
implements a set of interfaces, each of which consists of a set of
operations. In addition, a set of preconditions and postconditions is
associated with each operation.
 Preconditions are assertions that the component assumes to be fulfilled
before an operation is invoked. Postconditions are assertions that the
component guarantees will hold just after an operation has been invoked,
provided the operation’s preconditions were true when it was invoked.
 In this form of specification, nothing is said about what happens if an
operation is invoked while any of its preconditions are not fulfilled. Note that
the idea of pre- and postconditions is not a novel feature of component-based
software development, and it is used in a variety of software development
techniques.
 Naturally, an operation’s pre- and postconditions will often depend on the
state maintained by the component. Therefore, the notion of an interface is
extended to include a model of that part of a component’s state that may
affect or be affected by the operations in the interface. Now, a precondition is,
in general, a predicate over the operation’s input parameters and this state,
while a postcondition is a predicate over both input and output parameters as
well as the state just before the invocation and just after.
 Furthermore, a set of invariants may be associated with an
interface. An invariant is a predicate over the interface’s state
model that will always hold
 The concepts introduced here and the relationships among them are shown on
the UML class diagram of Figure 2.2 and as an example in Figure 2.3. For the sake
of readability, the classes Name, Type, and InOut- Parameter are not shown,
because they have no direct relationships with the newly introduced classes. Note
that this model allows the same state to be associated with several interfaces.
Often, the state models of different interfaces of a component will overlap rather
than be identical.
 This relationship cannot be expressed in the model because we cannot make any
assumptions about the structure of state models. Note also how each
postcondition is associated with both input and output parameters and two
instances of the state model, representing the state before and after an
invocation.
 In the model presented in Figure 2.2, a partial model of the state of a component
is associated with each interface, to allow the semantics of an interface’s
operations to be specified.
 Although state models in component specifications should above all be kept
simple, the actual representation used in the component’s implementation will
usually be subject to efficiency considerations, depending on the programming
language and other factors. It is also worth mentioning that the model is valid for
procedural as well as object-oriented specification techniques.
 Figure 2.3 is an example of an interface specification diagram. It shows
the two interfaces introduced in the previous section as classes with the
<<interface type>> stereotype.
 Thus, all information in the syntactic interface specifications is included
here. The state models of the interfaces are also shown. A state model
generally takes the form of one or more classes having at least one
composition relationship with the interface to which the state belongs.
 The special stereotype <<interface type>> is used instead of the
standard <<interface>> because the standard <<interface>> would
not allow the state models to be associated with the interfaces in this
way.
 The interface specification diagram is only a part of the complete
interface specifications. The pre- and postconditions that specify the
semantics of the operations as well as any invariants on the state model
are specified separately in OCL. Below is a specification of the three
operations of the two interfaces above. There are no invariants on the
state models in this example.
context ISpellCheck:: check(in word words@pre->including(word)
: String, out correct :
context
Boolean) : HRESULT ICustomSpellCheck::remove(in word :
String) :
pre:
HRESULT
word <> ""
pre:
post:
word <> ""
SUCCEEDED(result) implies correct
= post:
words->includes (word) SUCCEEDED(result) implies words =
context ICustomSpellCheck::add(in words@pre-> excluding(word)
word : String) : HRESULT
pre:
word <> ""
post:
SUCCEEDED(result) implies words =
 The precondition of the first operation states that if it is invoked with
an input parameter that is not the empty string, the postcondition will
hold when the operation returns. The postcondition states that if the
return value indicates that the invocation was successful, then the
value of the output parameter is true if word was a member of the set
of words and false otherwise.
 The specifications of the two last operations illustrate how
postconditions can refer to the state before the invocation using the
@pre suffix. This specification technique uses the convention that if
part of an interface.s state is not mentioned in a postcondition, then
that part of the state is unchanged by the operation. Thus, words =
words@pre is an implicit postcondition of the first operation. All
specifications refer to an output parameter called result, which
represents the return value of the operations. The function SUCCEEDED
is used in COM to determine whether a return value of type HRESULT
indicates success or failure.
 Like interface specification diagrams, component specification
diagrams are used to specify which interfaces components
provide and require.
 Figure 2.4 is an example of such a diagram, specifying a
component that provides the two interfaces specified above. The
component is represented by a class with stereotype <<comp spec>>
to emphasize that it represents a component specification. UML also has a
standard component concept, which is commonly used to represent a file
that contains the implementation of a set of concrete classes.
INTER-INTERFACE
CONSTRAINTS
 The component specification is completed
by the specification of its inter-interface
constraints.
 An example constraint is formulated in
OCL (Object Constraint Language) below.

context SpellChecker
ISpellCheck::words
ICustomSpellCheck::words

21
 The component specification diagram in Figure 2.4
shows how we can indicate which interfaces are offered
by a component.
 In this example, we indicated that the spell checker
offered the interfaces ISpellCheck and
ICustomSpellCheck and used the constraint
ISpellCheck::words = ICustomSpellCheck::words
 to specify that the interfaces act on the same
information model. We could, however, extend such
diagrams to indicate the interfaces on which a
component depends. This is illustrated in Figure 2.5.
INTERFACE
DEPENDENCY

23
REALIZATION
CONTRACTS
 We can also specify realization contracts
using Collaboration Interaction Diagrams.
1: op1
Whenever the operation op1
is called, a component
supporting this operation /ISomeInterface
must invoke the operation
op2 in some other 1.1: op2
component
/IUsedInterface

ECE658 24
COMPONENT
PROPERTIES
 Structural Properties (FR)
 Governing
how a component can be
composed with other components.
 Extra-Functional Properties (NFR)
 Such as performance, capacity, and
environmental assumptions.
 Family Properties
 Specifying
relations among similar or related
components.
25
 CREDENTI
ALS
 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
A specification technique based on credentials must include a set of registered attributes,
along with notations for specifying their value and credibility, and provisions for adding
new attributes. A technique could specify some attributes as required and others as optional.
 Attributes in .NET
 A component developer can associate attribute values with a component and
define new attributes by sub- classing an existing attribute class.

26
ENSEMB
LE
 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

27
EXTRA-FUNCTIONAL
PROPERTIES Component
1 *
* *

Credential * in-interfaces
*
Attribute
Value Interface
Credibility * 1 out-interfaces
IsPostulat *
e:
Boolean
* *

Operation
1
1

Type Parameter
1 *
28