COLLEGE OF TECHNOLGY AND ENGINEERING

MAHARANA PRATAP UNIVERSITY OF AGRICULTURE & TECHNOLGY, UDAIPUR

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

E-MANUAL

CS326 - SOFTWARE ENGINEERING

PREPARED BY

Mrs. Kalpana Jain

Assistant Professor
 DISCLAIMER

The E-Manual on “Software Engineering” is prepared as per the

syllabus offered to students of Computer Science & Engineering, CTAE,
MPUAT, Udaipur, enrolled for undergraduate (B. Tech) degree programme.

This document is a compilation of materials provided in text books,

and e-contents freely available on online sources. The author does not claim
for originality of work. This is meant purely for academic purpose for
students of Computer Science and Engineering, CTAE, MPUAT as a
reference Material for understanding of course. Multiplication and use of this
e-manual for commercial activity is strictly prohibited.

However, author shall in no event be liable for any errors, omissions

or damages arising out of use this information and specially disclaim any
warranties or merchantability or fitness for any particular use.
 Subject Code & Title: CS326 – SOFTWARE ENGINEERING

This lab deals with the analysis and design of a software problem .the tool used in a lab is
rational rose .this tool is used for a object oriented design of a problem . We draw a uml
diagram in a rational rose which deals with the objects and classes in a system .The Unified
Modeling Language or UML is is a mostly graphical modeling language that is used to
express designs. It is a standardized language in which to specify the items and components
of a software system. It is important to understand that the UML describes a notation and not
a process. It does not put forth a single method or process of design, but rather is a
standardized tool that can be used in a design process.

The Unified Modeling Language (UML) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a collection of best
engineering practices that have proven successful in the modeling of large and complex
systems. The UML is a very important part of developing objects oriented software and the
software development process.

The UML uses mostly graphical notations to express the design of software projects. Using
the UML helps project teams communicate, explore potential designs, and validate the
architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:

o Provide users with a ready-to-use, expressive visual modeling language so

they can develop and exchange meaningful models.
o Provide extensibility and specialization mechanisms to extend the core concepts.
o Be independent of particular programming languages and development processes.
o Provide a formal basis for understanding the modeling language.
o Encourage the growth of the OO tools market.
o Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
o Integrate best practices.

Why Use UML?

As the strategic value of software increases for many companies, the industry looks for
techniques to automate the production of software and to improve quality and reduce cost
and time-to-market. These techniques include component technology, visual programming,
patterns and frameworks. Businesses also seek techniques to manage the complexity of
CS326: Software Engineering 1
 systems as they increase in scope and scale. In particular, they recognize the need to solve
recurring architectural problems, such as physical distribution, concurrency, replication,
security, load balancing and fault tolerance.

List of Practical’s
(As per the syllabus prescribed by MPUAT University)
Choose any one project and do the following exercises for that project

Student Result Management System

Library management system
Inventory control system
Accounting system
Fast food billing system
Bank loan system
Reservation System
Share online trading
Hostel Management or
Any other according to student’s choice

1. Write the complete problem statement

2. Write the software requirement specification document
3. Draw the entity relationship diagram
4. Draw the data flow diagrams at level 0 and level 1
5. Draw use case diagram
6. Draw activity diagram of all use cases.
7. Draw state chart diagram of all use cases
8. Draw sequence diagram of all use cases
9. Draw collaboration diagram of all use cases

THEORY: Write the complete problem statement

The problem statement is the initial starting point for a project. It is basically a one to three
page statement that everyone on the project agrees with that describes what will be done at a
high level. The problem statement is intended for a broad audience and should be written in
non- technical terms. It helps the non-technical and technical personnel communicate by
providing a description of a problem. It doesn't describe the solution to the problem.
CS326: Software Engineering 2
The input to requirement engineering is the problem statement prepared by customer.
It may give an overview of the existing system along with broad expectations from the new
system.

