Lab Manual

For
Object Oriented Software Engineering
 LIST OF EXPERIMENTS

1. To write Complete Problem Statement.

2. To design Initial Requirement Specification document.

3. To design Use Case Diagram.

4. To design SRS document.

5. To design Class Diagram.

6. To design Object Diagram.

7. To design Sequence Diagram.

8. To design State Chart Diagram.

9. To design Component Diagram.

10. To design Activity Diagram.

11. To design Collaboration Diagram.

 Objectives: Object Oriented Software Engineering Lab

The Object Oriented Software Engineering Lab offers a profound insight into the
significance of software industry requirement modeling. It will help us to study
the Rational Rose tool used in the life cycle of software development, making it
simple to comprehend and execute the requirement modeling process.
Requirement Modelling helps us to make it simpler for big and complicated
applications to collect, interact, monitor, evaluate, check, validate, display and
handle hundreds of hierarchical and interrelated engineering demands.
The objective of the Lab work is to make the student conversant with the UML
tools for modeling of Business Applications. A case study on “Insurance
Management System” has been demonstrated. The students will be working in
groups of 2 on the following case studies:
1. Online Student Attendance System
2. Transport Management System
3. Library Management System
4. Student Result Management System
5. Hostel Management System
6. Video Library Management System
7. Hotel Management System
8. Court Cases Management System
9. E-Ticketing System
10. Online Share Trading System
11. Bank Loan System
12. Blood Bank System
13. Railway Reservation System
14. Automatic Teller System
 15. Resources Management System
16. Clinic Management System

On successful completion of the course,

1. The students shall be able to analyze and design their project.

2. The students should be able to identify the analysis elements of the project
and understand the association between them.
3. The students will be able to create analysis model of their project.
 Experiment 1

AIM: TO WRITE THE COMPLETE PROBLEM STATEMENT

INSURANCE MANAGEMENT SYSTEM

The developed system should allow admin users to register insured persons with
their name, date of birth, residence address, medical history and also policy
details. After registering all the insured persons, website should provide
management facilities like delete unwanted person’s data. And also should
provide awareness to the visitors about micro insurance through articles.

EXISTING DRAWBACKS:
1. Take more processing time.
2. There is lack of security and accuracy for the data.
3. Poor maintenance.
4. Consumes large volume of paper works.
5. Large amount of manual processing is needed.
6. Possibility of errors during manual processing and calculations.
7. Every member organization has its own data structure.
8. Due to lack of centralized data structure, it is very difficult to merge the data
to analyze the statistics.
9. Difficult to search the data.
10. Possibility of duplicates.

REVISIONS PROPOSED:
The insurance management system is a complete management system designed
to handle all aspects of running your insurance agency from tracking your policy
count to working your expiration list and everything which is required in the
ongoing process.
The required software should have following functionalities:

1. USER ACCOUNT: Each user should be able to handle and manage a

different account. The account holders are only allowed to access policies
and their long term benefits.
2. SEARCH: The user can search for different policies and their expiry
date.
3. DESCRIPTION: Every policy consist of different terms and condition,
updating date, expiry date and renewal process. It should also describe about
different agents looking after a particular policy.
4. POLICY ALERT: The system should be able to make customer aware
about policy expiry date. Alert should be made either by using their
respective email id or mobile numbers.
5. AUTOMATIC RENEWAL: There should be automatic policy renewal
such that by a single click the policy holder can easily renew it and
automatically database gets updated.
6. ONLINE PAYMENT FACILITIES: The software should facilitate easy
payment options using credit cards, debit cards, net banking, BHIM and UPI.
Renewal premium can be paid all in force policies, excluding policies under
Salary Saving Scheme & policies registered for premium payment through
NACH. Payment is allowed from 1 month prior to the due date till the policy
is in force.
 Experiment 2

AIM: WRITE THE INITIAL REQUIREMENTS SPECIFICATION DOCUMENT

INITIAL REQUIREMENTS SPECIFICATION DOCUMENT

Software requirements specification capture system behavior as opposed to
nonfunctional requirements specifications which define attributes as not behavior.
This ‘functionality’ refers to services, tasks or functions the user performs using the
system in question.

