The Future of Computing: Aspect-Oriented Programming and Patterns

CSE301 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):

110, March-April 2003.

106 • 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/downloa ds/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

– Security – Look and feel – Error-handling – Logging – Multi-threading – Commit (policies or aspects) • 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 inheritance He 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

modularity or that require compile-time allocation of data (FORTRAN).

by programming languages that do not support • 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.