Aspect oriented Everything?

[Clifford Heath]

New_aspect wrote:
> What I want to know is,if anybody on a
> commercial scale is using AOSD to develop commercial products?

I have been using aspect oriented design techniques since 1992,
when I invented a name "contextual extension" for a feature that
occurred naturally in a data definition language I had designed
in 1983. Needless to say, the term "aspect oriented" wasn't then
current :-).

I introduced hierarchical aspect-oriented design to ManageSoft last
year, and we are finding my hierarchical approach (which extends and
generalises most of the current AOSD state-of-the-art) helps considerably
in the design and requirements phases - because it gives a better
framework for SOC. So yes, it's fair to say that AO design *is* being
used in a >1MLOC commercial product, which spans C++, Java, C# and Perl
as well as a number of proprietry domain-specific languages (for errors,
tracing, configuration variables, etc).

I should say that our aspect orientation goes far beyond its traditional
application to "infrastructure" aspects like logging etc (though we have
identified and use over 80 different infrastructure aspects). For example,
the ManageSoft product distributes software packages down a distribution
hierarchy. Each distribution server has a basic object type which is
extended with several facets. The Packages facet details which packages
are or should be on each server. The Hierarchy facet details where this
server lives in the hierarchy, and the Configuration facet details the
configuration state of each server. These facets are *independent* of
each other, yet belong to the same object - each reflects where the object
cuts across a particular aspect. It's a kind of polymorphism, so not really
that new.

I think that the use of Aspect Oriented techniques beyond the infrastructure
layers is the main area for adding value. As has been noted, infrastructure
requirements should be built into the basic language, or added through
low-impact libraries - Ruby allows (though by manual construction) the best
of both worlds in this regard.

We are using Ruby for a multiple tier generator based on an XML database
schema language. This generator makes use of Ruby's mixins and the
"extend" method to implement "facet realisation" - dynamic extension
of base classes to allow them to serve in a particular context.
This is primitive aspect oriented programming, and works well.

The generator produces data tiers in C# and C++, web services definitions
and implementations, web-service client proxy stubs that implement location-
and version-transparency, as well as high-quality printed documentation, SQL
DDL and stored procedures, and will be extended to cover test cases, schema
migration and perhaps user interfaces (in C#). Despite our database only
containing 58 tables, the 3KLOC generator reads a 1.2KLOC schema file
and generates over 50KL of high-quality, formatted, readable, commented
code. If I was a contractor it would be a license to print money. Of all
langages I've learnt or created, implementing this generator in Ruby using
aspect-oriented techniques is the only way to have kept it down to its current
3KLOC - and most of that code is templates!

> Is it the fact that AOP is new and, for most, confusing

Maybe. Although it is somewhat difficult to grapple with, the intrinsic
concepts are much simpler than current implementations indicate. AspectJ
had to integrate with Java, so had to multiply the basic concepts, and
had to live within the traditional source-file idiom. AOD tools *must*
support dynamic view synthesis, allowing visualisation of the system in
both composed and partly-composed form. I'm not aware of a tool that
does that. Aspect oriented design requires a visual language for presenting
designs. Some work has been done on adding AOD features to UML, but
basically it's difficult because AOD is used to implement multi-dimensional
designs - which can't easily be flattened to any 2-D language. I think
that the only hope there is for a 1-D (traditional text-based) language
which is supported by powerful graphical tools which allow filtering the
aspects exposed in dynamic views.

A true AOD language (as opposed to a hack preprocessor added to an
existing language) would also support dynamic extension (which I term
facet realisation). We do that in Ruby with mixins and extend(), but
it's a bit too "manual".

> Is an Open Source development ever going to gain the trust of industry?

What on earth has that got to do with AOP?

> What are the main features that may lead to AOSD adoption?

Proper filtering aspect browsers in an IDE for a naturally aspect-oriented
language. None of which currently exist, as far as I'm aware.

 > Is AOP the next step on from OOP?

Perhaps, if the tool support is provided.

 > Is it another chance for some of the lesser
> utilised languages to step up to Java and C++?

No. I don't believe that AOD can be adequately justified when implemented
as an extension to either C++ or Java. AFAIK, there is no viable candidate
for the title of the first viable aspect-oriented language.

I meant to publish a bunch of writings and tools at my nascent domain
www.aspectdesign.org, but my employer is not forthcoming with an IP
disclaimer to publish tools so the domain lies dormant and the tools
unwritten. Sigh. I honestly believe these tools must be open source.
I've previously tried to found a business based on simple, general
powerful software tools and languages, and have become convinced that
commercial survival is only possible with limited-purpose tools.
Proprietry standards for basic technologies are doomed.

Clifford Heath, cjh at spam-me-rotten.managesoft.com - you work it out.