Producing Robust Use Case Diagrams via Reverse Engineering of
Use Case Descriptions
MOHAMED EL-ATTAR AND JAMES MILLER
STEAM Laboratory
Electrical and Computer Engineering Department
University of Alberta
melattar@ece.ualberta.ca
jm@ece.ualberta.ca
Summary
In a use case driven development process, a use case model is utilized by a development team to
construct an object-oriented software system. The large degree of informality in use case models,
coupled with the fact that use case models directly affect the quality of all aspects of the development
process, is a very dangerous combination. Naturally, informal use case models are prone to contain
problems, which lead to the injection of defects at a very early stage in the development cycle. In this
paper, we propose a structure named SUCD that will aid the detection and elimination of potential
defects caused by inconsistencies present in use case models. The SUCD structure contains a small
set of formal constructs that will allow use case models to be machine readable while retaining their
readability by containing a large degree of unstructured natural Language. In this paper we also
propose the REUCD process which utilizes the SUCD structured use cases to systematically generate
their corresponding use case diagrams and vice versa. To demonstrate the feasibility of this approach
and the application of the SUCD structure and the REUCD process, a simple study is conducted
using a mock online hockey store system.
1
Introduction
Use case modeling [37], since it was introduced in the early 1990s by Ivar Jacobson has been
constantly gaining wide acceptance by analysts, designers, testers and other stakeholders of a project.
Use case modeling can be used to drive the design phase [21, 22, 25, 32, 38, 41], the testing phase
[28] and can be utilized for managerial purposes such as effort estimation [3] and business modeling
[26]. The success experienced by use case modeling is chiefly because the technique is very simple
to use in order to effectively describe the functional requirements of a system. Another attractive
aspect of use case modeling is that it contains a small diagrammatic notational subset and a large
degree of natural language. This allows all stakeholders of a project to understand the use case model,
even those who are not technically equipped, which in turn will ensure that all stakeholders have a
common understanding and agreement upon the capabilities and features of the system.
The large degree of informality contained in the use case descriptions often causes use case
descriptions to be inconsistent with their corresponding use case diagrams. Moreover, inconsistencies
may reside within the use case descriptions themselves. In a use case driven approach [25] such as the
Rational Unified Process (RUP) [29, 30, 39], use case models are used to produce other UML
artifacts such as activity and sequence diagrams [21, 22, 25, 32, 38, 41]. Hence, it is important to
invest in producing high quality use case models that will yield the production of other high quality
UML artifacts. Consistency is a key quality attribute of use case models [4, 8, 19, 24, 31, 41].
Ensuring the consistency between use case descriptions and their corresponding diagrams requires a
great deal of discipline from analysts, which seldom exists. Moreover, producing consistent use case
models have been chiefly dependant on the experience of analysts. It is common knowledge that the
expertise of analysts in industry varies significantly. Often, junior analysts are required to develop use
case models, which will be highly vulnerable to inconsistencies. The produced inconsistent use case
models may potentially lead to the production of low quality software systems. Therefore, it is
essential to devise a structure that will aid the production of consistent use case descriptions. It is also
important that this structure can be used to ensure the consistency between the use case descriptions
and their corresponding diagrams; while maintaining the ability of these diagrams to be
understandable to all stakeholders.
In this paper we propose a structure to assist with the description of use cases. The proposed use case
description structure is called Structured Use Case Description (SUCD). SUCD will serve as a
guideline for authors in producing their use cases. Moreover, the SUCD form will allow the use case
descriptions to be machine readable. In this paper we devised a technique named Reverse
Engineering of Use Case Diagrams (REUCD), which will systematically generate use case diagrams
from use cases that are described in the SUCD form. Use case diagrams are developed at a much
higher level of abstraction than use case descriptions. Hence, use case diagrams can be accurately
reverse engineered from use case descriptions using REUCD. REUCD will only extract certain
information from the use case descriptions to generate use case diagrams. Fig. 1 shows an overview
of SUCD and REUCD. In this paper, we present our featured tool AREUCD, which will automate the
REUCD process and increase the speed and accuracy of its application.
2
Fig. 1 The application of the REUCD process to systematically generate use case diagrams from
descriptions
The REUCD process may also be reversed, whereby the use case diagram is initially developed and
used to systematically generate the ‘skeletons’ of the use case descriptions. Details about the events
occurring in the use cases can be manually completed later on by the analysts. This concept is
discussed in further detail in section 4. However, the theme throughout this paper will be aimed at
initially composing use case descriptions then systematically generating the diagrams from them. The
reason being that use case descriptions contain all the information required to produce a complete use
case diagram.
The remainder of this paper is organized as follows; in section 2 we present a brief introduction to use
case modeling and various use case authoring styles and structures. Section 2 also describes why
inconsistencies exist in to use case models and what their potential consequences are. Section 3
presents a detailed description of the proposed use case description structure SUCD. Section 4
describes how use cases described in the SUCD form can be used to systematically produce use case
diagrams. Section 4 also outlines the consistency rules that are required to ensure that the use case
descriptions and their diagrams are consistent. An overview of the featured tool AREUCD is
presented in Section 5. In Section 6 we present a simplified online hockey team store system to
demonstrate the application of SUCD, REUCD and AREUCD. Finally, Section 7 concludes and
suggests future work for systematically generating other UML artifacts.
3
2
2.1
Background
Brief Introduction to Use Case Modeling
This section presents a brief overview of use case modeling. A use case model contains three main
components. Firstly, the use case diagram, which contains two main components: use cases and
actors. Use cases are depicted as ovals, and they serve as a visual summary of the services that are
offered by the system to its actors. Actors are a class of users of the system who can benefit from one
or more services offered by the system. A use case diagram also shows the relationships that exist
between the use cases and the actors and between the use cases themselves. Secondly, the use case
descriptions. The use case descriptions essentially describe the flow of events required to occur in
order for an actor to benefit from a service offered by the corresponding use case [12]. There must be
one use case description corresponding to each of the use cases depicted in the use case diagram.
Traditionally, descriptions are authored in textual form. Lastly, a use case model makes use of a
glossary component. The glossary is not explicit to use case models, it is used for other activities
during development. The glossary will contain the explanations of common terms used throughout a
project.
There are several types of use cases. A base use case describes a service that a system offers to its
actors. A base use case may have a set of subflows and alternative flows. A base use case may also be
specialized or generalized. A specialized use case describes a specialized version of the workflow that
is described by its parent use case. Actions in a generalized use case are usually tailored and altered to
meet the needs of the services offered by its specializing use case. Moreover, a specialized use case
often inserts additional actions to that present in the generalized use case.
An extension use case is only initiated if certain given conditions are satisfied. The initiation of an
extension use case causes the behavior described in the extension use case to be ‘inserted’ into the
base use case it extends It has been argued by [10] that extension use cases are much like alternative
flows. The main semantic difference between extension use cases and alternative flows is that the
base use case is unaware of the behavior contained in the extension use case, meanwhile it is aware of
all the alternative flows that it contains. This required lack of knowledge that the base use case should
have about an extension use case means that the behavior described in the base use case should be
complete and meaningful even if the extension use case was removed all together.
When a base use case is performed, it utilizes the behavior contained in the inclusion use cases it
includes. Upon completion of performing the behavior contained in an inclusion use case, the
behavior contained in the base use case continues to be performed from the point where it was
interrupted to allow the inclusion use case to be performed. Thus, inclusion use cases are usually
included by more than one base use case. If the inclusion use case is included by one base use case, it
is then most likely that the base use case acquires the behavior of the inclusion use case in more than
one location.
4
2.2
Use Case Authoring Styles
There have been many different approaches to authoring use case descriptions. Each approach is
devised to describe use cases at different levels of detail and structure. For example, use cases can be
described using a single short paragraph. Caution must be exercised while describing use cases in
such form as this approach tends to assume that other stakeholders have a great degree of domain
knowledge, which is not necessarily always the case. On the other hand, use cases can be described
using a full blown approach that mentions every possible detail. Some approaches structure the use
case descriptions very carefully, while others do not incorporate any structure. Johansson [27]
analyzed and discussed problems that arose when attempting to construct a use case model and write
the corresponding descriptions of use cases for a weather station system. The problems were mainly
caused due to lack of guidelines for authoring use case descriptions. The paper concludes by urging
for guidelines to use case modeling.
Achour et al [8] examined two different types of guidelines; styling guidelines (SGs) and content
guidelines (CGs). The styling guidelines were mainly derived from current best practices such as
those presented in [15, 16]. The styling guidelines are used to improve the quality of the use cases’
structures. On the other hand, content guidelines were mainly derived from linguistics, artificial
intelligence and previous experiences in applying Case Grammars to requirements analysis. The
content guidelines are used to indicate the expected contents of use cases. The authors presented
seven hypotheses, three of which are related to CGs and the remaining four are related to SGs. The
experimental procedure utilized 69 software engineers, who were full-time or part-time students at the
University of Paris I - Sorbonne. All the subjects had professional experience and were all subjected
to a half day presentation on use case authoring and modeling. The results of the empirical studies
conclude that use case authoring guidelines generally do improve the quality of the use case
descriptions. The authors emphasize that even though authoring guidelines help produce better use
case descriptions, they rarely lead to perfect use cases. Therefore, the authors suggest that the use case
descriptions should be checked whenever quality is an issue.
Firesmith [19] describes a broader range of guidelines. These guidelines were proven to be effective
according to the author’s experience. These guidelines fall into the following categories: modeling
tools and languages; modeling externals; modeling use cases; modeling use case paths; and general
guidelines.
A number of use case authoring guidelines have been devised to capture the requirements for special
types of systems. Anderson et al. [6] described styles of documenting business rules in use cases.
Constantine [17] and Biddle et al. [9] described styles that lead to ‘essential’ use cases. Essential use
cases are aimed at capturing the requirements for user interfaces. The principle advantage of essential
use cases is that they do not require any refinements (transformation to other types of diagrams),
which will allow for the concurrent development of the user interface and other object-oriented
design artifacts. Rebecca [45] promoted a conversational style of authoring use cases.
Cockburn [16] described a set of eighteen different styles of writing use case descriptions. Cockburn
came across these styles while working on various projects. Jacobson [25] proposed one of the
5
authoring styles, which Cockburn has encountered. The authoring style proposed by Jacobson was
heavily popularized due to its adoption by the Rational Unified Process. The work presented by
Bittner and Spence [10] further developed this style of use case authoring. However, this style in its
current state experiences several limitations:
a) The authoring style lacks the required amount of structure to allow the use case descriptions to be
machine readable, which will impede the systematic process of:
o Generating use case diagrams from the descriptions.
o Generating the ‘skeletons’ of use case descriptions from the diagrams.
o Verifying the consistency between the use case diagram and the descriptions.
o Determining the flows of events within a use case and the flows of events between use
cases.
b) There is no mechanism available to:
o Declare generalization relationships between use cases.
o Declare generalization relationships between actors.
o Declare abstract use cases.
o Declare abstract actors.
o Declare that a use case implements an abstract use case.
o Systematically identify the exact location that behavior in extension use cases will be
inserted.
o Differentiate between public and private extension points.
o Allow an extension use case to reference the base use case it extends.
o Systematically differentiate between the actions that are performed by the system’s actors
and the actions that are performed by the system itself.
In this paper, we build upon the style developed by [10] mainly due to its effectiveness, clarity and
popularity. The authoring style proposed in this paper contains further structure required to overcome
the limitations outlined above. The key feature of the proposed structure (SUCD) is that it will ensure
the consistency between the use case descriptions and their corresponding diagrams.
2.3
Maintaining the Readability of Use Case Descriptions
The core feature behind the popularity of use case models is the great deal of unstructured natural
Language that the use case descriptions contain. The informality contained in use case descriptions
makes it accessible by stakeholders who are not technically equipped and not familiar with common
programming jargon and acronyms. Customers are often not technically equipped and thus the
informality in use case descriptions allows them to read and review the use case descriptions and
provide feedback. Unstructured natural Language is an indispensable component of use case
descriptions. Unfortunately, it is impossible to formally analyze use case descriptions that are
completely composed of unstructured natural Language. Use case descriptions become highly
vulnerable to poor quality attributes such as inconsistencies, incorrectness and incompleteness. Use
case descriptions can be formally analyzed only if they adhere to a formal structure. However,
describing use cases using only formal constructs will greatly reduce their readability and make them
inaccessible by all stakeholders. Therefore, a tradeoff exists between the amount of unstructured
6
natural Language and formal constructs that the use case descriptions may contain. The SUCD
structure provides a hybrid solution to this problem. The SUCD structure contains a very limited set
of formal constructs while allowing analysts the flexibility and liberty of using as much unstructured
natural Language as required. The SUCD structure will allow a great deal of formal analysis to be
performed on the descriptions while retaining their readability.
2.4
The Problem with Inconsistencies in Use Case Models
Many researchers have determined that inconsistencies in a use case model have harmful
consequences. Inconsistencies can exist in use case models in various forms. The consequences of an
inconsistency depend on the form that the inconsistency exists in.
Anda et al. [5] outlined a taxonomy of the core categories of defects in use case models. It was shown
in [5] that inconsistencies are a key category of defects as it severely hampers the overall quality of a
use case model. The consequences of the stated forms of inconsistencies were also outlined in [5],
which has shown to affect every aspect of the development process; from producing wrong, missing
and inaccurate functionalities to producing systems that are difficult to test.
Chandrasekaran [14] has explained that inconsistencies in a use case model are generally
symptomatic of one of two problems; Firstly, the use case model might be handling concepts that are
not defined or understood properly. Secondly, there maybe an ambiguity in the domain object model.
Lilly [34] and Bittner et al. [10] outlined a number of inconsistencies that explicitly exist in use case
diagrams as well as other types of inconsistencies that may exist throughout the use case model. The
authors of [34] and [10] have also explained the harmful consequences of these inconsistencies. For
example, in [34], it was shown that an inconsistent system boundary may cause designers to
implement the behavior of entities external to the system. This in turn requires more effort from the
development team than is actually required, causing the project to fall behind schedule and go over
budget.
Ambler [2] warns that inconsistencies in use case models are usually a sign of missing or vague
information. The literature has repeatedly shown that teams often fail due to a lack of details in the
use case model rather than too much detail [10]. Ambler also warns that too many inconsistencies
may cause the use case model to be “out-of-date” and therefore becoming useless. Therefore, use case
models need to remain consistent to be effective in the development process.
Consistency has always been a sought after as an essential quality attribute for use case models [4, 8,
19, 24, 31, 41]. Reviewing use case models is a highly recommended practice [7, 31, 42], used to
assure their quality by assuring that they posses a great deal of consistency.
Other researchers have devised techniques to incorporate and ensure consistency in the use case
models being developed. McCoy [36] introduced the tool RUT (Requirements Use case Tool), which
provides a template for modelers to input information about their use cases into a repository. The
purpose of the template is to ensure consistency during entry of the use cases’ information. Achour et
7
al. [8] compiled a set of styling and content guidelines to improve the quality of the use case
descriptions. A number of these guidelines are either directly or indirectly aimed at ensuring
consistency within the use case descriptions. Butler et al. [13] introduced the concept of refactoring
use case models. Butler explained that refactoring can improve the consistency of the use case
models. Ren et al. [40] developed a tool that implements the refactoring concepts presented in [13].
It can be concluded that it is desirable to minimize inconsistencies within use case models. Using the
SUCD structure and the REUCD process ensures that the use case descriptions and their diagram(s)
are consistent with each other. For example, if the descriptions state that a certain use case is
associated with a certain actor, then it will be ensured that an association relationship in the use case
diagram will be depicted linking the given use case with the given actor. The SUCD structure and the
REUCD process do not however ensure that inconsistencies, present in the segments that are written
in unstructured natural language, will be detected or eliminated. These segments require domain
expertise to verify their consistency. For example, if one use case states that a theatre’s seating
capacity is 1200 while another use case states that the given seating capacity is 1400, then this type of
inconsistency would require manual inspection (or review) to be detected and eliminated.
2.5
Inconsistencies: A Closer Look
An obvious argument at that point would be: if the heart of the use case model is in the descriptions
while the diagrams only serve as a visual roadmap then:
Why bother with the use case diagram? Why not just use the use case descriptions only to drive
the development process? In such a case, when only the descriptions are considered, then
ensuring the consistency between the use case descriptions and their diagrams is not important!
Even though this argument might be valid for a very trivial system, there still remain several
problems if only the use case descriptions are considered to produce other UML artifacts and code. If
the system in hand is very complex, which often is the case, then a use case description might span
over five pages to be adequately described [10]. In such case, if a team member wanted to know the
actors that are associated with a given use case, it would be more efficient and accurate to simply look
up this information in the diagram rather than going through several pages of text. Use case diagrams
are able to provide an overview of a system at a glance; while examining a set of use case
descriptions cannot. Therefore, stakeholders might be misled about the general purpose of the system
if the use case diagram did not accurately represent the descriptions. Hence, use case diagrams remain
an indispensable component of the use case model, and therefore if a use case diagram does not have
an accurate representation of the descriptions, then this might lead to the design of a faulty system.
Moreover, since the SUCD structure allows use case descriptions to be machine readable, a great deal
of information can be automatically extracted from the descriptions, such as the use cases that are
included by a given base use case.
8
2.6
The Cost of Inconsistencies
The existence of inconsistencies is indicative of many potential problems. Inconsistencies that exist in
the form of contradicting information reveal correctness problems. Incorrect information in use case
models will eventually translate to faults in the code later on in the development process.
Inconsistencies may also reveal completeness problems. Incomplete use case models lead to
assumptions in the design phase. Assumptions by nature are not always correct and therefore the
eventual system may end up being faulty. Inconsistencies may also be indicative of poor use case
modeling practices. Discouraged use case modeling practices lead to confusion and poor design, in
addition to problems with regard to correctness and completeness.
Use case modeling mainly occurs in the requirements and analysis phases. When problems exist in
the early stages of development, it is easier and more cost effective to remove then than later on in the
development process. The cost of detecting and removing a defect exponentially escalates in the latter
stages (see Fig. 2.1). It is shown in [11] that the cost of fixing a defect can increase (40-1000) times at
the operation phase when compared to the cost of fixing that defect at the requirements phase.
Methods such as Software Inspections [18, 20], reviews [44] and walkthroughs [47] are used to verify
software documents at the early stages. Adolph el al. [1] identified patterns that can be used be use
case authors to evaluate their use cases. Anda et al. [5] devised an Inspection technique tailored for
inspecting use case descriptions. The technique presented by [5] is a checklist approach based on a
number previously proposed checklists such as those provided in [7, 31, 42, 48]. The defects that are
being searched for by [5] are divided into inconsistencies, omissions, incorrect facts, ambiguities and
extraneous information [43]. The effectiveness of the techniques used to verify use cases are severely
hampered due to the inability to perform any formal and automated analysis on use case descriptions
composed using unstructured natural Language. The SUCD structure can increase the effectiveness of
the techniques outlined above.
Fig. 2.1 The cost of fixing defects escalate as they propagate through the development life-cycle
9
Defects that exist due to inconsistencies cannot be treated as individual entities [46]. A defect
typically multiples into many defects at the transition between phases (see Fig. 2.2). Therefore,
defects are infectious and hence the damage caused by a defect is dependant on the “distance”
between the injection point and the removal point [46], as well as the cost of removing it and its
resulting defects. The longer a defect remains in a system, the greater its opportunity to “spread”
around. Therefore, it is especially desirable to minimize problems in use case models that potentially
lead to defects since use case modeling mainly occurs in the early phases of the development lifecycle. The SUCD structure aims to minimize these problems by preventing analysts from introducing
inconsistencies in use case models. This in turn reaps the greatest benefit in terms of effort, time and
cost savings since defects directly or indirectly caused by low quality use case models have the
potential of remaining for a long period of time and multiplying (“spreading”) into many more
defects. Incorporating the SUCD structure requires a limited learning curve since the structure itself is
limited as will later be shown in Section 3. It is difficult at this point to predict if the overhead of
incorporating the SUCD structure will lead to a longer production period since tool support should
significantly decrease the time required to complete the use case descriptions. Moreover, using
AREUCD can decrease the development time as it automatically generates use case diagrams and
description ‘skeletons’. Hence, incorporating the SUCD structure and utilizing AREUCD can actually
decrease the time to develop the use case descriptions as supposed to conventionally developing the
descriptions manually.
Fig. 2.2 Defects “spread” and multiply as they propagate through the development life-cycle
10
3
Structured Use Case Description (SUCD)
In this section we describe our proposed structure (SUCD) for writing use case descriptions. As
mentioned earlier, SUCD is in large based on the structure presented by [10]. Use cases described
using the SUCD structure contain five structured main sections, these are: (a) Use Case Name, (b)
Basic Flow, (c) Alternative Flows, (d) Subflows and (e) Extension Points. Meanwhile, other sections
in a use case description that do not require structure are described using natural language. There have
many templates presented in the literature for describing use cases [15, 23, 24, 31, 35, 42]. The
structured sections incorporated by SUCD are the common sections found in many of templates
presented in the literature. The following list outlines the structural elements of SUCD that will be
described in detail in the subsequent sections:









3.1
Headers and Actions
Basic Flow and Use Case Name Structure
Alternative Flow Structure
Extension Points Structure
o Private Extension Points Structure
o Public Extension Points Structure
Subflow Structure
Special Actions
Generalization Between Use Cases
Abstract Use Cases
Generalization Between Actors
Headers and Actions
The basic building block comprising all structured components is headers. A header contains a
number of actions that carryout certain behavior. The name of the header indicates the behavior that
is carried out by its actions. A header is comprised of two matching tags; an ‘opening’ and a ‘closing’
tag. An ‘opening’ tag is comprised of curly brackets that contain the header’s name {<header>}
prefixed with the keyword ‘BEGIN’. Its corresponding ‘closing’ tag must contain the same header
name prefixed with the keyword ‘END’. A header’s enclosed actions are normally listed in bullet
form. For example, in a library system, a header may represent the actions required to enter
information regarding a new library member as shown below:
{BEGIN enter member information}
 Librarian enters member’s name
 Librarian enters member’s address
 Librarian enters member’s phone number
{END enter member information}
11
This header {Enter Member Information} contains three actions. In this paper, performing a header
indicates that all of its enclosed actions are performed. Each header inside a use case must have a
unique name. It can be easily deduced that the purpose behind performing the three actions shown
above is to enter a member’s information into the system. Moreover, all three actions must be
performed to carryout the underlying purpose of the header. Entering the member’s name only does
not complete the task of entering the member’s information. This is the fundamental purpose behind
a header. A header groups together a set of actions that must all be performed in order to carryout
complete and meaningful behavior.
A header may contain other lower-level headers that comprise parts of the behavior required to
carryout the main behavior represented by the higher-level header. Therefore, a use case description
will contain a virtual tree of headers, whereby actions become the roots (see Fig. 3.1). A high-level
header may have actions of its own. Performing a higher-level header forces the all of its lower-level
headers in addition to its own actions to be performed. When a lower-level header is completely
performed, its higher-level header resumes performance.
Fig. 3.1 Headers in a use case descriptions form a virtual tree structure
A header can explicitly state the header(s) that will be performed next. This can be achieved using
the ‘RESUME’ statement. The ‘RESUME’ statement consists of the keyword ‘RESUME’ followed
by a list of header(s) that will ensue. The ‘RESUME’ statement may state more than one header. This
is used to model the concept of flow forking. Finally, a header may explicitly state the headers that
must be completed before it can commence. This is achieved using the ‘AFTER’ statement. Similarly,
the ‘AFTER’ statement consists of the keyword ‘AFTER’ followed by a list of headers that need to
be completed first. This is used to model the concept of flow joining.
Actions listed under a header represent the actual behavioral details of a use case. Actions must be
listed in bullet form and described using natural language. Listing actions in bullet form will allow
analysts and designers to trace back design artifacts and decisions to individual actions in a use case
description. Only one actor may perform an action, unless the action is performed by the system
itself. The name of the actor that performs a given action is prefixed to that action. For the {Enter
12
Member Information} header shown above, the Librarian actor performs all three actions shown.
Actions that are performed by the system itself are prefixed by the keyword ‘SYSTEM’.
3.2
Basic Flow and Use Case Name Structure
A use case describes various scenarios whereby an actor may benefit from the service offered by that
use case. A scenario is thus considered to be an instance of a use case [10] being performed. At the
heart of each use case is a ‘normal’ scenario (often referred to as ‘happy case’ scenario) describing
the flow of events that are usually expected to occur. The ‘normal’ scenario is described in The Basic
Flow component of a use case. The Basic Flow contains a set of headers that are performed
sequentially to perform that ‘normal’ scenario. There is a special type of header that is exclusive to
the Basic Flow component; this header is made up of the matching tags {BEGIN Use Case} and
{END Use Case}. This special header indicates the start and end of a use case. For example, for the
Enroll New Member use case shown below (see Fig. 3.2), the Basic Flow will be structured as
follows (detailed actions are omitted):
Use Case Name:
Enroll New Member
Basic Flow:
{BEGIN Use Case}
{BEGIN authenticate librarian}
actions
{END authenticate librarian}
{BEGIN enroll new member}
{BEGIN enter member information}
actions
{END enter member information}
{BEGIN enter record into library database}
actions
{END enter record into library database}
{BEGIN produce library card for new member}
actions
{END produce library card for new member}
{END enroll new member}
{END Use Case}
13
Fig. 3.2 Basic flow of the Enroll New Member use case.
Headers of the Basic Flow may optionally use ‘RESUME’ and ‘AFTER’ statements. However, by
definition, a Basic Flow describes a flow of events that occur sequentially with no variations.
Therefore, the order which the headers are presented also dictates the sequence which they will be
performed. Hence, the use of the ‘RESUME’ and ‘AFTER’ statements are optional.
3.3
Alternative Flow Structure
Variations from the ‘normal’ scenario are described in the Alternative Flows component of a use case
description. Alternative flows initiate from any given location(s) in a use case description. In order for
an Alternative Flow to initiate at a given point, a specified condition must be satisfied. Alternative
Flows initiate from a single or a set of discrete locations from within the Basic Flow only. These
location(s) are stated in the description of each Alternative Flow. For each location specified, a set of
conditions are listed along with the header(s) that will be performed next if the given conditions are
satisfied.
The set of discrete locations where Alternative Flows may initiate are indicated using the ‘AT’
statement. The ‘AT’ statement consists of the keyword ‘AT’ followed by a header where the stated
conditions are evaluated. By default, the conditions are evaluated for each action within the specified
header. Alternatively, the conditions can be evaluated only at certain actions within the specified
header. This is achieved by specifying these actions after the ‘AT’ statement.
The conditions that are evaluated at each ‘AT’ statement are indicated using ’IF’ statements. An ‘IF’
statement consists of the keyword ‘IF’, followed by a specified condition. The condition is described
using natural language and is delimited by a carriage return character (new line). A set of header(s)
describing the actual Alternative Flow of events follow the ‘IF’ statement. These headers are referred
to as Alternative Flow headers. Each Alternative Flow header must have a specified ‘RESUME’
statement to explicitly state the header(s) that will be performed next. If a ‘RESUME’ statement was
not used, then the next header in the Basic Flow will be performed.
For example, if the barcode of a book is damaged and cannot be scanned, the Librarian must enter the
barcode manually. This is shown below using the two forms of alternative flow declarations described
earlier (see Fig. 3.3 and 3.4).
Alternative Flow:
AT {scan book}
IF barcode cannot be scanned
{BEGIN enter book manually}
 Librarian enters the book’s barcode number manually
