Introduction to AspectJ

1. Introduction to AspectJ Part 1 Conventional Separation of Concerns The Open-Closed Principle The Architect’s Dilemma

2. There are certain maintainability, reusability and extendibilityissues with OO s/w, that stem from the limitations of conventional ‘Separation of Concerns’ techniques. • These limitations have been overcome by Advanced Separation of Concerns techniques, like Aspect Oriented Programming, whose implementations, like AspectJ, resolve the maintainability, extendibility, and reusability issues.

3. What is not in part one, and why • In this first brown bag, we are not really going to cover any of the following: • AspectJ • Aspect Oriented Programming • the maintainability, extendibility and reusability issues addressed by the latter • Why not? Back in December, I decided to do a brown bag on AspectJ, which I knew nothing about at the time. Over Christmas I had some fun diving into AspectJ… just learning enough to solve some practical problems with it.

4. What is not in part one, and why • But when I tried to turn my experiences into a brown bag, I decided that rather than just presenting a practical introduction to AspectJ, which can be done just by reading a single book on the subject, I would try to provide people with a more solid foundationfor understanding AspectJ • So I decided also to cover topics like the following: • a basic history of s/w decomposition. • a reasonably in-depth explanation of why better decomposition techniques became necessary. • As a result, I can’t fit everything in a single brown bag

5. What is in part one In part one, we’ll cover some background concepts that we’ll need in the next brown bag, to explain the need for AOP. Here is what we are going to cover: • the origins of SoC • how it relates to modularization • two s/w decomposition techniques: • Functional Decomposition • OO Decomposition • how the techniques support modularization criteria • advances in SoC • the Open-Closed principle • the Architect’s dilemma, and XP’s answer to it

6. what is AspectJ? • an extension to the Java programming language • i.e. all valid Java programs… • …are also valid AspectJ programs • AspectJ is an implementation of Aspect Oriented Programming (AOP) AspectJ programs Java programs

7. what is AOP? • a programming technique • first presented seven years ago • in a milestone paper by the same name • published in 1997 Proceedings of the European Conference of OOP • written by a team at the Xerox Palo Alto Research Centre (PARC), in CA, USA • team leader: Gregor Kiczales, now a leading AOP evangelist • paper proposed AOP as a technique for improving separation of concerns (SoC) in software.

8. what is SoC? • term coined by Edsger Dijkstra • a pioneer in the establishment of the scientific basis of computer science • author of famous 1966 letter: Go To Statement Considered Harmful • GO TO = major source of errors • should be eliminated

9. Dijkstra and SoC – goto considered harmful • letter caused giant commotion in the computing community • combatants took positions on all sides of the issue • what he specifically objected to were the labels to which goto statements jump, not the goto itself • the number of bugs in a program seems to increase with the number of labels in it • labels and gotos make programs difficult to analyze statically

10. Dijkstra and SoC – goto considered harmful • programs using lots of gotos usually result in spaghetti code, which is difficult to understand, reason about, and maintain • debate long since died down • few programmers use goto liberally • most never use it at all • programming languages provide alternatives to the GO TO statement • Java is an example of this

11. Dijkstra and SoC – goto considered harmful • Java = (C++ ) -- broken glass • Java restricts the power of certain dangerous features found in C++, to make them safer • e.g. it has pointers, but disallows pointer arithmetic • although goto is a Java reserved word, Java has no goto construct for transferring control to an arbitrarily placed label • there are only a few legitimate uses for the goto statement • so Java provides alternative constructs that achieve the same effect as a goto, but only for those legitimate uses: • it provides break and continue constructs for transferring control to a label, but restricting the positioning of labels to limited places • also provides the finally construct of the try statement • looking at goto is not just a digression: as we’ll see in the next brown bag, the concept of goto is pertinent to the subject of AOP.

12. Dijkstra and SoC – pointed sayings • Dijkstra was famous for his wit, eloquence, and way with words • some of his memorable epigrams: • Computer Science is no more about computers… …than astronomy is about telescopes • the competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, … …and among other things he avoids clever tricks like the plague • if in 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, Djikstra would not have liked this, … …well that would be enough immortality for me • most relevant quotation in our context: the one in which he simply exhorts us to… …Separate Concerns

