the future of computing: aspect-oriented programming and patterns
DESCRIPTION
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:. - PowerPoint PPT PresentationTRANSCRIPT
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.