Unified Modeling Language (UML) Lab Manual: Class/Branch Iii B.Tech, Ii-Sem It ACADEMIC YEAR: 2009-10

.
Unified Modeling Language

[UML]
Lab Manual
Class/Branch: III B.TECH, II-SEM IT
ACADEMIC YEAR: 2009-10
PREPARED BY
Ch Krishna Priya B.Tech
DEPT.OF IT
PBR VITS-KAVALI
0
UNFIED MODELLING LANGUAGE LAB
The student is expected to take up about two mini- projects and model them and
produce Use Cases, Analysis Documents- both static & dynamic aspects, Sequence
Diagrams and State- Charts, Database design. A sample collection of Ideas is given.
Numerous other ideas can be found in the pages from the list of references given below.
SNO TITLE PAGE NO

1 Introduction to UML 2-16
2 A Point- of – Sale ( POS) System 17-22
3 Online Bookshop Example 23-29
4 A Simulated Company 30-41
5 A Multi- Threaded Airport Simulation 42-48
6 An Online Auction 49-58
7 A Content Management System 59-66
8 Bank Application 67-73
9 ATM Application 74-81
10 Railway Reservation System 82-88
11 : Unified Library Application 89-98
12 Inventory Control System 99-106
13 QUIZ Application 107-114
14 More diagrams for LIS 115-121
15 Pay Roll System 122-134
16 Course Registration System 135-148
STUDY OF UML
1
AIM:
General study of UML
DESCRIPTION:
The heart of object-oriented problem solving is the construction of a

model. The model abstracts the essential details of the underlying problem
from its usually complicated real world. Several modeling tools are
wrapped under the heading of the UML™, which stands for Unified
Modeling Language™. The purpose of this course is to present important
highlights of the UML.
At the center of the UML are its nine kinds of modeling diagrams, which
we describe here.
 Use case diagrams

 Class diagrams
 Object diagrams
 Sequence diagrams
 Collaboration diagrams
 Statechart diagrams
 Activity diagrams
 Component diagrams
 Deployment diagrams
Some of the sections of this course contain links to pages with more
detailed information. And every section has short questions. Use them to
test your understanding of the section topic.
Why is UML important?
Let's look at this question from the point of view of the construction
trade. Architects design buildings. Builders use the designs to create
buildings. The more complicated the building, the more critical the
communication between architect and builder. Blueprints are the
standard graphical language that both architects and builders must learn
as part of their trade.
Writing software is not unlike constructing a building. The more

complicated the underlying system, the more critical the communication
among everyone involved in creating and deploying the software. In the
past decade, the UML has emerged as the software blueprint language for
analysts, designers, and programmers alike. It is now part of the software
trade. The UML gives everyone from business analyst to designer to
programmer a common vocabulary to talk about software design.
2
The UML is applicable to object-oriented problem solving. Anyone
interested in learning UML must be familiar with the underlying tenet of
object-oriented problem solving -- it all begins with the construction of a
model. A model is an abstraction of the underlying problem. The domain
is the actual world from which the problem comes.Models consist of
objects that interact by sending each other messages. Think of an object
as "alive." Objects have things they know (attributes) and things they can
do (behaviors or operations). The values of an object's attributes
determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data)
and behaviors (methods or functions) into a single distinct entity. Objects
are instances of classes.
Use case diagrams
Use case diagrams describe what a system does from the

standpoint of an external observer. The emphasis is on what a system
does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an

example of what happens when someone interacts with the system. Here is
a scenario for a medical clinic.
"A patient calls the clinic to make an appointment for a yearly

checkup. The receptionist finds the nearest empty time slot in the
appointment book and schedules the appointment for that time slot.
"
A use case is a summary of scenarios for a single task or goal. An

actor is who or what initiates the events involved in that task. Actors are
simply roles that people or objects play. The picture below is a Make
Appointment use case for the medical clinic. The actor is a Patient. The
connection between actor and use case is a communication association
(or communication for short).
Actors are stick figures. Use cases are ovals. Communications are
lines that link actors to use cases.
3
A use case diagram is a collection of actors, use cases, and their
communications. We've put Make Appointment as part of a diagram with
four actors and four use cases. Notice that a single use case can have
multiple actors.
Use case diagrams are helpful in three areas.
 determining features (requirements). New use cases often

generate new requirements as the system is analyzed and the design
takes shape.
 communicating with clients. Their notational simplicity makes use
case diagrams a good way for developers to communicate with
clients.
 generating test cases. The collection of scenarios for a use case
may suggest a suite of test cases for those scenarios.
Class diagrams
A Class diagram gives an overview of a system by showing its

classes and the relationships among them. Class diagrams are static --
they display what interacts but not what happens when they do interact.
The class diagram below models a customer order from a retail

catalog. The central class is the Order. Associated with it are the
Customer making the purchase and the Payment. A Payment is one of
three kinds: Cash, Check, or Credit. The order contains OrderDetails
(line items), each with its associated Item.
4
UML class notation is a rectangle divided into three parts: class name,
attributes, and operations. Names of abstract classes, such as Payment,
are in italics. Relationships between classes are the connecting links.
Our class diagram has three kinds of relationships.
 association -- a relationship between instances of the two classes.

There is an association between two classes if an instance of one
class must know about the other in order to perform its work. In a
diagram, an association is a link connecting two classes.
 aggregation -- an association in which one class belongs to a
collection. An aggregation has a diamond end pointing to the part
containing the whole. In our diagram, Order has a collection of
OrderDetails.
 generalization -- an inheritance link indicating one class is a
superclass of the other. A generalization has a triangle pointing to
the superclass. Payment is a superclass of Cash, Check, and
Credit.
An association has two ends. An end may have a role name to clarify
the nature of the association. For example, an OrderDetail is a line item of
each Order.
A navigability arrow on an association shows which direction the

association can be traversed or queried. An OrderDetail can be queried
about its Item, but not the other way around. The arrow also lets you
know who "owns" the association's implementation; in this case,
5
OrderDetail has an Item. Associations with no navigability arrows are bi-
directional.
The multiplicity of an association end is the number of possible

instances of the class associated with a single instance of the other end.
Multiplicities are single numbers or ranges of numbers. In our example,
there can be only one Customer for each Order, but a Customer can have
any number of Orders.
This table gives the most common multiplicities.
Multiplicities Meaning
zero or one instance. The notation n . . m indicates n
0..1
to m instances.
0..* or * no limit on the number of instances (including none).
1 Exactly one instance
1..* at least one instance
Every class diagram has classes, associations, and multiplicities.

Navigability and roles are optional items placed in a diagram to provide
clarity.
Packages and object diagrams
To simplify complex class diagrams, you can group classes into

packages. A package is a collection of logically related UML elements. The
diagram below is a business model in which the classes are grouped into
packages.
6
Packages appear as rectangles with small tabs at the top. The
package name is on the tab or inside the rectangle. The dotted arrows are
dependencies. One package depends on another if changes in the other
could possibly force changes in the first.
Object diagrams show instances instead of classes. They are useful

for explaining small pieces with complicated relationships, especially
recursive relationships.
This small class diagram shows that a university Department can contain
lots of other Departments.
The object diagram below instantiates the class diagram, replacing it by a

concrete example.
Each rectangle in the object diagram corresponds to a single

instance. Instance names are underlined in UML diagrams. Class or
instance names may be omitted from object diagrams as long as the
diagram meaning is still clear.
Sequence diagrams
7
Class and object diagrams are static model views. Interaction
diagrams are dynamic. They describe how objects collaborate.
A sequence diagram is an interaction diagram that details how

operations are carried out -- what messages are sent and when. Sequence
diagrams are organized according to time. The time progresses as you go
down the page. The objects involved in the operation are listed from left to
right according to when they take part in the message sequence.
Below is a sequence diagram for making a hotel reservation. The

object initiating the sequence of messages is a Reservation window.
The Reservation window sends a makeReservation() message to a

HotelChain. The HotelChain then sends a makeReservation() message to a
Hotel. If the Hotel has available rooms, then it makes a Reservation and
a Confirmation.
Each vertical dotted line is a lifeline, representing the time that an

object exists. Each arrow is a message call. An arrow goes from the sender
to the top of the activation bar of the message on the receiver's lifeline.
The activation bar represents the duration of execution of the message.
In our diagram, the Hotel issues a self call to determine if a room is

available. If so, then the Hotel creates a Reservation and a
Confirmation. The asterisk on the self call means iteration (to make sure
8
there is available room for each day of the stay in the hotel). The
expression in square brackets, [ ], is a condition.
Collaboration diagrams
Collaboration diagrams are also interaction diagrams. They convey

the same information as sequence diagrams, but they focus on object roles
instead of the times that messages are sent. In a sequence diagram, object
roles are the vertices and messages are the connecting links.
The object-role rectangles are labeled with either class or object

names (or both). Class names are preceded by colons ( : ).
Each message in a collaboration diagram has a sequence number.

The top-level message is numbered 1. Messages at the same level (sent
during the same call) have the same decimal prefix but suffixes of 1, 2, etc.
according to when they occur.
Statechart diagrams
Objects have behaviors and state. The state of an object depends on

its current activity or condition. A statechart diagram shows the possible
states of the object and the transitions that cause a change in state.
Our example diagram models the login part of an online banking

