On the Requirements for Concurrent Software Architectures to Support Advanced Separation of Concerns Constantinos A. Constantinides1 and Tzilla Elrad2 1
Department of Mathematical and Computer Sciences Loyola University, Chicago
[email protected] 2
Concurrent Programming Research Group Department of Computer Science Illinois Institute of Technology, Chicago
[email protected]
ABSTRACT Some of the open issues regarding the design and implementation of a concurrent software architecture that should support advanced separation of concerns lie at the level at which components and aspects integrate. Should the integration be at the source code or maybe at the object code? How do we better express the aspectual properties of systems? To what degree should an aspect oriented architecture support an open system? Should it enable dynamic adaptability? Should it support reusability? Should it further enable formal verification of systems properties? In this paper we address these issues in the context of a set of desired requirements for concurrent software architectures in order to be able to improve software quality.
1. Introduction As concurrent systems become larger, the interaction of their functional components becomes more complex. This component interaction is based on a number of properties, called aspects, that do not localize well in one modular unit, but tend to spread (cut-across) among groups of components resulting in “code-tangling” [Kiczales et al. 97]. Example properties include synchronization, and scheduling. These aspects are not random properties, but they constitute entities that affect the performance and semantics of the system. As a result of “codetangling”, the benefits associated with OOP do no longer hold. Component interactions can limit reuse and reengineering of these systems would thus become unavoidable in order to meet future changes in requirements. The code-tangling phenomenon generalizes on a number of problems that have been well studied in the literature, most notably the inheritance anomalies [Matsuoka and Yonezawa 93]. In [Ossher and Tarr 99] the authors advocate the inadequacy of the OOP paradigm to address a complete separation of concerns, arguing that OOP provides only one dimension along which concerns can be separated and thus dictating what was coined the “tyranny of dominant decomposition”. In [Bergmans and Aksit 00], the authors coin the term “composition anomaly” to describe a situation
where the conceptually natural composition of two concerns conflicts with a particular composition scheme during implementation. For “old technologies” where requirements are mainly functional and where functional components do not extensively interact with each other, we could argue that the dominant decomposition of OOP works well. As the demand shifts to more and more “horizontal” (cross-cutting) requirements, the dominant decomposition can no longer adequately represent systems structure.
2. Desired Requirements for Complex Systems We can collectively describe a set of system properties and behavior with the notion of requirements. In this section we will address a number of desired requirements for concurrent software architectures in order to improve software quality. Although we have addressed some of these requirements in the context of the Aspect Moderator Framework [Bader et al. 00, Constantinides et al. 00a,b], our discussion here will be made general. 2.1. Separation of Concerns During the Life Cycle and Level of Weaving. Although both components and aspects are used to express concerns in a system, there is an asymmetry between them, as they constitute two separate axes of decomposition. Both components and aspects should be identified as separate entities during the early stages of the software life cycle, and more specifically during the requirements and analysis stages. We believe that it would be interesting to support different levels of separation though we agree with [Mens et al. 97] that complete separation of concerns might not be desirable. The level of weaving defines the point up to which one manages (or wishes) to achieve separation of concerns in the system. The level of weaving moves along the compilation axis, and it can be pre-compile, compile or post-compile (execution time) weaving. 2.2. Weaving Mechanism. Aspect thinking has been traditionally present implicitly in software systems where aspects were
OOPSLA 2000 Workshop on Advanced Separation of Concerns in Object-Oriented Systems.
ancing aspect could replace the load distribution strategy woven before with a better one depending on the current load of managed servers. Another example is given by [Böllert 98] where a particular malfunction in a software system should deploy a tracing aspect to be woven and run without having to restart the software system.
manually woven into components (and into each other). A number of current technologies automate the process of weaving into one that incorporates inlining aspect code into functional code. On the other hand, a number of researchers view the process of weaving as one that corresponds to choosing and ordering of sub-components. How weaving will be achieved can depend on a number of factors. One factor is whether one would decide to provide linguistic support for aspect definition or whether one would use other technologies such as reflection (to address aspect definitions on the meta-level) or a more general framework approach.
In [Sánchez et al. 98] it is argued that COOP languages do not provide enough support for the development of true adaptable software either because aspects, such as synchronization, are mixed in the functional components, or because once components are woven the resulting piece of software is too rigid to be adapted or reconfigured at run-time. Dynamic adaptability (reconfigurability) ensures that runtime requirements can be met without the need to reengineer the software system or halt the running system in order to ensure the proper reconfiguration. Availability for mission-critical systems and online applications is the key factor for their survival in the business life cycle. In most of the cases, the unavailability of these systems would result in an increase in non-productive time.
2.3. Open Architecture and Software Adaptability. An essential requirement for concurrent (and other complex) systems is that they shall have an open software architecture by which components can be reconfigured or replaced and be connected with newly installed components without forcing reengineering of the whole system. The concept of an open architecture is related to the issue of adaptability which is a major property that characterizes complex software architectures [Aksit et al. 93, Callsen and Agha 94, Hofmeister and Purtilo 91]. Ecommerce and online client-server applications, like troubleticketing systems, on-line reservation systems, time-card reporting systems, and online auctions, are becoming increasingly popular. To ensure high availability and reliability, these systems are often designed according to the design methodology of open distributed systems. In [Fayad and Cline 96] the authors argue that using OO technology does not guarantee that the resulting software is going to be adaptable. Rather, adaptability must be explicitly engineered into a software system and in places where it will do the most good to the business. As requirements change over time and as slightly different problems arise over time, a system must be able to change and evolve. In [Fayad and Cline 96] the authors identify four factors that adaptability is associated with. Extensibility is defined as the ability to change the amount of the capabilities of the system, and flexibility is the ability to change the kinds of capabilities. Extensibility and flexibility imply high-level changes. On the other hand, tunability is defined as a change activity whereas fixability is the ability to fix one thing without affecting (breaking) other things. Both tunability and fixability imply low-level changes.
Extensibility and reconfigurability are the main characteristics of open concurrent (and distributed) systems. Current research for open distributed systems [Callsen and Agha 94, Hofmeister and Purtilo 91] has focused mainly on the formal methods for the design and development of these systems, and paid less attention to the software architecture of these systems. Recent work on pattern-oriented solutions for distributed systems [Schmidt 94] has proven to work well in the design and development of these systems. 2.4. Software Stability. Generally, the functional components of a concurrent system are stable. The majority of the engineering done for a software project should be done for the purpose of fitting the project to those areas that will not change. This yields a stable core design and, thus, a stable software product. On the other hand, interaction components are volatile and reactive to the environment needs and during the analysis phase of these systems, it is important to identify and isolate the functional components from the interaction components. Any changes that will be introduced to the system will mostly be directed towards the ‘shell’ of the system, as the core will remain stable. Using adaptability and stability, we avoid the endless circle of reengineering entire software projects for minor changes [Fayad and Laitinen 98, Fayad and Hamu 00, Fayad and Altman 00].
2.3.1. Static and Dynamic Adaptability. The issue of static and dynamic adaptability is related to the notion of static and dynamic weaving. Static adaptability, sometimes referred to as the extensibility property of the software system, ensures that the software system can accommodate the future requirements from the system engineering perspective but does not guarantee that run-time requirements can be met as well. Static weaving means to modify the source code of a class by inserting aspectspecific statements at join points. In other words, aspect code is inlined into classes. The result is a highly optimized woven code whose execution speed is comparable to that of code written by traditional methodologies (without AOP or related techniques). However, static weaving makes it difficult to later identify aspect-specific statements in woven code. As a consequence, adapting or replacing aspects dynamically can be time consuming or not possible at all. An example where this would be beneficial is given by [Matthijs et al. 97] where a load bal-
2.5. Reusability. Another desired requirement would be to provide a model where both components and aspects as well as architectural and design decisions can be reused. The importance of reuse lies on the fact that it can cut down costs, increase productivity and improve the quality of software. It has already been argued in the literature [Fayad and Cline 96] that the general feeling that Object-Oriented Programming promotes reuse and expandability by its very nature is rather a misconception as none of these issues is enforced. Rather, a software system must be specifically designed for reuse and expandability. A number of researchers are suggesting that the maximum potential for reuse is over the entire life cycle, where reuse is applied to each phase, and it must begin in the re2
quirements phase. Another important issue is the one of the verification of components and aspects in isolation from each other as well as to test and verify the collaboration of components and aspects. This would constitute an important phase in the design process.
been to provide common synchronization abstractions. With class libraries we manage to reuse code, but we cannot avoid code-tangling, as synchronization code would still have to be embedded into the functional components for example. 2.6. Classification of Aspects. In [Constantinides et al. 99] we proposed a categorization of aspects according to their level of cross-cutting within the OOP paradigm, thus referring to interobject and intra-object aspects. Further, an aspect such as synchronization can be considered a static aspect, as it is very unlikely that its policy will have to change during execution. On the other hand, a scheduling policy will most likely have to be adapted at run-time. For example, a preference control scheduling policy might need to dynamically change from random selection to context oriented. We can therefore view scheduling as a dynamic aspect. This categorization can better be viewed advantageous, when one considers the notion of partial evaluation. With partial evaluation, one would be able to locking the system on some potentially fixed aspects and hence one would not have to pay a lot for performance for aspects that are fixed on a particular application. With partial evaluation in mind, the programmer could be able to categorize aspects as fixed (static) or open (dynamic) for a particular application. It is also important to distinguish between aspects that may exist at the system level and aspects that may exist at the application level while some aspects may cut-across these layers. An example of multi-layer aspect is quality of service, QoS, which may span the application layer, the operating system layer, and the network layer as well.
2.5.1. Forms of Design-Level Reuse. Design reuse can be viewed as the attempt to share certain aspects of an approach across various projects. [Szyperski 98] names a number of established reuse techniques together with the sharing level they are best suited (Table 1). Table 1. Reuse techniques and their level of sharing. (adapted from [Szyperski 98]) TECHNIQUE LEVEL OF SHARING Sharing contracts Interfaces Sharing interaction architectures Patterns Sharing subsystem architectures Frameworks 2.5.1.1 Interfaces. Interfaces are the means by which the participants of a cluster of components (classes) will connect. An interface is a set of named operations that can be invoked by clients. 2.5.1.2 Design Patterns. Design patterns are microarchitectures that describe the abstract interaction between objects collaborating to solve a particular problem. A cataloging of design patterns is presented in [Gamma et al. 95]. Design patterns have been accepted widely as proven solutions of microarchitectural elements and several frameworks have adopted them in their implementation. The ACE framework [Schmidt 94] supports a number of communication software patterns, though it does not address the issue of separation of components and aspects. Further, a number of concurrency design patterns have been presented in [Lea 97, Larsen 99]. These patterns are based on Java concurrency primitives, but none of these patterns has captured the interaction issues between concurrency code and the functional code.
2.7. Inter-Aspect Relationships. An open problem remains the issue of aspect to aspect relationship. We can break this down into two areas: 1) Interrelationship of orthogonal aspects and 2) the existence and interrelationship of non-orthogonal aspects. The relationship of orthogonal aspects relies on their order of activation and on their validation and verification. Another requirement is to provide a model that is capable to address non-orthogonal aspects in a formal away in order to support correct integration with other components. Current aspectoriented architectures have addressed models where aspects are orthogonal and therefore present a flat structure. There are cases where aspects are not orthogonal, but they can cut across each other. In these cases the overall structure is not flat but rather hierarchical. The issue of non-orthogonal aspects still remains an open problem, which we believe can be addressed in either of two ways: 1) by language design and 2) by implementation. One way to achieve the latter is through the definition of aspect interfaces. These interfaces can define protocols that can be used for both aspect-to-component and aspect-toaspect communication.
2.5.1.3 Frameworks. A framework is a set of cooperating classes, some of which may be abstract, that make up a reusable design for a specific class of software. Frameworks have gained much attention as a general approach in OOP. An important role of a framework is its regulation of the interactions that the parts of the framework can engage in. By freezing certain design decisions in the framework, critical interoperation aspects can be fixed. Reuse of framework components can result in an improvement in programmer productivity as well as enhancing the reliability of software [Fayad and Schmidt 97]. A comparison between frameworks and other OO reuse techniques such as patterns and components is provided by [Johnson 97] where it is argued that a framework is a form of designlevel reuse such as a template [Volpano and Kieburtz 89] despite the fact that frameworks are expressed in a programming language rather than special purpose design notation or special tools.
2.8. Use of Assertions. Close to the issue of aspect interface definitions, is the concept of assertions. [Meyer 92] introduced the concept of Design by Contract in the context of the Eiffel programming language. Under this theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of some mutual obligations (contracts). These contracts govern the interaction of the element with the rest of the world. When assertions are placed in aspect interfaces, inter-aspect communication
2.5.1.4 Class Libraries. Other form of reuse is through the use of class libraries. To date the main goal of such libraries have 3
would then be based on a protocol, and it would thus observe the semantics of the system. This ability to perform a job according to the specifications and the reliability provided by assertions is a major component that would affect the quality of the software.
3. Conclusion Concurrent software systems are usually impeded by a lengthy software lifecycle due to their inherited complexity. One way to speed up the software development process for these systems and to shorten the time to market is to maximize reusability of the software components. Luckily, object-oriented languages and techniques have proven to work well in building these systems, although they do not ensure that the resulting software components are reusable and adaptable, and reusability and adaptability must be engineered into these systems. When designing these systems, software architects often seek proven solutions of micro-architectural elements, such as design patterns. Many of these patterns have been documented in the literature and they have succeeded in convincing project managers, software architects and developers to deploy them in their systems during the development of the software products, regardless of whether the product is built for in-house use or to sell out of the shelf. Software architects often seek opportunities to identify the hinges that support reusability and adaptability. The failure to isolate the functional requirements from the nonfunctional requirements is an assurance that the resulting software system will have a close architecture that will be hard to maintain. Quality, stability, and productivity are the main concerns for software architects and project managers. Quality is guaranteed if we can reuse proven solutions like design patterns. Further, stability is realized if we ensure that the resulting software system is adaptable enough to meet future requirement and productivity can be improved if we increase the number of the deployed design patterns rather than reinventing the wheel. Recent work on designing frameworks for concurrent and distributed applications has stressed the need for deploying design patterns and artifacts in the design and development of these systems. Despite the fact that these frameworks have been successful in addressing concurrency and distribution requirements for concurrent distributed systems, recent work in aspect-oriented programming has shown that non-functional requirements are the main barriers for reusability, and adaptability when building complex systems.
2.9. Order of Activation of Aspects. The order of activation of aspects is an issue that is related to the semantics of the model. The underlying technology should provide the means to define this order of activation. For example, in a fine-grained concurrent system, synchronization should be evaluated before scheduling. If authentication is introduced, it has to be evaluated before synchronization. 2.10. Avoidance of Classical Concurrency Problems. An important objective when designing concurrent systems is to be able to provide a model that avoids the problems associated with inheritance anomalies or priority inversion [Sha et al. 90]. 2.11. Aspect Definitions and Language Issues. An open problem in the AOP community remains the issue of what would constitute the most appropriate abstraction level at which to describe aspects. Using separate high level declarative aspect description languages would seem more appropriate than using the same language as the component language but there will be tradeoffs with the implementation of the weaving mechanism whose complexity would increase, especially as more declarative aspect languages might have to be added to the system. On the other hand, the ability to express components and aspects in the same language is advantageous as large-scale software systems are built based on COTS technology rather than with domain specific languages. In our view a software architecture should remain language neutral so that it could be implemented using any high-level language that implements a number of minimal facilities. It would also be interesting for an architecture to take advantage of high-level facilities such as reflection should these facilities exist. 2.12. Ease of Use. Another desired requirement is to provide a system that will be easy to use, even for addressing complex tasks. The learning curve of the technology is a factor that has to be taken into consideration.
We believe that one should focus on the desired requirements of concurrent systems and not exclusively on the technology one uses to achieve advanced separation of concerns, with the ultimate goal being the provision of software quality. Naturally one has to be aware of the tradeoffs between the available technologies.
2.13. Performance and Use of Partial Evaluation. Overall performance is a major concern. The speed and memory tradeoff for increased flexibility must be minimized. The end result must be useable in a practical setting. Performance optimization is certainly an issue. Language solutions have an advantage over performance because of the inlining of aspect code into component code. To this end, partial evaluation can help improving the performance of an aspect oriented software design. With partial evaluation, the programmer would be able to locking the system on some potentially fixed aspects and hence one would not have to pay a lot for performance for aspects that are fixed on a particular application.
REFERENCES [Aksit et. al 93] Aksit, M., Wakita, K., Bosch, J., Bergmans, L., and Yonezawa, A. (1993). Abstracting Object Interactions Using Composition Filters. In Guerraoui, R., Nierstrasz, O., and Riveill, M., editors, Object-Based Distributed Programming, volume 791 of Lecture Notes in Computer Science, pages 152184. ECOOP, Springer-Verlag. [Bader et al. 00] A. Bader, C. A. Constantinides, T. Elrad, T. Fuller, P. Netinant. Building Reusable Concurrent Software Systems. In Proceedings of the International Conference on 4
Parallel and Distributed Techniques and Applications (PDPTA 2000) special session on Distributed Objects in Computational Science. June 26 - 29, 2000. Las Vegas, Nevada, USA.
Oriented Foundations of Framework Design, John Wiley & Sons, New York, September 1999. [Fayad et al. 99b] Mohamed Fayad, Douglas Schmidt, and Ralph Johnson, Building Application Frameworks: ObjectOriented Foundations of Framework Design, John Wiley & Sons, New York, Sept. 1999.
[Bergmans and Aksit 00] Lodewijk Bergmans and Mehmet Aksit. Composing Software from Multiple Concerns: A Model and Composition Anomalies. ICSE 2000 2nd Workshop on Multidimensional Separation of Concerns.
[Gamma et al. 95] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns: Elements of Reusable ObjectOriented Software. Addison-Wesley, Reading, MA,1995.
[Böllert 98] Kai Böllert. Aspect-Oriented Programming Case Study: System Management Application. ECOOP ’98 Workshop on Aspect-Oriented Programming.
[Hofmeister and Purtilo 91] Hofmeister, C. R. and Purtilo, J. M. Dynamic Reconfiguration of Distributed Programs. In Proceedings 11th International Conference on Distributed Computing Systems, 1991, pp. 560-571.
[Callsen and Agha 94] Callsen, C. J. and Agha, G. A. Open Heterogeneous Computing in ActorSpace. Journal of Parallel and Distributed Computing, 1994, pp. 289-300. [Constantinides et al. 99] Constantinos A. Constantinides, Atef Bader and Tzilla Elrad. An Aspect-Oriented Design Framework for Concurrent Systems. ECOOP ‘99 Workshop on Aspect-Oriented Programming.
[Johnson 97] Ralph E. Johnson. Frameworks = ( Components + Patterns). In Communications of the ACM. Vol. 40. No. 10. October 1997, pp. 39-42. [Kiczales et al. 97] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-Oriented Programming. In Proceedings of ECOOP ’97. LNCS 1241. Springer-Verlag, pp. 220-242.
[Constantinides et al. 00a] Constantinos A. Constantinides, Atef Bader, Tzilla Holzer Elrad, P. Netinant. Designing an Aspect-Oriented Framework in an Object-Oriented Environment. In ACM Computing Surveys Symposium on Application Frameworks, M.E. Fayad, Editor, Vol. 32, No. 1, March 2000.
[Larsen 99] Grant Larsen. Designing Component-Based Frameworks Using Patterns in the UML. In Communications of the ACM, Vol. 42, No. 10, Oct. 1999, pp. 38-45.
[Constantinides et al. 00b] Constantinos A. Constantinides, Atef Bader and Tzilla Elrad. Separation of Concerns in the Design of Concurrent Software Systems. ECOOP 2000 Workshop on Aspects and Dimensions of Concerns.
[Lea 97] Doug Lea. Concurrent Programming in JavaTM. Design Principles and Patterns. Addison Wesley, 1997.
[Fayad and Altman 00] M. Fayad, and A. Altman. Introduction to Software Stability. In Communications of the ACM. May 2000.
[Matthijs et al. 97] Frank Matthijs, Wouter Joosen, Bart Vanhaute, Bert Robben, and Pieere Verbaeten. Aspects Should Not Die. ECOOP ’97 Workshop on Aspect-Oriented Programming.
[Fayad and Cline 96] Mohamed Fayad, and Marshall P. Cline. Aspects of Software Adaptability. In Communications of the ACM. Vol. 39. No. 10. October 1996, pp. 58-59.
[Matsuoka and Yonezawa 93] S. Matsuoka and A. Yonezawa. Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. In G. Agha, P. Wegner, and A. Yonezawa (editors) Research Directions in Concurrent Object-Oriented Programming. MIT Press, April 1993, pp. 107-150.
[Fayad and Hamu 00] M. Fayad and D. Hamu, Object-Oriented Enterprise Frameworks, Wiley & Sons, New York, (to appear October 2000).
[Mens et al. 97] Kim Mens, Cristina Lopes, Badir Tekinerdogan, and Gregor Kiczales. Aspect-Oriented Programming. Report of the ECOOP ’97 Workshop for Aspect-Oriented Programming.
[Fayad and Johnson 99] Mohamed Fayad and Ralph Johnson Domain-Specific Application Frameworks: Experience by Industry, John Wiley & Sons, New York, October 1999.
[Meyer 92] Applying “Design by Contract”. In IEEE Computer. October 1992, pp. 40-52.
[Fayad and Laitinen 98] Fayad and M. Laitinen, Transition to Object-Oriented Software Development, John Wiley & Sons, New York, August 1998.
[Orfali and Harkey 98] Orfali, R., and Harkey, D. Client-Server Programming with JAVA and CORBA. John Wiley, New York, NY, 1998.
[Fayad and Schmidt 97] Mohamed Fayad and Douglas Schmidt. Object-Oriented Application Frameworks. Communications of the ACM. Vol. 40. No. 10. October 1997, pp. 3238.
[Ossher and Tarr 99] Harold Ossher and Peri Tarr. MultiDimensional Separation of Concerns in Hyperspace. ECOOP ’99 Workshop on Aspect-Oriented Programming.
[Fayad et al. 99a] Mohamed Fayad, Douglas Schmidt, and Ralph Johnson, Building Application Frameworks: Object5
[Sánchez et al. 98] Fernando Sánchez, Juan Hernández, Juan Manuel Murillo, and Enrique Pedraza. Run-Time Adaptability of Synchronization Policies in Concurrent Object-Oriented Languages. ECOOP ’98 workshop on Aspect-Oriented Programming.
[Szyperski 98] Clemens Szyperski. Component Software. Beyond Object-Oriented Programming. Addison-Wesley, 1998. ISBN 0-201-17888-5. [Volpano and Kieburtz 89] Volpano D. M., and Kieburtz, R. B. The Templates Approach to Software Reuse. In T. J. Biggerstaff and A. J. Perlis, Eds., Software Reusability, Vol. I, ACM Press, 1989.
[Schmidt 94] D. Schmidt. ACE: an Object-Oriented Framework for Developing Distributed Applications, in Proceedings of the 6th USENIX C++ Technical Conference, Cambridge, MA, USENIX Association, April 1994.
[Vogel and Duddy 98] Vogel, A., and Duddy, K. JAVA Programming with CORBA. John Wiley, New York, NY, 1998.
[Sha et al. 90] Lui Sha, Ragunathan Rajkumar, John P. Lehoczky. Priority Inheritance Protocols: An Approach to RealTime Synchronization. In IEEE Transactions on Computers. Vol. 39, No. 9. September 1990, pp. 1175-1185.
6
