Altought widely used and recognized in the scienti c community, the i* framework has, until now, failed to impose itself into enterprise practices. There are many ways that can be followed to favor industry-adoption. Among them, we believe that an integration into the (Rational) Uni ed Process, which already includes business modeling as a preliminary step in software development and furnishes custom syntax and semantic to do so could be an interesting approach. This paper summarizes the ideas of a research aimed at mapping i* model elements and RUP/UML business modeling ones with the best possible semantic match. The willingness is to provide RUP practitioners a powerful tool for capturing and analyzing social and organizational contexts of software systems based on the syntax they already know with as closely as possible related semantics.
The practice of modeling the processes of an organization at the inception of {
or continuously during { a software project has been adopted in many methods.
Indeed, within a new information system development, being aware of the
situation as-is is a fundamental prerequisite to de ne/align the system to-be. For
such purpose, i* (i-star, [
Yves Wautelet and Manuel Kolp would be to integrate i* bene ts relying on RUP/UML business use-case syntax and semantics. This could ease the integration of i* in RUP even if the exact form it would take remains an open issue (see Section 5).
UML Pro le for i* Modeling
The research method applied to achieve our objectives rstly consisted in
distinguishing groups of elements both within the ones de ned by i* and the
RUP/UML business use-case model. Elements considered here are the ones
dened in the business modeling discipline of the RUP knowledge base [
As presented in Table 1, three groups of elements have been distinguished within the i* ones: Dependum Elements (DE ), Actor Elements (AE ) and Links (iStarLink ). Similarly, as presented in Table 2, three groups of elements have been distinguished within the RUP/UML business use-case model: Inheriting from Use Case (IUC ), Inheriting from the Actor (IA) and Links (UMLLink ). The groups have been made on the basis of the elements nature to ease the semantical mapping process.
In order to compare i* elements and nd best matches with UML ones, we have rstly compared the DE set with the IUC one, such as DE IU C. We indeed proceed through a carthesian product in order to compare the semantics of each pairs of elements issued of groups from the two modeling languages. However, no satisfying match was found for the Softgoal element so that we have further compared this element with the set IA. After having found the best possible matches for each element of the DE set, we have proceeded to a comparison of AE with IA, such as AE IA. However, no satisfying match was found for the Actor Boundary so that we further compared this element with the IA set. Finally, when this was achieved and the best possible match was found for each element in the set IA, we have compared the iStarLink set with UMLLink like iStarLink U M LLink. (Hard)goal: In a goal dependency, the depender depends on the dependee to bring about a certain state of a airs in the world. Inheriting from Use Case Inheriting from the Links (UMLLink ) (IUC ) Actor (IA) Use Case Actor Business Use Case (BUC) Boundary BUC Realization Business Actor Use Case Realization Business Entity
Business Event Business Goal Business Worker Control Domain Entity Interface Table
View Table 2. Target UML Elements
Unidirectional Association Dependency or Instanciates Generalization Association Aggregation Include Realize Re ne Extend Derive Package Chosen Element: Business Use Case.
Rationale: Following the RUP knowledge base, a Business Use Case (class) de nes a set of business use-case instances in which each instance is a sequence of actions that a business performs that yields an observable result of value to a particular business actor. The Business Use Case (BUC ) element has been chosen because it is located at business (i.e., organizational) level such as the i* goal and yields an observable result of value.
Task: In a task dependency, the depender depends on the dependee to carry out an activity. The dependum names a task which speci es how the task is to be performed, but not why. The depender has already made decisions about how the task is to be performed.
Chosen Element: Business Use Case Realization.
Rationale: Following the RUP knowledge base, a Business Use-Case Realization describes how business workers, business entities, and business events collaborate to perform a particular business use case. This corresponds to the purpose of the i* Task and is in line with the choice made for the (hard)goal element since we have selected the BUC at that stage.
Softgoal: In a softgoal dependency, a depender depends on the dependee to perform some task that meets a softgoal. A softgoal is similar to a goal except that the criteria of success are not sharply de ned a priori. The meaning of the softgoal is elaborated in terms of the methods that are chosen in the course of pursuing the goal.
Chosen Element: Business Goal.
Rationale: Following the RUP knowledge base, a Business Goal is a requirement that must be satis ed by the business. Business Goals describe the desired value of a particular measure at some future point in time and can therefore 4
Yves Wautelet and Manuel Kolp be used to plan and manage the activities of the business. This de nition best corresponds to the purpose of the Softgoal.
Actor Boundary: Actor boundaries indicate intentional boundaries of a particular actor.
Chosen Element: Package.
Rationale: Following the RUP knowledge base, a general purpose mechanism for organizing elements into groups. Packages may be nested within other packages. Organizing elements into groups is precisely what we intend to do so we have selected this element for this purpose.
The UML Pro le for i* Modeling. The result of our study is summarized
in Table 3. The graphical notation is documented in [
i* element This section highlights a number of open issues about the proposed mappings and justi es some choices made/compromises taken in a more global manner.
A functional goal is mapped to a business use-case; the rationale is based only on part of the de nition of the latter element. One could argue that the de nition also emphasizes that each instance of it is a \sequence of actions that a business performs", which, based on the corresponding i* de nition, matches better with the notion of task. Nevertheless, a use-case realization is something even more concrete, so it makes sense to map tasks into something more detailed and tangible than in what goals are mapped. Still, a goal by itself does not have any notion of a sequence of actions in it. Therefore, while the mapping is aligned to part of the de nition, the compromise partly induces a semantic mismatch.
While the de nition of a business goal as a desired value of a particular measure points to being a non-functional objective, the existence of such a desired value makes the goal objective and binary. Softgoals are subjective and can be achieved to some acceptable degree; a semantic distance is thus present.
When mapping an actor boundary to a package, an important semantic aspect of the model is potentially lost. An actor boundary is indeed not only a grouping of model elements. Goal re nement and analysis within that boundary is done from the point of view of the respective actor. Packages can only capture these semantics if additional constraints are included.
The two notations are consequently rather di erent and preserving semantics
within such a mapping is a challenge. The form of integration is consequently
of primary importance to higher the chances of adoption. If the purpose was to
translate a particular model from i* to the RUP/UML business use-case model
(or vice-versa), then some knowledge would typically be lost from the original
model and other, new, knowledge would be required to be de ned (manually) in
the target model. This way both models could bene t since traceability between
both analysis models is maintained. Also, additional advantage could come from
the representation of the same problem using di erent modeling perspective. In
[
The rst step in the research aiming to integrate i* within the RUP has been
to study whether the RUP business use-case model provides elements that can
be used as syntax with a semantic understanding that is compliant with the one
associated to the i* ones. We have been able to nd answers for each of them
even if most often it was a matter of best possible compromise. Modeling in an
i* fashion with the RUP/UML business use-case model syntax and semantics is
thus possible; the graphical notation and an illustrative example are provided
in [
In addition to the results presented so far, we highlight the fact that, over the years, i* modeling has been applied in collaboration with our research team in the context of multiple real-life industrial case studies to describe the situation \as-is". We notably refer to the development of a production management system
Yves Wautelet and Manuel Kolp for a coking plant (2002-2007) and the development of a collaborative platform for outbound logistics actors (2008-2010). Some of these projects followed the RUP but i* modeling activities were applied \in parellel" rather than integrated into the uni ed development methodology. Also, i* was then applied with its traditional notation using custom CASE-tools. These cases can be used as basic material to study the alignment of i* models with business use-case ones.
Since our purpose is to integrate the i* approach (and thus its bene ts) within a RUP/UML context we have to formally study the complementarity/overlap between the models to evaluate the best integration option. Should we leave the business use case model into the RUP as a complementary/alternative view to i* models or should we use the i* model with the business use case model syntax only? This can thus be the subject of an empirical evaluation through an ex-post analysis of the cases at disposal.
Next to this, if we want to favor industry adoption, we need to study sets of questions related to the practical adoption of i* by RUP practitioners. More precisely, we distinguish the following research questions: { To what extend are industry practitioners able to use the RUP syntax and associated semantic in an i* context? { To what extend do industry practitioners perceive the bene ts of i* modeling? { To what extend are industry practitioners willing to change their habits to integrate i* modeling?
The authors would like to thank the anonymous reviewers for their valuable comments and suggestions to improve the quality of the paper.