Goal-oriented modeling is an efective way for modeling and analyzing the requirements of users. It takes stakeholder's intentions as the main clue and analyzes their goals and tasks to construct hierarchical requirements model. Unified Modeling Language (UML) is a de facto standard for system requirements modeling and design. In practice, it is very desirable to have an approach to automatically transform user requirements into system requirements, then automatically generate system prototypes for requirements validation. In ICSE'19 and RE'19, we propose an approach and CASE tool RM2PT, which can automatically generate prototypes from system requirements in UML. In this paper, we focus on filling the gap between user and system requirements. Specifically, we propose an approach Goal2UCM to automatically generate the use case diagram, the system operations and interfaces of use cases from the goal-oriented model iStar based on the model-driven approach. We evaluate the proposed approach with the case study of CoCoME system. Overall, the result is satisfactory. The 93.6% of the iStar model elements can be transformed successfully, and the remaining parts of sub-goals and sub-tasks can be refined and mapped into UML models manually. The proposed approach with the developed CASE tool can be applied to the software industry for requirements engineering.
Eliciting and specifying the user requirements is the initial step of requirements engineering.
Goal-oriented modeling iStar is a promising way for modeling and analyzing the requirements
of users. It provides software developers and designers with a way to model the characteristics
of system requirements visually and systematically. In practice, it is very desirable to have an
approach to automatically transform user requirements into system requirements, then
automatically generate system prototypes for requirements validation. Requirements modeling and
automatic prototyping (RM2PT) [
Compared with the related works to generate a use case diagram or class diagram from iStar 1.x model, we propose an approach Goal2UCM to automatically generate a use case diagram, the system operations and interface of use cases from iStar 2.0 model based on the modeldriven approach. In addition, we implement a iStar 2.0 modeler and Goal2UCM transformer (https://istar.rm2pt.com) , which are integrated with RM2PT to support further prototype generation for requirements validation. We evaluate the proposed approach with the case study of CoCoME system. Overall, the result is satisfactory. The 93.6% elements of iStar models can be transformed successfully, and the remaining parts of sub-goal and sub-tasks can be refined and mapped into UML models manually. The contributions of this paper are summarized as follows: • We propose an approach Goal2UCM to transform a iStar 2.0 model into a use case model, which includes a use case diagram, the system operations, the message of system operation, and the interface of use cases. • We implement the proposed approach and a iStar 2.0 modeler as the plugins in our CASE tool RM2PT to support iStar modeling and further prototype generation for requirements validation. • We demonstrate the efectiveness of the proposed Goal2UCM by CoCoME case study, in which 93.6% of the iStar model elements can be transformed successfully without any extension.
The remainder of the paper is organized as follows: Section 2 presents the related work. Section 3 introduces the iStar and use case models. Section 4 presents the proposed approach of mapping from iStar to use case model. Section 5 demonstrates the proposed approach through CoCoME case study. Section 6 concludes the paper and proposes future work.
To the best of our knowledge, the related work is about the transformation from iStar 1.x model
to use case diagram or class diagram. The work [
The proposed approach is based on the model-driven methodology. Before starting the transformation, the meta-models of iStar and use case model are presented in this section. We use iStar 2.0 (http://istarwiki.org) as the source model and the subset use case model of UML 2.5 (https://www.omg.org/spec/UML) as the target model. The meta-models of iStar and use case model are shown in Figure 1. iStar Model: The transformation does not cover all elements of the model. For the iStar model, the classifier of the intention subject is Actor, which has two sub classes Agent and Role. Base on the element definitions iStar specification, the Agent is the instance of the subject with the Role. The Role of iStar is semantically equivalent to the Actor in UML. Moreover, the Actor has several intentions, which can be a Goal, Task, and Resource. The Goal is the state that the Actor wants to achieve with a clear achievement standard. The Task refers to the action that Actor wants to implement, usually to achieve a goal. The Resource is the physical entity or information entity that the Actor needs to execute a task.
(a) iStar Metamodel UML Model: For the UML model, we do not transform the whole system, but only focus on the use case model, which include the classifiers such as the Actor and UC in the use case diagram, and the System operation and System service in the system sequence diagram of the use case. The transformation is straightforward, we will map the semantic equivalence classifiers and their relations of iStar to the UML model. We will see transformations rules and algorithm in the next section.
This section presents how to transform the iStar model into UML model based on the metamodel introduced in the preliminary section. We introduce the transformation rules for the use case diagram and system operations of use case first and then present the transformation algorithm
When transforming the use case diagram, the whole transformation process will be divided into two parts. The first part is the conversion of Actor, and the second part is the conversion of UseCase. In UML, an Actor is an external entity that interacts with the system. It can be a user, an external system that can interact with the system, or a basic device. In the Goal Model, Actors are divided into two categories, Role and Agent. Agent is a specific instance, such as a person, organization, or department. It is not suitable to convert Agent to Actor in UML because Agent is more specific and has more limitations. Role is an abstract description of a certain group of people, such as students. It is closer to the meaning of Actor in UML, so it can be converted directly.
.() .() 1 ∶ . () 2 ∶ . ()
The rule R1 describes the process of transforming role in Goal model into actor in UML.Formula R2 describes the process of transforming Goal in Goal Model into UC in UML. The UseCase describes the function of the system as a series of events and provides valuable observations for the operator. In the Goal Model, a Goal is a state that the Actor wants to achieve, and there is a clear completion standard. They all describe behavior or state from the perspective of Actor, so they can be transformed. However, not all goals can be converted to UseCase, only goals at the root can be converted. At present, we do not consider the situation when Goal is connected to another Goal through Refinement. This problem will be improved in the follow-up work.
The Task in iStar represents an action that the Actor wants to perform, usually to reach a certain Goal. The Task is corresponding to the following elements in use case model: Message and Operation. All of these elements may be involved to complete a single task in the entire UseCase. They describe the process of the same task. But if the Task is connected by multiple other Intentional Elements with OrRefinement, it will not be transformed in our case. The rules R3 and R4 describe the process of transforming Task in Goal Model into child elements CallMessage and ReturnMessage of message in UML.
The Task with the related Resource is corresponding to the following elements in UML: Operation and Parameter. Task is transformed into Operation, however, if the Task is connected by multiple other Intentional Elements with OrRefinement, it will not be transformed. The rule R5 describes the process of transforming Parameter in Goal Model into Operation in UML. The rule R6 describes the process of transforming Resource in Goal Model into Parameter in UML. 4 ∶ . . ()
. () 6 ∶ . . () . () 3 ∶
. () . . () 5 ∶ . () . ()
To use the above transformation rules, we propose the transformation algorithm in this section. It takes an iStar model as the input and outputs UML models. Firstly, it retrieves all the Role in iStar model, and then applies the rule 1 to transform all roles into the actors in UML. For each top goal of the Role in iStar, if there is no refinement type connection for the current Goal, it indicates that the goal is in the root node section, and the algorithm apply the rule 2 to transform it into the UseCase of UML. If the current Task is not connected by other tasks or goals with OrRefinement, the rules 3 and 4 will be executed, and the current Task will be transformed into CallMessage, ReturnMessage in UML, otherwise, no transformation will be performed. Moreover, the rule 5 to transform the Task in the Goal model into the Operation in UML. Then the rule 6 under the element to transform the Resource in the Goal model into a Parameter in UML. Finally, the algorithm assembles all the transformed elements of UML and outputs a file uml.xmi.
Algorithm 1: Transformation algorithm from iStar to UML models
Input : iStar Model - iStar.xmi Output : UML Model - UML.xmi begin roles ←retrieve(iStar.xmi); for r ∈ roles do apply rule 1; elements ← getIntentions(r); for e ∈ elements do if e == Goal and isRootGoal(e) then
apply rule 2; end if e == Task then apply rule 3, 4, 5; rs ← getRelatedResource(e); for r ∈ rs do
apply rule 6; end end end
end end return assemble(UML.xmi);
In this section, we use CoCoME case study (https://www.cocome.org) to evaluate and demonstrate the efectiveness of the proposed approach. We first present a brief introduction about the case study and then show and discuss the transformation results.
We use the case study CoCoME (Supermarket System) to demonstrate the proposed approach. The main subjects of this system are the cashier and customer. The main intention of cashier is processSale. This part constitutes a simple use case diagram. The goal processSale can be expanded to the interaction with customers. First, makeNewSale is initiated and then the enterItem loop is initiated, requiring the customers to provide the cashier with barcode and quantity information about the goods until it ends. Then we proceed to the next action, endSale. Finally, a selection to either makeCashPayment or makeCardPayment is needed. If cash payment is chosen, a specific amount is required. On the other hand, if card payment is chosen, the card account number, expiry date and fee is required. Due to space constraints, this chapter can not give a good introduction to this example. Therefore, we have made relevant web pages with detailed instructions (http://istar.rm2pt.com).
The transformation results are divided into the following two parts. The first part is a use case diagram, which describes the relationship between user Cashier and his/her UseCases. Then the system operations of the use cases processSale. The transformation success rate from the Goal model to the top-level use case diagram can be reaches 100%. The success rate of the system operation and message can be reaches 87.2%.
System sequence diagram: each task in the Goal model is transformed into the corresponding interaction (Call Message, Return Message, Execution) and Service (Operation) in UML, and the Resource of Dependency in the Goal model is transformed into the corresponding Service (Operation) in UML. In this paper, we propose an approach Goal2UCM for transforming the iStar to use case model in UML, which contains a use case diagram and the system operations with its parameters of the use cases. Overall, the result is satisfactory. The 93.6% of iStar model elements can be transformed successfully. The proposed approach is implemented and integrated with RM2PT to support requirements validation. However, the results show that some elements of UML can not be directly generated due to the lack of the information in the iStar model. In the future, we will try to extend iStar model and transformation rules with the sequence marks of the tasks to support system sequence diagram models generation as well as the contract of system operation and conceptual model to fully support the prototype generation.