[aosd-discuss] Balancing the scales - modularity or composition or can we have the best of b oth ?

[Awais Rashid]

Hi Andrew,

This is an interesting question. We are at present doing some studies of the
overhead of composition vs its benefits. IMO there are dependencies and
interactions amongst concerns that are inherent to a problem. These are what
Brookes referred to as "essential complexity". These are a fundamental part
of the problem and need to be addressed. A good modularity, abstraction and
composition mechanism should be able to provide means to manage this
essential complexity effectively. At times such complex interactions may be
revealed by a suitable approach. On the other hand, if a composition
specification adds further complex interactions then it is (in Brookes'
terms) accidental complexity. Aspects, whether in an asymmetric model or a
symmetric model, and if we can decouple them from their syntactic
dependencies on other concerns, can help manage and reason about some of the
essential complexity by bringing these complex dependencies to the forefront
of our thought. However, the syntactic dependencies in current AO models do
add additional complexity which is not inherent to a problem. I note that
this is not an issue of AO. This is an issue of any approach using tight
syntactic coupling. A number of people are looking at semantics-based or
more expressive composition models at various levels of abstractions that do
not rely on these syntactic dependencies. I feel this is where we would see
the full benefits of AO in handling complexity.

Awais.

> -----Original Message-----
> From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On Behalf
> Of Andrew Carton
> Sent: 28 January 2007 23:59
> To: discuss at aosd.net
> Subject: [aosd-discuss] Balancing the scales – modularity or composition
> or can we have the best of b oth ?
> 
> Hey all,
> 
> The AOSD community is working on advanced separation of concerns and ways
> to conveniently capture and reason about crosscutting behaviour as well as
> keeping existing decompositions intact. Abstraction allows a complex
> problem to be reasoned about by separating it up into smaller (modular)
> pieces. Even though abstraction and modularity are powerful techniques for
> separating concerns, they cannot be used without being complemented by
> composition. [1] It seems to me both separation and composition are
> balanced on the scales of complexity. When separation (abstraction +
> modularity) is improved, composition gets a lot more complicated. Equally
> when separation isn’t so good, there are less inter-modular interactions
> to worry about and composition is relatively easy. Are they inversely
> related? I have given a few examples below to why I think this is so and
> was wondering what people think.
> 
> In the symmetric design space (SOP[3] / Theme/UML[4] etc.), functionality
> is abstracted (and separated) to one kind of concern-module whether it is
> crosscutting or not. This is a very powerful paradigm – by allowing
> overlap [2], each module can be designed orthogonal to each other and one
> has gained a total “multidimensional” separation of concerns. However by
> allowing overlap to achieve better separation, it also has a negative
> impact on composition. Composition now involves resolving conflicts
> (conceptual, structural and perhaps even behavioural). [5] documents the
> intricacies involved and in my opinion, it is anything but easy! Parnas
> [6] writes about the “managerial” benefits of modularisation i.e. shorter
> development time. If each symmetric module is handed off to an
> individual/pair or even a separate design team in a software process, the
> parallel benefits are easy to see as Parnas suggests. However, as the
> composition is complicated, it will take more of an effort to recompose
> the system. The bottleneck of the process will be the designers left to
> recompose the modules. In effect, is development time really shorter?
> Theme/UML [4, pg 242-243] recognises the complexities involved in this
> approach and suggests some guidelines to reduce this complexity. Going
> back to my scale idea, in this example, separation is wonderful and we can
> see the full benefits suggested by Parnas, but on the other side
> composition is very complicated.
> 
> In the asymmetric approaches (such as AspectJ [7]), a crosscutting concern
> is abstracted and modularised from the base decomposition by using an
> aspect. Since the base is decomposed as normal and there is no overlap
> like in the symmetric approach, we don’t get as good separation of
> concerns. However, taking for example OO as the dominant decomposition,
> there is already quite good abstractions and modularisation constructs in
> place. AspectJ just adds some more constructs to the language to be able
> to deal with the ability to modularise crosscutting concerns. One could
> argue that these constructs are “just enough” to deal with both
> crosscutting and non-crosscutting behaviour. Perhaps “just enough” is all
> we will ever need? So what are the compositional effects of adding extra
> modular constructs? I would argue that they are similar to the symmetric
> approach. The aspect designer has to be able to compose or apply weaving
> semantics (pointcuts) to the base composition. This means that the
> crosscutting modules need to be understood. The responsibility is on the
> aspect designer not to interfere with behaviour and states it should not.
> Composition like before has got more complicated while adding these extra
> modular constructs. Looking at the scale again, in this example, “just
> enough” separation is achieved to reach the goals of modularity of
> crosscutting behaviour but compositional complexity increased also.
> 
> 
> Aspect-oriented modelling (from a model-driven perspective) attempts to
> increase both modular and compositional reasoning by raising the
> abstraction from the nitty-gritty of the implementation details. By
> applying transformations at different levels of abstractions one can
> achieve different levels of separation and different kinds of reasoning
> can be applied at each level. The approach seems very interesting. Where
> exactly does this approach fit in on the scale? I would love to say that
> this may be solution to reducing complexity entirely in software
> engineering but the tools/techniques seem to be still maturing and no
> doubt there are extra complexities involved with transformations and the
> refining process at each level.
> 
> Are we forever going to be making sacrifices between modularity and
> composition? Are we striving for the perfect balance between the two? Does
> complexity remain constant why we attempt to juggle the two? Is there even
> a scale? Is it even possible to have our cake and eat it too? Love to hear
> others thoughts on this! :)
> 
> Andrew
> 
> [1] Domain Models Are NOT Aspect Free  - Awais Rashid and Ana Moreira
> [2] N Degrees of Separation: Multi-Dimensional Separation of Concerns –
> Peri Tarr, Harold Ossher, Stanley M. Sutton, Jr., and William Harrison
> [3] Subject-oriented programming: a critique of pure objects - William
> Harrison Harold Ossher
> [4] Aspect-Oriented Analysis and Design – The Theme Approach – Siobhán
> Clarke, Elisa Baniassad
> [5] Subject-oriented composition - Harold Ossher, Matthew Kaplan, William
> Harrison, Alexander Katz and Vincent Kruskal
> [6] On the Criteria To Be Used in Decomposing Systems into Modules - D.L.
> Parnas
> [7] G. Kiczales. Aspect-oriented programming
> 
> 
> 
> _______________________________________________
> 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