Lab Manual

Sr. No. Title of Assignment

Choose a System of sufficient complexity and write an SRS for the
1
same.
Draw one or more Use Case Diagrams to capture and represent
2
requirements of the system.
Draw basic class diagram to identify and describe key concepts like
3
classes, types in your system and their relationships.
Draw advanced class diagram to depict advanced relationships, other
4
classifiers like interfaces.
Draw one or more Package diagram to organize and manage your
5
large and complex systems as well as complex models.
Draw activity diagrams to display either business flows or like flow
6
charts.
Draw sequence diagram with advanced notation for your system to
7
show objects and their message exchanges.
Draw state machine to model the behavior of single object,
8 specifying the sequence of events that an object goes through during
its lifetime in response to events.
Draw component diagram assuming that you will build your system
9
reusing existing components along with a few ones.
Draw deployment diagram to model the runtime architecture of your
10
system.

Assignment No. 1
Title of Assignment: Choose a System and write Software Requirement Specification(SRS)
for the same.

Relevant Theory / Literature Survey: (Brief Theory Expected)

What is a Software Requirements Specification?

An SRS is basically an organization's understanding (in writing) of a customer or potential

client's system requirements and dependencies at a particular point in time (usually) prior to
any actual design or development work. It's a two-way insurance policy that assures that both
the client and the organization understand the other's requirements from that perspective at a
given point in time.
The IEEE 830 standard defines the benefits of a good SRS:
Establish the basis for agreement between the customers and the suppliers on what the

1
 Lab Manual

software product is to do. The complete description of the functions to be performed by the
software specified in the SRS will assist the potential users to determine if the software
specified meets their needs or how the software must be modified to meet their needs
SRS contains functional and nonfunctional requirements only; it doesn't offer design
suggestions, possible solutions to technology or business issues, or any other information other
than what the development team understands the customer's system requirements to be.

What should the SRS address?

From the IEEE standard:

The basic issues that the SRS writer(s) shall address are the following:
a) Functionality. What is the software supposed to do?
b) External interfaces. How does the software interact with people, the system’s
hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc.
considerations?
e) Design constraints imposed on an implementation. Are there any required standards
in effect, implementation language, policies for database integrity, resource limits,
operating environment(s) etc.?

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

OPD System

I. Introduction
a) Purpose : Design and development of an Outdoor Patient system.
b) Scope : To automate the complete procedure of an OPD in a hospital by
using client server architecture based application.
c) Definition ,Acronymn, Abbreviation.
• Dr. Doctor
• OPD : Outdoor patient
• Sys : System
d) Overview : An automated OPD system for a hospital with 200 beds and
capacity to handle 300 OPD patients a day. It has 3 access points which
are deployed at – the receptionist, the consultancy and the pharmacist end.

Specification Requirement
a) Functional Requirement :

Name Introduction Input Processing Output

2
 Lab Manual

REGISTRATION Registers the Patient Id, Register Registration

MENU patient at the Name of the patient receipt
hospital. patient,Address, in hospital
Telephone No database
APPOINTMENT Tracks Patient Search Generate
MENU appointment Id,Genere of Doctor, appointment
detail of the disease (if Search free report for
document known) Time & the patient
Date
CASE HISTORY Keeps track Patient Updation Case
MENU of case Id,Diagnosis of case History
history of the history
patient
PATIENT’S Show details Patient Id, Update Generate
MENU of patient to Diagnosis, Case Patient
doctor Prescription History Report.
PHARMACIST’S Shows Patient Id Billing Generate
MENU prescribed Bill
medicines to
pharmacist ,
performs
billing
operation

b) External Interface Requirement

• Receptionist
a) New patient get himself registered in patient DB with unique
identity number.
b) Patient is given unique Patient ID, appointment details and
Information

Doctor
a) Using unique id, doc accesses case paper of patient.
b) Diagnose patient for ailment & update case paper& gives
Prescription.
c) Doc may refer to another Doc
d) Doc can access appointment DB

Pharmacy
a) Accesses the prescription made by Doctor
b) Fills in the prices for the medicines & makes bill.

c) Performance Requirement

3
 Lab Manual

• Proper updates
• Correct billing and schedule
• Easy data retrieval

Design Construction
• In compliance with Standards
• Entry only by receptionist at time of admission of patient

e) Attribute
• In the appointments menu, receptionist solely updates the shedule.The doc
can only view his schedule
• Cons fee only taken by the receptionist and pharmacy bill paid only at the
pharmacy

f) Other requirement
a) Database: Patient’s table,medicines table,doc schedule,paramedics table .

