Object Oriented Modeling & Design Lab

Laboratory Manual

BE (COMPUTER ENGINEERING)
Semester – VII
410244(D): Object Oriented Modeling And Design

Subject Teacher: - Swati Sucharita Barik

Department of Computer Engineering

Bhivarabai Sawant Institute of Technology and
Research,Wagholi,Pune

Page 1
 Object Oriented Modeling & Design Lab

Any 5 assignments from group 1 and 1 Mini project from group 2 is mandatory.

Group 1 Assignments

Draw state model for telephone line, with various activities.

1

Draw basic class diagrams to identify and describe key concepts like classes,
2 types in your system and their relationships
Draw one or more Use Case diagrams for capturing and representing
3 requirements of the system. Use case diagrams must include template
showing description and steps of the Use Case for various scenarios
Draw one or more Use Case diagrams for capturing and representing
4 requirements of the system. Use case diagrams must include template
showing description and steps of the Use Case for various scenarios
Draw activity diagrams to display either business flows or like flow charts
5

Draw component diagrams assuming that you will build your system
6 reusing existing components along with a few new ones
Draw deployment diagrams to model the runtime architecture of your
7 system

Page 2
 Object Oriented Modeling & Design Lab

Group-I

1. Draw state model for telephone line, with various activities.

Consider the class for telephone line with following activities and states:
As a start of a call, the telephone line is idle. When the phone receiver is picked from hook, it
gives a dial tone and can accept the dialing of digits.
If after getting dial tone, if the user doesn’t dial number within time interval then time out
occurs and phone line gets idle.
After dialing a number, if the number is invalid then some recorded message is played.
Upon entry of a valid number, the phone system tries to connect a call & routes it to proper
destination.
If the called person answers the phone, the conversation can occur. When called person hangs
up, the phone disconnects and goes to idle state.
Draw the state transition diagram for above description of telephone line.

A state diagram is a graph whose node are state and whose directed arcs are transition between
states which describes sequence caused by event sequences. A state diagram typically models the
common behavior of a class
In this example, the phone line is idle at the start of a call. When the phone is removed from the
hook, it emits a dial tone and can accept the dialling of digits. Upon entry a valid number, the
phone system tries to connect the call and route to the proper destination. The connection can fail
if the number or trunk are busy. If the connection is successful the called phone begins ringing.
When put on hook again, the phone line will go back to idle.

Page 3
 Object Oriented Modeling & Design Lab

2. Draw basic class diagrams to identify and describe key concepts like classes, types in
your system and their relationships

Class diagrams are the main building blocks of object-oriented modeling

Classes are interrelated to each other in specific ways. In particular, relationships in class
diagrams include different types of logical connections. The following are such types of logical
connections that are possible in UML:
Association,Directed Association,Reflexive Association, Multiplicity, Aggregation,
Composition,Inheritance/Generalization,Realization

 Class diagrams are the main building block in object oriented modeling. They are used to
show the different objects in a system, their attributes, their operations, and
the relationships among them.
 The class diagram depicts a static view of an application. It represents the types of objects
residing in the system and the relationships between them.
 A class consists of its objects, and also it may inherit from other classes.
 A class diagram is used to visualize, describe, document various different aspects of the
system, and also construct executable software code.
 It shows the attributes, classes, functions, and relationships to give an overview of the
software system.
 It constitutes class names, attributes, and functions in a separate compartment that helps
in software development.
 Since it is a collection of classes, interfaces, associations, collaborations, and constraints,
it is termed as a structural diagram.

Page 4
 Object Oriented Modeling & Design Lab

3&4. Draw one or more Use Case diagrams for capturing and representing requirements of
the system. Use case diagrams must include template showing description and steps of the
Use Case for various scenarios

 Use Case Diagram captures the system’s functionality and requirements by using actors
and use cases.
 Use Cases model the services, tasks, function that a system needs to perform.
 Use cases represent high-level functionalities and how a user will handle the system.
Usecases are the core concepts of Unified Modelling language modeling.
 A Use Case consists of use cases, persons, or various things that are invoking the features
called as actors and the elements that are responsible for implementing the use cases.
 Use case diagrams capture the dynamic behaviour of a live system. It models how an
external entity interacts with the system to make it work.
 Use case diagrams are responsible for visualizing the external things that interact with the
part of the system.
To draw a use case diagram in UML first one need to analyse the entire system carefully. we
have to find out every single function that is provided by the system. After all the functionalities
of a system are found out, then these functionalities are converted into various use cases which
will be used in the use case diagram.
 A use case is nothing but a core functionality of any working system. After organizing
the use cases, we have to enlist the various actors or things that are going to interact with
the system.
 These actors are responsible for invoking the functionality of a system. Actors can be a
person or a thing. It can also be a private entity of a system. These actors must be relevant
to the functionality or a system they are interacting with.
Page 5
 Object Oriented Modeling & Design Lab

 After the actors and use cases are enlisted, then you have to explore the relationship of a
particular actor with the use case or a system. One must identify the total number of ways
an actor could interact with the system. A single actor can interact with multiple use cases
at the same time, or it can interact with numerous use cases simultaneously.
Following rules must be followed while drawing usecase for any system:
1. The name of an actor or a use case must be meaningful and relevant to the system.
2. Interaction of an actor with the use case must be defined clearly and in an understandable
way.
3. Annotations must be used wherever they are required.
4. If a use case or an actor has multiple relationships, then only significant interactions must
be displayed.

Page 6
Object Oriented Modeling & Design Lab

Page 7
Object Oriented Modeling & Design Lab

Page 8
 Object Oriented Modeling & Design Lab

5. Draw activity diagrams to display either business flows or like flow charts

Here the input parameter is the Requested order, and once the order is accepted, all of the
required information is then filled, payment is also accepted, and then the order is shipped. It
permits order shipment before an invoice is sent or payment is completed.

An activity diagram can be used to portray business processes and workflows. It is used for
modelling business as well as the software. An activity diagram is utilized for the followings:
1. To graphically model the workflow in an easier and understandable way.
2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed within the
system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an application.
7. To represent a high-level view of a distributed or an object-oriented system.
6. Draw component diagrams assuming that you will build your system reusing existing
components along with a few new ones

 UML Component Diagrams are used for modeling large systems into smaller
subsystems which can be easily managed.
 UML Component diagrams are used to represent different components of a system.
 When modeling large object-oriented systems, it is necessary to break down the system into
manageable subsystems.
 A component is a replaceable and executable piece of a system whose implementation details
are hidden.
 A component provides the set of interfaces that a component realizes or implements.
Components also require interfaces to carry out a function.

Page 9
 Object Oriented Modeling & Design Lab

(Component Diagram for Library Management System)

Page 10
 Object Oriented Modeling & Design Lab

7. Draw deployment diagrams to model the runtime architecture of your system.

The deployment diagram visualizes the physical hardware on which the software will be
deployed. It portrays the static deployment view of a system. It involves the nodes and their
relationships. It ascertains how software is deployed on the hardware. It maps the software
architecture created in design to the physical system architecture, where the software will be
executed as a node. Since it involves many nodes, the relationship is shown by utilizing
communication paths.
The main purpose of the deployment diagram is to represent how software is installed on the
hardware component. It depicts in what manner a software interacts with hardware to
perform its execution.
Page 11
 Object Oriented Modeling & Design Lab

The deployment diagram consist of the following notations:

1. A component
2. An artifact
3. An interface
4. A node

Page 12
 Object Oriented Modeling & Design Lab

Deployment Diagram for Online Shopping

Page 13
 Object Oriented Modeling & Design Lab

Group-II (Any one)

8. Mini Project: Draw all UML diagrams for your project work.

9. Mini Project - Develop a Blockchain based application for health related medical
records Draw following UML Diagrams for Bank Management application
a. Class Diagram b. Object Diagram c. ER Diagram d. Component Diagram

CONTENTS(For Reference of Group-II)

Expt. No Experiment Title

Design ATM System Using Structural & Behavioral UML Diagram.

1

Design Coffee Vending Machine Using Structural & Behavioral UML Diagram.
2

Design College Admission Process Using Structural & Behavioral UML

3 Diagram.
Design Library Management System Using Structural & Behavioral UML
4 Diagram.
Design Railway Reservation System Using Structural & Behavioral UML
5 Diagram.
Design Online Shopping System Using Structural & Behavioral UML Diagram.
6

Design Hotel Management system using Structural and Behavioral UML

7 diagram
Design Hospital Management System Using Structural & Behavioral UML
8 Diagram.
Design University Result Management System Using Structural & Behavioral
9 UML Diagram.

Page 14
 Object Oriented Modeling & Design Lab

Experiment No.1
TITLE: Design ATM System Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:
Problem Statement:-
Design the software to support a computerized banking network including both human
Cashier and ATM. Each bank provides its own computer to maintain its customer accounts and
process transaction organize them, cashier station are owned by individual banks and
communication directly with their bank controller, then cashier enters account and transact data.
ATM communicates with central computer with appropriate bank. ATM accept cash card,
interact with user, communicate with central computer to carry out the transaction
process and print receipt.
Analysis
ATM performs many more functions one of them is withdrawal. The customer will interact to
ATM machine with ATM card. ATM will check customers account if authentication is correct
then ATM displays the withdrawal option. After withdraw process completes, customer can
collect money printed receipt from cash dispenser and ATM machine will reject the card.
Theory
To develop any software we can follow some sequential approach which begins from
that system level and progresses through analysis, design, coding, testing and the
maintenance when this is modeled with following activities as follows.
Software engineering and information gathering
With ATM system, different facilities are provided that is transaction.
Transaction is Maximum 3 times per day. Different people (customer) interacting with ATM for
the services provided as well as facilities .When organization decide to develop the system
it begins with requirement tracing of system to be develop. Requirement gathering is done at

Page 15
 Object Oriented Modeling & Design Lab

the level of system.

Facility users
They are customer, staff i.e. for providing facilities for customer. If customer want
to Withdrawal money then machine ask for ATM card, according to which amount is provided
by ATM.
Facilities are provided to user as follows:
1) They can withdrawal amount from their account.
2) There is restriction for withdrawal is dependent on capacity of ATM
3) There is restriction for withdrawal amount 3 times per day.
4) They can carry cash is Rs. 100, 500, 1000, etc
5) After withdrawing cash customer get their balance sheet from machine.
Disadvantages of Existing System
1) If customer forget this pincode, then it is not possible to withdraw cash.
2) There is a restriction on withdrawal cash.
Advantages of proposed system
1) No need to maintain catalog.
2) Paper work is reduced.
3) All calculation are performed by software.
4) It is easy to withdrawing money.
Requirement Analysis
The next stage after requirement gathering process is software requirement analysis. Here the
software engineer or analysis decides about the nature of program developed. There are
different analysis tools used.
a) Product Request
1) The machine i.e. ATM machine have to maintain amount for the ATM which are given to
customer.
2)When customer is withdraw cash, the machine should make entry in databases so that
time is reduced.
 ATM card
 Rs 100 Note
 Rs. 500/ Rs. 1000 note.
 Balance sheet.
b) Services
1) Check for ATM id.
2) Provided cash.
3) Provided balance sheet.
4) Setting pointer.
c) Design
Software design covers data design, architectural design and procedural
Page 16
 Object Oriented Modeling & Design Lab

design with SRS i.e. Requirements of customer i.e. Transformed into software design.
Design software has to be backed by system documentation aspect of software engineer design
focus on quality. The design information is
Account ( acc_no, balance, cname)
ATM (ATM_card, pin_no, expiry, acc_no)
Code (pin_no, ATM_card, valid card)
Money (ten, fifty, hundred, five hundred)

Table Primary key Foreign key

ATM Pin_code Acc_no

Account Acc_no

Code Pin_code

d) Coding
Programming or coding is next phase when system design is complete from design to
code development. Now choose VB 6.0 as front end because following features:
1) Easy to use.
2) Implementation is easy.
3) Updation can be easily done.
4) Cost designing software using VB is less.
5) User friendly.
Choose back end as MS-access with following features
1) Can store large amount data
2) Table size is 64KB which is much more store.
3) Access gives user friendly to access data easily and conveniently.

e) Testing
After coding, testing of code generated status various system testing methods from unit testing to
integration are used to in this phase. Testing is used to check errors, bugs or required output.
f) Maintenance / Support
It is last phase of life cycle when system is implemented at user wants changes are required as
new platform with OS may peripheral devices are changes.
Correction: -
In this uncover logical errors are corrected. Eg. Book_id datatype number but customer use
character every time, so software gives error. This error can be corrected by changing datatype to
Page 17
 Object Oriented Modeling & Design Lab

number.
Adaptation: - In this modification in software is done to according changes with
external environment.
Enhancement: - Changes because of the additional functionality requested by the customer.
Prevention: - Suppose after delivery of software customer recognize that response time of
software is slow. He tells to developer to make changes in software so developers
suggest recognizing software than changes.
ALGORITHM / PROCEDURE / FLOWCHART:
1. Open Rational Rose Enterprise Edition
2. Select Appropriate Language for Mapping of Design

3. Select Appropriate View for New Diagram

5. Browse The Diagram To Draw From Menu.

Page 18
 Object Oriented Modeling & Design Lab

5. Select Appropriate Diagram from the View

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

Page 19
 Object Oriented Modeling & Design Lab

8. Save Diagram at Selected Location with .Mdl Extension

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Page 20
 Object Oriented Modeling & Design Lab

Figure 1: Sequence Diagram for ATM System

CONCLUSION / RESULT:
In this Experiment, we have Design ATM System Using Structural & Behavioral UML Diagram.

Page 21
 Object Oriented Modeling & Design Lab

Experiment No.2
TITLE: Design Coffee Vending Machine Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:
Objective
Objective of the system is to prepare a coffee vending machine for commercial purpose. The
system will able to prepare coffee by processing all its required ingredients. User will be
provided with sophisticated & easy to use user interface.
Introduction
There are many different types of coffee makers using a number of different brewing principles,
in the most common devices, coffee grounds are placed in a paper or metal filter inside a funnel,
which is set over a glass or ceramic coffee pot, a cooking pot in the kettle family. Cold water is
poured into a separate chamber, which is then heated up to the boiling point, and directed into
the funnel.

Coffee Machine Design

 Cash Box: Knows amount of money put in; Gives change; Knows price of coffee; Turns Front
Panel on and off.
 Front Panel: Captures selection; knows what to mix in each; instructs Mixer what to mix.
 Mixer: Knows how to talk to the dispensers.
 Dispensers (cup-, coffee powder-, sugar-, creamer-, water-): Knows how to dispense a fixed
amount; Knows when it is empty.

Page 22
 Object Oriented Modeling & Design Lab

Figure 1: Coffee Vending Machine

Vending ingredients are all the ingredients which can be used in vending machines. This
includes 73mm in Cup products, 76mm Kenco in Cup drinks, coffee beans, tea bags, milk
products, sugar products and also includes cups, spoons and more. Most of these products can be
bought at a reduced cost in bulk packs.
Features
 Small Carbon Foot Print
 Energy Saving Advanced Power Management System
 Comprehensive Drink Range
 Simple User Interface
 One Touch Servicing
Working
Coffee vending machines are quite simple and basic. The way they work is not too different to
how a table-top coffee machine or even a drip coffee machine operates. If you think about it,
making coffee is simply adding together coffee beans or grounds to hot water and mixing with
milk and sugar, and that's exactly what a hot drinks vending machine does.

Functions:-
 Add Heat:-
To heat the coffee we have three options. We could use a heating element where the
water is gravity fed into a tubular heating element, external to the water reservoir, and boiled out.
Secondly, we could use a submersible heating element placed inside of the water reservoir to

Page 23
 Object Oriented Modeling & Design Lab

heat all of the water at once. Thirdly we could use an external hot plate to heat one or multiple
walls of the water reservoir and thus heat the water through surface convection.

 Direct Water:-

The fluids could be directed from the water reservoir to their final destination via tubing, gravity
feed, and/or a pump.
 Contain Water/Coffee:-
To contain the water and coffee we could use one reservoir, two reservoirs or a funnel. If one
reservoir was used for both the water and coffee container, our design would be a percolating or
French press coffee maker.

 Reduce Noise:-
To reduce the overall noise we considered two options: noise dampening material and internal
brew mechanism. To lessen the noise produced by our designs we could fill or cover the outer
shell of with a noise dampening material. We could also keep the brew mechanism, whether it is
drip or a spout, internal so its noise is damped by the outer casing.

 Maintenance

When it comes to the ways in which coffee vending machines work, it's not all about the coffee,
it's also about the upkeep and maintenance of the machine. Usually, vending machines are leased
from a supplier, and it's they who will ensure the machine keeps working as it should. With
regular visits, suppliers should empty the cash drawer, reconcile the proceeds against sales,
empty the waste grounds, refill ingredients and cups, and generally undertake any work to both
the interior and exterior to keep everything running smoothly, such as ensuring there's no buildup
of dirt around the exterior buttons that could cause them to stick, and making sure nothing is
blocking the internal sensors that could prevent some ingredients from being added to the mixing
chamber.
 Result
Based on the system requirements specification coffee vending machine has been analyzed &
designed.
ALGORITHM / PROCEDURE / FLOWCHART:
1. Open Rational Rose Enterprise Edition

2. Select Appropriate Language for Mapping of Design

Page 24
 Object Oriented Modeling & Design Lab

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

5. Select Appropriate Diagram from the View

Page 25
 Object Oriented Modeling & Design Lab

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

8. Save Diagram at Selected Location with .Mdl Extension

Page 26
 Object Oriented Modeling & Design Lab

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Page 27
 Object Oriented Modeling & Design Lab

Figure 1: Class Diagram for Coffee Vending machine

CONCLUSION / RESULT:
In this Experiment, we have Designed Coffee Vending Machine Using Structural & Behavioral
UML Diagram.

Page 28
 Object Oriented Modeling & Design Lab

Experiment No.3
TITLE: Design College Admission Process Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

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 courses and view report cards from personal computers attached
to the campus LAN as well as over the Internet. Professors will be able to access the system to
sign up to teach courses as well as record grades.
Due to a 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 Ingres relational database running on a DEC
VAX. 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 the 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 catalogue containing a
list of course offerings for the semester. Information about each course, such as professor,
department, and prerequisites, 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.

Page 29
 Object Oriented Modeling & Design Lab

Course offerings will have a maximum of ten students and a minimum of three
students A course offering with fewer than three students will be canceled. 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 the semester, the student will be able to access the system
to view an electronic report card. Since student grades are sensitive information, the
system must employ extra Security measures to prevent unauthorized access. Professors must
be able to access the on-line system to indicate which courses they will be teaching.
They will also need to see which students signed up for their course offerings. In
addition, the professors will be able to record the grades for the students in each class.

Page 30
 Object Oriented Modeling & Design Lab

1. Objective
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 use-case model. The Supplementary Specifications and the use-case model together
capture a complete set of requirements on the system.

2. Scope
This Supplementary Specification applies to the Course Registration System, which
will be developed by the OOA and OOD 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.
3. Functionality
Multiple users’ must be able to perform their work concurrently.
If a course offering becomes full while a student is building a schedule including that offering,
the student must be notified
4. Usability
The desktop user-interface shall be Windows NT and Windows2000 compliant.
5. Reliability
The system shall be available 24 hours a day 7 days a week, with no more than 10% down time.
6. 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 a 10
second late
Note: Risk-based prototypes 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 2 minutes.
7. Security
1.The system must prevent students from changing any schedules other than their own,
and Professors from modifying assigned course offerings for other professors.
2. Only Professors can enter grades for students.
3. Only the Registrar is allowed to change any student information
8. Design Constraints
The system shall integrate with an existing legacy system, the Course Catalog System, which is
an RDBMS Database.
9. Course Registration System Use-Case Model Main Diagram
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

Page 31
 Object Oriented Modeling & Design Lab

cancelled, so the student can be billed for the course offering.

