Uml Lab Material

Experiment 1:Familiarization of Rational Rose Environment
Objective and Background
The purpose of this UML lab is to familiarize programmers with

Rational Rose UML environment and Java application development. We will
learn how to work with Rational Rose Enterprise software, Case diagram, and
Class Diagram. We will also learn how to create a Use Case, two Java classes
called HelloUML and Test, generate Java code, edit the Java code, and
compile the Java program. At the end of this lab, you should be able to run
the program Test to display HelloUML message under the Windows
command line.
WEB SITE REFERENCES
Professor Lins Web site:http://www.etcs.ipfw.edu/~lin

Rational, the Software Development Companywww.rational.com
PROCEDURE
a. Tour of Rational RoseEnvironment

Application Window: a title bar, tool bar, menu bar, and a work
area for displaying toolbox, browser, document window, diagram
window, and specificationwindow
Browser: a window with navigation tool for viewing diagrams
andmany other modelelements
Documentation Window: for preparing text information to describe
model elements orrelationships
DiagramWindows
Overview Window: can be showed through put the mouse pointer
over handicon
Other windows such as Log, Edit, can be access through View on
menu bar
1
Title
Bar
Menu
Bar
Tool
Bar
Browser
Documentation Toolbox Diagram

Window Window
Specification
Window
b) Creating a simple application(Hello.java)
Step 1: Run Rational Rose

EnterpriseStep 2: Create a Use Case
Diagram
2
Click on UseCase View >Main
1. From the menu bar select Tool > Create > UseCase
2. Select the Actor from the Toolbox and place it into the Use
CaseDiagram
3. Right click on the Actor to see the pop-up menu, and then select
Open Specificationmenu
4. Select the Use Case from the Toolbox and place it into the User
Case Diagram
3
5. Right click on the User case to change the name toHelloUML
HelloUML
Actor
Step 3: Create Hello Class Diagram (classes, attributes, and operations)
1. Click on UseLogical View >Main
1. Create a new class calledHello

- Tools > Create >Class
- Select the Class icon (rectangle
box symbol) from theToolbox
4
- Place a class to the workspace of the ClassDiagram
- Type in a desired class name:Hello
- Right click the new class diagram and select OpenSpecification
- View the class name in the name box:Hello
2. Add Attributes to the Helloclass

- Right click the Hello class to select New Attributes from a dialogbox
- Accept the default name, and
hitenter
- Right click the Hello class again to select OpenSpecification

- The window called Class Specification for Hello is then displayed;
change the attribute name to message; select Type as: String; specify
Initial Value with a pair double quotes as: Hello UML; set Export
Control to:private
3. Add Operations to the Helloclass

- Right click the Hello class to get an dialogbox
- Select New Operations, and give a new method name
asgetName, then hit Enter key to enter another method name
asHello
- Double click the getName method to display
OperationSpecification menu for getName dialogbox
- Add return type as: String; add some information on
5
thisoperation method to Document textbox
4. Change Operation Specification for Hellomethod

- Right click on the class diagram Hello to select
OperationSpecification for showing Class Specification forHello
- Select Implementation radio button in the ExportControl
- Verify the Hello class diagram is the same as shownbelow.
6
Hello
message : String = "Hello
UML"
getName() Hello()
Step 4. Create the Test Class Diagram
1.Select Class icon from theToolbox

2.Place a class into the workspace Class Diagram, and give the
classname:
Test
3.Right click on the Test class, and select NewOperations
4.Add two methods: main andTest
7
Step 5. Object Instantiation
1. Select the dash line icon (Dependency orinstaintiates)
2. Draw the line starting from the Test to Hello to make an
object instantiation
8
Step 6. Code Generation
1. From the menu bar, select Tools > Java/J2EE >
ProjectSpecification.
2. Double-click on the last one of the Classpaths as shown in the
following diagram.
3. Click
on the
button
with
three
dots to
see a
dialogbox.
4. ChooseDirectory.
9
10
5. Select the class diagrams, Test and Hello by left clicking on
Test first and hold down Ctrl key and left click on
Helloclass.
6. From the menu bar, select Tools> Java/J2EE> Generate
Code. Choose your working directory and clickOK.
The following warning message from the dialog box and Log windows is OK
for the time being:
11
20:47:43| WARNING: Class Logical View::Test - no return type has
been specified for operation main - default will be used
The following codes in Hello.java and Test.java are generated
//Source file: C:\\My Documents\\Hello.java

class Hello
{
private String message = "Hello UML";
/**
* @roseuid 3C4762C801C8*/
*/
public Hello()
{
}
/**
* @returnString
* @roseuid3C4762A1029E
*/
public String getName()
{
return null;
}
}
//Source file: C:\\My Documents\\Test.java

public class Test
{
/**
* @roseuid 3C47635B0350
*/
12
public Test()
{
}
/**
* @roseuid 3C476355017B
*/
public void main()
{
}
}
7. main() is not static method in the generated codes. To change the
method to static type: Right click on the class, Test, the dialog box
will appear. Click on Operations tab. Double click on main method
and another dialog box will appear. Click on java tab and the
following dialog box will appear. Click on Edit Setbutton.
8. Create a new set static by cloning. Type in the name static in the
following dialogbox.
13
9. Change static to betrue.
Select two classes Test and Hello.

Code generate again with the
command from menu bar Tools>
Java/J2EE> Generate Code and
no error message should appear
thistime.
Step 7. Java Code Editing

1. Open source java files in Notepad and edit those files as shown
below. Or use any other Development Environment such as JBuilder or
JCreator. Change or add according to the highlighted words in the java
sourcefiles.
14
//Source file: E:\\lwinmoe\\lab1\\Hello.java
public class Hello
{
private String message = "HelloUML";
/**
* @roseuid 3C47663F006F
*/
public Hello()
{
}
/**
* @returnString
* @roseuid3C47663A025C
*/
public String getName()

{
return message;
}
}
//Source file: E:\\lwinmoe\\lab1\\Test.java

public class Test
{
/**
* @roseuid 3C4766960237
*/
public Test()
{
}
/**
* @return Void
* @roseuid 3C4766930387
*/
public static void main(String[] args)
15
{
Hello h = new Hello(); // instantiate a Hello object called h
System.out.println(h.getName()); // call getName() method from Hello
object
// h
}
}
Step 8. Compiling and Running Java Program from Command Line
1. To compile Hello.java and Test.java from command

line, open a commandshell.
2. Make sure the path is set to c:\jdk1.3.1_01\bin or the
directorywhere Java Development Kit (JDK) wasinstalled.
3. Run javac program with the source file Hello.java with
theparameter name. Do the same forTest.java.
4. Run your Test program with thecommand>java Test
VIVA QUESTIONS:-
1. Name some tools for UML?

Ans: Commercial UML tools:
1) Rational Rose
2) Blueprint Software Modeler
3) Power Designer
4) Borland Together
16
5) eRequirements
Free UML tools:

1) ClassBuilder
2) Use Case Maker
3) TinyUML
2. What is UML?
Ans: UML stands for Unified Modeling Language and it is a graphical

language for visualizing, specifying, constructing, and documenting the
artifacts of a software system under development.
3. What are the various UML modeling diagrams?
Ans: UML Modeling diagrams can be classified in two categories:

Static/Structural and Dynamic/Behavioral.
Static/Structural Diagrams:
1) Class Diagram
2) Component Diagram
3) Object Diagram
4) Package Diagram
5) Deployment Diagram
Dynamic/Behavioral Diagrams:
1) Activity Diagram
2) State Machine Diagram
3) Use Case Diagram
4) Sequence Diagram
5) Communication Diagram
17
UML & DP Lab Manual Page No.: 18
4. What are the different views that are considered when building an object-
oriented software system?
Ans: Normally there are 5 views.
Use Case view - This view exposes the requirements of a system.

Design View - Capturing the vocabulary.
Process View - modeling the distribution of the systems processes and

threads.
Implementation view - addressing the physical implementation of the

system.
Deployment view - focus on the modeling the components required for

deploying the system
NRI Institute of Technology Department of CSE

EXPERIMENT 2:LIBRARY MANAGEMENT SYSTEM
1. Problem Statement:
The goal of this project is to establish the requirements for a new library
Management system.
Librarians should be able to use this system to keep track of all

books in the library. It must enable us to catalog a wide range of
information: author, title, ISBN number, editor, type of book and status. It
must contain information about login database: student login id, staff login
id, administration login id etc. The student account must contain a clear
record about each & every book, their library account number, information
about the journals & magazines that are available in the library, it must
also maintains records about newspapers, the record of books available for
the reference etc. The staff account must enables the record of the total
number of books that are allocated for them & their account number etc
.The administration account must maintain the record of new books that
are available in the library, the record of books that are under repair, finally
the system should be able to calculate any fee payable on an overdue books,
there may be changes over a span of time. This updated information must
be accessed by the system.
2. Identification of Actors:
Actor Definition:
An Actor is anything that interacts with the use case: human user,
external hardware or another system.
Graphical Representation:

<<Actor>>
<<Actor>>
Customer
Customer
Questions to identify Actors:
1. Who is interested in a certain requirements?
2. Where in the organization is the system used?
3. Who will benefit from the use of the system?
4. Who will supply the system with this information & uses the information &
removes the information?
5. Who will support and maintain the system?
6. Does the system use an external resource?
7. Does one play several different roles?
8. Does several people play the same role?
9. Does the system interact with the legacy system?
Actors Identified in Library Management System:
Librarian Member Supplier
3.Identification of Use cases and Sub use cases:
Definition:

Use case model defines the outside (actors) and inside (use case) of the
systems behavior.
Use cases are initiated by actors and describe flow of events that these actors
set off.
Graphical Representation:
Process
Questions to Identify Use cases:
1. What are the tasks of each actor?

2. Will any actor create, store, change, remove or read this information?
3. What use case will create, store, change, remove or read this
information?
4. Will any actor need to inform the system about sudden external
changes?
5. Does any actor need to inform about external occurrences in the system?
6. What use case will support and maintain the system?
7. Can all functional requirements to be performed by the use cases?
Use cases Identified in Library Management System:
1.
Borrow Books
This use case allows the member to borrow books from the library.

2.
Return Books
This use case allows the member to return books.
3.
Inter Library Loan
This use case allows the member to provide the books which are not available
in the library.
4.
Check Library Card
This use case allows the member to check the limit of books and also the due.
5.
Do Research
This use case allows the member to do research.
6.
Purchase Supplier

This use case allows the supplier to purchase books.
7.
Read Books, Newspapers
This use case allows the member to read books and newspapers in the library.
4. Construction of use case Diagram:
Definition:
A use case diagram is a graph of actors, a set of use cases

enclosed by a system boundary, communication associations between the
actors, use cases and generalization among classes
Relation ships:
Use cases diagram consists of Actors, use cases and relation ships
to connect the actors and use cases. The relation ships are
Dependency:
It is a semantic relation ship between two things in which a change

to one thing may affect the semantics of the other thing.
Figure (
Association:
It is structural relation ship that describes a set of links, a link

being a connect among objects.

Aggregation is a special kind of association, a structural relation

ship between a whole and its parts.
0...1 *
Employer Employee
Generalization:
It is a specialization / generalization relationship in which objects of specialized

element (the child) are substitutable for objects of the generalized element (the
parent).
Extends And Includes:
Extends:
The extends association is used when you have one use case that is
similar to another use case but does a bit more or is more specialized in
essence, it is like a subclass.
Includes:
The includes use case extracts the common sub flow and make it a
use case of its own.
No sub use cases for College Information System.
Use case diagram of Library Management System :

accession
supplier
issues
member
enquiries
LMS_DB
librian f ine collections
Not login()
return()
book catalog
outers
reenquiry
member catalog
returns
5. Acitivity Diagram:
Definition:
An activity diagram shows the flow from activity to activity.
Activity:
It is an ongoing non atomic execution within a state machine.

Activities ultimately result in some action, which made up of executable atomic
computation.

Process order. This is represented by Lozenge shape
Contents of Activity Diagram:
1. Activity states and action states:
Activities have two states.
Wait state State during which there is no internal activity by the object
and the object is waiting for some external event to occur.
Activity State Performs some set of actions
2. Transition:
It is relationship between two states indicating that an object is the

first state will perform certain actions and enter the second state when a
specific event occurs and specific conditions are satisfied.
Parts of transition:
Source state
Event trigger
Guard condition
Action
Target state
Source state - state affected by the transition; changes when event and
guard condition satisfied.

Event trigger Event whose reception by the object in source state makes
transition eligible to fire, guard condition satisfied.
Guard condition Boolean expression evaluated when transition is

triggered on receiving an event.
Action Executable atomic computation.
Target state state that is active after the completion of the transition.
Synchronization:
Forking
A fork represents the splitting of a single flow of control into two or more
concurrent flows of control.
A fork may have one incoming transition and two or more outgoing
transitions, each of which represents an independent flow of control.
Joining
A join represents the synchronization of two or more concurrent flows of

control.

A join may have two or more incoming transitions and one outgoing
transition.
Guard Condition:
Activity and state diagrams express a decision when

conditions (guard) are used to indicate different possible transitions that
depend on Boolean conditions of container object.
Start state:
Default starting place for state machine/ sub state.
End state:
Execution of the state machine/ enclosing state
Swim Lanes
The activity diagram divided into groups, each group representing the
business organization responsible for those activities.
Each group is called a swim lane.
Each group is divided from its neighbor by a vertical solid line.

Activity diagram of Library Management System:
MEMBER LIBRIAN
return book go to counter if due Giv e details

y and return book of due
N pay cash
borrow book
inter lib loan
Y section
N N
check f or book in
do research
do research
Y done
N checkout
books
do news read news papers Y
Y
N

member librarian
give details of due

[ if yes ] / return book go to counter and [ if due ] / give details
return book? return book exit/ give to member
do/ check for any due
[ if no ] pay cash
[ if yes ] / inter lib loan interlibrary

borrow book?[ if yes ] inter lib loan?
loan section
do/ check out... book
[ if no ]
check for [ if no due ]
book in ... [ if yes ] / check books
done? checkout
[ if no ] books...
[ if yes ] / do research
do research do
researc...
[ if no ]
[ if no ]
[ if yes ] / read books&newspapers

read read
newspapers&book newspap...
[ if no ]
6. Identifying Analysis Classes:
Approaches to Identify classes:
There are four approaches to identify classes

Common class pattern approach
This is based on a knowledge base of the common class that have

been proposed by various researchers. The following are the patterns to identify
classes and objects
Concept class
Event class
Organization class
People class
Places class
Tangible things and devices class
Classes, Responsibilities, and Collaborators Process:
Classes, Responsibilities, and Collaborators Process consist of three

steps
1. Identify classes responsibilities

2. Assign responsibilities.
3. Identify collaborators
Use-Case Driven Approach: Identifying classes and behavior through

sequence/collaboration modeling
In this Approach once the system has been described in terms

of its scenarios (use cases), modeler can examine the steps of each scenario to
determine what objects are needed for the scenario and for it you need to draw
sequence /collaboration diagram for each use case
Noun Phrase Approach:
Here we identify the classes by observing the problem

statement. The nouns and noun phrases in the use cases and some classes are

implicit or taken from general knowledge. Here we divide the classes into 3
categories:
Relevant classes,
fuzzy classes,
irrelevant classes.
Here we eliminate all the irrelevant classes and the candidate

classes must be selected from relevant and fuzzy classes.
Redundant Classes:
Do not keep two classes that express the same information if more
than one word is used to describe the same idea select the one that is the more
meaningful in the context of the system.
Adjective Classes:
Adjectives can be used in many ways. An adjective can suggest a

different kind of objects, different use of the same object, or it could be utterly
irrelevant. Does the object represented by the noun behave differently when the
adjective is applied to it? If the use of the adjective signals that the behavior of
the object is different, and then makes a new class
Attribute Classes:
Tentative objects that are used only as values should be defined or

restated as attributes and not as a class.
Irrelevant Classes:

Each class must have a purpose and every class should be clearly
defined and necessary. You must formulate a statement of purpose for each
candidate class. If you cannot come up with a statement of purpose, simply
eliminate the candidate class.
Identifying classes in Library Management System:
Initial list of nouns phrases in library management system: Candidate classes
Account number
Password
Library card
Student
Staff
Member
Visitor
Due
Login
Supplier
Library system
Card
Transaction
Books
Books catalogue
Reference books
Amount

Inter library loan
Due date
Loan
Librarian
Account
Account holder
Magazines
Administrator
Approval process
List of nouns after eliminating Irrelevant classes
Account number
Password
Library card
Student
Staff
Member
Visitor
Due
Login
Supplier
Library system
Card
Transaction

Books
Books catalogue
Reference books
Amount
Inter library loan
Due date
Loan
Librarian
Account
Account holder
Magazines
Administrator
Approval process
System
List of nouns after eliminating redundant classes
Library card, card = library card
Login, approval process =login
Books, books catalogue =books
Librarian, administrator =librarian
Account number
Library card
Student
Staff

Member
Due
Login
Supplier
Card
Books
Books catalogue
Amount
Due date
Librarian
Account
Administrator
Approval process
Eliminating possible attributes
Account number
Library card
Student
Staff
Member
Due
Login
Supplier
Books
Amount

Due date
Librarian
Account
Class purpose
Library card Provides an information about books taken, limit of books to

member and librarian.
Student Provides information about student.
StaffProvides information about staff.
Member It is a generic class of student and staff which provides common

properties of student and staff
LoginIt the particular member to login to system
Supplier It provides the information about the supplier like

company, address
Books Providesinformation about books like ISBN no, publisher, title
7. Identifying Use case Realizations:
Definition:
A use case realization is a graphic sequence of events, also referred to as

a scenario or an instance of a use case.
These realizations or scenarios are depicted in either a sequence or

collaboration diagram.
Representation:

Use Case Realizations of Library Management System :
Borrow Books Use Case Realization:
borrow borrow
(from Use Case View)
Do ResearchUse Case Realization:
do research
do research
Purchase SupplierUse Case Realization:
purchase supplier purchase supplier

ReadBooks Use Case Realization:
read read
Return Use Case Realization:
return return

Check Library Card Use Case Realization:
check library card check library card

Inter Library Loan Use Case Realization:
inter library loan inter library loan

8. Construction of Sequence Diagram:
Sequence diagram is an interaction diagram that emphasizes the time

orderingof the messages.
Collaboration diagram is an interaction diagram that emphasizes the
structural organizationof the objects that send and receive messages.
A sequence diagram is a graphical view of a scenario that shows object
interaction in a time-based sequence -- what happens first, what
happens next.
A sequence diagram shows an interaction arranged in a time sequence.
Sequence diagram has two dimensions:
a) Vertical dimension ----- time
b) Horizontal dimension ----- different objects
Vertical line is called objects lifeline.
Lifeline represents the objects existence during the interaction.

An object is shown as a box at the top of a dashed vertical line.
Sequence contains the following things:
Object Messages
Lifeline
Focus Of control period of time during which an object is performing an

action.
Self Delegation.
9. Sequence Diagrams for Library Management System:
Sequence diagram for Borrow Books Use Case:

