Evaluation of Visual vs. Textual Use Case Modeling
Éric Gagnon, AXON
Éric Lefebvre, École de technologie supérieure
Abstract
Use case modeling is a widely used technique to specify software requirements [1] by
representing all the interactions between the actors and the system. The Rational Unified Process
(RUP [2]), for instance, claims to be use-case centric. The Unified Modeling Language (UML [3])
specifies a use case diagram, which represents the actors and the use cases with which they
interact, but does not specify how to represent each individual use case. Usually a use case is
written in a textual format and may be detailed by diagrams such as activity, collaboration or state
diagrams.
Many authors have expressed their views on how to write use cases and have proposed their
own templates [4] [5]. However, all these templates do not offer an easy reading of the use case
or an easy transformation into the subsequent models of the development process.
Visual representation of the use cases by activity diagrams has already been suggested. This
mode of representation brings significant advantages compared with the traditional textual
representation, such as better integration with the other development life cycle models and
generation of the test cases. Two distinct groups have evaluated both modes of representation. In
conclusion, we recommend to use as much as possible the visual representation and to replace
the use case diagram by an activity diagram, therefore paving the way to an easier transformation
of business process models into use case models.
Introduction
Emphasis in the software development cycle is nowadays on requirement engineering, since:
1. Complete and sound requirements are the key to a successful software development
2. Software is programmed at a higher level of abstraction, thanks to the new techniques of
generative programming [6] and of Model-driven Architecture [7].
Most of the current software development processes recommend use case modeling to specify
requirements. The current technique to write use cases is in a textual format, with a word
processor.
The main weakness of this technique is that use cases are not always easy to read. Another
weakness is that they are not easy to transform into system models. Can these weaknesses be
overcome by using a visual representation, based on activity diagrams, as they are specified by
UML?
Writing visual use cases with activity diagrams has been recommended by Larman [5] and by
Jacobson [8]. It has also been successfully experimented for several years by one of the authors
in his practice.
In this paper we present how to write visual use cases with activity diagrams and we evaluate
whether a visual representation can replace a textual one. We successively present the traditional
technique of writing use cases (Section 1), how to write a use case with an activity diagram
(Section 2), the benefits of the visual use cases (Section 3), the results of two surveys about the
evaluation of both representations (Section 5) and our recommendations and conclusion (Section
6).
1. Writing a textual use case
RUP [2] defines a use case as ‘a set of use-case instances, where each instance is a sequence
of actions a system performs that yields an observable result of value to a particular actor’. RUP
provides in its use case template the following Items:
 Brief description
 Actor(s)
 Flow of events
o Basic
o Alternative
 Special requirements
 Pre-conditions
 Post-conditions
 Extension points
The example of the figure 1 below ‘Order by Internet’ illustrates a textual use case. This use case
assumes that the customer has already selected the products he intends to buy and requests an
2
order. A use case diagram presents the use cases of the system and their relationships with the
actors.
Order by Internet
1. Brief Description
A customer gets his shopping cart previously prepared and requests an order. The
system validates the order and confirms it to the customer.
2. Actor
The customer.
3. Flow of Events
3.1
Basic Flow
Step 1. Member requests to view his cart.
Step 2. System displays the cart content
Step 3. Member requests to check out
Step 4. System checks if member has outstanding fees
Step 5. System displays terms and conditions
Step 6. Member accepts the terms and conditions
Step 7. System sends the order to the shipping
3.2
Alternative Flows
Step 3a. Member exits
Step 4a. Member has to pay outstanding fees
Step 6a1. Member refuses the terms and conditions
Step 6a2. System returns to Step 3
4. Special Requirements
None.
5. Pre-conditions
Member has logged in and has prepared a shopping cart.
6. Post-conditions
The order is confirmed.
7. Extension Points
4a. If system has outstanding fees, ‘Pay outstanding fees’
Fig. 1: Textual Use Case ‘Order by Internet’
3
2. Writing a visual use case
The same items usually described in a textual use case can as well be described in a visual use
case. The table below presents how to formalize these items in an activity diagram.
Textual format
Brief description
Actor(s)
Flow of events
Basic
Alternative
Special requirements
Pre-conditions
Post-conditions
Extension points
Include
Extend
Visual format
Legend of the diagram (a note)
Swim lane(s) or Stereotype(s)
Activity
Bold path
Alternative path indicated by a decision symbol
Additional text
Notes linked to the initial state
Notes linked to the final state
Directly identified in the diagram
An ‘Include’ activity which refers to an abstract use case
An ‘Extend’ activity which refers to an abstract use case
Table 1: Transforming a textual use case into a visual use case (an activity diagram)
Standard UML notation for activity diagrams is used, as well as the following additional
conventions (See Figure 2):
 Grey rectangles for actor’s interfaces;
 System error with a dotted line.
