[aosd-discuss] Protection against anti-aspects

[Juri Memmert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger T. Alexander wrote:

>> I assume that a case study with a large customer in a territory that is
>> less than friendly to AOSD, so that they throw only almost impossible
>> problems at the tools, might be an option.
> 
> 
> We certainly need this, and badly. Any thoughts on who/where?

Sorry... No. Using AOSD that way is exceedingly hard unless you have a
large name.


>> I agree. Most can't. I have, on the other hand, received an interface
>> from a very good developer. It contained the methods, the reasons why to
>> call the methods, what parameters they expect (not just the types, but
>> the content) and what return values can be expected, how errors are
>> created and how to react to them. A few methods and about 10 pages of
>> JavaDoc. Itr was truly amazing and I never had any trouble with that
>> (functionally complex) interface. So it can be done... but it is
>> admittedly hard.
> 
> 
> Any chance I could get a copy of that to use for instructional purposes?

I will try.


> Any thoughts on how to make that problem easier?

Well... code good interfaces, of course. ;-)
The thing is that most of the practices are already there, they just
need to be applied rigidly.
I'll list a few from the top of my head:
- - An interface must only contain the methods that absolutely need to be
there, no more, no less.
- - An interface must only contain methods with 3 parameters or less.
- - If you need more parameters, use a parameter object with a validate()
method that gives a good rationale why thinks are not ok.
- - Avoid primitive return values as they do not have enough context
- - Do not throw standard Java exceptions but your own business exceptions
and pack them full of information the caller might use to understand and
possibly resolve the problem.
- - Make the methods of the interface "Controller methods" in the
implementing classes. This means that these classes merely call other
methods which actually perform the tasks required.
- - One task, one method. This not only simplifies the methods themselves
but also adds a large number of possible joinpoints that can be used
easily to add / change functionality.
- - Send back and forth a rationale that traces what went wrong and why

public ParameterObject interfaceMethod(OtherParameterObject aParameter)
{
	ParameterObject returnValue = doA(aParameter);
	doB(aParameter, returnValue);
	doC(aParameter, returnValue);

	// We do this because whatever
	if (returnValue.someCheck())
	{
		doD(aParameter, returnValue);
	}
	else
	{
		doE(aParameter, returnValue);
	}

	return returnValue;
}

A method such as this is easy to understand as it lists the tasks that
are needed to implement the interface as method names, contains no
business logic but delegates it to specialized objects and carries a
rationale through the call graph that you can fill with meaningful
information.

None of this is new. But most of it is never done. As a result, you get
mangled code with lots of crosscutting concerns and hard-to-reach
joinpoints.
Honestly, I do not worry about a class with 80 methods as long as 75 of
them are private, concise, well documented and handle one task each.


>> I agree that we reusew components... but in most cases not very well,
>> regardless of the interface... this is mostly due to some innate
>> shortcomings of OO (reuse of callgraphs instead of methods), but that is
>> a different discussion.
> 
> 
> Ah yes, but surely it would be an interesting discussion!

True. ;-)


>> I also agree that AOSD adds complexity. But AOSD approaches also add to
>> the number of modules and with a good approach, the complexity of the
>> individual modules goes down as well as the complexity of how they
>> interact...
> 
> 
> I don't disagree, and I think (hope) that the benefits will ultimately
> outweigh the costs. I can certainly see benefits in many of the examples
> folks commonly point out as evidence. However, my concern is is the
> more complex and subtle cases where the effects are not so easy to
> discern. Of course, the choice of language features can add to
> (e.g., AspectJ) the costs.

I agree. Complex scenarios require complex solutions and more often than
not, "adapters" of any kind are not worth the hassle.
I found that in a system A with a complexity of X and a system B with a
complexity of Y, the adapter between both, regardless of the paradigm,
be it OO or AOSD, is not X+Y but more along the lines of X*Y.
If now the adapter is scattered across multiple small, supposedly
independent aspects, this is very hard to comprehend.
If the adapter in itself is a running system that complexity is still
there but, in my experience, easier to handle.


