2. "הפשטה" זה די פשוט ולא כל כך מופשט יוסי גיל סמינר קיץ למורים במדעי המחשב 22.6.2004

3. 2/22 Déjà Vu Stepping into a room, and feeling that you have already been there… This worm and cozy feeling at the back of your head … Nice, isnt it?

4. In Software … Déjà Vu = the Bells of Warning

5. The Fundamental Metaphor of Software Software is Like Fire, Software is Like Water Software always changes, and forever will

6. Software Component Duplication is Evil Every change here, should be repeated there… Software Component Client 1 Client 2

7. The Principle of Little Numbers 0 > 1: What you don't know cannot hurt you. Information hiding, encapsulation, table driven programming, modularity, etc. 1 > 2: If the same thing occurs twice in the code, then it occurs one time too many. Software is constantly subject to change. As changes occur, maintaining the two almost identical parts will become a nightmare. for (ever) { write code; while (exist(similar parts)) { extract identical portion; rewrite code; }

8. Abstraction Abstraction: find commonality of several phenomena Good abstraction: –Ignore the irrelevant details –Find the relevant commonalities –Maximize relevant commonalities Abstractions are almost invariably relative to a domain of interest

9. Abstraction and Reusability Benefits: –Reduce development cost: one component instead of many –Promote reliability: exercise component from many different aspects no need to remember to correct the same error twice Software Component Client 1 Client 2

10. Abstraction is Relative to Domain Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer.

11. Abstract at the Right Level

12. An IQ Test Table and Chair? Cat and Dog? Dog and Wolf? Pencil and Cup? School and Bank? Decline and wriggle? Jewels and Apartment? Salary raise and court-of-law? Army and clothing? Aesophagus and genealogy? Whats in common to:

13. Taxonomy Taxonomy: Abstraction of Abstractions tax·on·o·my 1. The classification of organisms in an ordered system that indicates natural relationships. 2. The science, laws, or principles of classification; systematics. 3. Division into ordered groups or categories: Scholars have been laboring to develop a taxonomy of young killers

14. Successful Taxonomies: Taxonomy: the ultimate goal of the abstraction process Examples: –Linguistic: classification of languages. –Biology: kingdom, phylum, subphylum, class, order, family, genus, species. –Chemistry: the periodic table of the elements. –Mathematics: Algebraic structure - group, ring, commutative-ring, skewed-field, field, algebra,... –Computer Science: Kinds of polymorphism. Descartes: the discovery of an order is no easy task... yet once the order has been discovered there is no difficulty at all in knowing it.

15. Meta-Abstraction Abstraction of the abstraction process: –Recipes for finding the right abstractions.

16. 15/22 Abstractions in Software The programming language provides mechanisms for representing our mental abstractions. Each mechanisms relies on a metaphor

17. 16/22 Familiar Mechanisms and Metaphors Procedure – the statement metaphor –Writeln(hello); => procedure print() Function – the expression metaphor –odd(b) => isOpen(f) Type – the primitive type metaphor –X: integer => TYPE A=array[1..100] of real; VAR x: A; Record – the folder metaphor

18. Programming Paradigms Paradigm == Kinds of Abstractions Employed Main Paradigms: –Procedure-oriented:Algorithms –Object-oriented:Classes and objects –Logic-oriented:Goals (predicate calculus) –Rule-oriented:If-then rules –Constraint-oriented:Invariant relationships

19. Reactions to New Technology Eureka!!! OOP is the solution It will never work! It s trivial! This is what we have been doing all the time! There is still much to do...

20. Evolution leading to OOP: #1/5 Decide on a data/data base model; write simple utilities around it: Brute-force attack: Fortran/Cobol/Data bases Global Data Proc 1Proc 4 Proc 2Proc 3

21. Evolution leading to OOP: #2/5 Decide which procedures you want; use the best algorithms you can find: Procedural: Pascal Proc 3 Type 1 Proc 1 Proc 2 Type 2 Var 1 Var 2 Algorithms + Data Structures = Programs N. Wirth

22. Evolution leading to OOP: #3/5 Decide which modules you want; partition the program so that data is hidden in modules: Data Hiding: Modula-2/Turbo-Pascal Module 2 Type 1 Var 1 Module 3 Var 2 Type 2 Module 1 Proc 1 Type Var Proc 2 Usage

23. Evolution leading to OOP: #4/5 Type 2 Type 1 Op 1 Var 1 Var 2 Op 2 Data Abstraction: ADA Decide which types you want; provide a full set of operations for each type: Op 1 Op 2 Op 3 Var 1 Var 2 Var 3 In contrast with modules, types can be instantiated

24. Evolution leading to OOP: #5/5 OOP: Decide which classes you want; provide a full set of operations for each class; make commonality explicit by using inheritance and genericity: The Power of Inheritance: Reduction in size of the Booch Components, originally written in Ada as a result of the port to C++.

25. Syllogisms X is good. Object oriented is good. X is object oriented. X = Ada, corelDraw, Roger King s Cat, Visual Basic, Microsoft Excel, Windows-NT, Communication programs,...

26. 25/22 Conclusions déjà vu is a danger signal! Abstraction is not abstract. Abstraction cannot be taught. Teach and study Abstraction mechanisms Meta abstraction is vague and/or trivial Strive to build a taxonomy

27. 26/22 method transferAmount(acct A, acct B, amount) { valid = verifyUserCredentials(TRANSFER_FUNDS); if (!valid) reportSecurityError(); exit; DB.startTransaction(); currentA = A.getBalance(); currentB = B.getBalance(); if (currentA – amount < 0) DB.rollback(); reportOverdraft(); exit; A.setBalance(currentA – amount); B.setBalance(currentB + amount); DB.commit(); if (DB.error()) reportDbError(); exit; log.log(Transferred amount from A to B); } SECURITY TRANSACTION MANAGEMENT BUSINESS LOGIC LOGGING Program requirements Aspectual Decomposition (conceptual process) Clearly distinct concerns Aspect Weaving (mechanical process) Executable Untangling the Web We Weave

28. 27/22 Aspect-Oriented Programming to the Rescue Design the core business logic Define aspects which are transformation operators. –Example: a logging operator Aspect Operator Program Module –Operators can be reused for many tasks –Should not break the operand –Transformation is packaged Apply aspect modules to adapt the code to support: –Logging –Security –Persistence …

29. 28/22 The Enemy of the Good… Two conflicting forces in software design: –If it is good, you want to add aspects to it … –When you add aspects, you change it… –In changing it, you might damage it… –…now it is not so good anymore! Le mieux est lennemi du bien.

30. 29/22 Code Transformation An aspect is a code transformer. –However, there is no simple, unified metaphor or semantics for definition or application of aspects. Ideally, we would like the transformer to be: –Expressive –Modular –Structure-preserving, i.e., tightly coupled with the underlying language. –Simple Bad example: –C pre-processor (which does not know anything about C….) Good example: –mixins -- an abstract sub-class mechanism.

31. 30/22 What is Aspect Application? How can we make AOP more than a fancy pre-processor? Uncontrolled and non-systematic change leads to anarchy. –Multiple applications of the same transformer? –Specification of application order? –Parameters to the transformer? –Time of transformation? (Compile/Link/Run) –Does the non-transformed version remain? Are the two versions compatible?

32. 31/22 Our Solution Reduce all above questions to the familiar domain of OOP –Motivation & Inspiration: Enterprise Applications and J2EE deployment process. In a nutshell, aspect application is a form of subclassing (slightly restricted, slightly generalized…) –Strong evidence that this works –A natural extension of an existing deployment process (more later) Capture the mode of operation of banks, government agencies, insurance companies, hospitals… –Make the world go round Java 2, Enterprise Edition - a modern and popular middleware framework for enterprise applications, implemented by e.g., IBM WebSphere App Server

33. 32/22 Aspects as Reimplements Operators Given a class C, aspect A, the application C=A[[C,p 1,…,p n ]] is a new class such that 1. C has the same type as C. (cannot declare variables of type C ) 2. May have additional fields. 3. May have a modified behavior. Simple subclassing: 1.Creates a subtype by adding more functions to the protocol. 2.Extends the structure definition by adding more fields. 3.Modifies the behavior by replacement and refinement A class in OOP is: 1.A type declaration C p; 2.Template for object creation (constructor, field layout etc.) p = new C(); 3.An implementation p.m(); Actual parameters p 1 … p n make C fit into the slots that A expects

