1 How to Handle Interacting Concerns? J. Andrés Díaz Pace * , F. Trilnik and Marcelo R. Campo ISISTAN Research Institute, Facultad de Ciencias Exactas, Universidad Nacional del Centro de la Provincia de Buenos Aires Paraje Arroyo Seco, B7001BBO Tandil, Argentina Email: { adiaz , ftrilnik , mcampo } @exa.unicen.edu.ar * Also CONICET Abstract. Concerns in software applications can range from general-purpose concerns such as tracing, synchronization or error handling, to more specific ones such as scheduling in simulation domains or time constraints in real-time systems. An appropriate separation of concerns is supposed to reduce software complexity and improve software evolution, by keeping track of different decomposition criteria (software dimensions) at the same time. Usually relevant concerns vary over time, are not orthogonal and conflicting among them, and become very domain-specific. Reasoning about a flexible way of handling aspects involving interaction of concerns still remains as an open challenge. In this context, we present an example based on the simulation of a thermic control system, showing how aspects related to mathematical models, concurrency, scheduling and optimizations, are scattered across the system, and how these interacting concerns are separated from the core functionality but coupled among them. A reflective approach is used to support these aspects within an object-oriented language. This work hopes to contribute to discuss how interacting (and often conflicting) concerns work in practice, and encourage developers towards a more systematic approach for an effective separation of concerns. 1. Introduction There is a growing agreement on that separation of concerns [Parnas87] is one of the object- orientation promises that this technology did not successfully achieve yet. By concerns, we mean the primary components to organize and decompose software into more comprehensible parts. Different kinds of concerns can range from general-purpose concerns such as tracing, synchronization or error handling, to more specific ones such as scheduling in simulation domains or time constraints in real- time systems. The object paradigm promotes the decomposition of a system taking as basis modular units such as classes or objects, but developers cannot avoid the problem of having a dominant decomposition. On the other hand, an appropriate separation of concerns is supposed to reduce software complexity and improve software evolution, by keeping track of different decomposition criteria (software dimensions) at the same time. An important work has been done in this field [Aksit92, Bergmans96, Kickzales97, Lopes97, Ossher00], namely: identify canonical concerns, provide language support and specific architectures, or discuss aspect composition. However, the intrinsic nature of concerns makes still difficult to apply these ideas in practice, and little work has been reported in the literature about interacting concerns [Pawlak99, Vanhaute99]. Usually relevant concerns vary over time, are not orthogonal and conflicting among them, and become very domain-specific. Thus, aspect-developers have to know almost the entire system when they apply aspect technology, in order to prevent possible semantic conflicts during aspect composition. We faced this problem in a relatively simple simulation of a thermic control system, in which aspects related to mathematical models, concurrency, scheduling and optimizations, were scattered across the system. In this paper we discuss our approach to tackle this problem, using reflection techniques to support aspects separated from the core functionality but coupled among them. The rest of the paper is organized in 3 sections. The first section briefly presents a case study simulating a thermal control system, and outlines some tradeoffs derived from its design using an object-oriented view. Then, we describe how our simulation problem was implemented using a reflective aspect-oriented framework. This section also includes how we managed the interaction of concerns. Finally, we draw the results of this experience and discuss some challenging issues regarding effective separation of concerns and interacting concerns.