system. Logging in consists of entering a valid social security number and
personal id number, then submitting the information for validation.
9
Logging in can be factored into four non-overlapping states: Getting
SSN, Getting PIN, Validating, and Rejecting. From each state comes a
complete set of transitions that determine the subsequent state.
States are rounded rectangles. Transitions are arrows from one state
to another. Events or conditions that trigger transitions are written beside
the arrows. Our diagram has two self-transition, one on Getting SSN and
another on Getting PIN.
The initial state (black circle) is a dummy to start the action. Final
states are also dummy states that terminate the action.
The action that occurs as a result of an event or condition is

expressed in the form /action. While in its Validating state, the object does
not wait for an outside event to trigger a transition. Instead, it performs an
activity. The result of that activity determines its subsequent state.
Activity diagrams
An activity diagram is essentially a fancy flowchart. Activity

diagrams and statechart diagrams are related. While a statechart diagram
focuses attention on an object undergoing a process (or on a process as an
object), an activity diagram focuses on the flow of activities involved in a
single process. The activity diagram shows the how those activities depend
on one another.
For our example, we used the following process.
10
"Withdraw money from a bank account through an ATM."
The three involved classes (people, etc.) of the activity are Customer,
ATM, and Bank. The process begins at the black start circle at the top and
ends at the concentric white/black stop circles at the bottom. The
activities are rounded rectangles.
Activity diagrams can be divided into object swimlanes that

determine which object is responsible for which activity. A single
transition comes out of each activity, connecting it to the next activity.
A transition may branch into two or more mutually exclusive

transitions. Guard expressions (inside [ ]) label the transitions coming out
11
of a branch. A branch and its subsequent merge marking the end of the
branch appear in the diagram as hollow diamonds.
A transition may fork into two or more parallel activities. The fork and the
subsequent join of the threads coming out of the fork appear in the
diagram as solid bars.
Component and deployment diagrams
A component is a code module. Component diagrams are physical

analogs of class diagram. Deployment diagrams show the physical
configurations of software and hardware.
The following deployment diagram shows the relationships among

software and hardware components involved in real estate transactions.
The physical hardware is made up of nodes. Each component

belongs on a node. Components are shown as rectangles with two tabs at
the upper left.
12
STEPS FOR MODELING UML DIAGRAMS
Modeling steps for Use case Diagram
1. Draw the lines around the system and actors lie outside the
system.
2. Identify the actors which are interacting with the system.
3. Separate the generalized and specialized actors.
4. Identify the functionality the way of interacting actors with
system and specify the behavior of actor.
5. Functionality or behavior of actors is considered as use cases.
6. Specify the generalized and specialized use cases.
7. Se the relatonship among the use cases and in between actor and
use cases.
8. Adorn with constraints and notes.
9. If necessary, use collaborations to realize use cases.
Moddeling steps for Sequence Diagrams
1. Set the context for the interactions, system, subsystem, classes,

object or use cases.
2. Set the stages for the interactions by identifying objects which
are placed asactions in interaction diagrams.
3. Lay them out along the X-axis by placing the important object
at the left side and others in the next susequent.
4. Set the lifelines for each and every object by sending create
and destory messages.
5. Start the message which is initiating interactions and place all
other messagesin the increasing order of items.
6. Specify the time and space constraints.
7. Set the pre and post conditiond.
Modeling steps for Collaboration Diagrams
1. Set the context for interaction, whether it is ystem, subsystem,

operation or class or one scenario of use case or collaboration.
2. Identify the objects that play a role in the interaction. Lay them
as vertices in graph, placing important objects in centre and
neigboring objects to outside.
3. Set the initial properties of each of these objects. If the attributes
or tagged values of an object changes in significant ways over the
interaction, place a duplicate object, update with these new values
and connect them by a message stereotyped as become or copy.
13
4. Specify the links among these objects.Lay the association links
first represent atructural connection.Lay out other links and adorn
with stereotypes.
5. Strating with the message that initiates this interaction, attach
each subsequent message to appropriate link, setting sequence
number as appropriate.
6. Adorn each message with time and space constraints if needed
7. Attach pre & post conditions to specify flow of control formally.
Modeling steps for Activity Diagrams
1. Select the object that have high level resposibilities.

2. These objects may be real or abstract. In either case, create a
swimlane for each important object.
3. Identify the precondition of iniitial state and post conditions of
final state.
4. Beginning at initial state, specify the activities and actions and
render them as activity states or action states.
5. For complicated actions, or for a set of actions that appear
multiple times,collapse these states and provide separate activity
diagram.
6. Render the transitions that connect these activities and action
states.
7. Start with sequential flows, consider branching, fork and joining.
8. Adorn with notes tagged values and so on.
Modelling steps for Statechart Diagram
1. Choose the context for state machine,whether it is a class,a

use case,or the system as a whole.
2. Choose the initial & final states of the objects.
3. Decide on the stable states of the object by considering the
conditions in which the object may exist for some identifiable period
of time.Start with the highlevel states of the objects & only then
consider its possible substates.
4. decide on the meaningful partial ordering of stable states over
the lifetime of the object.
5. Decide on the events that may trigger a transition from state
to state.Model these events as triggers to transitions that move from
one legal ordering of states to another.
6. Attach actions to these transitions and/or to these states.
7. Consider ways to simplify your machine by using
substates,branches,forks,joins and history states.
14
8. Check that all states are reachable under some combination
of events.
9. Check that no state is a dead from which no combination of
events will transition the object out of that state.
10. Trace through the state machine, either manually or by using
tools, to check it against expected sequence of events & their
responses.
Modeling steps for Class Diagrams
1. Identity the things that are interacting with class diagram.

2. Set the attributes and operations.
3. Set the responsibilities.
4. Identify the generalization and specification classes.
5. Set the relationship among all the things.
6. Adron with tagged values, constraints and notes.
Modeling steps for Object Diagrams
1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which are
collaborated with mechanisms.
3. Identify the relationship among all objects.
4. Walk through the scenario until to reach the certain point and
identify the objects at that point.
5. Render all these classes as objects in diagram.
6. Specify the links among all these objects.
7. Set the values of attributes and states of objects.
Modelling steps for Component Diagrams
1. Identify the component libraries and executable files which
are interacting with the system.
2. Represent this executables and libraries as components.
3. Show the relationships among all the components.
4. Identify the files,tables,documents which are unteracting with
the system.
5. Represent files,tables,documents as components.
6. Show the existing relationships among them generally
dependency.
7. Identify the seams in the model.
8. Identify the interfaces which are interacting with thw system.
9. Set attributes and operation signatures for interfaces.
10. Use either import or export relationship in b/w interfaces &
components.
11. Identify the source code which is interacting with the system.
15
12. Set the version of the source code as a constraint to each
source code.
13. Represent source code as components.
14. Show the relationships among components.
15. Adorn with nodes,constraints and tag values.
Modelling steps for Deployment Diagram
1. Identify the processors which represent client &

server.
2. Provide the visual cue via stereotype classes.
3. Group all the similar clients into one package.
4. Provide the links among clients & servers.
5. Provide the attributes & operations.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the
deployment diagram.
16
EXP NO :1 Point of Sale System
AIM: To create a Point of Sale System

ACTORS:
1. customer
2. cashier
USECASES:
1. Bar code scanning
2. Process sale
3. Close sale
4. Pay Bill.
5. Tax calculation
6. Buy product
7. Update Inventory
ALGORITHMIC PROCEDURE:
STEP 1: Start the application

STEP 2: Create the require actors and usecases in the browser window
STEP 3: Goto new usecase view and then click the usecase view and open a
new package
STEP 4: Rename the new package with the package with required names
STEP 5: Create two packages actor and usecase
17
Use Case Diagram :
Buy product
Barcode scanning
Pay bill
Customer
Cashier
Process sale
Close sale
Update Inventory
Tax calculation
18
POS system sequence diagram
Cashier POS System
1: process sale
2: enter item
3: scan item
4: total cost
5: close sale
6: total cost with tax
7: bill generation
8: generate reoprt
19
Process sale sequence diagram
Cashier POS System Codescanne Card reader Bank

r
1: Enter no of items
2: get item id
3: show item details
4: calculate bill
5: bill payment
6: get credit card number
7: verify validation
8: valid
9: validation ok
10: generate report
20
Process sale collaboration diagram
1: Enter no of items
5: bill payment 2: get item id
Cashier POS Codescan
System ner
4: calculate bill 3: show item details
10: generate report
6: get credit card number
9: validation ok
7: verify validation
Card Bank
reader
8: valid
POS system activity diagram
Customer Cashier Barcode reader pos system
enters the
shop
select prepare item scan items bill

product list generation
pay the bill process bill
21
Class diagram:
Component Diagram
Point of
scale
RESULT:
Thus various UML Diagrams were generated for POINT OF SALE SYSTEM and the
corresponding code was generated using Java.
22
EX NO :2 ONLINE BOOK SHOP
AIM: To create a UML diagram of ONLINE BOOK SHOP
ACTORS:
1. customer
USECASES:
 Select Category
 Select book
 Order
 Registration
 Login
 Verification
 Confirmation

new package
23
Online Book Shop Use Case Diagram
Sequence Diagram:
24
Sequence Diagram
25
OBS Collaboration Diagram
26
Activity Diagram:
27
Class Diagram:
28
Dynamic Aspect:
Analysis of Dynamic Aspect of classes:
State chart Diagram:

Objects of this class once created exit with no change of state until application terminates.
Static aspects of the system
The documentation in this section provides information about the static aspects of the
system. It shows how the classes interact and react to specific stimuli.
The documents are shown as follows
Class relation ship diagrams

The application setup of use case diagram is shown
Collaboration Diagram:
The application setup of the use case has collaboration diagrams.
Instance level collaboration diagram of the OBS is given below
Dynamic Aspects of the System:

Component Diagram
<<Application>>
Online Book
Shop
RESULT:
Thus various UML Diagrams were generated for ONLINE BOOK SHOP and the
29
EX NO :3 SIMULATED COMPANY
AIM: To create a SIMULATED COMPANY
ACTORS:
1. OWNER
USECASES:
1. Filing a loan application

2. Purchasing a machine
3. Doing production run
4. Working out the company details
5. Displaying company details.

new package
30
31
Sequence diagrams
32
33
34
Collaboration Diagrams
35
36
37
Activity Diagrams
38
39
40
Class Diagrams:
Component Diagram
<<Application>>
Simulated
company
RESULT:
Thus various UML Diagrams were generated for SIMULATED COMPANY and the
41
EX NO : 4 A Multi- Threaded Airport Simulation
AIM: To create a A Multi- Threaded Airport Simulation
ACTORS:
ATC Controller
Use Cases
1. ATC Controller
2. Decision Support System
3. Planning
4. Emergency
5. Sensor
6. Gateway
7. Runway
8. Terminal
9. Available
10. Waiting Queue

STEP 3: Goto new usecase view and then click the usecase view and
open a new package
STEP 4: Rename the new package with the package with required
names
USECASE DIAGRAM:
1 Draw and drop the actors and usecase from browser window into the
diagram window.
2 Associate the usecases and actors
ACTIVITY DIAGRAM:
1 The activity diagram describes the sequencing of activities, with
support for both conditional and parallel behavior.
2 The various controls are placed into the diagram window to create
activity diagram
42
SEQUENCE DIAGRAM:
1 Create a new package from the database and name it as a sequence

diagram
2 From the toolbar, select the required tools and make corresponding
connections.
COLLABORATION DIAGRAM:
1 Press F5 on the sequence diagram the collaboration diagram is obtained

2 Save the diagram.
COMPONENT DIAGRAM
3 Create a new package from the database and name it as a component

diagram
4 Generate the coding using java
Use Case Diagram
43
 Sequence Diagram:
Sequence Diagrams
Runway Assignment Control Sequence Diagram
44
Conflict Detection Sequence Diagram
Multi Airport Sequence Diagram
45
Collaboration Diagram:
Runway Assignment Control Collaboration

Diagram
Conflict Detection Collaboration Diagram
46
Activity Diagram:
Runway allocation for landing Activity Diagram
47
Class Diagram:
Component Diagram
Airport
Simulation
RESULT
The various UML diagrams were drawn for AIRPORT
SIMULATION SYSTEM application and the corresponding code
was generated.
48
EX NO:5 ONLINE AUCTION
Aim: To create a ONLINE AUCTION
Actors:
1. Purchaser
2. seller
Use Cases in Auction System
1. Login
2. Seller
3. Purchaser
4. Chatting
5. Select Method of bidding
6. Select Method of Auction
7. Buy Goods
8. Register for goods
9. Select history of database
Use Cases In Purchaser’s Diagram:
1. Validate User
2. Record chatting.

open a new package
names
USECASE DIAGRAM:
diagram window.
49
ACTIVITY DIAGRAM:
activity diagram
SEQUENCE DIAGRAM:

diagram
connections.

4 Save the diagram.
COMPONENT DIAGRAM

diagram
50
Use Case diagram of Auction System
buy goods login register for goods
chatting
select method of auction seller

purchaser
select method of bidding
select history of database
logout
Purchaser’s Use Case Diagram
validate user
<<include>>
<<include>>
<<include>>
<<extend>>
login buy goods chatting record chatting
select method of auction
select method of bidding
purchaser
51
Sequence Diagram:
Seller purchaser Adminstrator
1: Register for goods
2: select product by auction
3: get the product details
4: give status
5: check status
6: credit card details
7: validate card
8: give status of products
52
Static aspects of the system: Collaboration diagram
53
Activity Diagram
54
Activity Diagrams
Auction Activity Diagram
55
Bidding activity Diagram
56
Class Diagram:
user
name : string goods
id : number name : string
password : string quantity : number
login() update goods()

logout() details of goods()
bidding()
seller purchaser auctioned goods

progress goods
name : string name : string
id : number classification : char production date : int
id : number production price : double
password : string password : string Max purchase price : double
actual purchase price : double id of purchaser : int
login() login() least purchase price : double
chattting() chatting() target selling price : double
select method ofauction()
register goods() actual selling price : double
logout() select method of bidding()
purchase goods()
no of seller : int
logout() id of purchaser : int
id of seller : int
date of sale : int
registration
name : string
address1 : string
address2 : string
password : string
method of auction method of bidding
send form()
extract data() type of auction : int price of goods
create data()
send id()
save data()
method of bidding 1 method of bidding 2

call of bidding() call of bidding()
Component Diagram
<<Application>>
Online Auction
RESULT:
Thus various UML Diagrams were generated for Online Auction Application and
the corresponding code was generated using Java.
57
EX NO :6 CONTENT MANAGEMENT SYSTEM
AIM: To create a UML diagram of CONTENT MANAGEMENT SYSTEM.

ACTORS:
1. End user
2. Administrator
3. Manage
USECASES:
1. Access the web

2. publish
3. share information
4. check security permission
5. login
6. verifying control
7. control presentation
8. control content and style

new package
USECASE DIAGRAM:
diagram window.
ACTIVITY DIAGRAM:
58
activity diagram
SEQUENCE DIAGRAM:

diagram
connections
6 Save the diagram.
COMPONENT DIAGRAM

diagram
59
USE CASE DIAGRAM FOR CONTENT MANAGEMENT SYSTEM
CHECK SECURITY PERMISSION
publish
endUser EXTEND administrator

INCLUDE
id : integer ACCESS THE WEB
password : integer checksp()
INCLUDE vc()
login() cp()
logout()
VERSIONING CONTROL
sbope()
endUser()
LOGIN
INCLUDE
CONTROL PRESENTATION
SHARE INFORMATION
manager
CONTROL CONTENT AND STYLE
60
SEQUENCE DIAGRAM FOR CONTENT MANAGEMENT SYSTEM
END USER SYSTEM ADMINISTRAT

OR
logs in
checks for login permission
login ok
select the browse operation
generate the rquired info
logout
terminates the user login
logout successfull
61
COLLABORATION DIAGRAM FOR CONTENT MANAGEMENT SYSTEM
ADMINISTR
ATOR
2: checks for login permission
3: login ok
7: terminates the user login
5: generate the rquired info

8: logout successfull
SYSTEM END
USER
1: logs in
4: select the browse operation
6: logout
62
ACTIVITY DIAGRAM FOR CONTENT MANAGEMENT
user logs in
system checks for

security permission
user selects browse

operation
system displays the

required info
user logs out
63
CLASS DIAGRAM FOR CONTENT MANAGEMENT SYSTEM
System
<<Actor>> (from lang)
endUser in : InputStream
(from Use Case View) out : PrintStream
id : integer err : PrintStream
password : integer
setIn()
login() setOut()
logout() setErr()
sbope() setSecurityManager()
endUser() getSecurityManager()
currentTimeMillis()
arraycopy()
identityHashCode()
getProperties()
setProperties()
getProperty()
getProperty()
setProperty()
getenv()
exit()
gc()
<<Actor>> runFinalization()
administrator runFinalizersOnExit()
(from Use Case View) load()
loadLibrary()
checksp() mapLibraryName()
vc()
cp()
64
COMPONENT DIAGRAM FOR CONTENT MANAGEMENT SYSTEM
CONTENT MANAGEMENT SYSTEM
RESULT:VARIOUS DIAGRAMS FOR CONTENT MANAGEMENT SYSTEMS HAS BEEN DRAWN AND
VERIFED.
65
EX NO :7 BANK APPLICATION
AIM: To create a UML diagram of BANK APPLICATION.
ACTORS:
1. Customer
2. Manager
3. Operator
4. Transaction system
5. Master system
USECASES:
1. create acct
2. closing acct
3. withdraw
4. deposit
5. apply loan
6. grant loan
7. verify cust details
8. fixed deposit
9. verify maturity date
10. update trans
11. update master
12. issue amt

new package
USECASE DIAGRAM:
diagram window.
66
ACTIVITY DIAGRAM:

activity diagram
SEQUENCE DIAGRAM:

diagram
connections.

8 Save the diagram.
COMPONENT DIAGRAM

diagram
67
Banking - USE CASE Diagram
Create acct
Close acct
Operator
withdraw
deposit
Customer
update transaction
issuing amt
apply loan
Transacion
Grant loan system
Verify cust details

Manager
Verify maturity date

update master file
Fixed deposit
Master system
Banking: ActivityDiagram
specify
transaciontype
trans_trpe? 68
Banking: ActivityDiagram
specify
transaciontype
trans_trpe?
4 5
1 2 3
Deposit? FD? cust applyfor
createacct? closeacct? yes specifythe loan
withdrawamt? maurityperiod
yes no
cust paythe
Acct already
FD? datematured? amt Managerverify
exists? operatorissueamt&
closetheacct cust details
no no operatoraddtheamt
createacct & amtavailablein yes toacct/ issuetheFD
acct? satisfied? no
issuepassbook no yes
Informcust amt Issuetheamt yes
not available rejectingthe
grant loan loan
update
transaction
transcommited?
yes
cancel
updatemaster transaction
file
69
Ba nkin g: Sequence Di agram
Customer Operator Manager Master system transaction