34. 33/22 Example: Simple Logging Aspect aspect Logging { before every method of the operand { print(Method started: + currentMethodName); } after every method of the operand { print(Method completed); } Interface Base Implementation Augmented Implementation Aspect Module optional parameters

35. 34/22 Applying an Aspect to a Class Hierarchy C1C1 C2C2 C4C4 C3C3 C 1 C 2 C 3 C 4 No inheritance relationship between the re-implementations Since no new types are defined, this does not disturb polymorphism!

36. 35/22 Parameterized Example: A Transaction Aspect aspect Transactions< T, // methods of the operand that require a transaction (possible existing) S // methods of the operand that require their own tx (possibly nested) > { before every method in S { startNewTransaction(); } before every method in T { if (!inTx) startNewTransaction(); } after every method in T S { if (newTxStarted) commit(); } } Every application of this aspect must provide values for parameters T and S

37. 36/22 AspectJ2EE as a Distilled Code Transformer ClassInheritanceMixins AspectJ2EE Aspects Structure template DefineExtend Template for structure extension New Type Declare Subtype specific parent Template for subtyping limited set of parents (opreands) No Code imple- mentation Yes Modify specific parent Modify limited set of parents (operands) Modify any operand Parameters Only with Templates No Only for parent class Expressive binding mechanism

38. 37/22 Enterprise JavaBeans (EJBs) Represent the data model in J2EE applications Developers provide the business logic –Transfer amount X from account A to account B J2EE provides everything else –Services: Security, transactions, persistence… UPDATE account SET balance = balance + 100 WHERE id = 12345 SELECT balance FROM account WHERE id = 12345 Account a = AccountFactory.find(12345); a.deposit(100); float b = acct.getBalance();

39. 38/22 J2EE is not as good as AOP Closed and pre-defined set of services –Need a different service? Tough Luck! e.g., to add logging support, youll have to use scattered and tangled code. Fixed implementation of services –e.g., J2EE security is role-based. Need name-based security? Tough Luck! EJBs are hard to program –Just look at the standard specification –You mustnt do this, you mustnt do that… e.g., this may not be passed as a method argument

40. 39/22 The Deployment Process J2EE services are added to business logic during the deployment process Done without modifying code – only generating support code –Subclasses –Factory classes –RMI stubs/skeletons Define EJB Services as Aspects. Aspect application becomes part of the deployment process.

41. 40/22 J2EE Deployment User- provided classes Many, many more classes generated …

42. 41/22 AspectJ2EE Deployment Application of Four Aspects to an EJB The generated classes are subclasses

43. 42/22 Join Points Supported by Deployment/Subclassing Data access [ before | after ] [ property | private field ] [ get | set ] Code [ before | after | around ] [ method | ctor 1 | remote ] [ after throwing | after returning ] [ method | ctor ] Control flow [ cflow | cflowbelow ] [ catch ] 1 Standard Java restrictions on constructors apply

44. 43/22 The Deployment Descriptor XML syntax is used to specify the aspect application details –Order of application, parameters, etc. –Conceptually based on J2EEs XML Deployment Descriptors For example: Account aspectj2ee.demo.AccountBean aspectj2ee.core.Lifecycle aspectj2ee.core.Security execution(*(..)) User

45. 44/22 Remote Calls The deployment process also generates RMI stubs and skeletons If we allow the user to control the process, he can also control this facet In particular, we can define aspects for handling tier- cutting concerns A single module each (without scattered code) for handling: –Encryption/decryption of client-server communications –Data compression –Memoization –Client-side precondition checking Similar to Remote Pointcut, Nishizawa, Chiba and Tatsubori (AOSD 04)

46. 45/22 Summary 1.A smooth embedding of AOP in OOP 2.Proof of the pudding: works in real-world enterprise applications 3.Harmonious marriage of J2EE and AOP 4.New weaving mechanism using the deployment process 5.Realizing tier-cutting concerns with aspects

47. 46/22 And they lived happily ever after? Integration with WebSphere? Wedding AOP with other J2EE sub- technologies? Servlets JSP (Java Server Pages) Web services User study? Refactoring existing projects into this model?