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    -    [email protected]

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