: books : library card

: member
1: login()
: librarian
2: select
3: check status
4: book available
5: request book
6: request library card
7: account not full

8: issue book
9: change book status
Sequence Diagram for Do Research Use Case:
: books
: member
1: login
2: select book
3: request book
4: takebook and do research
Sequence diagram for Purchase Supplier Use Case:

: books
: librarian
: supplier
1: give details of the book
2: request books
3: supply books
4: add to books catalog
Sequence diagram for Read Use Case:
: books
: member
1: login
2: check status
3: book available
4: take book and read

Sequence diagram for Return Books Use Case:
: library card
: books
: member : librarian
1: return book
2: check card
3: due
4: calculate due
5: give amount details
6: pay amount
7: change status
10. Construction of Collaboration Diagram:
Represents
a) Collaboration, a set of objects related in a particular context.
b) Interaction set of messages exchanged among objects to achieve a desired

outcome.
As in a sequence diagram, arrows indicate the message sent within the

given use case.

In a collaboration diagram, the sequence is indicated by numbering the

messages.
Numbering Scheme
General numbering scheme

---- 1, 2, 3, 4.
Decimal numbering scheme

--- 1, 2, (2.1 2.2), 3, 4
Collaboration Vs Sequence:
The collaboration diagrams contain the path and sequence

number which is not present in sequence diagram.
Sequence Vs Collaboration:
The sequence diagram contains object life line and focus of control which is
not present in collaboration diagram.
Collaboration Diagrams of Library Management System:
Collaboration diagram for Borrow Books Use Case

: books
10: change book status
: librarian 4: book available
8: account not full
7: check for limit 9: issue book
1: login()
2: select
5: request book 3: check status
: library 6: request library card
card
: member
Collaboration diagram for Do Research Use Case:
: books
4: takebook and do research
1: login
2: select book
3: request book
: member
Collaboration diagram for Purchase Supplier Use Case:

1: give details of the book

2: request books
3: supply books
: librarian : supplier
4: add to books catalog
: books
Collaboration diagram for Read Use Case:
1: login
2: check status
4: take book and read

: books
3: book available
: member
Collaboration diagram for Return Use Case:

4: calculate due
1: return book
6: pay amount
5: give amount details : librarian
: member
7: change status
3: due
2: check card
: library
card
: books
11. Class Relationships:
Three types of relationships among classes are:
Association: How are objects associated? This information will guide us in

designing classes.
Super-sub structure (also known as generalization hierarchy): How are objects

organized into superclasses and subclasses? This information provides us the
direction of inheritance.
Aggregation and a-part-of structure: What is the composition of complex

classes? This information guides us in defining mechanisms that properly
manage object-within-object.
Attributes:

Questions to identify attributes and methods:
The following questions help in identifying the responsibilities of classes and

deciding what data elements to keep track of:
What information about an object should we keep track of?

What services must a class provide?
Guidelines for Defining Attributes:
Here are the guidelines for identifying attributes of classes in use cases
Attributes usually correspond to nouns followed by prepositional phrases

such as cost of the soup. Attributes also may correspond to adjectives or
adverbs.
Keep the class simple; state only enough attributes to define the object
state.
Attributes are less likely to be fully described in the problem statement.
You must draw on your knowledge of the application domain and the
real world to find them.
Omit derived attributes. For example, does not use time elapsed since
order. This can be derived from time of the order. Derived attributes
should be expressed as a method.
Do not carry discovery of attributes to excess. You can add more
attributes in subsequent iterations.
Attributes identified in Library Management System:
12. Construction of State Chart Diagram:
Definition:

Shows sequence of states that an object goes through during its life time in
response to outside stimuli and messages.
Representation:
Parts of a State:
Name
Entry/ Exit actions - Actions executed on entering/exiting a state
Internal transitions- Transitions handled, but no change in a state

Sub states - nested structure of a state
Deferred events list of events that are not handled in that state but
postponed to be handled in another state
Initial and Final states:
Initial - default starting place for state machine/ sub state.
Final Execution of the state machine/ enclosing state.
State Chart Diagram for Library Management System:

13. Construction of Class Diagram:
Definition
Also referred as object modeling, main static analysis diagram.

Show the static structure of the model that contains classes and their
relationships.
Class Notation: Static Structure
Rectangle 3 components class name, attributes and operations.
Class Diagram for Library Management System:

librarian
(from analysis model)
1
1 issue book()
receive due() 1
update database()
1 1 library card
1..n account no
supplier books status
comp name
1
supply books()
library member
name
id
address books
1..n
acc no
1..n 1..n ISBN no
login ()
req book() publisher
renewal () version
pay due() author
title
student staff
(from analysis model) (from analysis model)
year dept
branch designation
14. The Component View
In the component view of the model, a source code component

represents a software file that is contained by a package. The type of the file is
language independent.
The UML notation for a component is as follows.

Receipt
Generation
Validation LMS_DB
Member
Catalog
BooK
Catalog
Issues Returns Fine
Collection
A The Deployment View
The deployment view of architectures involves mapping software to

processing nodes it shows the configuration of run time processing
elements and the software processes living on them.
validation
Library card
Scanner
issues Library Data receipt

generation Bill printing
base
system
fine
collection
book catalog members

returns catalog
VIVA QUESTIONS:-
1. Define Use Case?

Ans: A use case specifies the behavior of a system or a part of a system, these
are used to capture the behavior that need to be developed. It involves the
interaction of actors and the system.
2. How do we represent private, public and protected in class diagrams?

Ans: + indicates that its public properties/methods. -indicates private
properties which means it cannot be accessed outside the class. # indicate
protected/friend properties.
3. Explain use case diagrams?

Ans: There are three important parts in a use case scenario, actor and use
case.
Scenario: A scenario is a sequence of events which happen when a user

interacts with the system.
Actor: Actor is the-who of the system, in other words the end user.
Use Case: Use case is task or the goal performed by the end user.
4. Explain Extend and Include in use cases?

Ans: Extend and Include define relationships between use cases
Include: Include relationship represents an invocation of one use case by

the other. If you think from the coding perspective its like one function
been called by the other function.
Extend: This relationship signifies that the extending use case will work
exactly like the base use case only that some new steps will inserted in
the extended use case.

EXPERIMENT 3:POINT-OF-SALE TERMINAL
1. PROBLEM STATEMENT
Online bookshop is a comprehensive bibliographic database providing

online access to books on various topics. The customer can reserve and
purchase books. He can also get to know the information about pricing and
comparison shopping of each book with an online shopping experience. The
online bookshop should be user friendly in the sense that it has to be easily
navigatable. It should also provide for setting up an account and providing
membership. The process of searching can be done in a number of ways such
as based on name of the author, title of the book, price of the book, category of
the book, name of the publication and date of publication.
The user searches for the book online, selects it and approves the
purchase of the book. The approval of the purchase is done as follows. The
online bookshop takes the credit card number provide by the user and also the
address of the user. If the credit card is known to be valid the online bookshop
approves the purchase and that book is marked as purchased in the database.
2. IDENTIFICATION OF ACTORS
ACTOR:
An actor is anything that interacts with a use case: human user, external
hardware, or another system. The term actor represents the role a user plays
with respect to the system. Actors can be the one that get value from the use
case or just participate in the use case.

The actor in a system is represented as below.
Fig
<<actor>> 1:
<<Actor>>
Customer NewClass
Customer
Representation of actor
You have to identify the actors and understand how they will use and
interact with the system. Candidates for actors can be found through the
answers to the following questions:
Who is interested in certain requirement?

Where in the organization is the system used.
Who will benefit from the use of the system?
Who will supply the system with this information, uses this information
and removes this information?
Who will support and maintain the system?
Does the system use an external resource?
Does one play several different roles?
Do several people play the same role?
Does the system interact with legacy system?
Our system contains the following actors:
Administrator:
He has to assign login Ids to all employees in an organization.
administrator
(from actors)
Customer:
He interacts with the system to purchase the books. Logs in by entering the
user id and password. Chooses the books of interest and pays the required
amount.

CUSTOMER
(from Actors)
Credit card check system:
It is associated with the ordering use case. It validates the credit card of the
user and then performs the required transaction
CREDIT CARD CHECK SYSTEM
(From actors)
Click to dial:
Interacts with the customer for providing the required information in case the
customer requires any details
CLICK TO DIAL
(From actors)
3. IDENTIFICATION OF USECASES AND SUB USECASES
Use case:
A use case is a sequence of transactions in which each transaction is

invoked from outside the system and engages internal objects to interact with
one another and with in the systems surroundings. A use case describes the
courses of events that will be carried out by the system. In its simplest form, a
use case can be described as a specific way of using the system from a users

(actors) perspective. A more detailed description might characterize a use case

as:
a pattern of behavior the system exhibits

a sequence of related transactions performed by an actor and the system
delivering something of value to the actor
Use cases provide a means to:
capture system requirements

communicate with the end users and domain experts
test the system
Graphical Depiction:
The basic shape of a use case is an ellipse:
NewUseCase
The steps for finding use Cases:
For each actor, find the tasks and functions that the actor should be able
to perform or that the system needs the actor to perform. The use case
should represent a course of events that leads to a clear goal.
Name the use cases.
Describe the use cases briefly by applying terms with which the user is
familiar. This makes the description less ambiguous.
Naming a Use Case
Use case names should provide a general description of the use case
function. The name should express what happens when an instance of the use
case is performed. The description of the use case should be descriptive and
consistent.
In our system the following are the use cases:

