The Future of Computing: AspectOriented Programming and Patterns

1
The Future of Computing Aspect-Oriented
Programming and Patterns

• CSE301
• University of Sunderland
• Harry R Erwin, PhD

2
A Canned History of Computing

• Assembly language
• High-order languages
• Structured programming
• Modular design
• Object-oriented design
• Where do we go now?

3
Possibilities

• Aspect-Oriented Programming
• Patterns

4
Aspect-Oriented ProgrammingResources

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

5
AOP Resources

• http//en.wikipedia.org/wiki/Aspect-oriented_progr
  amming
• http//www.parc.com/research/projects/aspectj/down
  loads/ECOOP1997-AOP.pdf
• http//www.developer.com/design/article.php/330894
  1
• http//www-128.ibm.com/developerworks/library/j-as
  pectj/
• http//www.eclipse.org/aspectj/
• http//aosd.net/

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

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

8
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 cant be modified at run
  time. When they are broken they have to be fixed
  and that can break clients.

9
Example Parametric Polymorphism

• Visit
• http//wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?polym
  orphism
• 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.

10
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?

11
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).
• Youve 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.

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

13
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.)

14
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

15
Batch sequential

• This was an early approach to software
  architecturethe 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.

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

17
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

18
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

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

20
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

21
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

22
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

23
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
• Eclecticno overall architectural structure
  enforced. Hence loses coherence over time.

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

25
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

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

27
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 (Ill leave it at that).

28
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.)

29
Pattern Conclusions

• Patterns apply to architecture as well as to
  design.
• Dont reinvent the wheelif 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.

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