use case diagram research paper

Click through the PLOS taxonomy to find articles in your field.

For more information about PLOS Subject Areas, click here .

Loading metrics

Open Access

Peer-reviewed

Research Article

Formalizing the use case model: A model-based approach

Contributed equally to this work with: Qamar uz Zaman, Aamer Nadeem, Muddassar Azam Sindhu

Roles Conceptualization, Formal analysis, Investigation, Methodology, Software, Writing – original draft

* E-mail: [email protected]

Affiliation Department of Computer Science, Capital University of Science and Technology (CUST), Islamabad, Pakistan

Roles Supervision, Validation, Writing – review & editing

Roles Conceptualization, Supervision, Validation, Writing – review & editing

Affiliation Department of Computer Science, Quaid-i-Azam University, Islamabad, Pakistan

• Qamar uz Zaman, 
• Aamer Nadeem, 
• Muddassar Azam Sindhu

• Published: April 20, 2020
• https://doi.org/10.1371/journal.pone.0231534
• Reader Comments

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.

Citation: Zaman Qu, Nadeem A, Sindhu MA (2020) Formalizing the use case model: A model-based approach. PLoS ONE 15(4): e0231534. https://doi.org/10.1371/journal.pone.0231534

Editor: Alejandro F. Villaverde, Consejo Superior de Investigaciones Cientificas (CSIC), SPAIN

Received: August 19, 2019; Accepted: March 25, 2020; Published: April 20, 2020

Copyright: © 2020 Zaman et al. This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Data Availability: The prototype tool and the examples files are published on Harvard Dataverse Network repository and can be accessed using link https://doi.org/10.7910/DVN/S9HQYD .

Funding: The author(s) received no specific funding for this work.

Competing interests: The authors have declared that no competing interests exist.

Introduction

Precise, consistent and verifiable software requirements are more useful for software verification and validation activities than ambiguous, inconsistent and unverifiable software 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 schematic diagram of the proposed approach.

• PPT PowerPoint slide
• PNG larger image
• TIFF original image

https://doi.org/10.1371/journal.pone.0231534.g001

The user populates an instance of the use case model. This populated use case instance is processed by Use Case to Kripke Structure Transformation Process and a Kripke structure is generated as an output. Use Case to LTL Transformation Process generates LTL formal specifications(LTL formulas) from the use case description provided as an input. The proposed meta-models for use case description and Kripke structure along with Use Case to Kripke Structure Transformation Process and Use Case to LTL Transformation Process are discussed in the following sub-sections.

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 .

https://doi.org/10.1371/journal.pone.0231534.g002

The proposed template consists of a set of keywords including UseCase :, ActorSet :, InputSet :, 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 InputSet :. 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 OutputSet : 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 invalid_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 .

https://doi.org/10.1371/journal.pone.0231534.g003

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 occurrence of Include or Extend . If any of these is found it calls Use Case Includer or Use Case Extender rules accordingly.

Rule 1 Use Case Flattener

Require : UC as a use case description in the proposed template

Ensure : UC flattened as a use case description in the proposed template

1: Define UC temp , UC flattened . ActorSet ← UC . ActorSet , UC flattened . InputSet ← UC . InputSet , UC flattened . OutputSet ← UC . OutputSet

2: for ℓ in UC . Scenario do

3:   if ℓ contains Include then

4:    UC temp ← Ucname

5:    UC flattened ← IncludeUseCase( UC flattened , UC temp )

6:   else if ℓ contains Extend then

7:    UC temp ← Ucname

8:    UC flattened ← ExtendUseCase( UC flattened , UC temp ,Userline)

10:    UC flattened . Scenario ← UC flattened . Scenario + ℓ

11:   end if

12: end for

Rule 2 Use Case Includer

Require : UC flattened , UC included as use case descriptions in the proposed template

1: UC flattened . ActorSet ← UC flattened . ActorSet ∪ UC included . ActorSet

2: UC flattened . InputSet ← UC flattened . InputSet ∪ UC included . InputSet

3: UC flattened . OutputSet ← UCflattened . OutputSet ∪ UC included . OutputSet

4: UC flattened . Scenario ← UC flattened . Scenario + UC included . Scenario

Rule 3 Use Case Extender

Require : UC flattened , UC extended as use case descriptions in the proposed template, Userline as scenario line

1: UC flattened . ActorSet ← UC flattened . ActorSet ∪ UC extended . ActorSet

2: UC flattened . InputSet ← UC flattened . InputSet ∪ UC extended . InputSet

3: UC flattened . OutputSet ← UCflattened . OutputSet ∪ UC extended . OutputSet

4: UC flattened . Scenario ← UC flattened . Scenario + Extension _ Point + Userline

5: UC flattened . Scenario ← UC flattened . Scenario + UC extended . Scenario + End _ Extension _ Point

Rule 2 takes UC flattened and UC included use case descriptions. It combines ActorSet , InputSet and OutputSet of both use case descriptions. Moreover, this process appends scenario lines of UC included to the scenario lines of UC flattened .

Rule 3 accepts UC flattened and UC extended use case descriptions. It combines ActorSet , InputSet and OutputSet of both use case descriptions. This process then append Extension_Point , Userline and scenario lines of UC extended use case description to the the UC flattened scenario lines. This process ends by appending End_Extension_Point to the UC flattened scenario. A meta-model for this flattened use case is defined and it is shown in Fig 4 .

https://doi.org/10.1371/journal.pone.0231534.g004

UseCase is the main element that includes ActorSet , InputSet , OutputSet and the ScenarioLine . 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 , AlternateScenarioLine , 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:

UseCase metamodel = 〈 name i , ActorSet i , InputSet i , ( k × OutputSet ) i , ( j × ScenarioLine ) i 〉. where i = 1, …, 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 ∈ N .

InputSet i = { InputSymbol 1 , InputSymbol 2 , …, InputSymbol q } where q ∈ N and InputSymbol ś value is stored in name.

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 ∈ 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 .