13. Dijkstra and SoC • Dijkstra introduced the term SoC in 1976, in one of his seminal works called: Notes on Structured Programming • in it, he advocated certain design principles that have now become completely accepted in the computer science community: • large systems should be constructed out of many smaller components • each component sould be defined only by its interface, and not by its implementation • smaller components may be designed using a similar process of decomposition, thus leading to a… TOP-DOWN STYLE OF DESIGN

14. Dijkstra and SoC • the previous principles are all relevant to our subject • but the most relevant of Dijkstra’s principles is: design should start by enumerating the 'separable concerns' and by considering each group of concerns independently of the others • Djikstra saw how systematic design can tame a mass of intricate details into a set of separable concerns

15. Parnas and SoC • Although the term SoC was coined by Djikstra, most books and papers attribute the concept to David Parnas • Parnas did not use the words 'Separation of Concerns' • but the idea of SoC was already present in a milestone paper that he wrote in 1972: On the Criteria to be Used in Decomposing Systems into Modules • paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system, while allowing the shortening of its development time

16. Parnas and SoC • expected benefits of modular programming: • managerial: development time should be shortened because separate teams would work on each module with little need for communication • product flexibility: it should be possible to make drastic changes to one module without a need to change others • comprehensibility • it should be possible to study the system one module at a time • the whole system can therefore be better designed because it is better understood • Parnas complained that although at the time there were many advocates of modularization, usually, they said nothing about the criteria to be used in dividing a system into modules

17. Parnas and SoC • Parnas says that the effectiveness of a modularization is dependent upon the criteria used in dividing the system into modules • he takes a sample system and decomposes it, first using the conventional method, and then using a new, unconventionalone: • conventional method • the one meant by all proponents of modular programming • criterion used is to make each step in the processing a module • one might say that to get the first decomposition one makes a flowchart • unconventional method • Criterion used is information hiding: • every module is characterized by its knowledge of a design decision, which it hides from all others • its interface or definition was chosen to reveal as little as possible about its inner workings

18. Parnas and SoC • Parnas then compares the two decompositions and shows that the unconventional one has distinct advantages for the goals of flexibility, comprehensibility and shorter development time. • he finds that the order in time in which processing is expected to take place should not be used in making the decomposition into modules • Parnas draws the following conclusions: • it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart • we propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change • each module is then designed to hide such a decision from the others

19. journey so far: • what is AspectJ? • what is AOP? • What is SoC? • term coined by Dijkstra in 1976 • but concept already present in 1972 Parnas paper • so what is our first definition of SoC?

20. Parnas and Soc • based on the ideas in Parnas' paper, here is our first definition of SoC: Separation of Concerns is the achievement of the benefits of • s/w flexibility • shorter s/w development times • s/w understandability by modularizing s/w using the criterion of information hiding. i.e. each module hides a difficult or changeable design decision from the others

21. Parnas and Soc • So that was 1972 • Parnas did SoC by modularizing s/w based on Information Hiding principle • he criticized modularization based on flow charts • he complained that most advocates of modularization said nothing about modularization criteria

22. modularity: unanswered questions but what about the following questions: • are there other ways of modularizing s/w? if so: • should more than one criterion be applied at the same time? • are some of these modularizations better than others? • what is a module? • what makes a good module? • does modularization bring other benefits?

23. journey so far: • what is AspectJ? • what is AOP? • what is SoC? • term coined by Dijkstra in 1976 • but concept already present in 1972 Parnas paper • our first definition of SoC • unanswered questions on modularity • what is Modularity?

24. what is modularity? • by 1985, when I started my Computer Science degree, some of the answers to these questions had already been found • I first read about modularity in a software engineering book by Richard Fairley • it devoted only a few pages to modularity and modularization • here is what it said about modules: there are many definitions of the term ‘module’ • FORTRAN subroutine • Ada package • a work assignment for an individual programmer but all these are correct in the sense that: • modular systems incorporate collections of abstractions • each abstraction handles a local aspect of the problem being solved Modularity enhances design clarity, which in turn eases implementation, debugging, testing, documentation and maintenance of a s/w product.