The first phase of requirements engineering begins with requirements elicitation i.e. gathering
of information about requirements. Here, requirements are identified with the help of
customer and existing system processes. So from here begins the preparation of problem
statement.
So, basically a problem statement describes what needs to be done without describing how.

Conclusion: The problem statement was written successfully by following the steps
described above.

CS326: Software Engineering 3

 Write the software requirement specification document

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 SRS document itself states in precise and explicit language those functions and
capabilities a software system (i.e., a software application, an eCommerce Web site, and so
on) must provide, as well as states any required constraints by which the system must abide.
The SRS also functions as a blueprint for completing a project with as little cost growth as
possible. The SRS is often referred to as the "parent" document because all subsequent project
management documents, such as design specifications, statements of work, software
architecture specifications, testing and validation plans, and documentation plans, are related
to it.

It's important to note that an 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.

A well-designed, well-written SRS accomplishes four major goals:

o It provides feedback to the customer. An SRS is the customer's assurance that the
development organization understands the issues or problems to be solved and the
software behavior necessary to address those problems. Therefore, the SRS should be
written in natural language (versus a formal language, explained later in this article), in
an unambiguous manner that may also include charts, tables, data flow diagrams,
decision tables, and so on.
o It decomposes the problem into component parts. The simple act of writing down
software requirements in a well-designed format organizes information, places borders
around the problem, solidifies ideas, and helps break down the problem into its
component parts in an orderly fashion.
o It serves as an input to the design specification. As mentioned previously, the SRS serves
as the parent document to subsequent documents, such as the software design
specification and statement of work. Therefore, the SRS must contain sufficient detail in
the functional system requirements so that a design solution can be devised.
o It serves as a product validation check. The SRS also serves as the parent document for
testing and validation strategies that will be applied to the requirements for verification.

CS326: Software Engineering 4

SRSs are typically developed during the first stages of "Requirements Development," which
is the initial product development phase in which information is gathered about what
requirements are needed--and not. This information-gathering stage can include onsite visits,
questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or
needs analysis of the customer or client's current business environment. The actual
specification, then, is written after the requirements have been gathered and analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:

Functionality. What is the software supposed to do?

External interfaces. How does the software interact with people, the system„s
hardware, other hardware, and other software?
Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?
Attributes. What are the portability, correctness, maintainability, security, etc.
considerations?
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.?

Characteristics of a good SRS

An SRS should be

 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable

Correct - This is like motherhood and apple pie. Of course you want the specification to be
correct. No one writes a specification that they know is incorrect. We like to say - "Correct
and Ever Correcting." The discipline is keeping the specification up to date when you find
things that are not correct.

CS326: Software Engineering 5

Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has
only one interpretation. Again, easier said than done. Spending time on this area prior to
releasing the SRS can be a waste of time. But as you find ambiguities - fix them.

Complete - A simple judge of this is that is should be all that is needed by the software
designers to create the software.

Consistent - The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in
another.

Ranked for Importance - Very often a new system has requirements that are really
marketing wish lists. Some may not be achievable. It is useful provide this information in
the SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast response."
Another of my favorites is - "The system should never crash." Instead, provide a quantitative
requirement like: "Every key stroke should provide a user response within 100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong - but
tends to make the document not maintainable.

Traceable - Often, this is not important in a non-politicized environment. However, in most

organizations, it is sometimes useful to connect the requirements in the SRS to a higher level
document.

A sample of basic SRS Outline

Introduction
Purpose
Document conventions
Intended audience
Additional information
Contact information/SRS team members
References

Overall Description
Product perspective
Product functions
User classes and characteristics
Operating environment
User environment

CS326: Software Engineering 6

Design/implementation constraints
Assumptions and dependencies

External Interface Requirements

User interfaces
Hardware interfaces
Software interfaces
Communication protocols and interfaces

System Features
System feature A
Description and priority
Action/result
Functional requirements
System feature B

Other Nonfunctional Requirements