RESUME {update record}
{END enter book manually}
14
Fig. 3.3 First form: Using the AT statement to define an alternative flow initiation point
Alternative Flow:
AT {scan book}
 Librarian scans the specified book
IF barcode cannot be scanned
{BEGIN enter book manually}
 Librarian enters the book’s barcode number manually
RESUME {update record}
{END enter book manually}
Fig. 3.4 Second Form: Explicitly stating the actions where the condition for the alternative flow is
evaluated
It is not necessary for an alternative flow to define any headers, an alternative flow may simply
redirect the flow of events to a different location in a use case. In such a case, the alternative flow will
be composed of only an ‘AT’ statement followed by an ‘IF’ statement which is then followed by a
‘RESUME’ statement.
Since conditions are expressed using natural language, there is no need to add further structure and
keywords to represent more logically complex conditions. For example, if the above Alternative Flow
can be initiated if the book’s barcode is damaged or if the scanner itself is malfunctioning, then the
condition may simply be changed to ‘IF Barcode cannot be scanned or scanner is not working’.
3.4
Extension Points Structure
There are two types of Extension Points defined in [10]; Private Extension Points and Public
Extension Points. Private Extension Points are only accessible within the use case it belongs to.
Meanwhile, Public Extension Points act as interfaces or ports, which extension use cases ‘connect to’
in order to insert their additional behavior. Since Extension Points and Alternative Flows are
semantically similar, both chiefly share a similar structure.
3.4.1
Private Extension Points Structure
Private Extension Points are headers that maybe ‘inserted’ throughout any location in the use case.
Most use case modeling tools allow minimization of Private Extension Point headers within the Basic
Flow to prevent them from obscuring the main purpose of the use case. In our proposed structure,
Extension Points (public or private) are not defined within other flows. Instead they are defined under
the Extension Points section of a use case description. A Private Extension Point is composed of an
‘AT’ and ‘IF’ statements, for similar reasons as for Alternative Flows, followed by a header
containing the extending behavior. Unlike Alternative Flows, Extension Points (private or public) can
initiate from any type of flow. A ‘FLOW’ statement is used to specify that type of flow. A Private
Extension Point header is preceded with the label “PRIVATE EXTENSION POINT”. Private
15
Extension Points also need to declare the location in the use case where the flow of events will
resume. Private extension point must have ‘CONTINUE’ statement which indicates the header, in the
flow it interrupted, that will be performed next. The difference between a ‘RESUME’ statement and a
‘CONTINUE’ statement is that a ‘RESUME’ statement specifies a header that exists in the Basic
Flow, meanwhile a ‘CONTINUE’ statement specifies a header that exists in the flow specified by the
‘FLOW’ statement. Similar to Alternative Flows, an Extension Point (private or public) may
optionally not contain any headers describing extending behavior. However, this should be an
unlikely situation since an extension point is usually used to describe complex behavior that may
obscure the real purpose of the base use case incase it was merged with other types of flows.
The following example shows the Basic Flow of the Buy University Merchandise Online use case
(see Fig. 3.5). The private extension point represented by the header PRIVATE EXTENSION
POINT {BEGIN Out of Stock} contains the behavior responsible for handling the situation where a
member selects an item that is out of stock (detailed actions are omitted).
Use Case Name:
Buy University Merchandise Online
Basic Flow:
{BEGIN Use Case}
{BEGIN buy university merchandise}
{BEGIN browse merchandise catalogue}
actions
{END browse merchandise catalogue}
{BEGIN select product}
actions
{END select product}
{BEGIN process order}
actions
{END process order}
{END buy university merchandise}
{END Use Case}
16
Extension Points:
PRIVATE EXTENSION POINT
FLOW Basic Flow
AT {select product}
IF selected product is out of stock
{BEGIN out of stock}
actions
{END out of stock}
CONTINUE {browse merchandise catalogue}
Fig. 3.5 Defining a Private Extension Point for the Buy University Merchandise Online use case.
3.4.2
Public Extension Points Structure
A Public Extension Point involves a base use case (where the additional behavior will be inserted)
and an extension use case (where the additional behavior is supplied from). Hence, defining a Public
Extension Point requires structure to be embodied within the base and extension use cases.
Structure at the Base Use Case
At the base use case end, a Public Extension Point is declared under the Extension Points section.
This declaration consists of a header that acts as an interface to allow the extension use cases to
supply its additional behavior. The header of a Public Extension Point is preceded with the label
‘PUBLIC EXTENSION POINT’ followed by the name of the extension point. A Public Extension
Point header at the base use case does not define any actions since the behavior is supplied externally
from extension use cases. An extension use case is aware of the base use case’s internals which it
extends. This knowledge allows the extension use case to know the exact location(s) in the base use
case where its behavior will be inserted. Moreover, this knowledge allows the extension use case to
know the location in the base use case where the flow of events will resume.
Structure at the Extension Use Case
At the extension use case end, a corresponding Public Extension Point header will contain the actions
that constitute the additional behavior. Similarly, a Public Extension Point header is declared under
the Extension Points section of the extension use case and is preceded with the label ‘PUBLIC
EXTENSION POINT BEHAVIOR’. A Public Extension Point must state the use case it extends as
well as the location in the extended use case where the extending behavior will be inserted. The
‘EXTENDING’ statement can be used for this purpose. The structure of the ‘EXTENDING’
statement consists of the keyword ‘EXTENDING’ followed by {<Extended use case name> :
<Public Extension Point Name>}, followed by an ‘AT’ and ‘IF’ statements and finally a
‘CONTINUE’ statement.
17
Considering the same use case described in section 3.4.1, assuming that the extension point provided
was public, the base use case is then described as shown on the left side of Fig. 3.6, while the
extension use case is described as shown on the right side. (Detailed actions are omitted).
Note that in that an extension use case may also have other types of flows such as a Basic Flow. This
is because an extension use case may be initiated directly by an actor or be included by another base
use case. However, including an extension use case or associating it directly with an actor is a
discouraged modeling practice. Extension use cases should be used only for the reason they are
created for, that is to contain the behavior of Public Extension Points.
Use Case Name:
Use Case Name:
Buy University Merchandise Online
Product Out of Stock
Basic Flow:
Extension Points:
{BEGIN Use Case}
PUBLIC EXTENSION POINT BEHAVIOR
{BEGIN buy university merchandise}
{BEGIN browse merchandise catalogue}
actions
{END browse merchandise catalogue}
EXTENDING { Buy University Merchandise
Online : out of stock}
{BEGIN select product}
actions
{END select product}
{BEGIN process order}
actions
{END process order}
{END buy university merchandise}
FLOW Basic Flow
AT {select product}
IF selected product is out of stock
{BEGIN out of stock}
actions
{END out of stock}
CONTINUE
catalogue}
{browse
merchandise
{END Use Case}
Extension Points:
PUBLIC EXTENSION POINT
out of stock
Fig. 3.6 Defining a Public Extension Point for the Buy University Merchandise Online use case.
18
3.5
Subflow Structure
Subflows contain behavior that is usually required to be performed more than once. A use case may
contain several Subflows. An action in any flow inside a use case may initiate a Subflow belonging to
that use case. A Subflow can be initiated from any other type of flow, including other Subflows, using
the ‘PERFORM’ statement (see section 3.6). When the behavior of a given Subflow is completely
performed, the action or header in the main flow that follows the ‘PERFORM’ statement is
performed. Hence, a header in a Subflow does not require a ‘RESUME’ statement since a Subflow
does not need to be aware of the location in the main flow where it was initiated from.
Each Subflow must have a header containing its name. This name header is used to signify the start
and end of the given Subflow. The Subflow name header is presented as SUBFLOW <Subflow
name>. A Subflow does not require a condition to be evaluated in order for it to be initiated. If a
Subflow is only initiated under certain conditions, then these conditions should be evaluated at the
main flow, not at the Subflow header itself. Therefore, a Subflow header does not contain ‘AT’ and
‘IF’ statements. For example, the following Subflow (see Fig. 3.7) named print record. belongs to
the use case Enroll New Member and is responsible for printing a copy of a new member’s newly
created record (assuming that the new record needs to be printed several times for managerial
purposes).
Subflows:
SUBFLOW print record
{BEGIN print new member’s record}
actions
{END print new member’s record}
Fig. 3.7 Defining a Subflow
3.6
Special Actions
In addition to regular actions, there exist special types of actions that cause an inclusion use case or a
Subflow to be initiated. The following shows the structures required to declare these special types of
actions:
Initiating an inclusion use case:
{BEGIN header name}
 INCLUDE <name of the Included use case>
{END header name}
Initiating a Subflow:
{BEGIN header name}
 PERFORM <name of the desired Subflow>
{END header name}
19
3.7
Generalization Between Use Cases
As mentioned in section 2.1, a specialized use case may insert additional behavior to or modify
existing behavior in the use case it specializes. If a specialized use case inherits a lower-level header,
this will also cause the inheritance of that lower-level header’s immediate higher-level headers. To
further elaborate, let us assume a generalized use case with the header tree structure shown in Fig.
3.8. If a specialized use case would inherit Header 6, this will also cause headers Header 4 and
Header 1 to be inherited. Note that inheriting a lower-level header does not cause the actions of its
higher-level headers to be inherited as well. Therefore, when inheriting Header 6, action a1 of
Header1 is not inherited as well. If an action is inherited, such as a1 of Header 2, then Header 2
and Header 1 are also inherited
Fig. 3.8 The tree structure of headers belonging to a use case
If a generalization relationship exists between two use cases, structure is only required at the
specializing use case. The rationale behind this is that the generalized use case is not required to be
aware of its specialized use cases while the specializing use cases need to be aware of any use cases
they specialize. The name of the generalized use case is stated under the name of the specialized use
case and is presented as SPECIALIZES <Name of generalized use case> (see right side of Fig.
3.9). It is not necessary for a specializing use case to inherit all the headers and actions in its
generalized use case. In fact, a specialized use case may not inherit any headers or actions from its
generalized use case. However, the existence of such a situation is inappropriate since the
generalization relationship between the use cases would be useless. An inherited header or action can
be determined if it exists in the generalized use case. Fig. 3.9 shows two use cases that share a
generalization relationship. The use case Buy On Sale University Merchandise inherits all of the
actions specified in its parent use case and further adds the actions described under the header {Apply
Sale}. It can be determined at the Buy On Sale University Merchandise use case that the header
{Select Product} is inherited since it exists in the generalized use case Buy University
Merchandise Online.
20
Use Case Name:
Use Case Name:
Buy University Merchandise Online
Basic Flow:
Buy On Sale University Merchandise
SPECIALIZES
Buy
University
Merchandise Online
Basic Flow:
{BEGIN Use Case}
{BEGIN Use Case}
{BEGIN buy university merchandise}
{BEGIN browse merchandise catalogue}
actions
{END browse merchandise catalogue}
{BEGIN buy university merchandise}
{BEGIN browse merchandise catalogue}
actions
{END browse merchandise catalogue}
{BEGIN select product}
actions
{END select product}
{ BEGIN process order}
actions
{END process order}
{END buy university merchandise}
{END Use Case}
{BEGIN select product}
actions
{END select product}
{BEGIN process order}
actions
{END process order}
{BEGIN apply sale}
actions
{END apply sale}
{END buy university merchandise}
{END Use Case}
Fig. 3.9 Defining a generalization relationship between two use cases
3.8
Abstract Use Cases
Abstract use cases cannot be initiated. The behavior of an abstract use case must be implemented by
a concrete use case. An abstract use case hence contains headers that do not have any actions. The
actions are provided by the implementing concrete use case. An implementing concrete use case must
implement all the headers present in the abstract use case. The implementing concrete use case may
then insert additional headers and actions. In use case modeling, a concrete use case can implement
an abstract use case using the generalization relationship, where the concrete use case plays the role
of the specializing use case while the abstract use case plays the role of the generalized use case. All
headers in an abstract use case must be written in italic font. The name of the abstract use case is
stated under the name of the implementing concrete use case and is presented as IMPLEMENTS
<Name of abstract use case> (see right side of Fig. 3.10). Similarly, the rationale for this is that
21
the concrete use case needs to be aware of the abstract use case it implements, while the abstract use
case does not need to be aware of the concrete use cases that implement it. For example, Fig. 3.10
shows the abstract use case Buy University Merchandise Online being implemented by the
concrete case Buy On Sale University Merchandise.
Use Case Name:
ABSTRACT
Buy University Merchandise Online
Use Case Name:
Basic Flow:
Buy On Sale University Merchandise
IMPLEMENTS Buy University Merchandise
Online
Basic Flow:
{BEGIN Use Case}
{BEGIN Use Case}
{BEGIN buy university merchandise}
{BEGIN browse merchandise catalogue}
{END browse merchandise catalogue}
{BEGIN buy university merchandise}
{BEGIN browse merchandise catalogue}
actions
{END browse merchandise catalogue}
{BEGIN select product}
{END select product}
{BEGIN process order}
{END process order}
{END buy university merchandise}
{END Use Case}
{BEGIN select product}
actions
{END select product}
{BEGIN process order}
actions
{END process order}
{BEGIN apply sale}
actions
{END apply sale}
{END buy university merchandise}
{END Use Case}
Fig. 3.10 Defining an abstract use case and its implementing concrete use case
3.9
Generalization Between Actors
Actors reside outside a system’s boundaries. Hence, an actor description does not include any flows
of any kind since it is inappropriate to model the behavior of entities outside a system’s boundaries.
Actor descriptions consist of the actor name and brief description of the actor written in unstructured
natural language. However, for the purpose of better understanding the roles of the actors, actors can
be associated with each other only through a generalization relationship. Similar to generalizations
between use cases, the actor name section is structured to model generalization relationships. For
22
example, a Manager is considered a specialized version of an Employee. Fig. 3.11 shows how the
actor names are structured to model the generalization relationship that exists between them. The
name of the generalized actor is stated under the name of the specialized actor and is presented as
SPECIALIZES <Name of generalized actor>.
Actor Name:
Actor Name:
Employee
Manager
SPECIALIZES Employee
Fig. 3.11 Defining a generalization relationship between two actors
3.10 Other Sections in a Use Case Description
There remain further sections in a use case description that do not affect the automated transformation
of use case descriptions to diagrams, such as special and supplementary requirements. These sections
can be populated using unstructured natural language. More information about how to capture special
and supplementary requirements is presented in [33].
3.11 Formalizing the SUCD Structure Grammar
It is essential for the grammar and constructs of the SUCD structure to be formalized. Formalizing the
SUCD structure will provide a strict guideline to use case authors in composing use case descriptions,
so that there is no disagreement or ambiguity as to what is allowed and what is not. The grammar of
the SUCD structure is defined below in E-BNF (see Fig. 3.12).
S ::= UseCaseDescrption+ Actor+
Actor ::= Abstract? ActorName Implements? Specializes?
ActorName::= CharactersAndOrDigits+
UseCaseDescrption ::=
NameSection
BasicFlowSection?
AlternativeFlowSection?
SubflowsSection?
ExtensionPointsSection?
NameSection ::= ‘Use Case Name:’
Abstract?
UseCaseName
Implements?
Specializes?
Abstract ::= ‘ABSTRACT’
23
Implements ::= ‘IMPLEMENTS’ UseCaseName
Specializes ::= ‘SPECIALIZES’ UseCaseName
BasicFlowSection ::=
‘Basic Flow:’
‘{BEGIN Use Case}’
Header*
‘{END Use Case}’
Header ::= ‘{BEGIN’ HeaderName ‘}’
AfterStatement?
Contents*
ResumeStatement?
‘{END’ HeaderName ‘}’
AlternativeFlowsSections ::= ‘Alternative Flows:’ AF*
AF ::=
AtStatement
IfStatement
AFHeader
AFHeader ::=
‘{BEGIN’ HeaderName ‘}’
Contents*
ResumeStatement?
‘{END’ HeaderName ‘}’
SubflowSection ::= ‘Subflows: ’ Subflow*
Subflow ::=
‘SUBFLOW’ SubflowName
SubflowHeader
SubflowHeader ::= ‘{BEGIN’ HeaderName ‘}’
Contents*
‘{END’ HeaderName ‘}’
SubflowName ::= CharactersAndOrDigits+
ExtensionPointsSection ::= ‘Extension Points: ’ EP*
EP ::= PREP | PUEP | PUEPDeclaration
PREP ::= ‘PRIVATE EXTENSION POINT’
FlowStatement
24
AtStatement
IfStatement
PREPHeader
EPHeader
PREPHeader ::= ‘{BEGIN’ HeaderName ‘}’
Contents*
ResumeStatement
‘{END’ HeaderName ‘}’
PUEP ::= ‘PUBLIC EXTENSION POINT BEHAVIOR’
FlowStatement
AtStatement
IfStatement
EPHeader
BaseUCName ::= UseCaseName
HeaderInBaseUC ::= HeaderName
EPHeader ::= ‘{BEGIN’ HeaderName ‘}’
Contents*
‘{END’ HeaderName ‘}’
ContinueStatement
PUEPDeclaration ::= ‘PUBLIC EXTENSION POINT’
PublicExtensionPointName
ExtensionUCName ::= UseCaseName
HeaderInExtensionUC ::= HeaderName
Contents ::= Header | Statement
Statement ::= (‘•’ | Digit) (ActionStatement | PerformStatement |
IncludeStatement)
ActionStatement ::= Actor ‘’ Action
Action ::= CharactersAndOrDigits+
FlowStatement ::= ‘FLOW’ FlowType
IncludeStatement ::= ‘INCLUDE’ UseCaseName
25
PerformStatement ::= ‘PERFORM’ SubflowName
ResumeStatement ::= ‘RESUME’ (‘{‘HeaderName’}’)+
AfterStatement ::= ‘AFTER’ (‘{‘HeaderName’}’)+
AtStatement ::= ‘AT’ ‘{‘HeaderName’}’ Statement*
IfStatement ::= ‘IF’ Condition
ContinueStatement ::= ‘CONTINUE {’ ReturnHeader ‘}’
UseCaseName ::= CharactersAndOrDigits+
HeaderName ::= CharactersAndOrDigits+
Condition ::= CharactersAndOrDigits+
FlowType ::= CharactersAndOrDigits+
ReturnHeader ::= CharactersAndOrDigits+
PublicExtensionPointName ::= CharactersAndOrDigits+
CharactersAndOrDigits ::= Character | Digit
Character ::= ‘a’| ‘b’ |...| ‘z’| ‘A’| ‘B’|...| ‘Z’
Digit ::= ‘0’| ‘1’ |...| ‘9’
Fig. 3.12 E-BNF grammar for the SUCD structure
The E-BNF grammar shown above describes the formal grammar of the SUCD structure and the
concepts explained throughout section 3. In addition to the main concepts described earlier, the
grammar outlined reveals additional features of the SUCD structure. These features are either minor
or applicable to all types of structured sections in the use case description. For instance, it can be
deduced that a statement does not necessarily start with a bullet point, it may instead start with a digit.
It maybe desired to start the statements of a header with a digit if there is a need to enforce a certain
sequence for the statements to be performed. Furthermore, it can be useful to kick start the systematic
generation of other UML artifacts such as sequence diagrams; however, this is out of the scope of this
paper.
26
It can also be deduced by further examining the grammar of the SUCD structure that it is only
required to use the keyword ‘ABSTRACT’ in the use case name section to define an abstract use
case. It is not necessary to describe abstract use cases using italic font. However, it is recommended
to describe abstract use cases using italic font since the conventional method of labeling any abstract
element in the UML is by using italic font. Hence, abstract use cases throughout this paper are
described in italic font.
The use of colors is not enforced according to the grammar. However, the use of colors to describe
various aspects of the use case descriptions can be extremely beneficial as it makes the use case
descriptions significantly more readable. It is expected that when tool support becomes available for
authoring use cases using the SUCD structure, that it would incorporate the use of colors.
4
Consistency Rules Between Use Case Descriptions and Diagrams
One of the principle advantages of using the proposed use case description structure is that it ensures
consistency between the use case descriptions and their corresponding use case diagram(s). In this
section we will describe how the proposed structure can be systematically mapped to diagrammatic
notations that form use case diagrams. This systematic process can be automated through tool
support, which will ensure its consistency and speed. The following is the list of all structural
elements that can be mapped onto diagrammatic notations:







Use Case Name
The include statement
Public Extension Points
Associations between actors and use cases
Generalization Between Actors
Abstract Use Cases and their Implementation
Generalization Between Use Cases
The process of generating use case diagrams from use case descriptions and vice versa is analogous to
generating complete and accurate UML class diagrams from code and generating code structures
from UML class diagrams. The reason UML class diagrams cannot be used to generate complete
programs is because they act as a visual summary of a program’s static structure. On the other hand,
during reverse engineering, a complete program will contain more than enough details required to
generate complete and accurate UML class diagrams.
Use case descriptions (analogous to code) contain far more details than use case diagrams (analogous
to class diagrams). Given a set of use case descriptions, a complete and accurate use case diagram can
be systematically produced (see Fig 4.1). However, if modelers choose to create use case diagrams
manually first, which is often the case, a ‘skeleton’ of the use case descriptions can be systematically
27
produced. Tool support can automate the process of generating the ‘skeleton’ of the use case
descriptions (see Fig 4.2). The details of the use case descriptions are later added manually by
analysts to ‘flesh out’ the generated ‘skeletons’. After the use case descriptions are complete, tool
support can automatically detect inconsistencies between the descriptions and the diagrams.
Fig. 4.1 Systematically generating the use case diagram after initially developing the use case
descriptions
Fig. 4.2 Systematically generating use case descriptions after initially developing the use case diagram
(reversing the REUCD process)
28
4.1
Mapping of Use Case Description Structures and Use Case Diagrams
The following template will be used to present information about mappings between use case
description structures and use case diagrams (see Table 1):
Table 1. Template for mapping description structures to diagrammatic elements
Use Case Description Structure Element:
Description of how to map a description structure element to use case diagrammatic notation(s).
Example:
An example of the use case description structure element and its corresponding diagrammatic
notation(s).
Consistency Rules:
A set of consistency rules that are used to check the consistency between any given set of descriptions
and their corresponding diagrams(s), which will be required by a tool if analysts decide to build the
use case diagram before writing the use case descriptions.
I. Use Case Name:
A use case description with a given use case name generates a use case in the diagram with a
matching name.
Example:
Use Case Name:
Buy On Sale University Merchandise
Consistency Rules:
1) Every use case description must have a corresponding use case in the diagram with matching
names
2) Every use case in a diagram must have a corresponding use case description with matching names
II. The INCLUDE Statement:
The include statement creates an ‘include’ relationship between the base use case, which contains the
include statement, and the inclusion use case, which is stated in the include statement.
Example:
Use Case Name:
Enroll New Member
Basic Flow:
{BEGIN Use Case}
.
29
{BEGIN authenticate librarian}
 INCLUDE Authenticate User
{END authenticate librarian}
.
{END Use Case}
Consistency Rules:
1) An inclusion use case in a diagram must be initiated at least once by each base use case that
includes it, using the include statement.
2) An INCLUDE statement in a base use case must refer to a use case that exists in the diagram
3) An INCLUDE statement in a base use case must refer to a use case that is included by that base
use case.
III. Public Extension Points:
A base use case that contains a Public Extension Point is extended by the extension use case stated in
the Public Extension Point header. The Public Extension Point name is also depicted at the base use
case in the diagram. The condition associated with the Public Extension Point is displayed as part of
the extend relationship notation that connects the involved use cases.
Example:
Use Case Name:
Use Case Name:
Buy University Merchandise Online
Product Out of Stock
Basic Flow:
Extension Points:
{BEGIN Use Case}
PUBLIC EXTENSION POINT BEHAVIOR
.
.
{BEGIN select product}
actions
{END select product}
EXTENDING { Buy University Merchandise
Online : out of stock}
Extension Points:
FLOW Basic Flow
AT {select product}
IF selected product is out of stock
{BEGIN out of stock}
actions
{END out of stock}
PUBLIC EXTENSION POINT
out of stock
CONTINUE
catalogue}
.
.
{END Use Case}
{browse
merchandise
30
Consistency Rules:
1) At the base use case, a Public Extension Point header must refer to an extension use case that
exists in the diagram.
2) At the base use case, a Public Extension Point header must refer to an extension use case that
extends the base use case. The stated Public Extension Point header must also exist within the
Extension Points section of the extension use case.
3) At the extension use case, the ‘AT’ statement of a Public Extension Point must refer to a base use
case that exists in the diagram.
4) At the extension use case, the ‘AT’ or ‘FROM TO’ statement of a Public Extension Point must
refer to a base use case that the extension use case extends. The header stated in the ‘AT’ or
‘FROM TO’ statement must also exist within the base use case.
5) At the extension use case, the ‘RESUME’ statement of a Public Extension Point must refer to a
header that exists within the base use case.
6) At the extension use case, the condition stated in the ‘IF’ statement of a Public Extension Point is
depicted in the diagram as part of the extend relationship notation that links the base use case and
the extension use case.
IV. Associations Between Actors and Use Cases:
An actor stated in an action contained in a use case creates an association link between that actor and
the corresponding use case in the diagram.
Example:
Use Case Name:
Enroll New Member
Basic Flow:
{BEGIN Use Case}
.
.
{BEGIN enter member information}
31



