0% found this document useful (0 votes)
34 views7 pages

Lab 04 - SCNLAB

The document introduces use case diagrams in UML. It defines visual modeling and its benefits for understanding problems and communicating solutions. Use case diagrams show actors and use cases, including relationships between them. The document provides examples of actors, use cases, and relationships. It includes a task that guides modeling actors and use cases for a blood donation system and recycling machine based on problem statements.

Uploaded by

Aakif Bhatti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views7 pages

Lab 04 - SCNLAB

The document introduces use case diagrams in UML. It defines visual modeling and its benefits for understanding problems and communicating solutions. Use case diagrams show actors and use cases, including relationships between them. The document provides examples of actors, use cases, and relationships. It includes a task that guides modeling actors and use cases for a blood donation system and recycling machine based on problem statements.

Uploaded by

Aakif Bhatti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Lab 04

Lab 04 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.

Name: Choudhary Saif Ali Reg No:


57268
10
10
Lab 04
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

Name: Choudhary Saif Ali Reg No:


57268
11
11
Lab 04

system's intended functions (use cases), its surroundings (actors), and relationships
between the use cases and actors (use case diagrams).

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.

Name: Choudhary Saif Ali Reg No: 57268


Lab 04

Figure 1: Use case diagram example

TASK:
Now you will learn how to apply the above-mentioned methods to draw use case
diagrams
1. From the problem statement of your project.
1. Actors
 Donor
 Receiver
2. Use cases with each actor
 Donor Registration
 Manage Users
 Generate Report
 Update his details
 System authorization
 Request for blood
 Update the database
 Send Alerts
3. Finally: draw the main use case diagram:

Name: Choudhary Saif Ali Reg No: 57268


Lab 04

2. From the pr ov i de d problem statement of your project.

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 receipt roll is finished, the operator will be called by a special alarm signal.

After reading the above problem statement, find:


4. Actors above statement will be as follows:
 Customer
 Operator
5. Use cases with each actor
 Bottle
 Can
 Check Return
 Register Return

Name: Choudhary Saif Ali Reg No: 57268


Lab 04

 Ask Receipt
 Print Receipt
 Whole Day Deposited
 Total Deposited Receipt
 Update Info
 Alarm Signal
6. Find extended or uses use cases (if applicable)
 Bottle extend Can
 Check Return extend Register Return
 Ask Receipt
 Print Receipt
 Whole Day Deposited
 Total Deposited receipt
 Update Info
 Alarm Signal

Name: Choudhary Saif Ali Reg No: 57268


Lab 04

4. Finally: draw the main use case diagram:

Name: Choudhary Saif Ali Reg No: 57268

You might also like