system
1:specify_trans()
3:c reate_acct() 2:check_trans_type()
5:pay_amt()
4:acct_already_exist()
6:issue_passbook() 7:update_trans()
8:closing_acct()
9:issue_amt() 10:update_trans()
11:withdraw()
12:fix eddeposi t()
13:if not FD, check_amt()

14:issue_amt()
15:update-trans()
16:if FD,verify_mat_date()
17:if matured, issue_amt()
18:update_trans()
19:deposit()
20:fixeddeposit()
21:if FD,specify_fd_period()
22:update_trans()
23:apply_loan()
24:verify_cust_details
25:grant_loan()
2 6:t rans_c omm it()
27:if commited, update_master()
28:if not, cancel_trans()
70
Banking:Colloboration diagram
2: 2:check_trans_type()
5: 4:acct_already_exist() 7: 7:update_trans()
12: 12:fixeddeposit() 10: 10:update_trans()
13: 13:if not FD, check_amt() transaction
15: 15:update-trans()
16: 16:if FD,verify_mat_date() system
18: 18:update_trans()
20: 20:fixeddeposit() 22: 22:update_trans() 28: 28:if not, cancel_trans()
24: 24:verify_cust_details
26: 26:trans_commit()
Operator
Manager
6: 6:issue_passbook()
9: 9:issue_amt()
14: 14:issue_amt()
17: 17:if matured, issue_amt()
1: 1:specify_trans() 23: 23:apply_loan()

3: 3:create_acct()
4: 5:pay_amt() 27: 27:if commited, update_master()
8: 8:closing_acct()
11: 11:withdraw()
19: 19:deposit() 25: 25:grant_loan()
21: 21:if FD,specify_fd_period()
Customer
Master
system
71
Banking: Class Diagram
Transaction
trans_type : int
trans_completed : boolean
check_trans_type()
trans_commit()
cancel_trans()
update_trans() Transaction Types
type : int
create_acct()
Cust
close_acct()
Name : string withdraw()
occupation : string deposit()
otherdet : varchar fixeddeposit()
acct_type : string wd_fd()
acct_no : int verfify_maturiy_date()
apply_loan()
specify_trans() verfiy_cust_detals()
pay_amt() grantloan()
specify_fd_period() System_maintena
nce issue-amt()
acct_already_exist()
balance : float
issue_passbook()
check_amt()
update_master()
Banking:Componen Diagram
Transaction Master
System system
Cus tomer
trans
RESULT:
Thus various UML Diagrams were generated for BANK APPLICATION and the
72
EX NO :8 ATM APPLICATION
AIM: To create a UML diagram of ATM APPLICATION.
ACTORS:
1. Client
2. Administrator
3. System
USECASES:
1. insert card
2. enter pin no
3. invalid pin
4. type of transaction
5. withdrawal amount
6. balance amount
7. transaction completed
8. remove the card
9. exit
10.carryout transaction
11.transaction completed
12.complain
13.sends currency
14.check balance amount
15.check card validity
16.inform about transaction
17.sends bill

new package
73
USECASE DIAGRAM:
 Draw and drop the actors and usecase from browser window into the
diagram window.
 Associate the usecases and actors
ACTIVITY DIAGRAM:
 The activity diagram describes the sequencing of activities, with

 The various controls are placed into the diagram window to create
activity diagram
SEQUENCE DIAGRAM:
 Create a new package from the database and name it as a sequence

diagram
 Form the toolbar, select the required tools and make corresponding
connections.
 Press F5 on the sequence diagram the collaboration diagram is obtained

 Save the diagram.
COMPONENT DIAGRAM:
 Create a new package from the database and name it as a component

diagram
 Generate the coding using java
74
Use Case Diagram ATM
insert card validity
PIN
Request
client
Admini
change Pin
Change Pin
Withdrawal
Report
Done
75
Administrator Sequence Diagram
insert card Pin request Widthdraw change Pin
: Admini
1: Atm Card
2: Pin from client
3: Validate
4: Request
5: check for balance

6: pay amount
7: Cahnge Pin
76
Client Sequence Diagram
insert card Pin request widthdraw change pin Exit

: client
1: Insert the card into ATM
2: Enter Pin code

3: Validity
4: Show menu
5: Request
6: to withdraw
7: valid
8: pay amopunt
9: to change pin
10: Enter new Pin

11: New pin
12: To exit
13: Eject the card
77
Collaboration Diagram For Administrator
3: Validate insert
5: check for balance card
Pin
1: Atm Card
2: Pin from client

7: Cahnge Pin change
Pin
: Admini 6: pay amount
4: Request Widthdr
request aw
Collabration Diagram For Client
insert
Exit 1: Insert the card into ATM card 3: Validity
13: Eject the card
7: valid 2: Enter Pin code
8: pay amopunt Pin
: client 4: Show menu
widthdra
12: To exit w 11: New pin
6: to withdraw 5: Request 10: Enter new Pin
9: to change pin
request change
pin
78
ATM Activity Diagram
Insert the
card
Enter Pin Check pin valid
Choice to widthdraw,account
info,change pin
is widthdraw
yes is report
Amount for
widthdraw yes is pin change
Print the account
details yes
Checking
balance Enter new
Pin
Inform ur balance
check valid
is less amount
Update pin
pay amount
requested
Go to menu
Eject the
card
79
ATM Class Diagarm
Client Admini
name atmid : String
cardNo : String +theClient +theAdmini
Laocation : String
Pin : Integer
Withdraw()
requestWithdraw() changePin()
requestChangePin() Report()
Component Diagram
ATM
RESULT:
Thus various UML Diagrams were generated for ATM SYSTEM and the
80
Exp.No: 9 AIM: To create a UML diagram of RAILWAY RESERVATION
SYSTEM
ACTORS:
1. Passenger
2. System
USECASES:
1. enter the website
2. choose the destination
3. list of trains
4. user details
5. number of seats
6. credit card number
7. ticket status
8. confirmation
9. exit
new package
USECASE DIAGRAM:
diagram window.
ACTIVITY DIAGRAM:
activity diagram
SEQUENCE DIAGRAM:
diagram
81
 From the toolbar, select the required tools and make corresponding
connections.
COMPONENT DIAGRAM:
diagram
82
Usecase Diagram
Enter the Web site
Choose the destination
List of Trains
User details
Choose the Train
Passenger
Number of seats System
Credit Card number
Ticket status
Confirmation
Exit
83
Activity Diagram
ENTER
WEBSITE
SPECIFY SOURCE,
DEST.
CHOOSE
TRAIN
SPECIFY USER
DETAILS
SEAT
NO AVAILABLE YES
NEXT TRAIN
SPECIFY CREDIT
CARD NUMBER
VALIDATE
CREDIT
CONFIRM
DETAILS
DISPLAY
TICKET
UPDATE
DATABASE
84
Sequence Diagram(Passenger)
ENTER SPECIFY CHOOSE SPECIFY ENTER CREDIT CONFIRM

: Passenger DETAILS CARD NO
WEBSITE DEST. TRAIN DETAILS
1: Enter website
2: Specify Destination
3: Choose train
4: Specify details
5: Enter Credit card number
6: Confirm details
Collaboration Diagram(Passenger)
1: Enter website ENTER

WEBSITE
2: Specify Destination
SPECIFY
DEST.
: Passenger
3: Choose train
4: Specify details
CHOOSE
TRAIN
5: Enter Credit card number
SPECIFY
6: Confirm details DETAILS
ENTER CREDIT
CONFIRM CARD NO
DETAILS
85
Sequence Diagram(System)
: System LIST OF ACCEPT CHECK AVAILABILITY VALIDATE DISPLAY UPDATE

TRAINS DETAILS OF SEATS CREDITCARD TICKET DATABASE
1: List out the trains
2: Accept details
3: Seat Availability
4: Validate Credit Card
5: Display Ticket
6: Update Database
Collaboration Diagram(System)
1: List out the trains LIST OF

TRAINS ACCEPT
2: Accept details DETAILS
3: Seat Availability
CHECK AVAILABILITY
: System 4: Validate Credit Card OF SEATS
VALIDATE
5: Display Ticket
CREDITCARD
6: Update Database
UPDATE DISPLAY
DATABASE TICKET
86
Class Diagram
PASSENGER
NAME SYSTEM
CREDITCARDNUMBER
DETAILS 1 DISPLAY_LIST_OF_TRAINS()
* CHECK_AVAIL_SEATS()
ENTER_WEBSITE() CHECK_CREDITCARD_INFO()
CHOOSE_DEST() PROCESS_STATUS()
CHOOSE_TRAIN() SHOW_TICKET()
ENTER_DETAILS() CONFIRM()
ENTER_CREDITCARDNUM()
Component Diagram
<<ActiveX EXE>>
OnlineTicket
RESULT:
Thus various UML Diagrams were generated for RAILWAY RESERVATION

