1 / 48

Obvious or Not? R egulating Architectural Decisions Using Aspect-Oriented Programming

Obvious or Not? R egulating Architectural Decisions Using Aspect-Oriented Programming. Mati Shomrat MS Thesis - TAU 2001 AOSD 2002 paper M. Shomrat & A. Yehudai. What is Software Architecture?. CMU Software Engineering Institute has approximately 100 definitions for “Software Architecture”:

aliya
Download Presentation

Obvious or Not? R egulating Architectural Decisions Using Aspect-Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Obvious or Not?Regulating Architectural Decisions UsingAspect-Oriented Programming Mati Shomrat MS Thesis - TAU 2001 AOSD 2002 paper M. Shomrat & A. Yehudai Regulating Architectual Decisions using AspectJ

  2. 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 Regulating Architectual Decisions using AspectJ

  3. 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) Regulating Architectual Decisions using AspectJ

  4. X CPU controller DetailedDisk controller X ContiguosDisk BufferingDisk controller controller DiskController:Mediator Design Model DiskController Monitoring Compliance of Software Systems with Its High-Level Design Models,M. Sefika, A. Sane and R. Campbell Regulating Architectual Decisions using AspectJ

  5. 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. Regulating Architectual Decisions using AspectJ

  6. Guidelines: … … … … Does the implementation adheres to the architecture? Architecture Implementation ? Regulating Architectual Decisions using AspectJ

  7. The Problem • Implementing a regularity is a painstakin effort. • Verifying that a given system satisfies a regularity involve the analysis of the whole system. • Regularities will be very unstable with respect to system’s evolution. • It will be very difficult to change a regularity, because such a change must be introduced manually in many parts of the system. Regulating Architectual Decisions using AspectJ

  8. 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 Regulating Architectual Decisions using AspectJ

  9. Verification Enforcement vs. Verification Architecture Implementation ? Guidelines: … … … … Regulating Architectual Decisions using AspectJ

  10. Architecture Implementation Guidelines: … … … … Guidelines: … … … … Enforcement vs. Verification Enforcement Regulating Architectual Decisions using AspectJ

  11. Previous work • Verification • CCEL • GENOA • CoffeStrainer • Software Reflexion Models • Enforcement • LGA Regulating Architectual Decisions using AspectJ

  12. 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. Regulating Architectual Decisions using AspectJ

  13. LGA • The law covers • The structure of the system being produced. • The structure of the object base representing the state of the project. • The process of software development. • The evolution of the law itself. Regulating Architectual Decisions using AspectJ

  14. 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 Regulating Architectual Decisions using AspectJ

  15. 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 Regulating Architectual Decisions using AspectJ

  16. 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. Regulating Architectual Decisions using AspectJ

  17. 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. Regulating Architectual Decisions using AspectJ

  18. 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. Regulating Architectual Decisions using AspectJ

  19. 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. Regulating Architectual Decisions using AspectJ

  20. 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). Regulating Architectual Decisions using AspectJ

  21. 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 Regulating Architectual Decisions using AspectJ

  22. 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 messages • Sent(S,M,T) :- Level(Ls)@S, • Level(Lt)@T, • (Ls=Lt | Ls=Lt+1), • do(deliver(M)@T). Regulating Architectual Decisions using AspectJ

  23. 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 Regulating Architectual Decisions using AspectJ

  24. Using AOP as an Enforcement Tool Regulating Architectual Decisions using AspectJ

  25. AOP Verification = Enforcement Specify regularities as aspects Done only once Add the aspects to the system’s code Compile static dynamic Enforced by the compiler -compiler error / warning Becomes part of the system, will be activated at the time the event occur. Enforcement Regulating Architectual Decisions using AspectJ

  26. 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 Regulating Architectual Decisions using AspectJ

  27. 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. Regulating Architectual Decisions using AspectJ

  28. Programming languages usually adopt amodule­centered view of software. • AOP complements the module-centered approach with the mechanism for definition of cross-module regularities. Regulating Architectual Decisions using AspectJ

  29. Implementation Guidelines • General SpecificationThe specification should be described in abstract terms, later to be "hooked" into concrete systems. General Aspect Aspects “Hook” Concrete System Regulating Architectual Decisions using AspectJ

  30. Implementation Guidelines • On Time Detection Detection of law breaches in specifications should be made as early as possible. Static specification should be detected at compile time. • 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. • Single Tool ApproachNo other tool should be used to specify and enforce regularities other than the AspectJ language and compiler. Regulating Architectual Decisions using AspectJ

  31. Example: Distributed Architecture • Agents interacting with each other under a coordination policy. • The policy must be maintained by all agents. • Hence a crosscuting concern. • In our example, we must assume all use the same language, AspectJ. • Example: congestion control policy [Minsky and Unggureanu]. Regulating Architectual Decisions using AspectJ

  32. Congestion Control Policy • For each server S • Each client of S has a quantum of time dt assigned to, which is the minimal delay between any two requests. • The server can set the delay of an agent to a desired value. • If an agent attempts to send a message to S sooner than permiteed by its delay, the message is to be blocked. Regulating Architectual Decisions using AspectJ

  33. Congestion Control Policy • 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. Regulating Architectual Decisions using AspectJ

  34. 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); • } • } Regulating Architectual Decisions using AspectJ

  35. Congestion Control Policy • 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); Regulating Architectual Decisions using AspectJ

  36. 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); • } • } • … • } Regulating Architectual Decisions using AspectJ

  37. “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) { … } • } • … • } Regulating Architectual Decisions using AspectJ

  38. Example: Intensive Care Unit • Exclusive Access The kernel should have exclusive access to the machinery connected to the patient. • IndependenceThe kernel should be independent of the rest of the system. • Limited InterfaceThe kernel must provide an interface for use by the rest of the system. Regulating Architectual Decisions using AspectJ

  39. Kernelized Structure Not Kernel X Kernel Peripherals Regulating Architectual Decisions using AspectJ

  40. 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;} Regulating Architectual Decisions using AspectJ

  41. 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 Architectual Decisions using AspectJ

  42. 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 Architectual Decisions using AspectJ

  43. Regulating use interaction • Covers all actual uses • But • Cannot monitor and regulate static compilation dependencywhen a class declares a data member of another • class but does not actually use it. Regulating Architectual Decisions using AspectJ

  44. 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 Architectual Decisions using AspectJ

  45. 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 Regulating Architectual Decisions using AspectJ

  46. 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. Regulating Architectual Decisions using AspectJ

  47. 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. Regulating Architectual Decisions using AspectJ

  48. 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 AspectJ

More Related