Performance requirements
Safety requirements
Security requirements
Software quality attributes
Project documentation
User documentation

Other Requirements
Appendix A: Terminology/Glossary/Definitions
list Appendix B: To be determined

CS326: Software Engineering 7

 HOSPITAL MANAGEMENT MINI PROJECT

INTRODUCTION:

Hospital are the essential part of our lives, providing best medical facilities to people suffering from
various ailments, which may be due to change in climatic conditions, increased work-load,
emotional trauma stress etc. It is necessary for the hospitals to keep track of its day-to-day activities
& records of its patients, doctors, nurses, ward boys and other staff personals that keep the hospital
running smoothly & successfully. But keeping track of all the activities and their records on paper
is very cumbersome and error prone. It also is very inefficient and a time-consuming process
Observing the continuous increase in population and number of people visiting the hospital.
Recording and maintaining all these records is highly unreliable, inefficient and error-prone. It is
also not economically & technically feasible to maintain these records on paper. Thus keeping the
working of the manual system as the basis of our project. We have developed an automated version
of the manual system, named as “Hospital Management System”. The main aim of our project is to
provide a paper-less hospital up to 90%. It also aims at providing low-cost reliable automation of
the existing systems. The system also provides excellent security of data at every level of user-
system interaction and also provides robust & reliable storage and backup facilities.

Objectives of the system:

The project “Hospital management system” is aimed to develop to maintain the day –to-day state of
admission/discharge of patients, list of doctors, reports generation, and etc.It is designed to achieve
the following objectives:
1. To computerize all details regarding patient details & hospital details.
2. Scheduling the appointment of patient with doctors to make it convenient for both.
3. Scheduling the services of specialized doctors and emergency properly so that facilities
provided by hospital are fully utilized in effective and efficient manner.
4. If the medical store issues medicines to patients, it should reduce the stock status of the
medical store and vice-versa. 5. It should be able to handle the test reports of patients
conducted in the pathology lab of the hospital.
6. The inventory should be updated automatically whenever a transaction is made.
7. The information of the patients should be kept up to date and there record should be kept
in the system for historical purposes.

Input:
 Patient Information.
 Medicine Details.
 Bed Details.
 Details of Doctors.
 Payment Details.

CS326: Software Engineering 8

  Staff Information.

Operations:

 Administration
 Login
 Insert Patient, Medicine, Equipment and Staff Details.

 Patient
 Book appointments.
 Check on Medicine.
 Search Doctor/Disease.
 Online pay.

 Output
 Booking Confirmation.
 Scheduled Dates.

 Constraints
 All the patient must register themselves into the system.
 Login information contains only customer id and password.
 A customer can only view his/her appointment details.

USE CASE DIAGRAM:

A use case diagram at its simplest is a representation of a user‟s interaction with the system that
shows the relationship between the user and the different use cases in which the user is involved. A
use case diagram can identify the different types of users of a system and the different use cases and
will often be accompanied by other types of diagrams as well. Use case diagrams provide the
simplified and graphical representation of what the system must actually do. Due to their simplistic
nature, Use case diagrams can be a good communication tool for stakeholders. The drawings
attempt to mimic the real world and provide a view for the stakeholder to understand how the
system is going to be designed. The purpose of use case diagrams is simply to provide the high
level view of the system and convey the requirements in layman's terms for the stakeholders.

CS326: Software Engineering 9

USE CASE DIAGRAM FOR HOSPITAL MANAGEMENT SYSTEM:

CS326: Software Engineering 10

ACTIVITY DIAGRAM
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system. Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system. The control flow is drawn
from one operation to the another. This flow can be sequential, branched or concurrent. Activity
diagrams deal with all type of flow control by using different elements such as fork, join, etc. The
basic purpose of activity diagrams is to describe the activity flow of a system. It describes the
sequence from one activity to another and also describes the parallel, branched and concurrent flow
of the system.

