Formalizing the use case model: A model-based approach

In general, requirements expressed in natural language are the first step in the software development process and are documented in the form of use cases. These requirements can be specified formally using some precise mathematical notation (e.g. Linear Temporal Logic (LTL), Computational Tree Logic (CTL) etc.) or using some modeling formalism (e.g. a Kripke structure). The rigor involved in writing formal requirements requires extra time and effort, which is not feasible in several software development scenarios. A number of existing approaches are able to transform informal software requirements to formal specifications. However, most of these approaches require additional skills like understanding of specification languages additional artifacts, or services of domain expert(s). Consequently, an automated approach is required to reduce the overhead of effort for converting informal requirements to formal specifications. This work introduces an approach that takes a use case model as input in the proposed template and produces a Kripke structure and LTL specifications as output. The proposed approach also considers the common use case relationships (i.e., include and extend). The generated Kripke structure model of the software allows analysis of software behavior early at the requirements specification stage which otherwise would not be possible before the design stage of the software development process. The generated LTL formal specifications can be used against a formal model like a Kripke structure generated during the software development process for verification purpose. We demonstrate the working of the proposed approach by a SIM vending machine example, where the use cases of this system are inputs in the proposed template and the corresponding Kripke structure and LTL formal specifications are produced as final output. Additionally, we use the NuSMV tool to verify the generated LTL specifications against the Kripke structure model of the software, which reports no counterexamples thus validating the proposed approach.


Introduction
Precise, consistent and verifiable software requirements are more useful for software verification and validation activities than ambiguous, inconsistent and unverifiable software a1111111111 a1111111111 a1111111111 a1111111111 a1111111111 requirements written in a natural language. These features of software requirements are mainly dependent on the selected requirements specification approach [1]. Informal software specification is quite flexible due to the use of natural language. However, natural language requirements are prone to errors and ambiguities. Consequently, the much needed characteristics of a software specification, i.e., clarity and correctness can get compromised. Moreover, it reduces the chances for providing regular and predictable support services which are usually required after the deployment of a software [2]. In contrast, when these requirements are formally specified, they ensure a higher degree of consistency, reliability and extendibility. These specifications, due to their well defined syntax and semantics are unambiguous. However, formal specifications are highly demanding in terms of time and effort [3]. The required additional time and cost, may not be feasible in all development scenarios. This creates space for the development of an approach that can transform informal software requirements into formal software requirements.
In the literature, a number of approaches can be found that transform informal software requirements to formal requirements. For example, approaches proposed by Somé et al. [4], Kalnins et al. [5] and Scandurra et al. [6]. These approaches require software requirements written in natural language and transform these to corresponding requirements in a formal language. Though these approaches perform well but they have different types of limitations, for example some of these depend upon domain specific ontology [7], others require expertise in supporting skills like formation of domain diagram, activity diagram, interaction diagram or class diagram [8]. In addition to these limitations, some of the approaches either use Restricted Use Case Modeling (RUCM) [9], or Use case Specification Language (USL) [10] that requires understanding and usage of pre-defined syntax rules. Besides, these approaches lack the capability to handle the use case relationships, i.e., include and extend relationships which are useful for re-usability. Moreover, approaches proposed by Somé et al. [4], Kalnins et al. [5], Scandurra et al. [6] and Yue et al. [9] and Chu et al. [10] perform transformation at model level. A major limitation of model level transformation is that it is not a general purpose transformation and works only for some selected configurations. This limitation was addressed by proposing a meta-model based transformation mechanism. The distinctive characteristics of this setup lie in its capability to handle all possible features of the source model [11].
Realizing the importance of transformation and effects of overheads involved in the existing transformation approaches, this work proposes an approach that transforms use case descriptions into corresponding Kripke structure and LTL formal specifications. This approach requires to document the use case description(s) in the proposed template in a natural language. This approach also handles the commonly used use case relationships, i.e., include and extend relationship. It performs the transformation at meta-model level. Both generated LTL formal specifications and Kripke structure can be used as input to model checkers like NuSMV [12], SPIN [13] and SAL [14]. However, model checking is not a direct subject of the current study; instead, the focus is on formalization of use case description. The major contributions of this paper are: meta-models for use case and Kripke structure and an approach to transform use case description into a Kripke structure at meta-model level and use case to LTL specifications directly.
The proposed meta-models for use case and Kripke structure as well as the proposed approach are discussed in the proposed approach section, use case model and the generated Kripke structure along with the generated LTL formal specifications for SIM vending machine example are presented in the example section. Related work section discusses the existing state-of-the-art approaches in this context. Finally, the conclusion section concludes the work.

Proposed approach
This paper presents an approach to transform use case description(s) to a Kripke structure and LTL formal specifications. The use case description(s) is(are) required to be specified in the proposed use case template using a natural language. The proposed template requires to specify a use case description using a set of keywords along with the distinct listing of software input and output symbols. These input and output symbols are identified at the requirements elicitation stage. To make the proposed approach suitable for model-driven object-oriented paradigm, meta-models for use case description and Kripke structure have been defined. Along with these meta-models, transformation rules that transform a use case description to a Kripke structure and LTL formal specifications are also defined. A user can use either of these as an input to the model checkers like NuSMV, SPIN and SAL to verify the software behavior at an early stage of software development process which otherwise would not be possible before the design phase of the software development process. Fig 1 shows a

Use case meta-model
Generally, a use case template is required for writing a use case description. There are a number of available use case templates. Examples of popular use case templates include the templates proposed by Cockburn [15], Ivar Jacobson [2], RUP [16], Duran [17], Leite [18] etc. These available use case templates contain some common features like use case name, actor name, success scenario and alternate scenario. But to the best of our knowledge, UML does not recommend any template as a standard template. This allows to propose a new use case template, if required.
As discussed earlier, there are multiple available use case templates, but none of these lists input and output symbols of the software explicitly. Moreover, available templates list alternate scenario(s) in a separate section. This makes it difficult to proceed for the transformation process as the transformation process must repeatedly scan the use case description back and forth to track the possible flow of the use case. To overcome these difficulties and to make the transformation process simple, we propose a use case template that lists the input and output symbols explicitly. Furthermore, it enlists the alternate scenario(s) along with the normal scenario.
Furthermore, the use case relationships are used to reuse a use case to make the system more operable. This makes a use case more flexible to write in a more customized format. Zaman et al. [19] proposed a use case template that is closer to our requirements of writing a use description. However, this template does not handle use case relationships, i.e., include and extend. In addition, their proposed template requires the lengthofBitVector, BitVector and binary values for output symbols. These requirements make this template difficult to use by a common user. The proposed template in this work does not require the user to calculate lengthofBitVecor, BitVector and corresponding binary values for output symbols. In addition, this template also handles use case relationships. An include relationship allows to include another use case whereas, the extend relationship extends a use case functionality on some specified interaction. As an example, consider the case of a software that allows a user to choose a payment option by selecting to pay using a credit card or to pay by cash on delivery. This software also requires the user to re-login when finalizing the payment option. Use case relationships facilitate to specify this scenario.Pay by card or pay by cash on delivery use cases can be extended and the requirement to re-login can be documented by including the login use case.
A specimen of the proposed use case template is given in Fig 2. The proposed template consists of a set of keywords including UseCase:, ActorSet:, Input-Set:, OutputSet:, Scenario, Alternate_Scenario:, End_of_AlternateScenario, Continue, Include, Extend, Condition and End_of_Usecase.
The use case name is required to be unique in a software and is recorded with the keyword UseCase:. Software's actor(s) is(are) labeled with the keyword ActorSet:. This template allows to record input and output symbols explicitly. It enlists the possible input with a keyword InputSet:. For example, a user's credentials may be valid or invalid. In this case, the InputSet: will have valid_credentials and invalid_credentials. Each use case is required to have an Input-Set:. The output set is denoted by OutputSet: keyword and contains the possible output values for this output symbol, e.g., a system can display a successful login message or invalid login attempt, depending on the provided credentials to the software by a user. In this case, the Out-putSet: with a label login message contains successful_login_message and invalid_login_attempt. Other possible OutputSet: may have output symbols like file_uploaded_successfully and inva-lid_file_upload_attempt with a label file notification message. The proposed approach is flexible and does not place any limitation on the number of OutputSet: and output symbols. It dynamically fulfills the contextual requirements.
An actor's interaction with a software is listed under the keyword Scenario and a possible alternate scenario is with the keyword Alternate_Scenario. An alternate scenario can be concluded in two ways either with Continue or End_of_AlternateScenario keyword. An alternate scenario ended with End_of_AlternateScenario keyword represents an interaction with the software which results in halting the execution and switching to the position from where the alternate scenario started whereas, the Continue keyword marks the end of alternate scenario where a software continues to repeat its operation unless a valid input is provided. The keyword End_of_Usecase is used to mark the end of a use case. The keywords Include and Extend are used to specify the use case relationships namely include and extend respectively and require a valid use case name. There is another keyword Condition that specifies the user interaction with the software when an extending use case extends the specified use case.
A context free grammar has been defined for the proposed use case template using Extended Backus-Naur Form (EBNF) notation Fig 3. To ensure syntactical correctness of the input use case, a parser has been developed. Fig lists the context free grammar. An id is defined as a string of alphabets and _. This id can be used to define Ucname, inputsymbol, output's label, Outputvalue, Userline and Systemline. A Ucname is used with UseCase: to specify the name of a use case. In addition, it is also used to specify the name of use case being included or extended. The use case being included is specified with Include, whereas the use case being extended is specified with Extend along with Condition. The actors of a use case are listed with ActorSet: keyword. The input symbols of a use case can be specified by InputSet:. The output symbols are listed with OutputSet along with its possible values. The Scenario: lists the user action line(s) and system action line(s). The scenario is ended with End_of_Usecase. All the possible alternate scenarios are listed with Alternate_Scenario. It lists the alternate user line(s) and system line(s). An alternate scenario can be ended either by End_of_AlternateScenario or Continue.
A use case containing Include or Extend is flattened by Use Case Flattener process and it is listed as Rule 1. This process accepts a use case description, read its scenario line by line for the  UseCase is the main element that includes ActorSet, InputSet, OutputSet and the Scenario-Line. UseCase element has a data member name to store use case name. ActorSet includes Actor element(s) with a data element name to store the value of an actor. The true strength of meta-model can be used if it carries its relationships with multiple objects of the same structure. For this matter mutual cardinality of objects is taken into account. There is one to one cardinality between UseCase and ActorSet, whereas the cardinality between ActorSet and Actor elements is one to many. UseCase can only have one InputSet and there can be more than one InputSymbol elements in an InputSet. There can be multiple OutputSet in a UseCase to contain the possible output symbols with their respective values. OutputSymbol element in an OutputSet is value. ScenarioLine element in a UseCase element is used to represent use case scenario lines. A UseCase element can have multiple ScenarioLine elements. ScenarioLine element has its specialized forms including ActorActionLine, SystemActionLine, AlternateScenar-ioLine, EndUseCaseLine, EndAlternateScenarioLine, ContinueLine, ExtensionPointLine and EndExtensionPointLine. ActorActionLine element represents a use case scenario line where an actor's interaction with the system and SystemActionLine element is used to represent a software response to an actor. AlternateScenarioLine element lists the start of an alternate scenario and EndAlternateScenarioLine to mark the end of alternate scenario. The end of an alternate scenario can also be marked by a ContinueLine element. ExtensionPointLine element is used to mark the scenario lines of a use case being extended and EndExtensionLine is used to mark the end of the scenario lines of the use case being extended. EndUsecaseLine is used to mark the end of use case.
The use case meta-model can be described as: . ., n, represents the i th instance of use case meta-model. name i is a use case model name. ActorSet i = {Actor 1 , Actor 2 , . . ., Actor p } and p 2 N.
The variable k is a positive integer and it is used to represent the number of OutputSet in the i th instance of use case meta-model and OutputSet = {label, OutputSymbol 1 , OutputSymbol 2 , . . ., OutputSymbol s } where s 2 N and the label records the textual output e.g. login message. OutputSymbol = {value. The element value denotes the textual value of output symbol e.g. successful_login_message or invalid_login_attempt.
Kripke structure meta-model A Kripke structure [21] is a formal notation and is a five-tuple hQ, S, δ, q 0 , λi where • Q is a finite set of states, • S is a finite set of input symbols, The AP are atomic propositions describing some property of a system over a particular state. An extension of a Kripke structure is proposed by Meinke et al. [22] to use it as a multibit Moore machine with states labeled by Boolean bitvector that makes it useful for test case generation of reactive systems by Learning-based Testing (LBT). The Kripke structure used for this purpose is defined as: • Q is a finite set of states, • S is a finite set of input symbols, • δ:Q×S! Q is a transition function.
• q 0 2 Q is the initial state, • λ: Q ! B k is a labeling function and (b 1 ,. . .,b k ) 2 B k , a Boolean bitvector, is an indexing of a set AP of k atomic propositions.
Model checkers like NuSMV [12], SPIN [13] and SAL [14] take a Kripke structure as input model for formal verification of software behavior. Fraser et al. [23] used a Kripke structure model to generate test cases for white box testing by exploiting structural properties of the software code using a Kripke structure model and in [24], [22] and [25], authors used specification based black box testing by learning Kripke structure models of the system under test. The model transformation process requires a meta-model of a Kripke structure. To the best of our knowledge, there is no existing meta-model definition for a Kripke structure. However, metamodel for a state machine exists in the literature [26]. In this study, we use the definition of Kripke structure as in [22]. A meta-model for the reformulated Kripke structure has been defined and is shown in Fig 5.
KripkeStructure element has a StateSet element which contains a start state and other states of a Kripke structure. A State element has a name element and a BitLabel to store the bitvector of the state. Its value is represented by Bit elements. Each Bit element can have a possible true or false value. A KripkeStructure element has an InputSet element that consists of multiple InputSymbol elements. The InputSymbol element has a name. A KripkeStructure element can have multiple Transition elements that represent the transitions of a Kripke structure. A Transition element is defined by a from and end state of State type and a transition symbol of type InputSymbol.
The Kripke structure meta-model can be represented as: The element Transition = {q fromstate , q tostate , InputSymbol}. A Kripke structure can have multiple transitions. The designed meta-model is implemented using EMF [20].

Use case to Kripke structure transformation process
In model to model transformation, a model of a meta-model can be transformed to a model of another meta-model. This transformation can be automated if the transformation rules are expressed in some transformation language. Epsilon Transformation Language (ETL) is one such language [27]. It is is a hybrid model to model and rule based transformation language. It is built on top of the Epsilon model management platform that allows to perform multiple model management tasks including update in place, model to model and model to text transformation. ETL can transform many input models to many output models. Fig 6 shows the transformation process of a use case model to a Kripke structure model. A use case description UC is provided as an input model to this transformation process. The transformation process consists of nine rules to handle the provided use case description and to generate the resultant Kripke structure model KS. We will briefly discuss these rules in the following paragraphs. We abstracted some of the implementation details to make these rules more readable.
Rule 1 copies the UC.InputSet to KS.InputSet and also calculates the bitvectorlength value. In addition, it also generates random binary values for OutputSymbol in OutputSet.
Rule 1 Calculate binary values, bitvectorlength and copy input symbols  Rule 5 describes the computation steps that are performed when a scenario line ℓ of type UC.AlternateScenarioLine is read. A temporary state q hold is defined and the value of q current is copied to it. Moreover, a new state q n ew is created. The value of q current .BitLabel is copied to BitLabel temp . The value of BitLabel temp is updated with the binary value of last output symbol read. The updated BitLabel temp is assigned to q new .BitLable. This rule also defines a transition from the state q current to the newly created state q nes and is labeled with the value of σ temp . This transition is added to the KS.Transition. Transitions for the all input symbols other that σ temp are defined from q current and dead state and are also added to KS. Rule 9 processed a scenario line of type UC.EndExtensionPointLine and defines a new transition from q current to q beforeExtenstion is defined and it is labeled withe σ temp . The value of q current is assigned with the value of q beforeExtension and the flag bit isExtentionPoint set to false. The scenario line of type UC.EndUsecaseLine does not produce any impact on the transformation process.
Rule 9 Process a use case line of type End Extension Point  (ip+os(op)+ac)), where n denotes the number of scenario lines, ip denotes the number of input symbols, os denotes the number of output set, op denotes the number output symbols in an os and ac denotes the number of actors in the use case description of the use case provided as an input to this process.

