Page 1, CBSE – graduate course Specification of Software Components Frank Lüders Mälardalen University, Dept. of Computer Engineering

Page 2, CBSE – graduate course Outline  Introduction to Software Components and Specification  Introduction to UML Class Modeling  Syntactic Specification of Software Components  Semantic Specification of Software Components  Specification and CBSE Methodology  Conclusion

Page 3, CBSE – graduate course Software Components and Their Specification  A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parts.  Internal components: same as above, except for the independent deployment and composition by third parts.  The specification of a software component is the key to its successful use as a part in a larger piece of software.

Page 4, CBSE – graduate course Different Types/Levels of Specification  Syntactic Specification Specifies the syntax of using a component’s services Technologies such as COM, CORBA, and JavaBeans  Semantic Specification Also specifies the semantics of these services State-of-the-art CBSE methodology  Extra-Functional Specification Specifies properties besides a component’s services A fairly new research area NOT COVERED IN THIS TALK

Page 5, CBSE – graduate course Simple UML Class Models

Page 6, CBSE – graduate course UML Class Diagram

Page 7, CBSE – graduate course UML Class Diagram with Generalization

Page 8, CBSE – graduate course Aggregation and Composition

Page 9, CBSE – graduate course UML Metamodel

Page 10, CBSE – graduate course Syntactic Specification 1.A component implements a set of named interfaces and can require a set of interfaces implemented by others 2.An interface implements a set of named operations 3.An operation has a set of input and output parameters with associated types  Variations: A COM component implements a set of classes, each implementing a set of interfaces. 1 holds by association. A JavaBean is a class with one interface which can be derived from (be a subtype of) several other interfaces. An operation can have a return value. This can be viewed as an output parameter.

Page 11, CBSE – graduate course A Generic Model of Syntactic Specifications

Page 12, CBSE – graduate course Example: Specification of a COM component 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; };

Page 13, CBSE – graduate course Uses of Syntactic Specifications  Type checking of client code  Ensuring run-time interoperability COM: binary standard for interfaces (vtables) CORBA: mapping to programming languages  Ensuring syntactically safe substitution and evolution  Documentation - along with semantic descriptions

Page 14, CBSE – graduate course Semantic Specification  Extension of syntactic specification  A state model is associated with each interface  Operations have pre- and post-conditions pre: state * in-parameters -> bool post: state * state * in-parameters * out-parameters -> bool  Invariants on an interface’s state model state -> bool  Intra-interface conditions for components state1 * state2 * … -> bool

Page 15, CBSE – graduate course A Generic Model for Semantic Specifications

Page 16, CBSE – graduate course Example: UML Component Specification

Page 17, CBSE – graduate course Example: Object Constraint Language (OCL) context ISpellCheck::check(in word : String, out correct : Boolean) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies words = (word) context SpellChecker ISpellCheck::words = ICustomSpellCheck::words

Page 18, CBSE – graduate course Uses of Semantic Specification  Tool support for component developers and users Automatic correctness testing of components Checking that client code satisfies pre-conditions  Ensuring semantically safe substitution and evolution Liskov’s principle of substitution applies  Possible to substitute if new component accept larger sets and produces a smaller that the original  Documentation – supplementary to natural language

Page 19, CBSE – graduate course Specification and CBSE Methodology  Methods using extra-functional specification Ensemble (Wallnau, Stafford, 2001)

Page 20, CBSE – graduate course Conclusion  Syntactic vs. semantic specification Syntactic specs is the only form in widespread use The potential utility of semantic specs is much greater UML may lead to wider use of semantic specification  Extra-functional specification Many open issues Will probably have great impact in the future