Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

Transcription

1 1 Last update: 2 November 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout

2 2 Lecture 12: Componentization

3 Agenda for today 3 Componentization Componentizability classification Role of language mechanisms Validation strategy Previous work

4 Design patterns: no reusable solution 4 Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to this problem in such a way that you can use this solution a million times over, without ever doing it the same way twice. Erich Gamma et al., Design Patterns, 1995 NOT REUSABLE

5 Assumption and conjecture 5 Assumption: It is better to reuse than to redo (even to redo with the help of a model) Conjecture: Many design patterns can be turned into reusable components

6 Challenge of this work 6 Patterns are not, by definition, fully formalized descriptions. They can t appear as a deliverable. J-M. Jézéquel, Design Patterns and Contracts, 1999, p 22 Challenge: Provide reusable components that programmers can reuse directly without recoding the same functionalities again and again

7 Target audience 7 Program implementers Program designers Library developers Programming language designers Both academia and industry

8 Componentization: a definition 8 Process of devising a reusable component that provides a ready-made implementation of a design pattern directly usable by any client application. A design pattern is given by one or more of A description of the pattern s intent Use cases A software architecture for typical implementations

9 Componentization mechanisms 9 Client-supplier relationship Simple inheritance Multiple inheritance Unconstrained genericity Constrained genericity Design by Contract Automatic type conversion Agents Aspects 2 categories of patterns: Componentizable Non-componentizable

10 Genericity 10 class STACK [G] feature Formal generic parameter end put (x: G) is... item: G is... To use the class: obtain a generic derivation, e.g. account_stack: STACK [ACCOUNT] Actual generic parameter

11 Using generic derivations 11 point_stack: STACK [POINT] p, q, r: POINT... point_stack.put (p) point_stack.put (q) r := point_stack.item r. move (3.0, 5.0)

12 Adding two vectors 12 u + v = w i a b c

13 Constrained genericity 13 class VECTOR [G] feature infix "+" (other: VECTOR [G]): VECTOR [G] is -- Sum of current vector and other require other_not_void: other /= Void lower_compatible: lower = other.lower upper_compatible: upper = other.upper local a, b, c: G do... See next... end... Other features... end

14 Constrained genericity 14 The body of infix "+": create Result.make (lower, upper) from i := lower until i > upper loop a := item (i) b := other.item (i) c := a + b -- Requires a + operation on G! Result.put (c, i) i := i + 1 end

15 Constrained genericity: The solution 15 Declare class VECTOR as class feature end VECTOR [G > NUMERIC]... The rest as before... Class NUMERIC (from the Kernel Library) provides features infix "+", infix "*",.

16 Componentization mechanisms 16 Client-supplier relationship Simple inheritance Multiple inheritance Unconstrained genericity Constrained genericity Design by Contract Automatic type conversion Agents Aspects

17 Automatic type conversion (1/2) 17 class MY_CLASS create from_type_1 convert from_type_1 ({TYPE_1}) to_type_2: {TYPE_2} feature -- Conversion from_type_1 (arg: TYPE_1) is -- Build from arg. do -- Something end to_type_2: TYPE_2 is -- Instance of TYPE_2 built from Current object do -- Something end end

18 Automatic type conversion (2/2) 18 my_attribute: MY_TYPE attribute_1: TYPE_1 attribute_2: TYPE_2... my_attribute + attribute_1 -- Equivalent to: -- my_attribute + create {MY_TYPE}.from_type_1 (attribute_1) attribute_2 + my_attribute -- Equivalent to: -- attribute_2 + my_attribute.to_type_2

19 Componentization mechanisms 19 Client-supplier relationship Simple inheritance Multiple inheritance Unconstrained genericity Constrained genericity Design by Contract Automatic type conversion Agents Aspects

20 Agents 20 Object encapsulating a routine ready to be called May be viewed as: Delayed call, or typed function pointer To create an agent: my_routine := agent my_feature To call an agent: my_routine.call ([args]) Lecture 10

21 Componentization mechanisms 21 Client-supplier relationship Simple inheritance Multiple inheritance Unconstrained genericity Constrained genericity Design by Contract Automatic type conversion Agents Aspects

22 Aspects 22 aspect DecoratedComponent { /*Special construct (called pointcut) to specify when and where the aspect * should be applied. * A pointcut typically lists the features to which the aspect applies.*/ } before: pointcutname...{ /*You may view pointcutname as a feature name as a first approximation.*/ dosomething; } after: pointcutname...{ dosomething; } around: pointcutname...{ if (somecondition) proceed (); else System.out.println ( Error ); }

23 Criteria for success 23 Completeness Usefulness Faithfulness Type-safety Performance Extended applicability

24 Type-safety: Definition 24 Property of a system for which any call of the form x.f (a) that is valid at compilation time, there exists exactly one version of f applicable to the dynamic type of x at run time and this version of f has the right number of arguments and the appropriate types.

25 Why are the components trusted? 25 Extensive use of contracts Criteria assessing the quality of the components: Completeness Usefulness Faithfulness Type-safety Performance Extended applicability

