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

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’ “

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

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.

Directly Representing Mental Models THE MACHINE

Separation and Abstraction

More Abstraction … More Indirection

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

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

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

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

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

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

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

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

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

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?

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…

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

Tangling of Concerns apply interest manage transaction

Tangling of Concerns apply interest apply charges manage transaction

Tangling of Concerns apply interest apply charges transfer money manage transaction

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

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

Scattering of Concerns

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.

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.

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

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

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

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

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

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

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

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

Triggered Behavior in an Aspect At Design triggered method original method

Symmetrical Separation Tangled Core

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

Separated Concerns In Design

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.

Composing Symmetrical Separation

Composing Trigger Relationships

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

Composing Trigger Relationships

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

Now let’s try to spot concerns!