Separation of concerns: Techniques, issues and implications

Abstract

System decomposition is one of the fundamental abstraction principles of software engineering. One way in which decomposition can be achieved and managed is through a concern-based approach. With reference to software, systems concerns can be viewed as distinct system aspects or features (e.g., functional and non-functional concerns). Concern-based decomposition has become central to software development because of the benefits that such an approach can potentially provide. In order to achieve such benefits, it is necessary to be able to represent and manage the different concerns separately - known as separation of concerns. Such separation is difficult to obtain given that software systems tend to encapsulate multiple dimensions of concerns that cut across functional requirements. One solution regularly applied is to use techniques that separate concerns along different dimensions and then integrate them with a base dimension. To apply this scenario consistently across the whole development process, the various techniques must be flexible and adaptive at both conceptual and implementation levels. This paper argues that these techniques lack in flexibility because the underlying principles that define them are not yet fully developed. In order to demonstrate this limitation, the paper draws on the strengths and weaknesses of some of the major techniques for separation. Such techniques are based on a set of criteria that underlie important aspects of the separation principle. A critical analysis based on the criteria will provide an indication of the areas in which specific techniques have limited ability. Based on the outcomes, implications of the study and future work are presented.