Librarian enter member’s name
Librarian enter member’s address
Librarian enter member’s phone
number
{END enter member information}
.
.
{END Use Case}
Consistency Rules:
1) An actor stated to perform any given action within a use case description must exist in the
diagram.
2) An actor stated to perform any given action within a use case description must be linked with that
use case using an association relationship in the diagram.
3) An actor linked with a use case using an association relationship in the diagram must perform at
least one action in the given use case.
V. Generalization Between Use Cases:
A use case name stated as generalized in another use case’s Use Case Name section creates a
generalization relationship link between the involved use cases.
Example:
Use Case Name:
Buy University Merchandise Online
Use Case Name:
Buy On Sale University Merchandise
SPECIALIZES
Buy
University
Merchandise Online
Consistency Rules:
1) A specializing use case must refer to a different use case that exists in the diagram
2) A specializing use case must refer to a use case in the diagram that is specializes.
3) The specializing use case must have a generalization relationship directed towards the
generalized use case in the diagram
VI. Abstract Use Cases and their Implementation:
The name of an abstract use case is displayed in italic font in the diagram. A use case implementing
an abstract use case creates a generalization relationship arrow in the diagram, originating from the
implementing use case and directed towards the abstract use case.
32
Example:
Use Case Name:
Buy University Merchandise Online
Use Case Name:
Buy On Sale University Merchandise
IMPLEMENTS
Buy
University
Merchandise Online
Consistency Rules:
1) An implementing concrete use case must refer to an abstract use case that exists in the diagram.
2) An implementing concrete use case must refer to an abstract use case that it implements.
3) The entire header tree structure of the abstract use case must exist and be implemented in the
concrete use case.
4) A use case description written in abstract form (italics) must have a corresponding use case in the
diagram with its name displayed in italics.
5) An abstract use case in the diagram must have a corresponding use case description written in
abstract form (italics).
VII. Generalization Between Actors:
An actor name stated as generalized in another actor’s Actor Name section creates a generalization
relationship link between the involved actors.
Example:
Actor Name:
Employee
Actor Name:
Manager
SPECIALIZES Employee
Consistency Rules:
1) A specializing actor must refer to a different actor that exists in the diagram
2) The specializing actor must have a generalization relationship directed towards the generalized
actor in the use case diagram.
33
3) Every actor description with a given name must have a corresponding actor in the diagram with a
matching name.
4) Every actor in the diagram with a given name must have a corresponding actor description with a
matching name.
4.2
Other Structured Sections in Use Case Descriptions
Structured sections such as Private Extension Points, Subflows and Alternative Flows are not
modeled in a use case diagram. However, it is still important to structure these sections since they
describe the flow of events within a use case. Structuring those sections will aid the transformation of
use case descriptions to other UML artifacts such as activity diagrams and sequence diagrams.
5
Tool Support for Automated Generation of Use Case Diagrams
Tool support is essential for the effective application of the REUCD process. For a highly complex
software system, the corresponding use case model may contain up to four hundred use cases. Use
cases are not sorted in any chronological order. Relationships linking the use cases with other use
cases and actors also not sorted in any fashion either. Therefore, performing the REUCD process for
such system manually is a very cumbersome task that is prone to many inconsistencies. Even for a
relatively smaller use case model, one that contains twenty use cases, the application of the REUCD
process is still vulnerable to mistakes.
In this paper, we feature the tool AREUCD (Automated REUCD), which supports the two way
generation of use case diagrams from use case descriptions and vice versa. In order to generate use
case diagrams from use case descriptions, AREUCD is loaded with a UC description file (‘.ucd’
extension). AREUCD parses through the descriptions of all the given use case descriptions and actors
and generates a file containing the corresponding use case diagram. The use case diagram is
generated in XML format, which will allow it to be displayable by UML modeling tools. Conversely,
in order to generate use case description ‘skeletons’, AREUCD is loaded with UC diagram file. The
UC diagram can be generated by a UML modeling tool. The UC diagram must be in XML format,
however this is not an issue since almost all UML modeling tools store information about their
models in XML format. Upon parsing the diagram or description files, the properties of the given UC
descriptions or diagram is displayed (see Figure 5.1). Figure 5.2 shows an overview of the operation
of AREUCD.
34
Fig. 5.2 An overview of AREUCD
6
Online Hockey Team Store System Case Study
The following case study is used to demonstrate how use case descriptions are presented in the SUCD
form and to demonstrate the application of AREUCD. This case study will also illustrate the
concepts, described in section 4, to systematically generate use case diagrams from use case
descriptions using the REUCD process. The case study is about a simplified online hockey team store
system. The presented system is simplified for clarity, yet complex enough for the purposes of
demonstrating the SUCD structure and the REUCD process.
The system allows customers to purchase tickets for upcoming hockey games. To buy a ticket, a
customer needs to choose the game he/she would like to attend from the team’s online calendar. The
customer selects the desired section in an area where he/she would like their tickets to be along with
the quantity of tickets requested. Upon retrieval of this information, the system will search the
database for the requested tickets. If the tickets are available, the customer is prompted to either
accept or reject the offered seats. If the customer accepts the offered seats, the customer is then
directed to a billing page where the purchase transaction can take place. Otherwise, if the tickets are
not available, the customer is informed about the unavailability and then requested to submit another
search for tickets. Occasionally, tickets for certain games in certain sections of the hockey arena may
go on sale. Unlike regular priced tickets, a customer may purchase a maximum of six on sale tickets.
The system also allows customers to purchase team merchandise such as hockey jerseys, sticks,
pucks…etc. When choosing a merchandise item, the customer may provide customization requests
for an extra cost. Available customization options depend on the type of item. For example, if the
item was a hockey jersey, the customer may choose to have his/her name sewed on the jersey along
with their favorite number. Meanwhile, if the item was a steel pen, the customer may have a name (or
other words) engraved on the pen. To boost merchandise sales, a customer may enter a ticket number
while purchasing merchandise for a chance to win a grand prize. A customer may purchase tickets
and team merchandise using a credit card or a team hockey card. If the customer chooses to purchase
using a credit card, an external credit card authorization system is utilized to verify the validity of the
given credit card information. Meanwhile, if the customer chooses to purchase using a team hockey
card, the customer is requested to enter a PIN. The system internally verifies the PIN with the
35
associated hockey team card to approve the transaction. For any purchase, the customer is requested
to enter billing information. The billing information is used for market survey purposes and delivery
of tickets and team merchandise. Billing information would include the customer’s name, phone
number and address.
This simplified system contains seven use cases and two actors. The formal use case and actor
descriptions are presented below. For illustrative purposes, the evolution of the use case diagram is
shown below as the use cases are read one by one (Fig. 5.15.8).
Use Cases:
1) Use Case Name:
Buy Tickets
Brief Description: This use case is responsible for allowing customers to purchase as many tickets
as they need in any section.
Preconditions:
1) At least one game and one seat is available
Basic Flow:
{BEGIN Use Case}
{BEGIN present price list}
 SYSTEM presents the different sections that exist in the arena and the price for a
