[aosd-discuss] AOP and Modern OO approaches

Fri May 11 06:12:05 EDT 2007

I agree.  I think 'agile aspects' are relevant.

It is possible to identify headline aspects early during the requirements definition phase (Boucke, et al.,  2006.  Relating Architectural Views with Architectural Concerns).  It is unlikely that systems architecture would be mature enough to provide a detailed aspects picture this early in the development process.   

Perhaps just identifying headline aspects from the requirements analysis will help minimise emergent problems during software development, and reduce the need for fine-grained aspect controls.  

I suspect there is a tradeoff here between architectural aims and practical implementation.

Regards

Charles

________________________________

From: Dean Wampler [mailto:dean at aspectprogramming.com]
Sent: Thu 10/05/2007 13:24
To: Donisthorpe C (AT)
Cc: Dean Wampler; discuss at aosd.net
Subject: Re: [aosd-discuss] AOP and Modern OO approaches

Charles,  

I agree that depending too much on fine-grained controls causes problems. If you create lots of detailed, explicit dependencies between modules, you will have serious trouble with long-term maintenance. The paper by Tourwe, et al. on the "AOSD/Evolution Paradox" demonstrated this. In fact, it's a familiar problem from OOD, as well. I discussed it in my industry track paper at AOSD '07, which looked at OOD principles applied to AOD. 

I think we need to figure out how to hide these fine-grained details behind appropriate abstractions and then do all our aspect coupling (weaving, etc.) using these abstractions.

Concerning the goal of identifying the cross-cutting concerns early, I think that is certainly desirable, but the nature of development these days requires agility and responsiveness to changing requirements. Hence, we'll never succeed at identifying all of them up front. We need to figure out how to be agile with aspects, too, in my opinion.

Yours,

dean

On May 9, 2007, at 9:19 AM, Donisthorpe C ((AT)) wrote:

	Dean,

	Your suggestion that 'its a paradox that modularizing global, cross-cutting behaviours require very fine-grained control' is  interesting and prompts the following thought.  

	It would be more efficient to limit the effect of cross-cutting behaviours and reduce the overhead of 'fine-grained control' in the software.  This would have the benefit of simplifying the software development task. It could be simplified if crosscut influence were minimised or constrained at the system level prior to software design.

	I think that crosscuts can be tackled at different levels in the development process and that early identification can make the detailed design task easier.   EA could simplify the system architecture and reduce the need for crosscutting effects by identifying and developing the headline aspects.  

	Perhaps, this analysis approach could be enhanced to help reduce the possibility of system failure as not all crosscut effects can be predicted within a large complex system.

	Regards

	Charles

________________________________

	From: discuss-bounces at aosd.net on behalf of Dean Wampler
	Sent: Wed 09/05/2007 14:07
	To: vamsidhar sharma
	Cc: discuss at aosd.net
	Subject: Re: [aosd-discuss] AOP and Modern OO approaches

	Since I wrote the presentation, perhaps I should field the question ;)

	All I meant by this statement is that AOP expands the options for 
	changing program behavior at the level of the class, individual 
	objects, and even individual methods and fields in an object. The OO 
	mechanisms you mention take you most of the way and they are great 
	when you can choose which subclasses to define and instantiate. Then 
	you can override methods as needed to change the behavior locally.

	You don't always have that freedom in some real-world systems, so 
	it's nice to have tools with sophisticated "join point models" that 
	let you reach into existing classes and objects and modify their 
	behavior, even dynamically. The better AOP tools let you specify 
	conditions for when this behavior should occur. For example, you can 
	say that "new behavior" N should only be added to a particular method 
	M if it is being called in the context of another method M1 and data 
	D has a particular value, etc., etc.

	However, the important point isn't that you have more fine-grained 
	control over the objects in the system. Rather, the important point 
	of AOP is that you can specify in one place (a "module") the state 
	and behaviors you want that are shared among an arbitrary number of 
	classes and objects that might not have any other relationship.

	Perhaps it's a paradox that modularizing these global, cross-cutting 
	behaviors requires very fine-grained control.

	Hope this helps.

	Dean

	On May 9, 2007, at 5:55 AM, vamsidhar sharma wrote:

	> While understanding AOP I found this article by Robert Martin
	>
	> http://objectmentor.com/resources/articles/AOP_in_Ruby.pdf
	>
	> In this the author says that modern OO desgin approaches like 
	> inheritance, design patterns, Inversion of control containers etc. 
	> work at a coarse grained level of interaction..
	>
	> Can anyone clarify what that means.. the coarse-grained level?
	>
	> Thanks
	> Vamsi
	>
	>
	>
	> __________________________________________________
	> Do You Yahoo!?
	> Tired of spam?  Yahoo! Mail has the best spam protection around
	> http://mail.yahoo.com <http://mail.yahoo.com/> 
	>
	> _______________________________________________
	> discuss mailing list    -    discuss at aosd.net
	>
	> To unsubscribe and change options, go to:
	> http://aosd.net/mailman/listinfo/discuss_aosd.net
	>
	> Check out the AOSD.net Wiki: http://aosd.net/wiki

	Dean Wampler, Ph.D.
	dean at objectmentor.com
	http://www.objectmentor.com <http://www.objectmentor.com/> 
	http://www.aspectprogramming.com <http://www.aspectprogramming.com/> 
	http://www.contract4j.org <http://www.contract4j.org/> 

	I want my tombstone to say:
	   Unknown Application Error in Dean Wampler.exe.
	   Application Terminated.
	       [Okay]        [Cancel]

	_______________________________________________
	discuss mailing list    -    discuss at aosd.net

	To unsubscribe and change options, go to:
	http://aosd.net/mailman/listinfo/discuss_aosd.net

	Check out the AOSD.net Wiki: http://aosd.net/wiki

Dean Wampler, Ph.D.
dean at objectmentor.com
http://www.objectmentor.com <http://www.objectmentor.com/> 
http://www.aspectprogramming.com <http://www.aspectprogramming.com/> 
http://www.contract4j.org <http://www.contract4j.org/> 

I want my tombstone to say:
  Unknown Application Error in Dean Wampler.exe.
  Application Terminated.
      [Okay]        [Cancel]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20070511/1920fc0f/attachment.html 