25. Fairley on modularization • there are numerous criteria that can be used to guide the modularization of a system • depending on the criteria used, different system structuresmay result • in practice, a s/w system can be modularized using a single design criterionor aspects of severalcriteria • the criteria: • conventional criterion • information hiding criterion • data abstraction criterion • levels of abstraction • coupling and cohesion • problem modeling

26. Fairley on modularization criteria • conventional criterion each module and its submodules correspond to a processing step in the execution sequence • information hiding criterion each module hides a difficult or changeable decision from the other modules • data abstraction criterion each module hides the representation details of a major data-structure behind functions that access and modify the data structure • coupling and cohesion a system is structured to maximise the cohesion of elements in each module and to minimize the coupling between modules • problem modeling the modular structure of the system matches the structure of the problem being solved • levels of abstraction modules, and collections of modules provide a hierarchical set of increasingly complex services

27. Layers Pattern • levels of abstraction criterion • originally described by Dijkstra • a.k.a. the Layers architectural pattern • Here is how Craig Larman describes it: • organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities • with a clean, cohesive separation of concerns, so that: • ‘lower’ layers are low-level and general services • higher layers are more application specific • collaboration and coupling is from higher to lower layers • lower-to-higher layer coupling is avoided

28. Layers Pattern • Larman says of the Layers pattern that it is an example of the most common technique for achieving SoC • Dijkstra was the first person to formally identify the importance of composing systems in layers of abstraction • so that would be another reason for attributing the concept of SoC to Dijkstra

29. Fairley on modularization • after this look at Layering, a particular modularization criterion mentioned by Fairley… …let’s go back to his 1985 s/w engineering book • it is evidence that quite a bit of progress had been made in the 13 years following the Parnas paper • but a lot of progress was still to come • while the book stressed the fact that modularization was a good thing, and worth achieving… …it didn't really acknowledge the presence of any issues or questions, like the following: • could other modularization criteria exist? • what should be the qualities of a modularization criterion? • how is the effectiveness of a modularization criterion influenced by the type of module ituses todecompose a system?

30. outstanding modularization criteria/issues • Fairley’s book just said: • here are the criteria - several of them • you can use one or more • using different criteria results in different system structures • it didn't compare and contrast criteria • it didn’t prioritise them, or recommend that as many as possible should be used • it didn't deal with the abstract concept of modularization: only with concrete instances of it • another 10 years or so would have to pass … …before a more abstract and unifying treatment of modularization was published … …which tackled some of these tasks

31. a more comprehensive treatment of modularization • such a treatment of modularization appeared in a book by Betrand Meyer • Meyer is considered to be a world authority on OO s/w development • the book is called Object-Oriented Software Construction • it has been described as the most comprehensive, definitive, O-O reference ever published • this is especially true of the second edition, published in 1997

32. journey so far: • what is AspectJ? • what is AOP? • what is SoC? • term coined by Dijkstra in 1976 • but concept already present in 1972 Parnas paper • our first definition of SoC • 1972: unanswered questions on modularity • what is Modularity? • Fairley’s 1985 treatment of the subject • much progress on modularity between 1972 and 1985 • but many question / issues remained • so let’s look at Meyer’s treatment of the subject

33. Meyer on modularization • as part of his quest to define OO s/w construction, Meyer devises a more abstract definition of modularity • he also shows how: OO s/w constructionbrings together, and uses, several of the modularization techniques enumerated by Fairley • his investigation of modularity begins by looking at s/w quality • s/w quality is best described as a combination ofseveral factors

34. Meyer on modularization – S/W Qualities • Meyer distinguishes between • external quality factors properties like speed, and ease of use… …whose absence or presence may be detected by users • and internal quality factors properties like modularity or readability… …which are only visible to developers • In the end, he says, only external factors matter: if I use a web browser or live near a computer-controlled plant… …little do I care whether the source code is readable or modular… …if graphics take ages to load, or if a wrong input blows up the plant • but for the users to enjoy the visible qualities, … the designers and implementers must have applied techniques that will ensure the hidden qualities

