Composable designs with UFA

While aspect–oriented approaches draw their strength from improving modularity at the source code level, their acceptance for wide spread application depends on a seamless embedding into the software life–cycle. When striving for an appropriate design notation for AOSD it is important to carefully balance the abstraction required by design with the precision required for implementing a given design. We choose the Aspectual Collaborations model [7, 5] as a basis, which allows separate development of modules comprising sets of collaborating classes and a posteriori integration of such modules. We present UFA (UML for Aspects) as an extension of the UML, which maps these modules to packages in UML. We furthermore focus on multiple levels of bindings between modules and their elements. UFA closes the gap between collaboration based design and an implementation that allows unanticipated composition in an aspect–oriented style. 1. WHEN DO ASPECTS ARISE? The notion of aspects as used in the AOP community seems to be closely related to the source code. It is defined by the crosscutting of concerns which is manifest in scattering and tangling of source code. In order to define a notation and a method for aspect–oriented design it is therefore important to examine whether the phenomenon of crosscutting also exists in earlier phases. There are two possible reasons, why crosscutting is less a problem in design, than it is in implementation: Firstly, for some aspects there exists a level of abstraction at which they appear atomic, i.e., without internal structure. This is the kind of aspects for which it suffices to attach a tagged value or property to certain UML symbols in the design. Persistence is such a concern, which may well be scattered over large parts of a model, but at a given level of abstraction a property {persistent} is enough to say. There would be little advantage in separating out the defi