SYSTEM and the corresponding code was generated using Java.
87
Exp.No:10 AIM: To create a UML diagram of LIBRARY MANAGEMENT
system
ACTORS:
1. Librarian
2. Member
3. System
4. Sys operator
5. Manager
USECASES:
1. apply membership card

2. issue membership card
3. lose of library card
4. pay fine and get new membership card
5. refer book
6. issue book
7. renewal
8. return
9. inform books needed
10.check no of books in member’s card
11.calculate fine
12.pay fine
13.check who currently has the book
14.order for new books
15.enter student details
16.enter book details

new package
USECASE DIAGRAM:
88
diagram window.
ACTIVITY DIAGRAM:

activity diagram
SEQUENCE DIAGRAM:

diagram
connections.

COMPONENT DIAGRAM

diagram
 Generate the coding using java.
‘CODE FOR LIBRARY SYSTEM
‘CODE FOR LIBRARIAN
89
Library Use Case Diagram
Control Maintain Members

Check datevalid
Request for Activity Order for books/magazine
Reponse
Manager Librarian Join
Renewel
Loan book Return book FIne deatil pay fine
Instuction Materials need Report
Helpsto member
bookskeeper
Request for materials need
Reference material
Maintain material
90
Activity Diagram
Find books or some

reading m aterials
Overthrough
books Return or
renewel book
No
if need Refer the
books Check date
valid
if member
no
Getting loan if fine

from librarian pay fine
Librarian note deatils fine paid

required , give it for loan
Return or
renewal book
Leave the
Library
91
Manager Sequence Diagram
control Request Response
: Manager
1: instruction to maintain
2: request for acitvity
3: Reponse to request
Collaboration Diagram
1: instruction to maintain
2: request for acitvity
control
: Manager
Request
3: Reponse to request
Respons
e
92
Bookskeeper Sequence Diagram
Helps Inform to Request

: bookskeeper librarian
1: Reuesting books needed from member or nonmember
2: Response for request
3: Inform books needed for library
Request
1: Reuesting books needed from member or nonmember

3: Inform books needed for library
Helps 2: Response for request
Inform to
librarian
: bookskeeper
93
Matian
membership
order
Return or 3: Matain membership deatails

renewel
4: Order for reading material needed

6: Cheking for membership
8: Request for return or renewel 9: Checking for date vaild
11: Pay fine 12: Taking books return
10: Date crossed Asking Fine

reuest
2: Requesting for some activity
: Librarian
5: Reuesting to get books for loan
7: Give books for loan
Give for
Loan 1: Give Reading Material needed
Reading material
needed
94
Sequence Diagram For Member
books for return or Reuesting Helping Refer books

loan Renewel
: member
1: Refer books to read or loan
2: Requesting for books needed

3: Books needed is shown
4: Getting books for loan
5: Return or Renewel books
6: May pay fine
95
5: Return or Renewel books

4: Getting books for loan 6: May pay fine
books for
loan return or
Renewel
: member
3: Books needed is shown
1: Refer books to read or loan

2: Requesting for books needed Helping
Refer
books
Reuestin
g
96
Class Diagram
Librarian
Management name : char
detail : char
name : char
detail : char
issuebooks()
takingreturn()
checkVailddate()
Member
bookskeeper
name : char
detail : char name : char
validDate : char detail : char
getloanBooks() maintainBooks()
returnBooks() requirment()
Component Diagram
<<Application>>
Libraray
RESULT
Thus various UML Diagrams were drawn for LIBRARY SYSTEM and the
97
EXP NO 11 AIM: To create a UML diagram of Inventory Control System.
To create a UML diagram of Inventory Control System.
ACTORS:
1. Stock Manager
2. Service Manager
3. Supplier
4. Stock Accountant
5. Buyers
USECASE:
1. maintain existing stocks

2. request for stocks_supply
3. buy new stocks
4. request service repair
5. component service repairment
6. maintains service account
7. supply required stocks
8. maintains purchase account
9. stocks sale
10. maintain supply account
11. update stock inventory DB

open a new package
names
USECASE DIAGRAM:
diagram window.
98
ACTIVITY DIAGRAM:
activity diagram
SEQUENCE DIAGRAM:

diagram
connections.
 Press F5 on the sequence diagram the collaboration diagram is

obtained
COMPONENT DIAGRAM

diagram
/* CODE FOR INVENTORY CONTROL SYSTEM */
Option Explicit
99
Inventory Class Diagram
StockAccountant
StockManager StocksAvailable1
DateBought1
StocksAvailable
DateSold1
StocksPurchased
ServiceRepairmentDate
StocksSold
1
SupplyAccount1
StocksServiced
PurchaseAccount1
StockRepaired +theStockManage
ServiceAccount1
InventoryDB r
InventoryDB1
MaintainsExistingStocks()
MaintainsSupplyAccount()
BuySocks()
UpdateStocks()
SellStocks()
MaintainsPurchaseAccount()
MaintainsInventoryDB()
MaintainsServiceAccount(
StockManager()
)MaintainsInventoryDB()
StockAccountant()
+theStockAccountant
+theStockAccountant
+theStockAccountant
+theSupplyAccount
+thePurchaseAccount+theServiceAccount
SupplyAcco
unt PurchaseAc ServiceAcco
+theSupplyAccount count unt
+theServiceAccount
+theStockSupplier +theServiceEngineer
StockSupplier +theBuyer ServiceEngineer

CompanyRequests CompanyRequests
Buyer
StocksSupplied StocksServiced
StocksRequested1 StocksRepaired
SupplyDetails
StocksBought1 ServiceRairInfo
GetSupplyRequest()
RequestCompanyStocks( SevicesStocks()
SupplyStocks() )BuyStocks()
MaintainsSupplyAccount() RepairsStocks()
UpdateStocks() MaintainsServRepAcc()
StockSupplier()
MaintainsPurchaseAccount() ServiceEngineer()
100
USECASE DIAGRAM
Maintains existing
stocks
Request for
Stocks_supply
Stock
manager
Buy new stocks
Request_ServiceRepai
r
Components_ServiceR
epairment
Service
Engineer
Maintains service
account
Supply required stocks
Supplier
Maintains Purchase
account
Stock
Accountant StocksSale
Maintains Supply
account
Buyers
Update
StocksInventoryDB
101
COLLABORATION DIAGRAM
Inventory Collaboration Diagram
1: Request for supply

3: Purchase Stocks
StockManager Supplier
2: Supply stocks
9: Updates Inventory DB
6: Request Stocks
7: Sell Stocks
5: Update Stocks and Inventory DB 4: Update Purchase account

10: Request for Service or Repair of Stocks 13: Update InventoryDB
11: Provides Service And Repairs
Buyer
8: Update Supply Account
ServiceEngin StockAccoun
eer tant
12: Updates ServiceRepair Account
102
SEQUENCE DIAGRAM
Inventory Sequence Diagram
StockManager StockAccountant Supplier Buyer ServiceEngineer
Request for supply
Supply stocks
Purchase Stocks
Update Purchase account
Update Stocks and Inventory DB
Request Stocks
Sell Stocks
Update Supply Account
Updates Inventory DB
Request for Service or Repair of Stocks
Provides Service And Repairs
Updates ServiceRepair Account
Update InventoryDB
103
start
Inventory Activity Diagram
Request option
repair or
Buy? service?
Sell?
Purchase new
Stocks Sell
Repairs or
Stocks
services stocks
Updates Purchase Updates Supply

Account account Update
Repair_ServiceAccount
Update stocks
in Inventory DB
stop
104
Component Diagram
<<Application
Inventory
>>
RESULT
The various UML diagrams were drawn for INVENTORY

SYSTEM application and the corresponding code was generated.
105
EXP NO 12 AIM: To create a UML diagram of QUIZ APPLICATION.
ACTORS:
1. Interviewer
2. participant
3. scorer
USECASES:
10.number of team
11.number of participants
12.explain rules
13.round no
14.ask questions
15.time up
16.answers
17.correct answers
18.announce marks
19.announce results
20.distribute prices

new package
USECASE DIAGRAM:
diagram window.
106
ACTIVITY DIAGRAM:

activity diagram
SEQUENCE DIAGRAM:

diagram
connections.

COMPONENT DIAGRAM

diagram
107
Quiz Usecase Diagram
No of Teams
Team Name
No of Participants
Rules
Rounds
Participant
Interviewer
Q&A
Time
Score Scorer
Result
Prize
108
Activity Diagram For Quiz
Announcement of no.of Teams, Participants &

Rules
Questions
Answers
Check
Answers
Correct Incorrect
Increament
Score
Next
Question
Result
Prize
109
Sequence Diagram for Interviewer
RULES NO.OF QUESTION RESULT PRIZE

Interviewer TEAMS
1: Announces
2: Announces
3: Asks
4: Announces
5: Distributes
Collaboration Diagram for Interviewer
RULES NO.OF TEAMS QUESTION
2: Announces RESULT
3: Asks
1: Announces 4: Announces
5: Distributes
PRIZE
Interviewer
110
Sequence Diagram For Participant
RULES ROUNDS CHOICE OF QUESTION ANSWERS SCORE

QUESTION
Participant
1: Announced to
2: Announced to
3: Specifies
4: Specifies 5: Asked to
6: Choose
7: Answers
8: Correct
9: Wrong
Collaboration Diagram For Participant

