chapter 2 specification of software components
DESCRIPTION
Chapter 2 Specification of Software Components. Overview. Current Component Specification Techniques Specifying the Semantics of Components Specifying Extra-Functional Properties of Components Summary. What Is a Component Comprised of?. Some Code… - PowerPoint PPT PresentationTRANSCRIPT
Page 1Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
Chapter 2Chapter 2
Specification of Software ComponentsSpecification of Software Components
Page 2Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
OverviewOverview
Current Component Specification Techniques Specifying the Semantics of Components Specifying Extra-Functional Properties of Components Summary
Page 3Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 4Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 5Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 6Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
Current Component Specification TechniquesCurrent Component Specification Techniques
syntactic specifications Microsoft’s Component Object Model (COM) Common Object Request Broker Architecture (CORBA) JavaBeans
Page 7Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 8Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
Components and Interfaces IllustratedComponents and Interfaces IllustratedComponent
Interface
Operation
*
in-interfaces*
*
*
Name
1
1
1 11
1
Parameter
1
*
Type1 *
OutParameterInParameter
InOutParameter
*
out-interfaces
*
Page 9Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 10Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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;
};};
Page 11Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 12Building Reliable Component-based Systems Chapter 2 -Specification of Software 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.
Page 13Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 14Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 15Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 16Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 17Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 18Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 19Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 20Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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)
Page 21Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 22Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 23Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
Interface dependencyInterface dependency
<<comp spec>>SomeComponent
ISomeInterface
IAnotherInterface
IUsedInterface
Page 24Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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
Page 25Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
Specifying Extra-Functional PropertiesSpecifying Extra-Functional Properties
Conventional software doctrine is the view that software specifications must be:
Sufficient Complete Static Homogeneous
Page 26Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 27Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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.
Page 28Building Reliable Component-based Systems Chapter 2 -Specification of Software 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.
Page 29Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
Extra-functional PropertiesExtra-functional PropertiesComponent
Interface
Operation
*
in-interfaces*
*
*
AttributeValueCredibilityIsPostulate : Boolean
Credential
*1
* 1
*
1
Parameter
1
*
Type1 *
*
out-interfaces
*
Page 30Building Reliable Component-based Systems Chapter 2 -Specification of Software Components
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