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

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

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

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

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

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

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

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

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

10. 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; };

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

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

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

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

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

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

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

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

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

20. 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 = words@pre->including (word) SUCCEEDED(result) implies words = words@pre->including (word) context ICustomSpellCheck::remove(in word : String) : HRESULT pre: word <> “”post: implies words = words@pre->exluding(word) SUCCEEDED(result) implies words = words@pre->exluding(word)

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

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

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

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

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

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

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

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

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

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