1 ObjectOriented Software Construction Bertrand Meyer Chair of

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

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

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

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

Error handling example: without agents action 1 if ok 1 then action 2 if ok 2 then action 3. . . More processing, more nesting. . . end Chair of Software Engineering OOSC - Summer Semester 2004 5

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

Normal call vs. agent § Normal call a 0. f (a 1, a 2, a 3) § Agent call (expression): preface it by keyword agent, yielding agent a 0. f (a 1, a 2, a 3) § For example: u : = agent a 0. f (a 1, a 2, a 3) § 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”. Chair of Software Engineering OOSC - Summer Semester 2004 7

Type of closed agent expression § In class C: f (x 1: T 1; x 2: T 2; x 3: T 3) is do. . . end u : = agent f (a 1, a 2, a 3) § In some other class: a 0: C v : = agent a 0. f (a 1, a 2, a 3) § Type of both u and v: u, v: PROCEDURE [C, TUPLE] Chair of Software Engineering OOSC - Summer Semester 2004 8

Tuples 9 § 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 Chair of Software Engineering OOSC - Summer Semester 2004

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

Mathematical model for tuples 11 § 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: {<1, "a">, <2, "a">, <3, "a">} § 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]. Chair of Software Engineering OOSC - Summer Semester 2004

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 Chair of Software Engineering OOSC - Summer Semester 2004 12

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

Features of routine classes 14 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. Chair of Software Engineering OOSC - Summer Semester 2004

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 a 0. f (a 1, a 2, a 3) -- All closed (as before) w : = agent a 0. f (a 1, a 2, ? ) x : = agent a 0. f (a 1, ? , a 3) y : = agent a 0. f (a 1, ? ) z : = agent a 0. f (? , ? ) Chair of Software Engineering OOSC - Summer Semester 2004 15

Agent types 16 § Reminder: PROCEDURE [BASE, ARGS –> TUPLE] f (x 1: T 1; x 2: T 2; x 3: T 3) is -- in class C do . . . end agent a 0. f (a 1, a 2, a 3) agent a 0. f (a 1, a 2, ? ) PROCEDURE [C, TUPLE] -- All closed PROCEDURE [C, TUPLE [T 3]] agent a 0. f (a 1, ? , a 3) PROCEDURE [C, TUPLE [T 2]] agent a 0. f (a 1, ? ) PROCEDURE [C, TUPLE [T 2, T 3]] agent a 0. f (? , ? ) PROCEDURE [C, TUPLE [T 1, T 2, T 3]] Chair of Software Engineering OOSC - Summer Semester 2004

Calling an agent a 0: C; a 1: T 1; a 2: T 2; a 3: T 3 u : =agent a 0. f (a 1, a 2, a 3) PROCEDURE [C, TUPLE] u. call ([]) v : = agent a 0. f (a 1, a 2, ? ) PROCEDURE [C, TUPLE [T 3]] v. call ([a 3]) w : = agent a 0. f (a 1, ? , a 3) PROCEDURE [C, TUPLE [T 2]] w. call ([a 2]) x : = agent a 0. f (a 1, ? ) PROCEDURE [C, TUPLE [T 2, T 3]] x. call ([a 2, a 3]) y : = agent a 0. f (? , ? ) PROCEDURE [C, TUPLE [T 1, T 2, T 3]] y. call ([a 1, a 2, a 3]) Chair of Software Engineering OOSC - Summer Semester 2004 17

Keeping the target open r : = agent {T 0}. f (a 1, a 2, a 3) -- Target open, arguments closed Type is: PROCEDURE [T 0, TUPLE [T 0]] Example call: r. call ([a 0]) s : = agent {T 0}. f (? , ? ) -- Open on all operands -- Can also be written as just: agent {T 0}. f Type is: PROCEDURE [T 0, TUPLE [T 0, T 1, T 2, T 3]] Example call: s. call ([a 0, a 1, a 2, a 3]) Chair of Software Engineering OOSC - Summer Semester 2004 18

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) Chair of Software Engineering OOSC - Summer Semester 2004 19

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 Chair of Software Engineering OOSC - Summer Semester 2004 20

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) Chair of Software Engineering OOSC - Summer Semester 2004 21

Iterators 22 § 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 Chair of Software Engineering OOSC - Summer Semester 2004

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

Command classes 24 § 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. Chair of Software Engineering OOSC - Summer Semester 2004

Command classes (cont’d) 25 § 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 Chair of Software Engineering OOSC - Summer Semester 2004

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

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

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. ” Chair of Software Engineering OOSC - Summer Semester 2004 28

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

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