From i* Requirements Models to Conceptual Models of a Model Driven Development Process

Abstract

Abstract.A good understanding of the systems requirements has a high impact in the successful development of software products. Therefore, an appropriate requirements model must provide a comprehensive structure for what must be elicited, evaluated, specified, consolidated, and modified, instead of just providing facilities for software specifications. Since there is a well-known gap between requirements specifications and final software products, we propose the integration of Goal-Oriented Requirements Engineering (GORE) and ModelDriven Development (MDD) to solve this gap. The core of our proposal is comprised by a set of guidelines to automate the process of going from an initial i* model to a final software product by means of a precise model transformation process. Finally, we use a case study that is based on a photographic agency system in order to illustrate our approach.

Reusing enterprise models to build platform independent computer models

“…Other works based on i* are (Alfonso et al, 2010), (Luna et al, 2010) and (Alencar et al, 2009). The first two explain explain CIM to PIM transformations in the context of a web application.…”

“…Moreover, in (Luna et al, 2010) an automatic evaluation of i* models is included so as to be able to know the level of satisfaction of the goals described in them. On the other hand, (Alencar et al, 2009) explains the transformation guidelines to automatically obtain OO-Method approach models (Pastor & Molina, 2007) from i* models. It establishes a total of eight guidelines that allow the modellers to reuse the knowledge depicted in i* diagrams.…”

“…The processes to be automated at the PIM level are obtained from tasks at the CIM level and actors in the i* diagrams are transformed into classes at the PIM level if it is necessary to maintain information about them. Regarding this guideline, from the information we found in (Alencar et al, 2009), it is not clear if there exists an automatic way to distinguish actors to be transformed and actors that do not need to be transformed. Moreover, attributes of classes are obtained from the resources associated to an actor at the CIM level if these resources express information about the actor but, again, it is not clear if it is possible to know whether a resource has this characteristic automatically.…”

“…This also means that a procedure should not be allowed to relate to a process and a service at the same time. The representation of the 'Relations Metamodel', however, does not allow this fact to be expressed graphically and to do so it would have to be specified by means of a constraint expressed in a language like Object Constraint Language (OCL), which is not currently envisaged in this research (Alencar et al, 2009). …”

Towards interoperability of i* models using iStarML

“…On the boundary, i.e. on the transformation of i* and Tropos models to object-oriented modelling, different approaches have been already proposed [66]. If we try some automatization approach of these transformation proposals, for sure that iStarML would be a relevant option as Platform Independent Language (PIM).…”