The Future of Computing: Aspect-Oriented 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 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 Programmingspecial issue, CACM, 44(10): 28-97.

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

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 can’t 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?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.

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

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. 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 Some Architectural Styles

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

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 • Eclectic—no 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 (I’ll 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. • 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.

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.