=Paper=
{{Paper
|id=None
|storemode=property
|title=Modeling Crisis Management System With the Restricted Use Case Modeling Approach
|pdfUrl=https://ceur-ws.org/Vol-1076/paper2.pdf
|volume=Vol-1076
|dblpUrl=https://dblp.org/rec/conf/models/ZhangYA13
}}
==Modeling Crisis Management System With the Restricted Use Case Modeling Approach==
https://ceur-ws.org/Vol-1076/paper2.pdf
Modeling Crisis Management System With the
Restricted Use Case Modeling Approach
Gong Zhang1, Tao Yue2, and Shaukat Ali3
1 2
School of Computer Science and Simula Research Laboratory
Engineering, Beihang University, P.O. Box 134, Lysaker, Norway
Beijing, China {tao, shaukat}@simula.no
zhanggong@sei.buaa.edu.cn
Abstract. 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.
Keywords: Use Case; Use Case Modeling; Use Case Template; Restriction
Rules.
1 Selection of the Approach
We selected a use case modeling approach called Restricted Use Case Modeling
(RUCM) approach [7, 8]. The goal of RUCM approach is to reduce ambiguity of use
case models and facilitate automated analysis and generation of other diagrams.
RUCM has been systematically and empirically evaluated through case studies to be
easy to apply and leads to higher quality of UML analysis models. RUCM is being
extended to cover more aspects such as real-time, safety, variability and crosscutting
aspects of use case modeling, which all together form the Zen-RUCM framework.
RUCM was initially developed for use case modeling in the object-oriented
paradigm. However, in our recent works, the approach has been extended for aspect-
orientation as well. In this paper, we only used object-oriented version of the RUCM
approach for modeling Crisis Management System (CMS). The approach is for
requirements specification and analysis and our tool called aToucan [7, 8] can
automatically generate initial analysis models from RUCM models. In this paper, we
modeled only a single system since currently we do not support capturing variability
in RUCM specifications, which is one of our ongoing works.
2 Restricted Use Case Modeling (RUCM) Approach
In this section, we describe key constructs of the RUCM approach.
2.1 Use case template
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.
Table 1. Use case template
Use Case Name The name of the use case. It usually starts with a verb.
Brief Description Summarizes the use case in a short paragraph.
Precondition What should be true before the use case is executed.
Primary Actor The actor which initiates the use case.
Secondary Actors Other actors the system relies on to accomplish the services of the use case.
Dependency Include and extend relationships to other use cases.
Generalization Generalization relationships to other use cases.
Basic Flow Specifies the main successful path, also called “happy path”.
Steps (numbered) Flow of events.
Postcondition What should be true after the basic flow executes.
Specific Applies to one specific step of the reference flow.
Alternative Flows RFS A reference flow step number where flow branches
from.
Steps (numbered) Flow of events.
Postcondition What should be true after the alternative flow executes.
Global Applies to all the steps of the reference flow.
Alternative Flows Steps (numbered) Flow of events.
Postcondition What should be true after the alternative flow executes.
Bounded Applies to more than one step of the reference flow, but not all of them.
Alternative Flows RFS A list of reference flow steps where flow branches
from.
Steps (numbered) Flow of events.
Postcondition What should be true after the alternative flow executes.
A basic flow describes a main successful path. It often does not include any
condition or branching [4]. It is recommended to describe separately the conditions
and branching in alternative flows. A basic flow is composed of a sequence of steps
and a postcondition. Each UCS can only have one basic flow. Alternative flows
describe all the other scenarios or branches, both success and failure. An alternative
flow always depends on a condition occurring in a specific step in a flow of reference,
referred to as reference flow, and that reference flow is either the basic flow or an
alternative flow itself. The branching condition is specified in the reference flow by
following restriction rules (R20 and R22—Section 2.2). We refer to steps specifying
such conditions as condition steps and the other steps as action steps. Similarly to the
basic flow, an alternative flow is composed of a sequence of numbered steps. The
action steps can be one of the following five interactions (which are reused from [3]
except for the fifth):
1) Primary actor ! system: the primary actor sends a request and data to the
system;
2) System ! system: the system validates a request and data;
3) System ! system: the system alters its internal state (e.g., recording or
modifying something);
4) System ! primary actor: the system replies to the primary actor with a
result; and
5) System ! secondary actor: the system sends requests to a secondary actor.
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 [1]. A specific alternative flow is
an alternative flow that refers to a specific step in the reference flow. A bounded
alternative flow is a flow that refers to more than one step in the reference flow–
consecutive steps or not. A global alternative flow (called general alternative flow in
[1]) is an alternative flow that refers to any step in the reference flow. Distinguishing
different types of alternative flows makes interactions between the reference flow and
its alternative flows much clearer. For specific and bounded alternative flows, a RFS
(Reference Flow Step) section, specified as rule R19, is used to specify one or more
(reference flow) step numbers. Whether and where the flow merges back to the
reference flow or terminates the use case must be specified as the last step of the
alternative flow. Similarly to the branching condition, merging and termination are
specified by following restriction rules (R24 and R25—Section 2.2). By doing so, we
can avoid potential ambiguity in UCSs caused by unclear specification of interactions
between the basic flow and its corresponding alternative flows. Each alternative flow
must have a postcondition (enforced by restriction rule R26—Section 2.2).
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 Restriction rules
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.
Table 2. Restrictions (R1-R16)
# Description Explanation
R1 The subject of a sentence in basic and alter- Enforce describing flows of events
native flows should be the system or an actor. correctly. These rules conform to
R2 Describe the flow of events sequentially. our use case template (the five
R3 Actor-to-actor interactions are not allowed. interactions).
R4 Describe one action per sentence. (Avoid Otherwise it is hard to decide the
compound predicates.) sequence of multiple actions in a
sentence.
R5 Use present tense only. Enforce describing what the system
does, rather than what it will do or
what it has done.
R6 Use active voice rather than passive voice. Enforce explicitly showing the
R7 Clearly describe the interaction between the subject and/or object(s) of a
system and actors without omitting its sender sentence.
and receiver.
R8 Use declarative sentences only. “Is the system Commonly required for writing
idle?” is a non-declarative sentence. UCSs.
R9 Use words in a consistent way. Keep one term to describe one thing.
R10 Don’t use modal verbs (e.g., might) Modal verbs and adverbs usually
R11 Avoid adverbs (e.g., very). 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., [1, 3, 5])
except for R13 and R15. We add these two rules because we observed that negative
adverbs, negative adjectives, and participle phrases are very difficult to parse by
natural language parsers. R9 requires using words consistently to document UCSs. A
common approach to do so is to use a domain model and glossary (e.g., [4], [2]) as a
basis to write UCSs.
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 [7, 8]. For transforming RUCM
models to UML class, sequence, activity and state machine diagrams, please refer to
our previous work [6, 9, 10].
3 RUCM Model for the Crisis Management System
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 [11], and it is also presented in Appendix. In our model, we
describe how we used the RUCM template and restrictions to specify the use case
specification for use case “Communicate with Other Coordinator”. In addition, we
demonstrate how we use RUCM to specify non-functional requirements provided in
the case study document.
References
1. Bittner K. and Spence I.: Use Case Modeling. Addison-Wesley Boston (2002)
2. Bruegge B. and Dutoit A. H.: Object-Oriented Software Engineering Using UML, Patterns, and Java.
Prentice Hall, 2nd Edition (2004)
3. Cockburn A.: Writing effective use cases. Addison-Wesley Boston (2001)
4. Larman C.: Applying UML and Patterns. Prentice-Hall, 3rd Edition (2004)
5. Schneider G. and Winters J. P.: Applying use cases: a practical guide. Object Technology, Addison-
Wesley (1998)
6. Yue T., Ali S. and Briand L.: Automated Transition from Use Cases to UML State Machines to
Support State-based Testing. Proc. The Seventh European Conference on Modeling Foundations and
Applications (ECMFA) (2011)
7. Yue T., Briand L. and Labiche Y.: Facilitating the Transition from Use Case Models to Analysis
Models: Approach and Experiments. ACM Transactions on Software Engineering and Methodology
(TOSEM), vol. 22 (1). (2013)
8. Yue T., Briand L. C. and Labiche Y.: A Use Case Modeling Approach to Facilitate the Transition
Towards Analysis Models: Concepts and Empirical Evaluation. Proc. MODELS2009, 5795/2009, pp.
484-498 (2009)
9. Yue T., Briand L. C. and Labiche Y.: An Automated Approach to Transform Use Cases into Activity
Diagrams. Proc. 6th ECMFA, LNCS 6138, pp. 337-353 (2010)
10. Yue T., Briand L. C. and Labiche Y.: Automatically Deriving a UML Analysis Model from a Use Case
Model. Simula Research Laboratory, Technical Report 2010-15 (2010)
11. Gong Z., Tao Y. and Shaukat A.: Modeling Crisis Management System with the Restricted Use Case
Modeling Approach. Repository for Model-Driven Development (ReMoDD), October 21. Retrieved
October 28, 2013, http://www.cs.colostate.edu/remodd/v1/content/modeling-
crisis-management-system-restricted-use-case-modeling-approach
Appendix
Use Case: Communicate with Other Coordinator
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.
Non-functional requirements
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 non-
functional properties.