The variable j ∈ N denotes the number of scenario lines in the i th instance of use case meta-model. The ScenarioLine = { ActorActionLine , SystemActionLine , AlternateScenarioLine , EndAlternateScenarioLine ContinueLine , ExtensionPointLine , EndExtensionPointLine , EndUseCaseLine }. The proposed meta-model is implemented in Eclipse Modeling Framework (EMF) [ 20 ].

Kripke structure meta-model

A Kripke structure [ 21 ] is a formal notation and is a five-tuple 〈 Q , Σ, δ , q 0 , λ〉 where

• Q is a finite set of states,
• Σ is a finite set of input symbols,
• δ : Q ×Σ → Q is a transition function,
• q 0 ∈ Q is the initial state,
• λ: Q →2 AP is a labeling function

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 multi-bit 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 ×Σ→ Q is a transition function.

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, meta-model 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 .

https://doi.org/10.1371/journal.pone.0231534.g005

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:

KripkeStructure metamodel = 〈 StateSet i , InputSet i , ( z × Transition ) i 〉 where i = 1,…, n denotes the i th instance of Kripke structure meta-model.

The element StateSet i = { q initiali , q 1 , q 2 , …, q l } where l ∈ N .

The initial state q initiali = { name = Initial_State and BitLabel } where BitLabel = Bit 1 , …, Bit lengthofbitvector and Bit = { false }.

The state q = { name , BitLabel } where BitLabel = Bit 1 , …, Bit lengthofbitvector and Bit = { true , false }

The element InputSet i = { InputSymbol 1 , InputSymbol 2 , …, InputSymbol m } where m ∈ N and InputSymbol = name.

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.

https://doi.org/10.1371/journal.pone.0231534.g006

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

1: ucOPSet Binary : new UseCase ! OutputSet , bitvectorlength ← 0, InputSet temp : new KripkeStructure ! InputSet

2: for UC . OutputSet do

3:   count output ← outputOutputSet . OutputSymbol . count

4:   bit req ← RequiredBits count output ; bitvectorlength += bit req

5:   for OutputSymbol do

6:    ucOPSet Binary . value ← OutputSymbol . value

7:    ucOPSet Binary . binaryvalue ← random binary value

8:   end for

10: for UC . InputSet . InputSymbol do

11:   InputSet temp . InputSymbol . name ← UC . InputSet . InputSymbol . name

13: KS . Inputset = InputSet temp

14: KS . bitvectorlength ← bitvectorlength

Rule 2 defines state dead , KS . State . InitialState and q c urrent states. It also initializes the KS . State . InitialState and state dead BitLable ’s indices to false . In addition, it set q c urrent value to KS . State . InitialState .

Rule 2 Define Initial and Dead states

1: BitLabel temp : new KS . BitLable , state dead , q current : new KS . State

2: for BitLabel temp do

3:   BitLabel temp . Bit . val ← false

5: KS . State . InitialState . BitLabel ← BitLabel temp

6: state dead ← BitLabel temp

7: q current ← KS . State . InitialState

Rule 3 reads a scenario line at a time and tracks the occurrence of actor, input and output symbols. On their occurrence it sets the value of flag bits isActor , isInput and isOutput accordingly. It also tracks the values of last read input symbol to σ temp and output symbol to output temp .

Rule 3 Scan a scenario line for the occurrence of Actor, Input and Output Symbols

1: for UC . ScenarioLine do

2:   for UC . InputSet do

3:    if ℓ contains σ then

4:     isInput ← true , σ temp ← InputSymbol . name

5:    end if

6:   end for

7:   for UC . ActorSet do

8:    if ℓ contains Actor then

9:     isActor ← true

10:    end if

11:   end for

12:   for UC . OutputSet do

13:    for OutputSymbol do

14:     if ℓ contains OutputSymbol then

15:      output temp ← OutputSymbol . value

16:     end if

17:    end for

18:   end for

19: end for ‘

Rule 4 defines a new state q new on the occurrence of a actor and input symbol in a scenario line. It defines BitLabel temp with the value of qcurrent . The value of BitLabel temp is updated by the Bit Label Updater process. It updates the corresponding indices for the BitLabel temp with the corresponding binary value of output temp . The updated output temp value is then assigned to q new . BitLablel . The newly created state q new is then added to KS.State . A transition from qcurrent and q new is defined and is labeled with the value of σ temp . This newly created transition is added to the KS.Transition . Transitions for the UC . InputSet other than σ temp are also defined from q current and state dead . These transitions are also added to KS . Transition . The value of q current is updated with the value of q new .

Rule 4 Define a new state and transitions

1: if isInput AND isActor then

2:   isInput ← false , isActor ← false

3:  Define q new , BitLabel temp ← q current . BitLabel

4:   BitLabel temp ← BitLabelUpdater ( output temp , ucOPSet Binary , BitLabel temp )

5:   q new . BitLabel ← BitLabel temp

6:   KS . State . add ( q new )

7:   if isExtensionPoint then

8:    KS . Transition .add( q beforeExtension , q new , σ temp )

10:    KS . Transition .add( q current , q new , σ temp )

12:   for UC . InputSet — σ temp do

13:    KS . Transitio .add( q current , state dead , σ )

14:   end for

15:   q current ← q new

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 . Transition .

Rule 5 Process a use case line of type Alternate Scenario

1: if ℓ .typeOf( UC . AlternateScenarioLine ) then

2:   q hold ← q current

3:  Define q new , BitLabel temp ← q current .BitLabel

5:   q new .BitLabel ← BitLabel temp

6:   KS . State .add( q new )

7:   KS . Transition .add( q current , q new , σ temp )

8:   for UC . InputSet — σ temp do

9:    KS . Transition .add( q current , state dead , σ )

10:   end for

11:   q current ← q new

Rule 6 defines a new transition from q current to q current and is labeled with σ temp , when a scenario line of type UC . ContinueLine is read. The value of q current is also updated with the value of q hold .

Rule 6 Process a use case line of type Continue

1: if ℓ .typeOf( UC . ContinueLine ) then

2:   KS . Transition . add ( q current , q current , σ temp )

3:   q current ← q hold

Rule 7 defines a transition form q current to KS . State . InitialState on reading a line of type UC . EndAlternateScenarioLine and this transition is labeled with value of σ temp . The value of q current is updated with the value of q hold .

Rule 7 Process a use case line of type End Alternate Scenario

1: if ℓ .typeOf( UC . EndAlternateScenarioLine ) then

2:   KS . Transition .add( q current , KS . States . InititalState , σ temp )

Rule 8 processes a scenario line of type UC . ExtensionPointLine that results in the definition of a new state q beforExtension . The calue of state q current is copied to the state q beforExtension and a flag isExtensionPoint is marked to true .

Rule 8 Process a use case line of type Extension Point

1: if ℓ .typeOf( UC . ExtensionPointLine ) then

2:   isExtensionPoint ← true

3:   q beforeExtenstion ← q current

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

1: if ℓ .typeOf( UC . EndExtensionPointLine ) then

2:   KS . Transition .add( q current , q beforeExtension , σ temp )

3:   q current ← q beforeExtenstion

4:   isExtensionPoint ← false

The time complexity for Use Case to Kripke Structure Transformation process is calculated and it 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 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 ρ = 〈q 0 , q 1 ,.:., q n 〉 corresponding to a word ω = σ 0 , σ 1 , …, σ m ∈ Σ ω is a sequence such as ∀ i ≥ 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:

• X ϕ : K , ρ ⊨ X ϕ ≡ K , ρ 1 ⊨ ϕ

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 LTLNextSpecificationGenerator 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 .

https://doi.org/10.1371/journal.pone.0231534.g007

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 1 LTL next specification generator process

  isInput ← false , isActor ← false , isOutput ← false

 String OutputLabel , OutputLabel beforeExtension , OutputLabel beforeAlternate ,

  InputSymbol read , OutputSymbol read , Formula current

1: for set in UC . OutputSet do

2:   set . OutputSymbols ← set . OutputSymbols + null

3:   OutputLabel ← OutputLabel + set . Label + “= null”

5: for ℓ in UC . ScenarioLine do

6:   for inputsymbol in UC . InputSet then

7:    if ℓ contains inputsymbol then

8:     isInput ← true

9:     InputSymbol read ← inputsymbol

12:   for set in UC . OutputSet do

13:    for outputsymbol in set do

14:     if ℓ contains outputSymbol then

15:      isOutput ← true

16:      OutputSymbol read ← outputsymbol

17:      for set available in UC . OutputSet do

18:       if set . Label = set available then

19:       Update OutputLabel . set . Label ← OutputSymbol read

20:       end if

21:      end for

22:     end if

23:    end for

24:   end for

25:   for actor in UC . ActorSet do

26:    if ℓ contains actor do

27:     isActor ← true

28:    end if

29:   end for

30:   if ℓ .typeof( UC . ExtensionPointLine ) then

31:    OutputLabel beforeExtension ← OutputLabel

32:   end if

33:   if ℓ .typeof( UC . EndExtensionPointLine ) then

34:    OutputLabel ← OutputLabel beforeExtension

35:   end if

36:   if ℓ .typeof( UC . AlternateScenarioLine ) then

37:    isAlternate ← true

38:    OutputLabel beforeAlternate ← OutputLabel

39:   end if

40:   if ℓ .typeof( UC . ContinueLine ) OR ℓ .typeof(“UC.EndAlternateScenarioLine”) then

41:    isAlternate ← false

42:    OutputLabel ← OutputLabel beforeAlternate

43:   end if

44:   if isActor AND isInput AND isOutput then

45:    if all OutputSet . Label . value = null then