35. Meyer on modularization – S/W Qualities • the book presents a set of modern techniques for obtaining internal quality • he reviews external quality factors and concludes that given the state of the s/w industry at the time, four of them were particularly important • Correctness, Robustness, Extendibility, and Reusability • here are his definitions of the last two: • Extendibility the ease of adapting s/w products to changes of specification • Reusability the ability of s/w elements to serve for the construction of many different applications

36. Meyer on modularization – exdendibility and reusability • from the goals of extendibility and reusabilty follows the need for flexible system architectures … made of autonomous s/w components • Meyer introduces the term modularity to cover the combination of extendibility and reusability • modular programming was once taken to mean the construction of programs as assemblies of small pieces, usually subroutines • but such a technique cannot bring real extendibilty and reusability benefits… …unless we have a better way of guaranteeing that the resulting pieces, the modules, are: • self-contained • organized in stable architectures • any comprehensive definition of modularity must ensure these properties

37. Meyer on modularization – informal definition • Meyer first gives an informal definition of modularity: a softwareconstruction method is modular, if it helps designers produce s/w systems made of … …autonomous elements connected by a coherent, simple structure • he then embarks on an investigation ofmodularity issues to answer the following questions: • what are the precise properties a s/w construction method must possess to deserve the 'modular' label ? • what should be the properties that a satisfactorymodule structure must satisfy? • the definition of the term 'module', does not become available until the second question is answered, which happens at the end of the investigation, … so throughout the investigation, the term 'module' denotes the basic unit of decomposition of a system, whatever it may be.

38. journey so far: • what is AspectJ? • what is AOP? • what is SoC? • term coined by Dijkstra in 1976 • but concept already present in 1972 Parnas paper • our first definition of SoC • 1972: unanswered questions on modularity • what is Modularity? • Fairley’s 1985 treatment of modularity • much progress on subject between 1972 and 1985 • but many question / issues remained • Meyer’s treatment of the subject • key external qualities: Extendibility and Reusability • modularity: informal definition • let’s look at his investigation of modularity to determine • properties of modular s/w construction method • properties of satisfactory module structure

39. Meyer’s investigation – the 15 properties • Meyer looks at modularity from multiple viewpoints • he introduces a set of complementary properties, which taken collectively, cover the most important requirements on a modular design method • N.B. Meyer uses the following terms interchangeably: s/w construction method = design method = decomposition method • the properties are 5 criteria, 5 rules, and 5 principles

40. Meyer’s investigation – 5 criteria A design methodworthy of being called modular should satisfy the following requirements: • Modular Decomposability

41. Meyer’s investigation – 5 criteria a s/w construction method satisfies Modular Decomposability if … it helps in the task of decomposing a s/w problem into… a small number of less complex subproblems, … connected by a simple structure, … and independent enough to allow further work to proceed separately on each of them.

42. Meyer’s investigation – 5 criteria 5 Criteria • Modular Decomposability • Modular Composability

43. Meyer’s investigation – 5 criteria a method satisifies Modular Composability if… it favours the production of s/w elements which may then be … freely combined with each other... to produce new systems, … possibly in an environment quite different from the one in which they were initially developed.

44. Meyer’s investigation – 5 criteria 5 criteria • Modular Decomposability • Modular Composability • Modular Understandability

45. Meyer’s investigation – 5 criteria a method favours Modular Understandability if … it helps produce s/w in which a human reader… can understand each module without having to know the others, … or at worst,… by having to examine only a few of the others.

46. Meyer’s investigation – 5 criteria 5 Criteria • Modular Decomposability • Modular Composability • Modular Understandability • Modular Continuity

47. Meyer’s investigation – 5 criteria a method satisfies Modular Continuity if in the s/w architectures that it yields, … a small change in a problem specification… will trigger a change of just one module, … or a small number of modules.

48. Meyer’s investigation – 5 criteria 5 Criteria • Modular Decomposability • Modular Composability • Modular Understandability • Modular Continuity • Modular Protection

49. Meyer’s investigation – 5 criteria a method satisfies Modular Protection if in yields architectures in which … the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst, … will only propagate to a few neighbouring modules.

50. 5 criteria to be met by a modular design method Modular Decomposability Modular Composability Modular Continuity Modular Protection Modular Understandability