single seat in each section
{END Present Price List}
{BEGIN enter ticket order information}
 Customer selects the desired game from the team’s calendar
 Customer enters the desired section
 Customer enters the number of tickets
 Customer submits order request
 PERFORM search tickets
{END enter ticket order information}
{BEGIN purchase ticket}
 SYSTEM prompts the Customer to accept or reject the offered seats
 Customer accepts to purchase ticket
 INCLUDE Perform Transaction
{END purchase ticket}
{END Use Case}
Alternative Flows:
36
AT {enter ticket order information}
 PERFORM search tickets
IF tickets not available
{BEGIN search for tickets again}
 SYSTEM notifies the Customer that the requested tickets are unavailable
RESUME {enter ticket order information}
{END search for tickets again}
AT {purchase ticket}
 Customer accepts to purchase ticket
IF tickets were rejected
{BEGIN rejected seats}
 SYSTEM notifies the Customer that the cancellation has been confirmed.
RESUME {present price list}
{END rejected seats}
Subflows:
SUBFLOW search tickets
{BEGIN print new member’s record}
 SYSTEM retrieve seating information about the requested games
 SYSTEM retrieve seating information about the requested section
 SYSTEM locates the desired number of seats in the requested section. The seats
must be next to each other in the same row
{END print new member’s record}
Postconditions: If tickets are issued, these seats become unavailable for future customers
Extension Points:
Special Requirements: System must be online
Fig. 5.1 The use case diagram after one use case description is read
2) Use Case Name:
Buy On Sale Tickets
SPECIALIZES Buy Tickets
Brief Description: This use case is responsible for allowing customers to purchase a maximum of
six on sale tickets.
Preconditions:
At least one game and one seat is available
Basic Flow:
37
{BEGIN Use Case}
{BEGIN present price list}
 SYSTEM presents the different sections that exist in the arena and the price for a
