The Future of Computing: Aspect-Oriented Programming

and PatternsCSE301

University of Sunderland

Harry R Erwin, PhD

A Canned History of Computing

• Assembly language

• High-order languages

• Structured programming

• Modular design

• Object-oriented design

Where do we go now?

Possibilities:

• Aspect-Oriented Programming

• Patterns

Aspect-Oriented Programming:Resources

• Brian Hayes, 2003, “The post-OOP paradigm”, American Scientist, 91(2): 106-110, March-April 2003.

• Elrad, Tzilla, Robert E. Filman, and Atef Bader, ed., 2001, Aspect-Oriented Programming special issue, CACM, 44(10): 28-97.

AOP Resources

• http://en.wikipedia.org/wiki/Aspect-oriented_programming

• http://www.parc.com/research/projects/aspectj/downloads/ECOOP1997-AOP.pdf

• http://www.developer.com/design/article.php/3308941• http://www-128.ibm.com/developerworks/library/j-

aspectj/• http://www.eclipse.org/aspectj/• http://aosd.net/

A Hard OOP Problem is Finding the Right Decomposition

• Cross-cutting considerations (policies or aspects)– Security– Look and feel– Error-handling– Logging– Multi-threading– Commit

• Handling incompatible class contracts– A circle is a shape defined by a center and radius– A rectangle is a shape defined by two points– A square is a shape defined by its edge and one point.

What are Cross-Cutting Considerations?

• Factory and abstract factory patterns• Multiple inheritance. In Java, this may involve the

