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.

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 modeling in a research setting of developing an innovative pilgrimage support system

• Open access
• Published: 03 November 2023

Cite this article

You have full access to this open access article

• Valentino Vranić 1 ,
• Ján Lang 1 ,
• Martín López Nores 2 ,
• José Juan Pazos Arias 2 ,
• Jaime Solano 3 &
• Guillermo Laseca 3  

610 Accesses

2 Citations

Explore all metrics

With so much confusion around use case modeling, software developers may be reluctant to apply it. However, use cases are easy to apply and have great benefits even in research settings with nonprofessional software developers involved. We report on our experience on this within an innovative tourist information system developed in a research setting of an ongoing Horizon 2020 project named Promotion of Rural Museums and Heritage Sites in the Vicinity of European Pilgrimage Routes (rurAllure). The resulting use case model comprises forty use cases supported by class diagrams, use case diagrams, sequence diagrams, as well as by the domain model and dictionary. Three quarters of use cases have been implemented at least to some extent. Writing use cases provoked intense communication, which helped consolidate the system architecture. The use cases helped validate and better understand the GUI form wireframes designed beforehand and get quickly to a consistent implementation of the system that can be experimented with further in different ways. Finally, the forthcoming extensive system and user experience testing will be guided by the use case model. The paper also exposes the domain model and dictionary along with selected use cases and the hierarchy of user and system actors, which may be useful as such or as a stimulus for the development of other innovative tourist information systems.

Similar content being viewed by others

Introduction to Design Science Research

From enterprise models to low-code applications: mapping DEMO to Mendix; illustrated in the social housing domain

Marien R. Krouwel, Martin Op ’t Land & Henderik A. Proper

The Double Diamond Model: In Pursuit of Simplicity and Flexibility

Avoid common mistakes on your manuscript.

1 Introduction

International research projects most often involve some kind of software system development. Such software systems not just embody the project findings in a way that enables these findings to be used and experimented with, but their development is often a driving force for the whole project. This puts researchers of different profiles unrelated to software development into the role of software developers. Professional software development partners are often involved in order to facilitate the process of software development, but other partners often significantly contribute to various software development stages, including the actual programming.

Working versions of such software systems are needed in short time in order to make further experiments. These, in turn, reveal further requirements that need to be implemented within the system. No surprise that such research and development teams often turn to agile software development, which indeed suits well the conditions they are facing.

Thanks to intense communication and close collaboration within, preferably, colocated teams, agile software development can be very successful even with minimal actual efforts put into capturing requirements in a written form. This is why user stories, which are one-sentence “promises for a conversation between a requirements expert and a developer,” as Cockburn denoted them [ 5 ], appear to be sufficient there. Cohn also suggests that it is better that the development team and the customer discuss the details [ 7 ]. But international research project settings usually do not provide such conditions. The members of the team reside in different countries and most of the communication goes on remotely.

Related user stories are commonly grouped into so-called epics. Dalpiaz and Sturm show a simple use case and an epic whose user stories correspond very much to the steps of that use case [ 11 ]. However, typical use cases require more writing than user stories and they usually involve some level of modularization, but they create a more firm basis for the development. This is especially important for distributed teams of professional and nonprofessional software developers, who are native in different languages, and for whom the system they are developing is not a goal in itself, but rather a tool for obtaining the experimentation and evaluation results.

In this paper, we describe and generalize our recent experience of applying use case modeling to establish a firm software development basis for further exploration within an innovative tourist information system developed in a research setting of an ongoing Horizon 2020 project named Promotion of Rural Museums and Heritage Sites in the Vicinity of European Pilgrimage Routes (rurAllure). Footnote 1 The paper also exposes some software analysis artifacts that might be useful for the development of other innovative tourist information systems.

The rest of the paper is organized as follows. Section  2 explains how are use cases currently understood and misunderstood. Section  3 describes the essentials of how we applied use case modeling in the rurAllure project. Section  4 describes how and to what extent we elaborated our use case model. Section  5 describes what support models have we used. Section  6 discusses the benefits of use cases for our project.

Section  7 compares the approach proposed in this paper to related work. Section  8 concludes the paper and indicates some possibilities for further work.

2 Current (mis)understanding of use cases

Use cases are typical, goal oriented interactions of users and software systems [ 5 ]. They represent an inexpensive means of exploring what really a software system should enable.

Use cases can be seen as a way of generalizing collections of related scenarios [ 5 ], specific stories of what can happen when a user attempts to reach a particular goal. The value of collecting and analyzing scenarios has been recognized by Carroll in his scenario-based design [ 4 , 21 ]. However, in use case modeling the generalization commonly happens outright, without recording the actual scenarios.

As they target interactions, use cases are most often expressed as simple sequences of steps switching the actions taken by the user and the system response towards its successful end. They may look as simple as this use case identified within the rurAllure system:

Generate a Pilgrimage Plan A pilgrim lets the planning service generate a pilgrimage plan according to the pilgrimage plan parameters. 1. The pilgrim wants to create a pilgrimage plan. 2. The web portal prompts for the pilgrimage plan parameters: origin, destination (if different from the traditional destination of the pilgrimage route), start date (default time assumed), main mode of mobility, companions (traveling alone, in a couple, or in a group, with or without children, etc.), interests (gastronomy, architecture, literary heritage, etc.). 3. The pilgrim enters the pilgrimage plan parameters (at least origin, start date and mode of mobility). 4. The web portal gets a pilgrimage plan corresponding to the parameters from the planning service. 5. The web portal displays the pilgrimage plan as a sequence of daily pilgrimage plans and as a map. 6. The pilgrim decides to save the plan. 7. The pilgrim sets the plan accessibility (private/replicable/shared). 8. The web portal saves the changes. 9. The use case ends.

These sequences of steps are called flows of events or simply flows [ 16 ]. Sometimes, they are denoted as scenarios [ 5 ] (not to be confused with scenarios as they are perceived by Carroll [ 4 , 21 ]).

Any but trivial applications of use cases requires some kind of their modularization. In the Generate a Pilgrimage Plan use case, we need to deal with the situation when no direct booking options are available. This could have been be included in the basic flow we showed, but that would certainly make the intent of the use case less comprehensible. Consequently, such modifications or extensions to basic flows are introduced in separate modules called alternative (or alternate ) flows. They were introduced by Ivar Jacobson at OOPSLA 87 [ 13 , 17 ], who proposed the initial use case modeling notation [ 14 ], but the idea was conceived already in 1967 [ 15 ]. This notation also enabled including (activating) a use case within another use case or extending (affecting) a use case from within another use case.

Alistair Cockburn proposed a slightly different style of writing use cases, mainly with respect to alternative flows [ 5 ]. More importantly, Cockburn distinguished between use cases as a concept and as a notation, emphasizing that the most important use cases are those targeting user goals, while also showing that the same notation can be used to capture use cases targeting summary goals and subfunction use cases [ 5 ].

While Cockburn, as compared to Jacobson, favors even more concise step formulation, using alternative flows instead of conditional behavior (if-like statements), Overgaard and Palmkvist [ 26 ] write use cases as verbose, prose-like text and do not use step numbering at all. Coplien and Bjørnvig [ 10 ] suggest a two-column table format: one column represents the user’s actions, while the other one those taken by the system.

Practitioners pick and choose features they learned about from different sources, and possibly even introduce their own. Some features from different notations can be combined, while some are mutually exclusive [ 25 ]. Albeit use cases look like algorithms, it is important to bear in mind that they will be read by nonprogrammers, so enforcing the use of keywords and restricting their semantics may easily make them look like code, which can be harmful to their comprehensibility. On the other hand, there have been efforts to preserve use cases in code [ 2 , 3 , 9 , 10 , 16 ], so that code could be read like use cases, but this is not meant as a substitute for expressing use cases in natural language.

Dozens of approaches to how a “right” use case should be written are proposed, with more or less structuring and limitations in terms of allowed keywords and even complete phrases, often contradictory in their recommendations [ 24 ].

Speaking of use case modeling notations, UML use case diagrams cannot be left out. Attracted to use case diagrams by their graphical nature, many practitioners easily confuse them for the real thing: the text. Use case diagrams provide only an overview of use cases and cannot express their flows. Consequently, it is best to draw use case diagrams only after they have been written. Otherwise, one can easily end up with a number of use case diagrams—or one big use case diagram—with bubbles and relationships no one understands. Even worse, use case writers might feel an obligation to stick to this unfounded picture and start to make up descriptions of use cases that make no sense. Unfortunately, even very good books on use case modeling, such as the one by Overgaard and Palmkvist, mislead practitioners to start their use case modeling with use case diagrams [ 26 ].

Use cases are not a user interface specification. They are concepts of the users’ mind that can be supported by the software system and its user interface more or less thoroughly. Footnote 2 A use case can be realized over one or several user interface forms, while the same form may be involved in several use case realizations. Consequently, use cases should not mention windows, buttons, menus, labels, and other elements of a typical windows graphical user interface or any user interface in general. Having the user interface elements mentioned here and there usually does not pose a problem and this is what one can see very often in practice [ 5 ]. However, in order not to fall into the trap of confusing use cases for a user interface specification, it is best to actively abstract from any occurrence of user interface elements. For example, instead of saying a user “clicks the OK button” we can say that they “confirm the action.”

3 The rurAllure pilgrimage support system: a case for use cases

As mentioned in the introduction, rurAllure is an ongoing Horizon 2020 project on promotion of rural museums and heritage sites in the vicinity of European pilgrimage routes. The project strives at networking relevant institutions in the area rural heritage, mapping rural museums and heritage sites in the vicinity of the four selected European pilgrimage routes, developing studies of the corresponding rural heritage, and developing the corresponding pilgrimage support system. To be able to deal with these complex objectives, the project consortium, coordinated by Martín López Nores, one of the authors of this paper, involves 15 partners from 6 European countries, which form a team of social and humanities scientists and historians, museum practitioners, experts in economy and territorial development, computer scientists, designers, experts in tourism and marketing, as well as private companies and government institutions. The rurAllure also involves more than 60 associated partners (the list is growing).

While the project brings many reports, activities, established connections, etc., it is exactly this pilgrimage support system that puts everything together into something that everyone can see and interact with. High expectations of this system are not only on the side of the European Commission representatives, associated partners, and general audience, but also on the side of the consortium as such. Everyone wants to see how their work “works.” Such a reflection of their work within a functional software system then motivates the consortium to produce more of interesting results.

3.1 The process

Developing interactive systems such as this pilgrimage support system requires an agile process. Without any doubt, an agile process assumes the ability to rapidly respond to change. Despite what many people think, frantically responding to change is not the sole activity in agile software development. To be able to respond to change responsibly, there must be some common grounds around which everything spins and can safely land if necessary. These common grounds should not be unnecessarily detailed. In fact, they should be lean . This is a different approach to software development and work in general, which strives not to produce waste. One of the consequences this has is that decisions are not made until there is sufficient information to do so. This prevents from creating unnecessary artifacts: waste. In other words, a lean process is a basis for an agile process [ 10 ].

To be agile and lean requires close, direct communication among all the people involved in the process. This the lean secret: everyone, all together, from early on [ 10 ]. This is the philosophy behind the approach applied to develop a pilgrimage support system helping pilgrims to enrich their pilgrimages with rural heritage experience.

A general idea of what such a pilgrimage support system should look like was established already in the project proposal. Based on this, GVAM, Footnote 3 a company which is one of the partners in the rurAllure project, came with an initial set of graphical user interface (GUI) form wireframes, so that the project participants as the designers of the system could better imagine how it would work. As we started with the implementation immediately after expressing use cases, we did not feel the need to use any mock-up design tools to get an interactive form of the GUI. An initial idea of the system architecture was also proposed. Part of it was based on the microservice architecture, with an initial description of the services.

A brainstorming session was initiated with all the project participants being invited. It continued over a Trello board, which was used to collect usage narrative fragments as short and personalized ideas of what the system should offer to pilgrims. More pilgrimage knowledgeable partners, mainly Associazione Europea delle Vie Francigene, Mária Út Egyesület, and Fundación Uxío Novoneyra, including all project participants with individual pilgrimage experience, were opening new perspectives, while more technically oriented project participants watched over feasibility.

In parallel with collecting usage narrative fragments—and relying on them—the activity of expressing the essential ideas of what the system is and how it is going to behave in a coherent form was started. On the one hand, the basic (data) concepts were identified and related to each other. On the other hand, the system behavior was expressed in the initial set of use cases. All this was open and accessible to all the project participants for commenting and modifications using the capabilities of collaborative editing on the Synology Drive (much like Google Drive documents).

We cannot say the process was smooth. But if it were, that would mean that the communication was not frank and we should probably be afraid of what system would come out of this. There were many discrepancies, but all were dealt with in a very short time with a goal of building common understanding. All the constituent parts of analysis and design—usage narratives, domain model, use cases, architecture, and GUI design—were continuously cross-checked for consistency.

3.2 Usage narratives

Some typical system usages were explored by describing them from the perspective of imagined specific users as if they were real people in usage narratives. Usage narratives are often used—formally or informally—as precursors to use cases [ 5 ]. Personas and scenarios [ 8 ] are practically analogous to usage narratives.

The usage narratives we dealt with in rurAllure introduced the three types of users envisaged: the pilgrims (the subject of most of the narratives), the vendors who want to offer services along the routes (one narrative), and the administrators who manage the platform’s content for each route (two narratives). It is important to note that our goal was not to cover all the interactions, but to make the starting point for use cases, within which we strived for completeness.

Here is an example of a usage narrative named Using the rurAllure Website and Mobile Application:

Camille is a young French woman who is interested in European culture and trekking. She is planning her holiday vacations and is thinking about traveling a pilgrimage route somewhere in Europe. Though quite familiar with pilgrimage routes such as the Way of St. Jacques, she wants to discover new routes and places in Europe she doesn’t know that well, as she is willing to submerge herself in lesser known paths and places. Doing a quick search on her computer, she heads towards the rurAllure website, which seems to have what she is looking for.

Getting a Personalized Trip is a longer usage narrative:

Although there are featured trips available, Camille sees that there is a trip planner and she wants to give it a try, expecting to create a trip from scratch specifically tailored to her interests and preferences. Firstly, she introduces the dates she wants to travel. Although the route itself starts from Mariazell in Austria she prefers choosing Kőszeg in Hungary as the point of departure because she had been to Austria on other occasions. She defines şumuleu Ciuc (Csíksomlyó) in Romania as the destination. Then, she includes some other details: she wants to travel by bicycle and checks the tags of “history,” “nature” and “gastronomy.” Finally, she clicks the “See your plan” button. The website now displays the proposed itinerary, which is displayed both on a map and as a sequence of daily plans connecting successive places/activities of interest. At the point of departure she is offered various bicycle rental options among the services offered, in case she wanted to rent a bike at Kőszeg. On the map, Camille finds that some segments appear with dashed lines; by passing the mouse pointer over them, she understands that those segments are detours from the official paths, that take her to visiting some places related to the selected tags of “history,” “nature” and “gastronomy.” She loves this idea, but browsing the info sheets of those places she chooses to remove one of them for not looking particularly interesting. At some point, while browsing the successive daily plans and looking at the locations, Camille notices a list of popular places that she could visit, too, even if not related to the aforementioned tags. One of them, the Salty spa of Cozmeni, really catches her attention, so she has it added to her plan and sets it as the ending location for the corresponding day. Camille is fascinated to see that the planner updates the subsequent stages automatically!

As we can see, for usage narratives it is perfectly fine to refer to imagined user interface controls. They imagine specific situations which involve specific people. Through this, it is easier for a writer to “see” how the imagined system “looks” and “feels” as if it were already implemented.

3.3 Domain model: what the system is and the domain dictionary

While use cases describe what the system does, which tends to develop and change over time, there is an internal, more stable perspective that needs to be taken first: what the system is. This perspective is primarily about data.

Figure  1 shows the essential (application) domain concepts and how they are related to each other using the UML class diagram notation. What is displayed in the figure is the essence of the pilgrimage support system. Its main concern is around a pilgrimage plan, which is a sequence of daily pilgrimage plans. These, in turn, represent sequences of pilgrimage sites and other places/activities of interest (abbreviated as POI) related to activity or hospitality, along with timing. Some of the activity/hospitality POIs are proposed by vendors. All these, including the pilgrimage sites, are just geographical locations with accompanying information. A pilgrimage plan as such or each planned POI can be associated with narratives, Footnote 4 which are any media content offering an interpretation of the heritage found nearby.

Domain model

This domain model looks more like a data model than a comprehensive conceptual model as proposed by Johnson and Henderson [ 18 ]. This is because our intention was not to get overwhelmed by the functionality, which was to be explored through use case modeling following this activity. The same concepts constitute the domain dictionary, which features their textual definitions (see Appendix A). A domain dictionary forms the basis for a coherent user interface vocabulary. Where the application domain is not sufficiently understood, writing use cases may help in exploring it and establishing the domain concepts.

3.4 Essential use cases

In rurAllure, a simple and common approach based mainly on Jacobson’s notation [ 14 , 16 ] was applied to keep use cases readily understandable. As mentioned in Sect.  2 , at the simplest level, a use case is captured as a sequence of steps that defines the most probable, successful interaction. These form so-called basic flows. Footnote 5 They are usually preceded by a short use case description. Recall the Generate a Pilgrimage Plan use case from Sect.  2 . Notice how the first step clearly expresses how the use case starts. The flow maintains the interaction switching the actions taken by the user and the system response towards its successful end. It skips the details considered unnecessary to gain the understanding of the use case.

For the rurAllure use case model, we started exactly with how the planning of pilgrimage trips should work as we saw this as the main feature of the system. No one was raising this as an issue within the initial set of GUI form wireframes, nor within the usage narratives. However, looking at everything we had, we realized we did not understand how the planning of pilgrimage trips should work, so we started guessing and exposed our idea as a use case.

As we were maintaining the use case model in a shared, collaboratively edited document in a system similar to Google documents, the project coordinator and colleagues from GVAM reacted very soon complaining that this was not supposed to be as the use case said. Interestingly, they disagreed among themselves. This is not bad, on the contrary: what happened is actually desirable. Use cases enabled us to expose the idea in a cheap model clearly and then to judge it. We were able to correct the use case arriving at the version we introduced here within the course of several iterations.

This is what we did also with other use cases. We always favored more important and challenging use cases over trivial ones, such as those related to registration or logging in. Often, we wrote only basic flows and checked to see whether we agree upon the essence of these use cases before elaborating them.

A user interacting with the system takes a particular role or plays a particular actor. The idea of an actor helps consolidate the system for different sets of use cases. Consequently, a software system looks and behaves differently for different actors.

Apart from the users, whose hierarchy is depicted in Fig.  2 , parts of the system and its parts can also be perceived as actors. These are depicted in Fig.  3 . In order to ensure common understanding, it is also important to provide textual definitions of actors (see Appendix B).

System actors

The concrete actors represent actual types of users and actual parts of the system, while abstract actors and inheritance (generalization/specialization, in a correct UML parlance) are used so that we can express use cases common to several of these actors.

Services are further elaborated in Fig.  4 . It is important to emphasize that this is an analytical perspective on the system, which is needed here in order to expose its essential behavior. For example, web portal stands here for the interaction carried via a web based interface.

Service actors

The rurAllure system is actually a platform with several ways to access its functionality. From the perspective of a common user, this is always through one of the portals: the web portal or the mobile application. The scope of some use cases is limited to only one of them, while some use cases are valid for both of them. This can be expressed through the abstract Portal system actor. Consider this use case:

[PORTAL] Book an Activity or Service at a POI A pilgrim books an activity or service offered at a POI. Basic Flow 1. The pilgrim wants to book an activity or service offered at a POI. 2. The portal displays the direct booking options available for the activity or service (normally accompanied by pricing) provided by the booking service . 3. The pilgrim selects a booking option and confirms the selection. 4. The planning service recomputes the affected daily pilgrimage plan (and subsequent ones if necessary). 5. The portal displays the updated pilgrimage plan. 6. The booking service stores the information that the corresponding option is booked. 7. The booking service sends an email notification to the pilgrim and to the corresponding vendor . 8. The use case ends.

The scope is indicated before the use case name. We emphasize the names of the actors for their easier recognition. We kept revising this set of actors as we elaborated the use case model.

We could imagine other systems accessing the platform through its services, but this was not addressed by our use case model.

4 Elaborating the use case model

A use case model is useless if no one understands it. Moreover, use cases are written in natural language in order to be readily understandable by all stakeholders. Due to this, we were careful in introducing more advanced use case modeling features. However, we think that without using alternative flows, Footnote 6 include and extend relationships between use cases, and use cases with multiple flows, a use case model would contain so much repetition that it would be not only very difficult to establish and maintain, but also to read.

4.1 Alternative flows

Important alternative possibilities with respect to basic flows are captured in so-called alternative flows. These alter basic flows or even other flows at certain steps. Recall the Book an Activity or Service at a POI use case from Sect.  3.5 This is an alternative flow to its basic flow:

Alternative Flow: No Direct Booking Options Available After step 1, if no direct booking options are available: 1. The portal displays the activity or service data (its name, contact information, link, etc.), if available. 2. The use case ends.

Alternative flows are simply introduced after the basic flow, and, for a given use case, we typically wrote them down only after we agreed upon its basic flow. They are named in order to make them readily understandable. It is usually not necessary to name basic flows, as their meaning is given by the name of the use case they reside in (but see Sect.  4.4 ).

4.2 Include

A use case can include another use case, which means that this use case is activated at a certain point, with the control returned to the including use case once the included use cases is completed. Consider the Remove a Featured Pilgrimage Plan , which includes the Find a Pilgrimage Plan in its step 2:

[WEB PORTAL] Remove a Featured Pilgrimage Plan An administrator removes a featured pilgrimage plan. Basic Flow 1. The administrator wants to remove a featured pilgrimage plan. 2. The Find a Pilgrimage Plan use case is activated with the search restricted to featured pilgrimage plans. 3. The administrator selects a pilgrimage plan. 4. The web portal prompts the corresponding route administrator whether the pilgrimage plan should be removed. 5. The web portal removes the pilgrimage plan completely. 6. The administrator can cancel the operation at any time. 7. The use case ends.

As shown in this example, the activation can be made with a particular setting invoked (“with the search restricted to featured pilgrimage plans”).

Not specifically related to the include relationship, observe step 6 of the use case, which enables to cancel the operation at any time. This step could have been included anywhere or even outside the flow. However, including it in the flow keeps it within the sight. Consequently, flows are only partially ordered sequences of steps.

An included use case itself can also include other use cases:

[WEB PORTAL] Find a Pilgrimage Plan A user searches for a pilgrimage plan created by some pilgrim. Basic Flow: 1. The user wants to remove a featured pilgrimage plan. 2. The Find a Pilgrimage Plan use case is activated with the search restricted to featured pilgrimage plan. 3. The user selects a pilgrimage plan. 4. The web portal prompts the route administrator whether the pilgrimage plan should be removed. 5. The web portal removes the pilgrimage plan completely. 6. The user can cancel the operation at any time. 7. The use case ends.

An include clause may be a conditional. Here is a more verbose with a multiple conditional include clauses and an include clause in an alternative flow:

[WEB PORTAL] Adopt a Pilgrimage Plan A pilgrim adopts as their own a featured pilgrimage plan or a replicable pilgrimage plan created by another pilgrim. Basic Flow 1. The pilgrim wants to adopt a pilgrimage plan. 2. The pilgrim selects an appropriate pilgrimage plan among the featured pilgrimage plans, in which case the Find a featured pilgrimage plan use case is activated, or replicable pilgrimage plans (created by other pilgrims), in which case the Find a pilgrimage plan use case is activated. 3. The pilgrim enters the pilgrimage plan parameters to adapt the selected pilgrimage plan: the origin (possibly extending or shortening the adopted plan at the beginning), start date, mode of mobility, etc. 4. The web portal gets from the planning service a pilgrimage plan adapted according to the parameters. 5. The pilgrim sets the plan accessibility (private/replicable/shared). 6. The pilgrim confirms the changes. 7. The web portal saves the pilgrimage plan as a new pilgrimage plan owned by the pilgrim. 8. The use case ends. Alternative Flow: The Pilgrim is Not Logged In After step 4, if the pilgrim is not logged in: 1. The Log In use case is activated. 2. In case of a successful log in, the use case continues with step 5 of the basic flow. Otherwise, the pilgrim is prompted to cancel the operation. 3. If the pilgrim confirms canceling the operation, the use case ends. Otherwise, the use case continues with step 1 of this flow.

Some use cases are intended only to extend or alter other use cases, just like alternative flows do to the basic flow within one use case. Consequently, such extension use cases contain no basic flows, but only alternative flows. These external alternative flows alter other use cases at certain labelled steps or ranges of steps known as extension points. Consider this use case:

[PORTAL] Extend a Pilgrimage Plan by POIs A pilgrim extends a pilgrimage plan by POIs. If activated from the mobile application , the use case redirects to the web portal . Basic Flow 1. The pilgrim wants to extend daily pilgrimage plans by adding POIs. 2. The web portal displays the pilgrimage plans that the pilgrim owns. 3. The pilgrim selects a daily pilgrimage plan within one of the pilgrimage plans. 4. The web portal displays the selected daily pilgrimage plan. 5. The pilgrim selects a POI and indicates whether another POI is to be added before or after this location. 6. The web portal displays the list of available POIs provided by the recommendation service . 7. The pilgrim can view the details of any of the POIs from the list. 8. The pilgrim selects one POI to be added to the daily pilgrimage plan. 9. The planning service recomputes the daily pilgrimage plan and subsequent ones if the POI exceeds one day. 10. The web portal displays the updated daily pilgrimage plan. 11. Steps 5–10 can be repeated. The pilgrim can remove any POIs that have been added within this use case. 12. The pilgrim can cancel the changes at any time, in which case the use case ends without saving the changes. 13. The pilgrim confirms the changes. 14. The web portal saves the changes. 15. The use case ends. Extension Points Displaying a Pilgrimage Plan : steps 4–6 Displaying the Details of a POI : step 7

This use case extends the Extend a Pilgrimage Plan by POIs use case and several other use cases:

[PORTAL] Rate a POI A pilgrim rates a POI. Alternative Flow: Rate a POI After the Displaying the Details of a POI extension point in the Extend a Pilgrimage Plan by POIs use case, the Choosing a Hospitality POI extension point in the End Up a Daily Pilgrimage Plan with Accommodations use case, or the Displaying the Details of a POI extension point in the Make a Detour from a Daily Pilgrimage Plan use case: 1. The portal provides a possibility to rate the POI whose details are being displayed with up to five stars. 2. The pilgrim can rate the POI or reject to do so. 3. The use continues with the next step.

An extension use case may as well extend only one use case:

[WEB PORTAL] Recommend POIs The recommendation service recommends POIs to extend a pilgrimage plan with. Alternative Flow: Recommend POIs Instead of the Displaying a Pilgrimage Plan extension point of the Extend Daily Pilgrimage Plans by POIs use case: 1. The web portal displays recommended POIs provided by the recommendation service for the whole pilgrimage plan.

This is useful if the presence of such behavior needs to be stressed or it is assumed it could extend other use cases as the model grows. Otherwise, the alternative flow occurring in it could be simply put into the extended use case.

Although the same extension point can be addressed by several use cases, most often, extension points are introduced for the purposes of making an extension by one specific use case. This is so in our model, too, i.e., one extension point is addressed by one use case only. This might make a false impression that extension points as such modify or participate in modifying the behavior of the extended use case. Of course, this is not so. Furthermore, raw step numbers can be used instead. However, labeled extension points are more convenient when it comes to renumbering steps in the use case being extended.

4.4 Use cases with multiple basic flows

To reduce the number of use cases, a use case can group several related basic flows each of which could have been considered a separate use case. Usually, this strategy is applied when these use cases resemble so-called CRUD (create–read–update–delete) operations. Here is an example:

[WEB PORTAL] Manage POIs An administrator adds, updates, or removes a POI. Basic Flow: Add a POI 1. The administrator wants to add a POI. 2. The web portal prompts for the POI data. 3. The administrator provides the POI data, including indicating whether it is active (available for selection in the pilgrimage plans). 4. The web portal saves the POI. 5. The use case ends. Basic Flow: Update a POI 1. The administrator wants to update a POI. 2. The Find a POI use case is activated. 3. The web portal displays the POI data and prompts for changes. 4. The administrator provides the POI data, including indicating whether it is active (available for selection in the pilgrimage plans). 5. The web portal saves the POI. 6. The use case ends. Basic Flow: Remove a POI 1. The administrator wants to remove a POI. 2. The Find a POI use case is activated. 3. The web portal displays the POI data and prompts for confirming removing it. 4. The administrator confirms removing the POI. Alternatively, the administrator can cancel the operation, in which case the use case ends. 5. The web portal disables providing the POI for inclusion in any subsequent pilgrimage plans and suppresses displaying its details. 6. The use case ends.

4.5 What was not used and why

Although preconditions show how use cases are sequentially dependent [ 6 ], we did not include them in our model relying these can be easily devised by the reader. For example, it is obvious that a user has to be logged in in order to take some actions whose consequences are associated with a particular user or that a pilgrimage plan has to exist before being modified, etc.

Postconditions are comprehensible from the use case flows, so we did not include them in our model either. Introducing them separately might be beneficial for a quick understanding what a use case brings. However, in all but trivial use cases, postconditions cannot be expressed that concisely as they have to express both minimal guarantees (if a use case fails) and success guarantees [ 5 ].

A use case included by other use cases should not contain the information on how it is activated (in the first step), nor should it declare that it has ended (in the last step). This kind of flow is known as a subflow in Jacobson’s notation [ 16 ]. Cockburn’s notation [ 5 ] does not recognize this concept. To be formally correct with use cases that are both included in some other use cases and that can be activated on their own, which is often the case with search and find use cases, the core behavior would have to be introduced in a subflow, while there should also be a basic flow there that would include the activation and end steps and the activation of the subflow in between the two. However, a use case model is not to be executed by a machine, but to be read by people, so we decided not to use subflows in our model.

While inheritance between use cases can improve their modularity and decrease the repetition of the actual steps, it obscures the meaning of the inheriting use cases. The readers are forced to read the use cases these use cases inherit from. It is possible for the base use cases to be completely abstract, i.e., to have nothing but names. They can be used to better structure use case diagrams by reducing the number of edges as actors participating in a number of use cases derived from a common base use case will be connected only to this use case. However, for the reasons explained in Sect.  2 , use case diagrams were not of a great concern to us as we were focusing on use case text as such. Consequently, we decided not to use inheritance between use cases.

5 Supporting the use case model by other models

We supported our use case model by class diagrams, use case diagrams, and sequence diagrams in order to make it more comprehensible.

5.1 Class diagrams

As described in Sect.  3.5 , we used class diagrams to model actors. In their essence, these are inheritance hierarchies. No other relationships are used. No attributes, nor operations were introduced in the classes that represent actors.

5.2 Use case diagrams

Use case diagrams are useful for showing how use cases are related by explicit relationships and how they are grouped according to the subject. We identified ten subjects in the rurAllure system, which include getting an initial pilgrimage plan, extending and adjusting pilgrimage plans, adding services and narratives, sharing pilgrimage plans, or following pilgrimage plans, and drew a use case diagram for each of them. Figure  5 shows an example.

The use case diagram of the extending and adjusting pilgrimage plans subject

As we explained in Sect.  2 , use case diagrams should be used as an overview of already written use cases, and not as the starting point for use case modeling. It is easy to draw meaningless use case diagrams no one will argue against, but this is not so with the actual text of use cases.

5.3 Sequence diagrams

We introduced sequence diagrams only for the most complicated use cases, such as Adopt a Pilgrimage Plan , whose sequence diagram is depicted in Fig.  6 . We did not go beyond the use case description, i.e., the sequence diagrams we created are purely analytical. Lifelines refer to the human and system actors as they are conceived in the use case description. Messages are based on the steps. Combined fragments are used to express decisions or loops.

The sequence diagram of the Adopt a Pilgrimage Plan use case

6 Aftermath

The use case model of the rurAllure system comprises forty use cases. The hierarchies of user and system actors are captured in three class diagrams. The use cases are visually supported by ten use case diagrams accompanied by five sequence diagrams expressing the most complicated use cases. In addition to this, the domain concepts the use cases rely on are captured in the domain model and defined in the domain dictionary. Three quarters of use cases have been implemented at least to some extent. Often, even significant changes were introduced. Consequently, the role of our use case model was not to strictly prescribe how things will be implemented and then to stick to this model as a contract, which is the role use case models often play in waterfall-like software development, but to create a tangible idea of the system which can be worked with further.

6.1 Impressions

The use cases started to be useful for us from the moment we started writing them. They provoked so intense communication over the collaboratively edited document on the Synology Drive, in addition to which we exchanged dozens of e-mails, held many remote meetings in different settings, and talked face-to-face at joint meetings we had an opportunity to have so far. Through this, the use case model helped consolidate the system architecture. It demonstrated how the rurAllure system will be accessed by users and how the services will be used.

Our impression is that the developers considered the use case model as something assumed. However, two developers shared their thoughts with us on how useful the use case model was for them:

For developers, the most important thing is to have the objectives of each functionality perfectly defined, especially in a project as large as rurAllure, with so many teams working with totally different points of view. A clear description gives us a calm atmosphere to structure and design each new functionality. The use cases have allowed us from settling tireless discussions between different teams to prioritizing several upcoming implementations. In the end, the development of a platform translates into implementing functionalities that complete the use cases. The more use cases a functionality touches, the higher priority its release should have.

However, the most important moment has been during the design phase of each of our microservices. The initial design is the most critical point, as it is done when the project is still too young, but at the same time, it is the basis on which the final functionality will be created. Without clear and concise use cases, this could have neve been done.

The perception of the use case model by nontechnical project participants is probably best captured in the thoughts one of them shared with us:

When I read the section devoted to use cases, it was, in my view, really well explained and it does help to understand what the system is supposed to do, both the text (with each step of the basic flow) and the accompanying graphics. At first, I sometimes found a bit difficult to understand how some use cases were linked to others and even I sometimes wondered about the order in which they were presented, especially when a use case in directly related to another one in the basic flow (as, I guess, it was easy to see in my review comments), but overall I found this section very useful.

I do not have a particular example to highlight. In fact, I would say that reading all of them (not only some) is what better helped me to have a much more clear idea of what the system was expected to do at the point when the D3.1 [deliverable containing the use case model] was created, that is, in an early phase of the project, when deeply explaining and understanding how everything is supposed to do in more advanced stages of the development is more important.

6.2 Recommendations

Recapping the process we applied, we may give the following recommendations for applying use case modeling in similar settings:

Write the most important use cases first

Start writing use cases even if you are not sure about them; disagreements should be exposed at this stage

Start with basic flows

Select a reasonably expressive yet comprehensible notation

Not everyone needs to participate in writing use cases (this might be only one or two persons), but everyone should be able to see them being created

GUI form wireframes may be useful for GUI design, but are not a supplement for use cases; GUI should reflect use cases, of course, but to design GUI without having a clear idea of use cases and then force developers to decipher use cases from wireframe forms might lead to big misunderstandings

Keep use cases free from user interface notions; with this, the same use case remains valid for different realizations in a mobile application or web application, etc.

We did not update the use case model. It served its purpose and updating it wouldn’t be lean [ 10 ].

Use cases aim at capturing the most important interactions of a human actor with the system. In this, they uncover some of the system structure and how its parts interact with each other. However, unless they are associated with code or directly represented within it [ 2 , 3 , 10 ], this is always limited. Thus, our use cases deal with the services the rurAllure system offers, but they do not cover the details of these services. For example, they do not cover the accessibility aspects, which are the responsibility of the planning service, such as feasible daily distances, mobility impairments, feasibility of the detours, the condition of the paths, etc.

While GUI form wireframes, such as the one depicted in Fig.  7 , were designed before we started writing use cases, associating them with use cases helped validate their purpose and better understand them. The GUI form wireframe in the figure is related to these use cases: Generate a Pilgrimage Plan, Adopt a Pilgrimage Plan, Register as a Pilgrim, Log In, and Update my Account.

Specific route portal home interface wireframe

6.3 Beyond original use cases

The meaningfulness of the proposed tourist experiences is largely embedded in the notions of featured trips and narratives. The use cases do not provide insight into how they should be designed; rather, we are gaining experience in the pilot elaborations of selected routes about what makes an interesting trip for different audiences, how narratives can weave together multiple bits of information cohesively, etc.

In the current state of development, we are going beyond the originally assumed ways to use the rurAllure system. For example, accessibility experiments were conducted with blind people, with a featured trip and a narrative that contained 3D-printed materials that helped the travelers discover the geology of the place (namely, the thermal area of Bagno Vignoni, in the Tuscany region of Italy, found along the Via Francigena). This is not a failure of the use cases. On the contrary, the use case model helped us get quickly to a consistent implementation of the system that can be experimented with further in different ways.

6.4 Threats to validity

From the point of view of construct validity, we can say that the setting in which we applied our approach was a real setting, and not an artificially constructed one.

Not having implemented all use cases and changes in their implementation might indicate that the approach is not fully valid, which represents a threat to internal validity. However, the vast majority of use cases has been implemented. Furthermore, understanding of use cases evolves over time and the authors were actually involved in this for the rurAllure project. The decision not to implement some uses cases was based on project priorities and resources, and not on irrelevance or low quality of use case descriptions.

The approach and recommendations reported here have been applied only within one project setting. However, the project setting was fairly complex and it is reasonable to expect that the approach and recommendations are valid for similar settings.

We did not actually try to run the project without employing our approach, so we cannot know whether it really helps. This represents a threat to conclusion validity. However, this is not completely true. The project proposal writing and initial discussions within the consortium left an impression of a consensus over what has to be implemented. But—as we started with use case modeling—disagreements started to arise, and use cases helped sort them out (see Sect.  3.4 ).

7 Related work

In his short retrospective on use cases published in 2004 [ 15 ], Jacobson says:

I am still reluctant to suggest that system analysts describe use cases in a more formal way than simple text. Avoid trying to specify the internals of each use case with diagrams such as activity diagrams or state charts, although it is good to describe the interactions between a use case and actors with sequence diagrams or activity diagrams with swimlanes.

What we did is pretty much in line with Jacobson’s viewpoint. It is worthwhile to note that we didn’t know about this retrospective at the time of creating our use case model.

Bispo et al. [ 1 ] identified 13 different strategies for use case modeling published in 39 papers between 2008 and 2018. These include using ontologies, antipattern identification, role playing, natural language processing, scenario patterns, using business process notations, domain specific languages, use case fragments, means of distributed communication, visual mental models, visual languages, reverse engineering, and automatic use case diagram layout. The category we can identify with to some extent is the one based on the use of the means of distributed communication. However, our strategy for use case modeling is probably best denoted as lean: only as much of use case modeling as it is needed to explore and understand what needs to be done.

Tiwari and Gupta [ 24 ] identified twenty different use case templates in the papers published between 1992 and 2014. The way we wrote our use cases is closest to what Jacobson and Cockburn proposed. According to Tiwari and Gupta [ 24 ], Jacobson’s notation is the most cited one, while Cockburn’s is the third most cited. The second one is Kruchten’s, which is similar to these two, apart from introducing keywords [ 24 ].

The implementation of the uses cases discussed in this paper ran practically in use case slices, just as recommended by Jacobson et al. [ 17 ], although not in a formal manner. Nevertheless, we can confirm that we treated the most important functionality in most important use cases first and that we worked in parallel on multiple use cases.

Apart from Jacobson et al. [ 17 ], several other authors reported achieving good results with applying use case modeling in agile software development [ 12 , 19 , 20 , 22 ], also in synergy with user stories [ 23 ], but they are not as specific as we are as to what to apply and how to apply it from all the possibilities that use case modeling offers. Furthermore, we found no papers dealing with applying use case modeling in research settings.

8 Conclusions and further work

With so much confusion around use case modeling, software developers may be reluctant to apply it. However, use cases are easy to apply and have great benefits even in research settings with nonprofessional software developers involved. We report on our experience on this within an innovative tourist information system developed in a research setting of an ongoing Horizon 2020 project named Promotion of Rural Museums and Heritage Sites in the Vicinity of European Pilgrimage Routes (rurAllure). The resulting use case model comprises forty use cases supported by class diagrams, use case diagrams, sequence diagrams, as well as by the domain model and dictionary. Three quarters of use cases have been implemented at least to some extent. Based on this, we provide a set of recommendations for applying use case modeling in similar settings.

The paper also exposes the domain model and dictionary along with selected use cases and the hierarchy of user and system actors, which may be useful as such or as a stimulus for the development of other innovative tourist information systems.

Writing use cases provoked intense communication, which helped consolidate the system architecture. The use cases helped validate and better understand the GUI form wireframes designed beforehand and get quickly to a consistent implementation of the system that can be experimented with further in different ways. Finally, the forthcoming extensive system and user experience testing will be guided by the use case model.

https://rurallure.eu/ .

This is not to say that use case modeling cannot be used to capture just any interaction of a user and a system, or even of different systems or subsystems. However, such interactions are of little value when trying to understand what does a system mean to its users or how a an intended system should be built to really mean something to its users.

https://www.gvam.es/en/ .

Not to be confused with usage narratives.

Also called main flows.

Also called alternate flows.

Bispo, C., Fernandes, S., Magalhães, A.P.: Strategies for use case modeling: A systematic literature review. In: Proceedings of the XXXIII Brazilian Symposium on Software Engineering. ACM, Salvador, Brazil (2019)

Bystrický, M., Vranic, V.: Literal inter-language use case driven modularization. In: Proceedings of LaMOD’16: Language Modularity À La Mode, workshop, Modularity 2016. ACM, Málaga, Spain (2016)

Bystrický, M., Vranic, V.: Preserving use case flows in source code: approach, context, and challenges. Comput. Sci. Inform. Syst. J. (ComSIS) 14 (2), 423–445 (2017)

Article   Google Scholar  

Carroll, J.M.: Five reasons for scenario-based design. Interact. Comput. 13 (1), 43–60 (2000)

Cockburn, A.: Writing Effective Use Cases. Addison-Wesley (2000)

Cockburn, A.: Use case preconditions: a best-kept secret? BATimes, https://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret/ (2012)

Cohn, M.: User Stories Applied: For Agile Software Development. Addison Wesley (2009)

Cooper, A.: The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Sams - Pearson Education, Redwood City, CA, USA (2004)

Google Scholar  

Coplien, J.: The DCI Architecture: Supporting the Agile Agenda (2009). Øredev Developer Conference

Coplien, J., Bjørnvig, G.: Lean Architecture for Agile Software Development. Wiley (2010)

Dalpiaz1, F., Sturm, A.: Conceptualizing requirements using user stories and use cases: A controlled experiment. In: Proceedings of 26th International Working Conference, REFSQ 2020, LNCS 12045. Springer, Pisa, Italy (2020)

Farid, W.M., Mitropoulos, F.J.: Novel lightweight engineering artifacts for modeling non-functional requirements in agile processes. In: Proceedings of IEEE Southeastcon 2012. IEEE, Orlando, FL, USA (2012)

Jacobson, I.: Object-oriented development in an industrial environment. In: Proceedings of 2nd Conference on Object-oriented Programming Systems, Languages, and Applications, OOPSLA 1987. ACM, Orlando, FL, USA (1987)

Jacobson, I.: Object Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley (1992)

Jacobson, I.: Use cases - yesterday, today, and tomorrow. Softw. Syst. Model. 3 (3), 210–220 (2004)

Jacobson, I., Ng, P.W.: Aspect-Oriented Software Development with Use Cases. Addison-Wesley (2004)

Jacobson, I., Spence, I., Kerr, B.: Use-Case 2.0: the hub of software development. ACM Queue 14 (1), 94–123 (2016)

Johnson, J., Henderson, A.: Conceptual Models: Core to Good Design. Springer, Synthesis Lectures on Human-Centered Informatics (2011)

Nawrocki, J., Ochodek, M., Jurkiewicz, J., Kopczynska, S., Alchimowicz, B.: Conceptualizing requirements using user stories and use cases: a controlled experiment. In: Proceedings of 40th International Conference on Current Trends in Theory and Practice of Computer Science, SOFSEM 2014, LNCS 8327. Springer, Nový Smokovec, Slovakia (2014)

O’Neill, I.: In praise of use cases–a paean with a software accompaniment. Comput. Sci. Educ. 28 (1), 65–86 (2018)

Rosson, M.B., Carroll, J.M.: In: J.A. Jacko (ed.) The Human Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications, third edn., chap. Scenario-Based Design. CRC Press (2012)

Santos, N., Pereira, J., Ferreira, N., Machado, R.J.: Modeling in agile software development: Decomposing use cases towards logical architecture design. In: Proceedings of 19th International Conference on Product-Focused Software Process Improvement, PROFES 2018, LNCS 11271. Springer, Wolfsburg, Germany (2018)

Spurrier, G.R., Topi, H.: Synergistically employing user stories and use cases in the practice and teaching of systems analysis and designpractice and teaching of systems analysis and design. Commun. Assoc. Inf. Syst. 51 , 140–178 (2022)

Tiwari, S., Gupta, A.: A systematic literature review of use case specifications research. Inf. Softw. Technol. 67 , 128–158 (2015)

Vranic, V., Luboš Zelinka: A configurable use case modeling metamodel with superimposed variants. Innov. Syst. Softw. Eng. A NASA J. 9 (3) (2013)

Övergaard, G., Palmkvist, K.: Use cases: patterns and Blueprints. Addison-Wesley (2004)

Download references

Acknowledgements

The work reported here received funding from the European Union’s Horizon 2020 research and innovation program under Grant agreement No. 101004887 (rurAllure), the Scientific Grant Agency of Slovak Republic (VEGA) under Grant No. VG 1/0759/19, the Operational Program Integrated Infrastructure for the project: Support of Research Activities of Excellence Laboratories STU in Bratislava, project no. 313021BXZ1, co-funded by the European Regional Development Fund (ERDF), the Slovak Research and Development Agency under the contract No. APVV-16-0213, atlanTTic Research Centre for Telecommunication Technologies, funded by the ERDF and Galician Regional Government, and Spanish Ministry of Education and Science research project TIN2017-87604-R.

Open access funding provided by The Ministry of Education, Science, Research and Sport of the Slovak Republic in cooperation with Centre for Scientific and Technical Information of the Slovak Republic.

Author information

Authors and affiliations.

Institute of Informatics, Information Systems and Software Engineering, Faculty of Informatics and Information Technologies, Slovak University of Technology in Bratislava, Bratislava, Slovakia

Valentino Vranić & Ján Lang

AtlanTTic Research Centre for Information and Communication Technologies, University of Vigo, Vigo, Spain

Martín López Nores & José Juan Pazos Arias

GVAM Guías Interactivas S.L., Madrid, Spain

Jaime Solano & Guillermo Laseca

You can also search for this author in PubMed   Google Scholar

Contributions

VV wrote most of the manuscript text. MLN wrote the part on the limitations of use case modeling in Sect.  6 . JL collected the opinions of the project participants of the rurAllure project. All authors participated in writing of the use cases and domain dictionary and reviewed the manuscript. JL produced the use case and sequence diagrams. VV produced the domain model diagram. JS and GL designed the GUI wireframe forms.

Corresponding author

Correspondence to Valentino Vranić .

Ethics declarations

Conflict of interest.

The authors declare that they have no conflict of interest.

Ethics approval

The research reported here involved observing the actions taken by the rurAllure project participants carrying out their project tasks, which were a part of their project duties. Since project participant actions are normally observed, this research did not introduce any additional ethical burden. No project participant apart from the authors is mentioned by name. All project participants are fully aware that the actions taken by them can be reported in research papers published within the rurAllure project.

Additional information

Publisher's note.

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

A Domain dictionary

Pilgrimage trip A travel to a pilgrimage site (or to some other destination, but planned to a significant extent on paths associated to a pilgrimage tradition), typically taking several days. It can also be understood as a realization of a pilgrimage plan.

Location An exact geographical position, defined by its latitude and longitude. It may stand for a geographical region (e.g., the area of the archaeological site of Montegrotto Terme, the village of Csíksomlyó or the natural park of O Courel), in which case it is its focal point.

Region An area defined by one or more polygons.

Pilgrimage path A sequence of locations that correspond to a physical path (with some official recognition or, at least, connected to some tradition) that leads towards a pilgrimage site or connects several such sites.

Pilgrimage route A collection/set of pilgrimage paths related to the same pilgrimage site(s) or traditions.

Place/activity of interest (POI) A place or activity that someone may find useful or interesting during a pilgrimage trip. The term is intentionally broad in order to view the planning of a pilgrimage trip as a sequence of POIs. The following hyponyms may be used when a more specific meaning is intended: o Pilgrimage site:] A location of religious importance (e.g., Nidaros Cathedral in Trondheim). o Activity/hospitality POI:] A place or activity different from a pilgrimage site that someone may find useful or interesting during a pilgrimage trip. This may be an undertaking that may occur at a given location on specific dates and hours (e.g., visiting a church, museum, or heritage site, participating in a religious celebration or a guided tour, attending a festival or artistic performance, etc.) and with a specific duration. It may imply a change of the location and even be a bundle of services.

Narrative A bundle of multimedia contents (text, audio, images, videos, etc.) synchronized over time and space, offering an interpretation of the heritage found near/along certain POIs of a pilgrimage path.

Daily pilgrimage plan A sequence of POIs to travel from a starting location to a destination location in one day, as a part of a pilgrimage plan.

Pilgrimage plan A sequence of daily pilgrimage plans, plus information about the general preferences indicated by the pilgrim for the whole travel experience, the number of people traveling with them, the mode of mobility (e.g., on foot or by bicycle), etc. A pilgrimage plan can be private (not visible to anyone else), replicable (available to others to replicate and modify as their own plans), or shared (available to others to join with read-only access). Featured pilgrimage plans are provided to be reused for making pilgrims’ own plans.

Pilgrim A user on a pilgrimage trip or planning to undertake a pilgrimage trip.

Vendor A user interested in offering activity/hospitality POIs or certain services to pilgrims who travel on the pilgrimage paths of one or several pilgrimage routes.

Administrator A user with the credentials to supervise the information offered on the web portal for a given pilgrimage route. This includes creating POIs, approving vendors and their offerings, uploading narratives, supervising POIs retrieved from third-party sources, creating featured pilgrimage plans, etc.

User: Any user of the system (initial description introduced in Sect.  4 ):

Pilgrim: A user on a pilgrimage trip or planning to undertake a pilgrimage trip.

Vendor: A user interested in offering activity/hospitality POIs or certain services to pilgrims who travel on the pilgrimage paths of one or several pilgrimage routes.

Some vendors may be recorded as providing service within a certain region (e.g., transport and emergencies).

Administrator: A user with the credentials to supervise the information offered on the web portal for a given pilgrimage route: creating POIs, approving vendors and their offerings, uploading narratives, supervising POIs retrieved from third-party sources, creating featured pilgrimage plans, etc.:

Route administrator: An administrator responsible for route management.

Superadministrator: An administrator who may create route administrators. Creating such administrators will be done directly at the development level.

System: The hardware and software that make up the IT platform of rurAllure:

Web portal: A set of web pages offering interfaces for all users to accomplish their goals when using the system. Internally, the web portal will comprise different systems:

Mobile application: An application for a mobile operating system (e.g., Android or iOS) offering functionalities for pilgrims en-route: getting indications and POI recommendations, playing out narratives, rating POIs and narratives, contacting with vendors or emergency services, reporting incidents, etc.

Service (some of the service invocations are not mentioned explicitly in use cases):

Planning service: A software module providing pilgrimage trip planning capabilities to pilgrims, taking as a reference the pilgrimage paths that make up a pilgrimage route.

Recommendation service: A software module providing recommendations to pilgrims about POIs that they may be interested in, in the vicinity of the locations traversed in their current pilgrimage plan.

Narratives service: A software module that manages and recommends the bundles of multimedia content that may be offered to the pilgrims to consume during certain parts of a pilgrimage plan.

Matchmaking service: A software module notifying pilgrims about existing pilgrimage plans that they may join or reuse to create personalized plans of their own.

Social service: A software module managing the groups of pilgrims who have joined a shared pilgrimage plan. It provides simple means for pilgrims to suggest modifications to the plan, which only the owner can materialize.

Info retrieval service: A collection of modules retrieving information from selected sources (CSV files coming from spreadsheet or database exports, RSS feeds that may wrapp selected social media accounts, etc.) in order to create new POIs in the CMS.

Bookings service: A software module offering simple tools to manage bookings of services provided by vendors, as an alternative to just leaving their contact information to manage bookings offline or referring the users to external websites.

FAIR research data service: A software module that monitors the activities of the other services in order to make the research data generated within the project available to the scientific community, in the shape of open and anonymized datasets.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/ .

Reprints and permissions

About this article

Vranić, V., Lang, J., Nores, M.L. et al. Use case modeling in a research setting of developing an innovative pilgrimage support system. Univ Access Inf Soc (2023). https://doi.org/10.1007/s10209-023-01047-1

Download citation

Accepted : 14 September 2023

Published : 03 November 2023

DOI : https://doi.org/10.1007/s10209-023-01047-1

Share this article

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

• Software modeling
• Agile software development
• Research and development projects
• Rural tourism
• User stories

Advertisement

• Find a journal
• Publish with us
• Track your research

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.

Designing A Use Case Diagram For Developing An Electricity Consumption (EC) System

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.

• System Design Tutorial
• What is System Design
• System Design Life Cycle
• High Level Design HLD
• Low Level Design LLD
• Design Patterns
• UML Diagrams
• System Design Interview Guide
• Crack System Design Round
• System Design Bootcamp
• System Design Interview Questions
• Microservices
• Scalability

Use Case Diagrams | Unified Modeling Language (UML)

• Class Diagram | Unified Modeling Language (UML)
• Unified Modeling Language (UML) Diagrams
• Activity Diagrams | Unified Modeling Language (UML)
• Collaboration Diagrams | Unified Modeling Language(UML)
• Behavioral Diagrams | Unified Modeling Language(UML)
• Object Diagrams | Unified Modeling Language (UML)
• Sequence Diagrams | Unified Modeling Language (UML)
• Class Diagrams vs Object Diagrams | Unified Modeling Language(UML)
• Deployment Diagram in Unified Modeling Language(UML)
• Structural Diagrams | Unified Modeling Language(UML)
• Conceptual Model of the Unified Modeling Language (UML)
• Which UML Diagrams are mostly used?
• Package Diagram | Introduction, Elements, Use Cases and Benefits
• How to Design ER Diagrams for Legal Case Management Systems
• Use Case Diagram for Online Banking System
• Top 7 UML Diagram Tools That You Can Consider
• Timetable Generating System UML diagram
• Introduction to UML Diagrams
• Difference between UML and ER diagram
• How To Configure Amazon Route 53 In AWS
• Bash Scripting - If Statement
• How to Set Upstream Branch on Git?
• MVC Framework Introduction
• Comparable Interface in Java with Examples
• Spring Boot - Sending Email via SMTP
• Best Way to Master Spring Boot – A Complete Roadmap
• How to Embed PDF file using HTML ?
• How to upload image and Preview it using ReactJS ?
• Java Developer Learning Path – A Complete Roadmap

A Use Case Diagram is a vital tool in system design, it provides a visual representation of how users interact with a system. It serves as a blueprint for understanding the functional requirements of a system from a user’s perspective, aiding in the communication between stakeholders and guiding the development process.

Important Topics for the Use Case Diagrams

• What is a Use Case Diagram in UML?
• Use Case Diagram Notations
• Use Case Diagram Relationships
• How to draw a Use Case diagram in UML?
• What are common Use Case Diagram Tools and Platforms?
• What are Common Mistakes and Pitfalls while making Use Case Diagram?
• What can be Use Case Diagram Best Practices?
• What are the Purpose and Benefits of Use Case Diagrams?

1. What is a Use Case Diagram in UML?

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents the interaction between actors (users or external systems) and a system under consideration to accomplish specific goals. It provides a high-level view of the system’s functionality by illustrating the various ways users can interact with it.

2. Use Case Diagram Notations

UML notations provide a visual language that enables software developers, designers, and other stakeholders to communicate and document system designs, architectures, and behaviors in a consistent and understandable manner.

1.1. Actors

Actors are external entities that interact with the system. These can include users, other systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases and receive the outcomes. Proper identification and understanding of actors are crucial for accurately modeling system behavior.

1.2. Use Cases

Use cases are like scenes in the play. They represent specific things your system can do. In the online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or “Update Product Information”. Use cases are represented by ovals.

1.3. System Boundary

The system boundary is a visual representation of the scope or limits of the system you are modeling. It defines what is inside the system and what is outside. The boundary helps to establish a clear distinction between the elements that are part of the system and those that are external to it. The system boundary is typically represented by a rectangular box that surrounds all the use cases of the system.

Purpose of System Boundary:

• Scope Definition: It clearly outlines the boundaries of the system, indicating which components are internal to the system and which are external actors or entities interacting with the system.
• Focus on Relevance: By delineating the system’s scope, the diagram can focus on illustrating the essential functionalities provided by the system without unnecessary details about external entities.

3. Use Case Diagram Relationships

In a Use Case Diagram, relationships play a crucial role in depicting the interactions between actors and use cases. These relationships provide a comprehensive view of the system’s functionality and its various scenarios. Let’s delve into the key types of relationships and explore examples to illustrate their usage.

3.1. Association Relationship

The Association Relationship represents a communication or interaction between an actor and a use case. It is depicted by a line connecting the actor to the use case. This relationship signifies that the actor is involved in the functionality described by the use case.

Example: Online Banking System

• Actor: Customer
• Use Case: Transfer Funds
• Association: A line connecting the “Customer” actor to the “Transfer Funds” use case, indicating the customer’s involvement in the funds transfer process.

3.2. Include Relationship

The Include Relationship indicates that a use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the including use case to the included use case. This relationship promotes modular and reusable design.

Example: Social Media Posting

• Use Cases: Compose Post, Add Image
• Include Relationship: The “Compose Post” use case includes the functionality of “Add Image.” Therefore, composing a post includes the action of adding an image.

3.3. Extend Relationship

The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions. It is represented by a dashed arrow with the keyword “extend.” This relationship is useful for handling optional or exceptional behavior.

Example: Flight Booking System

• Use Cases: Book Flight, Select Seat
• Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case when the user wants to choose a specific seat, but it is an optional step.

3.4. Generalization Relationship

The Generalization Relationship establishes an “is-a” connection between two use cases, indicating that one use case is a specialized version of another. It is represented by an arrow pointing from the specialized use case to the general use case.

Example: Vehicle Rental System

• Use Cases: Rent Car, Rent Bike
• Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions of the general use case “Rent Vehicle.”

4. How to draw a Use Case diagram in UML?

Step 1: identify actors.

Determine who or what interacts with the system. These are your actors. They can be users, other systems, or external entities.

Step 2: Identify Use Cases

Identify the main functionalities or actions the system must perform. These are your use cases. Each use case should represent a specific piece of functionality.

Step 3: Connect Actors and Use Cases

Draw lines (associations) between actors and the use cases they are involved in. This represents the interactions between actors and the system.

Step 4: Add System Boundary

Draw a box around the actors and use cases to represent the system boundary. This defines the scope of your system.

Step 5: Define Relationships

If certain use cases are related or if one use case is an extension of another, you can indicate these relationships with appropriate notations.

Step 6: Review and Refine

Step back and review your diagram. Ensure that it accurately represents the interactions and relationships in your system. Refine as needed.

Step 7: Validate

Share your use case diagram with stakeholders and gather feedback. Ensure that it aligns with their understanding of the system’s functionality.

Let’s understand how to draw a Use Case diagram with the help of an Online Shopping System:

2. use cases:.

• Browse Products
• Add to Cart
• Manage Inventory (Admin)

3. Relations:

• The Customer can browse products, add to the cart, and complete the checkout.
• The Admin can manage the inventory.

Below is the usecase diagram of an Online Shopping System:

5. What are common Use Case Diagram Tools and Platforms?

Several tools and platforms are available to create and design Use Case Diagrams. These tools offer features that simplify the diagram creation process, facilitate collaboration among team members, and enhance overall efficiency. Here are some popular Use Case Diagram tools and platforms:

6.1. Lucidchart

• Cloud-based collaborative platform.
• Intuitive drag-and-drop interface.
• Real-time collaboration and commenting.
• Templates for various diagram types.
• Integration with other tools like Jira and Confluence.

6.2. draw.io

• Free, open-source diagramming tool.
• Works offline and can be integrated with Google Drive, Dropbox, and others.
• Offers a wide range of diagram types, including Use Case Diagrams.
• Customizable shapes and themes.

6.3. Microsoft Visio

• Part of the Microsoft Office suite.
• Supports various diagram types, including Use Case Diagrams.
• Integration with Microsoft 365 for collaborative editing.
• Extensive shape libraries and templates.

6.4. SmartDraw

• User-friendly diagramming tool.
• Templates for different types of diagrams, including Use Case Diagrams.
• Integration with Microsoft Office and Google Workspace.
• Auto-formatting and alignment features.

6.5. PlantUML

• Open-source tool for creating UML diagrams.
• Text-based syntax for diagram specification.
• Integrates with various text editors and IDEs.
• Supports collaborative work using version control systems.

6. What are Common Mistakes and Pitfalls while making Use Case Diagram?

Avoiding common mistakes ensures the accuracy and effectiveness of the Use Case Diagram. Here are key points for each mistake:

6.1. Overcomplication:

• Mistake: Including excessive detail in the diagram.
• Impact: Confuses stakeholders and complicates understanding.
• Prevention: Focus on essential use cases and maintain an appropriate level of abstraction.

6.3. Ambiguous Relationships:

• Mistake: Unclear relationships between actors and use cases.
• Impact: Causes misinterpretation of system interactions.
• Prevention: Clearly define and label relationships with proper notation.

6.3. Inconsistent Naming Conventions:

• Mistake: Inconsistent naming of actors and use cases.
• Impact: Causes confusion and hinders communication.
• Prevention: Establish and adhere to a consistent naming convention.

6.4. Misuse of Generalization:

• Mistake: Incorrect use of generalization relationships.
• Impact: Misrepresentation of the “is-a” relationship between use cases or actors.
• Prevention: Ensure accurate usage to represent specialization relationships.

6.5. Overlooking System Boundaries:

• Mistake: Not clearly defining the system boundary.
• Impact: Challenges understanding of the system’s scope.
• Prevention: Clearly enclose relevant actors and use cases within a system boundary.

6.6. Lack of Iteration:

• Mistake: Treating the diagram as a static artifact.
• Impact: May become outdated and not reflect the current state of the system.
• Prevention: Use an iterative approach, updating the diagram as the system evolves.

7. What can be Use Case Diagram Best Practices?

Creating effective and clear Use Case Diagrams is crucial for communicating system functionality and interactions. Here are some best practices to follow:

7.1 Keep it Simple:

• Focus on High-Level Functionality: Avoid unnecessary details and concentrate on representing the system’s primary functionalities.
• Use Concise Language: Use clear and concise language for use case and actor names to enhance readability.

7.2 Consistency:

• Naming Conventions: Maintain a consistent naming convention for use cases and actors throughout the diagram. This promotes clarity and avoids confusion.
• Formatting Consistency: Keep a consistent format for elements like ovals (use cases), stick figures (actors), and lines to maintain a professional look.

7.3. Organize and Align:

• Logical Grouping: Organize use cases into logical groups to represent different modules or subsystems within the system.
• Alignment: Maintain proper alignment of elements to make the diagram visually appealing and easy to follow.

7.4. Use Proper Notation:

• Consistent Symbols: Adhere to standard symbols for actors (stick figures), use cases (ovals), and relationships to ensure understanding.
• Proper Line Types: Clearly distinguish between association, include, extend, and generalization relationships using appropriate line types.

7.5. Review and Iterate:

• Feedback Loop: Regularly review the diagram with stakeholders to ensure accuracy and completeness.
• Iterative Process: Use an iterative process, updating the diagram as the system evolves or more information becomes available.

By following these best practices, you can create Use Case Diagrams that effectively communicate the essential aspects of a system, fostering a shared understanding among stakeholders and facilitating the development process.

8. What are the Purpose and Benefits of Use Case Diagrams?

The Use Case Diagram offers numerous benefits throughout the system development process. Here are some key advantages of using Use Case Diagrams:

• Use Case Diagrams provide a visual representation of the system’s functionalities and interactions with external entities.
• This visualization helps stakeholders, including non-technical ones, to understand the system’s high-level behavior.
• Use Case Diagrams serve as a powerful communication tool, facilitating discussions between stakeholders, developers, and designers.
• They provide a common language for discussing system requirements, ensuring a shared understanding among diverse team members.
• During the requirements analysis phase, Use Case Diagrams help in identifying, clarifying, and documenting user requirements.
• They capture the various ways users interact with the system, aiding in a comprehensive understanding of system functionality.
• Use Case Diagrams center around user goals and scenarios, emphasizing the perspective of external entities (actors).
• This focus on user interactions ensures that the system is designed to meet user needs and expectations.
• In the system design phase, Use Case Diagrams aid in designing how users (actors) will interact with the system.
• They contribute to the planning of the user interface and help in organizing system functionalities.
• Use Case Diagrams are valuable for deriving test cases and validating system behavior.
• Testers can use the diagrams to ensure that all possible scenarios, including alternative and exceptional paths, are considered during testing.

9. Conclusion

In conclusion, a Use Case Diagram in UML serves as a powerful tool for capturing and visualizing the functional requirements and interactions within a system. By representing actors, use cases, and their relationships in a clear and concise manner, this diagram provides a high-level overview of the system’s behavior.

Please Login to comment...

Similar reads.

• Geeks Premier League 2023
• Geeks Premier League
• System Design

Improve your Coding Skills with Practice

What kind of Experience do you want to share?