Classification of Aspects What is the best way

Classification of Aspects • What is the best way to view, manage and materialize aspects in a systems lifecycle. • Shortcomings of existing technologies in the field – Aspects : Design level – Aspects : Implementation level – Aspects : Execution • The way we view aspects at each of the above levels affects – Reusability – Manageability …

Object Orientation • A means to modularize data abstractions along with their operations • Mechanisms at your disposal: – Grouping – Reuse – Behavior extension • OOP helps, but not always: – Tangling – “Inheritance anomalies” • Extension is tied to inheritance

Object Orientation (continued) • So I need to code a bit more. So what ? – Manageability of you code decreases – Extensibility becomes more complicated – Error prone • People caught up with us and want more – – Requirements are becoming more and more complex Programs nowadays control/manage critical applications Evolution of requirements leads to program extensions/adaptation We would like to reuse, extend/adapt our system with the minimum amount of effort for us(code). – Minimum amount of changes to the client code.

There are ideas around • Software Components – “binary units of independent production, acquisition, and deployment that interact to form a functioning system” Clements Szyperski • Units and Mixins – Think of units and mixins as special modules and classes • Units : like java packages but linking is externally specified • Mixins : like classes but parameterized over their superclasess • Point made : – Objects simply cannot cut it. We need extra help to be able to efficiently extend a system without modifying or recompiling.

Aspects • “The definition” – Aspects are modules whose behavior crosscuts other system components • Join Points – Road signs within your application (textual, dynamic etc) that denote aspectual behavior integration points • Under AOSD terminology – There is a clear distinction between concerns and their applicability within your system. – Quantification and Obliviousness

Aspects and their life span • Aspect lifetime within a systems lifecycle – Design level – Implementation level – Execution time • The ability to refer, manage, and control your aspects as a different, distinct entity within your system, provides for better adaptability, extensibility, and reusability.

Aspects and their life span (continued) • Design – Separate different issues that the program should tackle – Assignment of responsibilities to different groups of people (obliviousness) – Reuse of your design denotes the alteration of a part (aspect) of your initial design. • Implementation – A more direct mapping from design to code – Allows for reuse and grouping of aspects (inheritance) – Ease of understanding /maintenance

Aspects and their life span (continued) • Execution – – Runtime reconfiguration of your system Runtime adaptability and extensibility Plug-and-Play aspects / components Possibility to also incorporate runtime checks for correct composition of aspects and components (claim!) • Final result : – A system where aspects and software components are different entities that can play together through well defined interfaces – “Linking” of the above artifacts can happen at runtime (with the possible addition of a checker / verifier !)

Lets talk code Technologies Separate Compilation Aspect. J NO Runtime Adaptability NO Demeter. J/DJ NO NO Hyper. J YES NO AMF YES DJ-Aspects YES

Lets talk code (continued) • Limitations arise due to implementation decisions – Aspect. J weaves in aspectual code at compile time. Dynamic join point model is a combination of call graph analysis and deployment of reflection. – Hyper. J uses bytecode engineering, thus allowing for separate compilation but no runtime adaptability. – Demeter. J/DJ through the usage of visitors. • Demeter. J generates extra code (similar to Aspect. J) • DJ deploys reflection instead – AMF depends on a framework design and reflection – DJ-Aspects use Meta Programming techniques

Lets talk code (continued) • What is it that we need to obtain both facilities – The ability to refer to Aspects as independent modules/artifacts at runtime – The ability to seamlessly alter the applications architecture without disrupting the overall execution • Why do we need both facilities – Allow for aspects and components to be composed together : • Extensible software • Better reuse • Runtime Adaptability

An example • A simple airport … • Setup : – – One runway First Come first serve basis Landing and takeoff queues Control tower needs to coordinate them • What are our aspects – Synchronization – Scheduling – Authentication

An example (continued) • Nature of your aspects – Authentication : one time deal, consider the method as fixed and thus the aspect as “static” in its behavior – Synchronization : Only one plane in the runway at a time. Behavior does not change, however there is a dependency with scheduling ! – Scheduling : The policy might change according to events (planes are low in gas, emergencies etc). Needs to communicate with synchronization aspect – Scheduling and Synchronization are “non-orthogonal”

Traditionally • Write your code so that it covers all cases. – Is there such a solution ? • The system might need to evolve – More runways – Adapt according to air traffic • The nature of the application does not allow for : “stop-compile-deploy” approach.

Are you going anywhere with this !!!! • Consider each one of the constraints (authentication, scheduling, synchronization) as an aspect. • Your software components can be mapped to the physical artifacts of the problem (planes, runway, control tower) • Aspects interact with software components to ensure the correct operation of the whole system. • If a component needs to be added or a new aspect this can happen at runtime. • But there are still problems …

A new can of worms • What if I add a new aspect that does not preserve fairness between take-offs and landings ? • Even worse what if I add an aspect that performs synchronization in the wrong way ? • How do I know which aspect replaces which ? • If I add a new runway, how will that affect the system? I will need new aspects to attach to it plus balance the request between the 2 runways.

May we suggest … • A language or tool that allows for the existence of both aspects as well as software components at runtime as system artifacts that can be referred to and manipulated independently. [AMF , DJ-Aspects] • A mechanism with which one can define the composition of software components and aspects (think of join point designators, aspectual collaborations, Hyper. J) • A runtime check of “composition policies” to ensure proper execution of the whole system before actual integration of new components / aspects.

And more concretely … • The first 2 suggestions have been implemented and possible solutions are available • The last suggestion is hindered by difficulties: – Use Design By Contract to define pre and post conditions – A contract checker has to be incorporated with the language/tool that will verify at runtime pre and post hold before actual deployment. • This issue has been discussed in the context of DBC with OOP. [Findler and Felleisen]

And more concretely …(continued) • Interesting to see. . – Contract enforcement has an aspect flavor to it. (Example in Aspect. J tutorial) • The contract checking tool should also take into account the “law of substitutability of types” – A subtypes contract specification should be directly implied by its super type’s contract specification. • Types : – For classes – For aspects (allowing substitution only when appropriate)

The whole picture • Through inheritance : – We have grouping of aspects and object – Reuse of code – Denotes sharing of behavior • Through Contract specification and verification – Specify the aspects pre and post conditions – Verify whether one aspect is substitutable by another (through contract checks) – Verify “correctness” of each attachment with currently running code.