AOSD - Enhancing SoC :: INF5120 :: Mansur Ali Abbasi. AOSD :: Aspect Oriented Software Development SoC :: Separation of Concerns

07.05.2007 :: INF5120 :: Mansur Ali Abbasi

AOSD - Enhancing SoC

AOSD :: A

spect

O

riented

S

oftware

D

evelopment

NB!

This lecture leans on conciseness rather

than completeness (in contrast to F01-F13)…

(…That means you

should

read at least some of

Learning goals

1.

Students must…

a. …have an introductory knowledge of AOSD as an emerging development

paradigm (including background/rationale)

b. …acquire basic understanding of main concepts and terminology of AOP.

c. …acquire basic understanding of main concepts and terminology of AOM.

d. …recognize and understand the necessity and applicability for AO analysis and design.

2.

Students should…

a. …be able to understand the contents of the articles associated with this lecture.

b. …be able to connect AO-principles to other parts of the curriculum of INF5120 (especially requirements engineering and architecture).

c. …be able to outline and describe the essential concepts of mainstream state-of-the-art SoC-mechanisms.

3.

Students are NOT expected to…

Agenda

1. SoC mechanisms in software development

a. SoC – a definition

b. OO technology / Object “thinking”

c. Enhancements to OO-technology

d. Agents and Services

e. Model-centric “thinking”

2. AOSD – Aspect-Oriented Software Development

a. Motivation b. Introduction c. Aspects d. Benefits 3. AOP - Example a. AspectJ

4. AOM – Aspect Oriented Modeling

a. AOM in general

b. AOMDF – Overview

c. AOMDF - Interactions

d. The Theme Approach

5. Summarizing thoughts

a. Summarizing thoughts

b. Future 6. References

1a. Separation of Concerns (SoC)

Only available way of effectively structuring one’s thoughts. Scientific thinking = apply SoC

Apply SoC =

“…to consider in depth only a single aspect of a subject matter in isolation for the sake of the aspect’s own consistency, while knowing that one is occupying one’s mind with only one among all the aspects of the subject matter, and hence being single- and multi-track- minded at the same time.”

- Edsger W. Dijkstra Divide and conquer – break up into sub-problems, solve them individually and then combine their solutions to form the solution to the larger problem.

Core intellectual meta-activity during system analysis and design.

SoC-effectiveness is a measure of how good a development paradigm is. (OO-techniques provide better SoC than pre-OO techniques).

1b. OO technology / Object “thinking”

Recall from lecture F01:

A paradigm shift in software development

Encapsulation – everything to do with a “thing” in one place!

Reuse, polymorphism, interfaces, etc…

Easier to map real world phenomena to software elements

Modularity

comprehension

complex software systems

Only a small step w.r.t. SoC

Perfectly possible to design “spaghetti”-systems using OO

Decomposition along a single dimension

1c. Enhancements to OO (1)

OORAM

Object Oriented Role Analysis Model

Address the shortcomings of Object Orientation

Most common OOP languages are actually Class Oriented

Role models and model synthesis

capture phenomena as descriptions of object–collaboration patterns

Small per-concern metamodels / recipes for implementing specific concerns Abstractions above object models

Derive a system through a synthesis of several role models

A precursor for UML (Collaboration diagrams)

1c. Enhancements to OO (2)

OORAM:

1c. Enhancements to OO (3)

UML and OCL

UML: De-facto standard modeling language

OCL: Express contraints and rules over object models

Enabling technologies for MDE / MDA.

Design Patterns / Analysis Patterns

Repeatable general solutions for common

analysis and design problems

Visitor, Observer, Abstract Factory, etc.

SoC-guidelines, reduce risk of ending up with

intangible systems

Collected over time – experience Anti-patterns

1d. Agents and Services (1)

“Goal-orientation” / “Capability-Orientation”

Explosion of network- and Internet-based computing

interconnected systems with individual agendas and priorities

emergence of need to represent systems in terms of

business-goals and services

Natural evolution from OO thinking

Agent-Based Software Development

Agent-based system: System of multiple interacting agents that

autonomously pursue individual or common interests based on

inherent knowledge and continuous environment sensing.

Agents: “Smart objects / autonomous entities” with beliefs, goals,

responsibilities and plans.

1d. Agents and Services (2)

1d. Agents and Services (3)

1d. Agents and Services (4)

Services and SOA:

Recall F09 and F10!

Independent services with well-defined interfaces

Loosely coupled, black-box software elements

Distributed capabilities and ownership

Better SoC with Agents and/or Services

Higher abstraction

Modularization beyond the object-concept (complementary)

More natural translation of requirements into software design

Easier to reason about distributed systems

1e. Model-centric “thinking” (1)

Model Driven Engineering / MDA

Further mechanization in terms of SoC

Shift from code-centric to model-centric development

Graphical modeling tools (often domain specific)

(Semi-)automation of translation from design to implementation

CIM, PIM, PSM, mappings / transformations, and all that…

☺

J2EE

1e. Model-centric “thinking” (2)

Automation in software development:

Requirements Requirements Requirements

Implementation Source in a general-purpose language, e.g., Java or C++ Implementation (may generate code in Java or C++) Source in domain-specific language (DSL) Implementation (may generate code in Java or C++) Source in domain-specific language (DSL) High-level spec (functional and nonfunctional) Manually implement Manually implement Manually implement

Compile Compile Compile

1e. Model-centric “thinking” (3)

Contribution in terms of SoC

Higher abstraction

Multiple views of a system during design

Easier to perform round-trip engineering

Models are not just additional documentation artifacts, but they are the

actual source

Instant feedback through simulation / rapid code generation

Metamodelling, domain specific languages

Narrowing of the path between requirements and implementation!

Better SoC?

Yes, clearly!

Part 2 – Aspect-Oriented

2a. Motivation (1)

Good system architecture

Must consider both current and future requirements in order to avoid patchy-looking implementations

Problem

Requirements have become increasingly complex

Pervasive, competing concerns (security, logging, fault tolerance, QoS…)

Conventional design and implementation techniques are not enough

Only allow SoC along a small / fixed set of dimensions Tyranny of the dominant decomposition

Crosscutting concerns

Code tangling Code scattering

Multidimensional concerns / requirements, but only one-dimensional modularization available in implementation platforms

2a. Motivation (2)

Scattering:

Design element to support R1 in many places of OO design

Tangling:

Single OO design unit has elements for many

2a. Motivation (3)

The pain of crosscutting concerns / features…

…Understanding, analyzing and changing them!

Information is distributed

Maintaining consistency in the presence of changes is difficult Difficult to consider alternative treatments

Lack of attention to crosscutting concerns early in the development

cycle can lead to major redesign in later stages of development.

2a. Motivation (4)

The solution

Need “tools” for simultaneous separation of overlapping concerns

in multiple dimensions

Some temporary solutions to this have been around for a while:

Design patterns, mix-in classes, domain-specific solution (EJB frameworks) None address the problem at its roots, still tangling and scattering of

crosscutting concerns (tyranny of the dominant decomposition prevails)

The real solution – breaking the tyranny:

Aspect Orientation

Aspect: modular unit designed to implement a concern. With respect to a primary / dominant decomposition an aspect is a concern that crosscuts that decomposition.

2b. Introduction (1)

Aspect oriented development – 3 main steps

Aspectual decomposition:

Decompose the requirements, identify crosscutting and common concerns. Separate module-level concerns from crosscutting system-level concerns. Example: core credit card processing, logging, and authentication.

Concerns implementation:

Implement each concern separately.

Example: core credit card processing unit, logging unit, and authentication unit.

Aspectual recomposition:

Specify recomposition rules by creating modularization units -- aspects.

Example: must log each operation's start and completion, each operation must clear authentication before executing business logic.

2c. Aspects (1)

System-level crosscutting concerns:

Logging

Authentication

Fault-tolerance

…

Domain-specific crosscutting concerns:

Billing

Timing

Monitoring

…

2c. Aspects (2)

Implementation level:

AOP languages, multidimensional separation of concerns in the

implementation platform

easier translation from requirements to

implementation

Analysis and design level:

Need to identify aspect early in the development phase

AOAD techniques / Aspect Oriented Modeling

2d. Benefits of AOSD

Benefits:

Modularized implementation of crosscutting concerns

Easier-to-evolve systems

Since the aspected modules can be unaware of crosscutting concerns, it's easy to add newer functionality by creating new aspects. Further, when you add new modules to a system, the existing aspects crosscut them, helping create a coherent evolution.

Late binding of design decisions

An architect can delay making design decisions for future requirements, since (s)he can implement those as separate aspects

More reuse of components:

Aspects are more loosely-coupled components than objects (no tangling of concerns)

3a. AspectJ (1)

Introduction

Most popular AOP implementation, extends Java

Compiler (or “weaver-compiler”) produces standard Java class files

AspectJ program == Java program

3a. AspectJ (2)

1 overlay onto Java

Joinpoint:

well-defined point in a program's flow. For example, joinpoints could define calls to specific methods in a class

4 small additions to Java

Pointcut:

Construct to pick out joinpoints and collect context (values) at those points

Advice:

Code (additional action) that executes upon meeting certain conditions. For example, an advice could log a message before executing a joinpoint

Inter-type declarations ( aka “open classes” ) Aspect:

unit of modularity for behavior that crosscuts.

3a. AspectJ (3)

Hello world (base code)

Plain old java

//HelloWorld.java

public class HelloWorld {

public static void say(String message){ System.out.println(message);

}

public static void sayToPerson(String message, String name){ System.out.println(name + ", " + message);

} }

3a. AspectJ (4)

Manners (aspect code)

//MannersAspect.java

public aspect MannersAspect {

pointcut callSayMessage() :

call( public static void HelloWorld.say*(..) );

before() : callSayMessage() { System.out.println("Good day!"); } after() : callSayMessage() { System.out.println("Thank you!"); } }

Aspect

Pointcut

Joinpoint

designation

Advice

3a. AspectJ (5)

Compiled (woven) program:

“Good day!” will be printed before each message and “Thank you!” after each message.

If we add another method in class HelloWorld that fits the joinpoint designation of the callSayMessage pointcut, the aspect advice will apply there as well:

public class HelloWorld {

… …

public static void sayToGroup(String message, List names){

//call sayToPerson for each name in the names-List. }

}

Note how the base code is totally unaware of being “aspected” by the

manners concern.

3a. AspectJ (6)

Pseudo-example: Telecom setting

Base: Call routing and setup logic

Aspects: Timing, Logging, Billing, QoS, …

public class Customer{…}

public class Call{…}

public abstract class Connection{…}

public class Local extends Connection{…}

public class LongDistance extends Connection{…}

…

public aspect TimerLog{…} public aspect Timing{…} public aspect Billing{

precedence: Billing, Timing; …

… }

These are trivial examples, AspectJ can do a lot of neat things

Aspect precedency in situations where advice from

several aspects affect same joinpoints

4a. AOM in general

Fusing AO-concepts and Model Driven Engineering

Leveraging the strengths of two great advancements in software development

The Theme Approach

Theme/Doc (analysis)

Theme/UML (design)

Partial tool support

AOMDF (Aspect Oriented Model Driven Framework)

Structural and behavioural AOM, extends UML Automated model compositions of Class diagrams and Sequence diagrams

Tools support in near future Design only

4a. AOM in general (2)

4b. AOMDF – Overview (2)

application domain namespace

compose

composition directives

instantiate

values used in bindings model element names values used in bindings

aspect

class model 1 aspect

class model 1

instantiate

primary class model

composed class model

context-specific aspect class models

class models context-specific aspect

4c. AOMDF - Interactions (1)

ma(x)

mb(x)

:|C :D :E

4c. AOMDF - Interactions (2)

4c. AOMDF - Interactions (3)

4c. AOMDF - Interactions (4)

4c. AOMDF - Interactions (5)

5a. Summarizing thoughts

Contribution to SoC

Better separation of crosscutting concerns with AOSD

AOP vs. AOM

Common theme: Improved support for SoC

Code vs. models

Code provides a single view of behaviour

AOP aspects crosscut source code modules

Models provide multiple overlapping views of a systems

Views support separation of concerns AOM aspects crosscut views in a model

AOM design models are not necessarily descriptions of aspect-oriented

programs

5b. Future

Much happening in the AOSD-field…

Several AOP languages and tools have emerged…

Many variants / frameworks for AOM, standardization?

Tool support for AOM…

Further research on multidimensional SoC…

AOSD is the next (or actually the current) big thing…

Thesis suggestions available (AOM-related)

6. References

Articles:

Solberg, A. et al, Developing Service Oriented Systems Using An Aspect Oriented Model Driven Framework, International Journal of Cooperative Information Systems (IJCIS), 2006 Clarke, S. and Baniassad, E., Theme: An Approach for Aspect-Oriented Analysis and Design, Proceedings of the International Conference on Software Engineering (ICSE), 2004 IBM Research, Multi-Dimensional Separation of Concerns: An Overview,

http://www.research.ibm.com/hyperspace/MDSOC.htm

Laddad, R., I want my AOP! (Part 1),

http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html, 2002

Laddad, R., I want my AOP! (Part 2),

http://www.javaworld.com/javaworld/jw-03-2002/jw-0301-aspect2.html, 2002

Laddad, R., I want my AOP! (Part 3),

http://www.javaworld.com/javaworld/jw-04-2002/jw-0412-aspect3.html, 2002

Dijkstra, E. W., Selected Writings on Computing: A Personal Perspective, New York: Springer-Verlag, 1982. ISBN: 0387906525

6. References (2)

Books:

Filman, R. E. et al., Aspect-Oriented Software Development: Addison-Wesley Professional, 2005. ISBN: 0321219767

Clarke, S. and Baniassad, E., Aspect-Oriented Analysis and Design – The Theme Approach: Addison-Wesley Professional, 2005. ISBN: 0321246748

Jacobson, I. and Ng, P-W., Aspect-Oriented Software Development With Use Cases: Addison-Wesley Professional, 2005. ISBN: 0321246748

Luck, M. et al., Agent-Based Software Development: Artech House Publishers, 2004. ISBN: 1580536050

Websites:

www.aosd.net

www.early-aspects.net www.aosd-europe.net

www.aspectj.com(now an Eclipse project: www.eclipse.org/aspectj)

www.aspectc.org