repetitive rewriting of aspect- or policy-related code. 8(

• Templates that use policy classes in C++. (Current research area)

• Generative programming (using a “compiler” that enforces the standard policies). This approach dates to the 1970s.

These problems are solvable.

Handling Incompatible Class Contracts

• H. S. Lahman suggests using:– Delegation– Dynamic associations– Specification objects– Parametric polymorphism

• And similar approaches instead of inheritanceHe suggests these “because is-a taxonomies are static structures that can’t be modified at run time. When they are broken they have to be fixed and that can break clients….”

Example: Parametric Polymorphism

• Visit:– http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?polymorphism

– http://www.javaworld.com/jw-02-2000/jw-02-jsr.html

• Such a polymorphic algorithm is insensitive to the types of the data being processed.

• Smalltalk works that way naturally.• In C++, this can be implemented using templates.• In Java, this requires interfaces.

AOP Ideas

• The problem is to enforce a common approach to common problems.

• This can be handled procedurally (unreliable).• These involve managing the cross-cutting

considerations using a ‘compiler’ of some sort.• That does not solve the problem with incompatible

class contracts. For that you need something other than inheritance.

• Solutions to hard problems are worth PhDs….• Is evolutionary design a solution?

Patterns

• Remember the MVC and Visual Proxy patterns from Lecture 18?

• Patterns apply to other areas of design, to programming (where they are called idioms) and to architecture (where they are called styles).

• You’ve seen a number of idioms in previous lectures.• This will be a quick survey of patterns and architectural

styles based on the discussion in Graham, 2001, Object-Oriented Methods, 3rd edition, Addison-Wesley, of the ideas in Shaw and Garlan, 1996, Software Architecture, Prentice-Hall.

• Patterns are compatible with AOP.

Elements of a Pattern

• The four essential elements (Gamma, et al) of a design pattern are:– A descriptive name – A problem description that shows when to apply the

pattern and to what contexts. The description explains how it helps to complete larger patterns.

– A solution that abstractly describes the constituent elements, their relationships, responsibilities, and collaborations.

– The results and trade-offs that should be taken into account when applying the pattern.

Pattern Resources

• Gamma, Helm, Johnson, and Vlissides, 1995, Design Patterns, Addison-Wesley.

• Cooper, 1998, The Design Patterns Java Companion, Addison-Wesley, available free from http://www.patterndepot.com/put/8/JavaPatterns.htm, the sample code in the book is available as http://www.patterndepot.com/put/8/JavaPatterns.ZIP.

• The Portland Pattern Repository: http://c2.com/ppr/• Alexander, 1977, A Pattern Language: Towns/Buildings/

Construction, Oxford University Press. (This is for historical interest.)

Some Architectural Styles

• Dataflow– Batch sequential– Pipes and filters

• Virtual Machines– Interpreters– Rule-Based Systems

• Call-and-Return Systems– Main program and

subroutine– OO systems– Hierarchical layers

• Repositories– Databases

– Hypertext systems

– Blackboards

• Component Systems– Communicating processes

(CORBA, P-to-P, Client-Server)

– Event systems

Batch sequential

• This was an early approach to software architecture—the problem was organized into jobs linked by tape-resident files. The control language and the programs were punched onto Hollerith cards, and the process submitted as a batch job to a computer center.

• The major weaknesses of this approach were:– Turnaround time (sometimes days)– Need for human intervention– Inefficient utilization of computer resources, particularly if some

development organization had learned to ‘game’ the job prioritization and cost accounting algorithms.

• Led to the invention of time-sharing.

Pipes and filters

• In this approach, the tapes in the batch sequential architecture were replaced by pipes: byte-organized sequential files written by and read by the processing steps (filters). This is still the approach in Unix scripting.

• In some systems, the dataflow over the pipes does not have to be synchronized. These dataflow architectures are frequently used in real-time applications such as air traffic control and submarine sonar processing.

• Does not lend itself well to real-time and transaction processing applications where dataflow has to be synchronized.

Interpreters

• In some systems, the application needs to be altered frequently or needs to run on machines of different architectures. The usual solution is to use a very high-level programming language that is not compiled, but rather interpreted. The slowdown is usually about 10x, but this is not an issue as the compilation is avoided. Examples include:– Java– Visual Basic– UCSD Pascal (PCode is still used in MS Office)– MatLab– Various code generators– Most scripting languages

Rule-Based Systems

• Rule-based systems are used to represent expertise or common sense. Information is stored in sets of rules that are triggered based on events or changes.

• Examples include:– Unix control files for daemons

– Firewalls

– Intrusion detection systems

– Expert systems

Main program and subroutine• This is the standard functional architecture of the 60s-80s. The problem

is decomposed into a series of transformations of data controlled by a single main function.

• Often required by programming languages that do not support modularity or that require compile-time allocation of data (FORTRAN).

• Strengths include:– Reliable response times– High performance

• Weaknesses:– Program limited in scope by the need for one person (the architect) to

understand it.– Limited flexibility– Not all problems, particularly GUIs, lend themselves to this architecture.– Blocks for I/O and operating system calls.

OO systems (narrow sense)

• Decompose the problem into coroutines — a limited number of asynchronous threads that interact to perform the task.

• Strengths– Some problems have this structure– Allows systems to be built that are beyond the grasp of

a single person

• Weaknesses– Poor performance and response times– Cannot be easily shown correct

Hierarchical layers

• Organize the problem into layers, with lower layers hiding physical requirements from higher layers that implement the business logic or application.

• Strengths:– Divide and conquer– Machine-agnostic

• Weaknesses:– Performance– May not match the solution space constraints

Databases

• Organizes the problem into a collection of tables containing rows. The database engine then allows manipulation of those elements. SQL is an example that uses set theory.

• Strengths:– Very good with large amounts of data in uniform formats

• Weaknesses:– Does not handle heterogeneous information– Lack of support for non-tabular information structures– Rows lack identity– Not object-oriented

Hypertext systems

• Data are organized into heterogeneous pages connected by links.

• Strengths:– Matches how information seems to be represented in the

brain.– Naturally heterogeneous– Works with objects

• Weaknesses:– Performance poor– Eclectic—no overall architectural structure enforced. Hence

loses coherence over time.

Blackboards

• Problem-solving data that are organized into an application-dependent hierarchy. Knowledge sources interact through the blackboard and a solution is found incrementally. Observers watch for changes and respond with additional changes.

• Strengths:– Good representation of semantic data– Problem-centered– The mammalian brain seems to work this way, although the observers are

organized into a semantic model of the world rather than working independently.

• Weaknesses:– Performance– Lack of convergence possible– No strong guarantee that the world model is even partly true. Fantasies can

take root and resist conflicting evidence.

CORBA

• Common Object Request Broker Architecture• An architecture for heterogeneous distributed environments

where processes and threads need access to resources. CORBA is a way to link to needed resources indirectly.

• Available in Java• Strengths:

– Avoids the need to locate resources at program start-up and can handle resources that migrate

• Weaknesses:– Performance– Single point of failure

Peer-to-Peer

• In this solution, resources and requests are matched in a ‘marketplace’. Involves protocols for posting both in a location where economic exchanges can be set up. Original work done at Xerox PARC by Tad Hogg and Bernardo Huberman.

• Strengths:– Adapts quickly to supply and demand

• Weaknesses:– Security– ‘Tragedy of the Commons’, particularly when other activities need

shared resources. This is a current problem with file sharing networks on the internet.

– Does not guarantee performance.

Client-Server

• An approach to setting up relationships between resource providers (usually servers) and users (clients). (In X windows, this relationship is reversed!) Uses connections to link the pairs. Standard architecture of the internet.

• Strengths:– Allows clients and servers to communicate through the

‘cloud’.

• Weaknesses:– TCP/IP security (I’ll leave it at that).

Event Systems

• Based on the original approach to simulation. Events are managed by the operating system. When they come up for service (based on priority and time), service routines and/or processes are dispatched to handle them. See discussion of AWT and Swing.

• Strengths:– Performance can be guaranteed using rate-monotonic scheduling.– Strong supporting theory (Kleinrock, Queueing systems).– Allows elements of a heterogeneous architecture to communicate.

• Weaknesses:– Single point of control can be overloaded.– Performance overhead.– Can be inefficient.– Hard for many software engineers to understand since it involves post-

graduate maths. (If you want a job for life, learn this stuff.)

Pattern Conclusions

• Patterns apply to architecture as well as to design.

• Don’t reinvent the wheel—if a problem has been solved successfully, steal the solution.

• Be aware of the strengths and weaknesses of your approach.

• Think about how your architectural pattern is implemented in design patterns.

General Conclusions

• I did a classified study of these problems at TRW in 1978.

• During the early 1980s, I continued to study these problems at Norden Systems.

• I did not come up with global solutions, because the issues were sensitive to solution details. This led me towards using pattern languages.

• This is the reason I prefer to work in solution space over requirements space. Parnas also criticizes working in requirements space.