USL:ADomain-Specifc LanguageforPrecise Specifcationof Use Cases and ItsTransformations Chu Thi Minh Hue1, Dang Duc Hanh2, Nguyen Ngoc Binh3 and Le Minh Duc4 Departmentof Software Engineering, VNU Universityof Engineering andTechnology 1HungYen UniversityofTechnology and Education,Vietnam 2Corresponding author 3Visiting professor, Hosei University, Japan 4Hanoi University,Vietnam E-mail: {huectm.di12 | hanhdd | nnbinh}@vnu.edu.vn, duclm@hanu.edu.vn Keywords: use cases, pre-and postcondition, labelled transition systems, model transformations, domain-specifc lan­guages Received: March 29, 2018 A use case model is often represented by a UML use case diagram and loosely structured textual de­scriptions. The use case model expressed in such a form contains ambiguous and imprecise parts. This prevents integrating it into model-driven approaches, where use case models are often taken as the source of transformations. In this paper, we introduce a domain-specifc language named the Use case Speci­fcation Language (USL) to precisely specify use cases. We defne the abstract syntax of USL using a metamodel together with OCL wellformedness rules and then provide a graphical concrete syntax for the usability goal.We also defnea precise semantics for USLby mapping USL models to LabelledTransition Systems(LTSs).Itopensa possibilityto transformUSLmodelstosoftwareartifactssuchastest casesand design models.Wefocusona transformationfromaUSLmodeltoa template-basedusecase description inorderto illustrateourmethod.AlanguageevaluationofUSLisalsoperformedinthispaper. Povzetek: Zasnovanjedomenskospecif¡cno specifkacijo primerovin transformacij. cni jezik USL za natan¡ 1 Introduction like [3, 4, 9, 5, 6, 7], which used natural language descrip­ tion, the works in [10, 11] proposed a formal semantics for Use case is a software artifact that is commonly used for use case. On the other hand, UML activity and sequence di-capturing and structuring the functional requirements. A agrams are proposed in [12, 13, 14, 15] to model the control usecaseis defnedas“the specifcationof sequencesofac-fowsinuse case.Anumberofotherworks[4,16,17]pro­tions, includingvariant sequencesand error sequences,that posed usinga domain specifc language (DSL)to specify a system, subsystem, or class can perform by interacting use case. DSL [18] is a language that is designed specif-with outside objects to provide a service of value” [1]. As ically for a certain domain to ease the task of describing a requirements artifact, the use case model is commonly concepts in the domain. specifed by a UML use case diagram and loosely struc- However, the main limitation of the existing work is that tured textual descriptions [2]. A key beneft of this use they do not focus on precisely capturing the relevant use case specifcation is that it is easy for non-technical stake-case information. These include control fows, steps, sys-holders to learn and use. However, the use case models ex-tem actions, actor actions, and constraints on the use case pressed in this form often contain ambiguous and imprecise and its fows. In this paper, we propose a DSL named Use parts. This prevents the models from being used directly Case Specifcation Language (USL) to overcome this lim-in model-driven approaches, as a transformation source to itation. The goal of USL is to precisely specify use cases produce other analysis and design models. An important and its model transformation abilities. The USL’s domain challenge here is how to achieve a balance between two consists in the task of specifying use cases that capture the seemingly conficting goals: to specify use case suffciently system behavior. precise for model transformation purposes, while achieving the ease-of-use requiredby non-technical stakeholders. Our approach is to defne the abstract syntax of USL To this end, a considerable number of works, including by extending the metamodels of the UML use case and [3, 4, 5, 6, 7] and those discussed in [8], have attempted to activity diagrams [2]. Our extension consists in a set of introduce rigor into use case description. More specifcally, meta-concepts needed for the following purposes: (1) to T.Yueetal.[3] proposedaddingkeywordsand restriction describethe elementsofatypicalusecase descriptiontem-rules into use case descriptions and then using natural lan-plate; (2) to represent the basic and alternate fows ofa use guage processing techniquesin orderto analyze them. Un-caseintheformof sequential, branched, repeating steps,or concurrent steps; (3) to categorize steps and actions based on the interaction subjects, which include the system, ac­tors and included/extending use cases;and (4) to represent constraints on the use case, actions, and fows. Our precise specifcation of USL makes it possible to automatically transform USL models into other software artifacts using model transformation techniques. In brief, the main contributions of our work are as follows: – ADSL namedUSLto precisely specify use cases.We defne the abstract syntax of USL using a metamodel constrained by OCL wellformedness rules [19]. For usability, we defne a graphical concrete syntax for USL. – A formal semantics specifcation for USL using La-belled Transition System [20]. This semantics en­ables the automatic transformation of USL models into other software artifacts, such as test cases and class models. – A support tool that includes a visual editor for con­structing USL models. We use this tool and two commonly-used case studies to illustrate our method. WealsoevaluateUSLby comparingitto other related languages. This work makes four signifcant improvements from our earlier conference paper [21]. First, regarding to USL specifcation, we make the abstract syntax precise with the OCL wellformedness rules [19] anddefnea graphical con­crete syntax. Second, we develop an additional case study in order to illustrate how to apply USL in practice. Third, we defne a numqber of typical model transformation sce­nariosforUSL modelandexplain,in more detail,the trans­formation into template-based use case description.Fourth, we provide an evaluation for USL. The restofthis paperisorganizedas follows. Section2 presents the background and anexample for ourwork. Sec­tion3overviews our approach. Section4presents the USL abstract syntax andexplains its formal semantics. Section5 explains how USL models are transformed into other soft­ware artifacts. Section 6 introduces our support tool and illustrates how to apply USL to the ATMsystem case study. This section also presents anevaluationof USL. Section7 comments on the related works. The paper is closed with the conclusions and future work. 2 Background and motivation Figure 1 shows a simplifed requirement model of a Library system including a UML use case model de­picted in the part (a) and a UML class diagram capturing corresponding domain concepts of the system which is pre­sented in the part (b). Our paper uses the use case Lend Book in the part (a) as a motivating example. This use case is invoked when the librarian executes the book lending Figure 1: The simplifed use case and the conceptual do­main model of the Library system. Table1:Atypical use case description template Use case name: Lend Book Brief description: The Librarian processes a book loan. Actors: Librarian. Precondition: The librarian has logged into the system successful. Postcondition: If the use case successfully ends, the book loan is saved and a complete message is shown. In the other case, the system displays an error mes­sage. Trigger:The Librarian requests a book-loan process. Special requirement: There is no special requirement. Basic fow 1. The Librarian selects the Lend Book function. 2. The system shows the Lend-book window, gets the current date and assigns it to the book-loan date. 3. The Librarian enters a book copyid. 4. The system checks the book copyid. If it is invalid, it goes to step 4a.1 5. The Librarian enters a borrower id. 6. The system validates the borrower id. If it is invalid, it goes to step 6a.1 7. The Librarian clicks the save-book-loan button. 8. The system validates the conditions to lend book. If it is invalid, the system goes to step 8a.1 9. The system saves the book loan record, then executing two steps 10 and 11 concurrently. 10. The system shows a complete message. 11. The system prints the borrowing bill. Alternate fows E1. request searched book 1. The Librarian selects the search function after step 4a.1. 2. The system executes the extending use case Search book. 4a. The book copyid is invalid 1. The system shows an error message, then going to step 3. 6a. The Borrower id is invalid 1. The system shows an error message, then going to step 5. 8a. The lending condition is invalid 1. The system shows an error message. 2. The system ends the use case. transaction. The use case is represented in a typical tem­plate as showninTable1. A typical use case description template [22] often in­cludes two parts, the overview information elements and the detailed description of fows. The frst part consists of the following elements: the use case name, the use case’s brief description, the actors participating in the use case, the use case’s precondition and postcondition,thetrigger that initiates the use case and the special requirement that describes the non-functional requirements of the use case. The second part contains two types of fows, the basic fow and alternative fows. The basic fow covers what nor­mally happens when the use case is performed. Each use case description has only one basic fow. The alternative fows cover optional or exceptional behaviour as well as the variations of the normal behaviour. Both the basic and alternative fows are often further structured into steps or subfows [23, 1]. Moreover, one can smooth use case fows to contain only a basic fow and some alternate fows. Each step in fows consists of actions performed either by the system or actors.We refer to actors, the system, and other relation use cases as interactive subjects. For example, Step 1 in the basic fow is carried out by the Librarian actor, while Step2is performedby the sys-tem.Astep may also contain the information to decide the next moving is another step or another fow or the start-ingor fnishingof concurrent actions.As illustratedinTa­ble 1, Step2 includes three system actions, “The system shows the Lend-book window”, “The system gets the cur­rent date” and “The system assigns the current time to the book-loan date”. Step5containsa branching decision, “If it is invalid, the system goes to step 6a”. Step9 contains the starting point of two concurrent actions: “The system executes two steps 10 and 11 concurrently”. In ourwork, we consider sentences describingexecution of an extending or an included use case as the system’s actions. Our previous work [21] divides use case’s actions into nine types as follows: Actor-Input is an actor action to enter data into the sys­tem, e.g., the action “The Librarian enters a book copyid” at Step3inTable1is an Actor-Input. Actor-Request is an actor action to send requests into the system, e.g., the action “The Librarian clicks the save-book-loan button” at Step 7 in Table 1 is an Actor-Request. System-Display is a system action that the system per­forms operations with the user interface, e.g., the action “The systemshowsthe lend-book window”atStep2inTa­ble1is a System-Display. System-Operation is a system action to validate a re­quest and data, or process and calculate data, e.g., the ac-tion“Thesystemgetsthe currentdate”atStep2inTable1 is a System-Operation. System-State is a system action to query or update its internal states, e.g., the action “The system saves the book loan record”atStep9inTable1isa System-State. System-Output is a system action to send outputs to the actors, e.g., the action “The system shows an error mes­sage” at Step 1 of the alternate fow 4a in Table 1 is a System-Output. System-Request is a system action to send requests to a secondary actor, e.g., the action “The system prints the borrowing bill” at Step 11 shown in Table 1 is a System-Request. System-Include is a system action to include another use case. System-Extend is a system action to extend another use case, e.g., the action “The system executes the extending use case Search book” within Step2of the alternate fow E1 inTable1is a System-Extend. Ause case is successfully executed only if the pre-and postcondition of the use case as well as of the actions of the current fow are satisfed. Within the context of model-driven development, a use case model,as illustratedinFig.1 tendstobetakenasa source model of transformations in order to obtain other software artifacts such as analysis models, design mod­els, and test cases. However, the ambiguous and imprecise parts within use case descriptions prevents us from achiev­ing such transformations. In order to integrate use cases into model-driven approaches, we aim to tackle the follow­ing challenges: Capturing the overview structure. The use case model needs to preserve the overview structure of use case de­scriptions so that a template-based representation of use cases might be generated for non-technical stakeholders. Specifyingprecisely controlfollows. Ause case includes a set of scenarios, each of which corresponds to a control fow of the use case. Therefore, the use case model needs to preserve the information of control fows of use cases. This allows us to automatically generate artifacts like test scenarios and behaviour models. Specifying precisely actions. The use case model needs to precisely represent actions within use case scenarios. Aprecise specifcation of actions allows us to capture use case relationships and to generate other artifacts from use cases such as class diagrams, test scenarios, and test ob­jects. Specifying use case constraints. For the aim to automat­ically generate test data, the use case model needs to pre­servethe constraints within use case descriptions, including the pre-and postcondition of use cases, the pre-and post­condition of use case actions, and their guard conditions. 3 Overview of the approach Figure2 illustrates our approach. First, we take as input a use case diagram, the textual descriptions of use cases, and a class diagram capturing the conceptual model of the system. Then, we aim to represent each use case specif­cation as a model element of a so-called use-case domain. In order to defne the use-case domain, we defne meta-concepts w.r.t. the structural elements of the typical use-case-description template and the use case concepts as ex­plained in Sect. 2. The meta-concepts allow us (1) to rep­resent the basic and alternate fows of a use case in form of sequential, branched, or repeating steps, (2) to categorize use case steps and actions based on the interactive subjects including the system and actors, and (3) to represent con­straints on the use case and its fows. Figure 2: Overview of the USL Approach. In order to represent textual descriptions of actions or constraints within a use case specifcation, we consider them as operations on an object-oriented model w.r.t. the input conceptual model of the system. In that way, we could employpairs ofpre-and postcondition as contracts on actions in order to obtain a more precise specifcation of the use case. The constraints are often expressed using constraint languages such as the OCL [24], JML [25], and natural language as mentioned in [17]. In this research, we employthe OCL to represent the constraints. Specifcally, our approach is realized as follows. We propose a domain specifc language named USL in order to represent use cases within the use-case domain. Fur-ther,wedefneaformal semanticsofUSLsothatwecould transform USL models in to other artifacts such as test cases and analysis class models. To illustrate this point, a transformation from a USL model to a template-based use case description willbeexplainedin detailsin SubSect. 5.3. 4 The USL language This section frstexplains the abstract syntax and the graph­ical concrete syntax of USL. Here, we utilize the meta-modeling approach as mentioned in [26] to defne USL. Then, we focus on defning a precise semantics for USL by mapping a USL model to a Labelled Transition Sys-tem(LTS) [20]. 4.1 The USL abstract syntax We defne the USL metamodel w.r.t. the use-case domain based on (1) UML use case specifcation (Chapt. 18 of [2]), (2) the Use Case Descriptions (UCDs) [1], [23], [22], and (3) the UML activity specifcation (Chapt.s 15, 16 of [2]). We will refer to these as thedomain sources (1), (2), and (3), respectively. Figure3shows the metamodel of USL.For brevity, we divide the metamodel into four blocks: (a), (b), (c), and (d). Figure 3-a(i.e., block (a)) presents the top-level con­cepts. Figure 3-b presents the FlowStep hierarchy. Fig­ure 3-c presents the ControlNode hierarchy. Figure 3­d presents the Action hierarchyand how it is related to the FlowStep hierarchy. Figure 3-e presents the con­cept Constraint and how it is used to specify Action, InitialNode, FinalNode, and FlowEdge. Toconservespace, we will not repeat here the defnitions of all of the USL concepts that are described in the three domain sources. Wewill instead focusonakeysub-setof the concepts – those that will be used later to defne the transformationof USL models. Figure4presents the USL model of the Lend Book use caseasshowninTable1.We will use this example USL model in order to illustrate our defnitions. Action (domain sources(1,3)) representsa action thatis performed eitherbyan actor orbythe system. An Action is characterisedby the following attributes: actionName and parameters. The parameters are represented by concept Parameter inherited the concept Parameter of UML (as presented in Sect. 19.9.13 of [2]). Action is specialized into two main types (as illustrated in Fig. 3-d): ActorAction and SystemAction. ActorAction is further specialized into ActorRequest and ActorInput. SystemAction is special­ized into SystemOperation, SystemOutput, SystemDisplay, SystemState, SystemInclude and SystemExtend that were explained in Sect. 2. FlowStep (domain source (2)) is a sequence of Actions that represents a step in a basic fow or an alternate fow of the use case. It is characterised by the following attributes: number (the order number of step), description (the content of the step) and maxloop (the maximum itera­tion of the step if existing). FlowStep is specialized into two types (as shown in Fig. 3-b): ActorStep and SystemStep, as mentioned in Sect. 2. We defne three utility functions as showninTable2. Example 4.1.1. The USL model shown in Fig. 4 con­sists of the FlowSteps s1, ..., s16. Among these, s1is an ActorStep and s2 isa SystemStep. Step s3 contains the ActorInput a5. Step s1 contains the ActorRequest a1. Step s2 con­ tains SystemOperation a3. Step s10 con­ tains the SystemOutput a12. Step s4 con­ tains the SystemState a6. Step s11 contains the SystemRequest a13. Step s14 contains the SystemExtend a16. The Action a5 has Parameter “bcid”. Control Node (domain source (3)) represents a control action that regulates the fows across other USLNodes. A ControlNode, as illustrated in Fig. 3-c, is specialized into InitialNode, FinalNode, DecisionNode, ForkNode and JoinNode. These respectively represent the starting and ending points of use case, the branching points of steps, and the starting and ending points of con­current actions in steps. To ease notation, we defne two overloading functions w.r.t. ControlNode and a func­tion w.r.t. DecisionNode as showninTable2. Example 4.1.2. The USL model as shown in Fig. 4 contains nine ControlNodes c0, ..., c8. In partic­ular, c0 is an InitialNode, c7 and c8 are different FinalNodes, c1, ..., c3 and c6 are DecisionNodes, c4 is a ForkNode, andc5isa JoinNode. USLNode represents all the nodes FlowStep or ControlNode that make up a USL model. FlowEdge (domain source (3)) is a binary directed edge between two USLNodes. If both steps are a part of a basic fow, we call the transition a BasicFlowEdge. On the otherhand,ifbothstepsareapartofan alternatefow,we call the transition an AlternateFlowEdge. As shown in Table 2, we defne two utility functions source and target, two overloading functions guardE and a func­tion isCompleted w.r.t. the concept FlowEdge. Example 4.1.3. The USL model as shown in Fig. 4 contains b1, ..., b18 as BasicFlowEdges and al_1, ..., al_10 as AlternateFlowEdges. Variable (domain source (3)) represents variables that Figure 3: The USL metamodel. Table 2: List of utility functions w.r.t. USL concepts Utility function Description firstAct:FlowStep › Action lastAct:FlowStep › Action actions:FlowStep › Actions firstAct:ControlNode › ControlNode lastAct:ControlNode › ControlNode source:FlowEdge › USLNode target:FlowEdge › USLNode guardE:FlowEdge › Constraint guardE:USLNode › USLNode › Constraint isCompleted:FlowEdge › Boolean preA:Action › Constraint preA:ControlNode › Constraint postA:Action › Constraint postA:ControlNode › Constraint preC:USLModel › Constraint postC:USLModel › Constraint postC:USLModel › FinalNode › Constraint Returning the frst Actions of a FlowStep. Returning the last Actions of a FlowStep. Returning a set of Actions of a FlowStep. Returning the ControlNode itself. Returning the ControlNode itself. Returning the source USLNodes of a FlowEdge. Returning the target USLNodes of a FlowEdge. Returning the guard condition. Taking the source and target USLNodes as input and returning the guard condition. Determining whether or not lastAct(source(e)) has completed its exe­cution. Returning the precondition of an Action. If the ControlNode is nota InitialNode, returning true, else return­ing the Constraint of the InitialNode Returning the postcondition of an Action. If the ControlNode is nota FinalNode, returning true, else returning the Contraint of the FinalNode. Returning the precondition of a USLModel. Returning the postcondition of a USLModel. Returning the postcondition of a particular FinalNode of a USLModel. hold data values during the execution of a use case sce­nario. It is inherited the concept Variable of UML pre­sented Sect. 15.7.25 of [2]. DescriptionInfor (domain source (2)) maintains the other textual description of use case. Constraint (domain source (1,3)) represents constraints that are formed by use case variables: (1) the precondi­tion of use case associated with InitialNode; (2) the postcondition of use case associated with FinalNodes; (3) guard conditions of a transition; and (4) the pre-and postcondition of an Action. This concept is inherited the concept Constraint in UML, shown in Sect. 7.6 of [2]. As depicted in Table 2, we defne utility functions w.r.t. Constraints to get the pre-and postcondition of ac­tions and use case. Example 4.1.4. The USL model as shown in Fig.4 con-tainsg1,...,g6asguard conditionsandp1,...,p6aspost­conditions of Actions. We defne a set of OCL wellformedness rules as restric­tions on the USL metamodel. These rules are defned in the context of the UseCase concept and listed as follows. Rule 1. AUSL model has oneInitialNode: 1 self.uslnode->selectByType(InitialNode) 2 ->size()=1 Rule 2. AUSL model has at least oneFinalNode: 1 self.uslnode->selectByType(FinalNode) 2 ->size() >= 1 Rule 3. AUSL model has at least oneFlowStep: 1 self.uslnode->selectByKind(FlowStep) Figure 4: Representing the Lend Book use case as a USL model. 2 ->size()>=1 Rule 4. An InitialNode has one out-going BasicFlowEdge and does not have any in-coming FlowEdges: 1 (self.flowedge->select(t:FlowEdge|t.source. oclIsTypeOf (InitialNode))->size()=1)and( self.flowedge ->select (b:FlowEdge|(b. source.oclIsTypeOf(InitialNode)) and (b. oclIsTypeOf(BasicFlowEdge)))->size()=1) and (self.flowedge->select(t:FlowEdge| t .target.oclIsTypeOf(InitialNode))->size() =0) Rule 5. A FinalNode has one in-coming FlowEdge and does not have anyout-going FlowEdge: 1 self.uslnode->selectByType(FinalNode)-> forAll (f:FinalNode|(self.flowedge-> select(e:FlowEdge|e.target=f) ->size() =1) and (self.flowedge->select (e: FlowEdge|e.source=f)->size()=0)) Rule 6. A DecisionNode has one in-coming FlowEdge and at least two out-going FlowEdges: 1 (d:DecisionNode|(self.flowedge->select(e: FlowEdge|e.target=d)->size()=1)and ( self.flowedge->select(e:FlowEdge|e. source=d)->size()>=2) ) Rule 7. A ForkNode has at least one in-coming FlowEdge and at least two out-going FlowEdges: 1 self.uslnode->selectByType(ForkNode)->forAll( f:ForkNode|(self.flowedge->select(e: FlowEdge|e.target=f)->size()>=1) and ( self.flowedge->select(e:FlowEdge|e.source =f)->size()>=2) ) Rule 8. A JoinNode has at least two in-coming FlowEdges and one out-going FlowEdge. 1 self.uslnode->selectByType(JoinNode)->forAll (j:JoinNode|(self.flowedge->select(e: FlowEdge|e.target=j)->size()>=2)and(self. flowedge->select (e:FlowEdge|e.source=j) ->size()=1)). Rule 9. ASystemStep or ActorStep has at least one in-coming FlowEdge and one out-going FlowEdge: 1 self.uslnode->selectByKind(FlowStep)->forAll( f:FlowStep|(self.flowedge->select(e: FlowEdge|e.target=f)->size()>=1)and(self. flowedge->select(e:FlowEdge|e.source=f)-> size()=1)) Rule 10. A USL model is valid if the FlowEdges that connect the USLNodesof the model arevalid, i.e., the type and label are correctly defned: 1 self.uslnode->forAll(n:USLNode| 2 if (n.oclIsTypeOf(InitialNode))then 3 self.flowedge->select(b:FlowEdge| 4 (b.source.oclIsTypeOf(USL::InitialNode)) and (b.oclIsTypeOf(USL::BasicFlowEdge)))-> size()=1 5 else 6 if (self.flowedge->selectByType( BasicFlowEdge)->select(b:BasicFlowEdge|b .target=n))->size()>=1 then 7 if (n.oclIsTypeOf(DecisionNode))then 8 self.flowedge->selectByType(BasicFlowEdge) ->select (b:BasicFlowEdge|b.source=n) ->size()=1 9 else 10 if (n.oclIsTypeOf(ForkNode)) then 11 self.flowedge->select(f:FlowEdge|f.source =n)->forAll(b:FlowEdge|b.oclIsTypeOf( BasicFlowEdge)) 12 else 13 if (n.oclIsTypeOf(JoinNode)) then 14 (self.flowedge->select(f:FlowEdge|f. source=n)->forAll(b:FlowEdge|b. oclIsTypeOf(BasicFlowEdge)))and(self .flowedge->select(f:FlowEdge|f. target=n)->forAll (b:FlowEdge|b. oclIsTypeOf(BasicFlowEdge))) 15 else 16 if(n.oclIsKindOf(FlowStep)) then 17 self.flowedge->select(f:FlowEdge|(f. source=n) and (f.oclIsTypeOf( BasicFlowEdge)))-> size() = 1 18 else true 19 endif 20 endif 21 endif 22 endif 23 else ((self.flowedge->selectByType( BasicFlowEdge)->select(b:BasicFlowEdge|b. source=n))->size()=0) and if(n. oclIsTypeOf(FinalNode))then 24 true else self.flowedge ->selectByType ( AlternateFlowEdge) ->exists (f: AlternateFlowEdge|f.label=self. flowedge->selectByType( AlternateFlowEdge)->select(a: AlternateFlowEdge|a.target=n)->first() .label)endif) 25 endif 26 endif) Rule 11. The number property of each FlowStep in a Basic fow is unique: 1 self.uslnode->selectByKind(FlowStep)->select( n:FlowStep|self.flowedge->selectByType( BasicFlowEdge)->exists(t:BasicFlowEdge|(t .source=n)or(t.target=n)))->forAll(n1: FlowStep, n2:FlowStep|n1.number=n2.number implies n1=n2). Rule 12. The number property of each FlowStep in an Alternate fow is unique: 1 self.uslnode->selectByKind(FlowStep)->select (n:FlowStep|self.flowedge->selectByType( AlternateFlowEdge)->exists(t: AlternateFlowEdge|(t.source=n)or(t.target =n)))->forAll(n1:FlowStep,n2:FlowStep|(n1 .number=n2.number)and(self.flowedge-> selectByType(AlternateFlowEdge)->select( t1:AlternateFlowEdge|t1.target=n1)->first ().label=self.flowedge->selectByType( AlternateFlowEdge)->select(t2: AlternateFlowEdge|t2.target=n2)->first(). label) implies n1=n2). Example 4.1.5. Let us focus on the USL model as shown in Fig. 4: – If we remove c0 from or add a new InitialNode to this model then it will violate Rule 1. – If we remove both c7, c8 from the model then it will violate Rule 2. – If the model only has ControlNodes then it will violate Rule 3. – If FlowEdge b1is nota BasicFlowEdge but an AlternateFlowEdge then the model will violate Rule 4. – If we connect b17 to c8 and remove c7 then the model will violate Rule 5. – If we add an AlternateFlowEdge to connect s4 toc6 then the model will violate Rules6and9. – If we remove b14, s11, b16, p3 then the model will violate Rules7and8. – If either FlowEdge b6is nota BasicFlowEdge but an AlternateFlowEdge or the value of the label property of AlternateFlowEdge al_1 is not “4a” then the model will violate Rule 10. – If the value of the number propertyofs2is not2but 1then the model will violate Rule 11. – If the value of the number property of s14 is not2 but1then the model will violate Rule 12. 4.2 The USL concrete syntax In order to help the user to easily create USL models, we propose a concrete syntax for USLwith the graphical no­tations as shown in Table 3. We have implemented this syntax in a visual editor for USL modelling. A detailed explanation of this tool will be presented in Sect. 6. 4.3 Formal semantics of USL We formally defne a USL model as follows. Here, we consider a USL model as a graph consisting of nodes and edges. Anode represents either a step or a control action performedbythe system. Further,we will takeinto account thefact that the underlying use case references the domain concepts captured in a UML class diagram. Defnition 1. A USL Model of a use case is the tuple D = hDC , A, E, Ci such that: – DC is a class diagram to represent the underlying do­main; – A is the set of USLNodes; – E is the set of FlowEdges; – C = G . CpreUC . CpostUC . CpreA . CpostA is the set of Constraints, where: – A = AcNode . Af ; – AcNode = NI . NF . Nd . Nj . Nf , where NI = {a | a . A, InitialNode(a)} NF = {a | a . A, FinalNode(a)}, Nd = {a | a . A, DecisionNode(a)}, Nj = {a | a . A, JoinNode(a)}, Nf = {a | a . A, ForkNode(a)}; – |NI | =1;|NF |. 1; – Af = Aa . As, where Af = {a | a . A, FlowStep(a)}, Aa = {a | a . A, ActorStep(a)}, As = {a | a . A, SystemStep(a)}; – |As|. 1;.s . Af .|actions(s)|. 1; – E = Eb . Ea and Eb . Ea = Ø, where Eb = {e | e . E, BasicFlowEdge(e)}, Ea = {e | e . E, AlternateFlowEdge(e)}. C.T.M. Hue et al. Table 3: The graphical notations of USL Concepts Presentation Notation DescriptionInfor Aborderless text box that properties are listed in the text box InitialNode An unflled circle FinalNode Acircle with a crosshairs symbol DecisionNode Aflled diamond with one in-coming arrowed line and at least two out-going arrowed lines ForkNode Asolid line segment with one in-coming arrowed line and at least two out-going arrowed lines JoinNode Asolid line segment with at least two in-coming arrowed lines and one out-going arrowed line BasicEdge Athick arrowed line AlternateEdge Alabelled, thin arrowed line (the label is the name of the fow) ActorStep Alabeled, 2-part rectangle. The frst part contains the label and two properties numberStep and description of the ActorStep. The second part contains the ActorActions of the ActorStep SystemStep Alabelled, 2-part rectangle. The frst part contains the label and two properties numberStep and description of the SystemStep. The second part contains the SystemActions of the SystemStep Action Information of a Action are presented by textual form in the second part of FlowSteps Example 4.1.5. The USL model as shown in Fig. 4 contains the following elements: NI = {c0}; NF = {c7,c8}; AcNode = {c0, ..., c8}; Aa = {s1,s3,s5,s7,s13}; As = {s2,s4,s6,s8, ..., s12,s14,s15,s16}; Eb = {b1, ..., b17}; Ea = {al_1, ..., al_10};G = {g1, ..., g6};CpreUC = Ø; CpostUC = Ø;CpreA = Ø;andCpostA = {p1, ..., p6}. DC corresponds to the conceptual model shown in the part (b) of Fig. 1. There are sixteen constraints for guard conditions and pre-and postconditions, e.g., the postcondition p1 of Action a11 isexpressedby the following OCL contraint: BookLoan.allInstances()->exists(b:BookLoan| (b.bcid = bcid) and (b.bid = bid) and (b.payed=0)). We useLTS [20] to formally defne the operational se­mantics of USL. Conceptually, the execution of a USL modelis modelledbyanLTS, whose transitions are caused by the execution of use case actions, and whose states are defned by variable assignments during the execution. We defnetheLTSofaUSL model recursively fromthe basic USL concepts. The semantics of these concepts are defned as summarized inTable 4. Defnition2formalizes the no-tionof theLTSof the USL model. Defnition 2. Given a USL model D = hDC , A, E, Ci, an LTS that results from the execution of D is the tuple h.(V), P(G×A×P), T ,.init, Fi such that: Table4:LTS-based semanticsof the basic USL concepts – V is a fnite set of variables whose types include the basic types and the classes of the DC ; – .(V) is the set of states(.), each of which is a set of value assignments to a subset of variables in V; – P. CpostA . CpostUC is the set of constraints as the postconditions of D; – A = AcNode . Aact is the set of actions; – G. G.CpreUC .CpreA is the set of guard conditions of the transitions; – T. .(V) × P(G×A×P) × .(V) is the tran­sition relation defned as follows: A transition t = g|a|r (., (g, a, d),.0) .T , written as . -› .0, where a .A is the action that causes t, g = defGuard(a) . G is the guard condition to execute a, r .P is the postcondition of a, and ., .0 . .(V) are the pre-and post-states of t (resp.) such that .0 satisfes r; – .init . .(V) is the initial state; – F. .(V) is the set of fnal states, where: S – Aact = s.Af actions(s); – defGuard is defned as follows (summarized fromTa­ble 4). preC(D), ifInitialNode(a) Librarian:“100”, Librarian:“111”, BookLoan:“1”, guardE(e)(e . D.E, target(e)= a), ifDecisionNode(a) BookLoan:“2”}. Transition . ForkNode(a) . FinalNode(a) isCompleted(e) . guardE(e), V ta11,c4 = .a11 true|c4|true -› .c4. . . . . . . . . . . .. (e.D.E,target(e)=a) if JoinNode(a) reachable(.a11) ={ta11,c4} and firable(.a11)= = preC(DI ) . preA(a) . guardE(e)(e . D.E, target(e)= a), {ta11,c4}. if SystemInclude(a) Defnition 4. Givena current state . of anLTS L ofa USL . . . . . . . . . . preC(DX ) . preA(a) . guardE(e)(e . D.E, target(e)= a), if SystemExtend(a) preA(a) . guardE(e)(s . Af , target(e)= s), if((a . Aact) . (a = firstAct(s)) preA(a)(s . Af ,a . actions(s)), ifotherwise model D,a concurrent transition . . L.T is a set of transitions t1,t2,...,tn . firable(.). Example 4.3.3. When the USL model as shown in Fig. 4 executes at Step c4, we have two transi­ true|a12|p2 tions tc4,a12 = .c4 -› .a12 and tc4,a13 = true|a13|p3 .c4 -› .a13, reachable(.c4)= {tc4,a12,tc4,a13} and firable(.c4)= {tc4,a12,tc4,a13}. Hence,{tc4,12, tc4,13} is a concurrent transition and .a12, .a13 satisfy p2, p3, respectively. Within our approach theLTSofa USL model may con­tain both concurrent and non-concurrent transitions. We next defne the semantics of a use case scenario. Defnition 5. Given a use case scenario ofa USL Example 4.3.1. We assume that the snapshot shown in Fig. 5 is captured when the USL model as shown in Fig. 4 is executed at Step a8. We have the follow­ing value assignments: (bcid, “001”) . bcid = “001”, (lid, “110”) . lId = “100”, (ldate, “25/8/17”) . ldate = “25/8/17”, (bid, “1234”) . bcid = “1234”. The objects of the snapshot are as follow: BookCopy:“001”, BookCopy:“002”, Borrower:“123”, Borrower:“124”, Librarian:“100”, Librarian:“111”, BookLoan:“1”. Then, we have .a8 = {(bcid, “001”), (ldate, “001”), (lid, “110”), (bid, “124”), (bLoan, (“2”, “001”, “124”, “110”, “25/8/17”, 0)), BookCopy:“001”, BookCopy:“002”, Borrower:“123”, Borrower:“124”, Librarian:“100”, Librarian:“111”, BookLoan:“1”}. Certain use case actions are concurrent actions, whose executions cause concurrent transitions between states. The next two defnitions defne precisely what this means. Defnition 3. Givena current state . of anLTS L ofa USL g|a|r model D and a transition t = . -› .0 . L.T , we defne the following terms: – preT(t)= ., postT(t)= .0 , guard(t)= g, postC(t)= r, and act(t)= a. – eval(g) is the evaluation of Constraint g. – reachable(.)= {t | preT(t)= .} is the set of transitions that start from .. – firable(.)= {t . reachable(.), eval(guard(t)) = true} is the set of transitions that can be fred from .. Example 4.3.2. When the USL model as shown in Fig.4 executes at action a11, we have .a11 = {(bcid, “001”), (lDate, “001”), (lid, “110”), (bid, “124”), (bLoan, (“2”, “001”, “124”, “110”, “25/8/17”,0)), BookCopy:“001”, BookCopy:“002”,Borrower:“123”, Borrower:“124”, model D that consists of the following sequence of actions (a0,...,an-1). The execution of this scenario is realized t0t1tn-1 asapathin theLTS L of D: p = .0 › .1 › · ·· › .n, gi|ai|ri where ti = .i -› .i+1 (.i =0, . . ., n - 1), .0 = L..init, .n . L.F, and ti . L.T . Example 4.3.4. When the USL model as shown in Fig.4 executes at Step .a11 as mentioned above and eval(g1), eval(g3), and eval(g5) are true, then the use case sce­nario is as follows: true|a1|true true|a2|true true|a3|true p = .init -› .a1 -› .a2 -› true|a4|true true|a5|true true|a6|true .a3 -› .a4 -› .a5 -› true|c1|true g1|a7|true true|a8|true .a6 -› .c1 -› .a7 -› true|c2|true g3|a9|true true|a10|true .a8 -› .c2 -› .a9 -› g5|a11|true true|c4|true {true|a12|p2,true|a13|p3} .a10 -› .a11 -› .c4 -› true|c5|true true|c7|true .a12-a13 -› .c5 -› .c7 (.c7 .F). 5 Transforming USL models to other software artifacts This sectionexplainshowUSL models canbe transformed to software artifacts including test cases, structural and be­havioral models, and textual template-based use case de­scriptions (TUCDs). We particularly focus on the last transformation (to obtain TUCDs) and show how the trans­formation could be realized. 5.1 Generating test cases Atest scenario is used to create a set of test cases [27]. A test case results from combining a test scenario with some test data. According to the use case-driven testing approach [27], a use case scenario identifes one test scenario (a use case description consists of one or more use case scenar­ios). The constraintsofa use case scenariohelp identifying the test data of the corresponding test scenario. The model-based testing (MBT) method [28] presents a specifc technique for automatically generating test cases from a use case model. Specifcally, the control fows of a use case model are used to generate the use case scenar­ios. For example, Linzhang [29] frst presents a technique to represent the control fows using UML activity diagram. He then proposes an algorithm to traverse all the possible basic paths of the activity diagram to generate the test sce­narios. Two other works [30, 31] focus on the problem of auto­matically generating test data from the test scenario con­straints, written in OCL. They develop OCL constraint solvers for this task. Since our USL captures the necessary information ele­ments of the use case description, we argue that USL mod­els can also be used as an input to generate test cases. More specifcally, USL has meta-concepts for representing the different control nodes of the UML activity diagram. Fur­ther, the Constraint meta-concept of USL captures the different types of constraints that are needed to generate test data. 5.2 Generating structural and behavioural models In the requirement analysis activity, the behaviours de­scribed in a use case description are analysed in order to create other structural and behavioural models. The target models are often represented using UML diagrams, includ­ing activity diagram, class diagram, collaboration diagram, and sequence diagram. D. Savic´et al. [16] and M. Smialek et al. [17] propose a specifc method for the above. In particular, they frst use different types of actions to precisely model the use case behaviours. Theythen presenta model transformation technique that automaticallytransforms the behaviours and other relevant model elements into a class diagram. Ex­amples of these elements that are discussed in [28] include sender and receiver objects, messages, and parameters. Our USL specifcation was inspired by this work. Specifcally, we use Action meta-concept to represent use case behaviours and the relevant model elements dis­cussed above. Regarding to behavioural modelling, a USL model can be used as input to generate activity and se­quence diagrams. The reason is because USL represents all the control nodes of UML activity diagram. For exam­ple, a specifc technique for generating sequence diagram is presented in [12]. 5.3 Generating TUCDs According to [32, 33, 34], textual template-based use case descriptions (TUCDs) [1, 22, 8] enable the customer to positively participate in requirement analysis, to identify and resolve conficts in the requirement drafts, and to en­sure thatitis consistent with their intention.Table1shown earlier is an example of such a template. Informatica 42 (2018) 325–343 335 In order to automatically generate a TUCD from a USL model, we develop a transformation USL2TUCD using the model-to-text transformation language Acceleo [18]. The transformation USL2TUCD is shown in Listing 1. We illustrate this transformation using the USL model of the use case named Withdrawal (shown in Fig. 9). The output TUCDisatext fle named Withdrawal.txt that is shown in Fig. 10. Briefy, the USL2TUCD transformation uses fve queries to extract information from the input USL model (uc). The frst query is getBasicFlow(uc) at line 19. It is used is to fnd all the BasicFlowSteps in uc. The second query is getDecisionNode (uc) at line 25. It is used to get all the DecisionNodes in uc. The third query is getPreAlternateFlowLabel(uc,d) at line 27. It is used to get the label of the in-coming AlternateFlowEdge of some DecisionNode d in uc. It returns empty if no such AlternateFlowEdges exist. The fourth query is getAFEdges(uc,d) at lines 29 and 37. This query is used to get the out-going AlternateFlowEdges from a DecisionNode d in uc. The ffth query is getAlternateFlow(uc, l) at lines 30 and 39. This query is used to fnd the FlowSteps in the AlternateFlow in uc that is labeled l. The defnitions of all fve queries are written in another transformation named libraryUCD. The transformation is shown in Listing 2. Listing1: TheUSL2TUCDtransformation 1 [module GenUCDescription(’http://eclipse .USLModel/USL’)] 2 [import org::eclipse::acceleo::module:: sample::service::libraryUCD] 3 [template public generateElement(uc: UseCase)] 4 [comment @main/] 5 [file (uc.descriptioninfor->r at(0). useCaseName.concat(’.txt’), false, ’ UTF-8’)] 6 [let d:DescriptionInfor =uc. descriptioninfor-> at(0)] 7 ---------------------------------­8 UC name: [d.useCaseName/] 9 Description: [d.description /] 10 Actor: [for(a:String|d.actor)] a, [/for] 11 Level abstract: [d.levelAbstract /] 12 Precondition: [d.preCondition /] 13 Postcondition: [d.postCondition /] 14 SpecialRequirement: [d. specialRequirement/] 15 [/let] 16 ---------------------------------­17 BasicFlow 18 ---------------------------------­19 [let Bsteps:OrderedSet(FlowStep)= getBasicFlow(uc)] 20 [for(s:FlowStep|Bsteps)] 21 [s.number/]. [s.description/] 22 [/for] [/let] 23 ---------------------------------­ 24 AlternateFlow 25 [let dList:OrderedSet(DecisionNode)= getDecisionNode(uc)] 26 [for(d:DecisionNode|dList)] 27 [let preALabel:String= getPreAlternatFlowLabel(uc, d)] 28 [if(preALabel=’’)] 29 [for(af:AlternateFlowEdge|getAFEdges( uc, d))] 30 [let Asteps:OrderedSet(FlowStep)= getAlternateFlow(uc, af.label)] 31 [af.label/]. [af.description] 32 [for(s:FlowStep|Asteps)] 33 [s.number/]. [s.description/] 34 [/for] [/let] 35 [/for] 36 [else] 37 [for(af:AlternateFlowEdge|getAFEdges( uc, d))] 38 [if(af.label <>preALabel)] 39 [let Asteps:OrderedSet(FlowStep)= getAlternateFlow(uc, af.label)] 40 [af.label/]. [af.description/] 41 [for(s:FlowStep|Asteps)] 42 [s.number/]. [s.description/] 43 [/for] [/let] 44 [/if] 45 [/for] 46 [/if] [/let] 47 [/for] [/let] 48 ---------------------------------­ 49 [/file] 50 [/template] Listing 2: The libraryUCD transformation 1 [comment encoding = UTF-8 /] 2 [module libraryUCD(’http://eclipse. USLModel/USL’)] 3 [query public getBasicFlow(uc:UseCase): OrderedSet(FlowStep)=uc.uslnode-> select (n:USLNode|uc.flowedge-> selectByType (BasicFlowEdge)->exists( b:BasicFlowEdge|(n=b.source) or (n=b. target)))->selectByKind(FlowStep)/] 4 5 [query public getAlternateFlow(uc: UseCase,l:String): OrderedSet( FlowStep)=uc.uslnode->select(n: USLNode|uc.flowedge->selectByType( AlternateFlowEdge)->select(a: AlternateFlowEdge|a.label=l)->exists( f:AlternateFlowEdge|(f.target=n)or(f. source=n)))->selectByKind(FlowStep)/] 6 7 [query public getAFEdges(uc:UseCase, d: DecisionNode): OrderedSet( AlternateFlowEdge) =uc.flowedge-> select(f:FlowEdge|(f.source=d)and(f. oclIsTypeOf(AlternateFlowEdge)))-> selectByType (AlternateFlowEdge) /] 8 9 [query public getDecisionNode(uc:UseCase ): OrderedSet(DecisionNode)=uc. uslnode->selectByType(DecisionNode) /] 10 11 [query public getPreAlternatFlowLabel ( uc:UseCase,d:DecisionNode):String= 12 if uc.flowedge->selectByType( AlternateFlowEdge)->select(f: AlternateFlowEdge| f.target=d)->size ()>0 then 13 uc.flowedge->selectByType( AlternateFlowEdge)->select(f: AlternateFlowEdge| f.target=d)->at (0).label 14 else 15 ’’ 16 endif /] 6 Tool support and evaluation In this section, we frst describe a USL tool that we have developed for visually creating USL models. After that, we explain two case studies for USL.We conclude this section with an evaluation of USL. 6.1 Tool support Wedevelopeda support toolfor our approachas illustrated in Fig. 6. This USL tool provides three main functions. The frst function (displayed on the left of the fgure) is called the “Loading function”. It is responsible for loading the use cases and domain concepts of a system from a UML use case diagram anda class diagram. The second function (shown on the right of the fgure) is called “USL Editor”. It is used to create the USL models for the loaded use cases. This editor has a user-friendly GUI. The third function is called “Generating Artifacts”. It automatically generates other software artifacts. In our tool, the “Loading function” was developed using a Java project. The “USL Editor” was implemented using an EMF project and an GMF project within the Eclipse tool [26]. Specifcally, the EMF project is tobuild the abstract syntaxofUSLandtheGMF projectistobuildthe concrete syntax and to implement the OCL constraint rules on the metamodel. The “Generating artifacts” function was writ­ten using model transformation languages, such as M2T and M2M [18]. To illustrate, Fig.8 showsa USL model for the use case Session, that is created by the “USL Edi­tor”. Figure10showsaTUCDtextflethatis automatically generated by a transformation that was specifed earlier in Listings1 and 2. This transformation was written in the Acceleo M2T language. Note that when working with a generation relationship between use cases, the modeler needs to create USL models only for the specifc use cases rather than for the abstract ones. Figure 6: The USL tool. 6.2 Case study In order to demonstrate the applicability of our method, we chose another system case study named ATM, which is de­scribed in Bjork [35]. The system includes three actors, seven specifc use cases, one abstract use case, and two use case relationships. Figure7shows the use casesof the ATM system. Figure8 and Fig.9 show two USL models corresponding to these two use cases: Session and With­drawal. Figure 10 and Fig. 11 show two TUCD text fles that are generated from these two USL models, by apply­ing the function “Generating Artifact”. These fles are the use case descriptions of the two corresponding use cases. Figure 7: The use case diagram of the ATM system. 6.3 Language evaluation This section presents our evaluation of USL’s expressive­ness, compared to fve languages: RUCM [3], UC-B [10], MBD-L1 [4], SiLabReq [16] and RSL [17]. We use the following four sub-criteria of expressiveness: C1. Template-based representation of use case descrip­tions C2. Control fow-based representation of use case be-haviour 1‘MBD’ stands for the author’s names, ‘L’ for language. C3. Action specifcation C4. Use case constraint representation Table5lists theevaluation results for the above criteria. In the table, we use three letters ‘F’, ‘I’, ‘N’ to denote the specifcation method that is used for each language: ‘F’ denotes formal specifcation method, ‘I’ denotes informal specifcation method and ‘N’ denotes that the specifcation method is not discussed. Table 5: Expressiveness comparison between use case specifcation languages Use case information RUCM [3] UC-B [10] MBD-L [4] SelabReq [16] RSL [17] USL (c1) Overview elements I N F N N F (c1) Flows of use case I I F N N F (c1) Use case scenarios N N N F F N (c2) Control fows I N F N F F (c2) Concurrent actions N N N N N F (c3) Action types I N F F F F (c4) Use case scenario’s pre-and postcondition I F F N I F (c4) Guard conditions I F F N I F (c4) Action’s pre-and postcondition N F N N N F We will discuss in detail the results shown in the table in the frst fve subsections that follow. In the last subsection, we discuss the possibility of applying USL in practice. 6.3.1 Template-based representation of use case descriptions As discussed in Sect. 4, USL enables us to cap­ture all the information elements of the use case de­scription template shown in Table 1. In particu­lar, the elements of overview information are described by the properties of the DescriptionInfo object in the model. The steps in a basic fow are rep­resented by FlowSteps (including ActorStep and SystemStep)and are connectedbyBasicFlowEdges and ControlNodes. Similarly, steps in an alter­nate fow are represented by FlowSteps (including ActorStep and SystemStep)and are connected by ControlNodes and AlternateFlowEdges. USL represents this template precisely using the corresponding USL meta-concepts. Briefy, we draw the following con­clusions fromTable5: – USL is more expressive and more precise than three other languages, namely UC-B, SilabReq, and RSL. – USLis more precise thanRUCM. – USL is as expressive and precise as MBD-L. Specifcally, our USL is more expressive than UC-B, SilabReq, and RSL because of the following reasons. First, Figure 8: Modelling use case Session in the USL Editor tool. the use case information elements that are captured in USL are more formal than what are represented in UC-B. UC­B provides a GUI for informally describing use case sce­narios. Second, UC-B only represents the steps of a use case scenario and the trigger of a use case. SilabReq and RSL only capture fows corresponding to use case scenar­ios.With USL, we canexpress more use case information, such as the pre-and postcondition of an action. On the other hand, USL captures information elements asexpressively asRUCM. TheRUCM method proposesa Restricted Use Case Modeling (RUCM) language, using a setofkeywords and restricted description rules. Specifca­tionsinUSLaremoreformalthanthoseinRUCM, because RUCM’s specifcations are expressed in natural language. In comparison with MBD-L, USL lacks concepts for specifying sub-fows. However, as discussed in Sect. 2, use cases containing sub-fows can be smoothed so that theyare suitable for modelling in USL. On the other hand, MBD-L is only specifed with the abstract syntax. Unlike USL, it does not contain a concrete syntax and a formal semantic. 6.3.2 Control fowrepresentationfor use case behaviour Our USL language is built on UML activity diagram. A USL model includes USLNodes (corresponding to Nodes in UML activity diagram) and FlowEdges (correspond­ing to Edges in UML activity diagram) to specify con­trol fows which pass through steps in the use case’s fows. USL captures the different control fow types of UML ac­tivity diagram (such as sequence, branch, loop, and con­currence fow). In addition, USL also specifes steps witha limited number of iterations. For example, in the use case Session in SubSect.6.2,Step4 executesa maximumof three times. Briefy, we draw the following conclusions fromTable 5: – USL can represent concurrent steps, while the other lan­guages do not. – USL directly represents control fows using USLNodes and FlowEdges, while the other languages do not model the fows directly. Figure 9: Modelling use case withdrawal in the USL Editor tool. over, these works do not directly specify control fows. Theyonly capture rejoin points or refer to other steps. 6.3.3 Action specifcation As discussed in Sect. 4, USL precisely specifes use case behaviors using nine action types. These action types are represented by meta-concepts in the USL metamodel. The action type of eachbehavior enables us to identify sender objects, receiver objects, messages, parameters of actions and object types. Briefy, we draw the following conclu­sions fromTable5: – Action type coverage: – USL represents all the action types that are supported in other languages. – USL complements several action types, compared to four related languages, MBD-L, SiLabReq, RSL, and RUCM. USL employs two new action types IncludeAction and ExtendAction to repre­sent use case relationships. – Precise specifcation: – USL uses the USL meta-concepts to represent actions. – The actions in USL are precisely specifed using pre-and postconditions. Some languages, e.g., MBD-L, SiLabReq, and RSL also support this feature. Others, namely UC-B andRUCM,do not support it. We use more action types to classify behaviors and we capture the behavior’s information more precisely. More specifcally, by using different concepts in USL to spec­ify action types our approach captures behaviors more for­mally than UC-B. In UC-B, behaviors are not precisely specifed and are divided into different action types. Simi­larly, behaviors are better capturedin USL thaninRUCM, because the latter only useskeywords and restricted rules in natural language to divide behaviors into action types. Moreover,RUCM does not support the action type named SystemDisplay, that is captured in USL. In comparison with MBD-L, SiLabReq, and RSL, ac­tions in USL are better classifed with nine action types. MBD-L uses only four categories of action types: Re­quest, DataValidate, Expletive and Response. Similarly, SeLabReq divides actions into four groups: Actor pre­pares Data (APDExecuteSO),Actor calls System(ACSExe­cuteSO), System executes SystemOperation (SExecuteSO), and System replies and returns Result (SRExecutionSO). The classifcation method of RSL is less specifc than USL’s, because it does not support the type of system ac­tion that sends a request to a primary actor. This system action typeis specifedin USLby SystemRequest. 6.3.4 Constraint representation USL employs OCL to defne constraints in use case. Specifcally, a use case’s precondition is specifed by a Constraint associated with the InitialNode. A use case scenario’s postcondition is specifed by a Constraint associated witha FinalNode of scenario. Similarly, guard conditions on fows and actions’ pre-and postconditions are captured by Constraint associated with FlowEdges and actions, respectively. Briefy, we draw the following conclusions fromTable5: – USL supports a more complete set of constraints than four other languages, namely RUCM, MBD-L, SiLabReq, and RSL. – Constraint representation in USL (using OCL) is more precisethantwoother languages,RUCMandRSL(these languages use natural language to write constraints). USL specifes more constraint types than four other lan-guage:RUCM, MBD-L, SiLabReq, and RSL. UnlikeUSL, these languages do not support actions’ pre-and postcon­dition. Moreover, USL is better than RUCM and RSL in terms of precision, because several languages, such as MBD-L, SiLabReq, and RSL, also support this feature. The other languages, UC-B andRUCM,do not support it. It is worth mentioning that constraints specifed in USL are quite similar to constraints in UC-B. In the latter, con­straints are specifed using Event-B’s mathematical lan­guage. However, this language is rather inconvenient and diffcult for non-technical stakeholders to understand. 6.3.5 Applying USL in practice It is possible to apply USL in practice for twomain reasons. First, as discussed in Sect. 5, use cases are precisely spec­ifed and represented in USL as models, which conform to a metamodel. This enables them to be automatically transformed into other software artifacts, such as textual use case descriptions, structural and behavioral models and test cases. These generated models are necessary artifacts in software development. Second, the USL tool realizes our USL approach as an Eclipse modeling project (DSL toolkit) [26]. This tool en­ables the modeler to visually create USL models and to in­tegrate these models into theexisting UML use case models and class model(the latter capturesthe domain conceptsof a system). Moreover, our DSL toolkit provides the meta-metamodel language MOF to build USL. It also enables the defnition of model transformation languages in order to realize the transformations discussed in Sect. 5. However, USL is not without limitations. The graphical concrete syntax of the language might be inconvenient for modelers who prefer writing use cases in the textual form. In order to accommodate for this, the USL tool would be extended with a textual editor, similar to one used in the RSL approach [17]. This textual editor would enable a modeler to specify use cases by entering descriptive sen­tences about actions in steps, constraints, and relations be­tween steps. The tool would then process these to create the corresponding USL model. 7 Related work We position our work in the intersection between use case-driven development [1] and model-driven develop­ment [18].Within this context,a use case modelis usually represented as a combination of a UML use case diagram and a textual description written in natural language. Such ause case specifcation tends to be ambiguous, unclear,and inconsistent. In order to precisely specify use cases several approaches as in [10], [4], [16], [17], [3] have been pro­posed. T.Yueet al. [3] proposed a use case modeling language called Restricted Use Case Modeling (RUCM), which is composedofa use case description template,a setofkey-word, and a set of well-defned restrictions for a restricted natural languageto specify use cases.However,theRUCM is semi-formal textual language and it does not mention some important information such as concurrent actions, the pre-and postcondition of actions. Hence, in other work that use RUCM to express use case specifcations to automatically generate other artifacts, they have to use NLP(Natural Language Processing) techniquetoextractin­formation.For example, C.Wang et al. [30] uses use case specifcationsexpressedinRUCMin orderto generate test cases. AfteruseNLP techniquetoextracttest scenariosand constraints described in natural language, they use OCL to precisely specify constraints and use these precise specif­cations to automatically generate test data. R. Murali et al. [10] proposed using a mathematical lan­guage w.r.t. Event-B in order to formalize the pre-and postcondition of triggers and actions within use case fows. However, other descriptions of a use case are still infor­mal. Their proposition only focus automatically generates acorresponding Event-B model that is then amenable to the Rodin verifcation tools that enable system-level properties to be verifed. M. Misbhauddin et al. [4] extended the metamodel of UML use case models in order to capture both the structural and behavioural aspectsof use cases.To specifya use case, theydevelopeda prototypetool called UCDest. However, concurrent actions, pre-and postcondition of actions have not been mentioned. Moreover, action types are defned inadequately. D. Savic´et al. [16] and M. Smialek et al. [17] proposed the DSLs named SilabReq and RSL in order to capture use cases as the functional requirements models. The DSLs only focus on fows describing use case scenarios while other description information of use case is omitted. In ad­dition, the RSL does not defne distinguish actions insert­ing an extending use case and an included use case, both are defned action. Furthermore, the DSLs do not mention concurrent actions, pre and postcondition of actions. In comparison with all thework above,We provide for USLa formal semantic which useLTS toexpress, while other works lack a formal semantics. Our previous work in [36, 9] proposed a metamodel to specifyuse cases.Inthatworkwealsotriedtodefneapre­cise semantics for use cases based on graph transformation. Ourworkhere continuesitbyenhancingtheuse case meta-modelas wellas proposinganewLTS-based techniquein order to characterize the operational semantics of use case. Furthermore, all above mentioned approaches still lack a method specifying use cases satisfying all relevant infor­mation of use cases including fows, steps, system actions, actor actions, control fows, relationships, and constraints on the use case and its fows. The USL language, introduced in this work, aims to cover all relevant information of a use case including both structural and behavioural aspect. Comparing to the cur-rentworksin literature,USL could obtainthe followingad-vantages: (1) to specify concurrent actions in fows; (2) to capture and represent nine action types in which there are the system action including another use case and the sys­tem action extending another use case that have not been mentioned in other research; (3) to present not only con­straints on the use case and its fowsbut pre-and postcon­dition of each action in fows; (4) to present control fows of steps within the use case. In addition, in this paper we also defned operational semantics of USL to specify dy­namic information when use case scenariosexecute. In that way, from USL models we could obtain software artifacts by transformations. 8 Conclusion This paper proposed a DSL named USL to specify use cases. A USL model can cover the relevant information of a use case description including fows, steps, system ac­tions, actor actions, relationships, control fows, and con-straints.Webuilt the abstract usinga metamodel together with wellformedness rules and the graphical concrete syn­tax of USL. Moreover, we defned precise semantic for the USLbymappingUSL modelstoLTSs.Wealsodeveloped a USL Editor to create the USL models visually. In ad­dition, we explained how USL models can be transformed to some software artifacts and developed a model transfor­mation program to automatically generate textual template-based use case descriptions. Moreover,weevaluated USL’s expressiveness. In the future work, we will focus on realizing transfor­mations from USL models in order to generate test cases as well as other software artifacts automatically. In addition, we will enrich the abstract syntax and enhance the concrete syntax of USL in order to support better for modelers. Acknowledgement We wish to thank the anonymous reviewers for their useful comments. References [1] I. Jacobson, Object-Oriented Software Engineering: AUse Case Driven Approach, AddisonWesleyLong-man Publishing Co., Inc., 2004. [2] OMG, “UML 2.5,” May 2005. [3]T.Yue, L.C. Briand, andY. Labiche,“Facilitating the Transition from Use Case Models to Analysis Mod­els: Approach and Experiments,”ACMTrans. Softw. Eng. Methodol., vol.22, no.1, pp.5:1–5:38, March 2013. [4] M. Misbhauddin and M. Alshayeb, “Extending the UML Use Case Metamodel with Behavioral Informa­tion to Facilitate Model Analysis and Interchange,” Software&Systems Modeling,vol.14, no.2,May. [5] P. Kruchten, The Rational Unifed Process: An Intro-duction,3ed., Addison-WesleyProfessional, 2004. [6] D. Liu, K. Subramaniam, B.H. Far, and A. Eber-lein,“AutomatingTransitionfrom Use-CasestoClass Model,” Proc. Canadian Conf. Electrical and Com­puter Engineering. Toward a Caring and Humane Technology (Cat. No.03CH37436)(CCECE), 2003. [7] P. Haumer, “Use case-based software development,” in Scenarios, Stories, Use Cases: Through the Sys­tems Development Life-Cycle, ed. I. Alexander and N. Maiden, ch. 12, pp.237–264,Wiley, 2004. [8] S. Tiwari and A. Gupta, “A Systematic Literature Review of Use Case Specifcations Research,” Inf. Softw.Technol.,vol.67, no.C. [9] D.H. Dang, “Triple Graph Grammars and OCL for Validating System Behavior,” Proc. 4th Int. Conf. Graph Transformations (ICGT), LNCS 5214, pp.481–483, Springer, 2008. [10] R. Murali, A. Ireland, and G. Grov, “UC-B: Use Case Modelling with Event-B,” Proc. 5th Int. Conf. Ab­stract State Machines, Alloy, B, TLA, VDM, and Z(ABZ), ed. M. Butler, K.D. Schewe, A. Mashkoor, and M. Biro, LNCS 9675, Springer, 2016. [11] W. Grieskamp and M. Lepper, “Using Use Cases in ExecutableZ,” Proc. 3th Int. Conf.Formal Engineer­ing Methods (ICFEM), pp.111–119, IEEE, 2000. [12] J.S. Thakur and A. Gupta, “Automatic Generation of Sequence Diagram from Use Case Specifcation,” Proc. 7th India Conf. Software Engineering (ISEC), pp.20:1–20:6,ACM, 2014. [13] L. Li, “Translating Use Cases to Sequence Dia­grams,” Proc. 15th Int. Conf. Automated Software Engineering (ASE), pp.293–298, IEEE Computer So­ciety, 2000. [14] J.M. Almendros-Jiménez and L. Iribarne, “Describ­ing Use Cases with Activity Charts,” Proc. Int. Conf. Metainformatics (MIS 2Generation of System Test Cases from Use Case Specifcations,”004), LNCS 3511, pp.141–159, Springer-Verlag, 2005. [15] S.Tiwari and A. Gupta, “An Approach of Generat­ing Test Requirements for Agile Software Develop­ment,” Proc. 8th on India Conf. Software Engineering (ISEC),ACM, 2015. [16] D.Savi´c,S. Vlaji´c,S. Lazarevi´c,I. Antovi´c,V. Stano­jevi´c, and A.R. da Silva, “Use Case Speci- c, M. Mili´fcation Using the SILABREQ Domain Specifc Lan­guage,” Computing and Informatics, vol.34, no.4, pp.877–910, Feb. 2016. [17]M. SmialekandW.Nowakowski,From Requirements to Java in a Snap: Model-Driven Requirements Engi­neering in Practice, Springer. [18] M. Brambilla, J. Cabot, and M. Wimmer, Model-Driven Software Engineering in Practice, 1st ed., Morgan&Claypool Publishers, 2012. [19] OMG, “OCL 2.0,” May 2006. [20] R.M. Keller, “Formal verifcation of parallel pro­grams,” Commun. ACM, vol.19, no.7, pp.371–384, July 1976. [21] M.H. Chu, D.H. Dang, N.B. Nguyen, M.D. Le, and T.H. Nguyen, “USL: Towards Precise Specifcation of Use Cases for Model-Driven Development,” Proc. 8th Int. Conf. Information and CommunicationTech­nology (SoICT), pp.401–408, 2017. [22] A. Cockburn, Writing Effective Use Cases, 1 edi­tion ed., Addison-WesleyProfessional, Boston, Oct. 2000. [23] I. Jacobson, I. Spence, and K. Bittner, USE-CASE 2.0 The Guide to Succeeding with Use Cases, Ivar Jacobson International SA., 2011. [24] M. Giese and R. Heldal, “From Informal toFormal Specifcations in UML,” Proc. Int. Conf. The Unifed Modeling Language: Modelling Languages and Ap­plications(UML),ed.T.Baar,A. Strohmeier,A.M.D. Moreira, and S.J. Mellor, LNCS 3273, 2004. [25] P. Schmitt, I. Tonin, C. Wonnemann, E. Jenn, S. Leriche, and J.J. Hunt, “A Case Study of Speci­fcation and Verifcation Using JML in an Avionics Application,” [26] R.C. Gronback, Eclipse Modeling Project: A Domain-Specifc Language (DSL) Toolkit, 1 edi­tion ed., Addison-Wesley Professional, Boston, March 2009. [27] J. Heumann, “Generating Test Cases From Use Cases,” tech. rep., Rational Software, 2001. [28] s. results and B. Legeard, Practical Model-Based Testing: A Tools Approach, 1 edition ed., Morgan Kaufmann, Amsterdam;Boston, Dec. 2006. [29] W. Linzhang, Y. Jiesong, Y. Xiaofeng, H. Jun, L. Xuandong, and Z. Guoliang, “Generating Test Cases from UML Activity Diagram Based on Gray-Box Method,” Proc. 11th Asia-Pacifc Conf. Soft­ware Engineering (APSEC), IEEE Computer Society, 2004. [30] C. Wang, F. Pastore, A. Goknil, L. Briand, and Z.Iqbal,“Automatic GenerationofSystemTestCases from Use Case Specifcations,” Proc. Int. Sympo­sium Conf. SoftwareTesting and Analysis (ISSTA), pp.385–396,ACM, 2015. [31] “Generating Test Data from OCL Constraints with SearchTechniques,” vol.39. [32] B. Regnell, M. Andersson, and J. Bergstrand, “A Hierarchical Use Case Model with Graphical Rep­resentation,” Proc. IEEE Symposium andWorkshop on Engineering of Computer-Based Systems (ECBS), pp.270–277, IEEE Computer Society, 1996. [33] G. Kotonya and I. Sommerville, Requirements En­gineering: Processes andTechniques, 1sted.,Wiley Publishing, 1998. [34] M. Genero Bocco, A. Durán Toro, and B. Bernárdez Jiménez, “Empirical Evaluation and Review of a Metrics-Based Approach for Use CaseVerifcation,” Journal of Research and Practice in InformationTechnology,vol.36, no.4, pp.247–258, 2004. [35] Russell C. Bjork, “An Example of Object-Oriented Design: An ATM Simulation.” http://www.math-cs.gordon.edu/ courses/cs211/ATMExample/. Accessed: 2018-01-01. [36] D.H. Dang, A.H.Truong, and M. Gogolla, “Check­ing the Conformance between Models Based on Sce­nario Synchronization,” Journal of Universal Com­puter Science, vol.16, no.17, pp.2293–2312, 2010.