Use case to LTL transformation process
The use case description, described in the proposed template, is also used to produce LTL formal specifications. LTL formal specifications are built using LTL formulas. LTL formulas are built from finite sets of atomic propositions, the logical operators and the temporal operators. The temporal operators include: • Next operator, represented by the symbol � or X • Eventually operator, represented by the symbol � or F • Globally operator, represented by the symbol □ or G • Until operator, represented by the symbol U Formal semantics of LTL operators can be described with the help of Kripke structure. Let K be a Kripke structure and a path ρ = hq 0 , q 1 ,.:., q n i corresponding to a word ω = σ 0 , σ 1 , . . ., σ m 2 S ω is a sequence such as 8i � 0: q i+1 = δ(q i , σ i ) and q 0 is the initial state. The set Paths(K, q 0 ) denotes all paths in K, where q 0 is the initial state of K. If we consider ϕ and ψ as two syntactically well formed LTL formulas then semantics of LTL operators over path ρ can be described as: The scenario lines of a use case description specify either an actor's interaction with the software using an input symbol or system's interaction with the actor using an output symbol. The input symbol is specified with the input identifier in the produced LTL formal specifications. Each of the specified OutputSet has a label and it is used to specify a particular output. The OutputSymbol in OutputSet holds the possible value for this output. In the start of a use case scenario, all of the OutputSet have a null value and this is marked as the Initial_State in the generated LTL formal specifications. The state is specified in the LTL formal specifications by state. LTL formal specifications are generated from a use case description by LTLNextSpeci-ficationGenerator process and LTLFutureSpecificationGenerator process and these are described by Rule 1 and Rule 2 respectively. The block diagram of Use Case to LTL Transformation process is shown in Fig 7. Rule 1 produces LTL formal specifications using the LTL next operator. It initializes the OutputLabel with all the specified OutputSet label's value to null. It, then, scans all scenario lines one by one for the occurrence of actor, input symbol and output symbol. If any of these is found in the line being read then it enables the corresponding flag isActor, isInput and isOutput to true. It stores the read input symbol to InputSymbol read . The read output symbol is stored to OutuputSymbol read and the value of corresponding label in OuputLabel is updated with the value of OutuputSymbol read . The value of OutputLabel is stored in OutputLabel beforeExtension on reading the Extension_Point line and is reassigned to OutputLabel on reading the End_Extension_Point line. Whereas, the value of OutputLabel is stored in OutputLabel beforeAlternate and it is reassigned to OutputLabel on reading the Continue line or End_of_AlternateScenario line. An LTL formula identified with an identifier Formula current is defined by using the values of OutputLabel, InputSymbol read and the value of OutputSymbol read . A keyword LTLSPEC is added in the start of Formula current to make it appropriate for model checking using NuSMV model checker. The generated LTL formula identified as Formula current is added to LTL formulas and is the final output of this process. Rule 2 enlists the process to generate the LTL formulas using LTL future operator. It initializes the Input future value to null in the start of the process. It scans all scenario lines one by one for the occurrence of actor, input symbol or output symbol. If any of these is read in the line being read then it enables the corresponding flag isActor, isInput and isOutput to true. It stores the read output symbol to OutputSymbol read . When an input symbol is read, the value of Input future is assigned to Input beforefuture . The value of Input future is then concatenated with X where X represents the LTL next operator and the read input symbol with a label input in the generated LTL formula.
Rule 2 LTL future specification generator process if Counter input = 0 then 6: Counter input ++ 7: Input future "(input =" + inputsymbol + ")" 8: else 9: Input beforefuture Input future 10: Input future Input future + "& X (input =" + inputsymbol + ")" 11: The value of Input future is stored in Input beforeExtension on reading the UC.ExtensionPointLine and is reassigned to Input future when the UC.EndExtenstionPointLine is read. Whereas, on reading the UC.AlternateScenarioLine, the value of Input future is stored in Input beforeAlternate and the value of Input future is updated with the value of Input beforefuture . While, on reading the UC. ContinueLine or UC.EndAlternateScenarioLine the value of Input future is updated with the value of Input beforeAlternate . The LTL formula identified by the Formula current identifier is produced by using the values of state, Input future and OutputSymbol read . A keyword LTLSPEC is added in the start of Formula current to make it appropriate for model checking using NuSMV model checker. The generated Formula current is added to LTL formulas.
The time complexity of Rule 1 and Rule 2 is O(n(ip+os (op)+ac)) where n denotes the number of scenario lines, ip denotes the number of input symbols, os denotes the number of Out-putSet, op denotes the number of output symbols in an os. The variable ac denotes the number of actors in a use case description.