ACTIVITY DIAGRAM FOR HOSPITAL MANAGEMENT SYSTEM:

CS326: Software Engineering 11

SEQUENCE DIAGRAM:

A sequence diagram shows object interactions 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 are typically associated with use case realizations in the Logical view of the
system under development. Sequence diagrams are sometimes called event diagrams or event
scenarios. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or
objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them,
in the order in which they occur.

This allows the specification of simple runtime scenarios in a graphical manner. If the lifeline is
that of an object, it demonstrates a role. Leaving the instance name blank can represent anonymous
and unnamed instances. Messages written with horizontal arrows with the message name written
above them, display interaction. Solid arrow heads represent synchronous calls, open arrow heads
represent asynchronous messages, and dashed lines represent reply messages.

If a caller sends a synchronous message, it must wait until the message is done, such as invoking a
subroutine. If a caller sends an asynchronous message, it can continue processing and doesn‟t have
to wait for a response. Asynchronous calls are present in multithreaded applications, event driven
applications and in message-oriented middleware. Activation boxes, or method-call boxes, are
opaque rectangles drawn on top of lifelines to represent that processes are being performed in
response to the message. Object calling methods on themselves use messages and add new
activation boxes on top of any others to indicate a further level of processing.

CS326: Software Engineering 12

SEQUENCE DIAGRAM FOR HOSPITAL MANAGEMENT SYSTEM:

CS326: Software Engineering 13

CLASS DIAGRAM:
A class diagram in the UML is a type of static structure diagram that describes the structure of a
system by showing the system's classes, their attributes, operations (or methods), and the
relationships among objects. Purpose of Class diagrams:
1. Shows static structure of classifiers in a system.

2. Provides basic notation for other structure diagrams prescribed by UML.

3. Helpful for developers and other team members.
4. Business Analysts can use class diagrams to model systems from business perspective.

CLASS NOTATION:
A class notation consists of three parts:
1). Class Name: The name of the class appears in first partition.

2). Class Attributes: - Attributes are shown in the second partition. - The attribute type is shown
after the colon. - Attributes map onto member variables (data members in code).

3). Class Operations (methods): - Operations are shown in the third partition. They are services the
class provides. - The return type of a method is shown after the colon at the end of the method
signature. - The return type of method parameters are shown after the colon following the
parameter name. - Operations map onto class methods in code.

CLASS RELATIONSHIPS
1). Inheritance (or Generalization): Represents an IS-A relationship.
2). Simple Association: A structural link between two peer classes.
3). Aggregation: A special type of association. It represents a “part of” relationship.

4). Composition: A special type of aggregation where parts are destroyed when the whole is
destroyed. 5). Dependency: Exists between two classes if changes to the definition of one may
cause changes to the other (but not the other way around).

CS326: Software Engineering 14

CLASS DIAGRAM FOR HOSPITAL MANAGEMENT SYSTEM:

CS326: Software Engineering 15

DATA FLOW DIAGRAM:
A data flow diagram (DFD) maps out the flow of information for any process or system. Data
flowcharts can range from simple, even hand drawn process overviews, to in-depth, multi-level
DFDs that dig progressively deeper into how the data is handled. They can be used to analyze an
existing system model or a new one.

SYMBOLS USED IN DFD:

1. External Entity: an outside system that sends or receives data, communicating with the system
being diagrammed. They are the sources and destinations of information entering or leaving the
system. They are also known as terminators, sources and sinks or actors.

2. Process: any process that changes the data, producing an output. It might perform computations,
or sort data based on logic, or direct the data flow based on business rules.

3. Data Store: files or repositories that hold information for later use, such as a database table or a
membership form. Each data store receives a simple label.

4. Data flow: the route that data takes between the external entities, processes and data stores. It
portrays the interface between the other components and is shown with arrows, typically labeled
with a short data name

DFD Level 0:

CS326: Software Engineering 16

DFD level 1:

CS326: Software Engineering 17