8: Correct QUESTION
ANSWERS SCORE
9: Wrong 4: Specifies
7: Answers 5: Asked to
CHOICE OF
QUESTION
1: Announced to 6: Choose
Participant 3: Specifies
RULES
2: Announced to
ROUNDS
111
Sequence Diagram for Scorer
TIME SCORE RESULT
Scorer
1: Time Elapsed for a question
2: Increament after Correct Answer
3: Announce at the end
Collaboration Diagram For Scorer
RESULT
3:
1: TIME
2:
Scorer : Scorer
SCORE
112
Class Diagram For Quiz
<<Class Module>>
PARTICIPENT
NAME : Variant
*
TEAM_NAME : Variant
NOS : Variant
<<Class Module>> ANSWERS()

1
INTERVIEWER
NAME : Variant
QUESTIONS() 1
RULES()
RESULTS()
<<Class Module>>
1 SCORER_
SCORE : Variant
TIME : Variant
ANN_RESULTS()
ANN_TIME()
Component Diagram For Quiz
QUIZ
RESULT :
The various UML diagrams were drawn for QUIZ application and the
corresponding code was generated
113
Library Information System
Class Diagram-Library Information System:-

EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistere
cd
Member
EA 4.10 Unregistered
dbase Trial Version - EA 4.10 Unregistered Trial Version
name: librarian EA 4.10 Unregistere
- adress: int
- speed: - id: int - name:
EA 4.10 Unregistered Trial Version* EA 4.10 Unregistered
- computer:
*
Trial Version int EA 4.10 Unregistere
- designation:
- cost: int 1 + login() : void
+ search() : void * + verify() : void
+
+
login() : void
search() : void
1
+
+
read() : void
return() : void
+
+
add() : void
delete() : void
+ issue() : void
1 + collectfine() : void
1
student Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistere
* *
- branch:
- year: int
EA 4.10 Unregistered Trial Version
staff EA 4.10 Unregistered
book Trial Version EA 4.10 Unregistere
+ read() : void * - author:
- designation:
+ write() : void - cost: int
-
-
branch: int
experience: int - publisher: int
+ read() : void + read() : void

+ write() : void EA 4.10 Unregistered
+ write() : voidTrial Version EA 4.10 Unregistere
EA 4.10 Unregistered Trial Version EA 4.10 Unregistered

«realize»
Trial Version EA 4.10 Unregistere
«realize»
magazine
EA 4.10 Unregistered Trial Version EA 4.10
textbookUnregistered Trial Version EA 4.10 Unregistere
- author:
- author: - cost: int
- cost: int
- publishername: int
- publishername: int
+ read() : void
+ read() : void + write() : void
+ write() : void
114 Unregistered Trial Version EA 4.10 Unregistere

EA 4.10 Unregistered Trial Version EA 4.10
Object
EA 4.10 diagram -Library
Unregistered Trial Information
Version EA System:-
4.10 Unregistered Trial Version EA 4.10 Unregistere
cd
member librartian
staff
EA 4.10 Unregistered Trial
student
Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistere
text Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistere
database
EA 4.10 Unregistered Trial

book Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistere
magazine
115
Sequence diagram: -Library Information System:-
EAsd4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial V
EA 4.10member
Unregistered Trial Version
librarian
database
Trial Version EA 4.10 Unregistered Trial V
book
EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial V
create
verifyid

login
EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial V

search EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial V
fou
deletebook
issuebook
read
return
Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial V
EA 4.10 Unregistered Trial Version EAaddbook

4.10 Unregistered Trial Version EA 4.10 Unregistered Trial V
116
EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Ver
Deployment diagram: -Library Information System:-
dd
client serv er
+ book.exe() : void + login() : void
+ librarian.exe() : void EA 4.10 +Unregistered
«deploy» search() : void Trial Version EA 4.10 Unregistered Trial Ver
+ member.exe() : void
+ database.exe() : void
117
Activity diagram: -Library Information System:-
ad
customer librarian database

EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Un
start
request for book
EA 4.10 Unregistered Trial Versionv erifyEA

id
4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Un
giv e permission
goto database
login
search
found
EA 4.10 Unregistered Trial Versionv erifybook

EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Un
EA 4.10 Unregistered Trial Version issue

EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Un
delete
EA 4.10readbook
Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Un
return
takebook
v erifybook
EA 4.10 Unregistered Trial Version stopEA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Un
118
EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Ve
Component diagram: -Library Information System:-
id
lib infosys
member.j av a
EA 4.10 Unregistered Trial Version EA 4.10 Unregistered
librarian.j av a
Trial Version EA 4.10 Unregistered Trial Ve
EA 4.10 Unregistered Trial Version book.j

EAav4.10
a
Unregistered Trial Version EA 4.10 Unregistered Trial Ve
119
Collaboration diagram: -Library Information System:-
4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Versio
cd
4.10 Unregistered Trial Version EA 4.10 Unregistered

:database Trial Version EA 4.10 Unregistered Trial Versio
4.10 Unregistered Trial Version 3: logi

EA n( )4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Versio
4: search( ) 8.1: del ete book
10.1: add book
5: found( )
4.10 Unregistered9:Trial
read book( )
Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Versio
:member 10: return( )
:librarian
1: create( )
2: verify id
8: i ssue book
4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version

6: select book EA 4.10 Unregistered Trial Versio
7: veri fy book
:book
4.10 Unregistered Trial Version EA 4.10 Unregistered

120 Trial Version EA 4.10 Unregistered Trial Versio
Mini Project :
PAYROLL SYSTEM
CONTENTS
Chapter No. Description Page No.
1. Problem Statement 01
2. Payroll System Glossary 02
3. Payroll System Supplementary Specifications 03
4. Finding the Actors & Use cases from the Payroll system 05
5. Payroll System use case model main diagram 06
5.1 Brief Description of use cases 07
6. Identifying the Classes 08
6.1 Boundary Classes
6.2 Control Classes
6.3 Entity Classes
7. Class Diagram 09
8. Sequence Diagram 10
9. Deployment Diagram 11
PROBLEM STATEMENT
As the head of information technology at ACME incorporation, you are

tasked with building a new payroll system to replace the existing system, which is
hopelessly out of date. Acme needs a new system to allow employees to record
timecard information electronically and automatically generate pay cheques based
on number of hours worked and total amount of sales (for commissioned
employees).
The new system will be state of the art and will have windows based
desktop interface to allow employees to enter timecard information, enter purchase
orders, change employee preferences such as payment methods and create
various reports. The system will run on individual desktop throughout the entire
121
company. For reason of security and auditing, employees can only access and edit
their own timecard and purchase orders.
The system will retain information of all employees in the company (Acme),
currently has 5000 employees worldwide. The system must
pay each employee a correct amount, on time, by the method
that they specify (see possible methods described later).
Acme for cost reasons does not want to replace one of their
legacy data base, the project management database that
contains all information regarding projects and charged
numbers. The new system must work with the existing project
management database, which is the DB2 database running
on IBM mainframe. The payroll system will access but not
update information stored in the project management
database.
Some employees work by the hour and they are paid by

hourly rate. The Submit timecard that regards the date and
number of hours worked for a particular charge numbers. If
someone works for more than 8 Hours, Acme pays him or her
1.5 times their normal rate for those extra hours. Hourly
workers are paid every Friday.
Some employees are paid a flat salary. Even though they

are paid a flat salary they submit timecards that regards the
date and hours worked. This is so the system can keep track
of hours worked against particular charged numbers. They are
paid on the last working day of the month.
Some of the salaried employees also receive a

commission based on their sales. They submit purchase
orders that deflect the date and amount of sale. The
commission rate is determined for each employee and is one
of 10%, 15%, 25% or 35%.
122
One of the most requested features of the new system is
employ reporting. Employees will be able to query the system
for numbers of hours worked, totals of all hours billed to a
project (charge number), total pay received here-to-date,
remaining vacation time, etc.,
Employees can choose a method of payment. They can

have their pay cheques, mailed to the postal address of their
choice, or they can request direct deposit and have their pay
cheque into a bank account of their choosing. The employee
may also choose to pack their pay cheques up at the office.
Payroll administrator maintain employee information, the
payroll administrator is responsible for adding new
employees, deleting employees and changing all employees
information such as name, address and payment
classification (hourly, salaried, commissioned), as well as
running administrative reports.
The payroll application will run automatically every Friday

and on the last working day of the month. It will pay the
appropriate employees on those days. The system will be told
what date the employees to be paid. So, it will generate
payments for records from the last time the employee was
paid to the specified date. The new system being designed so
that the payroll will always be generated automatically and
there is no need for any manual intervention.
Payroll System Glossary

Introduction
This document is used to define terminology specific to the problem domain,
explaining terms, which may be unfamiliar to the reader of the use-case
descriptions or other project documents. Often this document can be used as an
informal data dictionary, capturing data definitions to that use-case description and
other project documents can focus on what the system must do with the
information.
123
Definitions
The glossary contains the working definitions for the key concepts in
the payroll system.
Bank system
Any bank(s) to which direct deposit transactions are sent.
Employee
A person that works for the company that owns and operates the payroll
system (Acme, Inc).
Payroll Administrator
The person responsible for maintaining employees and
employee information in the system.
Project Management Database