46:     Formula current ← “LTLSPEC G (state = Initial_State & input =” + InputSymbol read + “− > X (” + OutputSymbol read + “)”

47:    else

48:     Formula current = “LTLSPEC G (” OutputLabel + “& input =” + InputSymbol read + “−> X (” + OutputSymbol read + “)”

49:    end if

50:   end if

51:  LTL formulas = LTL formulas + Formula current

52:   isActor ← false , isOutput ← false

53: end for

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

 boolean isInput ← false , isActor ← false , isOutput ← false

 String Input future , Input beforefuture , Input beforeExtension , Input beforeAlternate ,

  OutputSymbol read , Formula current

  Counter input ← 0, isFirstWritten ← false , isAlternate ← false

1: for ℓ in UC . ScenarioLine do

2:   for inputsymbol in UC . InputSet do

3:    if ℓ contains inputsymbol

4:     isInput ← true

5:     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:     end if

12:    end if

13:   end for

14:   for set in UC . OutputSet do

15:    for outputsymbol in set do

16:     if ℓ contains outputSymbol then

17:      isOutput ← true

18:      OutputSymbol read ← outputsymbol

19:     end if

20:    end for

21:   end for

22:   for actor in UC . ActorSet do

23:    if ℓ contains actor then

24:     isActor ← true

25:    end if

26:   end for

27:   if ℓ .typeof( UC . ExtensionPointLine ) then

28:    Input beforeExtension ← Input future

29:   end if

30:   if ℓ .typeof( UC . EndExtensionPointLine ) then

31:    Input future ← Input beforeExtension

33:   if ℓ .typeof( UC . AlternateScenarioLine ) then

34:    isAlternate ← true

35:    Input beforeAlternate ← Input future

36:    Input future ← Input beforefuture

37:   end if

38:   if ℓ .typeof( UC . ContinueLine ) OR ℓ .typeof( UC . EndAlternateScenarioLine ) then

39:    isAlternate ← false

40:    Input future ← Input beforeAlternate

41:   end if

42:   if isActor AND isInput AND isOutput then

43:    Formula current ← “LTLSPEC G (state = Initial_State &” + Input future + “−> F (” + OutputSymbol read + “)”

44:   end if

45:  LTL formulas ← LTL formulas + Formula current

46:   isActor ← false , isOutput ← false

47: end for

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 OutputSet , 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:

• Ltlstart = “ LTLSPEC ” Ltlform {“ LTLSPEC ” Ltlform }.
• Ltlform = Atomicprop { Binaryopr Atomicprop }.
• Binaryopr = “ U ” | “ R ” | “−>” | “&” | “|” | “=” | “!=”.
• Atomicprop = “(” Ltlform “)” | Unaryopr Ltlform | “ TRUE ” | “ FALSE ” | id .
• Unaryopr = “ X ” | “ G ” | “ F ” | “!”.
• id = alpha { alpha }.
• alpha = ‘ a ’‥‘ z ’ + ‘ A ’‥‘ Z ’ + ‘_’.

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, AlternateScenario and EndAlternateScenario lines. The include and extend constructs are handled by Use Case Flattener process. This process replaces these to ExtensionPoint and EndExtenstionPoint 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. Rule 5 handles AlternateScenario line and Rule 6 handles Continue line. In addition to theses, Rule 7 handles EndAlternateScenario line. Whereas, ExtensionPoint and EndExtensionPoint lines are handled by Rule 8 and Rule 9 respectively.

Completeness of use case to LTL transformation process.

This process consists of two rules and both rules handle all use case constructs. The use case constructs are treated in different contexts for the generation of LTL formulas by Rule 1 and Rule 2. Input symbols are handled by lines 6-11 of Rule 1 and lines 2-13 of Rule 2. Whereas, output symbols are handled by lines 1-4, 12-24 of Rule 1 and lines 14-21 of Rule2. ExtensionPoint and EndExtensionPoint lines are handled by lines 30-35 of Rule 1 and lines 27-32 of Rule 2. AlternateScenario line is handled by lines 36-39 of Rule 1 and lines 33-37 of Rule 2. Continue and EndAlternateScenario are handled by lines 40-43 of Rule 1 and lines 38-41 of Rule 2.

Tool support

The proposed approach is implemented in the Use Case to Kripke Structure and LTL formulas generator tool (UCKSLTL) [ 28 ]. This tool takes a use case in the proposed template as an input and produces the resultant Kripke structure along with LTL specifications. The generated Kripke structure is presented in . dot , . gml , . png and . smv formats. The tool uses GraphViz API [ 29 ] to draw the generated Kripke structure. This tool verifies the syntactical structure of a use case against the proposed template. These features simplifies the user task to document a use case description and the transformation process.

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 .

https://doi.org/10.1371/journal.pone.0231534.g008

https://doi.org/10.1371/journal.pone.0231534.g009

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.

https://doi.org/10.1371/journal.pone.0231534.g010

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.

https://doi.org/10.1371/journal.pone.0231534.g011

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:

• LTLSPEC G ( state = Initial_State & input = valid_CNIC → X ( cardMessage = valid_card_message ))

The software displays a valid card message to the user if the user provides a valid CNIC to the software at the initial state.

• LTLSPEC G ( cardMessage = valid_card_message & checkSIMMessage = null & purchaseSIMOptionMessage = null & amountMessage = null & thumbMessage = null & issueSIMMessage = null & balanceHistoryMessage = null & changePlanMessage = null & input = number_of_registered_SIMs → X ( checkSIMMessage = list_of_registered_SIMs ))

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.

• LTLSPEC G ( state = Initial_State & ( input = valid_CNIC ) & X ( input = number_of_registered_SIMs ) → F ( checkSIMMessage = list_of_registered_SIMs ))

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.

• LTLSPEC G ( state = Initial_State & ( input = valid_CNIC ) & X ( input = number_of_registered_SIMs ) & X ( input = change_plan_option ) → F ( changePlanMessage = SIM_current_plan ))

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. Fig 12 shows a growth in time required (as given by time complexity formula) against the use case description parameters. The values of use case description parameters have been normalized in the range 0 to 1. The values of use case parameters are on the x-axis and the values of time complexity are on the y-axis of the graph. Likewise Fig 13 shows the relationship between use case parameters and the actual execution time. The values of use case parameters are on the x-axis and the values of execution times on the y-axis of the graph. The graph shown in Fig 12 reflects an increase in the time complexity values as the values of use case parameters increase. It can be seen from both figures that the growth in time requirement 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 numbers of states and transitions of the generated Kripke structure. Figs 14 and 15 show growth in the number of states and transitions, respectively, against the use case parameters. The values of use case parameters have been normalized before plotting these graphs. Both graphs show linear growth in the size of generated Kripke structure against the size of input use case.

https://doi.org/10.1371/journal.pone.0231534.g012

https://doi.org/10.1371/journal.pone.0231534.g013

https://doi.org/10.1371/journal.pone.0231534.g014

https://doi.org/10.1371/journal.pone.0231534.g015

https://doi.org/10.1371/journal.pone.0231534.t001

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 .

https://doi.org/10.1371/journal.pone.0231534.t002

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.

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.

• View Article
• Google Scholar
• 2. Jacobson I. Object-Oriented Software Engineering: A Use Case Driven Approach. Redwood City, CA, USA: Addison Wesley Longman Publishing Co., Inc.; 2004.
• 3. Li FL, Horkoff J, Borgida A, Guizzardi G, Liu L, Mylopoulos J. From stakeholder requirements to formal specifications through refinement. In: International Working Conference on Requirements Engineering: Foundation for Software Quality. Springer; 2015. p. 164–180.
• 6. Scandurra P, Arnoldi A, Yue T, Dolci M. Functional requirements validation by transforming use case models into Abstract State Machines. In: Proceedings of the 27th Annual ACM Symposium on Applied Computing. ACM; 2012. p. 1063–1068.
• 8. Graham I, O’Callaghan A, Wills AC. Object-oriented methods: principles & practice. vol. 6. Addison-Wesley Harlow, UK; 2001.
• 9. Yue T, Briand LC, Labiche Y. An automated approach to transform use cases into activity diagrams. In: European Conference on Modelling Foundations and Applications. Springer; 2010. p. 337–353.
• 10. Chu MH, Dang DH, Nguyen NB, Le MD, Nguyen TH. USL: Towards Precise Specification of Use Cases for Model-Driven Development. In: Proceedings of the Eighth International Symposium on Information and Communication Technology. ACM; 2017. p. 401–408.
• 11. Lemesle R. Transformation rules based on meta-modeling. In: Proceedings Second International Enterprise Distributed Object Computing (Cat. No. 98EX244). IEEE; 1998. p. 113–122.
• 14. De Moura L, Owre S, Rueß H, Rushby J, Shankar N, Sorea M, et al. SAL 2. In: International Conference on Computer Aided Verification. Springer; 2004. p. 496–500.
• 15. Adolph S, Cockburn A, Bramble P. Patterns for Effective Use Cases. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.; 2002.
• 16. Kruchten P. The Rational Unified Process: An Introduction. 3rd ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.; 2003.
• 19. Zaman Qu, Sindhu MA, Nadeem A. FORMALIZING A USE CASE TO A KRIPKE STRUCTURE. In: Proceedings of the IASTED International Symposium Software Engineering and Applications (SEA 2015); 2015.
• 20. Steinberg D, Budinsky F, Merks E, Paternostro M. EMF: eclipse modeling framework. Pearson Education; 2008.
• 22. Meinke K, Sindhu MA. LBTest: A Learning-Based Testing Tool for Reactive Systems. In: Software Testing, Verification and Validation (ICST), 2013 IEEE Sixth International Conference on; 2013. p. 447–454.
• 24. Meinke K, Sindhu MA. Incremental Learning-Based Testing for Reactive Systems. In: Gogolla M, Wolff B, editors. Tests and Proofs. vol. 6706 of Lecture Notes in Computer Science. Springer; 2011. p. 134–151.
• 25. Feng L, Lundmark S, Meinke K, Niu F, Sindhu MA, Wong PY. Case studies in learning-based testing. In: IFIP International Conference on Testing Software and Systems. Springer Berlin Heidelberg; 2013. p. 164–179.
• 27. Kolovos DS, Paige RF, Polack FA. The epsilon transformation language. In: International Conference on Theory and Practice of Model Transformations. Springer; 2008. p. 46–60.
• 28. Zaman Q, Nadeem A, Sindhu MA. Use Case to Kripke Structure and LTL Formulas Generator Tool (UCKSLTL); 2020. Available from: https://doi.org/10.7910/DVN/S9HQYD .
• 29. Ellson J, Gansner E, Koutsofios L, North SC, Woodhull G. Graphviz-open source graph drawing tools. In: International Symposium on Graph Drawing. Springer; 2001. p. 483–484.
• 30. Kaindl H, Smiałek M, Wagner P, Svetinovic D, Ambroziewicz A, Bojarski J, et al. Requirements specification language definition. Project Deliverable D2. 4.2, ReDSeeDS Project, 2009;.
• 31. Śmiałek M, Kalnins A, Kalnina E, Ambroziewicz A, Straszak T, Wolter K. Comprehensive system for systematic case-driven software reuse. In: International Conference on Current Trends in Theory and Practice of Computer Science. Springer; 2010. p. 697–708.
• 33. Singh M, Sharma A, Saxena R. Formal Transformation of UML Diagram: Use Case, Class, Sequence Diagram with Z Notation for Representing the Static and Dynamic Perspectives of System. In: Proceedings of International Conference on ICT for Sustainable Development. Springer; 2016. p. 25–38.
• 34. Richters M, Gogolla M. On formalizing the UML object constraint language OCL. In: International Conference on Conceptual Modeling. Springer; 1998. p. 449–464.
• 37. Bajwa IS, Lee MG, Bordbar B. SBVR Business Rules Generation from Natural Language Specification. In: AAAI spring symposium: AI for business agility; 2011. p. 2–8.

An Automated Approach to Transform Use Cases into Activity Diagrams

• Conference paper
• Cite this conference paper

• Tao Yue 20 , 21 ,
• Lionel C. Briand 21 &
• Yvan Labiche 20  

Part of the book series: Lecture Notes in Computer Science ((LNPSE,volume 6138))

Included in the following conference series:

• European Conference on Modelling Foundations and Applications

1265 Accesses

34 Citations

Use cases are commonly used to structure and document requirements while UML activity diagrams are often used to visualize and formalize use cases, for example to support automated test case generation. Therefore the automated support for the transition from use cases to activity diagrams would provide significant, practical help. Additionally, traceability could be established through automated transformation, which could then be used for instance to relate requirements to design decisions and test cases. In this paper, we propose an approach to automatically generate activity diagrams from use cases while establishing traceability links. Data flow information can also be generated and added to these activity diagrams. Our approach is implemented in a tool, which we used to perform five case studies. The results show that high quality activity diagrams can be generated. Our analysis also shows that our approach outperforms existing academic approaches and commercial tools.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Unable to display preview.  Download preview PDF.

IEEE Std. 830-1998, IEEE Standard for Software Requirement Specification (1998)

Google Scholar  

Berenbach, B., Inc, S.C.R., Princeton, N.J.: The evaluation of large, complex UML analysis and design models. ICSE (2004)

Bittner, K., Spence, I.: Use Case Modeling. Addison-Wesley, Boston (2002)

Brown, E.K., Miller, J.E.: Syntax: a linguistic introduction to sentence structure. Routledge (1992)

Bruegge, B., Dutoit, A.H.: Object-Oriented Software Engineering Using UML, Patterns, and Java. Prentice-Hall, Englewood Cliffs (2009)

CaseComplete: http://www.casecomplete.com/

Chen, T.Y., Tang, S.F., Poon, P.L., Tse, T.H.: Identification of categories and choices in activity diagrams. In: QSIC 2005, Citeseer, pp. 55-63 (2005)

Eclipse Foundation: Eclipse Modeling Framework

Fliedl, G., Kop, C., Mayr, H.C., Salbrechter, A., Vöhringer, J., Weber, G., Winkler, C.: Deriving static and dynamic concepts from software requirements using sophisticated tagging. Data Knowl. Eng. 61, 433–448 (2007)

Article   Google Scholar  

Fowler, M.: UML distilled: a brief guide to the standard object modeling language. Addison-Wesley, Reading (2003)

Gomaa, H.: Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison-Wesley, Reading (2000)

Gutiérrez, J.J., Clémentine, N., Escalona, M.J., Mejías, M., Ramos, I.M.: Visualization of Use Cases through Automatically Generated Activity Diagrams. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., Völter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 83–96. Springer, Heidelberg (2008)

Chapter   Google Scholar  

Ilieva, M.G., Ormandjieva, O.: Models Derived from Automatically Analyzed Textual User Requirements. Soft. Eng. Research, Management and Applications (2006)

Kermeta: Kermeta metaprogramming environment. Triskell team

Kruchten, P.: The Rational Unified Process: An Introduction. Addison-Wesley, Reading (2003)

Mustafiz, S., Kienzle, J., Vangheluwe, H.: Model transformation of dependability-focused requirements models. In: ICSE Workshop on Modeling in Software Engineering (2009)

Nebut, C., Fleurey, F., Le Traon, Y., Jezequel, J.M.: Automatic test generation: A use case driven approach. IEEE TSE 32, 140–155 (2006)

Olsen, G.K., Oldevik, J.: Scenarios of traceability in model to text transformations. ECMDA-FA. Haifa, Israel (2007)

OMG: UML 2.2 Superstructure Specification

RAVENFLOW: http://www.ravenflow.com/

The Stanford Natural Language Processing Group. The Stanford Parser version 1.6

Visual Paradigm for UML: http://www.visual-paradigm.com/product/vpuml/

Waheed, T., Iqbal, M.Z.Z., Malik, Z.I.: Data Flow Analysis of UML Action Semantics for Executable Models. ECMDA-FA (2008)

Yue, T., Briand, L.C., Labiche, Y.: A Use Case Modeling Approach to Facilitate the Transition Towards Analysis Models: Concepts and Empirical Evaluation. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 484–498. Springer, Heidelberg (2009)

Yue, T., Briand, L.C., Labiche, Y.: Automatically Deriving a UML Analysis Model from a Use Case Model. Carleton University (2009)

Yue, T., Briand, L.C., Labiche, Y.: A Systematic Review of Transformation Methodologies between User Requirements and Analysis Models. Carleton University (2009)

Yue, T., Briand, L.C., Labiche, Y.: An Automated Approach to Transform Use Cases into Activity Diagrams. Carleton University, Technical report SCE-10-01 (2010)

Download references

Author information

Authors and affiliations.

Software Quality Engineering Lab, Carleton University, 1125 Colonel By Drive, Ottawa, ON, K1S 5B6, Canada

Tao Yue & Yvan Labiche

Simula Research Laboratory, University of Oslo, P.O. Box 134, Lysaker, Norway

Tao Yue & Lionel C. Briand

You can also search for this author in PubMed   Google Scholar

Editor information

Editors and affiliations.

Victoria University, Wellington, New Zealand

Thomas Kühne

Malina Software Corporation, 10 Blueridge Court, K2J 2J3, Nepean, Ontario, Canada

Laboratoire d’Informatique de Paris 6, 8, rue du Capitaine Scott, P.O. Box, 75015, Paris, France

Marie-Pierre Gervais

CEA LIST, Gif-sur-Yvette, F-91191, France

François Terrier

Rights and permissions

Reprints and permissions

Copyright information

© 2010 Springer-Verlag Berlin Heidelberg

About this paper

Cite this paper.

Yue, T., Briand, L.C., Labiche, Y. (2010). An Automated Approach to Transform Use Cases into Activity Diagrams. In: Kühne, T., Selic, B., Gervais, MP., Terrier, F. (eds) Modelling Foundations and Applications. ECMFA 2010. Lecture Notes in Computer Science, vol 6138. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-13595-8_26

Download citation

DOI : https://doi.org/10.1007/978-3-642-13595-8_26

Publisher Name : Springer, Berlin, Heidelberg

Print ISBN : 978-3-642-13594-1

Online ISBN : 978-3-642-13595-8

eBook Packages : Computer Science Computer Science (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

Generating UML Use Case Models from Software Requirements Using Natural Language Processing

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

The Community

Modern analyst blog, community blog.

• Member Profiles

Networking Opportunities

Community spotlight, business analysis glossary, articles listing, business analyst humor, self assessment.

• Training Courses
• Organizations
• Resume Writing Tips
• Interview Questions

Let Us Help Your Business

Advertise with us, rss feeds & syndication, privacy policy.

From Research to Implementation: Use Case Diagrams – Usage and Benefits

Who is really using them?

What kind of projects are they being used on?

Why are people not using them?

How are people using them?

Are they providing any benefit?

Recent research can help Business Analysts answer these questions and provide recommendations for implementation.

The Who, What, Why and How of Use Case Diagrams [1]

The first research paper helps us answer the Who, What, Why, and How questions relating to the actual implementation of Use Case diagrams in the field. This study was conducted by the authors with full support of the Object Management Group (OMG). The authors created a web survey composed of 38 questions designed to inquire about UML usage, including Use Case diagrams. A total of 284 meaningful responses to the survey were collected and analyzed. The first meaningful piece of data to come out of this study indicated that 182 respondents utilize UML while 102 provided reasons why they were not using UML.

Who is really using Use Case diagrams?

The average practitioner has 15.1 years of IT experience, but they only have 4.7 years of UML experience. It is interesting to note that UML has been around for more that 12 years, but many experienced individuals still have a considerably low amount of time working on projects with UML. It is not really clear why there is such a low level of experience as the data showed no correlation between number of years of experience and UML diagram usage.

What kind of projects are Use Case Diagrams being used on?

Figure 1 shows us that UML diagrams are being used on non-trivial projects. Note that the average number of Use Cases per project is 88. This is a lot of information to convey, and it would seem beneficial to provide a Use Case Model that contains Use Case diagrams to help describe the behavior of a system this size. In addition, tools today provide the ability to map traceability between Use Cases and Classes to ensure the solution delivered is meeting the end goals of the user. Furthermore, as requirements change (as they often do), being able to know how many classes are affected by a change to a Use Case can provide invaluable information that relates directly to cost, scope and project planning.

Figure 1: Typical Project Size

Why are people not using Use Case diagrams?

Figure 2 shows the reasons given by respondents for not using Use Case diagrams (respondents were allowed to choose more than one answer, so total % is greater than 100). Looking at this data, there are a few areas that can be addressed easily and cheaply to alleviate the roadblock to Use Case diagram implementation.

Not well understood by analyst – This is easily solved with training or mentoring.

Insufficient value to justify cost – There is very little cost to creating Use Case diagrams when using commonly available corporate tools such as Microsoft Visio which adds no additional cost in tools. In addition, recent research has shown that Use Case diagrams do provide cognitive benefits (see next study, below).

Not useful with programmers – This, again, is easily solved with training or mentoring. In addition, Use Case diagrams provide the abstract view of system behavior which is the end goal of the programmers efforts.

Figure 2: Reasons for not using Use Case diagrams (% responses)

How are people using Use Case Diagrams?

The researchers asked the respondents to provide a rank (on a scale from 1-5) showing how they were using Use Case diagrams (and other UML diagrams) on projects. A review of Figure 3 shows some interesting numbers.

As would be expected, Client Validation has the highest score. However, it seems that the 2.90 score for Document for future maintenance and other enhancements is low. It appears that practitioners are not taking into account that enhancements, in particular, are not always performed by the personnel that originally created the system. Use Case diagrams are extremely useful in providing personnel, not familiar with the original system, a business context to understand. This may be a consequence of the diagram not being well understood by analysts.

The measures for Implement and Clarify, as defined, are expected as Use Case diagrams are not designed to provide detailed implementation detail for technical members of the project team.

Figure 3: Roles for Use Case Diagrams

Benefits of Use Case Diagrams [2]

Measuring the actual benefits of Use Case diagrams has only recently attracted the attention of researchers. As indicated above in Figure 2, 42% of respondents in the previous study indicated that there was “Insufficient value to justify cost, and a further 29% indicated that Use Case diagrams were “Not useful with clients”. Research published this year, however, shows that Use Case diagrams actually aid in the understanding of the use case narrative.

In this study, the researchers identify a process, Conceptual Modeling, that involves the analyst working with stakeholders to identify the initial ideas of the system, model those ideas, and use that Conceptual Model to have the stakeholders validate the requirements. Since Conceptual Modeling techniques often combine words with graphical symbols, the researchers applied the Cognitive Theory of Multimedia Learning (CTML). The CTML “suggests the most effective communication occurs when verbal and visual pathways are utilized simultaneously.”

49 upper-level business students, with no particular knowledge of object-oriented principles or UML, were randomly assigned to two groups. Each group was presented with a pre-test, five use cases (only one group included a Use Case diagram), tasks (measuring comprehension, retention and problem solving), and a post-test.

Retention and Problem solving measures increased by 22% and 20%, respectively, for the group that included a Use Case Diagram. The overall comprehension measure was unaffected. According to the authors: “These results suggest that diagrams, even simple diagrams such as the use case diagram provided in this experiment, can have measurable effects on viewer understanding.” Utilizing the CTML, he authors proposed, and subsequently showed, that by utilizing both visual and textual information, the reader is able to increase understanding of the system domain being designed.

Recommendations for Implementation

The first recommendation comes directly out of Figure 2 above. Companies need to provide adequate training and mentoring to both Business Analysts and Programmers to understand Use Case diagrams and UML in general. As the second study points out, Use Case diagrams increase learning performance when trying to understand Use Cases.

The second recommendation is to include Use Case Diagrams with every Use Case narrative or scenario. Regardless of the simplicity of the diagram, including a Use Case diagram can certainly not hurt the project and will, most likely, increase everyone's understanding of the system domain.

References:

Dimensions of UML Diagram Use:A Survey of Practitioners, Journal of Database Management, 19(1), 1-18, January-March 2008

Use Case Diagrams in Support of Use Case Modeling: Deriving Understanding from the Picture, Journal of Database Management, 20(1), 1-24, January-March 2009

Author: Mr. Botz is a working Business Analyst and operates Prime Proficiency, a company specializing in Business Analyst training.

Related Articles

Article/Paper Categories

Upcoming live webinars, ace the interview.

Roles and Titles

• Business Analyst
• Business Process Analyst
• IT Business Analyst
• Requirements Engineer
• Business Systems Analyst
• Systems Analyst
• Data Analyst

Career Resources

• Interview Tips
• Salary Information
• Directory of Links

Community Resources

• Project Members

Advertising Opportunities  | Contact Us  | Privacy Policy

Use Case Diagram Tutorial (Guide with Examples)

Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. They enable you to visualize the different types of roles in a system and how those roles interact with the system. This use case diagram tutorial will cover the following topics and help you create use cases better.

What is a UML Use Case Diagram

Importance of use case diagrams.

• Use Case Diagram Objects

Use Case Diagram Guidelines

Relationships in use case diagrams, identifying actors, identifying use cases.

• When to Use “Include”
• How to Use Generalization
• When to Use “Extend”
• Use Case Diagram Templates of Common Scenarios

A UML (Unified Modeling Language) use case diagram is a visual representation of the interactions between actors (users or external systems) and a system under consideration. It depicts the functionality or behavior of a system from the user’s perspective. Use case diagrams capture the functional requirements of a system and help to identify how different actors interact with the system to achieve specific goals or tasks.

Use case diagrams provide a high-level overview of the system’s functionality, showing the different features or capabilities it offers and how users or external systems interact with it. They serve as a communication tool between stakeholders, helping to clarify and validate requirements, identify system boundaries, and support the development and testing processes.

As mentioned before use case diagrams are used to gather a usage requirement of a system. Depending on your requirement you can use that data in different ways. Below are few ways to use them.

• To identify functions and how roles interact with them – The primary purpose of use case diagrams.
• For a high-level view of the system – Especially useful when presenting to managers or stakeholders. You can highlight the roles that interact with the system and the functionality provided by the system without going deep into inner workings of the system.
• To identify internal and external factors – This might sound simple but in large complex projects a system can be identified as an external role in another use case.

Use Case Diagram objects

Use case diagrams consist of 4 objects.

The objects are further explained below.

Although use case diagrams can be used for various purposes there are some common guidelines you need to follow when drawing use cases.

These include naming standards, directions of arrows, the placing of use cases, usage of system boxes and also proper usage of relationships.

We’ve covered these guidelines in detail in a separate blog post. So go ahead and check out use case diagram guidelines .

There are five types of relationships in a use case diagram. They are

• Association between an actor and a use case
• Generalization of an actor
• Extend relationship between two use cases
• Include relationship between two use cases
• Generalization of a use case

We have covered all these relationships in a separate blog post that has examples with images. We will not go into detail in this post but you can check out relationships in use case diagrams .

How to Create a Use Case Diagram

Up to now, you’ve learned about objects, relationships and guidelines that are critical when drawing use case diagrams. I’ll explain the various processes using a banking system as an example.

• Look for Common Functionality to Reuse

Is it Possible to Generalize Actors and Use Cases

Optional functions or additional functions.

• Validate and Refine the Diagram

Actors are external entities that interact with your system. It can be a person, another system or an organization. In a banking system, the most obvious actor is the customer. Other actors can be bank employee or cashier depending on the role you’re trying to show in the use case.

An example of an external organization can be the tax authority or the central bank. The loan processor is a good example of an external system associated as an actor.

Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from the system. In a banking system, a customer will need to open accounts, deposit and withdraw funds, request check books and similar functions. So all of these can be considered as use cases.

Top level use cases should always provide a complete function required by an actor. You can extend or include use cases depending on the complexity of the system.

Once you identify the actors and the top level use case you have a basic idea of the system. Now you can fine tune it and add extra layers of detail to it.

Look for Common Functionality to Use ‘Include’

Look for common functionality that can be reused across the system. If you find two or more use cases that share common functionality you can extract the common functions and add it to a separate use case. Then you can connect it via the include relationship to show that it’s always called when the original use case is executed. ( see the diagram for an example ).

There may be instances where actors are associated with similar use cases while triggering a few use cases unique only to them. In such instances, you can generalize the actor to show the inheritance of functions. You can do a similar thing for use case as well.

One of the best examples of this is “Make Payment” use case in a payment system. You can further generalize it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them have the attributes and the functionality of payment with special scenarios unique to them.

There are some functions that are triggered optionally. In such cases, you can use the extend relationship and attach an extension rule to it. In the below banking system example “Calculate Bonus” is optional and only triggers when a certain condition is matched.

Extend doesn’t always mean it’s optional. Sometimes the use case connected by extending can supplement the base use case. The thing to remember is that the base use case should be able to perform a function on its own even if the extending use case is not called.

Use Case Diagram Templates

We’ve gone ahead and created use case diagram templates for some common scenarios. Although your problem or scenario won’t be exactly like this you can use them as a starting point. Check out our use case diagram templates .

Questions Regarding the Use Case Diagram Tutorial

We’ve tried to comprehensively cover everything you need to know about creating use case diagrams. If you have doubts about any section or can think of ways to improve this tutorial please let us know in the comments.

More Diagram Tutorials

• Sequence Diagram Tutorial: Complete Guide with Examples
• Business Process Modeling Tutorial (BPM Guide Explaining Features)
• Ultimate Flowchart Guide (Complete Flowchart Tutorial with Examples)

Join over thousands of organizations that use Creately to brainstorm, plan, analyze, and execute their projects successfully.

FAQs on Use Case Diagrams

• Requirement analysis : Use case diagrams aid in understanding and documenting the functional requirements of a system by identifying actors and their interactions.
• System design : Use case diagrams provide a high-level overview of system functionality, helping to define scope and design system components.
• Communication with stakeholders : Use case diagrams facilitate discussions and ensure a shared understanding with stakeholders.
• Project planning and management : Use case diagrams assist in defining scope, prioritizing requirements, and identifying risks.
• Test planning : Use case diagrams help identify scenarios and generate test cases for comprehensive test coverage.
• Documentation : Use case diagrams serve as documentation artifacts for future development, maintenance, and upgrades.
• Identify actors and use cases : Clearly identify the actors, representing external entities interacting with the system, and the use cases, representing system functionalities.
• Use descriptive names : Choose meaningful and descriptive names for actors and use cases to ensure clarity and understanding.
• Define relationships : Establish relationships between actors and use cases to depict their interactions. Use arrows to show the direction of the interaction.
• Keep it simple : Avoid overcomplicating the diagram by focusing on the most essential actors and use cases. Too many details can make the diagram confusing and less effective.
• Use appropriate notation : Follow the standard UML notation for use case diagrams, including ovals for use cases, stick figures for actors, and arrows for relationships.
• Organize and layout : Arrange the actors and use cases in a logical and organized manner, ensuring a clear flow of information. Use lines and connectors to connect related use cases.
• Use hierarchical structure : If the system has complex functionality, consider using a hierarchical structure with primary use cases at the top level and detailed use cases nested beneath.

In a use case diagram, the following elements are typically included:

• Actors: Represent external entities interacting with the system.
• Use cases: Represent specific functionalities or actions performed by the system.
• Relationships: Connect actors and use cases to show interactions and dependencies.
• System boundary: Encloses use cases and actors within the scope of the system.
• Communication paths: Arrows or lines indicating the flow of communication.

On the other hand, use case diagrams do not include the following:

• Internal system details: Focus on high-level functionality, not specific components.
• Sequence of actions: No specific order of execution shown.
• Implementation details: Independent of implementation specifics.
• User interface details: No depiction of visual design or interface elements.

More Related Articles

Software engineer turned tech evangelist. I handle marketing stuff here at Creately including writing blog posts and handling social media accounts. In my spare time, I love to read and travel.