Overview

• Home
• Introduction
• Features
• News
• Architecture

Usage

• Downloads
• Tutorials
• License

Community

• SVN
• Issue Tracker
• Mailing lists
• Wiki

Concepts

• AOP
• Syntax-based pointcuts
• Semantics-based pointcuts
• Ontologies
• Our joinpoint model
• Publications

Working on...

• [aPetStore]
• Breakpoint
• Dynamic weaving overhead analysis
• Phoenix
• [SharpDevelop addin]
• Context-Access

Misc

• Existing .NET approaches

Feeds

• Site
• News

A first pictoral view

What do you mean by Assembly?

You may take a look at a basic definition of the term. Basically, it's a piece of .NET-compatible compiled code (e.g. the output of the C# compiler). Please note that the input to SetPoint is compiled code, in contrast to other engines that take source code as input.

The rationale behind this is simple: if you got the source code, just build it before applying aspects to it. If you didn't, well...that's fine anyway!

Why do I need Preprocessing?

AOP in .NET can be done in several ways. We have chosen IL-code instrumentation. The .NET infrastructure does not bring any interesting hooks to achieve this on a class-loading or class-prejitting basis, so simple, post-build assembly processing has been chosen as the means to instrument code. Other approaches (e.g. AOP.NET) have decided to use the Profiling API to modify IL code before JIT compiling takes place.

What do you mean by Preweaving?

Weaving in AOP can basically done in three ways:

• Dynamic Proxies (e.g. Aspect#: weaving is done explicitly by the base code programmer by using an AOP-engine-provided object construction factory.
• Advice weaving (e.g. AspectDNG: advice is added directly to the base code method, but no dynamic change on that code is afterwards possible.
• Hook weaving (e.g. http://janus.cs.utwente.nl:8000/twiki/bin/view/Composer/ComposeStar): base code is modified by adding hooks to it. During runtime, a weaver will dynamically decide which way to go (i.e. which aspects to apply, based on potentially evolving rules)
  
  We went for the third option, which calls for a pre-build step that adds the hooks. We call the action of adding hooks to the base code preweaving.

What do you mean by Semantication?

Our model sees software as describable from several perspectives. One of the them is what we call the code perspective (i.e. basically when you see your application through the source code lens). Given that an assembly can easily be described using this perspective by doing simple reflection on its available metadata, we pre-compute the representation of this perspective (we use RDF XML-serialization for knowledge representation) and store it in the assembly as a resource.

We call this post-build process semantication.

What's an Aspectualized assembly?

Basically an assembly that has already undergone both preweaving and semantication. It means it's ready to be understood by the SetPoint runtime and aspects can easily be added to it.

Must SetPoint.dll always be present?

Yes, it must. We previously mentioned that we have chosen to do dynamic weaving (advice is added during runtime). Someone has to do that job, and that someone lives inside SetPoint.dll.

What about the Configuration Assembly?

It must be there too. Pointcut definitions, advices, aspects and ontologies must live somewhere. We have chosen assemblies as the way of storing this data, but we're considering the move to any other, more textual representation. Why so? SetPoint's architecture is ready for dynamically changing configuration on the fly, but assemblies cannot be unloaded.

What goes inside it?

A Configuration Assembly has to declare a class that implements the setpoint.IConfiguration interface. Basically, it will be defining ontologies (in XML-serialized RDF format), pointcuts, aspects and advices.

Can I code the configuration assembly in C#/VB.NET/C++/Boo/etc?

Sure it can!

Do I need to?

No. As mentioned, you can perfectly write your configuration assembly code using C# or any other .NET compatible language, as long as you declare a class that implements the setpoint.IConfiguration interface. But we think that that's not comfortable enough, and that's why we created LENDL.

What's LENDL?

*L*ittle asp*E*ct & poi*N*tcut *D*efinition *L*anguage. It's basically a declarative domain-specific-language that lets you define ontologies, pointcuts, aspects and advices the easy way (or so we think ).

What on earth are ontologies?

You can take a look at this definition, but basically we're referring to a formal description of a concept. As mentioned before, we see software as describable from different perspectives. An ontology basically refers to achieving a formal representation of those perspectives. Just in case, you're already using ontologies! Class hierarchies and relational database diagramas are ontologies. We simply have chosen a different way of describing ontologies: OWL.

Why didn't you use an image map to explain the diagram, just the way civilized people do?

Because the website is automatically generated from our wiki and the Confluence engine behind it (even though it's amazing in every other respect) does not support image maps.