Beyond 2000 Beyond ObjectOrientation Intro GP AOP FP

Beyond 2000, Beyond Object-Orientation Intro GP AOP FP Com End 2000 -05 -05 László Kozma <kozma@ludens. elte. hu> Ákos Frohner <szamcsi@elte. hu> Tamás Kozsik <kto@elte. hu> Zoltán Porkoláb <gsd@elte. hu> Beyond 2 k Beyond OO

Introduction Intro GP AOP FP Com End • • 2000 -05 -05 Paradigms Object-orientation Generic programming Aspect-oriented programming Functional programming Component-oriented software technology Conclusion Beyond 2 k Beyond OO 2

Object-Orientation • Object • Class – data structure – operation – role Intro GP AOP FP Com End • Inheritance hierarchy • Polymorphism (inclusion) 2000 -05 -05 Beyond 2 k Beyond OO 3

GP - Example (1) Intro GP AOP FP Com End 2000 -05 -05 class stack { public: virtual void push( ? ); virtual ? pop(); //. . . private: int capacity; int stack_ptr; ? *elems; //. . . }; Beyond 2 k Beyond OO class int. Stack { public: void push(int); int pop(); }; class ptr. Stack { public: void push(char*); char* pop(); }; 4

GP - Example (2) Intro GP AOP FP Com End 2000 -05 -05 template <typename T> class stack { public: virtual void push( T ); virtual T pop(); //. . . private: int capacity; int stack_ptr; T *elems; //. . . }; Beyond 2 k Beyond OO 5

Generic Programming • • Intro GP AOP FP Com End Compile-time type checking Automatic instantiation Efficient ( vs. Reflection ) Simple • Negative variance: template specialisation • (Parametric) Polymorphism 2000 -05 -05 Beyond 2 k Beyond OO 6

GP - Standard Template Library • A. Stepanov, D. Musser • ADA, C++, JAVA (Pizza, GJ, Collection) • C++ Standard Template Library Intro GP AOP FP Com End – containers – algorithms – iterators • Part of the ISO C++ standard (1997) 2000 -05 -05 Beyond 2 k Beyond OO 7

Standard Template Library Iterator Find Vector Iterator Intro GP AOP FP Com End 2000 -05 -05 Merge Iterator List Beyond 2 k Beyond OO 8

GP - Coexistence with OO • C++ Standard Library (!= STL) template <class Char. Type, class Attr=char_traits<Char. Type>, class Allocator=allocator<T>> class basic_string { … }; Intro GP AOP FP Com End typedef basic_string<char> string; • Reduce interface-size • Template specialisation 2000 -05 -05 Beyond 2 k Beyond OO 9

Aspect-Oriented Programming • The need - poor modularity: – – Intro GP AOP FP Com End shared resources (locking) multi-object protocols error handling complex performance optimisations • The solution - crossing boundaries: 2000 -05 -05 – crosscutting concerns in one source file (aspect) – weaver or pre-processor to scatter the aspects Beyond 2 k Beyond OO 10

AOP - OO Example Monitoring of a system’s state. The “system”: Intro GP AOP FP Com End 2000 -05 -05 public class Variable { private int v; public Variable() { v = 0; } public int get. V() { return v; } public void set. V(int v) { this. v = v; } } Beyond 2 k Beyond OO 11

AOP - Monitoring: displaying the state on each change Solutions: Intro GP AOP FP Com End – producer-observer pattern (needs to subclass from a specific class) – introspection - catching method calls (needs special run-time architecture like Component Filters; has runtime overhead) Goal: 2000 -05 -05 – do not modify the original source (by hand) – do not add unnecessary run-time complexity Beyond 2 k Beyond OO 12

AOP - Aspect Monitoring code: Intro GP AOP FP Com End 2000 -05 -05 aspect Trace { advise * Variable. *(. . ) { static before { System. out. println("Entering " + this. Join. Point. method. Name + " v=" + this. Object. v); } static after { System. out. println("Exiting " + this. Join. Point. method. Name + " v=" + this. Object. v); } } } Beyond 2 k Beyond OO 13

AOP - Aspect. J • Implementation: Java/Aspect. J from Xerox • weaver: general-purpose source level preprocessor Intro GP AOP FP Com End 2000 -05 -05 – – – crossing normal visibility borders adding new methods adding common private variables code segments before and after old methods affecting otherwise unrelated classes Beyond 2 k Beyond OO 14

AOP - Woven Intro GP AOP FP Com End 2000 -05 -05 public class Variable { private int v; public Variable() { v = 0; } public int get. V() { int this. Result; System. out. println("Entering "+"get. V"+" v="+this. v); this. Result = v; System. out. println("Exiting "+"get. V"+" v="+this. v); return this. Result; } public void set. V(int v) { System. out. println("Entering "+"set. V"+" v="+this. v); this. v = v; System. out. println("Exiting "+"set. V"+" v="+this. v); } } Beyond 2 k Beyond OO 15

AOP - Coexistence with OO • Aspects reduce code repetition – improves readability – improves maintainability Intro GP AOP FP Com End • Mature OO design can be applied in large-scale • Aspects may be written in any language (weaver implementation is the only limitation) 2000 -05 -05 Beyond 2 k Beyond OO 16

Functional programming languages • Functional program = a set of function definitions + an expression to be evaluated • Usual properties Intro GP AOP FP Com End – support parametric polymorphism (see Generic Programming) – advance program correctness – flexible manipulations with functions • co-exist with object-oriented programming 2000 -05 -05 Beyond 2 k Beyond OO 17

FP - Parametric Polymorphism • modern functional languages (ML, Miranda, Haskell, Clean) length : : [a] -> Int // optional type specification length [] = 0 length [first: rest] = 1 + length rest Intro GP AOP FP Com End • application: length [1, 2, 3, 4] evaluates to 4 • applicable to lists regardless of base type • only one compiled function, used everywhere 2000 -05 -05 Beyond 2 k Beyond OO 18

FP - Program Correctness (1) • correct programs are hard to write – formal methods – testing • Intro GP AOP FP Com End formal methods are often hard to use in practice – code is too large (complexity explosion) – gap between specification and implementation • 2000 -05 -05 solutions – object-oriented programming – functional programming Beyond 2 k Beyond OO 19

FP - Program Correctness (2) What does OOP offer? Intro GP AOP FP Com End - implementation decisions encapsulated in objects + reduce complexity by appropriately structuring the program + (sometimes does not work -> see GP, AOP) - model the real world + objects and their relations correspond to entities of the real world + solve the problem in the problem domain 2000 -05 -05 Beyond 2 k Beyond OO 20

FP - Program Correctness (3) What does FP offer? (1) - executable specifications + radically reduce the gap between specification and implementation + support abstraction by focusing on "what" instead of "how" Intro GP AOP FP Com End 2000 -05 -05 qsort [] = [] qsort [x: xs] = qsort [y <- xs | y<x] +++ [x] +++ qsort [y <- xs | y>=x] Beyond 2 k Beyond OO 21

FP - Program Correctness (4) What does FP offer? (2) Intro GP AOP FP Com End 2000 -05 -05 - forces programming without side-effects + easy to reason about programs + simple mathematical machinery + semi-automatic proof tools Beyond 2 k Beyond OO 22

FP - Manipulations with computations (functions) • functions as parameters or results + example: the "map" function, element wise processing on a list: map inc [1, 2, 3, 4] evaluates to [2, 3, 4, 5] + similar possibilities are already present Intro GP AOP FP Com End • pointers to functions in C • subprogram types in Modula 2 • functions as generic parameters in Ada • greater flexibility, increased expressive power + e. g. currying: partial applications: map ((+) 2) [1, 2, 3, 4] evaluates to [3, 4, 5, 6] 2000 -05 -05 Beyond 2 k Beyond OO 23

FP - co-existence with OOP modern func. langs support many OOP concepts – abstract data types by type classes - allow alternative representations - similar to Java interfaces class Stack s e where push : : s e -> s pop : : s e -> s top : : s e -> e Intro GP AOP FP Com End 2000 -05 -05 instance Stack [e] e where push list elem = [elem: list] pop [first: rest] = rest top [first: rest] = first – record types with functional components • powerful dynamic binding • existential types -> inhomogeneity – encapsulation (modules, abstract datatypes) – subtyping, inheritance and dynamic types Beyond 2 k Beyond OO 24

FP - Conclusion • functional programming can co-exist with OOP • the marriage endows OOP with valuable properties • promising future (efficiency problems are disappearing, e. g. Clean) Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 25

Component-oriented programming Intro GP AOP FP Com End • New trend in the development of software applications is away from closed systems towards open system. • Opens systems must be ˝open˝ in at least three ways: topology platform evolution 2000 -05 -05 Beyond 2 k Beyond OO 26

Component-oriented programming • Topology – Open applications run on configurable networks. • Platform – The hardware and software platforms are heterogeneous. Intro GP AOP FP Com End • Evolution 2000 -05 -05 – Requirements are unstable and constantly change Beyond 2 k Beyond OO 27

Object-Oriented Software Development Intro GP AOP FP Com End • It partially addresses these needs by hiding data representation and implementation details behind object-oriented interfaces, thus permitting multiple implementations of objects to coexists while protecting clients from changes in implementation or representation. 2000 -05 -05 Beyond 2 k Beyond OO 28

Evolution II. Intro GP AOP FP Com End • Evolution is only partially addressed, however, since changes in requirements may entail changes in the way that the objects are structured and configured. • It is necessary to view each application as only one instance of a generic class of applications, each built up of reconfigurable software components. 2000 -05 -05 Beyond 2 k Beyond OO 29

Component Intro GP AOP FP Com End • The notion of component is more general than that of an object, and in particular may be of either much finer or coarser granularity. • An object encapsulates data and its associated behavior, whereas a component may encapsulate any useful software abstraction. 2000 -05 -05 Beyond 2 k Beyond OO 30

From Methodological Aspect Intro GP AOP FP Com End • A component is a component because it has been designed to be used in a compositional way together with other components. It is designed as part of a framework of collaborating components. Components need not be classes and frameworks need not be abstract class hierarchies. 2000 -05 -05 Beyond 2 k Beyond OO 31

Examples • Valid examples of components may be: Intro GP AOP FP Com End 2000 -05 -05 functions macros procedures templates modules Beyond 2 k Beyond OO 32

From Technical Aspect • At a software technology level, the vision of component-oriented development is a very old idea, which was already present in the first developments of structured programming and modularity. Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 33

Implementation Intro GP AOP FP Com End • Component-oriented software development is not easy to realize for both technological and methodological reasons. • For a programming language to support component-oriented development, it must integrate both computational and compositional aspects of software development. 2000 -05 -05 Beyond 2 k Beyond OO 34

Computational and compositional aspects • An application can be viewed simultaneously as a computational entity that delivers results and • as a construction of software components that fit together to achieve those results. Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 35

Integration • The integration of these two aspects is not straightforward, since their goals may conflict. For example concurrency mechanisms, which are computational, may conflict with inheritance, which is a compositional features Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 36

Semantic Foundation Intro GP AOP FP Com End • In order to achieve a clean integration of computational and compositional features a common semantic foundation is needed in which one may reason about both kinds of features and their interplay. • The key concepts of such foundations are: objects functions agents. 2000 -05 -05 Beyond 2 k Beyond OO 37

Exact Notion of Components • A component is a static abstraction with plugs • Static – By ˝static˝, we mean that a software component is a long-lived entity that can be stored in a software base, independently of the applications in which it has been used. Intro GP AOP FP Com End • Abstraction – By “abstraction”, we mean that a component puts a more or less opaque boundary around the software it encapsulates. • With plugs 2000 -05 -05 – “With plugs” means that there are well-defined ways to interact and communicate with the component (parameters, ports, Beyond 2 k Beyond OO messages, etc. ) 38

Outside view of a component • Seen from the outside, a component is a single entity, which may be moved around a copied , and in particular may be instantiated in a particular context, where the plugs will be bound to values or to other components. Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 39

Technical Support • Component-oriented software development not only requires a change of mind-set and methodology but it also requires new technological support. Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 40

Technical Support II. • Some issues that arise: Intro GP AOP FP Com End 2000 -05 -05 – – – – paradigm and mechanism for binding components together structure of a software component characterization of the composition process formal model of components and composition, verification method of correct compositions concurrent computational model and software composition. Beyond 2 k Beyond OO 41

Assembling Components • The fundamental composition mechanisms are the following: Intro GP AOP FP Com End 2000 -05 -05 - functional composition - blackboard - extensibility. Beyond 2 k Beyond OO 42

Functional composition Intro GP AOP FP Com End • This is the most fundamental composition mechanism. In this paradigm one entity is first encapsulated and parameterized as a functional abstraction, and is instantiated by receiving arguments that are bound to its parameters. This compositional mechanism occurs in nearly every programming environment not only in functional programming languages. 2000 -05 -05 Beyond 2 k Beyond OO 43

Blackboard • Agent environments use a global composition mechanism often called a blackboard. Intro GP AOP FP Com End • A blackboard is a shared space, known by every component, in which information can be put and retrieved at particular locations. For systems of agents communicating through channels, the blackboard is the global space of channel names. 2000 -05 -05 Beyond 2 k Beyond OO 44

Extensibility Intro GP AOP FP Com End • Object-oriented systems have introduced a new paradigm for software composition with the notion of extensibility - the possibility of adding functionality to a component while remaining “compatible” with its previous uses. • Extensibility is obtained in object-oriented languages through inheritance 2000 -05 -05 Beyond 2 k Beyond OO 45

Structure of a Software Component Intro GP AOP FP Com End • Components are static entities; moreover, they always consists of some kind of abstraction. • Static software entities are procedures, functions, modules, classes etc. - A procedure is an abstraction for a sequence of instructions. - A class is an abstraction for a collection of objects. - A module is a a set of named abstractions. • All software components are treated as first-class values that can be passed as parameters to other components. 2000 -05 -05 Beyond 2 k Beyond OO 46

The Composition Process • A component -oriented lifecycle is needed. Intro GP AOP FP Com End 2000 -05 -05 Beyond 2 k Beyond OO 47

Verification of Composition Intro GP AOP FP Com End • Whenever components are assembled to perform a common task, there is always an implicit contract between them about the terms of the collaboration. • Two approach can be taken for dealing with verifying the correctness of a configuration: - Meyer’s approach used in Eiffel - improve the expressiveness of type system. 2000 -05 -05 Beyond 2 k Beyond OO 48

Concurrency and Components • Features needed to model in a language that supports component-oriented development: - Active Objects: objects can be viewed as autonomous agents or processes. - Components: they are abstractions over the computational space of active objects. Intro - Composition: generalized composition is supported, GP not just inheritance. AOP FP - Types: both objects and components have typed Com End interfaces. - Subtypes: subtyping should be based on a notion of “plug compatibility“. Beyond 2 k Beyond OO 2000 -05 -05 49

Conclusion Old and new paradigms could/should live together: multi-paradigm programming Advantages: Intro GP AOP FP Com End 2000 -05 -05 – – – OO: mature large-scale design, good modularity GP: parametrised type constructs AOP: crosscutting concerns FP: formal-proof, data-flow optimisation Components: easy deployment and configuration Beyond 2 k Beyond OO 50