1. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 1 Advanced Topics in Object Technology Bertrand Meyer

2. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 2 Lecture 24: Agents and event-driven design

3. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 3 Avoiding glue code Event producer (e.g. GUI) Business model (application logic) Connection object Direct subscription

4. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 6 Error handling: with agents execute ([agent action1, agent action2 (...), agent action3 (...)]) if glitch then warning (glitch_message) end

7. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 10 Tuple classes  Syntax: TUPLE [X, Y, …] TUPLE TUPLE [A] TUPLE [A, B]

11. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 14 Features of routine classes call (values: ARGS) item (values: ARGS): RES -- 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 := x + i * step end

21. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 23 Iterators (cont’d) for_all there_exists do_all do_if do_while do_until

24. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 26 Inline agents (under discussion) my_employee_list.do_all (do count := count + 1 end)

27. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 27 Lessons: On language design & evolution  Maximize Signal Noise  Provide one good way to do anything  Dogmatism / Consistency?

28. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 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 ATOT - Lecture 24, 25 June 2003 29 Is this a new programming paradigm?  Lack of a methodology

30. Chair of Software Engineering ATOT - Lecture 24, 25 June 2003 30 End of lecture 24