Software Engineering Lab Manual (14B17CI572)

Lab 5: Introduction to UML and Use Case Diagram

Objectives
• Study the benefits of visual modeling.
• Learn use case diagrams: discovering actors and discovering use cases.
• Practice use cases diagrams using Rational Rose.

1. Outline
 Visual modeling.
 Introduction to UML.
 Introduction to visual modeling with UML.
 Use case diagrams: discovering actors and use cases.

2. Background
Visual Modeling is a way of thinking about problems using models organized around
real-world ideas. Models are useful for understanding problems, communicating with
everyone involved with the project (customers, domain experts, analysts, designers,
etc.), modeling enterprises, preparing documentation, and designing programs and
databases

2.1 Visual Modeling

 Capture the structure and behavior of architectures and components.
 Show how the elements of the system fit together.
 Hide or expose details appropriate for the task.
 Maintain consistency between a design and its implementation.
 Promote unambiguous communication.

2.2 What is UML?

The UML is the standard language for visualizing, specifying, constructing and
documenting the artifacts of a software-intensive system. UML can be used with all
processes throughout the development life cycle and across different implementation
technologies.

2.3 History of UML

The UML is an attempt to standardize the artifacts of analysis and design: semantic
models, syntactic notation and diagrams. The first public draft (version 0.8) was
introduced in October 1995. Feedback from the public and Ivar Jacobson's input were
included in the next two versions (0.9 in July 1996 and 0.91 in October 1996).
Version 1.0 was presented to the Object Management Group (OMG) for
standardization in July 1997. Additional enhancements were incorporated into the 1.1
version of UML, which was presented to the OMG in September 1997. In November
1997, the UML was adopted as the standard modeling language by the OMG.

2.4 Putting UML into Work: Use Case Diagram

The behavior of the system under development (i.e. what functionality must be
provided by the system) is documented in a use case model that illustrates the
system's intended functions (use cases), its surroundings (actors), and relationships
between the use cases and actors (use case diagrams).

16
Software Engineering Lab Manual (14B17CI572)

2.5 Actors
 Are NOT part of the system – they represent anyone or anything that must
interact with the system.
 Only input information to the system.
 Only receive information from the system.
 Both input to and receive information from the system.
 Represented in UML as a stickman.

2.6 Use Case

 A sequence of transactions performed by a system that yields a
measurable result of values for a particular actor
 A use case typically represents a major piece of functionality
that is complete from beginning to end. A use case must
deliver something of value to an actor.

2.7 Use Case Relationships

 Between actor and use case.
 Association / Communication.
 Arrow can be in either or both directions; arrow indicates who initiates
communication.
 Between use cases (generalization):
– Uses
• Where multiple use cases share pieces of same functionality.
– Extends
• Optional behavior.
• Behavior only runs under certain conditions (such as alarm).
• Several different flows run based on the user’s selection.

3. CASE Tools
The Rational Rose product family is designed to provide the software developer with
a complete set of visual modeling tools for development of robust, efficient solutions
to real business needs in the client/server, distributed enterprise and real-time systems
environments. Rational Rose products share a common universal standard, making
modeling accessible to nonprogrammers wanting to model business processes as well
as to programmers modeling applications logic.

4. In-Class Example
Now you will learn how to apply the above-mentioned methods to draw use case
diagrams from the problem statement.

17
Software Engineering Lab Manual (14B17CI572)

5. Exercises
Read carefully the following problem statement
We are after a system that controls a recycling machine for returnable bottles and
cans. The machine will allow a customer to return bottles or cans on the same
occasion.

When the customer returns an item, the system will check what type has been
returned. The system will register how many items each customer returns and, when
the customer asks for a receipt, the system will print out what he deposited, the value
of the returned items and the total return sum that will be paid to the customer.

The system is also be used by an operator. The operator wants to know how many
items of each type have been returned during the day. At the end of the day, the
operator asks for a printout of the total number of items that have been deposited in
the machine on that particular day. The operator should also be able to change
information in the system, such as the deposit values of the items. If something is
amiss, for example if a can gets stuck or if the receipts roll is finished, the operator
will be called by a special alarm signal.

After reading the above problem statement, find:

1. Actors
2. Use cases with each actor
3. Find extended or uses use cases (if applicable)
4. Finally : draw the main use case diagram:

6. Deliverables
You should submit the solutions for the previous exercises.
You should use these techniques to draw use case diagrams for your term project
using Rational Rose.

18