The legacy database that contains all information that
regarding projects and charge numbers.
System Clock
The internal systems clock that keeps track of time. The
internal clock will automatically run the payroll at the
appropriate times.
Pay Period
The amount of time over which an employee is paid.
Paycheck
A record of how much an employee was paid during a
specified Pay Period.
Payment Method
How the employee is paid, either pick-up mails, or directs
deposit.
124
Timecard
A record of hours worked by the employee during a
specified Pay Period.
Purchase Order
A record of a sale made by an employee.
Salaried Employee
An employee that receives a salary.
Commissioned Employee
An employee that receives a salary plus commissions.
Hourly Employee
An employee that is paid by the hour.
Payroll System Supplementary Specification
Objectives
The purpose of this document is to define requirements
of the payroll system. This supplementary specification lists
the requirements that are not readily captured in the use-
cases of the use-case model. The supplementary
specifications and the use-case model together capture a
complete set of requirements on the system.
Scope
This supplementary specification applies to the payroll
system, which will be developed by the OOAD students. This
specification defines the non-functional requirements of the
system: such as reliability, usability, performance and
supportability as well as functional requirements that are
common across a number of use-cases. (The functional
requirements are defined in the use-case specifications.)
References
125
None
Functionality
None
Usability
None
Reliability
The main system must be running 98% of the time. It is
imperative that the system be up and running during the times
the payroll is run(Every Friday and last working day of the
month).
Performance
The system shall support up to 2000 simultaneous users
against the central database at any given time and up to 500
simultaneous users against the local servers at any one time.
Supportability
None
Security
The system should prevent employees from changing
any timecards other than their own. Additionally, for security
reasons, only the payroll administrator is allowed to change
any employee information with the exception of the payment
delivery method.
Design Constraints
126
The system shall integrate with an existing legacy
system, the project management database, which is a DB2
database running on an IBM mainframe.
The system shall interface with existing bank systems via an
electronic transaction interface
(NOTE: THE FORMAL INTERFACES WITH THE EXTERNAL

BANK SYSTEM WOULD NEED TO BE DEFINED EARLY IN
THE PROCESS AND DEFINED HERE OR IN A SEPARATE
SUPPORTING DOCUMENT. SUCH A DEFINITIONS IS OUT
OF THE SCOPE OF THIS COURSE.)
The system shall provide a windows-based-desktop

interface.
Finding the Actors and Use-cases from the system
1.Actors
1. Employee
2. Commissioned Employee
3. Payroll Administrator
4. System clock
5. Project database
6. Printer
7. Bank system
2.Use-cases
127
1. Select payment
2. Maintain timecard
3. Create employee report
4. Maintain purchase order
5. Login
6. Create administrative report
7. Maintain employee information
8. Run payroll
USE-CASE DIAGRAM
128
Select payment
Maintain time card

Project data
Employee base
Create employee report
Login
Maintain purchase order
Commisioned
employee
Create administrator report
Payroll
administrator Maintain employee
information
System clock Run payroll

Printer
Bank system
129
Brief Description of Use-Cases
Run payroll
Brief Description
The use-case describes how the payroll is run every Friday and the last
working day of the month.
Flow of Events
Basic Flow
The use-case begins when it’s time to run the payroll. The payroll is run
automatically every Friday and the last working day of the month.
1. The system retrieves all employees who should be paid on

the current date.
2. The system calculates the pay using entered timecards,
purchase orders, employee information (e.g., salary,
benefits, etc,) and all legal deductions.
3. If the payment delivery method is mail or pick-up, the
system prints a paycheck.
4. If the payment delivery method is direct deposit, the system
creates a bank transaction and sends it to the Bank system
for processing.
5. The use-case ends when all employees receiving pay for
the desired date have been processed.
Alternative Flows
130
Bank System Unavailable
If Bank system is down, the system will attempt to send

the bank transaction again after a specific period. The system
will continue to attempt to re-transmit until the bank system
becomes available.
Deleted Employees
After the payroll for the Employee has been processed, if

the employee has been marked for deletion (see the Main
Employee use-case), then system will delete the employee.
Special Requirements
None
Pre-Conditions
None
Post-Conditions
Payments for each employee eligible to be paid on the

current date have been processed.
Extension Points
None
Identifying the Classes
Boundary classes
1. System check interface
2. Naming
Control Classes
1. Payroll controller
2. Pay controller
131
Entity Classes
1. Payroll DB Manager
2. Pay check
3. Time period
4. Employee
5. Salaried Employee
6. Hourly Employee
7. Commissioned Employee
8. Purchase Order
CLASS DIAGRAM
<< boundary >> << Interface>> 0..1 0..* << Interface>>

...>>
System Clock Interface Payroll Controller Bank System
0..1
0..*
<< boundary >> << control>> 0..1 0..* << Interface>>

Naming Pay Controller Printer Interface
0..1
0..1
0..* 0..*
<< entity>> << entity>> 1 0..* << entity>>
Payroll DB Manager Employee Pay Check
0..*
<< entity>> << entity>> << entity>>
Hourly Employee Salaried Employee Time Card
<< entity>> << entity>>

Commissioned Employee Purchase Order
1 0..*
132
Sequence Diagram
:System Clock :IPayroll Payroll DB :Employee :Timecard :Purchase :Paycheck :Printer

: System clock : Printer
Interface Controller Manager Order Interface
1: Lookup(string)
2: Run Payroll
3: getemployee(string)
4: Is Pay Day?()
5: get payamount()
6: get timecardinfo
7: get PO info()
8: calculatepay()
9: //create with amount(calculate pay)
10: //add(paycheck)
11: //save(paycheck,emp)
12: //get payment()
13: print(paycheck,string)
14: get bankinf
15: print
16: deposit(paycheck,bankinf)
DEPLOYMENT DIAGRAM
Desktop
Printer
PC
Payroll
Server
Bank Project
System Mana...
133
Mini Project :
COURSE REGISTRATION SYSTEM
CONTENTS
Chapter No. Description Page No.
1. Problem Statement 01
2. Course Registration System Glossary 02
3. Course Registration System Supplementary Specifications 03
4. Finding the Actors & Use cases from the registration system 04
5. Course Registration System use case model main diagram 05
5.1 Brief Description of use cases 05
6. Activity Diagram 08
7. Identifying the Classes 09
7.2 Control Classes
7.3 Entity Classes
8. Class Diagram 10
9. Interaction Diagram 11
10. State Chart Diagram 12
11. Component Diagram 13
12. Deployment Diagram 14
134
Problem Statement
As the head of Information Systems for WYLIE College you are tasked with
developing a new student registration system. The college would like a new
client /server system to replace its much older system developed around
mainframe technology. The new system will allow students to register for a course
and view report cards from PC’s attached to the campus LAN. Professors will be
able to access the system to signup to teach courses as well as record grades.
Due to decrease in Federal Funding, the college cannot afford to replace

the entire system at once. The college will keep the existing course catalog
database where all course information is maintained. This database is an “Ingress”
Relational Database running on “DECVAX”. Fortunately the college has invested in
an open SQL interface that allows access to this database from College’s UNIX
servers. The legacy system performance is rather poor, so the new system must
ensure that access to data on the legacy system occurs in a timely manner. The
new system will access course information from the legacy database but will not
update it. The registrar’s office will continue to maintain course information through
another system.
At the beginning of each semester students may request a course catalog

containing a list of courses offering for the semester. Information about each
course, such as Professor, Department, and pre-requisites will be included to help
students make informed decisions.
The new system will allow students to select four course offerings for the
coming semester. In addition, each student will indicate two alternative choices in
case the student cannot be assigned to a primary selection. Course offerings will
have a maximum of ten students and a minimum of three students. A course
offering fewer than three students will be cancelled. For each semester, there is a
period of time that students can change their schedule. Students must be able to
access the system during this time to add or drop courses. Once the registration
process is completed for a student, the registration system sends information to
the billing system so the student can be billed for the semester. If a course fills up
during the actual registration process, the student must be notified of the change
before submitting the schedule for processing.
At the end of semester, the student will be able to access the system to give
an electronic report card. Since students grades are sensitive information, the
system must employee extra security measures to prevent unauthorized access.
Professors must be able to access the online system to indicate which

courses they will be teaching. They will also need to see which student signed up
for the course offerings. In addition, the professors will be able to record the grades
for the students in each class.
135
Course Registration System Glossary
Introduction
This document is used to define terminology specific to the problem domain,
explaining terms, which may be unfamiliar to the reader of the use-case
descriptions or the other project documents. Often, this document can be used as
an informal data dictionary, capturing data definitions so that use-case descriptions
and other project documents can focus on what the system must do with the
information.
Definitions
The glossary contains the working definitions for the key concepts in the
Course Registration System.
Course
A Class offered by the university
Course Offering
A specific delivery of the course for a specific semester – you could run the
same course parallel sessions in the semester. Includes the days of the week and
times it is offered.
Course Catalog
The unabridged catalog of all courses offered by the university.
Faculty
All the professors teaching at the university.
Finance System
The system used for processing billing information.
Grade
The evaluation of a particular student for a particular course offering.
Professor
A person teaching classes at the university.
136
Report Card
All the grades for all courses taken by a student in a given semester.
Roster
All the students enrolled in a particular course offering.
Student
A person enrolled in classes at the university,
Schedule
The courses a student has selected for the current semester.
3. Course Registration System Supplementary Specification
Objectives
The purpose of this document is to define requirements of the Course

Registration System. This Supplementary Specification lists the requirements that
are not readily captured in the use cases of the usecase model. The
Supplementary Specifications and the use-case model together capture a
complete set of requirements of the system.
Scope
This Supplementary Specification applies to the Course Registration System,

