Jgoose: a Requirements Engineering Tool to Integrate I* Organizational Modeling with Use Cases in Uml Jgoose: Una Herramienta De Ingeniería De Requisitos Para La Integración Del Modelado Organizacional I* Con El Modelado De Casos De Uso En Uml

Nowadays Computational Systems are being characterized by their complexity, dynamism and great strategic importance. In this complex context of software specification, generating high quality documentation is very difficult. Usually, clients are not sure about their needs and sometimes software requirements do not represent clients and organizational environment needs. Inconsistent and incomplete requirements are very frequent. One of the challenges to solve this problem is to integrate organizational and functional requirements of the system to be developed. In this paper the JGOOSE (Java Goal into Object Oriented Standard Extension) tool used to assist requirement engineers in the development of use cases from the organizational models represented by i* technique is presented. To validate the tool, it was used and applied to the Conference Management System case study.


INTRODUCTION
The detection of most software project problems takes place on the initial steps of modeling software systems.These initial steps are called requirements engineering process (RE) and the main activities of this process can be defined as elicitation, analysis, negotiation, specification, management and requirement validation [23].
Understanding the necessity and meeting customers goals have always been one of the biggest challenges of Software Engineering.Requirement Engineering focus Ingeniare.Revista chilena de ingeniería, vol.17 Nº 1, 2009 on proposing methods, techniques and tools that help comprehension and requirement registration process that the software must accommodate.Different from other software engineering sub-areas, the requirements area must deal with the knowledge involving interdisciplinary, social science and cognitive science aspects [13].
The main reason for failures in the RE is the lack of an adequate organization understanding by software systems developers, also caused by the frequency that organizational changes occur, and the changes which can not be accommodated by existing software systems [1].During the requirements analysis phase, analysts with the stakeholders help, need to identify the organizational goals and the functional and non-functional requirements associated with the computer system being developed.Consequently, requirements engineer should examine and model the stakeholders' interests, and how they should be seen or negotiated, by various alternative organizational systems structures and environments.However, the production of quality specifications is relatively difficult.
In this context, it is important to highlight Eric Yu's propose [25], which expresses the importance of separating the early and late requirement elicitation phases.Early requirement phase activities are typically informal, and usually describe functional, organizational and nonfunctional requirements.This phase emphasizes the understanding of motivations and reasons that support system requirements.Late requirement phase activities are usually focused on the completeness, consistency and automated verification of requirements.
Framework i*, proposed by Yu [25] allows intention, relationship and motivation modeling among organizational members.From these models you can have a better understand of organizational environment functioning, human and work relations among the organization participants.With this information, the computational requirements solution for the organizational processes can be better elicited and specified.
However, actually the most used methodologies to developed computational systems are object oriented methodologies.Object oriented software have been developed using UML (Unified Modeling Language) [5] which is a broad format and well defined to modeling systems for oriented objects development, providing viewing patterns mechanisms, specification, development and software systems documentation.
On the other hand, most modern computational systems have been developed by using object oriented methodology.Object oriented software have typically been developed by using UML, which is a broad, well defined modeling system for object oriented developments, supplying viewing, specification, and construction mechanism patterns, and software system documentation.
The UML generally employs use cases to describe in a clearly and consistently way what the system should do through interactions between users and software systems.Use Cases are responsible for the decision and description of system functional requirements.However, the success of the software project depends primarily on a good understanding of the company`s organization environment and its processes in terms of objectives, business rules, tasks, resources and the relationships among its actors.In the context of requirements engineering, these aspects can be translated as the system organizational requirements or initial requirements (early requirements), and the Unified Modeling Language does not have adequate mechanisms for modeling these aspects.
In many studies [1,6,8,[19][20][21] the authors argue that UML support only the capture phase of final requirements.Even using mechanisms like business use cases, previous studies state that UML can not show how the system reaches its desired organizational goals, the motivations to develop the system, which alternatives are considered and alternative consequences to the stakeholders.Therefore, we concluded that we must use another technique like i* to represent such aspects, which focus is to describe not only the organizational relationships between the various organizational actors, but also the understanding of the reasons involved in the decision process.
Thus this paper proposes integration between i* framework and the object oriented modeling using the UML modeling language.This integration process is based on many researches, among them [1].These researches not only support this integration, but propose guidelines for the use of mapping technology to integrate i* and UML use cases [20 -21] or UML class diagrams [8,[18][19].Moreover, some of these papers propose integration in a semi-automated way through the implementation of tools [2,18] that make this process easier.This paper briefly presents mapping guidelines proposed in [19][20], which allow deriving UML use cases from the organizational models developed with i* framework.In addition, it's described a software tool called JGOOSE (Java Goal into Object Oriented Standard Extension) which was developed in this research to provide semi-8 Ingeniare.Revista chilena de ingeniería, vol.17 Nº 1, 2009 automatic support of these guidelines.To validate the software tool, a Conference Management System Case Study is presented.
The paper is organized as follow: in the section "EARLY REQUIREMENTS CAPTURE USING I* TECHNIQUE", the use of i* framework to capture the early system requirements is described.In the next section, an overview of the proposed mapping of use cases from i* organizational models is presented, together with guidelines that propitiate this mapping.In "JGOOSE TOOL" describes the tool developed to support this mapping and then, a case study using the tool is presented.Finally, the final paper considerations and future effort are made.

EARLY REQUIREMENTS CAPTURE USING I* TECHNIQUE
The i* framework was developed to support the analysis process and conceptual modeling, under a strategic (motivations and reasons) and intentional vision of processes that involve many participants called Actors.These Actors depend on one another to reach objectives/goals, execute tasks and provide resources.Different from other modeling techniques, which typically describe a process in terms of activity and flow stages between entities, i* technique is distinguished for being concerned on the reasons or motivations that are associates to the behavior aspects of the process.In general, traditional modeling techniques allow the description of component system (actors) in terms of its state, capacity (processes that can execute) and behavior (how and when the processes are executed), but they can not express the reasons involved in the processes (the motivation).
Further than assisting the requirement engineering process in its initial specification phase, the i* technique can be applied in other areas [25] such as, business re-engineering process, analysis of organizational impacts, software processes modeling, and also for the development of agent-oriented systems [7,21].This model was introduced in [27], and it was modeled through the Tropos framework in [22].The models SD and SR on figure 1 and 2, respectively, represent the external dependencies between the organizational actors, as well as the internal strategic reasons of these actors, in relation to the involved processes in a conference management that will use a software called Conference Management System to administer the article submission process and publication of proceeding events.Figures 1 and 2 present a correspondent number for easier reference to these elements throughout the text.
Ingeniare.Revista chilena de ingeniería, vol.17 Nº 1, 2009 Several scientific events (conferences, congresses, symposiums, meeting…) frequently congregate researchers and practitioner communities of the area, having as main focus the spreading of work results that involve topics related to the event, offering activities as lectures, tutorials, mini-courses and presentation of techno-scientific articles.Generally, each activity is supervised by a specialized program committee who is responsible for the critical selection of work to be presented.In this manner, we consider this conference management application domain.
Ingeniare.Revista chilena de ingeniería, vol.17 Nº 1, 2009 In figure 1 it can be observed that a conference involves many individuals.During the submission phase, Authors (Author (5) actor) submit papers are informed if their articles were received and a submission identification number (13) is issued by the system.In the revision phase, the committee (Chair (3) actor) must deliver to the article revision contacting potential reviewer (Reviewer (2) actor) and asking them to revise a number of articles according to their expertise.Eventually, revisions are requested and generally they decide on the acceptance or rejection of the submissions.In the final phase, the Authors (Author (5) actor) need to be notified of the decisions and, in case of acceptance of the article, production and submission of the revised version of their articles will be requested.The publisher (Publisher (4) actor) must collect the final versions and print the event proceedings.
In spite of supplying tips on why the processes are structuralized in a certain way, the Strategic Dependency Model (SD) (illustrated in figure 1) does not support enough elements to suggest, explore and evaluate alternative solutions.As the analysis process continues, additional responsibilities for the Conference Management System are discovered.These responsibilities will be represented in Strategic Rationale Model (SR) illustrated in figure 2.
The Strategic Rationale Model (SR) of figure 2 expands the actor who represents the Conference Management System (1) delegating some tasks to it on which External actors to the system depend on these tasks.These tasks are summarized as follow: • Manage Submission Phase (7.1): that is divided in:

DERIVING UML USE CASES FROM EARLY REQUIREMENTS
The mapping guidelines proposed by Santander [19,20] have as objective to associate i* models (SD and SR Diagrams) for UML Use Case diagrams.The initial stage of this integration process is the development of SD and SR models of the system that illustrate the early requirements of a computational system.
In general, the mapping process occurs from SD and SR organizational models, which initiates the integration and discovery process of the use cases for one target system of the organization.In the first moment (step 1), the actors for the UML Use Case diagrams are discovered and later, the use cases are discovered for these actors (step 2), as well as the main and alternative flows (primary and secondary scenes) of the discovered use cases (step 3).
The input in this integration process is the Strategic Dependency (SD) Model for steps 1 and 2. Through SD Model it can be detected which i* actors in has a dependence relation with the System, as well as detecting which elements (goal, tasks, soft-goals and resources) lik these actors to the system.The main and alternative flows descriptions of use cases (step 3) are derived from the Strategic Rationale Model (SR).These flows derived from the internal links of the computational system, which can be divided in decomposition links and means-end links.
The used guidelines to derive use cases from the i* modeling were defined in [19,20] and are summarized as follow: 1º Proposal step: Actor Discovery Guideline 1: all i* actor should be considered as a possible mapping for actor in use case; For example, the Reviewer Actor (2) can be analyzedsee figure 1.
Guideline 2: initially, we must analyze if the i* actor is external to the intended computational system.In case that the actor is external to the system, the actor is considered candidate actor in Use Cases; For example, the Reviewer actor (2) -figure 1 For example, ISA relationship between Author (5) and Accepted Author (6) in figure 1, can be mapped for a generalization relationship between these actors in the Use Cases diagram (see figure 8).
After all the actors have been discovered their respective Use Cases can be found.

2º Proposal step: Use Cases Discovery
Guideline 5: for each discovered actor in step 1, we should observe all dependences (dependum) of the actor view point as dependee in relation to the actor that represents the intended computational system (computational system → dependum → actor), aiming to discover use cases for the analyzed actor; Sub-Guideline 5.1: to evaluate goal dependenceseach such dependence must directly be mapped for actor use case.
For example, in figure 1 Sub-Guideline 5.3: to evaluate resource dependences -each such dependence must directly be mapped for actor use case.Sub-Guideline 5.4: all the soft-goals dependences are not mapped -normally this dependence type is associated in the organizational modeling to a non-functional requirement associated with the computational system.Thus, this dependence type is mapped for a non-functional requirement of the intended system.These requirements can be visualized in step 3 of the tool (figure 6) through the button "Show NFRS".
In the example of the figure 1 we don't have a task or resource relationship and so, the sub-guidelines 5.2 and 5.3 can not be applied due to the non existence of a relation type "computational system → task/resource → actor".
Guideline 6: analyze special situations, where an actor discovered (following the step 1), has dependencies (as depender) in relation to an i* actor that represents intended computational system or part of it.(actor → dependum → computational system).These dependencies, according to [18], usually generate Use Cases, due to the fact that the dependee is a software system and the depender (Use Case actor) must interact with the system to achieve the goal associated with the generated Use Case.
For example, in figure 1, the dependence Submission Number (13) between Author (5) (depender) and Conference Management System (1) (Dependee) can be mapped for a Use Case Submission Number.
Guideline 7: classify each Use Case according to the type associated to its goal (contextual goal, user goal, subfunction goal).This guideline is based on the classification proposal by Cockburn [8].
• A business goal represents an high-level intention related to business processes, that the organization or users have in the organizational environment context.• A summary goal represents an alternative to the satisfaction of the business goal.• An user goal results in the direct discovery of an excellent and valid functionality for the actor organization using the software system.• Finally, sub-function level goals are necessary to reach objective of user.
To support requirements engineers to identify new Use Cases and to have a better understand of the same ones, it is recommended to generate a table that contains the actor, its Use Case and the corresponding guideline (see table 1).A Guideline 9 is not supported by the current version of JGOOSE tool.However, it will be implemented in posterior versions of the tool, using an interaction mechanism with the requirements engineer who makes possible the generation of new Use Cases.
Guideline 10: To develop the use case diagram using the discovered use cases, as well as observing the relationships of the < < include> >, < < extend> > and < < generalization> > used to structure the use cases specifications.
The presented guidelines represent a systematic means to derive use cases from organizational models in i*.
However, the analysis effort can significantly be reduced with the support of a computational tool.Therefore, aiming to provide a semi-automated support for these guidelines JGOOSE tool was developed and it is described in the next section.
The mapping process described in the previous section was executed in JGOOSE tool from diagrams i* created by the OpenOME tool (Open Organizational Modeling Environment) [16] or OME3 [14] to UML use cases and they are showed in the tool.The main change in the JGOOSE tool comparing with its previous version (GOOSE) [3] is the new adopted systematic implementation that makes it more flexible to integrate with other tools, and significantly improves its usability.Previously the tool built the use cases diagram through the extension Rose Extensibility Interface, an interface that allows customization of menus, creating scripts to automate tasks and access to elements of the Rational Rose tool.However, the GOOSE development made the application dependent on the Rational Rose proprietary tool.
In JGOOSE tool, the diagram and its textual description are displayed in the tool (figure 6) and it is also stored in Java classes, where, through new versions of JGOOSE tools, there is a possibility to translate into specific UML CASE tool format or the XMI standard (XML Metadata Interchange) [26].The XMI standard use proposed by the OMG [15] has become a widespread standard for data exchange between CASE tools, making information exchange easier between different tools through a standard flexible format that can be easily decipherable to the information.

JGOOSE tool progress regarding its previous version (GOOSE) is listed bellow:
1) New guidelines • Development of sub guideline 5.4 that concerns about softgoals that are mapped as a possible non-functional requirement (NFRs) related to the system.• Development of guideline 8.1 that concerns about softgoals that are part of tasks decomposition and are mapped as special requirements in the Use Case description.
2) New features: new features were designed for a clearer i*>> UML Use Case mapping process with JGOOSE.For example, the information of all elements in one i* TELOS file which would be mapped to Actors and Use Cases with its descriptions.
3) TELOS File: support for open files generated by OME3 and OpenOME Tool.

4) Tool Development using Object Oriented of Java
Language.The i* objects and mapped Actors, Use Cases and relationships between then are generated with Java Classes that represents these objects in a consistent way.

JGOOSE tool use
The internal structure tool (represented by the figure 3) is basically: (1) Specific tokens capture in a TELOS file generated by the OpenOME or OME3 tool.This information describes the objects in the i* SD / SR diagram, their elements (actors, goals, tasks, soft-goals and resources) and its links (dependency, task decomposition and mean-end links) and all the attributes that characterize these objects.
(2) Store the Diagram SD / SR using data structure: Define a data structure that stores SD / SR diagram information.
(3) Map the SD/SR Structure to a data structure that represents UML Use Cases: guidelines proposed by Santander will be used [20] (guidelines 7 and 9 weren't developed).
(4) Translate the Use Cases Structure to the XMI standard (XML Metadata Interchange): feature aimed to generate an tool output format that can be open by some UML CASE tools.This feature will be coded in future versions of the tool.
Ingeniare.Revista chilena de ingeniería, vol.17 Nº 1, 2009 The necessary steps to map a model SD / SR stored in a TELOS file (*.tel) to an Use Cases diagram using the JGOOSE Tool are described bellow with the tool screenshots that illustrate its operation (figures 4, 5 and 6): • STEP 1 -Information capture of TELOS file: The user must open a TELOS file that stores a SD/SR diagram.This command can be executed through the "Open TELOS File" button (Abrir Arquivo TELOS) or in the "Arquivo » Open TELOS File" file menu.After this step, the i* actors are showed and the user must choose one actor who will represent the Computer System.Moreover this first screen shows all Actors, Elements and mapped Links of Telos file.
• STEP 2 -Guidelines Selection: The guidelines D.1 -D.4 will always be default selected.The guidelines D.8 -D.8.3 (see section 3) may be selected only if the model selected by step 1 is a SR model, only this model provides information to find the events flow for a Use Case.In this step, the user can also read a brief tutorial about the mapping guidelines (figure 5).
• STEP 3 -Mapped Actors, Use Cases and descriptions: Finally on the 3rd and final stage shows mapped Actors, IS-A Actors, Use Cases, and their descriptions as well as Non-Functional Requirements (NFRs), and the guidelines that was used to map such elements.This information is displayed in the user interface (figure 6).
The following section presents the case study Conference Management System described in figures 1 and 2. This case study was aided by JGOOSE tool.

CASE STUDY
The mapping process of SD and SR models described in figures 1 and 2 to UML Use Cases occurs semi-automatically using the JGOOSE tool and this process derives Actors, Use Cases and your descriptions.This mapping process is described below: Step -Mapping Actors Finally the table 2 shows mapped and not mapped Actors and their respective guidelines.13) are connected with the system through the already mapped actor Author (5).Hence, they are mapped to Use Cases using the guideline 6. • Accepted Author: The actor has no element connected to the system.However it inherits all the actor's use cases already mapped by Author (5).
Table 3 summarizes the step 2, showing the dependencies mapped to use cases and their respective actors.A first draft of the main scenario, according to the template proposed by [9] is generated for each use case.
The description for the Use Case Review Phase Managed Autonomously can be seen in figure 7. Although, the main scenario generated should be properly examined and rewritten and rearranged by the requirements engineer.

CONCLUSION AND FUTURE WORKS
In this paper, it was argued that use cases development can be improved with the use of i* technique.In [6] the authors describe some of the benefits of use cases development from the i* technique.The integrated use of organizational modeling i* and UML Use Cases modeling provide a consistent link between computer systems allowing better assessment of the dynamics in business processes and organizational environments.
Initially, this paper presented guidelines that allow the use of i* organizational models in the scenarios development in Use Cases form.Afterwards, the JGOOSE tool is presented with its operation, which provides support in the semi-automatic use of the guidelines.The guidelines and the tool were applied to a Conference Management System case study, getting the system UML Use Cases.From the case study was possible to see that information in both, existing strategic dependency and strategic rationale model, serve as a basis for the development a Use Case diagram that meets the customers / users goals.In this context, we should emphasize the support offered by the JGOOSE semi-automated tool which minimizes the requirements engineers' effort in Use Cases mapping when applying the proposed guidelines.Additionally, to help this mapping process, the JGOOSE tool supports some usability, flexibility and portability requirements which are fundamental aspects in a computational tool design.
Some related work are cited below: Pedroza's [17] and Alencar's [18] proposal which aims to derive classes diagram from i* models; Rosa`s and Santander`s [29,31], which works with the requirement elicitations for legacy software proposing mapping the DFDs (Data Flow Diagrams) to i* models; and Estrada's work [11] that suggests organizational and functional goals derived from business models.Moreover, Silva's [22] work related to Tropos Project [24] proposes a mapping from i* technique to a architecture level of Multi-Agent Systems.
In the automation mapping process aspect, we have some tools available, such as GOOD (Goals into Object Oriented Development) [8] and its improved version XGOOD (eXtended Goal Into Object Oriented Development) [18], that map i* objects to UML Classes Diagram, and the GOOSE tool (Goal Into Object Oriented Standard Extension) [3], the JGOOSE previous version tool, which maps i* objects to UML Use Cases diagram.
Nowadays we are investigating the possibility of the integrate the present proposal to the OOMethod [32].OOMethod is a methodological approach with tools to support automatic code generation from OO conceptual models.We believe that our proposal can help to generate OO conceptual models from i* models in a better systematic way.
In future endeavor we will address the following aspects: • Mapping process Improvement, as well as JGOOSE tool interface; • use the tool in other case studies, mainly studying the tool behaviour in more complex diagrams SD/SR; • Improving the tool, enabling the UML Use Cases mapping saved in XMI standard [4] which are compatible with a larger number of UML CASE tools; • Adequately treat non-functional requirements using NFR Framework proposed in [28].

Figure 3 .
Figure 3. Internal structure of JGOOSE tool for mapping i * -UML Use Cases.

Figure 6 .
Figure 6.Step 3 -Actors, Use Cases and mapped Scenarios for the Conference Management System.

Figure 1
Figure 1 represents the Strategic Dependency model (SD) of the Conference Management System.It displays numbers corresponding to some of the elements in order to facilitate the reference in the text.

3 8 )
rd Step -Building Use Cases Description (Scenarios) Finally, based on the guideline 8.1 of 3 rd step of guidelines, the JGOOSE tool generates the steps of use cases: Submission Phase Managed Autonomously (7), Review Phase Managed Autonomously (Proposal for Review Evaluated Autonomously (9), observing the decompositions in the SR model (figure 2).

Figure 8 .
Figure 8. Use Case Diagram -Conference Management System.

Evaluate Propose for review (9.1) that
the Strategic Dependency diagram of the figure 1 and Strategic Rationale diagram represented by figure 2, which expands the actor who represents Conference Management System.
1. Collect Submission Paper 2. Assign Submission Number • is decomposed in five sub-tasks: 1. Set Personal Profile 2. Evaluate Interest in Subject Paper 3. Evaluate Time Availability 4. Evaluate Relevance of Conference 5. Collect Papers Review • Manage Review Phase (8.1) that is divided in: 1. Propose Paper Review 2. Select "n" Reviewers of Paper Research Area 3. Assign Paper Reviewer 4. Collect Papers Review The initial version of the Conference Management System supports the submission, revision and notification phases of the conference management process.There is a version modeled which improves this initial version, decomposing the Conference Management System in four functions for the agents: Submission Supervisor, Revision Supervisor, Notification and Copyholder Supervisor.However, for our Case Study it was used only the early requirementsFigure 2. Strategic Rationale Model-Conference Management System -Early Architecture Release (Adapted from [2]).Ingeniare.Revista chilena de ingeniería, vol.17Nº 1, 2009modeling represented from -is external to the Conference Management System (1) and can be a candidate for a Use Cases actor.The Publisher actor (4) has dependence relation only with the Chair actor (3), thus this actor is not considered a candidate Actor for a Use Case.Guideline 3: if the actor is external to the system, it should be guaranteed that the actor in i* is a candidate actor in the Use Case diagram.For this purpose, the following analysis is necessary: Guideline 4: i* actors in i*, related through IS-A mechanism in the organizational models and individually mapped for use case actors in use (applying guidelines 1, 2 and 3), will be related in the use cases diagram through the <<generalization>> relationship.

Table 1 .
Mapped Use Cases Example -Conference Management System.
Sub-Guideline 8.1: to analyze the sub-components in a task decomposition linking in a possible mapping for steps in the primary scenario description (main flow) of use cases.Sub-Guideline 8.2: to analyze means-end links type in a possible mapping for alternative steps in the use cases description.Sub-Guideline 8.3: to analyze the relationships of sub-components dependences in the Strategic Rationale model in relation to other actors of the system.These dependences can originate pre-conditions and pos-conditions for the discovered use cases.Guideline 9: To investigate the possibility to derive new use cases goals from the steps observations in the scenarios (events flows) of the discovered use cases.Each step of a use case must be analyzed to verify the possibility of being refined in a new use case.Ingeniare.Revista chilena de ingeniería, vol.17Nº 1, 2009

Table 2 .
Mapped Actors -Conference Management System.

Table 3 .
System and the main scenario steps for the Submission Phase Managed Autonomously, Proposal for Review Evaluated Autonomously and Review Phase Managed Autonomously use cases.Figure 8 illustrates the UML Use Case diagram for the Conference Management System, which you can view the actors Author, Accepted Author linked to actor Author by a generalization link, Reviewer, Chair and their Use Cases.Use Cases Mapped -Conference Management System.
Thus, after following mapping guidelines, the JGOOSE tool generates the Actor and use cases relationship (showed in figure6) mapped to the Conference Management Figure 7. Use Case Specification -Review Phase Managed Autonomously.