single seat in each section
{END present price list}
{BEGIN request on sale tickets}
 Customer indicates interest to purchase on sale tickets
 SYSTEM presents the selected games that have on sale tickets
 SYSTEM presents the selected sections that contain on sale tickets
{END request on sale tickets}
{BEGIN enter ticket order information}
 Customer selects the desired game with on sale tickets
 Customer selects the desired section with on sale tickets
 Customer enters the number of desired on sale tickets
 Customer submits order request
 PERFORM search on sale tickets
{END enter ticket order information}
{BEGIN purchase ticket}
 SYSTEM prompts the Customer to accept or reject the offered seats
 Customer accepts to purchase tickets
 INCLUDE Perform Transaction
{END purchase ticket}
{END Use Case}
Alternative Flows:
AT {enter ticket order information}
 PERFORM search tickets
IF tickets not available
{BEGIN search for tickets again}
 SYSTEM notifies the Customer that the requested tickets are unavailable
RESUME {enter ticket order information}
{END search for tickets again}
AT {enter ticket order information}
 Customer enters the number of desired on sale tickets
{BEGIN too many tickets}
 SYSTEM notifies the Customer that the requested number tickets exceed the
38
maximum allowed of six
RESUME {enter ticket order information}
{END too many tickets}
AT {purchase ticket}
 Customer accepts to purchase ticket
IF tickets were rejected
{BEGIN rejected seats}
 SYSTEM notifies the Customer that the cancellation has been confirmed.
RESUME {present price list}
{END rejected seats}
Subflows:
SUBFLOW search on sale tickets
{BEGIN print new member’s record}
 SYSTEM retrieves seating information about the requested games
 SYSTEM retrieves seating information about the requested section
 SYSTEM locates the desired number of seats in the requested section. The seats
must be next to each other in the same row
{END print new member’s record}
Postconditions: If tickets are issued, these seats become unavailable for future customers
Extension Points:
Special Requirements: System must be online
Fig. 5.2 The use case diagram after two use case descriptions are read
3) Use Case Name:
ABSTRACT
Perform Transaction
Brief Description: This use case is responsible for allowing customers to pay for their selected
items
Preconditions:
At least one ticket is requested for purchase
39
Basic Flow:
{BEGIN Use Case}
{BEGIN enter billing information}
{END enter billing information}
{BEGIN print receipt}
{END print receipt}
{END Use Case}
Alternative Flows:
Subflows:
SUBFLOW print receipt
{BEGIN print transaction information}
{END print transaction information}
Postconditions:
If tickets are issued, these seats become unavailable for future customers
If merchandise is sold, the merchandise database is updated
Extension Points:
Special Requirements: System must be online
Fig. 5.3 The use case diagram after three use case descriptions are read
4) Use Case Name:
Purchase With Credit Card
IMPLEMENTS Perform Transaction
Brief Description: This use case is responsible for allowing customers to pay for their selected
items using a credit card
Preconditions:
At least one item is requested for purchase
Basic Flow:
40
{BEGIN Use Case}
{BEGIN enter billing information}
 SYSTEM requests Customer to enter billing information
 Customer enters first and last names
 Customer enters phone number
 Customer enters billing address
 Customer selects to pay using a credit card
{END enter billing information}
{BEGIN pay by credit card}
 Customer enters credit card type
 Customer enters credit card number and expiry
 Credit Card Validation System validates given credit card
{END pay by credit Card}
{BEGIN print receipt}
 PERFORM print receipt
{END print receipt}
{END Use Case}
Alternative Flows:
Subflows:
SUBFLOW print receipt
{BEGIN print transaction information}
 SYSTEM prints Customer information
 SYSTEM prints credit card information
 SYSTEM print items information and total price
{END print transaction information}
Postconditions: If tickets are issued, these seats become unavailable for future customers
Extension Points:
PRIVATE EXTENSION POINT
FLOW Basic Flow
AT {pay by credit card}
 Credit Card Validation System validates given credit card
IF credit card information is incorrect
{BEGIN enter credit card information again}
 SYSTEM notifies the Customer that the credit card information is incorrect
{END enter credit card information again}
CONTINUE {pay by credit card}
41
Special Requirements: System must be online
Fig. 5.4 The use case diagram after four use case descriptions are read
5) Use Case Name:
Purchase Using Hockey Team Card
IMPLEMENTS Perform Transaction
Brief Description: This use case is responsible for allowing customers to pay for their selected
items using a preauthorized payment plan setup on their hockey team card
Preconditions:
At least one item is requested for purchase
Customer has a hockey team card with a set PIN
Basic Flow:
{BEGIN Use Case}
{BEGIN enter billing information}
 SYSTEM requests Customer to enter billing information
 Customer enters first and last names
 Customer enters phone number
 Customer enters billing address
 Customer selects to pay using a hockey team card
{END enter billing information}
{BEGIN enter team hockey card information}
 Customer enters team hockey team card number
 Customer enters card PIN
 SYSTEM verifies card number and PIN
{END enter team hockey card information}
{BEGIN print receipt}
 PERFORM print receipt
{END print receipt}
42
{END Use Case}
Alternative Flows:
AT {enter team hockey card information}
 SYSTEM verifies card number and PIN
IF card information is invalid
{BEGIN enter team hockey card information again}
 SYSTEM notifies the Customer that the team hockey card information is incorrect