Requirement Analysis Document

Out Patient System
a) The hospital caters to the following
• 200 beds
• 20 or more doctors
• 300 patients / day

b) When a patient gives his details to the receptionist, the latter performs the
following activities:

1) If the patient has a history with the hospital

• his case is retrieved from the database
• Appropriate doctor is assigned
• Consultation fees is collected
• Bill is generated

2) If the patient is a first timer

 patient’s details are accepted
 He is registered with the hospital

4
 Lab Manual

 Patient is provided with an ID

 Appropriate doctor is assigned
 Consultation fees is collected
 Bill is generated

3) The paramedic in charge will enter the preliminary details of the patient such as
height, weight etc.

4) The doctor has the following role to play

 get case paper
 review it (view history, if present)
 update it with the symptoms ,diagnosis,prescription and notes.
 Forward prescription with the patient id to the pharmacy

5) The pharmacist will
get the prescription along with the patient id
Issue appropriate medicines
Generate Bill
Collect money
Print The Bill

Data Dictionary
1) Prescription.
Attribute Name Type Description

PID Numeric Foreign Key

Mname String Medicine Name
Dosage Numeric
Duration Numeric
Tdate Date
Totaltablets Numeric
Cost Numeric

2) Doctor
Attribute Name Type Description

DID Numeric Primary Key

Name String
Specialization String

5
 Lab Manual

3) Patient
Attribute Name Type Description

PID Numeric Primary Key

Name String
Phone Numeric
Age Numeric
Gender Character
Address String

4) Case Paper
Attribute Name Type Description

Tdate Date
Diagnosis Numeric
DID Numeric Foreign Key
PID Numeric Foreign key

5)Bill
Attribute Name Type Description

Amount Numeric
PID Numeric Foreign Key
BID Numeric Foreign Key

Testing: Not Applicable

(Input/ Output):

Conclusion: Thus characteristics and need of SRS are studied.

6
 Lab Manual

Assignment No. 2
Title of Assignment: Draw one or more Use Case Diagrams for capturing and
representing requirements of the system.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Use Case diagram captures use cases and actor interactions. It describes the
functional requirements of the system, the manner that outside things (actors) interact at
the system boundary and the response of the system.
Use case diagrams describe what a system does from the standpoint of an external
observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what
happens when someone interacts with the system. Here is a scenario for a medical
clinic.
"A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and
schedules the appointment for that time slot. "

7
 Lab Manual

A use case is a summary of scenarios for a single task or goal. An actor is who or what
initiates the events involved in that task. Actors are simply roles that people or objects
play. The connection between actor and use case is a communication association (or
communication for short).

Actors are stick figures. Use cases are ovals. Communications are lines that link actors
to use cases. A use case diagram is a collection of actors, use cases, and their
communications. A single use case can have multiple actors.

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following figure shows use case diagram for the sales order system.It uses “include”
and “extends” stereotypes.

8
 Lab Manual

Testing:
(Input/ Output):

Use Case Diagram Elements Use Case Diagram Connectors

Conclusion: Thus we have studied functional requirements of the system through the
usecase diagram

Assignment No. 3
Title of Assignment: Draw basic class diagram to identify and describe key

9
 Lab Manual

concepts like classes, types in your system and their relationships.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Class diagram gives an overview of a system by showing its classes and the
relationships among them. Class diagrams are static -- they display what interacts but
not what happens when they do interact.

The Class diagram captures the logical structure of the system - the classes and things
that make up the model. It is a static model, describing what exists and what attributes
and behavior it has, rather than how something is done. Class diagrams are most
useful to illustrate relationships between classes and interfaces. Generalizations,
aggregations, and associations are all valuable in reflecting inheritance, composition
or usage, and connections, respectively.
UML class notation is a rectangle divided into three parts: class name, attributes, and
operations. Relationships between classes are the connecting links.
Class diagram has three kinds of relationships.

• association -- a relationship between instances of the two classes. There is an

association between two classes if an instance of one class must know about the
other in order to perform its work. In a diagram, an association is a link
connecting two classes.
• aggregation -- an association in which one class belongs to a collection. An
aggregation has a diamond end pointing to the part containing the whole.Order
has a collection of OrderDetails.
• generalization -- an inheritance link indicating one class is a superclass of the
other. A generalization has a triangle pointing to the superclass. Payment is a
superclass of Cash, Check, and Credit

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The class diagram below models a customer order from a retail catalog. The central
class is the Order. Associated with it are the Customer making the purchase and the
Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains
OrderDetails (line items), each with its associated Item.

10
 Lab Manual

11
 Lab Manual

