Using i* to identify candidate aspects Eva Spies † , Julia Rüger † and Ana Moreira ‡ † Universität Koblenz-Landau, Postfach 201 602, 56016 Koblenz GERMANY ‡ Dept. Informática, FCT, Universidade Nova de Lisboa, 2829-516 Caparica, PORTUGAL {evaspies, jrueger}@uni-koblenz.de, amm@di.fct.unl.pt Abstract Aspect-orientation has been capturing researcher’s attention for the last few years. We have seen the birth of several aspect-oriented programming techniques and also the propagation of the aspect concept to the earlier stages of the software development process, such as requirements analysis and design. Our long-term goal is to extend aspect-orientation to the business modelling activity. This paper discusses our first results by using the i* 1 technique to assist us with the concern elicitation process. 1. Introduction The main idea of separation of concerns is to focus ones attention only on one certain issue at a time. Separation of concerns aims at identifying and modularizing those parts of software that are relevant to a particular concept, goal or purpose. Traditional approaches to software development, such as object-oriented and structured methods, have been created with this principle in mind. However, they are unable to handle broadly scoped requirements and constraints, also known as non- functional requirements. Non-functional requirements are global properties of a system and usually refer to quality of service. Recent approaches achieve separation of concerns by integrating functional and non-functional requirements [Dardenne 1993, Yu 1995a]. Nevertheless, they do not consider the crosscutting nature of some of those concerns. Examples of crosscutting concerns are security, fault tolerance and usability. The main goal of aspect- orientation is to promote modularization by offering mechanisms that permit the encapsulation of crosscutting concerns in separate modules, known as aspects. Aspects make the specifications and the code more general, so that they can be reused in several other cases. Aspect- oriented software development (AOSD) aims at providing means for their systematic identification, separation, representation and composition [Elrad 2001, AOSD]. For the last few years we have seen the appearance of several aspect-oriented requirements analysis and design approaches. Our paper focuses on aspects on the early- requirements activity (as opposed to late-requirements, according to the common requirements engineering classification activities [Mylopoulos 1999]). One of the problems pointed to the Early Aspects (www.early- aspect.net ) approaches (e.g. [Moreira 2002, Rashid 2003, Brito 2004, Baniassad 2004]) is the lack of an elicitation process, since are late-requirements techniques. Our work is a first step towards solving this problem. We based 1 Should be read “eye-star”. ourselves on the early-requirements technique i* [Yu 1995], as a guide to the identification of the main candidate aspects and to integrate the results within the requirements engineering model proposed in [Brito 2004]. The goal is to propose a set of guidelines to help identifying concerns and describe each one using the template proposed in [Brito 2004]. This paper is organized as follows. Section 2 sets the foundation for this paper, by discussing some work on early aspects and giving an overview of i*. So that the main section of this paper, Section 4, can be better understood, we first apply i* to a case study, in Section 3. By doing so the reader can have a better feeling of the main models proposed by i*, from where our guidelines to derive concerns, and ultimately candidate aspects, will be extracted in Section 4. Finally, Section 5 concludes this paper and points directions for further work. 2. Background 2.1 Early aspects There are three main steps in the aspect-oriented software development. First, we need to identify crosscutting concerns, and therefore be able to structure the requirements by decomposing the problem into concerns. Next, we need to represent (specify or implement, depending on the level of abstraction) each concern. Finally, all the concerns, crosscutting and non- crosscutting, need to be composed to obtain the final system. The composition process is also known as weaving. The composition is guided through composition rules. A composition rule defines the way, in which a crosscutting concern affects other concerns. The composition rule can appear inside the crosscutting concern, specifying how other concerns are affected by this crosscutting concern (just like what happens in AspectJ); it can appear inside a non-crosscutting concern, specifying the way crosscutting concerns affect that concern; finally, it can appear in a separated module. Our paper focuses on aspects at the early stage of the software development life cycle. We call them “candidate aspects”, as at this early stage we still do not know if they will be handled as aspects during later stages of the software development process [Rashid 2003]. Our work is based on the results presented in [Brito 2004], in particular a template they propose to define concerns, crosscutting or non-crosscutting. The template is presented in Table 1. Table 1: Template to describe a concern Name The name of the concern. Source Source of information, e.g. stakeholders, documents, domain, catalogues and business process.