1. Advanced Topics in Software Design Post Modernism & Aspect Orientation: Advanced Separation of Concerns

2. What is a “Concern”? A concern is… … a “kind” of functionality. … a feature, or a function of your system. … something you might worry about. Dijkstra wrote: “Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that is should be efficient and we can study its efficiency on another day […] But nothing is gained – on the contrary – by tackling these various aspects simultaneously. It is what I sometimes have called ‘the separation of concerns’ “

3. Mapping Concerns to Code Can we consider concerns separately if we can’t actually see them separately?

4. The ongoing need for SOC… These drawings represent the different ways the designer thinks about the structure There are far more drawings than this: Every angle is considered, every pipe is placed, Each aspect is considered separately.

5. Directly Representing Mental Models THE MACHINE

6. Separation and Abstraction

7. More Abstraction … More Indirection

8. Abstraction; Indirection Machine Specific Memory Manipulation instruction assumptions about the machine

9. Abstraction; Indirection Machine Specific Memory Manipulation instruction assumptions about the machine Machine Specifics Abstracted Away compiler assumptions about the machine separation of concerns

10. Abstraction; Indirection instruction Loops implicitly included compiler assumptions about the machine implicit looping such as “goto”

11. explicit loop Abstraction; Indirection instruction Loops implicitly included compiler assumptions about the machine implicit looping such as “goto” instruction Looping made explicit compiler assumptions about the machine explicit loop instruction

12. explicit loop instruction explicit loop instruction Abstraction; Indirection Blocks and repeated sequences implicit implicit sequence reused compiler assumptions about the machine

13. explicit loop instruction explicit loop instruction Abstraction; Indirection Blocks and repeated sequences implicit implicit sequence reused Blocks and repeated sequences explicit compiler assumptions about the machine subroutine/function compiler assumptions about the machine explicit loop instruction subroutine/function explicit loop instruction

14. Abstraction; Indirection Entities used in an unencapsulated way compiler assumptions about the machine subroutine/function explicit loop instruction subroutine/function explicit loop instruction

15. Abstraction; Indirection Entities used in an unencapsulated way compiler assumptions about the machine subroutine/function explicit loop instruction subroutine/function explicit loop instruction Objects encapsulate entities compiler assumptions about the machine subroutine/function explicit loop instruction subroutine/function explicit loop instruction object

16. The Path of Indirection… Machine Specific Memory Manipulation instruction assumptions about the machine Loops implicitly included instruction compiler assumptions about the machine explicit loop instruction explicit loop instruction Blocks and repeated sequences implicit implicit sequence reused compiler assumptions about the machine Entities used in an unencapsulated way compiler assumptions about the machine subroutine/function explicit loop instruction subroutine/function explicit loop instruction Objects encapsulate entities compiler assumptions about the machine subroutine/function explicit loop instruction subroutine/function explicit loop instruction object

17. So what’s next? Objects encapsulate entities compiler assumptions about the machine subroutine/function explicit loop instruction subroutine/function explicit loop instruction object what elements of our systems don’t align with objects?

18. Introducing Aspects… Concerns != Objects So ….There *is* functionality that doesn’t fit into an OO paradigm. There are two problems for how concerns align with objects…

19. A Concrete Example This transaction management concern does not fit into an OO structure. Every method that includes a transaction must have transaction management code

20. Tangling of Concerns apply interest manage transaction

21. Tangling of Concerns apply interest apply charges manage transaction

22. Tangling of Concerns apply interest apply charges transfer money manage transaction

23. What Caused the Tangling? Tangling occurs if one concern necessitates… (or in some sense “triggers”) …behavior from another concern ledger.debitInterest( ) triggers the commit acct.creditInterest( ) requires the begin

24. What Caused the Tangling? One object (such as the Checking account) has to play many roles.

25. Scattering of Concerns

26. What caused the Scattering? no way to unite the code related to a concern, because it deals with different entities. These entities each must be described separately, in and of themselves.

27. What would we want? Transaction Handling Apply Interest Deduct Charges Transfer Money We want to be able to think about each of these concerns separately, without worrying about the others. This is real “separation of concerns” as Dijkstra envisioned it.

28. But what do we have to overcome? Tangling: when one concern requires or triggers behavior of another concern, or when roles are mixed in an entity Scattering: when one concern is spread across many entities role-mixing

29. Aspects seek to overcome this… Now we’re going to go over AOP. We’ll talk first about its mechanisms for separation Then about its mechanisms for composition

30. What is an aspect? An aspect is a separate concern.

31. Different Kinds of Aspects These were encapsulated from concerns that were scattered, or whose roles were mixed within objects This was encapsulated from a concern that was triggered/required by another concern

32. Two Approaches for Separation Asymmetrical Captures only triggered concerns Symmetrical Captures mixed and scattered concerns Apply Interest Deduct Charges Transfer Money Transaction Handling Transaction Handling

33. Asymmetrical Separation Original Object-Oriented System (includes mixed and scattered concerns) Behavior that is triggered in various situations in the core core aspect

34. Banking: Asymmetrical Sep’n most generally associated with AspectJ from Xerox PARC

35. Triggered Behavior in an Aspect public aspect TransactionManagement { before(): transaction(){ transaction = new Transaction() transaction.begin() } after(): transaction(){ transaction.commit() } before and after: triggered “advice” At the Code Level

36. Triggered Behavior in an Aspect At Design triggered method original method

37. Symmetrical Separation Tangled Core

38. Symmetrical Separation Still have the triggered aspects But now we have separated the core to remove mixing and scattering

39. Separated Concerns In Design

40. Composition! Now that we’ve separated out everything, we need a way to tell the compiler (or whatever we’re using) how to integrate it so it can run.

41. Composing Symmetrical Separation

42. Composing Trigger Relationships

43. public aspect TransactionManagement { pointcut transaction: execution(*.applyCharges(..),*.applyInterest(..), *.transfer(..)) before(): transaction(){ transaction = new Transaction() transaction.begin() } after(): transaction(){ transaction.commit() } At the Code Level

44. Composing Trigger Relationships

45. Terminology TermDefinition ConcernKind of functionality AspectConcern that is “triggered” (asymmetrical) Shared- Concept Concern (base) Concern that shares conceptual elements with other concerns; not “triggered” (symmetrical) ThemeAny Concern

46. Now let’s try to spot concerns!