Soundness of the proposed approach
The proposed approach consists of two transformation processes i.e. Use Case to Kripke Structure Transformation and Use Case to LTL Transformation. In the following paragraphs, we will discuss the soundness of these processes.
Soundness of use case to Kripke structure transformation process. This process produces a Kripke structure from the provided use case. The generated Kripke structure is well formed and deterministic in nature. Initially this process defines an initial state s 0 and a dead state d 0 . These states are added to the states of the generated Kripke structure. All the generated states are labeled with unique bitvector of same length. All the input symbols are unique. The generated Kripke structure is deterministic. This process defines a unique initial state. There is only one transition defined for the read input symbol and the transitions for the remaining input symbols are defined and mapped to d 0 .
Soundness of use case to LTL transformation process. This process generates LTL formulas from given use case. A context free grammar has been defined using Extended Backus-Naur Form (EBNF) to verify the well formedness of the generated LTL formulas. The grammar is as follows: Binaryopr = "U" | "R" | "−>" | "&" | "|" | "=" | "!=". Atomicprop = "("Ltlform")" | Unaryopr Ltlform | "TRUE" | "FALSE" | id. Unaryopr = "X" | "G" | "F" | "!". The generated LTL formulas for the examples have been parsed against this grammar and no error was found. Count of the generated LTL formulas is dependent on the number output symbols of given use case. Whereas, complexity of LTL formulas is dependent on number of input symbols, system action lines and AlternateScenario lines of the use case.
A process is called complete in terms of its ability to generate Kripke structure and LTL formulas from all use case constructs provided in the proposed template.
Completeness of use case to Kripke structure transformation process. The use case constructs include input symbols, output symbols, user action line, actor action line, Alterna-teScenario and EndAlternateScenario lines. The include and extend constructs are handled by Use Case Flattener process. This process replaces these to ExtensionPoint and EndExtenstion-Point lines. This process handles all use case constructs proposed in use case template. Rule 1 handles input symbols and output symbols of input use case. Rule 2 handles user action and system action lines.