Use case name: LOGIN
LOGIN
(f rom Usecases)
Description:
The customer enters the user id and password and enters into his account if
they are valid.
Use case name: REGISTRATION
registration
(from registration)
Description:
This use case provides the user with a registration form for the customer to get
registered. It then gives the customer a user id and password for further logins.
It also creates a user account for the customer.
Use case name: SEARCH BOOKS
search books
(from searching books)
Description:
The customer searches his books of interest through various search options
available.
Use case name: SELECT BOOKS

select books
(from selecting books)
Description:
The customer after searching the books of interest selects the books to be
ordered and places them in a cart.
Use case name: ORDER
order
(from ordering)
Description:
The customer confirms the selected books and gives the number of copies
required. He also confirms the mode of payment of the currency.
Use case name: CLICK TO DIAL
click to dial
(from click to dial)
Description:
The customer if in case requires some addition information; he interacts with

the customer care through the 'click to dial' use case.
4. FLOW OF EVENTS

A flow of events is a sequence of transactions performed by the system.

They typically contain very detailed information, written in terms of what the
system should do, not how the system accomplishes the task. Flow of events
are created as a separate files or documents is your favorite text editor and
then attached or linked to use case using the files tab of a model element. A
flow of events should include:
When and how the use case starts and ends?

Use case/ actor interactions?
Data needed by the use case?
Normal sequence of events for the use case?
Alternate or exceptional flows?
Use case name: ONLINE BOOKSHOP
1. Choose registration option, customer information should be provided.
2. Account is created and you can login successfully.
The options available are:
View cart
Check out
Search a book
3. Customer can choose the subjects of his interest, and u can get books found
on search.
4. U can select books and add the books to cart then u will get message that
books added to the cart successfully.
5. Perform check out option. Customer is provided with information about title
of the book, author, quantity, price, discount and totals.
6. Customer needs to select the destination and payment mode.
The payment mode can be
Credit card

Online banking
Cheque or demand draft.
7. U need to confirm order. Then transaction id is provided for secure payment,

u need to proceed for payment.
8. Billing details, delivery details should be provided and from should be

submitted.
Alternative Flows
1. Book not available
In the basic flow, if the system doesnt find the book the customer
requests for, the system displays a message specifying the in availability of
book and requests the customer to give details of book in a special column and
assures the presence of the book in a catalogue if the book is available outside.
2. Insufficient balances in credit card
The system intimates the customer about the insufficient balance in the
credit card through a message and requests customer to check the balance.
3. Special requirements
None
4. Preconditions
None
5. Post conditions
None
6. Extension points.
None
5. Construction of Use case diagram
A use case diagram is a graph of actors, a set of cases enclosed by a

system boundary, communication associations between the actors and the use

cases, and generalizations among the use cases. A use case diagram shows the
relationship among the actors and use cases within system. The following 3
relationships are shown in a use case diagram:
registration
(from registration)
administrator
login
(from actors)
(from loging in)
customer search books

(from searching books)
(from actors)
select books
credit card
check system
(from actors)
order
(from ordering)
customer care click to dial

(from click to dial)
(from actors)
Communication: The communication relationship of an actor in a use case s

shown by connecting the actor symbol to the use case symbol with a solid
path. The actor is said to communicate with the use case.
Uses: A uses relationship between use cases is shown by a generalization

arrow from the use case.

Extends: The extends relationship is used when you have one use case that is
similar to another use case but does a bit more. In essence, it is like a
subclass.
6.Build a business process model using Activity diagram
An activity diagram is a variation or special case of a state machine, in

which the states are activities representing the performance of operations and
the transitions are triggered by the completion of the operations. Unlike state
diagrams that focus on the events occurring to a single object as it responds to
messages, an activity diagram can be used to model an entire business
process. The purpose of an activity diagram is to provide a view of flows and
what is going on inside a use case or among several classes. However, activity
diagram can also used to represent a classs method implementation.
Activity diagrams express a decision when conditions are used to

indicate different possible transitions that depend on Boolean conditions of
container object. The figure provided for a decision is the traditional diamond
shape, with one or more
incoming arrows and two or more outgoing arrows, each labeled by a distinct
guard condition. All possible outcomes should appear on one of the outgoing
transitions.
You can attach activity diagrams to most model elements in the use case
or logical views. Activity diagrams cannot reside within the component view.
Naming
The name of an activity must be unique and should declare the activitys
purpose. All activity icons with the same name on an activity diagram
represent the same activity.
Activity Diagram Tools

You can use the following tools on the activity diagram toolbox to model
activity diagrams:

Activities
Decisions
End State
Object
Object Flow
Start State
States
Swim lanes
NewActivity
Synchronizations
Transitions
The activity icon appears as a rectangle with rounded ends with a name
(Take Order and Process Order) and a compartment for actions:
Activity:

It is an ongoing non atomic execution within a state machine.
Activities ultimately result in some action, which made up of executable

atomic computations.
Object:
An object has state, behavior, and identity. The structure
and behavior of similar objects are defined in their common class. Each object
in a diagram indicates some instance of a class. An object that is not named is
referred to as a class instance.
Object flow:
It is useful to see the relationships between an operation and the objects
that are its argument values or results. The input to and outputs from an
operation may be shown as an object flow state.
State:
Is a condition/situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event .
Transition:
Is a relationship b/w two states indicating that an object in the 1 st state

will perform certain actions and enter the 2nd state when a specified event
occurs and specified conditions are satisfied?
On such a change of state, the transition is said to fire.
End State:
An end state represents a final or terminal state on an
activity diagram or state chart diagram. Place an end state when
you want to explicitly show the end of a workflow on an activity diagram or the
end of a state chart diagram.
The end state icon is a filled circle inside a slightly larger unfilled circle
that may contain a name (End Process):

Start State:
A start state (also called an "initial state") explicitly shows the beginning
of a workflow on an activity diagram or the beginning of the execution of a state
machine on a state chart diagram. You can have only one start state for each
state machine because each workflow/execution of a state machine begins in
the same place. The start state icon is a small, filled circle that may contain a
name (Begin Process):
Swim lanes
Swim lanes are very similar to an object because they provide a way to
tell who is performing a certain role. Swim lanes only appear on activity
diagrams. You should place activities within swim lanes to determine which
unit is responsible for carrying out the specific activity.When a swim lane is
dragged onto an activity diagram, it becomes a swim lane view.
Synchronizations
Synchronizations enable you to see a simultaneous workflow in an

activity diagram or state chart diagram. Synchronizations visually define forks
and joins representing parallel workflow.
Forks and Joins

A fork construct is used to model a single flow of control that divides into
two or more separate, but simultaneous flows. Every fork that appears on an
activity diagram should ideally be accompanied by a corresponding join. A join
consists of two of more flows of control that unite into a single flow of control.
All model elements (such as activities and states) that appear between forks
and join must complete before the flow of controls can unite into one.

custopmer Customer care Credit card check system adminstrator
Registration
do/ enter user details

exit/ Login id
Login
[ No ]
entry/ enter user id and pwd
do/ verify user id and pwd
verify pwd
[ Yes ]
Searching books
do/ search books
validate order
do/ validate the customer
exit/ valid user
selecting books
do/ select books
Click to dial
entry/ requiring help

place order do/ give required details
exit/
entry/ books are selected
do/ select the payment option
confirm order
entry/ payment complete
do/ confirms order
book delivery
do/ deliver the book
7. Identification of Analysis classes
A class is a set of objects that share a common structure and common

behavior (the same attributes, operations, relationships and semantics). A
class is an abstraction of real-world items. When these items exist in the real
world, they are instances of the class and are referred to as objects.
The following four approaches are used for identifying classes:
The noun phrase approach.

The common class patterns approach.

Use Case driven approach.

Sequence/collaborators approach.
For our system we use noun phrase approach for identifying classes.
USE CASE DRIVEN APPROACH
The use case driven approach is the third approach. Use cases are employed to
model the scenarios. The scenarios are described in text or through a sequence
of steps. Modeling with use cases is a recommended aid in finding the objects
of a system and s the technique used b the unified approach. Once the system
has been described in terms of its scenarios, the modeler can examine the
textual description or steps of each scenario to determine what objects are
needed for the scenario to occur.
CLASSES, RESPONSIBILITIES, AND COLLABORATORS
Classes, Responsibilities, and Collaborators are a technique used for

identifying classes responsibilities and Collaborators and therefore their
attributes and methods. By identifying an objects responsibilities and
collaborators you can identify its attributes and methods.
The classes, Responsibilities, and Collaborators process consists of three steps
Identify classes responsibilities.

Assign responsibilities
Identify collaborators.
In our example we consider the noun phrase approach.
Initial list of nouns Phrases:
The initials study of the use cases of the scheduling tool produces the
following phrases: The classes identified in our system are
Books
Credit card
Demand draft
User Id

Password
Cart
Invalid Password
Valid password
Registration
Credit Card Validation
Invalid credit card
Price
Discount
Total Amount
Customer
Administrator
Order
Help
Customer Care
Publishers
Payment
Payment Mode
Approval Process
Amount
Authors
Book name
Transaction idIRRELAVENT CLASSES:
Registration
Books

Credit card
Demand draft
User Id
Password
Cart
Invalid Password
Valid password
Customer
Administrator
Order
Help
Customer Care
Publishers
Payment
Payment Mode
Approval Process
Amount
Authors
Book name
Valid Password
Credit Card System
Click to Dial
System
Credit Card Validation
Invalid credit card

Price
Discount
Total Amount
Transaction id
Reviewing the redundant classes and building a common vocabulary:
Password, valid password = user password
Payment, payment mode = payment mode
Help, customer care = customer care
Price, amount = price
User id, valid id = user id
Book, book name = book
8. Identify the responsibilities of Classes
Classes, responsibilities, and collaborators is a technique used for