10.2 Flow of Events
10.2.1 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 alternate course 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.
10.2.2 Alternative Flows
10.2.2.1No 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.
10.2.2.2 Billing System Unavailable
If the system is unable to c communicate with the billing system, the system till attempt to re-
send the request after a specified period. T(the system will continue to attempt to resend until the
billing system is available
10.3Pre-Conditions
The Registrar must be logged onto the system in order for this use case to begin.
10.4 Post-Conditions
If the use case was successful, registration is now closed. If not, the system state remains
unchanged.
11. Login
11.1Brief Description
This use case describes how a user logs into the Course Registration System.
11.2Flow of Events
11.2.1 Basic Flow

Page 32
 Object Oriented Modeling & Design Lab

This use case starts when the actor wishes to log into the Course Registration System.
1. The system requests that the actor enter his/her name and password.
2. The actor enters his/her name and password.
3.The system validates the entered name and password and logs the actor into the
system.
11.2.2 Alternative Flows
11.2.2.1Invalid Name/Password
If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an
error message. The actor can choose to either return to the beginning of the Basic Flow or cancel
the login, at which point the use case ends.
11.3Post-Conditions
If the use case was successful, the actor is now logged into the system. If not, the system state is
Unchanged.
12. Maintain Professor Information
12.1Brief Description
This use case allows the Registrar to maintain professor information in the registration system.
This includes adding, modifying, and deleting professors from the system.
12.2Flow of Events
12.2.1 Basic Flow
This use case starts when the Registrar wishes to add, change, and/or delete professor
information in the system.
1.The system requests that the Registrar specify the function he/she would like to perform
(either Add a Professor, Update a Professor, or Delete a Professor)
2.Once the Registrar provides the requested information, one of the subflows is executed.
If the Registrar selected “Add a Professor”, the Add a Professor subflow is executed. If the
Registrar selected “Update a Professor”, the Update a Professor subflow is executed. If
the Registrar selected “Delete a Professor”, the Delete a Professor subflow is executed.
12.2.1.1 Add a Professor
The system requests that the Registrar enter the professor information. This includes:
-name
-date of birth
-social security number
-status
- Department
1.Once the Registrar provides the requested information, the system generates and
assigns a unique id number to the professor. The professor is added to the system.
2. The system provides the Registrar with the new professor id.
12.2.1.2 Update a Professor
1. The system requests that the Registrar enter the professor id.
2. The Registrar enters the professor id. The system retrieves and displays the professor

Page 33
 Object Oriented Modeling & Design Lab

information.
3. The Registrar makes the desired changes to the professor information. This includes any of the
information specified in the Add a Professor sub-flow.
4.Once the Registrar updates the necessary information, the system updates the professor
record.
12.2.1.3 Delete a Professor
1. The system requests that the Registrar enter the professor id
2. The Registrar enters the professor id. The system retrieves and displays the professor
information.
3. The system prompts the Registrar to confirm the deletion of the professor.
4. The Registrar verifies the details.
13. Maintain Student Information
13.1Brief Description
This use case allows the Registrar to maintain student information in the registration
system. This includes adding, modifying, and deleting Students from the system.
13.2 Flow of Events
13.2.1 Basic Flow
This use case starts when the Registrar wishes to add, change, and/or delete student information
in the system.
1.The system requests that the Registrar specify the function he/she would like to
perform (either Add a Student, Update a Student, or Delete a Student)
2.Once the Registrar provides the requested information, one of the subflows is executed.
If the Registrar selected “Add a Student”, the Add a Student subflow is executed. If the
Registrar selected “Update a Student”, the Update a Student subflow is executed. If the
Registrar selected “Delete a Student”, the Delete a Student subflow is executed.
13.2.1.1Add a Student
1. The system requests that the Registrar enter the student information. This includes:
-name
-date of birth
-social security number
-status
- Graduation date
2.Once the Registrar provides the requested information, the system generates and assigns
a unique id number to the student. The student is added to the system.
3. The system provides the Registrar with the new student id.
13.2.1.2 Update a Student
1. The system requests that the Registrar enter the student id.
2. The Registrar enters the student id. The system retrieves and displays the student
information.
3. The Registrar makes the desired changes to the student information. This includes any of the

Page 34
 Object Oriented Modeling & Design Lab

information specified in the Add a Student sub-flow.

4. Once the Registrar updates the necessary information, the system updates the student
information.
13.2.1.3 Delete a Student
1. The system requests that the Registrar enter the student id
2. The Registrar enters the student id.The system retrieves and displays the student information.
3. The system prompts the Registrar to confirm the deletion of the student.
4. The Registrar verifies the deletion.
5. The system deletes the student from the system.
13.2.2 Alternative Flows
13.2.2.1 Student Not Found
If, in the Update a Student or Delete a Student sub-flows, a student with the specified id number
does not exist, the system displays an error message. The Registrar can then enter a different id
number or cancel the operation, at which point the use case ends.
13.2.2.2 Delete Cancelled
If, in the Delete a Student sub-flow, the Registrar decides not to delete the student, the delete is
cancelled and the Basic Flow is re-started at the beginning.
13.3Pre-Conditions
The Registrar must be logged onto the system before this use case begins.
13.4 Post-Conditions
If the use case was successful, the student information is added, updated, or deleted
from the system. Otherwise, the system state is unchanged.
14. Register for Courses
14.1Brief Description
This use case allows a Student to register for course offerings in the current semester.
The Student can also update or delete course selections if changes are made within the
add/drop period at the beginning of the semester. The Course Catalog System provides a
list of all the course offerings for the current semester.
14.2 Flow of Events
14.2.1 Basic Flow
This use case starts when as Student wishes to register for course offerings, or to change his/her
existing course schedule.
1.The system requests that the Student specify the function he/she would like to perform
(either Create a Schedule, Update a Schedule, or Delete a Schedule).
2. Once the Student provides the requested information, one of the subflows is executed. If the
Registrar selected “Create a Schedule”, the Create a Schedule subflow is executed. If the
Registrar selected “Update a Schedule”, the Update a Schedule subflow is executed. If
the Registrar selected “Delete a Schedule”, the Delete a Schedule subflow is executed.
14.2.1.1 Create a Schedule
1.The system retrieves a list of available course offerings from the Course Catalog

Page 35
 Object Oriented Modeling & Design Lab

System and displays the list to the Student.

2. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of
available offerings.
3.Once the student has made his/her selections, the system creates a schedule for the
Student containing the selected course offerings.
4. The Submit Schedule subflow is executed.
14.2.1.2Update a Schedule
1.The system retrieves and displays the Student’s current schedule (e.g., the schedule for
the current semester.
2.The system retrieves a list of available course offerings from the Course Catalog
System and displays the list to the Student.
3. The Student may update the course selections on the current selection by deleting and adding
new course offerings. The Student selects the course offerings to add from the list of available
course offerings. The Student also selects any course offerings to delete from the existing
schedule.
4. Once the student has made his/her selections, the system updates the schedule for the Student
using the selected course offerings.
5. The Submit Schedule subflow is executed.
14.2.1.3 Delete a Schedule
1.The system retrieves and displays the Student’s current schedule (e.g., the schedule for
the current semester.
2. The system prompts the Student to confirm the deletion of the schedule.
3. The Student verifies the deletion.
4. The system deletes the Schedule.If the schedule contains “enrolled in” course offerings, the
Student must be removed from the course offering.
14.2.1.4 Submit Schedule
For each selected course offering on the schedule not already marked as “enrolled in”,
the system verifies that the Student has the necessary prerequisites, that the course
offering is open, and that there are no schedule conflicts. The system then adds the
Student to the selected course offering. The course offering is marked as “enrolled in” in the
schedule. The schedule is saved in the system.
14.2.2 Alternative Flows
14.2.2.1 Save a Schedule
At any point, the Student may choose to save a schedule rather than submitting it. If this occurs,
the Submit Schedule step is replaced with the following: The course offerings not marked as
“enrolled in” are marked as “selected” in the schedule. The schedule is saved in the system.
14.2.2.2 Unfulfilled Prerequisites, Course Full, or Schedule Conflicts
If, in the Submit Schedule sub-flow, the system determines that the Student has not satisfied the
necessary prerequisites, or that the selected course offering is full, or that there are
schedule conflicts, an error message is displayed. The Student can either select a different

Page 36
 Object Oriented Modeling & Design Lab

course offering and the use case continues, save the schedule, as is (see Save a Schedule
subflow, or cancel the operation, at which points the Basic Flow is re-started at the beginning.
14.2.2.3 No Schedule Found
If, in the Update a Schedule or Delete a Schedule sub-flows, the system is unable to retrieve the
Student’s schedule, an error message is displayed. The Student acknowledges the error, and the
Basic Flow is re-started at the beginning.
14.2.2.4Course Catalog System Unavailable
If the system is unable to communicate with the Course Catalog System, The system will display
an error message to the Student. The student acknowledges an error message.
14.2.2.5Course Registration Closed
If, when the use case starts, it is determined that registration for the current semester has
been closed then a message is displayed to the Student and the use case terminates. Students
cannot register for course offerings after registration for the current semester has been closed.
14.2.2.6 Delete Cancelled
If, in the Delete A Schedule sub-flow, the Student decides not to delete the schedule, the delete is
cancelled, and the Basic Flow is re-started at the beginning.
14.3 Pre-Conditions
The Student must be logged onto the system before this use case begins.
14.4Post-Conditions
If the use case was successful, the student schedule is created, updated, or deleted. Otherwise,
the system state is unchanged.
15. Select Courses to Teach
15.1Brief Description
This use case allows a Professor to select the course offerings from the course catalog
for the courses that he/she is eligible for and wishes to teach in the upcoming semester.
15.2 Flow of Events
15.2.1 Basic Flow
This use case starts when a Professor wishes to sign up to teach some course offerings
for the upcoming semester.
1. The system retrieves and displays the list of course offerings the professor is eligible to teach
for the current semester. The system also retrieves and displays the list of courses the professor
has previously selected to teach.
2.The professor selects and/or de-selects the course offerings that he/she wishes to teach
for the upcoming semester.
3. The system removes the professor from teaching the de-selected course offerings.
4.The system verifies that the selected offerings do not conflict (i.e., have the same dates
and times) with each other or any course offerings that the professor has previously signed
up to teach. If there is no conflict, the system updates the course offering information for each
offering the professor selects (i.e., records the professor as the instructor for the course offering).
15.2.2 Alternative Flows

Page 37
 Object Oriented Modeling & Design Lab

15.2.2.1 No Course Offerings Available

If, in the Basic Flow, the professor is not eligible to teach any course offerings in the upcoming
semester, the system will display an error message. The professor acknowledges the message
and the use case ends.
15.2.2.2 Schedule Conflict
If the systems find a schedule conflict when trying to establish the course offerings the Professor
should take, the system will display an error message indicating that a schedule conflict
has occurred. The system will also indicate which are the conflicting courses. The
Professor can either resolve the schedule conflict (i.e., by canceling his selection to teach
one of the course offerings), or cancel the operation, in which case, any selections will
be lost, and the use case ends.
15.2.2.3 Course Catalog System Unavailable
If the system is unable to communicate with the Course Catalog System, the system will display
an error message to the Student. The Student acknowledges the error message, and the use case
terminates.
15.2.2.4Course Registration Closed
If, when the use case starts, it is determined that registration for the current semester has
been closed a message is displayed to the Professor and the use case terminates.
Professors cannot change the course offerings they teach after registration for the current
semester has been closed. If a professor change is needed after registration has been closed, it is
handled outside the scope of this system.
15.3Pre-Conditions
The Professor must be logged onto the system before this use case begins.
15.4Post-Conditions
If the use case was successful, the course offerings a Professor is scheduled to teach have been
updated. Otherwise, the system state is unchanged.
16. Submit Grades
16.1Brief Description
This use case allows a Professor to submit student grades for one or more classes completed in
the previous semester.
16.2Flow of Events
16.2.1 Basic Flow
This use case starts when a Professor wishes to submit student grades for one or more
classes completed in the previous semester.
1.The system displays a list of course offerings the Professor taught in the previous
semester.
2. The Professor selects a course offering.
3. The system retrieves a list of all students who were registered for the course offering. The
system displays each student and any grade that was previously assigned for the offering.
4.For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The

Page 38
 Object Oriented Modeling & Design Lab

system records the student’s grade for the course offering. If the Professor wishes to skip a
particular student, the grade information can be left blank and filled in at a later time. The
Professor may also change the grade for a student by entering a new grade.
16.2.2 Alternative Flows
16.2.2.1 No Course Offerings taught if, in the Basic Flow, the Professor did not teach any course
offerings in the previous semester, the system will display an error message. The Professor
acknowledges the message, and the use case ends.
16.3Pre-Conditions
The Professor must be logged onto the system before this use case begins.
16.4Post-Conditions
If the use case was successful, student grades for a course offering are updated. Otherwise, the
system state is unchanged.
17. View Report Card
17.1Brief Description
This use case allows a Student to view his/her report card for the previously completed semester.
17.2 Flow of Events
17.2.1 Basic Flow
This use case starts when a Student wishes to view his/her report card for the previously
completed semester.
1.The system retrieves and displays the grade information for each of the course offerings
the Student completed during the previous semester.
2.When the Student indicates that he/she is done viewing the grades, the use case
terminates.
17.2.2 Alternative Flows
17.2.2.1No Grade Information Available
If, in the Basic Flow, the system cannot find any grade information from the previous semester
for the Student, a message is displayed. Once the Student acknowledges the message, the use
case terminates.
17.3 Pre-Conditions
The Student must be logged onto the system before this use case begins.
17.4 Post-Conditions
The system state is unchanged by this use case.

Page 39
 Object Oriented Modeling & Design Lab

ALGORITHM / PROCEDURE / FLOWCHART:

1. Open Rational Rose Enterprise Edition

2. Select Appropriate Language for Mapping of Design

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

Page 40
 Object Oriented Modeling & Design Lab

5. Select Appropriate Diagram from the View

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

8. Save Diagram at Selected Location with .Mdl Extension

Page 41
 Object Oriented Modeling & Design Lab

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Figure 1: Use case Diagram for College Admission System.

CONCLUSION / RESULT:
In this Experiment, we have Design College Admission Process Using Structural & Behavioral
UML Diagram.

Page 42
 Object Oriented Modeling & Design Lab

Experiment No.4
TITLE: Design Library Management System Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

1. Purpose of System
In this system Library management system there is different facility provided that is books,
newspapers, Magazines, questions paper and journals. Different people interacting with library
are services provided as well as facilities user diagram gives brief idea about functioning.

2. Benefits to the End User

1. They are student and staff member’s facilities provided by the system.
2. If book require is not available be suggest another reference books for only reading in
library.
3. Facilities are provided to staff members are similar to those provided to students. There are

3. Disadvantages of Existing System

1. Time required is very large because of manual system.

2. It is get more complicated due to paper work and more tasks.
3. Need to maintain catalogue.
4. Paper work extended many transition token.
5. Less secure.
6. All Functions was not performed by Software.

Page 43
 Object Oriented Modeling & Design Lab

4. System Specifications

Basic objective is to extends their reach to geographically scattered Students, reducing time
in activities, centralized data handling and paperless issuing books, with Reduced manpower,
cost cutting, operational efficiency

5. Functional Requirements

Access library database, issue book, submit book, take fine, search for book, Maintain
library database, display list of all available books.

6. Proposed System

Computerized library system proposes maintaining records of book. This system does not
includes
1. Finding book from rack.
2. Check its condition/finding a page.

Advantages of proposed system

1. Maintain catalog.
2. Paper work is reduced.
3. All calculations are performed by software.
4. Locating book is easy.
5. Burden on staff is reduced.

Disadvantages of Existing System

1. Large paper work is requiring for maintaining each and every record.
2. Calculations of fine also become very tedious.
3. Time required is very large because of manual system for maintaining record.
4.If librarian and student both do not know required book then scanning process
becomes very complicated and time consuming.

7. Services

1. Book issue/renew/return.
2. Calculating time
3. Generation of daily or monthly report

8. Performance Criteria

Page 44
 Object Oriented Modeling & Design Lab

1. While accessing records of particular category, list of books should be displayed

within a second.
2. Entering data to calculated fine should be accurate.

9. Testing / Maintenance

1. Testing

1. After coding, testing of code generated status various system testing methods from unit testing
to integration are used to in this phase.
2. Testing is used to check errors, bugs or required output.
3. After coding, testing of code generated status various system testing methods from unit.
Testing to integration is used in this phase.
4. Testing is used to check error, bugs or required output.

2. Maintenance/Support

It is the last phase of life cycle when system is implemented at user site. Changes are required as
new platform or peripheral devices are changed. Changes may occur due to external
environment.

Correction: - In this uncover logical errors are corrected. E.g. Book I.D. Data type Number but
customer use character every time, so software gives error. This error can be corrected by
changing data type to number.

Adaptation: - In this modification in software is done to according changes with external

environment.

Enhancement: - Changes because of the additional functionality requested by the customer.

Prevention: - Suppose after delivery of software customer recognize that response time of
software is slow. He tells to developer to make changes in software so developers suggest
recognizing software than changes.

10. Result
Based on the system requirements specification Library management system has been
analyzed & designed.

Page 45
 Object Oriented Modeling & Design Lab

ALGORITHM / PROCEDURE / FLOWCHART:

1. Open Rational Rose Enterprise Edition
2. Select Appropriate Language For Mapping of Design

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

5. Select Appropriate Diagram from the View

Page 46
 Object Oriented Modeling & Design Lab

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

8. Save Diagram at Selected Location with .Mdl Extension

Page 47
 Object Oriented Modeling & Design Lab

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Figure 1: Activity Diagram for Library Management System.

CONCLUSION / RESULT:
In this Experiment, we have Design Library Management System Using Structural & Behavioral
UML Diagram.

Page 48
 Object Oriented Modeling & Design Lab

Experiment No.5
TITLE: Design Railway Reservation System Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

Scope of System

The scope of the system is to solve all existing problems in reservation system. The purpose of
Railway Reservation System is a software application which provides the train timing details,
reservation, billing and cancellation. Using these systems Ticket Counter person can perform
operations like finding out the train timings and to know information about PNR status, seats
availability and costs of each ticket, etc.

Services Offered:

Booking of I-tickets, e-tickets and tatkal tickets.

I-ticket - refers to a Railway reservation booked on this website for the consummation of which
a printed Railway ticket on standard Stationery is dispatched by IRCTC to the Customer through
the courier, which constitute the authority to travel on trains.

E-ticket: E-ticket - refers to a Railway reservation booked on this website, for the consummation
of which the customer prints out an Electronic Reservation Slip which, along with one of the
authorized personal identification, constitutes the authority to travel, in lieu of the regular ticket
on standard stationary.

Tatkal Ticket-

Page 49
 Object Oriented Modeling & Design Lab

1. A ticket booked against Tatkal Quota against extra payment of premium charges as per extant
railway rules.
2. A maximum of six berths/seats can be booked at a time for a specified journey between any two
stations served by the train subject to distance restrictions in force.
3. An individual user can book a maximum of ten tickets in a calendar month.
4. Booking can be done against general (GN), SS (senior citizen), ladies (LD) and tatkal (CK)
quota berths/seats only.
5. Tatkal Quota (CK) berths/seats are earmarked in all-important trains in different classes except
First Class Air-conditioned (1A) class. Ladies quota (LD) is generally earmarked in Sleeper class
(SL) and second sitting (2S).
6. In case of tickets booked through internet no concession is permitted except senior citizen.
7. General enquiries available:
a. Accommodation available for a train/date combination.
b. Current Status of reserved tickets.
c. Time table
d. Train fare
e. Trains available between a given pair of stations
8. E-Booking or E-reservation facility available for all trains.
9. On line cancellation facility for E-tickets alone, up to the charting time for that train. (E-tickets
cannot be cancelled at counters)
10. Mobile booking of I-Tickets and E-tickets through NGPAY Mobile application, booking of I-
Tickets and E-tickets through CSAM- IRCTC Mobile Application, I tickets on airtel live, via
IRCTC's WAP enabled site.
11. Auto-Up gradation is available to the next higher class on optional basis. (As per railway rules).

Modeling the Requirements

Home Page
 Primary purposes of website - “Reservation” and “Train Inquiry” are not visible
 It's difficult to find the starting point – especially for a novice user
 Lots of advertisements on the home page
 Lot of blinking / animated portions distract the user
 Icons and featured text are not at proper places
 The login portion itself has too many options
 Layout doesn’t look professional

User Registration Page

 Form does not fit into a single window, ideally it should
 User name and password are asked at end, they should be at the beginning
 Shipping address is not necessary on this page

Page 50
 Object Oriented Modeling & Design Lab

 Designation contains only 25 characters, should be 50 characters

 Value Added Services are on the same page here, which can be avoided
 The user has to login again after registration, this should be avoided
 Sometimes, even after registration, logging in results in a message that the user is not registered.

Plan My Travel Page

 Icons aren’t clear as to their purpose - Train Icons for From and To
 Selection date is today by default, but i-ticket (default option) requires minimum 3 days in future
 It is difficult to understand the three different types of tickets, there is help icon, but it opens in a
popup window.
 The list of trains after submission comes below the fold. It's difficult to understand that
something happened after the submission
 There are many pop-ups – availability, route, fare etc. This should be avoided
 Ideally, an option to book the return ticket too should be provided. The request can be saved and
used later, if the booking for that date has not yet started.
 There are also advertisements and other links on the Play My Travel page, they distract the user
from the main task.
 Checking availability is a crucial part of the booking process, but the user has to click a button
and see a popup window for this.
 Many a times, this even comes up with an “Unable to retrieve due to communication failure”
problem!

Payment Options

 There are too many payment options, and difficult to understand which one is better. This also
comes up in a pop-up window. Ideally, this can be a preference that can be set in the user profile.
 Many a times, the booking process fails on payment, despite a note that you can see this in the
failed payments page, it does not show up.

Advantages
 Reservation on the first page makes it easy to a novice to get the job done
 Single screen design makes it clear to the customer on what to expect
 No page reloads – easy for the user, more efficient for the server
 Send only the data that is needed, display is taken care of by the interface. E.g. Server
 sends only the train number, name, arrival / departure time and availability data on an Inquiry –
not the whole HTML code
 Faster response time – since client has to send and receive less data, and the server too is freed
to do the core business logic, rather than the presentation part

Page 51
 Object Oriented Modeling & Design Lab

 Ability to change one item and automatic update on others – this will make it easier for users to
book their tickets – significantly reducing the transaction time
 The back-end and front-end are separated, front-end is intelligent – can cache data, process it
etc.
 Advertisements can still be delivered; you can even deliver contextual ads as the user plans their
travel. Other pages of the site can also be integrated.
Result
Based on the system requirements specification online railway reservation system has
been analyzed & designed.
ALGORITHM / PROCEDURE / FLOWCHART:
1. Open Rational Rose Enterprise Edition

2. Select Appropriate Language For Mapping of Design

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw

From Menu.

Page 52
 Object Oriented Modeling & Design Lab

5. Select Appropriate Diagram from the View

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

Page 53
 Object Oriented Modeling & Design Lab

8. Save Diagram at Selected Location with .Mdl Extension

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Page 54
 Object Oriented Modeling & Design Lab

Figure1: Component Diagram for Railway Reservation System.

CONCLUSION / RESULT:
In this Experiment, we have Design Railway Reservation System Using Structural & Behavioral
UML Diagram.

Page 55
 Object Oriented Modeling & Design Lab

Experiment No.6
TITLE: Design Online Shopping System Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

Problem Statement
Online shopping or e-shopping is a form of electronic commerce which allows
consumers directly buy goods or services from a seller over the Internet using a web browser.
The Current shopping System is critical toset up online shops, customers to browse through the
shops, and a system administrator to approve and reject requests for new shops and maintain lists
of shop categories. This is a small scale system for Online shopping System. The basic idea is
that the candidates can buy product from anywhere during any time by using their card number
and password provided to them. The database will maintain the product details information.
Customer can view their product details using the card details.
Problems of existing virtual shopping system?

1. Very few product videos are added

2. Very few bargains, a bid system can introduce where consumer can bargain.
3. Does not disclose the packaging/manufacturing and expiry date of products.
4. No/very few return or buy back guarantee.
5. Difficult to trace a site owner if cyber-crime/financial fraud is conducted most of them
also do not mention about their contact numbers and official address etc.

Scope

Purchasing and selling products and services over the internet without the need of going
physically to the market is what online shopping all about. Online shopping is just like a retail

Page 56
 Object Oriented Modeling & Design Lab

store shopping that we do by going to the market, but it is done through the internet. Online
shopping has made shopping painless and added more fun. Online stores offer product
description, pictures, comparisons, price and much more .The supplementary specification
applies to online shopping system. This specification defines the non-functional requirement of
the system such as:

Objectives

The purpose is to define the requirements of Online shopping system. This supplementary
specification lists the requirements that are not readily captured in the use case model.
Supplementary specification and the use case model capture a complete set of requirement of the
system.
 Modeling the Requirements
The Online shopping system involves with two types of users.
1. customer
2. ADMINISTRATOR

 customer role
The customers can login/logout the System. She/he can view his/her product details and buy
their product. The customer can just view the information whereas he/she could not make
changes in the database.
 ADMINISTRATOR ROLE
The administrator plays a vital role in the Online shopping system. The administrator controls
the entire database. The report of the product is generated by the administrator itself. The main
role of the administrator is to safeguard the database and can add/delete the products from the
database.
 Module Description
 Login
It is the login session for the Administrator, customer and Exit.
 Product Details
It is used to view the product details from the database.
 Add New Products
It is used to add a product into the database and it includes searching a product details
and removing a product from database.
 Updating The Quantity
It is used to update the product details from the database.

 UML Diagram
 Use case Diagram

Page 57
 Object Oriented Modeling & Design Lab

Use Case diagrams show the various activities the users can perform on the system. The System
is something that performs a function. They model the dynamic aspects of the system. It provides
a user’s perspective of the system.
Actor-
An actor is a user of the system playing a particular role.
Use case-
Use case is a particular activity a user can do on the system.
Relationship:
Relationships are simply illustrated with a line connecting actors to use cases.

customer items displayed purchase

login add item

admin

 Class Diagram
A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them. Such as a graphical representation of a static view on
declarative static elements. A class is the description of a set of objects having similar attributes,
operations, relationships and behavior

custom items to display purchase

name : variant new name : variant new item name : variant new
age : variant itm no : variant itm no : variant
address : variant new manuf date : variant quantity : variant
city : variant new exp date : variant cost per item : variant
total cost : variant
view() purchase()
view()

adminis
login add item
name : variant new
age : variant user name : variant new item name : variant new
city : variant new password : variant new item no : variant
quantity : variant
add items() add items()
view()

Page 58
 Object Oriented Modeling & Design Lab

Payment
Online shoppers commonly use a credit card or a PayPal account in order to make payments.
However, some systems enable users to create accounts and pay by alternative means, such as:
 Billing to mobile phones and landlines
 Cash on delivery (C.O.D.)
 Cheque
 Debit card
 Direct debit in some countries
 Electronic money of various types
 Gift cards
 Postal money order
 Wire transfer/delivery on payment
 Invoice, especially popular in some markets/countries, such as Switzerland
 Bitcoin or other crypto currencies
Some online shops will not accept international credit cards. Some require both the purchaser's
billing and shipping address to be in the same country as the online shop's base of operation.
Other online shops allow customers from any country to send gifts anywhere.
The financial part of a transaction may be processed in real time (e.g. letting the consumer know
their credit card was declined before they log off), or may be done later as part of the fulfillment
process.
Product delivery
 Once a payment has been accepted, the goods or services can be delivered in the
following ways:
1. Downloading/Digital distribution: The method often used for digital media products such
as software, music, movies, or images.
2. Drop shipping: The order is passed to the manufacturer or third-party distributor, who
then ships the item directly to the consumer, bypassing the retailer's physical location to save
time, money, and space.
3. In-store pick-up: The customer selects a local store using a locator software and picks up
the delivered product at the selected location. This is the method often used in the bricks and
clicks business model.
4. Printing out, provision of a code for, or e-mailing of such items as admission tickets and
scrip (e.g., gift certificates and coupons). The tickets, codes, or coupons may be redeemed at the
appropriate physical or online premises and their content reviewed to verify their eligibility (e.g.,
assurances that the right of admission or use is redeemed at the correct time and place, for the
correct dollar amount, and for the correct number of uses).
5. Shipping: The product is shipped to a customer-designated address. Functionality
Sell Configured to Ordered Products.
 The system shall display all the products that can be configured.

Page 59
 Object Oriented Modeling & Design Lab

 The system shall allow user to select the product to configure.

 The system shall display all the available components of the product to configure
 The system shall enable user to add one or more component to the configuration.
 The system shall notify the user about any conflict in the current configuration.
 The system shall allow user to update the configuration to resolve conflict in the current
configuration.
 The system shall allow user to confirm the completion of current configuration
Security
 Read products descriptions, reviews and terms and conditions after purchasing.
 Avoid using cards, try to use- net banking, check, PayPal. If you wish to use card then
always use 3D secure site
 Read user experience about your selected goods and the shopping site.
 Try to buy goods from your own country shopping sites to avoid late delivery and higher
shipping cost.
Advantages of online shopping

It is very easy to shop your favorite items from a large number of online shopping sites available
on the internet. You can perform an online shopping from your home comfort. Here is no need to
go to the crowed supermarkets or shopping malls during festival seasons. You just need a PC or
a laptop and one necessary payment sending option to shop online.
 It is very easy.
 You will choose your favorite items from variety of online shopping sites comparing
price and quality.
 No need to go physical shops. You will have more time for your family.
 Just need a computer and a payment sending option (like-net banking, credit card, ATM
card).
 Almost all kinds of items can be brought through online shopping system.
 You can buy foreign goods from your bedroom.
 You will get your goods at your home.
 It is very secure.
 Customer service is available.

Result
Based on the system requirements specification online shopping system has been
analyzed & designed.

ALGORITHM / PROCEDURE / FLOWCHART:

1. Open Rational Rose Enterprise Edition

Page 60
 Object Oriented Modeling & Design Lab

2. Select Appropriate Language For Mapping of Design

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

5. Select Appropriate Diagram from the View

Page 61
 Object Oriented Modeling & Design Lab

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

8. Save Diagram at Selected Location with .Mdl Extension

Page 62
 Object Oriented Modeling & Design Lab

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Figure 1: Deployment Diagram for Online Shopping System.

CONCLUSION / RESULT:
In this Experiment, we have Design Online Shopping System Using Structural & Behavioral
UML Diagram.

Page 63
 Object Oriented Modeling & Design Lab

Experiment No.7
TITLE: Design Hotel Management System Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

Part I: Analysis and Process framework

1. Process Model
There are six types of process models are available such as Waterfall model, Prototyping model,
RAD model, Incremental model, Spiral model, 4GT model. The most useful software
engineering paradigm that we in co-operate in developing our project is the “waterfall model”. In
prototyping model Prototype is built which is used for refining requirement related to software
development. RAD is linear sequential software development process rapidly generally used for
business levels. In Incremental model it takes the element from linear sequential model. Process
is related in each increment, until complete product is produced. Spiral model is divided into
number of framework activities also called regions. Software development environment that
support 4GT paradigm include following tools: non procedural language for database query,
report generation, high level graphics capability and spreadsheet capability but for the high level
objects. But for our System Waterfall model is appropriate because of the following reasons,
1. It is linear sequential model is the oldest and the most widely used paradigm for the software
engineering.
2. Requirement gathering system level and business level.
3. Requirement gathering related to software.
4. Code generation using some program language like C, CPP, Java etc., and Take details from
design phase.
5. It’s Presentation of analysis.
6. It focuses on changes.

Page 64
 Object Oriented Modeling & Design Lab

7. The target of this process model is that a complete system will developed after the number of
refinement.
8. This approach to software development begins at the system level and progresses towards
through analysis, design, coding, testing and support.
9. Using this process model, implementation is get easy.
2. Common Process Framework
Communication
A1 A1: Communication between customer and developers
A2 A2: Estimation
A3 A3: Creation of Software Scope
A4 .
A5 .
A6 .

Planning D1: Estimation

D1 D2: Scheduling
D2 D3: Tracking
D3 .
D4 .
D5 .
D6

Modeling M1: Analysis

M1 M2: Design
M2 .
M3 .
M4 .
M5 .

Construction C1: Coding

C1 C2: testing
C2 .
C3 .
C4 .
C5 .
C6

Page 65
 Object Oriented Modeling & Design Lab

Deployment D1: Delivery

D1 D2: Support
D2 D3: Feedback
D3 .
D4 .
D5 .
D6

4. Problem Statement
• Manually keeping records is very time consuming.
• Data is not always reliable as it is hand written and some human errors
might have occurred example wrong telephone number among other.
• Slow process of reservation. User has find manually whether room is
available or not.
• Hotel information data are not secured. It can be easily theft or altered.
• Finding records are very time consuming.
• Retrieval of guest records is extremely difficult. User has to manually
search each records to find the required information. It takes lot of time.
5. Cost Estimation

According to Inventory management system we are move towards to “Organic” mode. So in this
organic mode the project size typically 2-50 KLOC. As our observation the inventory
management system is a small size project, experience developers in the familiar environment. It
development environment is familiar & in house. So, according to the observations we assume
some figures. Suppose that a project was estimated to be 400 LOC.

Project ab bb Cb db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

The basic COCOMO equations take the form

E= ab (LOC)bb
D= cb (LOC)db

Organic mode
E = 2.4(400)1.05 = 1295.31 PM
D = 2.5(1295.31)0.38 = 38.07 M

Page 66
 Object Oriented Modeling & Design Lab

According to figure as shown above

E = is effort applied in person-months
D= is the development time in months
Avg. staff size (SS) = E/D persons.
1295.31/38.07 = 34 approx.

PART II: SRS Contents

1. Purpose
Purpose of System:-
This hotel management system is developed for hotels those are using a manual system to handle
hotel processes. There are three main users in hotel management system, administrator, Manager
and Receptionist. Administrator can maintain daily updates in the hotel records. This system will
automate the major operations of the hotel. Administrator can access to all system functionalities
without any restrictions. Administrator is must be an authorized user. He can further change the
password. There is the facility for password recovery, logout etc. Manager can access to all
system functionalities with limited restrictions. Receptionist can only access to the Reservation
Management section. The main aim of the entire activity is to automate the process of day to day
activities of Hotel.
The Reservation System is to keep track in room and hall reservation and check
availability. Using this system user can check which room is reserved and which room is
available. He can reserve room from reservation module. The Room Management System is for
manage all room types room services. Room management module help user to keep track of all
information of hotel room. He can check room laundry service, food service and sweeping
service from this module. The Inventory Control System will keep track in all inventories of the
hotel and guest details will handled by guest management. Administration department will
monitor the all. the main of developing this system is to computerize all the activity of the hotel
like Admission of a New Customer, Assign a room according to customer’s demand, checkout of
a customer and releasing the room and finally compute the bill etc. Using this system you can
manage check in and check out process easily. At check in, you can easily check the availability
of rooms in the hotel. And at check-out you can easily generate the total bill.
The main objective of the entire activity is to automate the process of day to day activities
of Hotel. Using this system you can manage room activities and keep track of admission of a
New Customer. Using this system you can check rooms according to customer’s need and can
assign easily room to customer. Checkout of a customer and updating the releasing room
information in the system is very easy. When user do checkout system will generate final bill
after calculating all the bills. User can also check online, all the packages available. He can also
book rooms online. He can also cancel booked room online. Hotel management can also check
the list of Regular customers and feedback of the hotel’s customer.

Page 67
 Object Oriented Modeling & Design Lab

3. System requirement
3.1 Hardware requirement
Processor: Pentium III or above
RAM: 256 MB or above
Hard disk: minimum 20 GB or more
Processor speed: 512 MHZ

8.2 Software requirements

Operating System for developing: Windows XP, Linux
Operating System Environment: Windows 98/XP
Tool used for developing: Visual Studio .Net Version: 2003 for coding
Back-end database: Microsoft SQL Server Version: 2000

4. Functional requirements

During the past several decades’ personnel function has been transformed from a relatively
obscure record keeping staff to central and top level management function. There are many
factors that have influenced this transformation like technological advances, professionalism, and
general recognition of human beings as most important resources.
• A computer based management system is designed to handle all the primary in formation
required to calculate monthly statements. Separate database is
• Maintained to handle all the details required for the correct statement calculation and
generation.
• This project intends to introduce more user friendliness in the various activities such as record
updation, maintenance, and searching.
• The searching of record has been made quite simple as all the details of the customer can be
obtained by simply keying in the identification of that customer.
• Similarly, record maintenance and updation can also be accomplished by using the
identification of the customer with all the details being automatically generated. These details are
also being promptly automatically updated in the master file thus keeping the record absolutely
up-to-date.
•The entire information has maintained in the database or Files and whoever wants to retrieve
can’t retrieve, only authorization user can retrieve the necessary information which can be easily
be accessible from the file.
The main objective of the entire activity is to automate the process of day to day.

Activities of Hotel like:

 Room activities,
 Admission of a New Customer,
 Assign a room according to customer’s demand,
Page 68
 Object Oriented Modeling & Design Lab

 Checkout of a computer and releasing the room

 Finally compute the bill etc.
 Packages available.
 Advance online bookings.
 Online Cancellation.
 List of Regular customers.
 Email facility.
 Feedbacks

7. User specifications

1. Registration:
 New user or new hotel admin gets registered in our booking portal.
 Admin gives details of registration.
2. Login:
 Existing user and existing hotel admin gets login and access the system components.
 Admin gives the permission to the user and hotel admin for serve.
3. Search Destination:
 Here, user can search the particular hotel and booking from that hotel which is search by the
user.
4. Booking Hotel:
 User can book particular hotel and get information about that booking. Hotel admin provides
some offer for particular time period.
 Also, admin provide the offers.
 Online Hotel Management
5. Payment:
 User can payment via credit card or debit card.
 And Hotel admin pay decided commission on particular booking to Admin.
 Admin can get decided commission on particular booking.
6. Updation:
 After the completion overall transaction Admin can manage the whole system.
 Hotel admin can also manage their user.

8. Proposed System

Proposed system will automate following functions

 Room Detail Functions
 Opening a New Room
 Modification to room assigned
Page 69
 Object Oriented Modeling & Design Lab

 Check-in and check-out Detail Functions

 Admission of New customer
 Check-out of customer
 Room assigning related to customer’s need.
 Statement of Customer Details
 Check-in customer
 Check-out customer
 Room Details
 Total number of Customers in the Hotel
 Individual customer Report
9. Services

• A computer based management system is designed to handle all the primary information
required to calculate monthly statements. Separate database is maintained to handle all the details
required for the correct statement calculation and generation.
• This project intends to introduce more user friendliness in the various activities such as
record updation, maintenance, and searching.
• The searching of record has been made quite simple as all the details of the customer can
be obtained by simply keying in the identification of that customer.
• Similarly, record maintenance and updation can also be accomplished by using the
identification of the customer with all the details being automatically generated. These details are
also being promptly automatically updated in the master file thus keeping the record absolutely
up-to-date.
• The entire information has maintained in the database or Files and whoever wants to
retrieve can’t retrieve, only authorization user can retrieve the necessary information which can
be easily be accessible from the file.
PART III: Coding / Testing / Maintenance
1. Coding

Programming or coding is next phase when system design is complete from design to
code development.

Advantages of Visual Studio .Net Version: 2003 Framework

1. NET is the framework for which we develop applications. It sits in between our application
programs and operating system. Applications developed for .NET run inside .NET and are
controlled by .NET. It supports both Windows and web applications.
2. NET provides an object oriented environment. It ensures safe execution of the code by
performing required runtime validations. For example, it is never possible to access an element
of an array outside the boundary. Similarly, it is not possible to a program to write into another

Page 70
 Object Oriented Modeling & Design Lab

programs area, etc. The runtime validations performed by .NET makes the entire environment
robust.
Now choose SQL Server 2000 as back end because following features:
1. The SQL Server 2000 database engine includes integrated XML support.
2. Scalability and Availability: The same database engine can be used across platforms ranging
from laptop computers running Microsoft Windows 98 through large, multiprocessor servers
running Microsoft Windows 2000 Data Center Edition.
3. Ease of installation, deployment, and use.

2. Testing

1. After coding, testing of code generated status various system testing methods from unit testing to
integration are used to in this phase.
2. Testing is used to check errors, bugs or required output.
3. After coding, testing of code generated status various system testing methods from unit. Testing
to integration is used in this phase.
4. Testing is used to check error, bugs or required output.

3. Maintenance/Support
It is last phase of life cycle when system is implemented at user wants changes are required as
new platform with OS May peripheral devices are changes.
1. Correction: - In this uncover logical errors are corrected. E.g. Patient ID data type Number but
customer use character every time, so software gives error. This error can be corrected by
changing data type to number.
2. Adaptation: - In this modification in software is done to according changes with external
environment. Modification in software is done according changes with environment.
3. Enhancement: - Changes because of the additional functionality requested by the customer.
Customer required some additional functions at that time in enhancement is done in the software
or product.
4. Prevention: - Suppose after delivery of software customer recognize that response time
of software is slow. He tells to developer to make changes in software so developers suggest
recognizing software than change.
ALGORITHM / PROCEDURE / FLOWCHART:
1. Open Rational Rose Enterprise Edition

2. Select Appropriate Language For Mapping of Design

Page 71
 Object Oriented Modeling & Design Lab

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

5. Select Appropriate Diagram from the View

Page 72
 Object Oriented Modeling & Design Lab

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

8. Save Diagram at Selected Location with .Mdl Extension

Page 73
 Object Oriented Modeling & Design Lab

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Figure 1: Use Case Diagram for Hotel Management System.

CONCLUSION / RESULT:
In this Experiment, we have Design Hotel Management System System Using Structural &
Behavioral UML Diagram.

Page 74
 Object Oriented Modeling & Design Lab

Experiment No.8
TITLE: Design Hospital Management System Using Structural & Behavioral UML Diagram.
PREREQUISITE: Software Analytical Skill
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

Part I: Analysis and Process framework

1. Process Model
There are six types of process models are available such as Waterfall model, Prototyping model,
RAD model, Incremental model, Spiral model, 4GT model. The most useful software
engineering paradigm that we in co-operate in developing our project is the “waterfall model”. In
prototyping model Prototype is built which is used for refining requirement related to software
development. RAD is linear sequential software development process rapidly generally used for
business levels. In Incremental model it takes the element from linear sequential model. Process
is related in each increment, until complete product is produced. Spiral model is divided into
number of framework activities also called regions. Software development environment that
support 4GT paradigm include following tools: non procedural language for database query,
report generation, high level graphics capability and spreadsheet capability but for the high level
objects. But for our System Waterfall model is appropriate because of the following reasons,
10. It is linear sequential model is the oldest and the most widely used paradigm for the software
engineering.
11. Requirement gathering system level and business level.
12. Requirement gathering related to software.
13. Code generation using some program language like C, CPP, Java etc., and Take details from
design phase.
14. It’s Presentation of analysis.
15. It focuses on changes.

Page 75
 Object Oriented Modeling & Design Lab

16. The target of this process model is that a complete system will developed after the number of
refinement.
17. This approach to software development begins at the system level and progresses towards
through analysis, design, coding, testing and support.
18. Using this process model, implementation is get easy.
2. Common Process Framework
Communication
A1 A1: Communication between customer and developers
A2 A2: Estimation
A3 A3: Creation of Software Scope
A4 .
A5 .
A6 .

Planning D1: Estimation

D1 D2: Scheduling
D2 D3: Tracking
D3 .
D4 .
D5 .
D6

Modeling M1: Analysis

M1 M2: Design
M2 .
M3 .
M4 .
M5 .

Construction C1: Coding

C1 C2: testing
C2 .
C3 .
C4 .
C5 .
C6

Page 76
 Object Oriented Modeling & Design Lab

Deployment D1: Delivery

D1 D2: Support
D2 D3: Feedback
D3 .
D4 .
D5 .
D6

4. Problem Statement
Problems with conventional system
1. Lack of immediate retrievals: -The information is very difficult to retrieve and to find
particular information like- E.g. - To find out about the patient’s history, the user has to go
through various registers. This results in inconvenience and wastage of time.
2. Lack of immediate information storage: - The information generated by various transactions
takes time and efforts to be stored at right place.
3. Lack of prompt updating: - Various changes to information like patient details or
immunization details of child are difficult to make as paper work is involved.
4. Error prone manual calculation: - Manual calculations are error prone and take a lot of time
this may result in incorrect information for example calculation of patient’s bill based on various
treatments.
5. Preparation of accurate and prompt reports: - This becomes a difficult task as information is
difficult to collect from various registers.

5. Cost Estimation

According to Inventory management system we are move towards to “Organic” mode. So in this
organic mode the project size typically 2-50 KLOC. As our observation the inventory
management system is a small size project, experience developers in the familiar environment. It
development environment is familiar & in house. So, according to the observations we assume
some figures. Suppose that a project was estimated to be 400 LOC.

Project ab bb Cb db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

The basic COCOMO equations take the form

Page 77
 Object Oriented Modeling & Design Lab

E= ab (LOC)bb
D= cb (LOC)db

Organic mode
E = 2.4(400)1.05 = 1295.31 PM
D = 2.5(1295.31)0.38 = 38.07 M

According to figure as shown above

E = is effort applied in person-months
D= is the development time in months
Avg. staff size (SS) = E/D persons.
1295.31/38.07 = 34 approx.

PART II: SRS Contents

1. Purpose
Purpose of System:-
The purpose of the system is to support a computerized system for patient & doctor. Each
hospital system provides a computer to each of them for hospital management & process to
organize them. In this, Patient wants to Log in the system. Check up and Fill all information
related with patient, whenever doctors want to log in the system. Record for patient id & the
time for meeting the doctor are made in computer. Also Enquiry Counter will check the number
of recipients. Accurate calculations should be made.

3. System requirement
3.1 Hardware requirement

Processor: Pentium III or above

RAM: 256 MB or above
Hard disk: minimum 20 GB or more
Processor speed: 512 MHZ

8.2 Software requirements

Operating System for developing: Windows XP, Linux
Operating System Environment: Windows 98/XP
Tool used for developing: Visual Studio .Net Version: 2003 for coding
Back-end database: Microsoft SQL Server Version: 2000

4. Functional requirements

Page 78
 Object Oriented Modeling & Design Lab

 A Hospital is a place where Patients come up for general diseases. Hospitals provide facilities
like:-
1. Consultation by Doctors on Diseases.
2. Diagnosis for diseases.
3. Providing treatment facility.
4. Facility for admitting Patients (providing beds, nursing, medicines etc.)
5. Immunization for Patients/Children.

 Various operational works that are done in a Hospital are:-

1. Recording information about the Patients that come.
2. Generating bills.
3. Recording information related to diagnosis given to Patients.
4. Keeping record of the Immunization provided to children/patients.
5. Keeping information about various diseases and medicines available to cure them.

 These are the various jobs that need to be done in a Hospital by the operational staff and Doctors.
All these works are done on papers. The work is done as follows:-
1. Information about Patients is done by just writing the Patients name, age and gender. Whenever
the Patient comes up his information is stored freshly.
2. Bills are generated by recording price for each facility provided to Patient on a separate sheet and
at last they all are summed up.
3. Diagnosis information to patients is generally recorded on the document, which contains Patient
information. It is destroyed after some time period to decrease the paper load in the office.
4. Immunization records of children are maintained in pre-formatted sheets, which are kept in a file.
5. Information about various diseases is not kept as any document. Doctors themselves do this job
by remembering various medicines.

All this work is done manually by the receptionist and other operational staff and lot of papers
are needed to be handled and taken care of. Doctors have to remember various medicines
available for diagnosis and sometimes miss better alternatives as they can’t remember them at
that time.

7. User specifications

1. Patients:-Number of patients coming hospital having number of several of decease. The

patient has to go inquiry office and give his/her whole details and which type of disease he/she
suffering from. Every patient must have register themselves and pay the initial
registration fee to the inquiry office whatever the charges the hospital has decided. After the

Page 79
 Object Oriented Modeling & Design Lab

patient is registered according to his/her status whether he is new or old patient she/he is
diverted to consult or doctor specialist.

2. Inquiry office:-This department is the public interface to the hospital. A new or old patient
visiting doctors, specialist etc. So inquiry office will take the information from patient and guide
him/her that to whom they should contact.

3. Doctors: Doctors are the important part of this management system. Doctors checks the patient
and diagnose the problem and then they will be admitted the patient otherwise they will be
giving medicines to the patients.

4. Staff: There are many people working in the staff like nurses and work boys. They give
medicines to indoor patients and take care of patients.

User Characteristics
Every user should be:
• Comfortable of working with computer.
• He must have knowledge in medical field.
• He must also have basic knowledge of English too.

8. Proposed System

1. The project maintains two levels of users:-

• Administrator Level-Doctor
• User Level-Data Entry Operator

2. In this project collection of data is from different pathology labs.

3. Results of tests, prescription, precautions and diet advice will be automatically updated in the
database.
4. Related test reports, patient details report, prescription and billing reports can be generated as per
user requirements.
5. User or Administrator can search a patient’s record by his/her name or their registration date.
6. Patient’s diet advice can be provided in Hindi.

9. Services

1. Maintaining records of indoor/outdoor patients.

2. Maintaining patients diagnosis details, advised tests to be done.
3. Providing different test facilities to a doctor for diagnosis of patients.
a. X-Ray

Page 80
 Object Oriented Modeling & Design Lab

b. Urine Test
c. Stool Test
d. Sonography Test
e. Gastroscopy Test
f. Colonoscopy Test
g. Blood Test
h. Biochemistry Test
4. Maintaining patient’s injection entry records.
5. Maintaining patient’s prescription, medicine and diet advice details.
6. Providing billing details for indoor/outdoor patients.
7. Maintaining backup of data as per user requirements (between mentioned dates).
8. If user forgets his/her password then it can be retrieved by hint question.
PART III: Coding / Testing / Maintenance
1. Coding

Programming or coding is next phase when system design is complete from design to
code development.

Advantages of Visual Studio .Net Version: 2003 Framework

3. NET is the framework for which we develop applications. It sits in between our application
programs and operating system. Applications developed for .NET run inside .NET and are
controlled by .NET. It supports both Windows and web applications.
4. NET provides an object oriented environment. It ensures safe execution of the code by
performing required runtime validations. For example, it is never possible to access an element
of an array outside the boundary. Similarly, it is not possible to a program to write into another
programs area, etc. The runtime validations performed by .NET makes the entire environment
robust.
Now choose SQL Server 2000 as back end because following features:
4. The SQL Server 2000 database engine includes integrated XML support.
5. Scalability and Availability: The same database engine can be used across platforms ranging
from laptop computers running Microsoft Windows® 98 through large, multiprocessor servers
running Microsoft Windows 2000 Data Center Edition.
6. Ease of installation, deployment, and use.

2. Testing

5. After coding, testing of code generated status various system testing methods from unit testing to
integration are used to in this phase.
6. Testing is used to check errors, bugs or required output.
7. After coding, testing of code generated status various system testing methods from unit. Testing

Page 81
 Object Oriented Modeling & Design Lab

to integration is used in this phase.

8. Testing is used to check error, bugs or required output.

3. Maintenance/Support

It is last phase of life cycle when system is implemented at user wants changes are required as
new platform with OS May peripheral devices are changes.
5. Correction: - In this uncover logical errors are corrected. E.g. Patient ID data type Number but
customer use character every time, so software gives error. This error can be corrected by
changing data type to number.
6. Adaptation: - In this modification in software is done to according changes with external
environment. Modification in software is done according changes with environment.
7. Enhancement: - Changes because of the additional functionality requested by the customer.
Customer required some additional functions at that time in enhancement is done in the software
or product.
8. Prevention: - Suppose after delivery of software customer recognize that response time
of software is slow. He tells to developer to make changes in software so developers suggest
recognizing software than change.

Page 82
 Object Oriented Modeling & Design Lab

ALGORITHM / PROCEDURE / FLOWCHART:

1. Open Rational Rose Enterprise Edition

2. Select Appropriate Language for Mapping of Design

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

5. Select Appropriate Diagram from the View

Page 83
 Object Oriented Modeling & Design Lab

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

Page 84
 Object Oriented Modeling & Design Lab

8. Save Diagram at Selected Location with .Mdl Extension

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Figure 1: Class Diagram for Hospital Management System.

CONCLUSION / RESULT:
In this Experiment, we have Design Hospital Management System Using Structural &
Behavioral UML Diagram.
Page 85
 Object Oriented Modeling & Design Lab

Experiment No.9
TITLE: Design University Result Management System Using Structural & Behavioral UML
Diagram.
PREREQUISITE: Software Analytical Skill.
HARDWARE CONFIGURATION / KIT:
Sr. No Hardware Configuration
1 Processor 1.5GHz or more
2 RAM 4Gb Minimum
3 HDD Minimum 30Gb free Space
4
Standard I/O devices

SOFTWARE CONFIGURATION:
Sr. No Software Configuration
1 Operating System Windows 7 or later
2 Rational Rose Enterprise Edition 7.0 or later

THEORY:

Part I: Analysis and Process framework

1. Process Model

The model that is basically being followed is the WATER FALL MODEL, which states
that the phases are organized in a linear order. First of all the feasibility study is done. Once that
part is over the requirement analysis and project planning begins. The design starts after the
requirement analysis is complete and the coding begins after the design is complete. Once the
programming is completed, the testing is done. In this model the sequence of activities
performed in a software development project are: -
 Requirement Analysis
 Project Planning
 System design
 Detail design
 Coding
 Unit testing
 System integration & testing

Here the linear ordering of these activities is critical. End of the phase and the output of one
phase is the input of other phase. The output of each phase is to be consistent with the overall

Page 86
 Object Oriented Modeling & Design Lab

requirement of the system. Some of the qualities of spiral model are also incorporated like after
the people concerned with the project review completion of each of the phase the work done.
WATER FALL MODEL was being chosen because all requirements were known
beforehand and the objective of our software development is the computerization/automation of
an already existing manual working system.

2. Common Process Framework

Task Set:

Common Process Framework

Analysis Design

A1 D1

A8 D4

Coding Testing

C1 T1

C3 T6

Analysis:
 A1 – Requirement Analysis
 A2 – Information Gathering
 A3 – Software Scope
 A4 – Project Scheduling
 A5 – Estimation
 A6 – ERD
 A7 – DFD
 A8 – SRS
Design:
 D1 – Architectural Design
 D2 – Component Design
 D3 – Interface Design
 D4 – Data Design
Coding:

Page 87
 Object Oriented Modeling & Design Lab

 C1 – Converting Design into Code

 C2 – DBMS Connectivity
 C3 – GUI
Testing:
 T1 – Test Plan
 T2 – Test Cases
 T3 – Unit Testing
 T4 – Integration Testing
 T5 – Alpha Testing
 T6 – Beta Testing

3. Problem Definition

Design the software to support a computerized University management system. Each

storing and accessing the data in the form of Excel sheets and account books is a tedious work. It
requires a lot of laborious work. It may often yield undesired results. Maintaining these records
as piles may turn out to be a costlier task than any other of the colleges and institutions
4. Cost Estimation

We do the Cost Estimation using COCOMO (constructive cost model)

Type an bn cb db

Organic 2.4 1.05 2.5 0.38

Efforts Required=E=ab(KLOC)bb
=2.4*(30)1.05
=85 PM
db
Duration=D=Cb(E)
=2.5*(85)0.38
=13 Months

Peoples required=E/D
=85/13
=7
Efforts Required=85 PM
Duration=13 Months
Peoples required=7

PART II: SRS Contents

Page 88
 Object Oriented Modeling & Design Lab

1. Purpose of System

Design the software to support a computerized University management system. University

Management System deals with the maintenance of university, college, faculty, student
information within the university. This project of UMS involved the automation of student
information that can be implemented in different college management.
The project deals with retrieval of information through an INTRANET or INTERNET
based campus wide portal. It collects related information from all the departments of an
organization and maintains files, which are used to generate reports in various forms to measure
individual and overall performance of the students.

2. Benefits to the End User

1. They are student and staff member’s facilities provided by the system.
2. Facilities are provided to staff members are similar to those provided to students.
3. Reducing time in activities.
4. Centralized data handling.
5. Improved the operational efficiency

3. Disadvantages of Existing System

1. Time required is very large because of manual system.

2. It is get more complicated due to paper work and more tasks.
3. Need to maintain catalogue.
4. Paper work extended many transition token.
5. Less secure.
6. All Functions was performed manually.

4. Project Specifications

Basic objective is to extends their reach to geographically scattered Students, reducing time
in activities, centralized data handling and paperless work, with Reduced manpower, cost
cutting, operational efficiency

5. Functional Requirements

Access University database, issue register new students, enable student login, check result,
search for student, Maintain student database, display list of all registered students.

6. Non Functional Requirements

Page 89
 Object Oriented Modeling & Design Lab

Some Functional requirements identified is listed below:

 The database shall be able to accommodate a minimum of 10,000 records of students.
 The software shall support use of multiple users at a time.

7. Proposed System
Computerized system proposes maintaining records of colleges, students and faculty. This
system does not includes
 Finding records from rack.
 Check its condition/finding a page.

 Advantages of proposed system

1. Maintain catalog.
2. Paper work is reduced.
3. All processing is performed by software.
4. Locating records is easy.
5. Burden on staff is reduced.

 Disadvantages of Existing System

1. Large paper work is requiring for maintaining each and every record.
2. Time required is very large because of manual system for maintaining record.

8. Services
1. Registering new students, colleges and courses.
2. Manage large number of student details.
3. Manage all details of student who registered for the course and send appropriate details about the
course to the students account.
4. Create student accounts and maintain the data’s effectively.
5. Generation of daily or monthly or semester report.
6. Creating department, allocating courses to departments, creating faculties, students and
allocating subjects to faculties, and modifications in the data entered by the user

9. System requirements
9.1 Hardware requirements
Processor: Pentium IV or above
RAM: 256 MB or above
Hard disk: minimum 20 GB
Processor speed: 512 MHZ

9.2Software requirements
Page 90
 Object Oriented Modeling & Design Lab

Operating System for developing: Windows XP

Operating System Environment: Windows 98/XP
Tool used for developing: Java SE 8

10. Performance Criteria

1. While accessing records of particular category, list of values should be displayed within
a second.
2. The software should be stable in order to handle large amount of data.
11. Use case Description
Level of Use Case Description
 UC Brief description
Summary of what system does in response to actor’s actions
 UC Intermediate description
Shows steps in use case, if-then
 UC Full description
Includes Brief description, expands intermediate description, shows scenarios
Reading and Writing Use Case Descriptions
 Reading: Straightforward
 Writing:
 We will not use it much
 Useful to practice because it leads to other modelling techniques (activity diagram, class
diagram)
Writing Use Case Descriptions
 Select a use case
 Write abbreviated full description (Use case name, Scenario (if any), Business Event,
Actors, Flow of steps, Exception conditions)
3. For figuring Flow of steps,
- Keep in mind general system model: Input-Processing-Output
- Steps should be at nearly the same level of abstraction (each makes nearly
same progress toward use case completion)
4. For figuring exception conditions, focus on if-then logic.
Use Case Description:
Use case describes how the various users access the system for particular purpose
Actors:-
 University Administrator
 Student
 Faculty Members
 University Database
Precondition:-

Page 91
 Object Oriented Modeling & Design Lab

 There is an active network connection to system.

 The system should be able to provide services.
Basic Events:-
 Actor:-Student
 Login:-The user must have to login to access various services
 Enter ID and password:-for the security purpose the user must have to enter User ID and
password.
 View Attendance:-The Student can view his college attendance report.
 View Result: - The student can view his academic result.
 Actor:-University Admin
The University Admin Creates Courses, Create Colleges and Generates various reports
 Actor:-Faculty
The Faculty members can view assigned Subjects , give marks
12. User Specification
1) Student: This class of user will use the system to fill various forms & information. Since the
users will be requesting for info in the field relate to system, they will have a basic knowledge
and experience with various web based applications since filling the forms does not require much
technical expertise it will very easy for this class of user to use the system.

2) Faculty members: They will have a good knowledge of computer system and also the operating
environment in which these systems are working in development. In order to use the system, the
faculty members should be familiar with various form processes.
3) University Admin: The system administrator will be one of the university member who should
be familiar with the University structure and functioning of the university she/he must also be
very well familiar with all the process in the University.
There are a number of attributes of software that can serve as user specification. It is important
that required attributes by specified so that their achievement can be objectively verified. The
following items provide a partial list of examples.
 The input system will allow for inputting numbers, operands, special symbols and letters of the
alphabet.
PART III: Coding/Testing / Deployment/Maintenance
1. Coding
Programming or coding is next phase when system design is complete from design to
code development.
Now choose Java as front end because following features:
1. Easy to use.
2. Implementation is easy.
3. Updating can be easily done.
4. User friendly.
Choose back end as MS-access with following features
Page 92
 Object Oriented Modeling & Design Lab

1. Can store large amount data.

2. Table size is 64KB which is much more store.
3. Access gives user friendly to access data easily and conveniently.
2. Testing
1. After coding, testing of code generated status various system testing methods from unit testing to
integration are used to in this phase.
2. Testing is used to check errors, bugs or required output.
3. After coding, testing of code generated status various system testing methods from unit. Testing
to integration is used in this phase.
4. Testing is used to check error, bugs or required output.
3. Deployment
1. Actual installation of product on customer site
2. Description of deployment diagram.
4. Maintenance/Support
It is the last phase of life cycle when system is implemented at user site. Changes are required as
new platform or peripheral devices are changed. Changes may occur due to external
environment.
Correction: - In this uncover logical errors are corrected. E.g. Book I.D. Datatype Number but
customer use character every time, so software gives error. This error can be corrected by
changing data type to number.
Adaptation: - In this modification in software is done to according changes with
external environment.
Enhancement: - Changes because of the additional functionality requested by the customer.
Prevention: - Suppose after delivery of software customer recognize that response time of
software is slow. He tells to developer to make changes in software so developers suggest
recognizing software than changes.

Page 93
 Object Oriented Modeling & Design Lab

ALGORITHM / PROCEDURE / FLOWCHART:

1. Open Rational Rose Enterprise Edition

2. Select Appropriate Language For Mapping of Design

3. Select Appropriate View for New Diagram

4. Browse The Diagram To Draw From Menu.

5. Select Appropriate Diagram from the View

Page 94
 Object Oriented Modeling & Design Lab

6. Give Appropriate Name By Renaming The File.

7. Drag & Drop the UML Building Block as Per Diagram from Tool Bar into the Workspace

8. Save Diagram at Selected Location with .Mdl Extension

Page 95
 Object Oriented Modeling & Design Lab

EXPERIMENTAL KIT: (PICTURE IF ANY)

PROGRAM / PSEUDO-CODE/DIAGRAM:

Use case Diagram for University Result Management System.

CONCLUSION / RESULT:
In this Experiment, we have Design University Result Management System Using Structural &
Behavioral UML Diagram.

Page 96