Example
The proposed approach has been used to transform use case descriptions of a number of examples which can be retrieved from UCKSLTL weblink [28]. We select Subscriber Identification Module (SIM) vending machine example to show the working of proposed approach in this paper. A SIM vending machine, works as a kiosk. It facilitates its user to check for a registered SIM, purchase a new SIM, view balance history and update call plan after adding a Computerized National Identification Card (CNIC) number. The use case description for SIM vending machine is shown in Fig 8. The use case diagram for this is shown in Fig 9. The proposed approach requires to add use case description of the included and extended use cases descriptions in the use case description of the use case including or extending them. This addition is also performed by the tool. However, the use case description after addition of the use case descriptions being included and extended is shown in Fig 10 to provide the reader an insight into this artifact.
The corresponding Kripke structure instance is shown in Fig 11. The exceptional behavior of system being developed is mapped to a dead state. In the generated Kripke structure, the dead state and the transitions mapping to it are not shown to make this figure readable.
A set of LTL formal specifications is generated by this approach for SIM vending machine example. Some of the generated LTL formulas are listed here: The software displays a valid card message to the user if the user provides a valid CNIC to the software at the initial state. The software displays the list of registered SIMs to the user if the user asks the software to provide the number of registered SIM after the provision of valid CNIC to the software.
A user will get the list of registered SIMs from the software by providing a valid CNIC and asking the software to provide number of registered SIM as input.
A user will get the information of SIM current plan after providing a valid CNIC, number of registered SIM and SIM plan as input to the software.
The approach presented in this paper transforms a use case description into corresponding Kripke structure and LTL formal specifications. Two different approaches are used in this study: one is to generate a Kripke structure from a use case description and the other one produces LTL formal specifications from the same use case description. Both of the generated formalism correspond to the same software and can be used by a model checker like NuSMV as an input for the validation purposes. For the validation purpose the generated Kripke structure and the LTL formal specifications were provided to the NuSMV tool. Upon execution NuSMV did not generate any counterexample. This validates the generated kripke structure and LTL formal specifications. This approach is domain independent and requires software requirements artifact, in the proposed template, for the transformation process. Whereas the other available approaches require additional artifacts like domain model, sequence diagram, interaction diagram, activity diagram or business rules definition along with the software requirements artifact for the transformation process. The user of this approach also does not require the skills to specify the software requirements artifact in some specialized specification language.

