regulating architectual decisions using aspectj1 obvious or not? regulating architectural decisions...

Regulating Architectual Decisions using AspectJ1

Obvious or Not?Regulating Architectural Decisions UsingAspect-Oriented Programming

Mati Shomrat MS Thesis - TAU 2001AOSD 2002 paper M. Shomrat & A. Yehudai


What is Software Architecture?

CMU Software Engineering Institute has approximately 100 definitions for “Software Architecture”:

• set of significant decisions …• any high level diagram that is useful for

communicating or analyzing some aspects of a software system

• A set of architectural (or, if you will, design) elements that have a particular form


Architectural Decisions (Regularities)

An intuitive definition: Any global property of the system, or of a significant part of it, is part of its architecture.

Emphasize high-level properties (e.g a system’s overall structure)


DiskController:Mediator Design Model

CPU

controller

DiskController

DetailedDisk

controller

BufferingDisk

controller ContiguosDisk

controllerMonitoring Compliance of Software Systems with Its High-Level Design Models,M. Sefika, A. Sane and R. Campbell

X

X


Design Regularity

A regularity deals with the structure of the system, not with its functionality. It does so by regulating the various interactions between its component.


Does the implementation adheres to the architecture?

Guidelines:

…

…

…

…

Architecture Implementation

?


The Problem

1. Implementing a regularity is a painstakin effort.

2. Verifying that a given system satisfies a regularity involve the analysis of the whole system.

3. Regularities will be very unstable with respect to system’s evolution.

4. It will be very difficult to change a regularity, because such a change must be introduced manually in many parts of the system.


The essence of the Problem

The essence of the problem of implementing higher-level design principles is their globality.

By globality we mean the fact that these principles represent policies that are not confined to single units of the system but need to be observed throughout it's whole


Enforcement vs. Verification

Guidelines:

…

…

…

…

Architecture Implementation

Verification

?


Enforcement vs. Verification

Guidelines:

…

…

…

…

Architecture

Guidelines:

…

…

…

…

Implementation

Enforcement


Previous work

Verification• CCEL• GENOA• CoffeStrainer• Software Reflexion Models

Enforcement• LGA


Law Governed Architecture (LGA)

• Concept introduced by Minsky• Used for enforcing regularity in Object

systems, but has other uses as well.• This work inspired our approach.• LGA associates with a development project

an explicit and global set of rules, called the law of the project.

• The law is enforced by the environment that manages the project.

• Darwin/2 - an environment realizing it.


LGA

The law covers1. The structure of the system being

produced.2. The structure of the object base

representing the state of the project.3. The process of software development.4. The evolution of the law itself.


The Law and its enforcement

• The law regulates interactions between component objects

• Two kinds of regulated interactions:• Between component parts of the system: eg.

messages, inheritance– Enforced mostly statically, eg. when created, when

configuartions are compiled. • Between programmers and the system: eg.

Creation, modifications (also of the law itself)– Enforced dynamically


The object base

• The state of a project is represented by an object base, including

– Modules– Builders (eg. Programmers).– Rules (components of the law).

• An object has a set of attributes, the exterior of the object. Eg. module m may have

– level(3)– Programmer(b)

• Law establish semantics of attributes


Example law:Evolving layered systems (1)• Module objects partitioned into layers.• Builders are either manager or

programmer.• Each module owned by some programmer.• A manager can create programmer objects.• A programmer can make module, becomes

its owner.• Owner of a module may program it, set

level, pass to other programmer.


Example law:Evolving layered systems (2)• A message m from s to t is permitted

only if the following hold:– Message obeys layering constraints– M is acceptable to t– M is not prohibited

• The law can change only as follows:– A programmer can add/remove acceptable

rule for own modules.– A manager can add/remove prohibited rule.


Darwin/2 environment

Has two layers• Abstract, language independent layer,

implementing the abstract LGA model.– View of objects and interactions, and law.– Maintains object base, and enforces law.– Laws are expressed in prolog.

• Concrete layer, containing set of language interfaces, for modules to be written in.

