In this paper we present some of the lessons learnt when using i* and Tropos in the SCORE 2009 competition (Student Contest on Software Engineering Contest). During the development of the BTW-UFPE Project we had to address several challenges, including: limitations of modeling notation, ensuring the quality of the intentional models, transition from requirements to architecture description as well as from architecture description to detailed design. Moreover, we identified the need to deal with intentional and domain variability in i* models and the lack of appropriate tool support. In this paper we also present some of the ongoing research which is aimed at addressing some of the identified challenges.
In the years of 2008 and 2009, we fully developed a multi-agent system which was a finalist of the Student Contest on Software Engineering -SCORE 2009 [18]. We chose the "BTW -If you go, my advice to you" project, which is related to the development of an information recommender system intended to help travelers when walking around streets unknown to them [11]. We adopted an agent oriented approach, based on the best practices of Tropos [21], to deliver our project. Agents are a natural choice when it comes to advice suggestion [24]. In the sequel we report on some of the lessons learnt and present various challenges for the technology adoption:
i) Requirements Elicitation -Our project relied on the PRiM process [7] for the elicitation phase. It was very useful for identifying actors, tasks and resources. However, it was of limited assistance for the discovery of goals and softgoals. An interesting possibility would be to use an approach based on Ground and Activity Theory [5] for finding (soft) goals. Unfortunately, due to time limitation we could not pursue this option.
ii) Different versions of the modeling language and tool support-There are different versions of the requirements language. For example there is the original i* [22] and the i* wiki version. Besides, different dialects have been proposed by the research groups, such as Tropos [4] and GRL [2]. In particular, in our group we have developed extensions to deal with variability and cardinality of elements [3]. We also developed two approaches to improve the modularity of the requirements models [9,17]. This large collection of i* dialects leads to uncertainty when learning and selecting the most appropriate version for the job at hand. Moreover, the lack of standardization also constrains the usage of modeling tools, since most of them are designed for a specific version of the notation. It is urgently required a family of tools to support the various goal modeling language variants. For the Score contest we modeled requirements according to the U-Tropos process [21] and used the OME tool.
iii) Quality of models -Once we have built a model, we need to assess its quality with respect to some criteria. Several metrics have been defined for the i* language [16,6]. However, we also need an approach to relate the criteria of interest (quality attributes) to the questions to be answered and metrics to be collected. Moreover, the evaluation phase should also be linked to an improvement stage, where the potential problems detected could be addressed [14]. In our project we had to rely on the team members' expertise to assess the quality of the models. iv) Transition from requirements to architecture models -A key challenge is to relate requirements and architectural models. Although some approaches have been proposed in the literature [9], the available tool support is very limited. In our project we did not use any systematic means for the derivation of the architectural model. Hence, it was difficult to assess if the derived architecture fulfilled (all) the requirements. Furthermore, the rationale for the choice of a candidate architecture (based on non-functional requirements or softgoals) was not recorded. This is especially critical on iterative projects. v) Transition from architecture models to detailed design -Once the architectural model is stable, a detailed design has to be delivered. This is a daring task. Little assistance is currently provided. We relied on some UML artifacts to describe the design information. The members experience was a key factor for this task. A more systematic approach is urgently required.
vi) Transition from detailed design to source code -In the context of objectoriented development there are plenty of tools to generate a draft source code from design models. We predict that a draft source code could also be automatically generated from an architectural and detailed design models. For the contest our team had to generate the target code manually. vii) Reuse of Multi Agent Systems -A lot of effort is necessary to develop a single multi-agent system (MAS), i.e. the BTW in our SCORE competition. If a similar or related MAS is required, often none of the previous artifacts are reused. Hence, it is paramount to promote software reuse in the context of multi-agent development. One of the key issues is to be able to express the common and variable parts of the artifacts. For example, there are recent works representing variability in i* models [1,3,8]. However, it is not clear yet how this variability information can be used to develop an Agent-based Product Line (APL).
Our research group is addressing some of these issues, namely ii, iii, iv and vii. In the remainder of this paper we are going to describe our current research lines related to tool support and promotion of reuse. Some of the other issues are partially handled in other works [9,14,17]. In Section 2, we describe our research objectives. In Section 3, some contributions and published works will be discussed. In Section 4 we present some conclusions. The last section points out some ongoing and future works.
Regarding the issues describe in the earlier section, in this paper we describe our research towards the following directions:
(1) Tool Support: an SPL approach
In the last few years, several extensions of the modeling language based on the i* / Tropos framework have been proposed, due to the specific needs of various research groups, eg. [3,4,17]. However, building a suitable tool support for each one of these extensions leads to a high development cost. In the mean time, the Software Product Line -SPL paradigm [13] has gained significant popularity in the software industry and academia. It promotes software reuse by specifying a family of software products through artifacts capturing their common and variable features. Thus, we aim to use their principles to provide a set products, i.e. specific goal modeling tools, to support different versions of i*/Tropos. Each tool will be configured according to a set of specific features related to chosen modeling language [15].
(2) MAS Reuse: An SPL approach Tropos [4] is considered one of the most complete agent oriented methodologies, since it spans all stages of multi-agent systems development. Since the initial proposal, in 2000, various versions and extensions have been proposed. However, these proposals have adopted different activities and notations, decreasing their adoption by software developers [20]. Our goal is to extend the Tropos process to enable the development of multi-agent systems according to the SPL approach. Hence, we need to add Domain Engineering and Application Engineering phases. Moreover, some form of Feature Modeling and Configuration Knowledge may also be required.
In this section we describe some of the ongoing work of our research group, related to the fulfillment of the research goals presented in Section 2.
(1) Tool Support: an SPL approach Due to the diversity of goal modeling languages based on i*, we needed to identify the common and variable constructors present in the several i*/Tropos extensions/dialects. Our purpose is to develop a product line of tools that can be easily configured to support any of the analyzed extensions. Hence, inspired by the Software Product Line paradigm [13] we are defining Core Assets, as well as Domain Engineering and Application Engineering Phases. Based on common i*/Tropos constructors, we proposed a core metamodel to support the goal modeling variability [10]. Depending on the language we want to use, different constructors could be inserted in the core metamodel, producing a new metamodel for a specific i* extension. As a first result, we developed a version of our i* modeling tool -called iStarTool [15] -which currently supports the original version of i* [22].
(2) MAS Reuse: An SPL approach Initially we considered best practices of the several Tropos approaches. This resulted in U-Tropos: a proposal for an unified process to develop agent oriented software [21].
In the current phase of this work, the SPL technology [13] has been investigated as an alternative to promote reuse in agent oriented systems development. In this context, we examined how goal modeling languages could be used to support product line variability. In particular we tried to relate goal models to feature models [3].
Goal oriented requirements engineering (GORE) can be used to discover variable and common requirements in a software product line (SPL), as well as to reduce costs related to the configuration of a specific product in such product family. Recently, a comparison among some GORE approaches to deal with software variability has pointed out that they have limited expressivity to represent variability in SPL, as presented in [3]. This has motivated us to investigate the use of i* framework as a GORE approach for SPL. The work presented in [19] proposes an extension of the i* modeling language, called i*-c (i* with cardinality), which allows the insertion of cardinality in some of their modeling elements. The G2SPL (Goals to Software Product Line) approach proposes a process to identify and model common and variable requirements in a SPL using i*-c models. This approach also guides the configuration of a specific product in a SPL.
In this section we present future works we plan to perform in order to achieve the goals described in Section 2. We also present some related works.
(1) Tool Support: An SPL approach Also based on SPL concepts [13], we intend to use the core i* metamodel, the extended i* metamodels and their identified variabilities, to create and configure a family of tools to support goal modeling. We expect that this solution will improve the maintainability and extensibility of the current and future tools. The next product will support the i* wiki version. Later aspectual i* [17] will also be incorporated in the product line. We also envisage support for i*-c (i* with cardinality) [3].
(
It is intended to extend the U-Tropos Process to include Domain and Application Engineering, for the development of agent based software using the methods and techniques of SPL. This new version of Tropos will be called Tropos-SPL (Tropos Software Product Line).
(
We are also proposing an approach that combines variability analysis and nonfunctional requirements to drive the configuration of a business process. Applying this approach we can analyze variability in the model in order to assess the impact of the choices on the process quality constraints -the non-functional requirements. Moreover, it provides a rationale for the selection of a specific configuration and could support the variability representation in business process [23].
Lastly, we are using i* models as a basis for identifying situations in which certain failures may be ignored [¡Error! No se encuentra el origen de la referencia.]. This work is being developed in the context of self-configurable systems, in which each failure would lead to a compensation.