Scalability of the proposed approach
In this section, we present some preliminary results to assess the scalability of the proposed approach for larger case studies. The ATM cash withdrawn example, the SIM vending machine example and two other case studies have been used for scalability analysis of the proposed approach. The time complexity and the execution time of the proposed transformation process depend on the following four parameters of the input use case: (a) number of actors (b) number of input symbols (c) number output symbols and (d) number of scenario lines. However, in our case studies, there is only one actor in each use case. The experiments have been performed on an Intel Core2 Duo P8600 machine with 8 GB RAM, running 64-bit Microsoft Windows 7 Professional operating system. The transformation process for the example and each case study have been executed 500 times and a mean execution time has been computed to eliminate slight variance due to operating system processes and threads scheduled at a specific time. Table 1 lists the execution times against the selected input parameters, as well as the number of states and transitions of the generated Kripke structure for each case study. is not linear, it is increasing slightly more rapidly. This observation is consistent with the time complexity formula given in Use Case to Kripke Structure Transformation Process sub-section which shows that the worst-case time complexity is quadratic. Another aspect of scalability relates to the size of generated Kripke structure. The last two columns of Table 1 show the

Related work
In this section, we review the approaches that transform use case description into corresponding formal notations. Somé et al. [4] propose to generate a state transition graph from a use case description and a domain model of a software. The domain model evolves with the maturity of the software development process. In addition, the generated transition graph does not consider the outputs of the software. This reduces the use of this generated transition graph for basic level of verification activities. Moreover, this also requires the additional efforts to reformulate a transition graph with the evolution of the domain model.
Kalnins et al. [5] generate a multi-layered model from a use case description. The use case description in the case of Kalnins et al. is required to be expressed in Requirements Specification Language (RSL) [30]. This use case description along with the UML activity and interaction diagrams are used to produce an architectural model. The generated architectural model includes application logic, business logic and data access layers. These layers are populated with UML component, interface, dependency, class and package instances. This approach is also supported by a tool. Though Kalnins et al. make a significant contribution but Smialek et al. [31] comprehend the usage of RSL with manual annotation of noun, verb, subject and predicate in a use case description. Their approach generates a sequence diagram from this annotated software requirements expressed using RSL. This approach requires manual efforts for the labeling process. Furthermore, the obtained precision is not scalable for supporting large scale industrial projects. Software validation plays an equally important role that is why it needs to be considered duly. Unfortunately, the approach presented by Smialek et al. [31] does not consider this aspect. Whereas, Scandurra et al. [6] proceed by prioritizing the validation aspect. The authors used RUCM framework for achieving this objective and eventually Scandurra et al. provided corresponding abstract state machine. The same framework of RUCM has also been used by another group of researchers Yue et al. [9] but the difference is that Yue et al. apply restricted rules and UCMeta for constructing sentences needed for use case description. The achievement of the authors primarily revolves around the transformation of use case description into the target domain and activity diagrams. Though the authors along with the utility of aToucan [32] contributed in simplifying the whole setup. However, this approach requires comparatively higher degree of expertise for documenting the use case description using RUCM. It seems impractical for a common user to practice this approach which discourages its integration into related areas of research.
Zaman et al. [19] transform a use case description into a Kripke structure. This approach requires the specification of use case description in a proposed template. This template requires the calculation of corresponding binary values for the output symbols of the software. Moreover, this approach does not handle the use case relationships.
Singh et al. [33] propose a technique that requires the creation of UML class and sequence diagrams prior to the formal transformation. After forming of these two artifacts they are able to formalize the static and dynamic views of a software in Z language. A software static view is extracted from a use case description with the support of a class diagram. Whereas, the software dynamic view is generated from the sequence diagrams. UML class and sequence diagrams are built during the design stage of the software development process. A correction at this stage of the development process is much expensive and also requires reformation of other software development artifacts.
A use case can describe only a single functionality offered in a software. Whereas, a software constitutes a number of functionalities. The above discussed approaches do not consider the software level constraints. Software level constraints can be defined with the help of Object Constraint Language (OCL) [34] and is used by Chu et al. [10] for formal transformation. They have used USL to document a use case description. The pre-and post-conditions of use case description are required to be expressed in OCL. This use case description along with UML class diagram is used to build a Labeled Transition System (LTS) [35] by using defined domain meta concepts and utility functions. This approach is expensive in terms of writing pre-and post-conditions of a use case in OCL, specifying use case description in terms of domain meta concepts and analytical skills to build a class diagram. The generated labeled transition system seems not to be aligned with the formal system due to absence of initial and final states in its formal setup that requires an explicit initial state to start its computation.
The approaches discussed so far focus on architectural arrangements of a software and ignore the software's business environment as well its constraints. This aspect has been considered by researchers and a number of approaches have been proposed to formalize informal requirements. Business environment of a software influence the design and working of a software. These can be represented by using business rules and domain ontology and are used by the following approaches for the formal transformation of informal software requirements.
Selway et al. [36], use General Architecture for Text Engineering (GATE) to process business rules expressed in a controlled natural language to generate the preliminary Semantics of Business Vocabulary and Business Rules (SBVR) model [37] with the assistance of a domain expert. The limitation of this model lies in its continuous and unconditional reliance over the domain expert and its limited vocabulary.
Li et al. [3] further investigated process of informal to formal requirements transformation but with the slight difference of using the Web Ontology Language (OWL) in the transformation process. This approach is limited in impact due to its nature of being domain specific. Consequently, it requires consistent additional efforts for the description of object, rules and relations.
The aforementioned discussed approaches transform informal specifications to formal specifications. Most of these approaches depend on the usage of a restricted natural language like RSL or RUCM, prior to the transformation process. The disadvantage of limited vocabulary and restricted rules compromise inherent features of simplicity and ease of use. Other approaches require the understanding and expertise in constraint languages like OCL are expensive as these constraints are defined on artifacts other than the requirements document. A number of approaches require the formation of artifacts like domain, sequence, interaction and activity diagrams. These diagrams are built later in the design stage of the software development process. Any correction at this stage is expensive and require the reformation of these artifacts prior to the re-transformation process. The approaches to transform informal requirements in the light of software business environment are domain specific and are based on the definition of business objects and their relations. Such domain specific approaches require the services of a domain expert for the realistic definition of business environment.
Considering the identified limitations including understanding of specialized languages, requirement of additional skill set, formation of other software development artifacts and definition of software environment, there is a need for an approach that allows to specify the software requirements in natural language, using requirements stage artifacts and is domain independent.
A comparison of the proposed approach with the existing approaches based on required input, generated output, required additional artifacts and additional skills to practice the approach is analyzed. This analysis is provided in Table 2.
It can be observed from Table 2 that most of these approaches require additional artifacts like domain model, sequence diagram, activity diagram and interaction diagram along with use case description prior to the transformation process. These diagrams are created at the design stage of the software development process. It can also be seen that some of these approaches require use case description specification in some specialized specification language like USL, RUCM or RSL. This aspect adds additional requirement for a user of these approaches. A number of these approaches are domain specific and require continuous support of domain expert for domain concepts definition. In comparison to these approaches, the proposed approach requires the software artifact itself specified in the proposed template using natural language. This template is simple enough and requires from the user to identify software inputs and outputs, those are defined at requirements elicitation stage.
The objective of this study is to generate a Kripke structure and LTL formal specifications. For this purpose, only those attributes of a use case description are considered which are useful for the target formalism and these attributes are common in other existing use case templates. In proposed approach, additional attributes of use case description like pre-/post-condition, trigger, etc. are not considered as they do not contribute in the transformation process.

