Specification of Software Components

1. Specification of Software Components Frank Lüders Mälardalen University, Dept. of Computer Engineering frank.luders@mdh.se CBSE – graduate course

2. 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 CBSE – graduate course

3. 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. CBSE – graduate course

4. 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 CBSE – graduate course

5. Simple UML Class Models CBSE – graduate course

6. UML Class Diagram CBSE – graduate course

7. UML Class Diagram with Generalization CBSE – graduate course

8. Aggregation and Composition CBSE – graduate course

9. UML Metamodel CBSE – graduate course

10. Syntactic Specification • A component implements a set of named interfaces and can require a set of interfaces implemented by others • An interface implements a set of named operations • An operation has a set of input and output parameterswith 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. CBSE – graduate course

11. A Generic Model of Syntactic Specifications CBSE – graduate course

12. 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; }; }; CBSE – graduate course

13. 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 CBSE – graduate course

14. 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 CBSE – graduate course

15. A Generic Model for Semantic Specifications CBSE – graduate course

16. Example: UML Component Specification CBSE – graduate course

17. 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 = words@pre->including (word) context SpellChecker ISpellCheck::words = ICustomSpellCheck::words CBSE – graduate course

18. 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 • Documentation – supplementary to natural language CBSE – graduate course

19. Specification and CBSE Methodology • Methods using syntactic specification • “Normal” OO-methods, e.g. using UML • Directly supported by component technologies • Methods using semantic specification and UML/OCL • UML Components (Cheesman, Daniels, 2001) • Catalysis (D’Souza, Wills, 1998) • Methods using extra-functional specification • Ensemble (Wallnau, Stafford, 2001) CBSE – graduate course

20. 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 CBSE – graduate course