identifying classes, Responsibilities, and Collaborators can help us identify
classes. Classes, Responsibilities, and Collaborators is based on the idea that
an object either can accomplish a certain responsibility itself or it may require
the assistance of other objects.. If it requires the assistance of other objects, it
must collaborate with those objects to fulfill its responsibility.
The Classes, Responsibilities, and Collaborators process consists of three steps
Identify classes responsibilities.

Assign responsibilities.
Identify collaborators.

Class name Responsibilities
Administrator Authentication gives to customer
Customer Buying books
Bookshop staff To provide info for customer
Order Needed by customer to select
Registration Maintain customer logins
Transaction sends books to customers
9.Construction of Use case realizations
Realization:
Collaboration realizes an operation or a use case. It describes the context
in which the implementation of an operation or a use case executes- that is,
the arrangement of objects and links that exists when the execution begins,
and the instances that are created are destroyed during execution. The
behavior sequences may be specified in interactions, shown as sequence
diagrams or collaboration diagrams.
Collaboration may also realize the implementation of a class.
Collaboration for a class is the union of the collaborations for its operations..
Realization is displayed as dashed arrows with a closed hallow arrow head.
In our system we identify the following realizations.
registration registration
(from registration)
select books select books


login login
(from loging in)
search books search books

(from searchi ng books)
order order
(from ordering)
click to dial click to dial

(from cli ck to dial)
10. Construction of Sequence diagrams
A sequence diagram is a graphical view of a scenario that shows object

interaction in a time-based sequence-what happens first, what happens next..
The lifeline represents the objects existence during the interaction. This form
was popularized by Jacobson. An object is shown as a box at the top of a
dashed vertical line.
The sequence diagram is very simple and has immediate visual appeal---
this is its great strength. A sequence diagram is an alternative way to
understand the overall flow of control of a program.
The following tools located on the sequence diagram toolbox which

enable to model sequence diagram:
Object: An object has state, behavior and identity. The structure and
behavior of similar objects are defined in their common class. Each object in a

diagram indicates some instance of a class. An object that is not named is

referred to as a class instance.
Message Icons: A message icon represents the communication between
objects indicating that an action will follow. The message icon is horizontal,
solid arrow connecting two-life line together.
Focus of Control: Focus of control (FOC) is an advanced notational
technique that enhances sequence diagram. It shows the period of time during
which an object is performing an action, either directly or through an
underlying procedure.
Message to Self: A message to self is a tool that sends a message from one
object back to the same object. The sender of a message is the same as the
receiver.
Note: A note captures the assumptions and decisions applied during
analysis and design. Notes may contain any information, including plain text,
fragments of code, or references to other documents.
Note Anchor: A note anchor connects a note to the element that it affects.
Sequence diagrams
Sequence diagram for login:
: login
:
:customer administrator
1: enter the id pwd
2: verifies id and pwd
3: id pwd OK
4: Display book shop page

Sequence diagram for Registration:
: : registration : login
: customer
administrator
1: requests for registration
2: requests for registration form
3: provide reg. form
4: fills the form
5: enter the fiiled up registration form
6: requests for confirmation of registration form
7: confirms the form
8: create new profile
9: Registration acknowledged
10: submit user information
Sequence diagram for selecting books:

Sequence diagram for Ordering:

Sequence diagram for Click to dial:
: customer
: customer
care
1: dial the customercare
2: enter details
3: authenticate the customer
4: asks a query
5: provides solution to the queries
6: asks for customer satisfaction
7: confirms user satisfaction

11. Construction of Collaboration Diagram
Collaboration diagram is an interaction diagram that shows the

order of messages that implement an operation or transaction. Another type of
interaction diagram is the collaboration diagram. A collaboration diagram is
a set of objects related in a particular context, and interaction, which is a set of
messages exchanged among the objects within collaboration to achieve a
desired outcome.
Two types of Numbering Sequences are:
1. Flat Sequence
2. Decimal Sequence
The disadvantage of interaction diagrams is that they are great only for
representing a single sequential process; they begin to break down when you
want to represent conditional looping behavior. However, conditional behavior
can be represented n sequence or collaboration diagrams for each scenario.
The main guideline in developing interaction diagrams is simplicity.

The interaction diagram uses its clarity with more complex conditional
behavior. An interaction basically is used to examine the behavior of objects
within a single use case. It is good at showing collaboration among the
objects but not so good at precise definition of the behavior
Collaboration diagram for login

: customer
1: enter the id pwd
4: Display book shop page
: login : administrator
2: verifies id and pwd
3: id pwd OK
Collaboration diagram for Registration
4: fills the form 8: create new profile
5: enter the fiiled up registration form

7: confirms the form
: registration
3: provide reg. form

: customer 6: requests for confirmation of registration form
9: Registration acknowledged
2: requests for registration form

1: requests for registration 10: submit user information
: login
: administrator
Collaboration diagram for Searching books

select :
transaction
8: goes for selection 6: searches for the book'
1: enter the user id n pwd

4: selects a search option
5: enter the details
: customer search :
transaction
2: id pwd OK
3: gives the search options
7: confirms the availability of the book
Collaboration diagram for Click to dial
1: dial the customercare

2: enter details
4: asks a query
7: confirms user satisfaction
: customer care
3: authenticate the customer

: customer 5: provides solution to the queries
6: asks for customer satisfaction
Collaboration diagram for selecting books

7: places books in the cart
6: confirms selection
: customer select :
transaction
5: requests for the confirmation of selection
2: id and pwd OK
4: selects the book 8: go for ordering the books
1: enter id and pwd

3: searches the books
: order
search :
transaction
Collaboration diagram for Ordering
: customer
2: requests for the number of copies

7: asks for payment details
10: confirms the validity of the credit
11: gives the transaction id
6: gives the total amount 12: Confirms order
5: calculates total amount 9: Validates payment

1: requests for order
3: enter the number of copies
8: provides payment details
: administrator : order
4: gives no of copies
Difference
between sequence and collaboration:
Sequence diagram show time based object interaction while collaboration

diagram shows how objects associate with each other.

Sequence diagrams are easier to read.

Collaboration diagrams use the layout to indicate how objects are
statically connected.
The create collaboration diagram command creates a collaboration

diagram from information contained in the sequence diagram. The create
sequence diagram command creates a sequence diagram from information
contained in the interaction collaboration diagram.
12. Identification of attributes of classes
Attribute:
An attribute is the description of a named slot of a specified type in class;

each object of a class separately holds a value of the type.
Guidelines for identifying attributes of classes are as follows:
Attributes usually correspond to nouns followed by prepositional phrases.

Attributes also may correspond to adjectives or adverbs.
Keep the class simple; state only enough attributes or adverbs.
Attributes are less likely to be fully described to define the object state.
Omit derived attributes.
Do not carry discovery attributes to excess.
The following questions help in identifying the responsibilities of classes and

deciding what data elements to keep track
What information about an object should we keep track of?

What services must a class provide?
For our system the attributes for each class are as follows:
Customer: Bookshop staff: Order:

Name: string phone number: integer amount: currency

User id: string location: string payment mode: integer

Password: string no of copies: integerUser account: integer
14. Analyzing the object behavior by constructing UML state chart diagram
State chart diagrams model the dynamic behavior of individual classes or

any other kind of object. They show the sequences of states that an object goes
through, the events that cause a transition from one state to another and the
actions that result from a state change.
registration login
do/ creates a user profile do/ enter user id and pwd
do/ provides user id and pwd
entry/ open home page
search
entry/ valid user
do/ provide book list
order
select
do/ provides payment options
do/ verifies the credit do/ place selected books in cart
do/ provides transaction id
click to dial Delivery

do/ answer queries
14. Construction of UML static Class diagram

The UML class diagram, also referred to as object modeling, is the main
static analysis diagram. These diagrams show the static structure of the model.
A class diagram a collection of static modeling elements, such as classes and
their relationships, connected as graph to each other and to their contents.
Class diagram do not show temporal information, which is required in dynamic
modeling.
Shows a set of classes, interfaces and collaborations and their

relationships.
Class diagrams address the static design view of a system.

Class diagrams that include active classes address the static process view of a
system.
registration
create new profine()

submit user information()
1
1
administrator login
1 (from analysis model)
user id
name
1 password
adm id 1 1
validates the id and pwd()
1 customer
1
(from analysis model) 1
1 name
user id
password
user account
searches books()
selectis books() n
order 1
(from analysis model) orders books() customer care
contacts the customer care() 1 (from analysis model)
amount 0..n
payment mode 1 phone number
no of copies location
generate bills() solves queries()
1..n
transaction
transaction type
amount
transaction id
transaction date n time
A class diagram is a picture for describing generic descriptions of

possible systems. Class diagrams and collaboration diagrams are alternate

representations of object models. Class diagrams contain classes and object

diagrams contain objects, but it is possible to mix classes and objects when
dealing with various kinds of metadata, so the separation is not rigid.
Attribute: An attribute is the description of a named slot of a specified type in

class; each object of a class separately holds a value of the type.
Method: The implementation of an operation. It specifies the algorithm or

procedure that produces the results of an operation.
Relationship: The relationship among objects is based on the assumptions
each makes about other objects, including what operations can be performed
and what behavior results. Three types of relationships among objects are
Association
Generalization
Aggregation
15. An overall refined class diagram:

registration
create new profine()