Testing:
(Input/ Output):

Class Diagram Elements Class Diagram Connectors

Conclusion: Thus we have studied to identify classes , attributes,operations and

relationships between them.

Assignment No. 4

12
 Lab Manual

Title of Assignment: Draw an advanced class diagram to depict advanced relationships,

other classifiers like interfaces.

Relevant Theory / Literature Survey: (Brief Theory Expected)

Class information: visibility and scope

The class notation is a 3-piece rectangle with the class name, attributes, and operations.
Attributes and operations can be labeled according to access and scope.

 Static members are underlined. Instance members are not.

 The operations follow this form:
<access specifier> <name> ( <parameter list>) : <return type>
 The parameter list shows each parameter type preceded by a colon.
 Access specifiers appear in front of each member.

Symbol Access
+ public
- private
# protected

Example :

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

13
 Lab Manual

The following diagram shows an advanced class diagram for shopping system.

Testing:
(Input/ Output):

Class Diagram Elements Class Diagram Connectors

14
 Lab Manual

Conclusion: Thus we have studied advance relationships and notations in class

diagram.

Assignment No. 5
Title of Assignment: Draw one or more Package diagram to organize and manage your
large and complex systems as well as complex models

Relevant Theory / Literature Survey: (Brief Theory Expected)

Package diagrams are used to reflect the organization of packages and their elements, and
provide a visualization of their corresponding namespaces

15
 Lab Manual

To simplify complex class diagrams, you can group classes into packages. A package is a
collection of logically related UML elements. The diagram below is a business model in
which the classes are grouped into packages.

Packages appear as rectangles with small tabs at the top. The package name is on the tab
or inside the rectangle. The dotted arrows are dependencies. One package depends on
another if changes in the other could possibly force changes in the first.

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The diagram below is a business model in which the classes are grouped into packages.

16
 Lab Manual

Testing:
(Input/ Output):

Package Diagram Elements Package Diagram Connectors

Conclusion: Thus we have studied how to organize packages and how to show
relationships between them.

Assignment No. 6

17
 Lab Manual

Title of Assignment: Draw activity diagrams to display either business flows or like
flow charts

Relevant Theory / Literature Survey: (Brief Theory Expected)

Activity diagrams are used to model the behaviors of a system, and the way in which
these behaviors are related in an overall flow of the system. The logical paths a process
follows, based on various conditions, concurrent processing, data access, interruptions
and other logical path distinctions, are all used to construct a process, system or
procedure.

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart

diagrams are related. While a statechart diagram focuses attention on an object
undergoing a process (or on a process as an object), an activity diagram focuses on the
flow of activities involved in a single process. The activity diagram shows the how those
activities depend on one another

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows an activity diagram for sales system.

18
 Lab Manual

19
 Lab Manual

Testing:
(Input/ Output):

Activity Diagram Activity Diagram

Elements Connectors

Conclusion: Thus we have studied how to represent activities and different notations
involved in an activity diagram.

Assignment No. 7

20
 Lab Manual

Title of Assignment: Draw a sequence diagram with advanced notation for your system
to show objects and their message exchanges.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A sequence diagram is an interaction diagram that details how operations are carried
out -- what messages are sent and when. Sequence diagrams are organized according to
time. The time progresses as you go down the page. The objects involved in the
operation are listed from left to right according to when they take part in the message
sequence.
A Sequence diagram is a structured representation of behavior as a series of sequential
steps over time. It is used to depict work flow, message passing and how elements in
general cooperate over time to achieve a result.

• Each sequence element is arranged in a horizontal sequence, with messages

passing back and forward between elements
• An actor element may be used to represent the user initiating the flow of events
• Stereotyped elements, such as boundary, control and entity, may be used to
illustrate screens, controllers, and database items, respectively
• Each element has a dashed stem called a lifeline, where that element exists and
potentially takes part in the interactions

Sequence diagrams are commonly used as explanatory models for use case scenarios.
By creating a sequence diagram with an actor and elements involved in the use case,
you can model the sequence of steps the user and the system undertake to complete the
required tasks. An element in a Sequence diagram is usually either an actor (the
stimulus that starts the interaction) or collaborating elements.

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows the sequence diagram for scenario Withdraw money for
ATM System.

21
 Lab Manual

22
 Lab Manual

Testing:
(Input/ Output):

Sequence Diagram Sequence Diagram

Elements Connectors

Conclusion: Thus we have studied the sequence diagram and its advanced notation
(fragments).

23
 Lab Manual

Assignment No. 8
Title of Assignment: Draw state machine to model the behavior of single object,
specifying the sequence of events that an object goes through
during its lifetime in response to events.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A State Machine diagram illustrates how an element, often a class, can move between
states classifying its behavior, according to transition triggers, constraining guards and
other aspects of State Machine diagrams that depict and explain movement and behavior.

A state represents a situation where some invariant condition holds; this condition can be
static, ie. waiting for an event, or dynamic, ie. performing a set of activities. State
modeling is usually related to classes, and describes the allowable states a class or
element may be in and the transitions that allow the element to move there. There are
three types of states: simple states, composite states and submachine states.

You can add a sub-machine element to a State Machine diagram. A sub-machine element
is a pointer to a child State Machine diagram.

There are two types of history pseudo-states defined in UML, shallow and deep history.
A shallow history sub-state is used to represent the most recently active sub-state of a
composite state; this pseudo-state does not recurse into this sub-state's active
configuration, should one exist. A single connector can be used to depict the default
shallow history state, in case the composite state has never been entered.

A deep history sub-state, in contrast, reflects the most recent active configuration of the
composite state. This includes active sub-states of all regions, and recurses into those sub-
states' active sub-states, should they exist. At most one deep history and one shallow
history can dwell within a composite state

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram illustrates some features of State Machine diagrams. The
Saved state is a composite state, and enclosed states are sub-states. Initial and final
pseudo-states indicate the entry to and exit from the state machine.

24
 Lab Manual

25
 Lab Manual

Testing:
(Input/ Output):

State Machine Diagram State Machine Diagram

Elements Connectors

Conclusion: Thus we have studied how to model behavior of single object using state
machine diagram.

Assignment No. 9

26
 Lab Manual

Title of Assignment: Draw component diagram assuming that you will build your
system reusing existing components along with a few ones.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Component diagram illustrates the pieces of software, embedded controllers, etc. that
will make up a system. A Component diagram has a higher level of abstraction than a
Class diagram - usually a component is implemented by one or more classes (or objects)
at runtime. They are building blocks, such that eventually a component can encompass a
large portion of a system.

A component is a code module. Component diagrams are physical analogs of class

diagram.

A component is a modular part of a system, whose behavior is defined by its provided

and required interfaces; the internal workings of the component should be invisible and
its usage environment-independent. Source code files, DLLs, Java beans and other
artifacts defining the system may be manifested in components.

A component may be composed of multiple classes, or components pieced together. As

smaller components come together to create bigger components, the eventual system can
be modeled, building-block style. By building the system in discrete components,
localization of data and behavior allows for decreased dependency between classes and
objects, providing a more robust and maintainable design.

Ports define the interaction between a classifier and its environment. Interfaces
controlling this interaction can be depicted by using the expose interface toolbox element.
Any connector to a port must provide the required interface, if defined. Ports can appear
on either a contained part, a class, or on the boundary of a composite structure.

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows component diagram for sales management system

27
 Lab Manual

Testing:
(Input/ Output):

Component Diagram Elements Component Diagram Connectors

Conclusion: Thus we have studied how to identify components and how to show
dependencies between them.

Assignment No. 10
Title of Assignment: Draw a deployment diagram to model the runtime architecture of

28
 Lab Manual

your system.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Deployment diagram shows how and where the system will be deployed. Physical
machines and processors are reflected as nodes, and the internal construction can be
depicted by embedding nodes or artifacts. As artifacts are allocated to nodes to model the
system's deployment, the allocation is guided by the use of deployment specifications.

Deployment diagrams show the physical configurations of software and hardware.

A deployment specification (spec) specifies parameters guiding deployment of an artifact,
as is necessary with most hardware and software technologies. A specification lists those
properties that must be defined for deployment to occur. An instance of this specification
specifies the values for the parameters; a single specification can be instantiated for
multiple artifacts.

These specifications can be extended by certain component profiles. Examples of

standard tagged values that a profile might add to a deployment specification are
«concurrencyMode» with tagged values {thread, process, none} or «transactionMode»
with tagged values {transaction, nestedTransaction, none}.

Design Analysis / Implementation Logic:

(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

Below is an example Deployment diagram. The two nodes have a TCP/IP communication
path indicated. Deployment relationships indicate the deployment of artifacts.
Furthermore, a deployment spec defines the process of deployment for the
networkScanner artifact. The manifestation relationships reveals the physical
implementation of components ReposCustomer and ReposInternalRecords.

29
 Lab Manual

Testing:
(Input/ Output):

Deployment Diagram Elements Deployment Diagram Connectors

Conclusion: Thus we have studied to deploy the system using deployment diagram

30
 Lab Manual

31