Conclusion
In this paper, we proposed an approach that transforms informal software requirements, specified as use cases, to corresponding formal requirements, i.e., LTL formal specification and a Kripke structure. The proposed approach handles use case relationships including include and extend which allows the proposed approach to transform a use case model instead of a single use case description. Moreover, this approach performs transformation at meta-model level. The user of this approach does not require any additional skills like understanding of constraint language, e.g., OCL or specialized natural language specification languages like RUCM or USL. The approach does not require any additional artifacts like domain model, sequence diagram, activity diagram, interaction diagram or business rules definition. An example of SIM vending machine is used to demonstrate this approach. The generated formal specifications, i.e., LTL formal specifications and a Kripke structure are validated using the NuSMV model checker which produces no counterexamples.
In future, the presented approach can be extended to make it compatible with the other existing use case templates.

Formal analysis: Qamar uz Zaman.
Investigation: Qamar uz Zaman. Architectural model The generated architectural diagram is semi-formal artifact and it cannot be used for the model checking purposes. In addition, the required activity and interaction diagrams along with a use case description are design phase artifacts. The correction cost at the design phase is relatively high than the correction cost at the requirements analysis phase. Moreover, the user of this approach requires the specification skills using RSL language.

Use Case Description
Abstract state machine The user of this approach requires the specification skills using RUCM framework. Moreover, the generated abstract machine requires to add more details of the system to make it suitable for the verification and validation purposes.