which will be developed by the OOAD students.
This Specification defines the non-functional requirements of the system; such
as reliability, usability, performance, and supportability, as well as functional
requirements that are common across a number of use cases. (The functional
requirements are defined in the Use Case Specifications).
References
None
Functionality
Multiple users must be able to perform their work concurrently.
137
If a course offering becomes full while a student is building a schedule including
that offering, the student must be notified.
Usability
The desktop user-interface shall be Windows 95/98 compliant.
Reliability
The system shall be available 24 hours a day 7 days a week, with no more than
10% down time.
Performance
1. The system shall support up to 2000 simultaneous users against the central
database at any given time and up to 500 simultaneous users against the local
servers at any one time.
2. The system shall provide access to the legacy course catalog database with
no more than 10 second latency.
Note: Risk based projects have found that the legacy course catalog database
cannot meet our performance needs without some creative use of mid-tier
processing power.
3. The system must be able to complete 80% of all transactions within
2minutes.
Supportability
None.
Security
The system must prevent students from changing any schedules other than
their own, and professors from modifying assigned course offerings for other
professors.
4. Finding the actors and use cases from the course registration system
4.1 Actors
4.1.1 Student
4.1.2 Professor
4.1.3 Registrar
4.1.4 Course catalog
4.1.5 Billing system
138
4.2 Use cases
4.2.1 View report card

4.2.2 Register for courses
4.2.3 Select courses to teach
4.2.4 Submit grades
4.2.5 Maintain professor information
4.2.6 Maintain student information
4.2.7 Close registration
4.2.8 Login
COURSE REGISTRATION SYSTEM USE CASE MODEL MAIN

DIAGRAM
View Report Card
student Register for courses
Course
Login Catalog
Select courses to teach
Professor
Submit Grades
Maintain Professor
Information
Registrar
Maintain Student Information
Close Registration
Billing System
139
Brief Description of use cases :
1. Close Registration
2. Login
3. Maintain Professor Information
4. Maintain Student Information
5. Register for courses
6. Select courses to teach
7. Submit Grades
8. View Report Card
1. Close Registration
Brief Description
This use case allows a Registrar to close the registration process. Course
offerings that do not have enough students are cancelled. Course offerings must
have a minimum of three students in them. The billing system is notified for each
student in each course offering that is not cancelled, so the student can be billed
for the course offering.
Flow of Events
Basic Flow
This use case starts when the Registrar requests that the system close
registration.
1. The system checks to see if registration is in progress. If it is, then a message

is displayed to the Registrar, and the use case terminates. The Close Registration
processing cannot be performed if registration is in progress.
2. For each course offering, the system checks if a professor has signed up to
teach the course offering and at least three students have registered. If so, the
system commits the course offering for each schedule that contains it.
3. For each schedule, the system “levels” the schedule: if the schedule does not
have the maximum number of primary courses selected, the system attempts to
select alternates from the schedule’s list of alternates. The first available course
140
offerings will be selected. If no alternates are available, then no substitution will be
made.
4. For each course offering, the system closes all course offerings. If the course
offerings do not have at least three students at this point (some may have been
added as a result of leveling), then the system cancels the course offering. The
system cancels the course offering for each schedule that contains it.
5. The system calculates the tuition owed by each student for his current
semester schedule and sends a transaction to the Billing System. The Billing
System will send the bill to the students, which will include a copy of their final
schedule.
Alternative Flows
No Professor for the Course Offering
If, in the Basic Flow, there is no professor signed up to teach the course
offering, the system will cancel the course offering. The system cancels the course
offering for each schedule that contains it.
Billing System Unavailable
If the system is unable to communicate with the Billing System, the system will
attempt to re-send the request after a specified period. The system will continue to
attempt to re-send until the Billing System becomes available.
Special Requirements
None.
Pre-Conditions
The Registrar must be logged onto the system in order for this use case to
begin.
Post-Conditions
If the use case was successful, registration is now closed. If not, the system
state remains unchanged.
141
Extension Points
None.
6. ACTIVITY DIAGRAM [ CLOSE REGISTRATION ]
Note:
Rule 1: Each use case should draw one activity diagram.

Rule 2: We can’t draw the activity diagram for all use cases. So, you should
consider important use case from the given problem and draw the activity diagram
(i.e., close registration)
[ Registration in progress ]
Display Image
[ No. of students < 3;Professor not to signed ]

Cancel Course
[ No. of students >= 3 and Professor signed
Commit
Course
Create
Schedule
Send list to
Billing System
142
7. Identifying the Classes
7.1.1 Course Form

7.1.2 Billing System
7.1.3 Close Registration Form
7.1.4 Course Catalog System
7.1.5 Grade Form
7.1.6 Login Form
7.1.7 Professor Profile Form
7.1.8 Report Card Form
7.1.9 Student Information Form
7.2 Control Classes
7.2.1 Close Registration Controller

7.2.2 Login Controller
7.2.3 Professor Profile Controller
7.2.4 Record Grade Controller
7.2.5 Registration Controller
7.2.6 Report Card Controller
7.2.7 Select Courses to teach controller
7.2.8 Select information controller
7.3 Entity Classes
7.3.1 Course Catalog

7.3.2 Course Offering
7.3.3 Professor
7.3.4 Schedule
7.3.5 Student (course)
143
8. CLASS DIAGRAM [ REGISTER FOR COURSES ]
<<entity>>
Registration User
<<entity>> <<entity>> <<entity>>

Professor Student Classification
1..* 1
1
+Teacher 3..10
+0..4 0..4
<<entity>>
Course Offering Fulltime Part time
144
9. INTERACTION DIAGRAM [ SELECT COURSES TO TEACH ]
: Professor : professor course options : Add course offering : Professor course : course : Course Offering
1:Extra password manager
2:Verify password
3:Enter Semester
4:Add an offering
5:Display
6:Select math 101
7:Get offering
8:Get offering
9:Get offering
10:Display offering
11:Select offering 12:Set prof(prof,course,course offer)

14:Add professor
13:Set prof(prof,course offer)
145
10. STATE CHART DIAGRAM
Initialization
entry/
add student/set count=0 Closed

[count=10]
Open
Cancel
entry/
cancel
course restore detail

Cancelled
add student [count<10]
146
11. COMPONENT DIAGRAM
Billing
Registra
tion
Course
Catalog
12. DEPLOYMENT DIAGRAM
147
Course Catalog
Student PC System
Registration
Server
Billing System Printer
148

Unified Modeling Language (UML) Lab Manual: Class/Branch Iii B.Tech, Ii-Sem It ACADEMIC YEAR: 2009-10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unified Modeling Language (UML) Lab Manual: Class/Branch Iii B.Tech, Ii-Sem It ACADEMIC YEAR: 2009-10

Uploaded by

Copyright:

Available Formats

.

Unified Modeling Language

SNO TITLE PAGE NO

2 A Point- of – Sale ( POS) System 17-22

3 Online Bookshop Example 23-29

4 A Simulated Company 30-41

5 A Multi- Threaded Airport Simulation 42-48

6 An Online Auction 49-58

7 A Content Management System 59-66

8 Bank Application 67-73

9 ATM Application 74-81

10 Railway Reservation System 82-88

11 : Unified Library Application 89-98

12 Inventory Control System 99-106

13 QUIZ Application 107-114

14 More diagrams for LIS 115-121

15 Pay Roll System 122-134

16 Course Registration System 135-148

General study of UML

The heart of object-oriented problem solving is the construction of a

 Use case diagrams

Why is UML important?

Writing software is not unlike constructing a building. The more

Use case diagrams

Use case diagrams describe what a system does from the

Use case diagrams are closely connected to scenarios. A scenario is an

"A patient calls the clinic to make an appointment for a yearly

A use case is a summary of scenarios for a single task or goal. An

Use case diagrams are helpful in three areas.

 determining features (requirements). New use cases often

A Class diagram gives an overview of a system by showing its

The class diagram below models a customer order from a retail

Our class diagram has three kinds of relationships.

 association -- a relationship between instances of the two classes.

A navigability arrow on an association shows which direction the

The multiplicity of an association end is the number of possible

This table gives the most common multiplicities.

Every class diagram has classes, associations, and multiplicities.

Packages and object diagrams

To simplify complex class diagrams, you can group classes into

Object diagrams show instances instead of classes. They are useful

The object diagram below instantiates the class diagram, replacing it by a

Each rectangle in the object diagram corresponds to a single

A sequence diagram is an interaction diagram that details how

Below is a sequence diagram for making a hotel reservation. The

The Reservation window sends a makeReservation() message to a

Each vertical dotted line is a lifeline, representing the time that an

In our diagram, the Hotel issues a self call to determine if a room is

Collaboration diagrams are also interaction diagrams. They convey

The object-role rectangles are labeled with either class or object

Each message in a collaboration diagram has a sequence number.

Objects have behaviors and state. The state of an object depends on

Our example diagram models the login part of an online banking

The action that occurs as a result of an event or condition is

An activity diagram is essentially a fancy flowchart. Activity

For our example, we used the following process.

Activity diagrams can be divided into object swimlanes that

A transition may branch into two or more mutually exclusive

Component and deployment diagrams

A component is a code module. Component diagrams are physical

The following deployment diagram shows the relationships among

The physical hardware is made up of nodes. Each component

Modeling steps for Use case Diagram