>>> Not always, at least in my experience. Further, it is not clear that an
>>> what an aspect is at the requirements or modeling level, or whether it
>>> translates into an aspect at the implementation level.
>>
>>
>> It better does, or traceability is lost.
> 
> 
> Agreed, but sadly it happens far too often. I'm curious, how are you
> using aspect technology for requirements and modeling?

Oh, I am bad about that in a way. There are concern modeling approaches
like Theme/Doc (Banniassad and Clarke) that could do a lot of work for
you but since it's not available yet, for me it always comes down to the
concern model.
I need to (possibly arbitrarily) define concerns on the requirements
level and refine them through the other phases down to implementation.
I also make heavy use of search engines to find common keywords,
refactoring of documents and diagrams to contain only information about
one concern, etc.
It's a hassle and I end up with many more artifacts than traditionally.
This makes using a CMS system almost mandatory.
Then, I use the concern model as a meta-index over the CMS and within a
short time people using the CMS have grown used to using the concern model.


>> But most users of AspectJ seem
>> to have different uses for the tool than I have for an AOSD tool.
>> I need to provide traceability that links each and every requirement
>> down to each class (at least, oreferrably method level) over all
>> artifacts in the project (or at least those that concern me).
> 
> 
> Hmm, this argument applies equally to traditional approaches (i.e.,
> non-AOSD) to software development. Are you finding that AOSD makes
> it easier?

This problem is one of the reasons I was drawn to AOSD initially.
Ans yes, I do find it easier. While you increase the number of modules,
you also make it easier to find missing modules because the excuse "it
must be somewhere in there (pointing to a 500 page document)" does not
longer apply.
Of course, at the moment, a lot of it is done by hand or at best
semi-automated, but tool support will get better over time.


>> I also do
>> not need AOSD to simplify coding structures unless that makes a
>> requirement easier. I do not, for instance, replace an Observer with its
>> AOSD counterpart unless it is justified on a level different form the
>> code level.
> 
> 
> It's good to hear someone expressing some common sense!

Ouch, that hurt. ;-)
It is the only way. Gadgets don't pay my rent. But saving my project
lead's ass in a meeting because he can estimate the cost of a change
based on a concern model with an accuracy of a few man-days does.


>> Huh? You lost me at "thinking". ;-)
>> Yes, I agree. But surprisingly, the meta-information is in people's head
>> and you can pull it out there and create a meta-model of the application
>> and its interactions.
>> In some of my projects, I need to find a "Heisenbug" (the closer you
>> look, the harder the bugh is to find) in a short time (say 96 hours)
>> where the development team has spent 20 man-days looking. In most cases,
>> I just need a concern model of the new features added and the features
>> touched by these concerns and in the places where they overlap, the
>> error lies... Broken contracts account for 99% of the errors.
>> Working with the developers, it is possible to do that in surprisingly
>> short time... they just need to be shown how.
> 
> 
> I couldn't agree more.  However, I am always amazed at how difficult it
> is to teach developers this stuff, particularly the ones that have been
> working in the "real world" for a while.

Working in the real world messes up most developer's heads. ;-)
On the other hand, it also teaches them more about what can be done and
what can't than any university course ever could.
I think the major problem is that they do not strive for excellency
anymore because that, initially, costs more, and in the end, it's
probably not even used because some PHB has some other inane thought.
I found that scenarios where they are desperate for a solution work best
here. showing them what could have been done with a few more minutes of
development well in advance... because that's when their jobs are on the
line.


	Juri

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCTWW1dlXiXRccbPMRAj8dAJsEragczgfDUaXjZZkey80TyP+flACgrur8
eePnmobBpM+jPmuGB4lFss8=
=KRBG
-----END PGP SIGNATURE-----