26 Componentization statistics 26 Category Number of patterns Percentage Componentizable patterns 15 65% Non-componentizable patterns 8 35% Category Number of patterns Percentage Componentizable patterns 15 65% Non-componentizable patterns (possible skeleton classes or some library support) Remaining patterns (no skeleton classes and no library support) 6 26% 2 9%

27 Agenda for today 27 Componentization Componentizability classification Role of language mechanisms Validation strategy Previous work

28 Componentizability classification 28 Design pattern 1. Componentizable 2. Non-componentizable 1.1 Built-in 1.2 Librarysupported 1.3 Newly componentized 1.4 Possible component 2.1 Skeleton 2.2 Possible skeleton 2.3 Some library support 2.4 Design idea Fully componentizable Componentizable but not comprehensive Componentizable but unfaithful Componentizable but useless Method No method

29 Componentizability classification 29 Design pattern 1. Componentizable 2. Non-componentizable 1.1 Built-in Prototype 1.2 Librarysupported 1.3 Newly componentized 1.4 Possible component 2.1 Skeleton 2.2 Possible skeleton 2.3 Some library support 2.4 Design idea Singleton Iterator Facade Interpreter Fully componentizable Flyweight Observer Mediator Abstract Factory Factory Method Visitor Command Composite Chain of Responsibility Componentizable but not comprehensive Builder Proxy State Componentizable but unfaithful Strategy Componentizable but useless Memento Method Decorator Adapter No method Template Method Bridge

30 Agenda for today 30 Componentization Componentizability classification Role of language mechanisms Validation strategy Previous work

31 Fully componentizable thanks to 31 Flyweight Observer Mediator Abstract Factory Factory Method Visitor Command Composite Chain of Responsibility Unconstrained genericity Constrained genericity Agents + Design by Contract + Client-supplier relationship + Inheritance

32 Mechanisms used for componentization 32 Mechanism Unconstrained genericity (non-exclusive) Constrained genericity (non-exclusive) Agents (non-exclusive) Number of patterns Percentage % % % Approach portable to any language with these mechanisms

33 Agenda for today 33 Componentization Componentizability classification Role of language mechanisms Validation strategy Previous work

34 Correctness and validity 34 Design patterns are not formally specified: Patterns are not, by definition, fully formalized descriptions. They can t appear as a deliverable. J-M. Jézéquel, Design Patterns and Contracts, Componentization: 1999, p 22. Understanding of each pattern explicit through assertions

35 Semantics of design patterns 35 Patterns have a description (intent) e.g. Chain of Responsibility: Avoid coupling the sender of a request to its received by giving more than one object a change to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. [GoF, 223] No formal specification Components add semantics through contracts e.g. class HANDLER [G] has can_handle, handled used in postcondition of handle ensure can_handle (a_request) implies handled (not can_handle (a_request) and then next /= Void) implies handled = next.handled (not can_handle (a_request) and then next = Void) implies not handled

36 Validation strategy 36 1 st step: Test-cases Check that implementation meets the contracts 2 nd step: Use a real-world application or library Example: Visitor Library in Gobo Eiffel Lint

37 Agenda for today 37 Componentization Componentizability classification Role of language mechanisms Validation strategy Previous work

38 Patterns with AspectJ [Hannemann 2002] 38 Reusability classification (Reusability: The abstract aspect can be reused. Programmers need to write concrete aspects.) Similar to the componentizability classification, except for: Reusable / Non-componentizable, skeleton: Singleton Reusable / Non-componentizable, some library support: Iterator Not reusable / Componentizable but not comprehensive: Proxy, Builder, State Not reusable / Fully componentizable: Abstract Factory, Factory Method

39 Aspect implementation - Pros and cons 39 Strengths: Reduction of the number of pattern s participants (one aspect instead of several classes) Traceability of the patterns in the code Localization of the pattern code Reusability of the pattern code Weaknesses: Language dependency Problem shift (many small aspects vs. several classes) Difficulty to understand (aspects + classes) and to maintain

40 Componentization vs. aspects 40 [Hannemann 2002]: Reusability classification of the GoF patterns Why is componentization still useful? Reusability: The abstract aspect can be reused. Programmers need to write concrete aspects. Still requires some repetitive work from the programmers. Language dependency (not all OO language has an aspect version) Problem shift (many small aspects vs. several classes) Difficulty to understand (aspects + classes) and to maintain

41 Language support of design patterns 41 Established fact: Design patterns have proved so useful that some have called for their promotion to programming language features [Chambers 2000]. Which pattern deserves a direct language support? Chambers: Clearly, languages lacking the appropriate mechanisms benefit from tool support, but this should be viewed as an undesirable intermediate state in language development, to be replaced in the future by true language support without tools requirements. Avoid featurism [Meyer 2002]; the construct should solve a general problem (e.g. Singleton vs. frozen classes). Vlissides: While several of the more fundamental design patterns may be transliterated easily into programming language constructs, many others cannot or at least should not.

42 Design patterns are good, components are better 42 A successful pattern cannot just be a book description: it must be a software component, or a set of components. Bertrand Meyer, Object-Oriented Software Construction, 2 nd edition, 1997, p 72.

43 Complementary material 43 From Patterns to Components: Chapter 6: Pattern componentizability classification Chapter 4: Previous work 4.2 Aspect implementation 4.3 Language support

44 44 End of lecture 12