The same example as in section 1, ‘Order by Internet’, illustrates a visual use case and is
presented in the figure 3 below. An alternate representation of the actors consists of labeling
each activity with a stereotype. The use case writer would then have the freedom to position the
activities in the diagram, for instance by vertically aligning them according to the main flow.
3. Benefits of Visual Use Case
We think that visual use cases are fairly easier to read than their corresponding textual use
cases. All decision points are clearly visualized, as well as the loops in the processing sequence.
They constrain use case writers to limit the size of each diagram and to be concise in specifying
each step within the rectangle of an activity.
Whereas textual use cases are written in a word processor with hyperlinks to the modeling tool,
visual use case writing is possible with most of the modeling tools. The model transformation from
requirements to system is therefore much easier to follow.
4
Visual Use Case
legend of the swim
lane approach
Initial state
User
System
Pre-conditions
-Pre-condition 1
-Pre-condition 2
-...
User or system action
Final state
Main
user
action
Interface
Branch
System process
Alternate user action
Main flow
"System
error
message"
Alternate flow
Error flow
Alternate
system
action
"System
message"
Post-conditions
-Post-condition 1
-Post-condition 2
-...
Main system action
Fig. 2: Visual Use Case notation and conventions
Use case diagrams can also be replaced by activity diagrams, which can contain much more
information, such as dependencies between use cases (See Figure 4). In such a diagram, each
activity represents a use case, which can then be decomposed in its details. Business process
models and use case models can now evolve with the same notation, especially with the new
possibilities for activity diagrams offered by UML2, the last UML version.
Another important benefit is the easy identification of the test cases (See Figure 5), since each
test case can be deduced from a path along the branches of the activity diagram. Test case
identification could also be assisted by computer.
Finally, visual use cases facilitate the quality control, by helping to find the missing flows and the
counting of interfaces to build, messages to write and flows to test.
5
Fig. 3: Visual Use Case ‘Order by Internet’, with swim lanes
6
Fig. 4: Visual Use Case Activity Diagram
4. Results of the surveys
We conducted two surveys to compare textual and visual use case representations:
 The first one among a group of 21 students, during the course ‘Enterprise Information
Systems’, within the ‘IT Engineering’ program, generally taking place during the third
year;
 The second one among a group of eight IT professionals.
Results of these two surveys are summarized below.
4.1 Results of the first survey
A textual use case, similar to the one presented in figure 1, was submitted to the students. They
were asked to first represent the case with an activity diagram, then to identify the pros and cons
of the visual representation and to recommend one of the representations.
Results are presented in the table below.
7
1
2
3
Pros of the visual representation
Ease of reading
Scenario identification
Overview
Number of students
14
11
7
1
2
Cons of the visual representation
Complex diagram, if specifications are complex
Level of details
Number of students
5
4
Favor Textual
Representation
4
Don’t favor any
Favor Visual Representation
15
2
Table 2: Pros and cons of the visual use case
Students largely favor the visual representation, thanks to easier reading and scenario
identification. Some of them were questioning an added complexity and the possibility to
represent a sufficient level of details.
4.2 Results of the second survey
The survey was conducted among a group of professional consultants, with an average
experience of 10 years.in system modeling. They were asked to answer a questionnaire to
evaluate the efficiency of visual compared with textual use case modeling. Six criteria were
evaluated:
o Efficiency: global efficiency of the technique for the development process;
o Ease of building the use case model;
o Completeness to cover all the possibilities expected in a use case;
o Accuracy to express the requirements;
o Ease of reading for the non technical people;
o Ease of reuse of the use case model in the activities following the requirement
specifications.
Each criterion got one value of a 1 to 5 scale:
1.
2.
3.
4.
5.
strongly prefer visual format
slightly prefer visual format
no preference
slightly prefer textual format
strongly prefer textual format.
mili-et-al.pdf
Eight persons answered the questionnaire (which had been sent to
Results are shown in the table below.
12 persons).
8
Criterion
Ease of building
Completeness
Accuracy
Ease of reading
Ease of reuse
Efficiency
Average
2
2
2,75
1,75
1,75
1,625
Global Average
2
Table 3: Evaluation of visual vs. textual use case representation.
Visual use case representation is globally slightly favored. Efficiency is its strongest advantage,
whereas accuracy is its most severe weakness.
Though these two surveys had a limited scope they clearly indicate that visual use cases are an
interesting alternative to textual use cases. However, they need to prove their accuracy in order
to be largely adopted.
5. Conclusion
Visual use cases have significantly improved our practice of use case and system modeling in
terms of efficiency and ease of use.
A visual use case can replace any textual use case. It has proved to be specially powerful for
commercial web site design. As with textual use cases, one has to be careful with:
 The level of abstraction to take;
 The number of steps to describe (group some, split others);
 The actions not contributing to the functional goals (hyperlinks from the navigation menu);
 The functions that take more than one page to describe (we recommend the use of
"include" and "extend");
 The flows that intersect each other (again, we recommend the use of "include" and
"extend").
Several additional enhancements may be investigated to assist the business and system
modelers in transforming the business process models into use case models and then into
system models. Automatically generating prototypes and test cases are also promising avenues
to be investigated.
9
References
[1] Jacobson, I., et al., Object-Oriented Software Engineering: a Use-Case Driven
Approach, Addison Wesley, 1992, Wokingham.
[2] Kruchten, P., the Rational Unified Process, an Introduction, Addison Wesley, 2000.
[3] OMG, UML 2.0 Sperstructure Spécification: Final Adopted spécification(2003)
document ptc/08-03-02, 2004, OMG.
[4] Cockburn, A., Writing effective use cases, Addison Wesley, 2001.
[5] Larman, C., Applying UML and Patterns, 3rd edition, Prentice Hall, 2005, Upper
Saddle River.
[6] Czarnecki, K., & Eisenecker, U., Generative programming : methods, tools, and
applications, Addison Wesley, 2000.
[7] Kleppe, A. G., Warmer, J. B., & Bast, W. (). MDA explained: the model driven
architecture : practice and promise, Addison-Wesley, 2003, Boston.
[8] Jacobson, I., and Ng, P., Aspect-Oriented Software Development with Use Cases.
Addison-Wesley, 2005, Upper Saddle River.
10