Beyond 2000, Beyond ObjectOrientation

1
Beyond 2000, Beyond Object-Orientation

• László Kozma ltkozma_at_ludens.elte.hugt
• Ákos Frohner ltszamcsi_at_elte.hugt
• Tamás Kozsik ltkto_at_elte.hugt
• Zoltán Porkoláb ltgsd_at_elte.hugt

2
Introduction

• Paradigms
• Object-orientation
• Generic programming
• Aspect-oriented programming
• Functional programming
• Component-oriented software technology
• Conclusion

3
Object-Orientation

• Object
• Class
• data structure
• operation
• role
• Inheritance hierarchy
• Polymorphism (inclusion)

4
GP - Example (1)
class intStack public void push(int)
int pop() class ptrStack public void
push(char) char pop()

• class stack
• public
• virtual void push( ? )
• virtual ? pop()
• // ...
• private
• int capacity
• int stack_ptr
• ? elems
• // ...

5
GP - Example (2)

• template lttypename Tgt
• class stack
• public
• virtual void push( T )
• virtual T pop()
• // ...
• private
• int capacity
• int stack_ptr
• T elems
• // ...

6
Generic Programming

• Compile-time type checking
• Automatic instantiation
• Efficient ( vs. Reflection )
• Simple
• Negative variance template specialisation
• (Parametric) Polymorphism

7
GP - Standard Template Library

• A. Stepanov, D. Musser
• ADA, C, JAVA (Pizza, GJ, Collection)
• C Standard Template Library
• containers
• algorithms
• iterators
• Part of the ISO C standard (1997)

8
Standard Template Library
Find
Iterator
Vector
Merge
Iterator
Iterator
List
9
GP - Coexistence with OO

• C Standard Library (! STL)
• Reduce interface-size
• Template specialisation

template ltclass CharType, class
Attrchar_traitsltCharTypegt, class
AllocatorallocatorltTgtgt class basic_string
typedef basic_stringltchargt string
10
Aspect-Oriented Programming

• The need - poor modularity
• shared resources (locking)
• multi-object protocols
• error handling
• complex performance optimisations
• The solution - crossing boundaries
• crosscutting concerns in one source file (aspect)
• weaver or pre-processor to scatter the aspects

11
AOP - OO Example

• Monitoring of a systems state.
• The system
• public class Variable
• private int v
• public Variable() v 0
• public int getV() return v
• public void setV(int v) this.v v

12
AOP - Monitoring

• Monitoring displaying the state on each change
• Solutions
• 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
• do not modify the original source (by hand)
• do not add unnecessary run-time complexity

13
AOP - Aspect

• Monitoring code
• aspect Trace
• advise Variable.(..)
• static before
• System.out.println("Entering "
• thisJoinPoint.methodName " v"
  thisObject.v)
• static after
• System.out.println("Exiting "
• thisJoinPoint.methodName " v"
  thisObject.v)

14
AOP - AspectJ

• Implementation Java/AspectJ from Xerox
• weaver general-purpose source level preprocessor
• crossing normal visibility borders
• adding new methods
• adding common private variables
• code segments before and after old methods
• affecting otherwise unrelated classes

15
AOP - Woven

• public class Variable
• private int v
• public Variable() v 0
• public int getV()
• int thisResult
• System.out.println("Entering ""getV""
  v"this.v)
• thisResult v
• System.out.println("Exiting ""getV""
  v"this.v)
• return thisResult
• public void setV(int v)
• System.out.println("Entering ""setV""
  v"this.v)
• this.v v
• System.out.println("Exiting ""setV""
  v"this.v)

16
AOP - Coexistence with OO

• Aspects reduce code repetition
• improves readability
• improves maintainability
• Mature OO design can be applied in large-scale
• Aspects may be written in any language(weaver
  implementation is the only limitation)

17
Functional programming languages

• Functional program a set of function
  definitions an expression to be evaluated
• Usual properties
• support parametric polymorphism(see Generic
  Programming)
• advance program correctness
• flexible manipulations with functions
• co-exist with object-oriented programming

18
FP - Parametric Polymorphism

• modern functional languages (ML, Miranda,
  Haskell, Clean)
• length a -gt Int // optional type
  specification
• length 0
• length firstrest 1 length rest
• application length 1,2,3,4 evaluates to 4
• applicable to lists regardless of base type
• only one compiled function, used everywhere

19
FP - Program Correctness (1)

• correct programs are hard to write
• formal methods
• testing
• formal methods are often hard to use in
  practice
• code is too large (complexity explosion)
• gap between specification and implementation
• solutions
• object-oriented programming
• functional programming

20
FP - Program Correctness (2)

• What does OOP offer?
• - implementation decisions encapsulated in
  objects
• reduce complexity by appropriately structuring
  the program
• (sometimes does not work -gt 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

21
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"
• qsort
• qsort xxs qsort y lt- xs yltx
• x
• qsort y lt- xs ygtx

22
FP - Program Correctness (4)

• What does FP offer? (2)
• - forces programming without side-effects
• easy to reason about programs
• simple mathematical machinery
• semi-automatic proof tools

23
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
• 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

24
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 instance Stack
  e e where
• push s e -gt s push list
  elem elemlist
• pop s e -gt s pop
  firstrest rest
• top s e -gt e top
  firstrest first
• record types with functional components
• powerful dynamic binding
• existential types -gt inhomogeneity
• encapsulation (modules, abstract datatypes)
• subtyping, inheritance and dynamic types

25
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)

26
Component-oriented programming

• 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

27
Component-oriented programming

• Topology
• Open applications run on configurable networks.
• Platform
• The hardware and software platforms are
  heterogeneous.
• Evolution
• Requirements are unstable and constantly change

28
Object-Oriented Software Development

• 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.

29
Evolution II.

• 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.

30
Component

• 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.

31
From Methodological Aspect

• 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.

32
Examples

• Valid examples of components may
  be functions macros procedures templates
  modules

33
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.

34
Implementation

• 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.

35
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.

36
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

37
Semantic Foundation

• 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.

38
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.
• Abstraction
• By abstraction, we mean that a component puts a
  more or less opaque boundary around the software
  it encapsulates.
• With plugs
• With plugs means that there are well-defined
  ways to interact and communicate with the
  component (parameters, ports, messages, etc.)

39
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.

40
Technical Support

• Component-oriented software development not only
  requires a change of mind-set and methodology but
  it also requires new technological support.

41
Technical Support II.

• Some issues that arise
• 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.

42
Assembling Components

• The fundamental composition mechanisms are the
  following - functional composition -
  blackboard - extensibility.

43
Functional composition

• 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.

44
Blackboard

• Agent environments use a global composition
  mechanism often called a blackboard.
• 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.

45
Extensibility

• 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

46
Structure of a Software Component

• 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.

47
The Composition Process

• A component -oriented lifecycle is needed.

48
Verification of Composition

• 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 -
  Meyers approach used in Eiffel - improve the
  expressiveness of type system.

49
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. - Composition
  generalized composition is supported, not just
  inheritance. - Types both objects and
  components have typed interfaces. - Subtypes
  subtyping should be based on a notion of plug
  compatibility.

50
Conclusion

• Old and new paradigms could/should live together
• multi-paradigm programming
• Advantages
• 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