Towards a two-dimensional separation of concerns (poster session)

• Authors: Constantinos A. Constantinides;Tzilla Elrad
• Venue: OOPSLA '00 Addendum to the 2000 proceedings of the conference on Object-oriented programming, systems, languages, and applications (Addendum)
• Year: 2000

As the size and requirements of software systems increase, their design has reached a complexity that requires software engineers to revisit the principle of separation of concerns [5]. Traditional software organization has been performed along some form of functional decomposition. Different paradigms and languages support the implementation, and composition of sub-parts into whole systems through the availability of some modular unit of functionality (component). In essence, traditional software decomposition and current programming languages have been mutually supportive [4]. At the same time, separation of concerns can only be beneficial if the different concerns can be effectively composed to produce the overall system. The OOP paradigm seems to work well only if the problem to be solved can be described with relatively simple interfaces among objects. Unfortunately, this is not the case when we move from sequential programming to concurrent programming where the component interaction violates simple object interfaces. One of the reasons behind this is the inherent structure of today's software systems that conceptually does not lead itself to a safe decomposition. As a result, the benefits associated with OOP no longer hold. Component interactions limit reuse and make it difficult to validate the design and correctness of software systems. Reengineering of these systems is needed in order to meet future changes in requirements. This component interaction is based on a number of properties that affect the semantics or the performance of the system and do not localize well in one modular unit, but tend to cut-across groups of components resulting in a “code tangling” [4]. Example cross-cutting properties (or aspects) include synchronization, scheduling, and fault tolerance. This code tangling destroys modularity, making the source code difficult to develop and difficult to understand. It also limits reuse, making the source code difficult to evolve. It further makes programs more error prone. In essence, it destroys the quality of the software. In [1] the authors refer to these phenomena as “composition anomalies”. This composition anomaly requires a shift in the methodologies used to separate concerns. In conjunction with modular composition, adaptability and reuse remain major issues to be considered while building complex software systems. Aspect-Oriented Programming (AOP) [4] is an emerging methodology that addresses components and aspects at the analysis and design phase of the software life-cycle, using mechanisms to compose them at the implementation level with a growing number of different technologies.