RESUME {pay by credit card}
{END enter team hockey card information again}
Subflows:
SUBFLOW print receipt
{BEGIN print transaction information}
 SYSTEM prints Customer information
 SYSTEM prints team hockey card information
 SYSTEM print items information and total price
{END print transaction information}
Postconditions: If tickets are issued, these seats become unavailable for future customers
Extension Points:
Special Requirements: System must be online
Fig. 5.5 The use case diagram after five use case descriptions are read
6) Use Case Name:
Buy Team Merchandise
Brief Description: This use case is responsible for allowing customers to buy team merchandise
such as jersey, hockey sticks, mugs and other collectibles
Preconditions:
Basic Flow:
43
{BEGIN Use Case}
{BEGIN display catalogue}
 SYSTEM displays catalogue with all team merchandise items
{END display catalogue}
{BEGIN select items}
 Customer selects desired items to purchase
 Customer enters quantity of each item
 Customer enters any desired customization information
{END select items}
{BEGIN purchase items}
 INCLUDE Perform Transaction
{BEGIN a chance to win}
 Customer enters a ticket number for a chance to win
{END a chance to win }
{END purchase items}
{END Use Case}
Alternative Flows:
Subflows:
Postconditions:
Extension Points:
PUBLIC EXTENSION POINT
Grand Prize Giveaway
Special Requirements: System must be online
44
Fig. 5.6 The use case diagram after six use case descriptions are read
7) Use Case Name:
Winning Ticket Entered
Brief Description: This use case is responsible for the situation where a winning ticket was
entered.
Preconditions:
Basic Flow:
Alternative Flows:
Subflows:
Postconditions:
Extension Points:
PUBLIC EXTENSION POINT BEHAVIOR
EXTENDING {Buy Team Merchandise : Grand Prize Giveaway}
FLOW Basic Flow
AT {a chance to win}
IF winning ticket was entered
{BEGIN grand prize giveaway}
 SYSTEM notifies Customer the he/she won the grand prize
 Customer enters phone number for a Customer service representative to call
{END grand prize giveaway}
CONTINUE {END Use Case}
Special Requirements: System must be online
45
Fig. 5.7 The use case diagram after all seven use case descriptions are read
Actors:
1) Actor:
Customer
Brief Description: This actor may purchase hockey tickets at regular price or on sale. This actor
may also purchase team merchandise. The actor will be requested to pay using a credit card or a
team hockey card.
2) Actor:
Credit Card Validation System
Brief Description: This actor ensures the validity of a given a credit card number and an expiry
date.
46
Fig. 5.8 The use case diagram after all use cases and actors are read
Using AREUCD, the use case diagram was automatically generated after reading the use case and
actor descriptions. The ‘.ucd’ file representing the use case and actor descriptions is located at
[STEAM]. AREUCD does not incorporate an evolutionary process as shown by figures 5.15.8.
Initially, AREUCD analyzes the entire set of descriptions to produce an object model representing the
properties of the descriptions (see Fig. 5.9) , then produces the entire use case diagram. The
corresponding XML file generated by AREUCD is located at [STEAM] and can be viewed using
MagicDraw.
47
Fig. 5.8 A screenshot of AREUCD after transforming the descriptions to an object model
7
Conclusion and Future Work
A quality use case model improves every aspect of the development cycle. There are several quality
attributes that should exist in every use case model. A use case model needs to be precise and
unambiguous, so that all stakeholders would have a common understanding of the capabilities and
constraints of the system. A use case model needs to be analytical and should not contain any
assumptions about the design or implementation. An analytical use case model describes what a
system should do instead of how it does it. Another essential quality attribute is consistency, which is
the focal point of this paper. Many researchers and practitioners warn about the harmful consequences
of inconsistencies in use case models. Inconsistencies can negatively affect every aspect of the
development cycle as well as the stakeholders. Inconsistencies occur in use case models mainly due
to inexperience. Use cases that are authored by inexperienced analysts or analysts without a great deal
48
of domain knowledge are hard to read and verify, and therefore inconsistencies become much more
difficult to detect. In addition, many use case authoring styles and structures that already exist do not
provide enough information to be able to construct a use case diagram that accurately represents the
descriptions. Relying on heuristics and experience to manually detect inconsistencies can be
cumbersome, error prone and requires a great deal of expertise to be effective. Such expertise is often
not readily available. Use case descriptions require necessary structure to allow the automated
generation of accurate use case diagrams and the detection of inconsistencies that may exist between
them, while allowing analysts the liberty and flexibility to describe a system using natural language,
which will make the model easy to comprehend. The added structure will also allow use case
descriptions to be machine readable. Consequently, this will allow tools to systematically extract a
great deal of information from the descriptions.
This paper proposes a structure (SUCD) for describing use cases. The structure serves as a guideline
to use case authors. The SUCD form along with the REUCD process enables the systematic
generation of use case diagrams and ensures consistency between the descriptions and their diagrams.
The generated diagrams will be complete and provide an accurate representation of the use case
descriptions. Tool support can be provided to automate this process as well. The REUCD process
may also be reversed, where the use case diagram is constructed before the use case descriptions. In
that case, tool support can automatically generate use case description ‘skeletons’ from use case
diagrams. Analysts will then need to manually fill in the details of each use case description. After
filling the details, tool support can detect any inconsistencies between the diagrams and the
descriptions and notify the analysts and modelers about these inconsistencies.
Future work can be directed towards developing a systematic approach to generate other UML
artifacts such as activity diagrams and sequence diagrams from use case descriptions. This will
provide a key step towards bridging the gap between the analysis phase and the design phase, and
reduce the dependence on experience. These future approaches should also be accompanied by
consistency rules that ensure the consistency between the use case descriptions and the generated
UML diagrams.
References
1. Adolph, S., Bramble, P.: Patterns for effective use cases. Addison-Wesley. 2002.
2. Ambler, S.: http://www.agilemodeling.com/essays/whenIsAModelAgile.htm
3. Anda, B., Dreiem, H., Sjøberg, D. & Jørgensen, M. Estimating Software Development Effort
Based on Use Cases – Experiences from industry. Submitted to UML'2001 (Fourth International
Conference on th Unified Modeling Language).
4. Anda, B., Sjøberg, D., Jørgensen, M.: Quality and Understandability in Use Case Models. 15th
European Conference Object-Oriented Programming (ECOOP), edited by J. Lindskov Knudsen.
Springer-Verlag, Budapest, Hungary, pages 402-428. 2001.
49
5. Anda, B., Sjøberg, D.I.K.: Towards an Inspection Technique for Use Case Models. Proceedings
of the 14th international Conference on Software engineering and Knowledge Engineering (2002)
127-134
6. Anderson, E., Bradley, M., Brinko, R.: Use case and business rules: styles of documenting
business rules in use cases. Addendum to the Object-oriented programming, systems, languages,
and applications conference. (1997)
7. Armour, F., Miller, G.: Advanced Use Case Modeling. Addison-Wesley. 2000
8. Ben Achour, C., Rolland, C., Maiden, N.A.M. & Souveyet, C. Guiding Use Case Authoring:
Results of an Empirical Study. Proceedings IEEE Symposium on Requirements Engineering,
IEEE Comput. Soc, Los Alamitos, CA, USA, 1999.
9. Biddle, B., Noble, J., Tempero, E.: Essential Use Cases and Responsibility in Object-Oriented
Development. Proc. of 25th CRPITS. 2002, Volume 24 Issue 1.
10. Bittner, K., Spence, I.: Use Case Modeling. Addison-Wesley, MA. 2002
11. Boehm, B.: Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall. 1981
12. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. AddisonWesley. 1999.
13. Butler, G., Xu, L.: Cascaded refactoring for framework evolution, Proceedings of 2001
Symposium on Software Reusability, ACM Press, 2001, pp. 51-57.
14. Chandrasekaran, P.: How use case modeling policies have affected the success of various projects
(or how to improve use case modeling). Addendum to the 1997 ACM SIGPLAN conference on
Object-oriented programming, systems, languages, and applications. 1997.
15. Cockburn, A. Writing Effective Use Cases. Addison-Wesley, 2000
16. Cockburn, A.: Goals and Use Cases. Journal of Object-Oriented Programming, 10(5), September.
1997.
17. Constantine, L. L.: Essential Modeling: Use Cases for User Interfaces. ACM Interactions, 2 (2):
34-46, March/April 1995.
18. Fagan, M.E. Design and Code Inspections to Reduce Errors in Program Development. IBM
Systems Journal, Vol. 15(3), pp. 182-211, 1976.
50
19. Firesmith, D.G. Use Case Modeling Guidelines. Proceedings of Technology of Object-Oriented
Languages and Systems – TOOLS 30. IEEE Comput. Soc, Los Alamitos, CA, USA, 1999.
20. Gilb, T., Graham, D.: Software Inspection. Addison-Wesley, Reading, MA. 1993
21. Gomaa, H.: Designing Software Product Lines with UML. Addison Wiley Professional. 2004.
22. Gomaa, H.: Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison
Wiley. 2000
23. Harwood, R. J. Use case formats: Requirements, analysis, and design. Journal of Object-Oriented
Programming, Vol. 9, No. 8, pp. 54-57, January 1997.
24. Jaaksi, A. Our Cases with Use Cases. Journal of Object-Oriented Programming, Vol. 10, No. 9,
pp. 58-64, February 1998.
25. Jacobson, I. et al. Object-Oriented Software Engineering. A Use Case Driven Approach. AddisonWesley, 1992.
26. Jacobson, I., Ericsson, M., Jacobson, A.: The Object Advantage. ACM Press. 1995.
27. Johansson, A.: Confusion in Writing Use Cases. Proc. of the 2nd International Conference on
Information Technology for Application (ICITA 2004)
28. Kaner, C., Bach, J., Pettichord, B.: Lessons Learned in Software Testing, 2003. John Wiley &
Sons.
29. Kroll, P., Kruchten, P.: The Rational Unified Process made easy: a practitioner’s guide to the
RUP. Addison-Wesley. 2003.
30. Kruchten, P.: The Rational Unified Process: An Introduction (2nd Edition). Addison Wesley
Longman Inc. 1999.
31. Kulak, D., Guiney, E.: Use Cases: Requirements in Context. Addison-Wesley. 2000
32. Larman, C.: Applying UML Patterns: An Introduction to Object-Oriented Analysis and Design
and the Unified Process. 2nd Edition. Prentice Hall. 2001
33. Leffingwell, D., Widrig, D.: Managing Software Requirements: A Unified Approach. AddisonWesley. 2000.
34. Lilly, S.: Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases, Proceedings of
TOOLS USA '99, IEEE Computer Society, (1999).
51
35. Mattingly, L. & Rao, H. Writing Effective Use Cases and Introducing Collaboration Cases.
Journal of Object-Oriented Programming, Vol. 11, No. 6, pp. 77-79, 81-84, 87, October 1998.
36. McCoy, J: Requirements use case tool (RUT). Companion of the 18th annual ACM SIGPLAN
conference on Object-oriented programming, systems, languages, and applications. 104-105
(2003)
37. OMG. UML 2.0 Infrastructure Specification, September, 2003. http://www.omg.org/docs/ptc/0309-15.pdf
38. Overgraad, G., Palmkvist, K.: Use Cases Patterns and Blueprints. Addison-Wesley (2005).
39. Rational Software: Rational Unified Process Version 2002.05.00, 2002.
40. Ren, S., Butler, G., Rui, K., Xu, J., Yu, W., Luo, R.: A Prototype Tool for Use Case Refactoring.
Proc. of the 6th International Conference on Enterprise Information Systems. P173-178. Porto,
Purtogal. 2004.
41. Rosenberg, D. & Scott, K. Use Case Driven Object Modeling with UML. Addison-Wesley, 1999.
42. Schneider, G., Winters, J.: Applying Use Cases – A Practical Guide. Addison-Wesley. 1998
43. Shull, F., Rus, I. and Basili, V. How Perspective-Based Reading Can Improve Requirements
Inspections. IEEE Computer, Vol. 33(7), pp. 73-79, July 2000.
44. Sommerville, I. Software Engineering, 5th Ed. Addison-Wesley, 1996.
45. Wirfs-Brock, R.: Designing Scenarios: Making the Case for a Use Case Framework. Smalltalk
Report, Nov.-Dec., 1993. SIGS Publications.
46. Wohlin, C. and Korner, U, Software Faults: Spreading, Detection and Costs, Software
Engineering Journal, Vol. 5, No. 1, pp. 33 – 42. 1990
47. Yourdon, E. Structured Walkthroughs. Prentice-Hall, 1989.
48. www.mcbreen.ab.ca/papers/QAUseCases.html
52