In product development, it is important to understand the difference between the

baseline functionality necessary for any system to compete in that product domain,
and features that make the system different from their competitor’s products.

Some strategies have important implications for software architecture. Specifically,

it is not just the Software requirements specifications of the initial release that
must be supported in the architecture. The Software requirements specifications
of initial products need to be explicitly taken into consideration.

The key to this blog posting is to get a complete understanding of Software

requirements specifications, not technical specifications which are easy to confuse.
Here is the difference.

1. A software requirement specification describes how a product will work

entirely from the user’s (or customer’s) perspective. It should care less about
implementation. (e.g. the ‘what’ v. the ‘how’)

2. A technical specification describes the internal implementation of the

software. It talks about data structures, relational database models, choice of
programming protocols, and environmental properties.
 Experiment 3

AIM: TO DRAW USE CASE DIAGRAM FOR INSURANCE MANAGEMENT

SYSTEM.

THEORY:
Use case diagrams are usually referred to as behavior diagrams used to describe a
set of actions (use cases) that some system or systems (subject) should or can
perform in collaboration with one or more external users of the system (actors).
Each use case should provide some observable and valuable result to the actors
or other stakeholders of the system.
Actors:
Actors represent anyone or anything that interact with the system. An actor may:
 Only input information to a system
 Only retrieve information from a system
 Both input and retrieve information to and from a system
Typically, the actors are found in the problem statement, and also from
conversation with the customers and domain experts.
In UML, an actor is represented by:

Use cases:
Use cases eventually map to the menu option. Use cases represent the
functionality provided by the system. Each individual functionality provided by a
system is captured as a use case.
A use case thus represents a dialog between an actor and the system. A collection
of use cases for a system reflects all the defined ways in which a system can be
used.
A use case can be defined as a sequence of transactions performed by a system
that yields a measurable result of values for a particular actor.
In UML, a use case is represented as an oval:

Sample Use Case Diagram:

 Experiment 4

AIM: TO DESIGN SRS DOCUMENT FOR INSURANCE MANAGEMENT

SYSTEM.

Theory:
A software requirements specification (SRS) is a detailed description of a software
system to be developed with its functional and non-functional requirements. The
SRS is developed based the agreement between customer and contractors. It may
include the use cases of how user is going to interact with software system. The
software requirement specification document consistent of all necessary
requirements required for project development. To develop the software system
we should have clear understanding of Software system. To achieve this we need
to continuous communication with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal
modules, hardware, communication with other programs and human user
interactions with wide range of real life scenarios. Using the Software
requirements specification (SRS) document on QA lead, managers creates test
plan. It is very important that testers must be cleared with every detail specified
in this document in order to avoid faults in test cases and its expected results.

Structure of SRS Document:

1. Introduction:
This part provide an overview of the SRS document, and it should contain
all information needed by a software engineer to design and implement the
software product described by the requirements listed in this document.

1. Purpose:
What is the purpose of this SRS and the (intended) audience for
which it is written.
 2. Scope:
Here we will identify software product by its name, and explain what
the software product(s) will, and, if necessary, will not do. Then we
can describe the application of the software being specified. As a
portion of this, it should be consistent with similar statements in
higher-level specifications, and describe all relevant benefits,
objectives, and goals as precisely as possible.

3. Definitions and Abbreviations:

Provide the definitions of all terms, and abbreviations required to
properly interpret the SRS. This information may be provided by
reference to one or more appendixes in the SRS or by reference to
other documents.

4. References:
This subsection should provide a complete list of all documents
referenced elsewhere in the SRS, or in a separate, specified
document. Identify each document by title, report number, and
publishing organization. And specify the sources from which the
references can be obtained. This information may be provided by
reference to an appendix or to another document.

5. Overview:
Describe what the rest of the SRS contains and explain how it is
organized.

2. Overall Description:
Describe the general factors that affect the product and its requirements. It
should also be made clear that this section does not state specific
requirements, it only makes those requirements easier to understand.

