1. Chair of Software Engineering OOSC - Summer Semester 2004 1 Object-Oriented Software Construction Bertrand Meyer

2. Chair of Software Engineering OOSC - Summer Semester 2004 2 Lecture 23: Agents and event-driven design

3. Chair of Software Engineering OOSC - Summer Semester 2004 3 Avoiding glue code Event producer (e.g. GUI) Business model (application logic) Connection object Direct subscription

4. Chair of Software Engineering OOSC - Summer Semester 2004 4 Metrics example create source_line_metric.make (“Source_lines”, [ [feature_scope, agent feature_line_counter], [class_scope, agent class_line_counter] ] )

5. Chair of Software Engineering OOSC - Summer Semester 2004 5 Error handling example: without agents action1 if ok1 then action2 if ok2 then action3... More processing, more nesting... end

6. Chair of Software Engineering OOSC - Summer Semester 2004 6 Error handling: with agents execute ([agent action1, agent action2 (...), agent action3 (...)]) if glitch then warning (glitch_message) end

7. Chair of Software Engineering OOSC - Summer Semester 2004 7 Normal call vs. agent  Normal call a0.f (a1, a2, a3)  Agent call (expression): preface it by keyword agent, yielding agent a0.f (a1, a2, a3)  For example: u := agent a0.f (a1, a2, a3)  This represents the routine, ready to be called. To call it: u.call ([]) -- For type of u, see next  Recall original name of agents: “delayed calls”.

8. Chair of Software Engineering OOSC - Summer Semester 2004 8 Type of closed agent expression  In class C: f (x1: T1; x2: T2; x3: T3) is do... end u := agent f (a1, a2, a3)  In some other class: a0: C v := agent a0.f (a1, a2, a3)  Type of both u and v: u, v: PROCEDURE [C, TUPLE]

9. Chair of Software Engineering OOSC - Summer Semester 2004 9 Tuples  Purposes:  Allow manipulation of sequences of values with arbitrary number of elements, with simple structure  Support “anonymous classes”  To allow for function that return multiple results  Permit type-safe agents

10. Chair of Software Engineering OOSC - Summer Semester 2004 10 Tuple classes  Syntax: TUPLE [X, Y, …] TUPLE TUPLE [A] TUPLE [A, B]

11. Chair of Software Engineering OOSC - Summer Semester 2004 11 Mathematical model for tuples  First intuition: TUPLE [A, B, C] represents the cartesian product A x B x C  But: A x B x C cannot be mapped to a subset of A x B !  Better model:  TUPLE represents the set of partial functions from N (set of integers) to the set of possible values, whose domain includes the interval [1.. n] for some n.  Example of such a function: {,, }  An element of TUPLE [A, B, C] is a function whose domain includes the interval [1.. 3])  So it’s also an element of TUPLE [A, B]: functions whose domain includes interval [1.. 2].

12. Chair of Software Engineering OOSC - Summer Semester 2004 12 Reminder: constrained genericity  LIST [G] (unconstrained): G represents arbitrary type. May use LIST [INTEGER] LIST [EMPLOYEE] LIST [SHIP]  SORTABLE_LIST [G -> COMPARABLE] (constrained by COMPARABLE)  G represents type descending from COMPARABLE LIST [INTEGER] LIST [T] only if T descendant of COMPARABLE

13. Chair of Software Engineering OOSC - Summer Semester 2004 13 Agent types: Kernel library classes ROUTINE* [BASE, ARGS -> TUPLE] PROCEDURE* [BASE, ARGS -> TUPLE] FUNCTION* [BASE, ARGS -> TUPLE, RES] call item Inherits from * Deferred

14. Chair of Software Engineering OOSC - Summer Semester 2004 14 Features of routine classes call (values: ARGS) item (values: ARGS): RESULT_TYPE -- In FUNCTION only... target, arguments, set_target, set_arguments...  Introspection features (in progress): precondition: FUNCTION [BASE, ARGUMENTS, BOOLEAN] postcondition type: TYPE Features of class TYPE: heirs, parents, routines etc.

15. Chair of Software Engineering OOSC - Summer Semester 2004 15 Keeping arguments open  An agent can have both “closed” and “open” arguments.  Closed arguments set at time of agent definition; open arguments set at time of each call.  To keep an argument open, just replace it by a question mark: u := agent a0.f (a1, a2, a3) -- All closed (as before) w := agent a0.f (a1, a2, ?) x := agent a0.f (a1, ?, a3) y :=agent a0.f (a1, ?, ?) z :=agent a0.f (?, ?, ?)