submit user information()
1
1
administrator login
1 (from analysis model)
user id : string
name : string
1 1 password : string
adm id : string 1
validates the id and pwd()
1 customer
1
(from analysis model) 1
1 name : string
user id : string
password : string
user account : integer
searches books()
selectis books() n
order 1
(from analysis model) orders books() customer care
0..n contacts the customer care() 1 (from analysis model)
amount : currency
payment mode : string 1 phone number"integer
no of copies : integer location : string
generate bills() solves queries()
1..n
transaction
transaction type : string
amount : currency
transaction id : string
transaction date n time : date
16. Component Diagram:

registration
customer bookshop
staff
Components for Registration:
registrati customer booksho

on user p staff
Components for Customer:
Components for bookshop staff:
17. Deployment Diagram:

After studying the component packages defined for the problem, examining
existing hardware and estimating the load on the system during the online
bookshop, we decided that we will need four processors for the system-one to
handle customer registration, one for the database, and two for bookshop staff.
Regist Datab
ration ...
credit
books c...
hop
Class model for POS with responsibilities (using GRASP patterns)

controller pattern
VIVA QUESTIONS:-
1. Explain sequence diagrams?

Ans:- Sequence diagram shows interaction between objects over a specific
period time. The message flow is shown vertically in waterfall manner i.e. it
starts from the top and flows to the bottom. Dashed lines represent the
duration for which the object will be live. Horizontal rectangles on the dashed
lines represent activation of the object. Messages sent from an object is
represented by dark arrow and dark arrow head. Return message are
represented by dotted arrow.
2. What are Relationships?

There are different kinds of relationships:
Dependencies: Dependencies are relations ships between two entities that

that a change in specification of one thing may affect another thing. Most
commonly it is used to show that one class uses another class as an
argument in the signature of the operation.
Generalization: Generalization is relationships specified in the class
subclass scenario, it is shown when one entity inherits from other.
Association: Associations are structural relationships i.e. a room has

walls, Person works for a company.
Aggregation: Aggregation is the typical whole/part relationship. This is

exactly the same as an association with the exception that instances
cannot have cyclic aggregation relationships (i.e. a part cannot contain its
whole).
Composition: Composition is exactly like Aggregation except that the

lifetime of the 'part' is controlled by the 'whole'. This control may be direct

or transitive. That is, the 'whole' may take direct responsibility for creating
or destroying the 'part', or it may accept an already created part, and later
pass it on to some other whole that assumes responsibility for it.
3. What is a design pattern?

Ans:- A design pattern is a proven design solution to a common problem faced
by software developers.
Properties of design patterns are
Encapsulated
object-oriented
reusable
EXPERIMENT 3: CUSTOMER SUPPORT SYSTEM
1. Problem statement
E-seva is the online payments. In the e-seva there are many types of
online bill payments (electric bill, phone bill etc).and there is an online ticket
reservation system. The electronic bill presentment & payment application
(EBPP) is a web based application which helps billers and their customers
settle their transitions online.
Briefly speaking billers and issue bills (e-bill) Online and send them to
their customers electronically. The users can select to view and pay their e-bills
in multiple languages. The system will also keep tractions history between
billers and customers. EBPP system should be reasonably accessible to
potential user. And online ticket reservation system. Railways wishes to
develop a ticketing and reservation system .this must support advance booking
of the tickets, cancellation of tickets and change of class of a ticket. The system
will also have a web interface where their user can register themselves and
purchase ticket online... The system will also have a querying facility that
allows user to check train time tables, Fares and availability of tickets.
2. IDENTIFICATION OF ACTORS
Actors represent system users. They help delimit the system and give a clear
picture of what the system should do. It is important to note that an actor
interacts with, but has no control over the use cases.
An actor is someone or something that:

1. Interacts with or uses the system
2. Provides input to & receive information from the system
3. Is external to the system and has no control over the use cases
An actor can be represented as shown below:
Actor diagrams
customer operator dba
(from Actors) (from Actors) (from Actors)
The following question should be answered to identify actors:
1. Who is interested in a certain requirement?
2. Where in the organization the system is used?
3. Who will benefit from the use of the system?
4. Who will supply the system with the information, use this information and
remove this information?
5. Who will support and maintain the system?
6. Does the system use the external resource?
7. Does one person play several different roles?
8. Do several people play same role?
9. Does the system interact with the legacy system?
Actors identified are:
Actors:
Customer: The person who utilizes the services provided by this application.
Operator: The person who interacts with the computer. He receives the payments
from the customers and gives receipts to them.
DBA: The person who maintains the data-base.

3. IDENTIFICATION OF USECASES AND SUB USE CASES:
In its simplest form a use case can be described as a specific way of using
the system from a users perspective.
A more detailed description might characterize a use case as:
A pattern of behavior the system exhibits

A sequence of related transactions performed by an actor and the system
Delivering something of value to the actor.
Use case provides a mean to:
1. Capture system requirements
2. Communicate with the end users and domain experts
3. Test the system
Use cases are the best discovered by examining the actors and defining
what the actor will be able to do with the system. Since all needs of a system
typically cannot be covered in one use case, it is usual to have a collection of
use cases. Together this use case collection specifies all ways of using the
system.
UML notation for the use case:
1. An ellipse containing the name of the use case inside it.
Login
Error: Reference source not found
2. An ellipse containing the name of the use case below it
NewUseCase
The following questions are to be answered to identify the use cases:

1. What are the tasks of each actor?
2. Will any actor create, store, change, remove, or read information in the
system?
3. What use cases will store, change, remove or read this information?
4. Will any actor need to inform the system abiut sudden external changes?
5. Does any actor need to perform about certain occurances in the system?
6. What use cases will support and maintain the system?
7. Can all functional requirements be performed by the use cases?
Use cases identified are:
Pay bills: This application is used for paying the bills like electricity bill,
house tax etc.
Booking movie tickets: we can purchase the movie tickets by using this
application.
Providing applications: It is used for getting the application forms.
Issuing certificates: One can take the birth and death certificates by using
this application.
APSRTC reservations: one can reserve the bus tickets.
Licenses: issuing trade licenses and vehicle licenses.
Login: allowing the operator to access the data-base.
Maintaining database: the purpose is to maintain the database consistently.
Flow of events in our system is.
Use-Case Specification: paying bills
1. Paying bills
This use-case allows a customer to pay the bills viz. Electricity bill,
telephone bill etc .The customer should provide the respective bill to the
operator. He will enter the details needed for this transaction. Finally the
receipt will be issued to the customer by the operator.
2. Flow of events
This use-case begins when the customer opts to pay bills.

1. The customer enquiries the receptionist about the counter for paying
bills.
2. He provides the bill or bill number to the operator.
3. The operator checks for the amount that customer has to pay.
The customer pays the amount to the operator and he enters it in respective
column.
The operator gives the receipt to the client.
3. Special requirements- None
4. Pre-condition-The customer should know the bill number, amount to be paid

for the bill
5. Post-condition- The database is updated accordingly after the transaction.
6. Extension points - None
4. Flow of Events
Registering Biller
The Unregistered User chooses the appropriate link to bring him to the Biller
Registration page.
The Unregistered User is then given fields in which to fill in the appropriate
Biller information.
When the Unregistered User submits his information, the system verifies the
correctness of the information.
Registering Customer
The Unregistered User chooses the appropriate link to bring him to the
Customer Registration page.
The Unregistered User is then given fields in which to fill in the appropriate
Customer information.

When the Unregistered User submits his information, the system verifies the
correctness of the information.
Alternative Flows
<Valid Biller /Customer Information>
If the information is correct, the system will then interact with the MySQL
database to create the account. If the MySQL database interaction is
successful, the user is then notified of the successful creation of his account. If
the MySQL database interaction is not successful, an error message is sent to
the Administrator and the user is notified of this error and asked to retry again
later.
<Invalid Biller/Customer Information>
If the information is incorrect, the system returns the Unregistered User to the
Biller Registration page and notifies him of the error. The user can then re-
enter his information, or exit the system.
Preconditions
User is not logged in.
Post conditions
User is registered and logged in.
5. Construction of Use case diagrams
Use case diagrams depict system behavior(use cases).These diagrams present a

high level view of how the system is used as viewed from an outsiders
(actors)perspective. A use case diagram may depict all or some of the use cases
of a system.
A use-case diagram can contain:
Actors (things outside the system)
Use case (system boundaries identifying what the system should do)
Interactions or relationships between actors and use case in the system

including the Associations, dependencies, and generalizations.

Extends association
A extends association is a stereo typed association that specifies how the

functionality of one use case can be inserted in to the functionality of another
use case. Extend relationships between use cases are modeled as dependency
by using the extend stereotype.
Includes association
An include association is a stereo typed association that connects a base use

case to an inclusion use case.