– Maps abstract concepts to the language.– Language specific parts of enforcer.


Abstract model of LGA

• Law governed system (LGS) includes object base, global law, and enfocing mechanism.

• Messages are terms f(t1,t2,…,tk), where f is a symbol, ti is a term or variable.

• Variables are used to return results to sender.


Objects in LGA

• Objects consist of– Exterior - (control state) the part of the state

visible to the law and controlled by it.– Interior - the part of the state accessible by the

agent, and only by it.– Agent - manipulates the interior, and sends

and receives messages.

• An agent may be– Programmed (ie. a program module)– Unprogrammed (ie. a human user).


The role of the law in LGA

• The law is the mediator of interactions• A message m sent by s to t is submitted to the

law.• The ruling of the law may depend on m, s, t , and

the exterior of agents.• The ruling of the law is a (possibly empty)

sequence of operations:– Deliver a message m or a modified m’ to t or to some other

agent t’.– Modify the exterior of s and/or t.– Create or destroy objects.– Produce an error message


Representation of laws

• The law is represented by a simplified type of prolog program.

• When given a goal sent(s,m,t), it produces a list of primitive operations which are the ruling of the law for this event.

• Example - layer restricted messagesSent(S,M,T) :- Level(Ls)@S, Level(Lt)@T, (Ls=Lt | Ls=Lt+1), do(deliver(M)@T).


LGA / LGI

Example of the use of LGA for kernelized system (will be discussed in our approach).

cannot_call(_,C1,_,C2) :-cluster(kernel)@C1,not cluster(kernel)@C2

Kernel classes cannot call non-kernel classes


Using AOP as an Enforcement Tool


AOP Verification = Enforcement

Specify regularities as aspects

Add the aspects to the system’s code

Compile

static

Enforced by the compiler -compiler error / warning

dynamic

Becomes part of the system, will be activated at the time

the event occur.

Enforcement

Done only once


Imposing Regularities By Means of Programming Language

• Only very few types of regularities can bebuilt into any given language;...

• Regularities that do not have universalapplicability should not be built into a generalpurpose language.

• Programming languages usually adopt amodule centered view of software. ...

• Language imposed regularities are obviouslynot effective for multi lingual systems, ...

N. Minsky


AOP imposed regularities

Only very few types of regularities can be built into any given language;

Regularities that do not have universalapplicability should not be built into a general purpose language.

In program P whenever condition C occurs do A.


Programming languages usually adopt amodule centered view of software.

AOP complements the module-centered approach with the mechanism for definition of cross-module regularities.


Implementation Guidelines

1. General SpecificationThe specification should be described in abstract terms, later to be "hooked" into

concrete systems.

“Hook”

Concrete System

General Aspect

Aspects


Implementation Guidelines

2. On Time DetectionDetection of law breaches in specifications should be made as early as possible. Static specification should be detected at compile time.

3. Say What You MeanThe implementation of specifications should

be done in a clear way, if it can't be done so we regard it as if it can't be done.

4. Single Tool ApproachNo other tool should be used to specify and enforce regularities other than the AspectJ language and compiler.


Example: Distributed Architecture

1. Agents interacting with each other under a coordination policy.

2. The policy must be maintained by all agents.

3. Hence a crosscuting concern.

4. In our example, we must assume all use the same language, AspectJ.

5. Example: congestion control policy [Minsky and Unggureanu].


Congestion Control Policy

For each server S

1. Each client of S has a quantum of time dt assigned to, which is the minimal delay between any two requests.

2. The server can set the delay of an agent to a desired value.

3. If an agent attempts to send a message to S sooner than permiteed by its delay, the message is to be blocked.



Enforcing the policy with the AspectJ• Layered approach.• Top layer - general infrastructure for an

enforcement mechanism.• Second layer - specific policy, still

independent of a system.• Third layer (not shown) hooking the

abstract representation to a specific system.


Distributed Architecture

public abstract aspect DistributedEnforcementMechanism perthis (this(Agent)){

public interface Agent {}

abstract pointcut send(Agent sender); abstract pointcut arrived(Agent receiver);

interface Ruling { boolean evaluateSendRuling(Agent sndr); boolean evaluateArrivedRuling(Agent rcvr); }}



abstract aspect CongestionControlPolicy extends DistributedEnforcementMechanism {

public interface Server {} public interface Client {}

declare parents: Server implements Agent; declare parents: Client implements Agent;

abstract pointcut send(Agent a); abstract pointcut arrived(Agent a);


Congestion Control Policy (cont.)

class CCAttributes { long clock() { … } long getDelay() { … } long getLastCall() { … } … } // end of inner class CCAttributes

Object around(Agent sender) : send(sender) { if (ruling.evaluateSendRuling(sender)) { proceed(sender); } } …}


“Wait” ruling for the CCP

(still part of the second layer) Public boolean evaluateSendRuling(Agent sndr) { CongestionControlPolicy.CCAttributes attr = context.getAttributes();

If (sender instanceof Client) { long wait = attr.getLastCall() + attr.getDelay() - attr.clock() if ( wait > 0) { try { Thread.sleep(wait) } catch (Exception w) { … } } …}


Example: Intensive Care Unit

1. Exclusive Access The kernel should have exclusive access

to the machinery connected to the patient.

2. IndependenceThe kernel should be independent of the

rest of the system.

3. Limited InterfaceThe kernel must providean interface for use by the rest of the system.


Kernelized Structure

Not Kernel

Peripherals

Kernel

X


Kernelized Structure

abstract aspect Call { interface Kernel {} pointcut method_call() : within(Kernel+) && call(* !Kernel+(..));

declare error: method_call(): "method call from kernel class to non- kernel class";}

aspect CallHook extends Call { declare parents: <kernel classes> implements Kernel;}


Kernelized System: marking of the kernel part

abstract aspect KernelArchitecture {

public interface Kernel {} declare parents: <kernel classes> implements Kernel;

}

Drawback Need to list (and then update) all kernel classes.


Regulating use interaction

aspect CannotUse { pointcut generation(); call ((!Kernel+).new(..)) && within(Kernel+); pointcut method_call(); call (* (!Kernel+).*(..)) && within(Kernel+); pointcut field_access(); set(* (!Kernel+).*) || get(* (!Kernel+).*) && within(Kernel+); declare error: generation(): “creation of a non-kernel class within a kernel class” declare error: method_call(): “ method call … ”; declare error: field_access(): “ accessing non-… ”; }


Regulating use interaction

Covers all actual uses

But

Cannot monitor and regulate static compilation dependency

when a class declares a data member of another

class but does not actually use it.


Regulating inheritance

public aspect KernelArchitecture { public interface Kernel {} public interface NotKernel {} declare parents: <kernel classes> implements Kernel; declare parents: <kernel classes> implements NotKernel;

pointcut cannot_inherit(): Initialization((Kernel+).new(..)) && Initialization((NotKernel+).new(..));

declare error: cannot_inherit(): “ inheritance law breached ”; }


Regulating inheritance

• No explicit way to regulate inheritance in AspectJ• Need to list both kernel and non kernel classes• Relies on the fact that everyclass has a construcor• Discovers kernel class that inherits from non kernel

But• Also flags non kernel class that inherits from kernel• Only user classes can be tagged


Summary

• We pointed the connection between AOP and law enforcement.

• Explored the use of AOP techniques for the enforcement of architectural regularities, using the AspectJ programming language.

• Demonstrated how language and compile limitation prevents us from enforcing certain kinds of rules.


Conclusion

AOP can serve as a means for the enforcement of architectural regularities, but the language we used and the compiler’s current state prevents us from doing so.


Future Work

• Enhancing AspectJ to fully support static as well as dynamic join points.

• inherit• declare

• Consider an aspect architecture language - An AOP language specific for the specification and enforcement of architectural regularities.

regulating architectual decisions using aspectj1 obvious or not? regulating architectural decisions...

Documents

significant decisions

software architecture

yehudai slide

architecture guidelines

particular form slide

campbell x x slide

verification guidelines

aspectj5 design regularity