16. Chair of Software Engineering OOSC - Summer Semester 2004 16 Agent types  Reminder: PROCEDURE [BASE, ARGS –> TUPLE] f (x1: T1; x2: T2; x3: T3) is -- in class C do... end agent a0.f (a1, a2, a3)PROCEDURE [C, TUPLE] -- All closed agent a0.f (a1, a2, ?)PROCEDURE [C, TUPLE [T3]] agent a0.f (a1, ?, a3)PROCEDURE [C, TUPLE [T2]] agent a0.f (a1, ?, ?) PROCEDURE [C, TUPLE [T2, T3]] agent a0.f (?, ?, ?)PROCEDURE [C, TUPLE [T1, T2, T3]]

17. Chair of Software Engineering OOSC - Summer Semester 2004 17 Calling an agent a0: C; a1: T1; a2: T2; a3: T3 u :=agent a0.f (a1, a2, a3)PROCEDURE [C, TUPLE] u.call ([]) v := agent a0.f (a1, a2, ?)PROCEDURE [C, TUPLE [T3]] v.call ([a3]) w := agent a0.f (a1, ?, a3)PROCEDURE [C, TUPLE [T2]] w.call ([a2]) x := agent a0.f (a1, ?, ?)PROCEDURE [C, TUPLE [T2, T3]] x.call ([a2, a3]) y := agent a0.f (?, ?, ?)PROCEDURE [C, TUPLE [T1, T2, T3]] y.call ([a1, a2, a3])

18. Chair of Software Engineering OOSC - Summer Semester 2004 18 Keeping the target open r := agent {T0}.f (a1, a2, a3) -- Target open, arguments closed Type is: PROCEDURE [T0, TUPLE [T0]] Example call: r.call ([a0]) s := agent {T0}.f (?, ?, ?) -- Open on all operands -- Can also be written as just: agent {T0}.f Type is: PROCEDURE [T0, TUPLE [T0, T1, T2, T3]] Example call: s.call ([a0, a1, a2, a3])

19. Chair of Software Engineering OOSC - Summer Semester 2004 19 Calling an agent: integration example b  my_function (x) dx a b  your_function (x, u, v) dx a my_integrator.integral (agent my_function, a, b) my_integrator.integral (agent your_function (?, u, v), a, b)

20. Chair of Software Engineering OOSC - Summer Semester 2004 20 The integral function integral (f: FUNCTION [ANY, TUPLE [REAL], REAL]; low, high: REAL): REAL is -- Integral of f over the interval [low, high] local x: REAL i: INTEGER do from x := low until x > high loop Result := Result + f.item ([x]) * step i := i + 1 x := low + i  step end

21. Chair of Software Engineering OOSC - Summer Semester 2004 21 Calling an agent: iterator all_positive := my_integer_list.for_all (agent is_positive (?)) all_married := my_employee_list.for_all (agent {EMPLOYEE}.is_married)

22. Chair of Software Engineering OOSC - Summer Semester 2004 22 Iterators  In class LINEAR [G], ancestor to all classes representing lists, sequences etc. for_all (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]) is -- Is there no item in structure that doesn’t -- satisfy test? do from start Result := True until off or not Result loop Result := test.item ([item]) forth end end

23. Chair of Software Engineering OOSC - Summer Semester 2004 23 Iterators (cont’d) for_all there_exists do_all do_if do_while do_until

24. Chair of Software Engineering OOSC - Summer Semester 2004 24 Command classes  Undo-redo design pattern  Support for undo, redo  Class COMMAND provides a procedure execute and its heir UNDOABLE_COMMAND adds undo.  Write a new class for every kind of undoable command.

25. Chair of Software Engineering OOSC - Summer Semester 2004 25 Command classes (cont’d)  Traditionally: one command class (descendant of COMMAND) for every kind of command.  Now, can transform any procedure into command: operation: PROCEDURE [CONTEXT, TUPLE] -- Operation to be applied by current command make (p: like operation) is -- Make p the current command’s operation. require p_not_void: p /= Void do operation := p ensure operation_set: operation = p end

26. Chair of Software Engineering OOSC - Summer Semester 2004 26 Inline agents (under discussion) my_employee_list.do_all (do count := count + 1 end)

27. Chair of Software Engineering OOSC - Summer Semester 2004 27 Lessons: On language design & evolution  Maximize Signal Noise  Provide one good way to do anything  Dogmatism / Consistency?

28. Chair of Software Engineering OOSC - Summer Semester 2004 28 Extensions (Eiffel: The Language, 1991) “There is one and only one kind of acceptable language extension: the one that dawns on you with the sudden self-evidence of morning mist. It must provide a complete solution to a real problem, but usually that is not enough: almost all good extensions solve several potential problems at once, through a simple addition. It must be simple, elegant, explainable to any competent user of the language in a minute or two. It must fit perfectly within the spirit and letter of the rest of the language. It must not have any dark sides or raise any unanswerable questions. And because software engineering is engineering, you must see the implementation technique.”

29. Chair of Software Engineering OOSC - Summer Semester 2004 29 Is this a new programming paradigm?  Lack of a methodology

30. Chair of Software Engineering OOSC - Summer Semester 2004 30 End of lecture 23