1. Product Perspective:
Puts the product into perspective with other related products or
projects.
 2. Product Functions:
Provide a summary of the functions that the software will perform.

3. User Characteristics:
Describe general characteristics of the eventual users of the product
that will affect the specific requirements.

4. General Constraints:
Provide a general description of any other items that will limit the
developer’s options for designing the system.

5. Assumptions and Dependencies:

List each of the factors that affect the requirements stated in
the SRS. These factors are not design constraints on the software but
are, rather, any changes to them that can affect the requirements in
the SRS. For example, an assumption might be that a specific
operating system will be available on the hardware designated for
the software product. If, in fact, the operating system is not available,
the SRS would then have to change accordingly.

3. Specific Requirements:
Give the detailed requirements (D-requirements) that are used to guide the
project’s software design, implementation, and testing. Each requirement
in this section should be correct, unambiguous, verifiable, prioritized,
complete, consistent, and uniquely identifiable. Attention should be paid to
the carefully organize the requirements presented in this section so that
they may easily accessed and understood. Furthermore, this SRS is not the
software design document, therefore one should avoid the tendency to
over-constrain (and therefore design) the software project within this SRS.

1. External Interface Requirements:

Include user, hardware, software, and communication interfaces.

2. Functional Requirements:
Describes specific features of the software project. If desired, some
 requirements may be specified in the use-case format and listed in
the Use Cases Section.

3. Use Cases:
Describe all applicable use cases in the system.

4. Classes and Objects: Describe all classes by expressing its functions

and attributes in the system.

5. Non-Functional Requirements:
Requirements may exist for performance, reliability, availability,
security, maintainability and portability. For example (95% of
transaction shall be processed in less than a second, system
downtime may not exceed 1 minute per day, > 30 day MTBF value,
etc).

6. Design Constraints:
Specify design constrains imposed by other standards, company
policies, hardware limitation, etc. that will impact this software
project.

7. Other Requirements:
Catchall section for any additional requirements.

4. Analysis Models:
List all analysis models used in developing specific requirements previously
given in this SRS. Each model should include an introduction and a
narrative description. Furthermore, each model should be traceable the
SRS’s requirements.

1. Sequence Diagrams:
It is a kind of interaction diagram that shows how processes operate
with one another and in what order. It is a construct of a Message
Sequence Chart. A sequence diagram shows object interactions
arranged in time sequence. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between
 the objects needed to carry out the functionality of the scenario.
Sequence diagrams typically are associated with use case realizations
in the Logical View of the system under development.

2. Data Flow Diagrams:

It is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. Often they are a
preliminary step used to create an overview of the system which can
later be elaborated.

3. State-Transition Diagrams:
Describe the system as finite number of states.

5. Change Management Process:

Identify and describe the process that will be used to update the SRS, as
needed, when project scope or requirements change. Who can submit
changes and by what means, and how will these changes be approved.

6. Appendices:
Provide additional (and hopefully helpful) information. If present, the SRS
should explicitly state whether the information contained within an
appendix is to be considered as a part of the SRS’s overall set of
requirements. Example Appendices could include (initial) conceptual
documents for the software project, marketing materials, minutes of
meetings with the customer(s), etc.
 Experiment 5

AIM: TO DRAW CLASS DIAGRAM FOR INSURANCE MANAGEMENT

SYSTEM.

THEORY:
Class diagrams are the main building blocks of every object oriented methods. The
class diagram can be used to show the classes, relationships, interface,
association, and collaboration. UML is standardized in class diagrams. Since classes
are the building block of an application that is based on OOPs, so as the class
diagram has appropriate structure to represent the classes, inheritance,
relationships, and everything that OOPs have in its context. It describes various
kinds of objects and the static relationship in between them.
The main purpose to use class diagrams are:
• This is the only UML which can appropriately depict various aspects of OOPs
concept.
• Proper design and analysis of application can be faster and efficient.
• It is base for deployment and component diagram.

There are several software available which can be used online and offline to draw
these diagrams like Edraw max, Lucid chart etc. There are several points to be kept
in focus while drawing the class diagram. These can be said as its syntax:
• Each class is represented by a rectangle having a subdivision of three
compartments name, attributes and operation.
• There are three types of modifiers which are used to decide the visibility of
attributes and operations.
• + is used for public visibility (for everyone)
• # is used for protected visibility (for friend and derived)
• – is used for private visibility (for only me)
Sample Class Diagram:
 EXPERIMENT 6

AIM: TO DRAW OBJECT DIAGRAM FOR INSURANCE MANAGEMENT

SYSTEM.
THEORY:
An Object Diagram can be referred to as a screenshot of the instances in a system
and the relationship that exists between them. Since object diagrams depict
behavior when objects have been instantiated, we are able to study the behavior
of the system at a particular instant. Object diagrams are vital to portray and
understand functional requirements of a system.

In other words, “An object diagram in the Unified Modeling Language (UML), is a
diagram that shows a complete or partial view of the structure of a modeled
system at a specific time.”

Difference between an Object and a Class Diagram –

An object diagram is similar to a class diagram except it shows the instances of

classes in the system. We depict actual classifiers and their relationships making
the use of class diagrams. On the other hand, an Object Diagram represents
specific instances of classes and relationships between them at a point of time.

How to draw an Object Diagram?

1. Draw all the necessary class diagrams for the system.

2. Identify the crucial points in time where a system snapshot is needed.
3. Identify the objects which cover crucial functionality of the system.
4. Identify the relationship between objects drawn.
Uses of an Object Diagram –

• Model the static design (similar to class diagrams) or structure of a system

using prototypical instances and real data.
• Helps us to understand the functionalities that the system should deliver to
the users.
• Understand relationships between objects.
• Visualize, document, construct and design a static frame showing instances
of objects and their relationships in the dynamic story of life of a system.
• Verify the class diagrams for completeness and accuracy by using Object
Diagrams as specific test cases.
• Discover facts and dependencies between specific instances and depicting
specific examples of classifiers.

Sample Object Diagram:

 Experiment 7

AIM: TO DRAW SEQUENCE DIAGRAM FOR INSURANCE MANAGEMENT

SYSTEM.

THEORY:
Sequence diagrams model the interactions between objects in a single use case.
They illustrate how the different parts of a system interact with each other to
carry out a function, and the order in which the interactions occur when a
particular use case is executed.

In simpler words, a sequence diagram shows different parts of a system work in a

‘sequence’ to get something done.

A sequence diagram is structured in such a way that it represents a timeline which

begins at the top and descends gradually to mark the sequence of interactions.
Each object has a column and the messages exchanged between them are
represented by arrows.

Elements in Sequence Diagram:

Class Roles or Participants

Class roles describe the way an object will behave in context. Use the UML object
symbol to illustrate class roles, but don't list object attributes.

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task. When an
object is busy executing a process or waiting for a reply message, use a thin gray
rectangle placed vertically on its lifeline.
Messages
Messages are arrows that represent communication between objects. Use half-
arrowed lines to represent asynchronous messages. Asynchronous messages are
sent from an object that will not wait for a response from the receiver before
continuing its tasks. For message types, see below.
Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.

Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that
points to an X. This object is removed from memory. When that object's lifeline
ends, you can place an X at the end of its lifeline to denote a destruction
occurrence.

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place
the condition for exiting the loop at the bottom left corner in square brackets [ ].
Types of Messages in Sequence Diagrams:

Synchronous Message
A synchronous message requires a response before the interaction can continue.
It's usually drawn using a line with a solid arrowhead pointing from one object to
another.

Asynchronous Message
Asynchronous messages don't need a reply for interaction to continue. Like
synchronous messages, they are drawn with an arrow connecting two lifelines;
however, the arrowhead is usually open and there's no return message depicted.

Reply or Return Message

A reply message is drawn with a dotted line and an open arrowhead pointing back
to the original lifeline.

Self Message
A message an object sends to itself, usually shown as a U shaped arrow pointing
back to itself.

Create Message
This is a message that creates a new object. Similar to a return message, it's
depicted with a dashed line and an open arrowhead that points to the rectangle
representing the object created.

Delete Message
This is a message that destroys an object. It can be shown by an arrow with an x
at the end.

Found Message
A message sent from an unknown recipient, shown by an arrow from an endpoint
to a lifeline.

Lost Message
A message sent to an unknown recipient. It's shown by an arrow going from a
lifeline to an endpoint, a filled circle or an x.
Sample Sequence Diagram:
 EXPERIMENT 8

AIM: TO DRAW STATE CHAT DIAGRAM FOR INSURANCE

MANAGEMENT SYSTEM.

THEORY:
Statechart diagram is one of the five UML diagrams used to model the dynamic
nature of a system. They define different states of an object during its lifetime and
these states are changed by events. Statechart diagrams are useful to model the
reactive systems. Reactive systems can be defined as a system that responds to
external or internal events.

Statechart diagram describes the flow of control from one state to another state.
States are defined as a condition in which an object exists and it changes when
some event is triggered. The most important purpose of Statechart diagram is to
model lifetime of an object from creation to termination.

Statechart diagrams are also used for forward and reverse engineering of a
system. However, the main purpose is to model the reactive system.

Following are the main purposes of using Statechart diagrams:

 To model the dynamic aspect of a system.

 To model the life time of a reactive system.

 To describe different states of an object during its life time.

 Define a state machine to model the states of an object.

How to Draw a Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life
cycle. Emphasis is placed on the state changes upon some internal or external
events. These states of objects are important to analyze and implement them
accurately.

Statechart diagrams are very important for describing the states. States can be
identified as the condition of objects when a particular event occurs.

Before drawing a Statechart diagram we should clarify the following points −

• Identify the important objects to be analyzed.

• Identify the states.

• Identify the events.

Following is an example of a Statechart diagram where the state of Order object

is analyzed

The first state is an idle state from where the process starts. The next states are
arrived for events like send request, confirm request, and dispatch order. These
events are responsible for the state changes of order object.

During the life cycle of an object (here order object) it goes through the following
states and there may be some abnormal exits. This abnormal exit may occur due
to some problem in the system. When the entire life cycle is complete, it is
considered as a complete transaction as shown in the following figure. The initial
and final state of an object is also shown in the following figure.
Sample State Chart Diagram:
 EXPERIMENT 9

AIM: TO DRAW COMPONENT DIAGRAM FOR INSURANCE

MANAGEMENT SYSTEM.

THEORY:
Component diagrams are different in terms of nature and behavior. Component
diagrams are used to model the physical aspects of a system. Now the question is,
what are these physical aspects? Physical aspects are the elements such as
executables, libraries, files, documents, etc. which reside in a node.
Component diagrams are used to visualize the organization and relationships
among components in a system. These diagrams are also used to make
executable systems.

Purpose of Component Diagrams

Component diagram is a special kind of diagram in UML. The purpose is also

different from all other diagrams discussed so far. It does not describe the
functionality of the system but it describes the components used to make those
functionalities.

Thus from that point of view, component diagrams are used to visualize the
physical components in a system. These components are libraries, packages, files,
etc.

Component diagrams can also be described as a static implementation view of a

system. Static implementation represents the organization of the components at
a particular moment.

A single component diagram cannot represent the entire system but a collection
of diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as −

• Visualize the components of a system.

• Construct executables by using forward and reverse engineering.

• Describe the organization and relationships of the components.

How to Draw a Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This
artifact includes files, executables, libraries, etc.

The purpose of this diagram is different. Component diagrams are used during
the implementation phase of an application. However, it is prepared well in
advance to visualize the implementation details.

Initially, the system is designed using different UML diagrams and then when the
artifacts are ready, component diagrams are used to get an idea of the
implementation.

This diagram is very important as without it the application cannot be

implemented efficiently. A well-prepared component diagram is also important
for other aspects such as application performance, maintenance, etc.

Before drawing a component diagram, the following artifacts are to be identified

clearly −

• Files used in the system.

• Libraries and other artifacts relevant to the application.

• Relationships among the artifacts.

After identifying the artifacts, the following points need to be kept in mind.

• Use a meaningful name to identify the component for which the diagram is
to be drawn.

• Prepare a mental layout before producing the using tools.

 • Use notes for clarifying important points.

Where to Use Component Diagrams?

We have already described that component diagrams are used to visualize the

static implementation view of a system. Component diagrams are special type of

UML diagrams used for different purposes. These diagrams show the physical

components of a system. To clarify it, we can say that component diagrams

describe the organization of the components in a system. Organization can be

further described as the location of the components in a system. These

components are organized in a special way to meet the system requirements.

As we have already discussed, those components are libraries, files, executables,

etc. Before implementing the application, these components are to be organized.

This component organization is also designed separately as a part of project

execution. Component diagrams are very important from implementation

perspective. Thus, the implementation team of an application should have a

proper knowledge of the component details

Component diagrams can be used to −

• Model the components of a system.

• Model the database schema.

• Model the executables of an application.

• Model the system's source code.

Sample Component Diagram:
 Experiment 10

AIM: TO DRAW ACTIVITY DIAGRAM FOR INSURANCE MANAGEMENT

SYSTEM.

Theory:
An activity diagram is used to display the sequence of activities. Activity diagrams
show the workflow from a start point to the finish point detailing the many
decision paths that exist in the progression of events contained in the activity.
They may be used to detail situations where parallel processing may occur in the
execution of some activities. Activity diagrams are useful for business modelling
where they are used for detailing the processes involved in business activities.

Elements of Activity Diagram:

Initial State or Start Point

A small filled circle followed by an arrow represents the initial action state or the
start point for any activity diagram. For activity diagram using swimlanes, the start
point is placed in the top left corner of the first column.

Activity or Action State

An action state represents the non-interruptible action of objects.

Action Flow

Action flows, also called edges and paths, illustrate the transitions from one
action state to another. They are usually drawn with an arrowed line.

Object Flow

Object flow refers to the creation and modification of objects by activities. An

object flow arrow from an action to an object means that the action creates or
influences the object. An object flow arrow from an object to an action indicates
that the action state uses the object.

Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a

decision prior to moving on to the next activity, add a diamond between the two
activities. The outgoing alternates should be labeled with a condition or guard
expression. You can also label one of the paths "else."
Guards

In UML, guards are a statement written next to a decision diamond that must be
true before moving next to the next activity. These are not essential, but are
useful when a specific answer, such as "Yes, three labels are printed," is needed
before moving forward.

Synchronization

A fork node is used to split a single incoming flow into multiple concurrent flows.
It is represented as a straight, slightly thicker line in an activity diagram.

A join node joins multiple concurrent flows back into a single outgoing flow.

A fork and join mode used together are often referred to as synchronization.
Time Event

This refers to an event that stops the flow for a time; an hourglass depicts it.

Merge Event

A merge event brings together multiple flows that are not concurrent.

Sent and Received Signals

Signals represent how activities can be modified from outside the system. They
usually appear in pairs of sent and received signals, because the state can't
change until a response is received, much like synchronous messages in
a sequence diagram.

Interrupting Edge

An event, such as a cancellation, that interrupts the flow denoted with a lightning
bolt.
Swimlanes

Swimlanes group related activities into one column.

Sample Activity Diagram:
 Experiment 11

AIM: TO DRAW COLLABORATION DIAGRAM FOR INSURANCE

MANAGEMENT SYSTEM.

Theory:
Collaboration diagrams are almost identical to sequence diagrams in UML, but
they focus more on the relationships of objects—how they associate and connect
through messages in a sequence rather than interactions.

A collaboration diagram offers the same information as a sequence diagram, but

while a sequence diagram emphasizes the time and order of events, a
collaboration diagram emphasizes the messages exchanged between objects in an
application. They can be a useful reference for businesses, organizations, and
engineers who need to visualize and understand the physical communications
within a program.

The symbols and notations used in communication diagrams are the same
notations for sequence diagrams.

 Rectangles represent objects that make up the application.

 Lines between class instances represent the relationships between different
parts of the application.
 Arrows represent the messages that are sent between objects.
 Numbering lets you know in what order the messages are sent and how
many messages are required to finish a process.