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

Page 2 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Overview qCurrent Component Specification Techniques qSpecifying the Semantics of Components qSpecifying Extra-Functional Properties of Components qSummary

Page 3 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components What Is a Component Comprised of? qSome Code… l The code represents the operations that the component will perform when invoked qAn interface… l The interface tells the component-user everything he needs to know in order to deploy the component l 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 4 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components The Specification of an Interface q This must consist solely of: l A precise definition of the component's operations. l All context dependencies.

Page 5 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Usefulness of Component Specification q For users, l The specification provides a definition of its interface, viz. its operations and context dependencies. l Since it is only the interface that is visible to users, its specification must be precise and complete. q For developers, l The specification of a component also provides an abstract definition of its internal structure.

Page 6 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Current Component Specification Techniques qsyntactic specifications l Microsoft’s Component Object Model (COM) l Common Object Request Broker Architecture (CORBA) l JavaBeans

Page 7 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Components and Interfaces q A component provides: l The implementation of a set of named interfaces, or types, each interface being a set of named operations qThe following diagram is a UML metamodel l This model allows an interface to be implemented by several different components, and an operation to be part of several different interfaces

Page 8 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Components and Interfaces Illustrated

Page 9 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Model explained q The model presents a generic representation of: l The relationships between components, interfaces, and operations q One can distinguish between: l Object Oriented specifications and l Procedural specifications

Page 10 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components IDL Example interface ISpellCheck : IUnknown { [in] BSTR *word, [out] bool *correct HRESULT check( [in] BSTR *word, [out] bool *correct ); }; interface ICustomSpellCheck : IUnknown { [in] BSTR *word HRESULT add( [in] BSTR *word ); [in] BSTR *word HRESULT remove( [in] BSTR *word ); }; library SpellCheckerLib { coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; };

Page 11 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Specification Uses q the primary uses of such specifications are: l Type checking of client code. l A base for interoperability between independently developed components and applications. qAn important aspect of interface specifications is how they relate to substitution and evolution of components

Page 12 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Substitution q Substituting a component Y for a component X is said to be safe if: l All systems that work with X will also work with Y q From a syntactic viewpoint, a component can safely be replaced if: l The new component implements at least the same interfaces as the older components, or l The interface of the new component is a subtype of the interface of the old component.

Page 13 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Specifying the Semantics of Components q Current component technologies assume that the user of a component is able to make use of such semantic information. l COM dictates that the error codes produced by an operation are immutable, i.e. changing these is equivalent to changing the interface

Page 14 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Interfaces q A component: l Implements a set of interfaces that each consists of a set of operations. l In addition, a set of pre-conditions and post-conditions is associated with each operation.

Page 15 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components A Pre-condition q Is an assertion that the component assumes to be fulfilled before an operation is invoked. qWill in general be a predicate over the operation’s input parameters and this state

Page 16 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components A Post-condition qIs 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. q Is a predicate over both input and output parameters as well as the state just before the invocation and just after

Page 17 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components An Invariant qIs a predicate over the interface’s state model that will always hold q A set of invariants may be associated with an interface.

Page 18 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Interface specification diagram This model allows the same state to be associated with several interfaces

Page 19 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Semantic Specification in a UML metamodel

Page 20 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Interface Specification context ISpellCheck::check(in word : String, out correct : Boolean): HRESULT pre: word <> “”post: implies correct = words->includes(word) SUCCEEDED(result) implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULT pre: word <> “”post: implies words = (word) SUCCEEDED(result) implies words = (word) context ICustomSpellCheck::remove(in word : String) : HRESULT pre: word <> “”post: implies words = SUCCEEDED(result) implies words =

Page 21 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Component specification diagram 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 22 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Inter-interface Constraints qThe 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

Page 23 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Interface dependency > SomeComponent ISomeInterface IAnotherInterface IUsedInterface

Page 24 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Realization Contracts q 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 25 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Specifying Extra-Functional Properties q Conventional software doctrine is the view that software specifications must be: l Sufficient l Complete l Static l Homogeneous

Page 26 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Credentials q A Credential is a triple l Attribute: is a description of a property of a component l Value: is a measure of that property l Credibility: is a description of how the measure has been obtained q Attributes in.NET l A component developer can associate attribute values with a component and define new attributes by sub- classing an existing attribute class.

Page 27 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Architectural component q Structural properties l Governing how a component can be composed with other components. q Extra-functional properties l Such as performance, capacity, and environmental assumptions. q Family properties l Specifying relations among similar or related components.

Page 28 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Ensemble qIn Ensemble, a set of credentials may be associated with a single technology, product, or component, or with a group of such elements q A UML metamodel with the concepts of syntactic specification augmented with credentials is shown in the following slide.

Page 29 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Extra-functional Properties

Page 30 Building Reliable Component-based Systems Chapter 2 -Specification of Software Components Summary qA component has two parts: an interface and some code q In current practice, component specification techniques specify components only syntactically. q The use of UML and OCL to specify components represents a step towards semantic specifications. qSpecification 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