We use the term multi-dimensional separation of concerns to denote separation of concerns involving: Multiple, arbitrary kinds (dimensions) of concerns. Separation according to these concerns simultaneously; i.e., a developer is not forced to choose a small number (usually one) of "dominant" dimensions of concern according to which to decompose a system at the expense of others. This separation must be more than just identification of concerns and of the code that pertains to each. It must include segregation (encapsulation) that is sufficient to limit significantly the impact of change. This does not mean that every change within a concern can affect only that concern; this is never possible. It means that, just as modules in a dominant decomposition localize the impact of many kinds of change and limit the impact (propagation) of others, so must this be true of any of the concerns. More precise definition of this requirement is an interesting topic for discussion and for further research. Overlapping or interacting concerns. It is appealing to think of many concerns as being independent or "orthogonal," but this is rarely the case in practice. It is essential to be able to support interacting concerns, while still achieving useful separation.
Friday, September 19, 2003
Ah, I see the IBM research has been doing stuff that is related to my idea of *OP views.
MDSOC
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment