Use case modeling is commonly applied to document requirements. Use case specifications (UCSs) are usually structured, unrestricted textual documents complying with a certain template. However, because they remain essentially textual, ambiguities are inevitable. In our previous work, we proposed a new use case modeling approach, named as Restricted Use Case Modeling (RUCM), which is composed of a set of well-defined restriction rules and a new template. The goal was to reduce ambiguity and facilitate automated analysis. In our works, RUCM has been systematically and empirically evaluated through case studies to be easy to apply and leads to higher quality of UML analysis models. In this paper, we modeled the Crisis Management System (CMS) case study using RUCM and our experience proved that RUCM is easy to apply and sufficient to capture the requirements provided for the case study.
In this section, we describe key constructs of the RUCM approach. 2.1
Our use case template has eleven first-level fields (1st column in Table 1.). The last four fields are decomposed into second-level fields (2nd column in the last four rows). The last column of each row explains the corresponding field(s). There is no need to further discuss the first seven fields since they are straightforward and commonly encountered in many templates. Below we focus the discussion on the Basic Flow and Alternative Flows fields.
A basic flow describes a main successful path. It often does not include any
condition or branching [
All steps are numbered sequentially. This implies that each step is completed before the next one is started. If there is a need to express conditions, iterations, or concurrency, then specific keywords, specified as restriction rules should be applied.
We classify alternative flows into three types: specific, global, and bounded
alternative flows. This classification is adapted from [
It is usual to provide a postcondition describing a constraint that must be true when a use case terminates. If the use case contains alternative flows, then the postcondition of the use case should describe not only what must be true when the basic flow terminates but also what must be true when each alternative flow terminates. The branching condition to each alternative flow is then necessarily part of the postcondition (to distinguish the different possible results). In such a case, the postcondition becomes complex and the branching condition for each alternative flow is redundantly described (both in the steps of flows and the postcondition), which therefore increases the risk of ambiguity in UCSs. Our template enforces that each flow of events (both basic flow and alternative flows) of a UCS contains its own postcondition and therefore avoids such ambiguity. 2.2
The restriction rules are classified into two groups: restrictions on the use of natural language, and restrictions enforcing the use of specific keywords for specifying control structures. The first group of restrictions is further divided into two categories according to their location of application (see below). Each restriction rule is assigned a unique number.
Commonly required for UCSs.
Keep one term to describe one thing.
Modal verbs and adverbs usually indicate uncertainty; therefore metrics should be used if possible.
R12 Use simple sentences only. A simple sentence Reduce ambiguity and facilitate must contain only one subject and one predicate. automated NL parsing.
R13 Don’t use negative adverb and adjective (e.g.,
hardly, never), but it is allowed to use not or no.
R14 Don’t use pronouns (e.g. he, this).
R15 Don’t use participle phrases as adverbial modifier. For example, the italic-font part of the sentence “ATM is idle, displaying a Welcome message”, is a participle phrase.
R16 Use “the system” to refer to the system under Keep one term to describe the design consistently. system; therefore reduce ambiguity.
Restriction rules R1-R16 in Table 2. constrain the use of natural language: the
table explains why they are needed to reduce ambiguity. Rules R1-R7 apply only to
action steps; they do not apply to condition steps, preconditions or postconditions.
Rules R8-R16 apply to all sentences in a UCS: action steps, condition steps,
preconditions, postconditions, and sentences in the brief description. Rules R8-R11
and R16 aim to reduce ambiguity of UCSs; the remaining rules (R12-R15) can help
reduce ambiguity and also facilitate automated generation of analysis models. Recall
that facilitating automated derivation of initial analysis models from UCSs is also one
of our goals, though this is not discussed in this paper. These two sets of restrictions
are thought to be good practice for writing clear and concise UCSs (e.g., [
The remaining ten restriction rules (R17-R26) constrain the use of control structures, except R26 that specifies that each basic flow and alternative flow should have its own postcondition. R17 and R18 specify keywords to describe use case dependencies include and extend. Sentences containing the keywords INCLUDE USE CASE and EXTENDED BY USE CASE are referred to as dependency sentences. R19 specifies keyword RFS, which is used in a specific (or bounded) alternative flow to refer to a step number (or a set of step numbers) of a reference flow that this alternative flow branches from. Rules R20-R23 specify the keywords used to specify conditional logic sentences (IF-THEN-ELSE-ELSEIF-ENDIF), concurrency sentences (MEANWHILE), condition checking sentences (VALIDATES THAT), and iteration sentences (DO-UNTIL), respectively. Keyword VALIDATES THAT (R22) specifies that a condition is evaluated by the system and must be true to proceed to the next step. This rule also requires that an alternative flow describing what happens when the validation fails (the condition does not hold) be described. Rules R24 and R25 specify that an alternative flow ends with a step using either keyword ABORT or keyword RESUME STEP, thereby clearly specifying whether the flow returns back to the reference flow and where (using keyword RESUME STEP followed by a returning step number) or terminates (using keyword ABORT).
R17-R21 and R23 have been proposed in the literature and we reused them with some variation. R22, R24 and R25 are newly proposed in this work for the purpose of making the whole set of restrictions as complete as possible so that flows of events and interactions between the basic flow and the alternatives can be clearly and concisely specified. Applying these rules helps reducing ambiguity in UCSs, and also facilitates automated NL processing (e.g., correctly parse sentences with our specified keywords) and the generation of analysis models, especially sequence diagrams.
The detailed description of RUCM is provided in [
In the requirements specification document of CMS, there is only one use case in the
provided case study and thus we don’t show the use case diagram. The RUCM model
for CMS is available in [
The RUCM template and restriction rules were applied to specify the use case specification for this use case as shown below. The use case specification is composed of one basic flow, six specific alternative flows and two global alternative flows. The control branches from the basic flow to all the alternative flows are clearly specified using RUCM. Restriction rules on natural language were applied to make English sentences more precise. Our own interpretation on some of the use case specification provided in the workshop case study is reflected as part of the model. Notice that we specified postconditions for each of the flow of events.
This use case is used for capture non-functional requirements of the system. These non- functional requirements are global for all the use cases in the use case model, though currently there is only one use case in the use case model. Therefore, we used Global Alternative Flows to capture each non-functional requirement provided in the case study description. Notice that for each non- functional requirement, RUCM naturally provides a mechanism to define an exception handler alternative flow, from which one can describe the scenario when the non-functional requirement is not met. As for specifying functional requirements, RUCM also enforces each flow of events to their own postconditions. By modeling this case study, we are confident that RUCM can also be used to either directly or with some adaption to capture nonfunctional properties.