telephone bill
house tax
water tax
electricity bill
login maintaining
pay bills
(from use ca...
database
(from use ca... (from use ca...
movie tickets
(from use ca...
consume
operator
r dba
(from actors)
...) (from actors)
...)
bus reservations (from actors)
...)
birth
death (from use ca...
certificates
competetive
passport
(from use ca...
exams
applications
(from use ca...
trade license vehicle license

licences
(from use ca...

REGISTER USE CASE DIAGRAM
Regester Biller <<include>>
UnRegester user Verify Information
<<include>>
Regester Customer
Biller Payment Engine

Customer MySql
ISSUE BILL USE CASE DIAGRAM

<<include>>
Issue Bill Enter e-bill
information
Biller
<<include>>
Update Trancation
MySql
<<include>>
Verify Customer
information
cancel Issue
e-bill screen
Pay Bill Use Case Diagram
Cancel Pay bill

Action
Customer Payment Information

Valdiation
Payment engine
<<include>>
Enter Payment
Information
UpDate Trancation
Information
6 Activity diagram

The following tools are used on the activity diagram toolbox to model
activity diagrams.
Decisions: A decision represents a specific location on activity diagram

when the workflow may branch based upon guard conditions.
Synchronization: Synchronizations visually define forks and joins
representing parallel workflow.
Forks and Joins: A fork construct is used to model single flows. A join
consists of two or more flows of control that unite into a single flow of
control.
States: A state represents a condition or situation during the life of an
object during which it satisfies some condition or waits for some event.
Transitions: A state transition indicates that an object in the source state
will perform certain specified actions and enter the destination state
when a specified event occurs or when certain conditions are satisfied.
Start States: A start state (also called an initial state) explicitly shows
the beginning of a workflow.
End States: An end state represents a final or terminal state.
SwimLane: A unique diagram feature that defines who or what is
responsible for carrying out activity or state.
Work Flow: Each activity represents the performance of a group of
actions in a workflow.
Activity Diagram:

login
password not accepted
password accepted
select type of service
from menu
service selected
service not selected

more services
perform the
service
no more services
exit from the
service menu
Activity Diagram:-

IDENTIFY THE RESPONSIBILITIES OF CLASSES:

This technique is used to identify the classes, responsibilities and
therefore their attributes and methods. It is based on the idea that an object
can either accomplish a certain responsibility by itself or it may require the
assistance of other objects in which case it collaborates.
Out of these, the noun phrase is used to identify the classes to increase
our understanding of the subject.
1. The initial list of noun phrases :( Candidate classes-may be)
Bills
Movie tickets
Application forms
Certificates
Log-in id
Password
Operator
Customer
Client
Database
Transaction
Bill number
Receipt
APSRTC Reservations
Licenses
System
Computer
Reservations

Amount
Vehicle number
Dba
Bus number
Seat number
Telephone number
APSRTC
Service charge
Tax
Vehicle
Bus
Movie
Dialog box
Box
Time
Information
Number
Money
Fare
Place
Birth date
Death date
Date
2. Reviewing the irrelevant classes

It is safe to eliminate the irrelevant classes. The candidate classes must be
selected from relevant classes and fuzzy classes.

The following irrelevant classes can be eliminated:
Bills
Movie tickets
Application forms
Certificates
Log-in id
Password
Operator
Customer
Client
Database
Transaction
Bill number
Receipt
APSRTC Reservations
Licenses
Reservations
Amount
Vehicle number
Dba
Bus number
Seat number
Telephone number
APSRTC
Service charge

Tax
Vehicle
Bus
Movie
Dialog box
Box
Time
Information
Number
Money
Fare
Birth date
Death date
Date
3. Reviewing the redundant classes and building a common vocabulary
Here the several classes appear more than once. Hence we eliminate the
redundant classes
Money, Amount, fare =Amount
Customer, Client =Customer
APSRTC Reservations, APSRTC, Reservations =APSRTC Reservations
Date, Birth date, death date =Date
Tickets, Movie tickets =Movie tickets
Here is the revised list of candidate classes.
Bills

Movie tickets
Application forms
Certificates
Log-in id
Password
Operator
Customer
Client
Database
Transaction
Bill number
Receipt
APSRTC Reservations
Licenses
Reservations
Amount
Vehicle number
Dba
Bus number
Seat number
Telephone number
APSRTC
Service charge
Tax
Vehicle
Bus
Movie

Dialog box
Box
Time
Information
Number
Money
Fare
Place
Birth date
Death date
Date
4. Reviewing the classes containing adjectives:
In this system we have no classes containing adjectives that we ca eliminate.
5. Reviewing the possible attributes

The noun phrases used only as values should be restated as attribute classes.
The following are attribute classes:
Bill Number: A value, not a class.

Bus number: A value, not a class.
Telephone Number: A value, not a class.
Vehicle Number: A value, not a class.
Amount: Some amount of money, not a class.
Pass word: An attribute.
Log-in id: An attribute.
Service charge: An amount of money, not a class.
Seat number: A value, not a class.
Date: An attribute, not a class.
Here is the revised list of candidate classes. Notice that the eliminated classes
are strikeouts.
Bills
Movie tickets
Application forms
Certificates

Log-in id
Password
Operator
Customer
Client
Database
Transaction
Bill number
Receipt
APSRTC Reservations
Licenses
Reservations
Amount
Vehicle number
Dba
Bus number
Seat number
Telephone number
APSRTC
Service charge
Vehicle
Bus
Movie
Dialog box
Box

Time
Information
Number
Money
Fare
Place
Birth date
Death date
Date
6. The Final List of Classes is:
Operator
Customer
Application
Bill
Certificate
License
Reservation
Movie tickets
8. IDENTIFY THE RESPONSIBILITIES OF CLASSES
CRC developed by Cunningham, Wilkerson, and Beck. Classes

Responsibilities and Collaborators is a technique used for identifying classes
responsibilities and their attributes and methods. They also help in identifying
the classes. Classes Responsibilities and Collaborators is based on the idea
that an object either can accomplish a certain responsibility itself or it may
require the assistance of other objects.
The Classes, Responsibilities, and Collaborators process consists of three

steps:
CLASSES RESPONSIBILITIES

Operator Interacts with the system and updates the data.

Customer Provides the details to the operator to perform the Service.
Application Specifies the type of the application.
Bill Specifies the bill number and the amount to be paid.
Certificate Indicates the type of the required certificate.
License Gives the vehicle number and particular details
Bus
Reservations Reserves the bus tickets by giving the details to the operator
Movie Tickets Reserves the movie tickets by giving the details
1. Identify classes responsibilities(and identify classes)

2. Assign responsibilities
3. Identify collaborators
9. CONSTRUCTION OF USECASE REALIZATIONS

A use case realization is a graphic sequence of events, also referred to as
a scenario or an instance of a use case. These realizations or scenarios are
depicted in either a sequence or collaboration diagrams.
Figures:
application applications
(from Usecases)
certificates certificates
(from Usecases)

licenses licenses
(from Usecases)
login login
(from Usecases)
maintain database maintaining database

(from Usecases)
movie tickets movie tickets

(from Usecases)
10. CONSTRUCTION OF SEQUENCE DIAGRAM
Register Diagram (Valid Biller/Customer Information)

Register Diagram (Invalid Biller/Customer Information)

Issue Bill Sequence Diagram
Pay Bill Sequence Diagram

View Account Information Diagram ( Biller)

Update Account Information Diagram Alternate Flow (Biller)


View Account Information Diagram (customer)

Update User Account Information Diagram (Administrator)


SEQUENCE DIAGRAM FOR TICKETING:
system
: consumer : operator
1: requests for a ticket
2: specifies the details
3: enters the bus no.,date ,time
4: not available
5: the ticket is not available
6: valid
7: requests the amount
8: takes the amount
9: enquires the name
10: enters the name
11: issues the ticket
12: receivces the ticket

11. COLLABORATION DIAGRAM
: consumer
1: requests for a ticket

2: specifies the details
8: takes the amount
5: the ticket is not available

7: requests the amount
9: enquires the name
12: receivces the ticket
4: not available
6: valid
11: issues the ticket : operator
3: enters the bus no.,date ,time

10: enters the name
system
12. STATE CHART DIAGRAM

idle state
login
per form
transaction
error in transaction maintena

nce
transaction successful
update
transaction
log out
13. CLASS DIAGRAM

Class Diagram of the E-seva services:


16. REFINE ATTRIBUTES, METHODS AND RELATION -SHIPS
Refining attributes for the customer class:
#cname: string
#servicetype: string
Refining attributes for the operator class:
#id: string
#password: string
Refining attributes for the Bill class:
#billno: string
#amount: float
#fine: string
#date: Date
Refining attributes for the Licenses class:
#vehicleno: string
#sercharge: string
#cname: string
Refining attributes for the certificate class:
#name: string
#fname: string
#mname: string
#place: string

#date: Date
Refining attributes for the Application class:
#type: string
#sercharge: number
Refining attributes for the reservation class:
#busno: string
#seatno: string
#source: string
#destination: string
Refining attributes for the movie ticket class:
#seatno: string
#sercharge: number
#show: number
#tname: name
The following operation presentation suggested by UML
Refining methods for the customer class:
+provide data ()
#receive receipt ()
Refining methods for the operator class:
+login ()
#update ()

Refining methods for the Bill class:
+paybill ()
#receipt ()
Refining methods for the Licenses class:
+getdetails ()
+provide licenses ()
Refining methods for the certificate class:
+get details ()
# receipt ()
Refining methods for the Application class:
+provide applications ()
Refining methods for the reservation class:
+get data ()
+restickets ()
+get ticket ()
Refining methods for the movie ticket class:
+get details ()
+book movie tickets ()
17. AN OVERALL REFINED CLASS DIAGRAM

customer
cname:string
servicetype:string
certificate
provide data()
receive receipt() licence
name:string (from Use Case View)
fname:string 1,n vehicleno:string
mname:string
sercharge:number
place:string interacts cname:string
date:string
1,n
... get details()
get details() OPERATOR ...
provide licenses()
receipt() (from Use Case View)
1,n id:string 1,n
issues issues
password:string
1 1
reservation
bill login() (from Use Case View)
(from Use Case View) update() busno:string
billno:string 1 seatno:striing
amount:string give out reserve source:string
fine:string destination:string
date:Date 1,n 1,n
get data()
pay bill() resticket()
reciept() get ticket()
movie ticket
application
seatno:string (from Use Case View)
sercharge:string reserve provide type:string
show:string
1,n sercharge:number
tname:string 1,n
provide app()
get details()
bookmovietickets()
18. THE COMPONENT DIAGRAM
Component diagrams are created to show components that are the physical
implementation of the system. The component diagram shows the organization
and dependencies among a set of components of the system. The UML notation
for a component is as shown below:
Component
NRI Institute of Technology Name Department of CSE

Fig: UML notation for a Component
The Component diagram of E-Voting system is as follows:
Login Database Reservation

ticket
Customer Maintain
Bills Data base
19. THE DEPOLYMENT DIAGRAM

DATA BASE
ADMINISTRATOR(DBA)
Registration
Customer
BILL_PRINTING_
Login SYSTEM
Administrator

VIVA QUESTIONS:-
1. What are the components of state chart diagram?

Ans: there are 3 important components
Action: It triggers from one another

Event: triggers the action
Guard: it is the condition that says which action to be triggered
2. Explain collaboration diagram?

Ans: collaboration and sequence diagram are almost same but the difference is
to show in a different way.in collaboration we concentrate more on the
messages between the objects.
EXPERIMENT 5: ATM APPLICATION
Use case diagram for ATM machine

SystemStartup Cash Installation System Shut Down
SystemStatus
Operator/Teller
ChangePIN Login
BankComputer
Transaction
Customer
Withdrawal Depos it Transfer CheckBalance MiniStatement
<<include>> <<include>>
<<include>>
<<include>>
<<include>>
AccountType
Savings Current

Sequence diagrams for ATM
System Start Up:
operator : ATMcomputer :
bankcom puter :
ATM-Sys tem ATM-Sys tem
BankComputer
s witch-on
perform s tartup()
ins tall the cas h

get cas h installation
s et the cas h-ins tallation
cas h ins talled
System Shut Down:

bankcomputer :
ATM-System BankClient
BankComputer
save all the settings

saving performed
changes done
shut down the system

system is going to be turn off
save all the transactions
ok turn off the sys tem
system shutdown
turn off
Withdrawal:

bankclient : ATM : ATM-Sys tem

bankcomputer :
BankClient
BankCom puter
ins ert card
verify the card
card verified
verification succes sful

enter the PIN
PIN entered
verify the PIN
PIN verified
valid us er
enter the type of account
current/s avings
enter the type of trans action
check banace
checking bal
withdrawal
dis play and reciept out of current bal
enter the am ount to withdraw
am ount entered
perform withdrawal operation
Amount out
dis play the receipt out of current balance
Save changes
Card out

Deposit:

Transfer:
bankclient : ATM : ATM-System

bankcomputer :
BankClient
BankComputer
insert card
verify the card
card verified
verification successful
enter the PIN
PIN entered verify PIN

PIN verified
valid user
current/savings
enter the type of transaction
Transfer
enter the amount to transfer
Amount entered
Enter the details to transfer
Detailes entered
out the card
count and check the amount
save the changes
changes saved

CheckBalance:
bankclient : ATM : ATM-Sys tem

bankcomputer :
BankClient
BankComputer
ins ert the card
verify the card
card verified
verification s ucces s ful
enter the PIN
PIN entered
verify the PIN
PIN verified
valid user
current/s avings
check balance
checking balance
dis play and out the receipt of current balance
card out
MiniStatement:

bankclient : ATM : ATM-System

bankcomputer :
BankClient
BankCom puter
insert the card
verify the card
card verified
verification successful
enter the PIN
PIN entered
verify the PIN
PIN verified
valid user
current/savings
MiniStatem ent
Las t 15 transactions
last transactions details
display and out the receipt of las t 15 trans action details.
card out
Activity diagram for ATM

insert card
enter PIN
enter the type of

account
withdrawal deposit Transfer CheckBalance MiniStatement
checkBalance Enter the checkBalance

Amount
enter the amt to enter the am ount and invalid PIN

place the amount in
withdraw account no to transfer
cabin
get money
take receipt

Collaboration diagrams for ATM system are as follows
SystemStartup:
2: perform startup()
1: switch-on
3: install the cash
ATM-System ATM-System
6: cash installed
5: set the cash-installation 4: get cash installation
bankcomputer :
BankComputer
SystemShutDown:

2: saving performed
1: save all the settings

4: shut down the system
9: turn off
ATM-System BankClient
3: changes done
8: system shutdown
7: ok turn off the system 5: system is going to be turn off
6: save all the transactions
bankcomputer :
BankComputer
Withdrawal:

14: checking bal

19: perform withdrawal operation 1: insert card
6: PIN entered
11: current/savings
13: check banace
15: withdrawal
18: amount entered
ATM : ATM-System bankclient :
BankClient
5: enter the PIN
10: enter the type of account
12: enter the type of transaction
16: display and reciept out of current bal
17: enter the amount to withdraw
20: Amount out
21: display the receipt out of current balance
23: Card out
2: verify the card

4: verification successful 7: verify the PIN
9: valid user 22: Save changes
3: card verified
8: PIN verified
bankcomputer :
BankComputer

Deposit:
1: insert card 19: count and check the amount

6: PIN entered
11: current/savings
13: Deposit
15: Amount entered
17: envelope placed
bankclient : ATM :
BankClient ATM-System
5: enter the PIN
14: enter the amount to deposit
16: place the envelope
18: out the card
2: verify the card
7: verify PIN
4: verification successful 20: save the changes
9: valid user
21: changes saved
3: card verified
8: PIN verified
bankcomputer :
BankComputer

CheckBal:
14: checking balance
1: insert the card

6: PIN entered
11: current/savings
13: check balance
bankclient : ATM :
5: enter the PIN
15: display and out the receipt of current balance
16: card out
2: verify the card

4: verification successful 7: verify the PIN
9: valid user
3: card verified
8: PIN verified
bankcomputer :
BankComputer
Transfer:

1: insert card 19: count and check the amount

6: PIN entered
11: current/savings
13: Transfer
15: Amount entered
17: Detailes entered
bankclient : ATM :
5: enter the PIN
14: enter the amount to transfer
16: Enter the details to transfer
18: out the card
4: verification successful 2: verify the card

9: valid user 7: verify PIN
21: changes saved 20: save the changes
3: card verified
8: PIN verified
bankcomputer :
BankComputer
MiniStstement:
State chart diagram for ATM

Inserting Card not inserted

CARD
CARD read successful
Reading Invalid PIN

PIN
PIN read Successful
Choosing Transaction not selected

Trasaction
Customer wants to
another transaction transaction Choosen
Performing
transaction
Transaction Finished
Aborted due to
many PINs
Ejecting
CARD

Class diagram for ATM
BankSystem
BankClient
first name
last name ATM-System
PIN address
card number state
Address interface
check password()
1
associates with Account

+1..* Transactions
number
transaction ID
balance
transaction Date
+1..* 1
Account transaction transaction Time
withdrawal()
transaction Type
deposit()
amount
transfer()
balance
checkbal()
ministatement()
CurrentAccount SavingsAccount

Component Diagram:
BankCo
mputer
Client ATM-Syst
em
Account Transacti
on
CurrentAc Savings
count Account
Deplaoyment Diagram

BankComputer
ATM-System Account Transaction

<<include>>
<<extends>> <<extends>>
Client CurrentAccount SavingsAccount

Uml Lab Material

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Uml Lab Material

Încărcat de

Drepturi de autor:

Formate disponibile

Experiment 1:Familiarization of Rational Rose Environment

Objective and Background

The purpose of this UML lab is to familiarize programmers with

WEB SITE REFERENCES

Professor Lins Web site:http://www.etcs.ipfw.edu/~lin

a. Tour of Rational RoseEnvironment

Documentation Toolbox Diagram

b) Creating a simple application(Hello.java)

Step 1: Run Rational Rose

Step 3: Create Hello Class Diagram (classes, attributes, and operations)

1. Click on UseLogical View >Main

1. Create a new class calledHello

2. Add Attributes to the Helloclass

- Right click the Hello class again to select OpenSpecification

3. Add Operations to the Helloclass

4. Change Operation Specification for Hellomethod

Step 4. Create the Test Class Diagram

1.Select Class icon from theToolbox

The following codes in Hello.java and Test.java are generated

//Source file: C:\\My Documents\\Hello.java

//Source file: C:\\My Documents\\Test.java

Select two classes Test and Hello.

Step 7. Java Code Editing

public String getName()

//Source file: E:\\lwinmoe\\lab1\\Test.java

1. To compile Hello.java and Test.java from command

1. Name some tools for UML?

Free UML tools:

Ans: UML stands for Unified Modeling Language and it is a graphical

3. What are the various UML modeling diagrams?

Ans: UML Modeling diagrams can be classified in two categories:

Use Case view - This view exposes the requirements of a system.

Process View - modeling the distribution of the systems processes and

Implementation view - addressing the physical implementation of the

Deployment view - focus on the modeling the components required for

NRI Institute of Technology Department of CSE

EXPERIMENT 2:LIBRARY MANAGEMENT SYSTEM

Librarians should be able to use this system to keep track of all

NRI Institute of Technology Department of CSE

Questions to identify Actors:

1. Who is interested in a certain requirements?

2. Where in the organization is the system used?

3. Who will benefit from the use of the system?

5. Who will support and maintain the system?

6. Does the system use an external resource?

7. Does one play several different roles?

8. Does several people play the same role?

9. Does the system interact with the legacy system?

Actors Identified in Library Management System:

Librarian Member Supplier

3.Identification of Use cases and Sub use cases:

NRI Institute of Technology Department of CSE

Questions to Identify Use cases:

1. What are the tasks of each actor?

Use cases Identified in Library Management System:

NRI Institute of Technology Department of CSE

This use case allows the member to return books.

Inter Library Loan

Check Library Card

This use case allows the member to do research.

NRI Institute of Technology Department of CSE

This use case allows the supplier to purchase books.

Read Books, Newspapers

4. Construction of use case Diagram: