GenQA: Automated Addition of Architectural Quality Attribute Support for Java Software * Sarthak Grover * Business Objects, an SAP company 332 Front St S, 3rd Fl La Crosse, WI 54601 USA sarthak.grover@gmail.com Nigamanth Sridhar Electrical and Computer Engineering Cleveland State University Cleveland OH 44115 n.sridhar1@csuohio.edu ABSTRACT Non-functional requirements for software systems are typically spec- ified using informal notations such as quality attribute scenarios. Further, implementation strategies for such non-functional attributes are frequently common across systems with quite different func- tional requirements. In such cases, the time invested in implement- ing these quality attributes could be salvaged, thereby reducing the project lifetime and increasing software quality. In this paper, we present the design and prototype implementation of a tool and as- sociated framework that enables software engineers to effectively capture non-functional requirements, and then automatically gener- ate implementations of these requirements to be added to the appli- cation being built. The quality attribute implementations are gen- erated as aspects (AspectJ in the prototype) that can be weaved in with the application code (Java) with minimal development effort. Categories and Subject Descriptors D.2.11 [Software Architectures]: Languages; D.2.2 [Design Tools and Techniques]: Computer-aided software engineering General Terms Design Keywords Aspects, automated generation, software architecture 1. INTRODUCTION Maintainability, usability, traceability, security, fault tolerance, etc., are properties of software systems that are not directly re- lated to the functional behavior of the system. Instead, such non- functional properties are considered external to the functional spec- * This work was partially supported by a CAREER grant from the NSF (CNS-0746632). * This research was conducted when this author was a graduate stu- dent at Cleveland State University. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’09 March 8-12, 2009, Honolulu, Hawaii, U.S.A. Copyright 2009 ACM 978-1-60558-166-8/09/03 ...$5.00. ification. Architectural decisions often affect non-functional prop- erties of software systems. The nice thing about such non-functional properties is that their implementation is typically “agnostic” to the system under con- struction. For example, support for fault tolerance is typically im- plemented in a similar manner whether the system under construc- tion is a web server or a peer-to-peer file sharing system. However, to the frustration of software engineers, when non-functional prop- erties are specified as part of a system specification, it is difficult to cleanly separate such properties from the functional specifica- tion. Consequently, the commonality advantages of non-functional properties are difficult to exploit. The preferred solution to this problem is to move the specifica- tion of non-functional requirements out of the system specification, and instead include them as part of the architectural description of the system. By way of making architectural decisions, the software engineer can now endow a system with the requisite non-functional property. Non-functional requirements are described as quality at- tribute scenarios as part of the architecture description [1]. These quality attributes get into the design specification in the form of tactics, and are finally implemented in conjunction with the imple- mentation of the functional system. Our view in this paper is that implementation of architectural tactics to incorporate quality attributes should involve an activity that is separate from the implementation of the functional speci- fication. Moreover, the property that the implementation of such tactics does not depend upon the functional behavior of the system under consideration should be exploited as much as possible. To support this view, we present in this paper the design and a prototype implementation of GENQA, a tool and framework that allows software engineers to: 1. Capture non-functional requirements and automatically place them in context with respect to the functional specification, 2. Generate code to implement these architectural tactics in such a way as to cleanly separate the functional concerns of the system from the non-functional concerns. The rest of this paper is organized as follows. In Section 2, we present the design of GENQA, and describe the prototype imple- mentation for Java and AspectJ. In Section 3, we present some ex- amples to demonstrate our system. After presenting some related research in Section 4, we conclude with a summary of our contri- butions in Section 5. 2. THE GENQA FRAMEWORK The GENQA framework includes several components that col- laborate to capture non-functional requirements, and generate the 483