GYAN GANGA INSTITUTE OF TECHNOLOGY AND SCIENCES, JABALPUR

DEPARTMENT OF COMPUTER SCIENCE & BUSINESS SYSTEM(CSBS)

LAB MANUAL

SOFTWARE ENGINEERING

(CB-403)

SESSION: 2022-23

SUBMITTED TO : Prof. PRAKRITI KAPOOR

SUBMITTED BY : GRP 2 (TEMPORARY)

ENROLLMENT NUMBER :

Page 1 of 49
 List of Experiment

Sr. Page
Topics/Subtopics Date Signature Grade
No. No.
Introduction toObject Oriented Technologies
1 4
and the UML Method.
2 18
Introduction to the UML Language.
Develop requirements specification for a
given problem (The requirements
3 specification should include both functional
and non-functional requirements for your 21
sample problem statement)
Develop DFD Model (Level 0, Level 1 DFD
4 26
and data dictionary) of the sample problem
Requirements Analysis Using Case Modeling 29
5
Develop Sequence Diagrams 30
6
Develop Collaboration Diagrams 32
7
Develop Class diagrams.
8 34
Package Diagram Model.
9 36
Dynamic Model: State Diagram / Activity
10 38
Diagram.
Component Diagram Model and Deployment
11 41
Model
12 Study the use of CASE tools. 44

Page 2 of 49
 HOSPITAL MANAGEMENT SYSTEM
Objective:

The objective of the Hospital Management System software is to streamline and automate the
administrative and clinical workflows of healthcare facilities. This software will assist healthcare
professionals in managing patient information, scheduling appointments, maintaining electronic
medical records, managing inventory, generating reports, and facilitating billing and payment
processes. The system aims to improve the overall efficiency and effectiveness of healthcare
operations and enhance patient care delivery.

Abstract:

The Hospital Management System software is a comprehensive solution designed to automate

and streamline the administrative and clinical workflows of healthcare facilities. The software
facilitates the digitization of patient data, appointment scheduling, and medical record
maintenance, which allows for efficient and accurate patient care delivery. The system provides
real-time access to patient information, including medical history, lab results, and prescriptions,
to authorized healthcare professionals. It also enables healthcare providers to manage inventory,
generate reports, and facilitate billing and payment processes. The Hospital Management System
software is a user-friendly and secure system that enhances the overall efficiency and
effectiveness of healthcare operations while providing a superior patient experience.

Page 3 of 49
 Experiment No.1
Aim: Introduction to Object Oriented Technologies and the UML Method.

Object-Oriented Technologies are a set of programming paradigms that provide a way of

modeling and designing software systems based on the concepts of objects, classes, inheritance,
and polymorphism. The UML (Unified Modeling Language) is a widely used visual modeling
language for object-oriented systems that helps to communicate, visualize, specify, and
document software systems.

❖ Software Development Process: The Waterfall Model vs. The Spiral Model:

Waterfall Model

The Waterfall Model is a linear sequential approach to software development where the
development process is divided into distinct phases such as requirement gathering, design,
implementation, testing, deployment, and maintenance. Each phase is completed before moving
on to the next phase. This model is easy to understand and implement, but it lacks flexibility and
feedback mechanisms.

Phases of Waterfall Model

● Feasibility Study: The main goal of this phase is to determine whether it would be
financially and technically feasible to develop the software. The feasibility study involves
understanding the problem and then determining the various possible strategies to solve
the problem. These different identified solutions are analyzed based on their benefits and
drawbacks, The best solution is chosen and all the other phases are carried out as per this
solution strategy.

● Requirements analysis and specification: The aim of the requirement analysis and
specification phase is to understand the exact requirements of the customer and document
them properly. This phase consists of two different activities.
1. Requirement gathering and analysis: Firstly all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an incomplete
requirement is one in which some parts of the actual requirements have been omitted) and
inconsistencies (an inconsistent requirement is one in which some part of the requirement
contradicts some other part).
2. Requirement specification: These analyzed requirements are documented in a software
requirement specification (SRS) document. The SRS document serves as a contract

Page 4 of 49
 between the development team and customers. Any future dispute between the customers
and the developers can be settled by examining the SRS document.

● Design: The goal of this phase is to convert the requirements acquired in the SRS into a
format that can be coded in a programming language. It includes high-level and detailed
design as well as the overall software architecture. A Software Design Document is used
to document all of this effort (SDD)

● Coding and Unit testing: In the coding phase software design is translated into source
code using any suitable programming language. Thus each designed module is coded.
The aim of the unit testing phase is to check whether each module is working properly or
not.

● Integration and System testing: Integration of different modules are undertaken soon
after they have been coded and unit tested. Integration of various modules is carried out
incrementally over a number of steps. During each integration step, previously planned
modules are added to the partially integrated system and the resultant system is tested.
Finally, after all the modules have been successfully integrated and tested, the full
working system is obtained and system testing is carried out on this.

● Maintenance: In this phase, the software is maintained and updated to fix any issues that
arise after deployment. This includes bug fixes, software updates, and enhancements. The
maintenance phase is ongoing and can continue for the entire lifecycle of the software.

Figure 1.1: Phases of Waterfall Model

Page 5 of 49
Advantages of Classical Waterfall Model

The classical waterfall model is an idealistic model for software development. It is very simple,
so it can be considered the basis for other software development life cycle models. Below are
some of the major advantages of this SDLC model:

● This model is very simple and is easy to understand.

● Phases in this model are processed one at a time.
● Each stage in the model is clearly defined.
● This model has very clear and well-understood milestones.
● Process, actions and results are very well documented.
● Reinforces good habits: define-before- design,design-before-code.
● This model works well for smaller projects and projects where requirements are well
understood.

Drawbacks of Classical Waterfall Model:

The classical waterfall model suffers from various shortcomings, basically, we can’t use it in real
projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model:

● No feedback path: In the classical waterfall model evolution of software from one phase
to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for error
correction.

● Difficult to accommodate change requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customers’ requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.

● No overlapping of phases: This model recommends that a new phase can start only after
the completion of the previous phase. But in real projects, this can’t be maintained. To
increase efficiency and reduce cost, phases may overlap.
● Limited flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or

Page 6 of 49
 uncertain requirements. Once a phase has been completed, it is difficult to make changes
or go back to a previous phase.
● Limited stakeholder involvement: The Waterfall Model is a structured and sequential
approach, which means that stakeholders are typically involved in the early phases of the
project (requirements gathering and analysis) but may not be involved in the later phases
(implementation, testing, and deployment).
● Late defect detection: In the Waterfall Model, testing is typically done towards the end
of the development process. This means that defects may not be discovered until late in
the development process, which can be expensive and time-consuming to fix.
● Lengthy development cycle: The Waterfall Model can result in a lengthy development
cycle, as each phase must be completed before moving on to the next. This can result in
delays and increased costs if requirements change or new issues arise.
● Not suitable for complex projects: The Waterfall Model is not well-suited for complex
projects, as the linear and sequential nature of the model can make it difficult to manage
multiple dependencies and interrelated components.

Spiral Model

The Spiral Model is a software development life cycle (SDLC) model that provides a systematic
and iterative approach to software development. It is based on the idea of a spiral, with each
iteration of the spiral representing a complete software development cycle, from requirements
gathering and analysis to design, implementation, testing, and maintenance.

The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through
multiple iterations of the software development process.

Phases of Spiral Model

● Planning: The first phase of the Spiral Model is the planning phase, where the scope of
the project is determined and a plan is created for the next iteration of the spiral.
● Risk Analysis: In the risk analysis phase, the risks associated with the project are
identified and evaluated.
● Engineering: In the engineering phase, the software is developed based on the
requirements gathered in the previous iteration.
● Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.
● Planning: The next iteration of the spiral begins with a new planning phase, based on the
results of the evaluation.

Page 7 of 49
 Figure 1.2: Phases of Spiral Model

Advantages of Spiral Model:

● Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the
risk analysis and risk handling at every phase.
● Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
● Flexibility in Requirements: Change requests in the Requirements at a later phase can
be incorporated accurately by using this model.
● Customer Satisfaction: Customers can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.
● Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and adaptability
in response to changing requirements or unexpected events.

Page 8 of 49
 ● Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the software
development process.
● Improved Communication: The Spiral Model provides for regular evaluations and
reviews, which can improve communication between the customer and the development
team.
● Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability

Disadvantages of Spiral Model:

● Complex: The Spiral Model is much more complex than other SDLC models.
● Expensive: Spiral Model is not suitable for small projects as it is expensive.
● Too much dependability on Risk Analysis: The successful completion of the project is
very much dependent on Risk Analysis. Without very highly experienced experts, it is
going to be a failure to develop a project using this model.
● Difficulty in time management: As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
● Complexity: The Spiral Model can be complex, as it involves multiple iterations of the
software development process.
● Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
● Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.

Difference between Waterfall Model and Spiral Model

Sr WATERFALL MODEL SPIRAL MODEL

no.

1 The Waterfall model is simple and easy. The spiral model is a lot more complex.

2 The waterfall model works in a sequential While the spiral model works in the
method. evolutionary method.

3 In the waterfall model errors or risks are In the spiral model errors or risks are
identified and rectified after the identified and rectified earlier.
completion of stages.

4 The waterfall model is adopted by While the spiral model is adopted by

customers. developers.

Page 9 of 49
 5 While the spiral model is adopted by While the Spiral model is used for large
developers. projects.

6 In waterfall model requirements and early While in spiral model requirements and
stage planning is necessary. early stage planning is necessary if
required.

7 Flexibility to change in the waterfall Flexibility to change in a spiral model is not

model is Difficult. Difficult.

8 There is a high amount of risk in the There is low risk in the spiral model.
waterfall model.

9 Waterfall model is comparatively The cost of the spiral model is very

inexpensive. expensive.

10 Customer involvement is minimum in In the Spiral Model Customer involvement

Waterfall Model is high.

11 It requires least maintenance. It requires typical maintenance.

12 It is based on a linear framework type. It is based on linear and iterative framework

types.

13 Testing is done after the coding phase in Testing is done after the engineering phase
the development life cycle. in the development cycle.

14 Reusability is extremely unlikely. To a certain extent, reusability is possible.

15 Customer control over the administrator is Customers have control over the
very limited. administrator as compared to the waterfall
model.
Table 1.1: Difference between Waterfall Model and Spiral Model

❖ The Software Crisis, Description of the Real World using the Objects Model:

Software Crisis-
The software crisis is a common occurrence in the software development industry, and it can
have serious consequences for businesses and organizations. Here are some reasons why
software projects can fail:

1.Poor Project Management: One of the leading causes of software project failure is poor project
management. This can include inadequate planning, poor communication, lack of coordination,

Page 10 of 49
 insufficient resources, and unrealistic expectations.

2.Insufficient Testing: Software testing is a critical component of the software development

process, as it helps identify defects and errors before the software is released. Insufficient testing
can lead to the release of software that contains bugs or other defects, which can result in
customer dissatisfaction and lost revenue.

3.Scope Creep: Scope creep occurs when the scope of a software project grows beyond its original
boundaries, which can lead to delays, increased costs, and reduced quality. This can happen
when new requirements are added to the project without proper evaluation or when there is a
lack of clear scope definition from the beginning.

4. Inadequate Resources: Software projects can fail if there are inadequate resources allocated
to them. This can include insufficient staffing, lack of expertise, insufficient budget, and
inadequate technology infrastructure.

5. Changing Requirements: Software projects can fail if the requirements change too frequently
or are not clearly defined from the beginning. This can lead to project delays, increased costs,
and reduced quality, as well as frustration for the development team and stakeholders.

6. Technological Obsolescence: Software projects can fail if the technology used becomes
obsolete before the project is completed. This can happen when the project takes too long, and
new technologies emerge that make the software obsolete before it is released.

In conclusion, software project failure is a common occurrence in the software development

industry, and it can have serious consequences for businesses and organizations. Software project
failures can be caused by poor project management, insufficient testing, scope creep, inadequate
resources, changing requirements, and technological obsolescence. It is crucial to identify these
potential problems and address them proactively to increase the chances of software project
success.

Objects Model

● Object models are used in software engineering to represent real-world objects and their
relationships in software systems.
● Objects are entities that have attributes and behavior.
● Attributes are characteristics of an object, such as size, color, or weight.
● Behavior refers to the actions that an object can perform, such as moving, talking, or
calculating.
● Methods and properties are used in the Objects Model to represent an object's behavior
and attributes.
● Object models are a fundamental concept in Object-Oriented Programming, which is
widely used in modern software engineering.

Page 11 of 49
Description of the Real World using the Objects Model:

● The Objects Model provides a way to describe the real world in terms of objects.
● This makes it easier to design software systems that accurately reflect the real world.
● In addition to physical objects, abstract concepts such as events, processes, and
relationships can also be represented using the Objects Model.
● Relationships between objects can be represented using the Objects Model.
● The Objects Model provides a powerful and flexible way to describe the real world in
terms of objects.

❖ Classes, Inheritance, and Multiple Configurations:

Classes

In Object Oriented Programming, a class is a blueprint or template for creating objects. A class
defines the properties (attributes) and behaviors (methods) that objects of that class will have.

For example, let's say we want to create a class called "Car". The Car class would define the
attributes of a car such as color, make, model, and year, as well as methods such as start(), stop(),
and accelerate().

Inheritance

Inheritance is a fundamental concept in object-oriented programming (OOP) that allows a new

class to be based on an existing class. The new class is called the derived class or subclass, and
the existing class is called the base class or superclass. Inheritance allows the derived class to
inherit the properties and behaviors of the base class, which can then be customized or extended
as needed.

For example, let's say we have a base class called Animal, which has attributes such as name and
age, and methods such as eat() and sleep(). We can create a derived class called Dog that inherits
from the Animal class and adds its own unique properties and behaviors.

Multiple Configurations

Page 12 of 49
In object-oriented programming, multiple configurations refer to the ability to create different
variations of a class by combining different sets of features or behaviors. This is achieved
through the use of interfaces and abstract classes.

Interfaces are a way to define a set of methods that a class must implement, without providing
any implementation details. Abstract classes, on the other hand, are classes that cannot be
instantiated on their own, but can be subclassed to create concrete classes that inherit their
properties and methods.

By combining different interfaces and abstract classes, we can create multiple configurations of a
class that have different sets of behaviors. For example, let's say we have an interface called
Flyable that defines a fly() method, and an abstract class called Animal that has methods such as
eat() and sleep(). We can create a class called Bird that implements the Flyable interface and
inherits from the Animal class, and a class called Dog that only inherits from the Animal class.

❖ Quality Software Characteristics:

Quality software can be defined as software that meets or exceeds customer expectations, is
reliable, easy to use, maintainable, and performs well. There are several characteristics that
define quality software, including:

● Functionality: This refers to the ability of the software to meet the functional
requirements of the customer. In other words, the software should perform the tasks that
it was designed to do.

● Reliability: This refers to the ability of the software to perform consistently and
accurately under a variety of conditions. Reliable software should be able to handle errors
and exceptions gracefully, and should be robust enough to continue working even if
unexpected events occur.

● Usability: This refers to how easy the software is to use. The software should be intuitive
and user-friendly, with clear instructions and a consistent interface.

● Efficiency: This refers to the speed and resource usage of the software. Efficient software
should perform tasks quickly and use system resources (such as memory and CPU)
efficiently.

Page 13 of 49
 ● Maintainability: This refers to how easy it is to maintain and modify the software.
Well-designed software should be modular and easy to understand, with clear
documentation and comments.

● Portability: This refers to the ability of the software to run on different platforms and
hardware configurations. Portable software should be designed to be compatible with
different operating systems and hardware configurations.

● Testability: This refers to how easy it is to test the software. Quality software should be
designed with testing in mind, with clear separation of concerns and well-defined
interfaces.

● Security: This refers to the ability of the software to protect data and resources from
unauthorized access. Secure software should be designed with security in mind, with
appropriate authentication and authorization mechanisms.

In summary, quality software is defined by several characteristics, including functionality,

reliability, usability, efficiency, maintainability, portability, testability, and security. By designing
software with these characteristics in mind, developers can create software that meets or exceeds
customer expectations and performs well in a variety of conditions.

❖ Description of the Object-Oriented Analysis Process vs. the Structure Analysis

Model:
Object-Oriented Analysis (OOA) and Structured Analysis (SA) are two different approaches to
software development. While both approaches are used for analysis and design of software
systems, they have some key differences.

The Object-Oriented Analysis Process:

Object-Oriented Analysis (OOA) is a process used to design software systems that are based on
the Object-Oriented (OO) paradigm. OOA starts with identifying objects and their relationships
in the real-world problem domain. These objects are then abstracted into classes, which are used
to represent the objects in the software system. The OOA process involves several steps,
including:

● Identifying the objects: In OOA, the first step is to identify the objects in the real world
that need to be modeled in the software system.

Page 14 of 49
 ● Defining the classes: Once the objects have been identified, the next step is to define the
classes that will represent those objects in the software system. These classes will contain
data and methods that define the behavior of the objects.

● Defining the relationships: After the classes have been defined, the next step is to define
the relationships between the classes. These relationships may include inheritance,
association, aggregation, and composition.

● Defining the behavior: Once the classes and relationships have been defined, the next
step is to define the behavior of the classes. This includes defining the methods that will
be used to manipulate the data in the classes.

The Structured Analysis Model:

Structured Analysis (SA) is a process used to design software systems that are based on the
Structured Programming (SP) paradigm. SA starts with identifying the processes and data in the
real-world problem domain. These processes and data are then abstracted into functional
modules and data structures, which are used to represent the processes and data in the software
system. The SA process involves several steps, including:

● Identifying the processes: In SA, the first step is to identify the processes in the real
world that need to be modeled in the software system.

● Defining the modules: Once the processes have been identified, the next step is to define
the modules that will represent those processes in the software system. These modules
will contain code that defines the behavior of the processes.

● Defining the data structures: After the modules have been defined, the next step is to
define the data structures that will be used to store the data in the software system.

● Defining the control flow: Once the modules and data structures have been defined, the
next step is to define the control flow of the system. This includes defining the sequence
of modules that will be executed to perform the desired tasks.

Page 15 of 49
Object-Oriented Analysis Process vs. the Structure Analysis Model

Object-Oriented Analysis (OOA) Structured Analysis (SA)

Identifies objects in the real world that need to Identifies processes in the real world that need
be modeled in the software system. to be modeled in the software system.

Defines classes that represent the objects in Defines modules that represent the processes
the software system. in the software system.

Defines relationships between the classes, Defines data structures that will be used to
such as inheritance, association, aggregation, store the data in the software system
and composition.

Defines the behavior of the classes by Defines the behavior of the modules by
defining the methods used to manipulate the defining the code that will be executed to
data in the classes perform the desired tasks.

Based on the Object-Oriented paradigm. Based on the Structured Programming

paradigm.

Focuses on objects and their relationships. Focuses on processes and data structures.
Table 1.2: Difference between OOA and SA

​ Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although UML
is used for non-software systems, the emphasis is on modeling OO software applications. Most
of the UML diagrams discussed so far are used to model different aspects such as static,
dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
If we look into class diagrams, object diagrams, collaboration diagrams, interaction diagrams all
would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before understanding
the UML in detail, the OO concept should be learned properly. Once the OO analysis and design
is done, the next step is very easy. The input from OO analysis and design is the input to UML
diagrams.

Page 16 of 49
 Figure 1.3: Types of UML Diagram

OO Analysis and Design

OO can be defined as an investigation and to be more specific, it is the investigation of objects.

Design means collaboration of identified objects.
Thus, it is important to understand the OO analysis and design concepts. The most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also
done for an existing system. Now an efficient analysis is only possible when we are able to start
thinking in a way where objects can be identified. After identifying the objects, their
relationships are identified and finally the design is produced.
The purpose of OO analysis and design can describe as −
● Identifying the objects of a system.
● Identifying their relationships.
● Making a design, which can be converted to executables using OO languages.

Page 17 of 49
 Experiment No. 2
Aim:Introduction to the UML Language.

Unified Modeling Language (UML) is a standardized language used in software engineering to

model, visualize, and document software systems. It provides a set of graphical notations and
diagrams that can be used to represent different aspects of a system, from its static structure to its
dynamic behavior. UML is a powerful tool that helps software developers and engineers to better
understand, communicate, and design complex systems. Here's an overview of the different
UML diagrams and their purposes:

1. Class Diagram: Class Diagram is one of the most commonly used UML diagrams, and it's
used to model the static structure of a system. It shows the classes in a system, their attributes,
methods, and relationships with other classes. Class Diagrams are an important tool for software
developers because they provide a blueprint for the software design, which helps to ensure that
the software meets the required specifications and performs as expected.

2. Object Diagram: Object Diagrams, on the other hand, show a snapshot of the objects in a
system and their relationships at a specific point in time. They are used to model the instances of
classes in a system and to provide a better understanding of the behavior and interactions
between objects in the system. Object Diagrams are particularly useful when analyzing complex
systems with many objects and complex relationships.

3. Use Case Diagram: Use Case Diagrams are behavioral diagrams that show the interactions
between a system and its users or other systems. They are used to model the functional
requirements of a system, and they help to identify the different ways that users or external
systems can interact with the system. Use Case Diagrams are an essential tool for software
developers because they help to ensure that the system meets the needs of its users.

4. Sequence Diagram: A sequence diagram is a type of behavioral diagram that shows the
interactions between objects or classes in a system over time. It's used to model the dynamic
behavior of a system, such as how objects collaborate with each other to complete a task.
Sequence diagrams are particularly useful for visualizing complex scenarios and for identifying
potential issues in the system's logic or design.

5. Activity Diagram: An activity diagram is a type of behavioral diagram that shows the flow of
activities or processes in a system. It's used to model the business processes or workflows in a
system. Activity diagrams are particularly useful for modeling business processes, system
requirements, and high-level interactions between components of a system.

Page 18 of 49
6. State Machine Diagram: A state machine diagram is a type of behavioral diagram that shows
the possible states of an object or a class and the events that cause transitions between these
states. It's used to model the behavior of a system or a component that has a finite number of
states. State machine diagrams are particularly useful for modeling complex systems with
complex behavior, such as user interfaces, communication protocols, and control systems.

7. Component Diagram: A component diagram is a type of structural diagram that shows the
components of a system and their relationships. It's used to model the physical architecture of a
system, such as the different subsystems that make up the system and their interconnections.
Component diagrams are particularly useful for understanding the physical structure of a system
and for identifying potential issues with component interactions and dependencies.

8. Deployment Diagram: A deployment diagram is a type of structural diagram that shows how
the components of a system are deployed on hardware nodes. It's used to model the physical
deployment of a system, such as the servers, routers, and other hardware devices that are used to
host the system. Deployment diagrams are particularly useful for understanding how a system
will be deployed in the real world and for identifying potential issues with hardware and
software dependencies.

9. Package Diagram: A package diagram is a type of structural diagram that shows the
organization and dependencies among packages in a system. It's used to model the high-level
organization of a system, such as the different modules, libraries, and subsystems that make up
the system. Package diagrams are particularly useful for understanding the organizational
structure of a system and for identifying potential issues with module dependencies and
coupling.

10. Communication Diagram: A communication diagram is a type of behavioral diagram that

shows the interactions between objects or classes in a system. It's similar to a sequence diagram,
but it focuses on the messages exchanged between the objects or classes, rather than the order of
the interactions. Communication diagrams are particularly useful for modeling the interactions
between objects in a distributed system, such as a client-server architecture.

11. Timing Diagram: A timing diagram is a type of behavioral diagram that shows the behavior
of objects or classes over time, focusing on the time intervals between events and messages. It's
used to model the timing constraints of a system, such as the maximum response time for a
request or the minimum time between two events. Timing diagrams are particularly useful for
understanding the timing behavior of a system and for identifying potential issues with
performance and latency.

Page 19 of 49
12. Interaction Overview Diagram: An interaction overview diagram is a type of behavioral
diagram that shows the interactions between objects or classes in a system, but at a higher level
of abstraction than sequence or communication diagrams. It's used to model the overall behavior
of a system or a subsystem, and to show how different components of the system interact with
each other. Interaction overview diagrams are particularly useful for understanding the overall
behavior of a complex system and for identifying potential issues with high-level interactions
and dependencies.

Page 20 of 49
 Experiment No. 3
Aim: Develop requirements specification for a given problem (The requirements
specification should include both functional and non-functional requirements for your
sample problem statement)

Objective:

To find the requirement specification (both functional and nonfunctional) of a given Problem.

1.Introduction

1.1 Purpose
The purpose of this document is to specify the requirements and features of the Hospital
Management System (HMS). It describes the system's functionality, its user interfaces, and the
requirements that it must meet.

1.2 Document Conventions

The conventions used in this document are as follows:
Bold text is used for section headings.
Italicized text is used for emphasis.
Acronyms and abbreviations are defined in the Glossary section.
1.3 Intended Audience and Reading Suggestions
This document is intended for the development team and stakeholders involved in the Hospital
Management System project. It is recommended to read this document in its entirety to gain a
complete understanding of the system's requirements.

1.4 Product Scope

The Hospital Management System (HMS) is an integrated information system that manages the
administrative, financial, and clinical aspects of a hospital. The system provides a centralized
platform to manage patient records, appointments, admissions, and billing, as well as pharmacy,
laboratory, and radiology services.

1.5 References
The following references were used in the creation of this document:

IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications

2.Overall Description

2.1 Product Perspective

The HMS is a standalone system that integrates the administrative, financial, and clinical
functions of a hospital. The system interacts with external systems such as insurance providers
and laboratory information systems to exchange information.

Page 21 of 49
2.2 Product Functions
The HMS system provides the following functions:

Patient registration and management

Appointment scheduling
Inpatient and outpatient admissions
Pharmacy management
Laboratory and radiology services management
Billing and payment management
Electronic medical records management
Reports generation

2.3 User Classes and Characteristics

The users of the HMS system are hospital staff members, including doctors, nurses,
administrative personnel, and finance personnel. The system is also accessible to patients and
their families through a web-based portal.

2.4 Operating Environment

The HMS system is designed to operate in a Windows-based environment. It requires a server
with a minimum of 8 GB of RAM and 250 GB of disk space.

2.5 Design and Implementation Constraints

The HMS system is designed to be scalable, secure, and maintainable. It is built using
industry-standard software development practices and technologies, including .NET Framework
and Microsoft SQL Server.

2.6 User Documentation

The HMS system provides user documentation, including user manuals and online help, to assist
users in navigating the system's features and functions.

2.7 Assumptions and Dependencies

The following assumptions and dependencies are made for the HMS system:

The hospital has a reliable internet connection to enable remote access to the system.
The hospital has the necessary hardware and software infrastructure to support the system.

3.External Interface Requirements

3.1 User Interfaces

The HMS system provides a web-based user interface for hospital staff members and a patient
portal for patients and their families. The user interface is intuitive, user-friendly, and
customizable. It allows users to perform various functions such as patient registration,
appointment scheduling, admission management, and billing management.

3.2 Hardware Interfaces

Page 22 of 49
The HMS system requires a server with a minimum of 8 GB of RAM and 250 GB of disk space.
It also requires workstations with internet access and web browsers such as Chrome, Firefox, and
Internet Explorer.

3.3 Software Interfaces

The HMS system integrates with external systems such as laboratory information systems and
insurance providers to exchange information. It also integrates with Microsoft Office Suite for
generating reports.

3.4 Communications Interfaces

The HMS system communicates with external systems through RESTful web services and API
calls.

4 System Features

4.1 Patient Registration and Management

The HMS system allows hospital staff members to register and manage patients' information,
including demographic information, medical history, and insurance information.

4.2 Appointment Scheduling

The HMS system enables hospital staff members to schedule patient appointments with doctors,
nurses, and other medical professionals.

4.3 Inpatient and Outpatient Admissions

The HMS system manages inpatient and outpatient admissions, including bed management,
room allocation, and discharge planning.

4.4 Pharmacy Management

The HMS system manages pharmacy services, including inventory management, prescription
management, and drug interaction checking.

4.5 Laboratory and Radiology Services Management

The HMS system manages laboratory and radiology services, including test orders, results
reporting, and imaging management.

4.6 Billing and Payment Management

The HMS system manages billing and payment services, including insurance verification, claim
submission, and payment processing.

4.7 Electronic Medical Records Management

The HMS system manages electronic medical records, including medical history, diagnoses,
treatments, and test results.

4.8 Reports Generation

The HMS system generates various reports such as patient records, appointment schedules,
billing reports, and inventory reports.

Page 23 of 49
5. Other Nonfunctional Requirements
5.1 Performance Requirements
The HMS system must be able to handle a large volume of data and requests while maintaining
high performance and responsiveness.

5.2 Safety Requirements

The HMS system must adhere to safety standards and regulations, including HIPAA, to ensure
patient confidentiality and security.

5.3 Security Requirements

The HMS system must implement robust security measures, including authentication,
authorization, and encryption, to protect against unauthorized access and data breaches.

5.4 Software Quality Attributes

The HMS system must be reliable, maintainable, and scalable. It must also be easy to use,
user-friendly, and customizable.

5.5 Business Rules

The HMS system must adhere to the hospital's business rules and regulations, including
insurance policies, billing procedures, and appointment scheduling guidelines.

Appendix A: Glossary

HMS: Hospital Management System

API: Application Programming Interface
HIPAA: Health Insurance Portability and Accountability Act

Appendix B: Analysis Models

The following analysis models have been developed to support the development and
implementation of the HMS system:

Use Case Diagrams: These diagrams illustrate the system's functionalities from a user's
perspective, including the main actors, use cases, and their relationships.

Activity Diagrams: These diagrams illustrate the flow of activities within the system, including
the actions performed by actors and the system's responses.

Class Diagrams: These diagrams illustrate the system's object-oriented structure, including the
classes, their attributes, and their relationships.

Sequence Diagrams: These diagrams illustrate the interactions between actors and the system,
including the messages exchanged and their order.

Page 24 of 49
State Diagrams: These diagrams illustrate the system's states and transitions, including the
events triggering the transitions and the actions performed during transitions.

These analysis models provide a comprehensive view of the HMS system, facilitating the
development, testing, and maintenance of the system.

Page 25 of 49
 Experiment No. 4
AIM OF THE EXPERIMENT:

Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project.

This is DFD level 0 which Includes : -

Entities :-

Hospital Administrator: This entity represents the person who is responsible for the overall
management and administration of the hospital. In the context of the HMS, the hospital
administrator interacts with the hospital staff, patients, and other stakeholders to ensure that the
hospital is operating efficiently and effectively.

Doctor: This entity represents the medical professional who provides medical diagnosis,
treatment, and advice to the patients. In the context of the HMS, the doctor interacts with the
hospital staff and patients to provide medical care and make treatment recommendations.

Patient: This entity represents the individual who seeks medical attention and services from the
hospital. In the context of the HMS, the patient interacts with the hospital staff to receive medical
services, schedule appointments, and make payments.

Process :-

Hospital Management System: This process refers to the overall management and
administration of the hospital, including activities such as patient admission, treatment and care,
staff management, financial management, and equipment management. The HMS process
involves coordinating various hospital departments and staff members to ensure that the hospital
is operating efficiently and effectively.

Page 26 of 49
 Figure 4.1 DFD Level 0 For HMS

LEVEL 1 DFD OF HOSPITAL MANAGEMENT SYSTEM

This is DFD level 1 which includes :-

Entities:
1) Patient: This entity represents the individual who seeks medical attention and
services from the hospital. In the context of the DFD, the patient interacts with the
hospital by providing information about their medical condition, and receiving
medical services from the hospital.

2) Doctor: This entity represents the medical professional who provides medical
diagnosis, treatment, and advice to the patients. In the context of the DFD, the
doctor interacts with the hospital by examining the patient, prescribing medication
and treatment plans, and communicating with other medical staff members.

Processes:

1) Manage Patient: This process refers to the management of the patient's

information and medical history within the hospital's information system. This
includes activities such as registering the patient's personal details, medical
history, and billing information.

Page 27 of 49
 2) Assign Room and Faculty: This process is responsible for assigning the patient
to a suitable room and faculty member based on their medical condition and the
availability of resources within the hospital. This process may involve
coordinating with other hospital staff members, such as the nursing staff or
administrative staff.

3) Assign Medicine: This process is responsible for assigning medication and

prescriptions to the patient as recommended by the doctor. This process may
involve coordinating with the pharmacy department to ensure that the medication
is available and delivered to the patient as required.

4) Manage Staff: This process refers to the management of the hospital staff
members' information and schedules. This includes activities such as scheduling
shifts, managing employee benefits, and maintaining the staff database.

Figure 4.2 DFD Level 1 For HMS

Page 28 of 49
 Experiment No.5
Develop UML Use case model for a problem

Objective :

To understand the users view of a project using Use case Diagram

Use Cases :-

1) Patient Registration :- This use case involves adding a new patient to the system,
including their personal information, medical history, and other relevant details.
2) Schedule an appointment :- This use case involves scheduling an appointment for a
patient with a doctor whereas a patient can cancel or change an appointment.
3) File Insurance forms and claims : - This use case involves the insurance claims.
4) View all patient reports : - This use case involves viewing all the reports of patients.
5) Examine the patient :- This use case involves examining the patient, Add Diagnosis,
Prescribe Medicine, Prescribe Test and Schedule medical process.
6) Patient Hospital Admission :- This use case involves patient admission and bed
allotments.
7) Discharge the Patient : - This use case involves the discharge of the patient.

Use Case Diagram for HMS

Figure 5.1 - Use Case Diagram for HMS

Page 29 of 49
 Experiment No.6
Develop sequence diagram

Objective :

To understand the interactions between objects that are represented as lifelines in a sequential
order of a project using Sequence Diagram.

Figure 6.1 - Sequence Diagram for HMS

Page 30 of 49
 1) Doctor: The Doctor entity is responsible for providing their availability information to
the Receptionist. This is achieved through the getAvailability() function which returns a
list of available appointment times.

2) Receptionist: The Receptionist entity is responsible for creating appointments for

patients. They achieve this by calling the createAppointment() function, passing in the
relevant information such as the patient's name and desired appointment time. They are
also responsible for sending bills to patients by calling the sendBill() function.

3) Department: The Department entity is responsible for providing the Receptionist with a
list of available rooms. This is achieved through the getAvailableRooms() function which
returns a list of available rooms within that department.

4) Bill: The Bill entity represents a financial document that outlines the costs of medical
services and procedures provided to a patient. The Receptionist entity is responsible for
sending bills to patients by calling the sendBill() function.

Page 31 of 49
 Experiment No. 7

Aim: Develop Collaboration Diagrams

Figure 7.1:Collaboration diagram of Hospital Management System

Page 32 of 49
A UML collaboration diagram, also known as a communication diagram, is a type of UML
diagram that shows how objects collaborate or interact with each other to accomplish a particular
task or goal.

In this case, the collaboration diagram represents the interactions between four components:
patients, doctors, nurses, and receptionists, in a hospital management system.

1. Here the entities used are : patient, doctor, nurse, and receptionist.

2. Lines are drawn to connect the boxes to represent the interactions between components. For
example, a patient might interact with a receptionist to check in for an appointment, or a doctor
might interact with a nurse to request patient information.

3. The lines are labeled with the types of interactions that are taking place. For example, a line
between a patient and a doctor might be labeled "medical consultation," while a line between a
receptionist and a patient might be labeled "appointment scheduling."

4. Necessary details to the diagram may be added to clarify the interactions. For example, you
might add labels to indicate the date and time of a medical consultation, or the location of a
nurse's station.

Overall, the UML collaboration diagram provides a visual representation of how different
components in a healthcare setting interact with each other to provide care to patients.

Page 33 of 49
 Experiment No. 8
Aim: Develop Class diagram

Objective:-

To show diagrammatically the objects required and the relationships between them while
developing a software product.

Class Diagram for Hospital Management System

Figure 8.1: Class diagram of Hospital Management System

Page 34 of 49
The Hospital Management System (HMS) class diagram represents the main classes and their
relationships in a typical hospital management system. The system includes several classes such
as the User Login, Patient, Doctor, Appointment, Medical Records, and Billing.

The User Login class handles user authentication and authorization to access the system, and it
has a relationship with the Doctor, Patient, and Admin classes. The Patient and Doctor classes
store personal and medical information about patients and doctors, respectively.

The Appointment class manages the scheduling and tracking of appointments between patients
and doctors, and it has a relationship with the Patient and Doctor classes.

The Medical Records class handles the storage and management of medical records for patients,
and it has a relationship with the Patient and Doctor classes.

Finally, the Billing class manages the billing and invoicing process for medical services rendered
to patients, and it has a relationship with the Patient, Doctor, and Appointment classes.

Each class has private attributes to store information and public functions to interact with the
system. Overall, this class diagram provides a clear understanding of the different classes and
their relationships within a hospital management system.

Page 35 of 49
 Experiment No.9
Objective:

To understand the concept of Package Diagram Model.

Figure 9.1: Package Diagram of Hospital Management System

A package diagram is a type of UML diagram that is used to organize and group related classes,
interfaces, and other elements into packages. In this case, the packages are named GUI, patient,
doctor, staff, management, database, payments, and medicine.

● The GUI package is likely to contain classes and interfaces related to the graphical user
interface of the system. This may include windows, buttons, forms, and other visual
elements that the user interacts with.

Page 36 of 49
 ● The patient package is likely to contain classes and interfaces related to the patients in the
system. This may include classes for storing patient information, managing appointments,
and tracking medical history.

● The doctor package is likely to contain classes and interfaces related to the doctors in the
system. This may include classes for managing patient appointments, prescriptions, and
medical records.

● The staff package is likely to contain classes and interfaces related to the staff members
in the system. This may include classes for managing employee schedules, payroll, and
other human resources tasks.

● The management package is likely to contain classes and interfaces related to the overall
management of the system. This may include classes for managing system
configurations, security, and system maintenance.

● The database package is likely to contain classes and interfaces related to the storage and
retrieval of data in the system. This may include classes for interacting with a database
management system (DBMS) or other data storage solutions.

● The payments package is likely to contain classes and interfaces related to payment
processing in the system. This may include classes for managing transactions, integrating
with payment gateways, and tracking payment history.

● Finally, the medicine package is likely to contain classes and interfaces related to the
medications in the system. This may include classes for managing drug inventories,
tracking prescriptions, and managing drug interactions.

Overall, the package diagram provides a high-level view of the system architecture and helps to
organize related classes and interfaces into logical groups. This can make it easier to understand
the system as a whole and to identify areas for improvement or expansion.

Page 37 of 49
 Experiment No.10
Objective :

To understand the State Diagram / Activity Diagram.

State Chart Diagram

States :-

Patient Registered: This state represents the initial state of the patient when they have completed
their registration and provided their personal and medical information to the hospital.

Patient Scheduled: This state represents the next state in which the patient has been scheduled
for an appointment or procedure. This state indicates that the hospital has confirmed the patient's
appointment or procedure time.

Patient Admitted: This state represents the state in which the patient has been admitted to the
hospital and has been assigned to a room. The hospital staff may perform tests or procedures on
the patient while they are in this state.

Test Performed: This state represents the state in which the patient is undergoing testing or
diagnostic procedures. The patient may remain in this state for some time, depending on the
complexity of the tests or procedures.

Operated: This state represents the state in which the patient is undergoing surgery or other
medical procedures. The patient may remain in this state for some time, depending on the
complexity of the operation or procedure.

Bill Generated: This state represents the state in which the hospital has generated a bill for the
patient's hospitalization and medical care. The bill will include the costs of the hospital stay,
medication, treatment, and any other services provided by the hospital.

Discharged: This state represents the final state in which the patient has been discharged from
the hospital and has left the hospital premises.

Page 38 of 49
 Figure 10.1: State chart diagram of Hospital Management

Activity Diagram for Hospital Management System

Patient Admission: This activity represents the process of admitting a patient to the
hospital. The activity may involve several sub-activities such as registration, assigning a
room, medical check-up, and assigning a medical team for the patient.

Patient Appointments: This activity represents the process of scheduling appointments

for the patient. The activity may involve several sub-activities such as checking the
availability of doctors, scheduling a time slot for the appointment, and sending reminders
to the patient.

Page 39 of 49
 Patient Treatments: This activity represents the process of providing medical treatments
to the patient. The activity may involve several sub-activities such as prescribing
medication, performing tests, monitoring vital signs, and updating medical records.

Billing: This activity represents the process of generating and managing the patient's
bills. The activity may involve several sub-activities such as calculating the cost of
services, applying discounts or insurance, generating the bill, and collecting payments.

Figure 10.2: Activity diagram of Hospital Management System

Page 40 of 49
 Experiment No.11
Objective:Component Diagram Model and Deployment Model

Software Required:

COMPONENT DIAGRAM MODEL FOR HOSPITAL MANAGEMENT SYSTEM-

Figure 11.1:Component Diagram of Hospital Management System

Here's a brief explanation of the components that might be present in a hospital management
system:

● Hospital Management System: This is the main component or module that represents
the overall system. It may include sub-components such as patient management, staff
management, inventory management, appointment scheduling, billing and payments, and
reporting.

● Patient Management: This component manages the patient-related functionalities of the

system, including patient registration, patient information management, and patient
history tracking. It may also include modules for managing patient appointments,
admissions, and discharges.

Page 41 of 49
 ● Doctor Management: Doctor component is one of the main components of the hospital
management system. It interacts with other components such as Patient Management,
Appointment Scheduling, Billing and Payments, and Reporting to provide comprehensive
functionality for doctors within the system.

● Nurse Management: This management is responsible for managing the information and
activities of nurses in the hospital. It includes functionalities such as nurse registration,
nurse information management, and nurse schedule management. In this management we
manage patient information, such as medical history, allergies, and vital signs. Nurses can
access this module to view and update patient information.

● Appointment Scheduling: This component handles the scheduling of patient

appointments with doctors or other healthcare providers. It may include modules for
managing appointment slots, booking appointments, and sending notifications to patients
and staff.

● Security Management: This component manages the security-related functionalities of

the system, including user authentication, access control, and data protection. It may
include modules for managing user accounts, passwords, permissions, and encryption.

● Persistence: The persistence layer is a crucial component of any modern software

system, and the above component diagram highlights the various entities and DAOs that
make up this layer in a hospital management system.

● Database: This component diagram shows the basic structure of the database component
of a hospital management system. Depending on the specific requirements of the system,
additional components may be added to the diagram to represent other aspects of the
system's architecture, such as user interfaces, business logic, or external systems.

DEPLOYMENT MODEL FOR HOSPITAL MANAGEMENT SYSTEM

Page 42 of 49
 Figure 11.2:Deployment model of Hospital Management System

Hospital Management System UML Deployment Diagram (Explanation)

The deployment diagram shows the scenario when the system is deployed. It has 5 nodes
represented with boxes and relationship connections. The nodes are the Admin’s Device
containing the hospital management software, the webserver, the physician, and the
patient device.For the connection, the software is connected to the ISP which enables it to
pass data to the webserver and then will be accessed by the patients thru browsers with
the use of URLs. Then the physician can access the software with the use of a TCP/IP
network and they can communicate with patients using ISP.

Page 43 of 49
 Experiment No. 12
Objective: Study the use of CASE Tools

Introduction

Software Engineering is broadly associated with the development of quality software with increasing use
of software preparation standards and guidelines. Software is the single most expensive item in a
computer system as the cost of software during the lifetime of a machine is equivalent to more than 95%
of the total cost (including hardware). Software Engineering requires a lot of data collection and
information generation. Since the computer itself is a very useful device as the information processor, it
may be a good idea to automate software engineering tasks. Computer Aided Software Engineering
(CASE) tools install many software engineering tasks with the help of information created using
computers. CASE tools support software engineering tasks and are available for different tasks of the
Software Development Life Cycle (SDLC). You have been introduced to CASE tools in Unit 10 of
MCS-014. This unit covers various aspects of these CASE tools and their functionality for various phases
of software development.

WHAT ARE CASE TOOLS?

Computer Aided Software Engineering (CASE) tools are gradually becoming popular for the
development of software as they are improving in the capabilities and functionalities and are proving to
be beneficial for the development of quality software. But, what are the CASE tools? And how do they
support the process of development of software? CASE tools are the software engineering tools that
permit collaborative software development and maintenance. CASE tools support almost all the phases of
the

software development life cycle such as analysis, design, etc., including umbrella activities such as
project management, configuration management etc. The CASE tools in general, support standard
software development methods such as Jackson Structure programming or structured system analysis and
design method. The CASE tools follow a typical process for the development of the system, for example,
for developing database application, CASE tools may support the following development steps:

∙ Creation of data flow and entity models

∙ Establishing a relationship between requirements and models

∙ Development of top-level design ∙ Development of functional and process description

∙ Development of test cases. The CASE tools based on the above specifications can help in automatically
generating database tables, forms and reports, and user documentation. Thus, the CASE tools –

∙ support contemporary development of software systems, they may improve the quality of the software ∙
help in automating the software development life cycles by use of certain standard methods

Page 44 of 49
∙ create an organization wide environment that minimizes repetitive work

∙ help developers to concentrate more on top level and more creative problem solving tasks

∙ support and improve the quality of documentation (Completeness and non ambiguity), testing process
(provides automated checking), project management and software maintenance. Most of the CASE tools
include one or more of the following types of tools:

∙ Analysis tools ∙ Repository to store all diagrams, forms, models and report definitions etc.

∙ Diagramming tools

∙ Screen and report generators

∙ Code generators

∙ Documentation generators

∙ Reverse Engineering tools (that take source code as input and produce graphical and textual
representations of program design-level information)

∙ Re-engineering tools (that take source code as the input, analyze it and interactively alter an existing
system to improve quality and/or performance). Some necessary features that must be supported by CASE
tools in addition to the above are:

∙ It should have Security of information. The information may be visible/ changeable by authorized users
only.

∙ Version Control for various products

∙ A utility to Import/Export information from various external resources in a compatible fashion ∙ The
process of Backup and Recovery as it contains very precious data.

Page 45 of 49
Figure 12.1: CASE tools Characteristics

Categories of CASE Tools On the basis of their activities, sometimes CASE tools are classified
into the following categories:

1. Upper CASE tools

2. Lower CASE tools

3. Integrated CASE tools.

Upper CASE: Upper CASE tools mainly focus on the analysis and design phases of software
development. They include tools for analysis modeling, reports and forms generation.

Lower CASE: Lower CASE tools support implementation of system development. They include
tools for coding, configuration management, etc.

Integrated CASE Tools: Integrated CASE tools help in providing linkages between the lower
and upper CASE tools.

Thus creating a cohesive environment for software development where programming by lower
CASE tools may automatically be generated for the design that has been developed in an upper
CASE tool.

​
​ Figure 12.2:Classification of CASE

Need of CASE Tools The software development process is expensive and as the projects become
more complex in nature, the project implementations become more demanding and expensive.
The CASE tools provide the integrated homogenous environment for the development of
complex projects. They allow creating a shared repository of information that can be utilized to

Page 46 of 49
minimize the software development time. The CASE tools also provide the environment for
monitoring and controlling projects such that team leaders are able to manage the complex
projects. Specifically, the CASE tools are normally deployed to –

∙ Reduce the cost as they automate many repetitive manual tasks.

∙ Reduce development time of the project as they support standardization and avoid repetition
and reuse.

∙ Develop better quality complex projects as they provide greater consistency and coordination.

∙ Create good quality documentation

∙ Create systems that are maintainable because of proper control of configuration items that
support traceability requirements. But please note that CASE tools cannot do the following:

∙ Automatic development of functionally relevant system

∙ Force system analysts to follow a prescribed methodology

∙ Change the system analysis and design process. There are certain disadvantages of CASE tools.
These are:

∙ Complex functionality

∙ Many project management problems are not amenable to automation. Hence, CASE tools
cannot be used in such cases.

Characteristics of a successful CASE Tools A CASE tool must have the following characteristics
in order to be used efficiently:

∙ A standard methodology: A CASE tool must support a standard software development

methodology and standard modeling techniques. In the present scenario most of the CASE tools
are moving towards UML. 35 Case Tools

∙ Flexibility: Flexibility in use of editors and other tools. The CASE tool must offer flexibility
and the choice for the user of editors’ development environments.

∙ Strong Integration: The CASE tools should be integrated to support all the stages. This
implies that if a change is made at any stage, for example, in the model, it should get reflected in
the code documentation and all related design and other documents, thus providing a cohesive
environment for software development.

Page 47 of 49
∙ Integration with testing software: The CASE tools must provide interfaces for automatic
testing tools that take care of regression and other kinds of testing software under the changing
requirements.

∙ Support for reverse engineering: A CASE tools must be able to generate complex models
from already generated code.

∙ On-line help: The CASE tools provide an online tutorial.

CASE SOFTWARE DEVELOPMENT ENVIRONMENT

CASE tools support extensive activities during the software development process. Some of the
functional features that are provided by CASE tools for the software development process are:

1. Creating software requirements specifications

2. Creation of design specifications

3. Creation of cross references.

4. Verifying/Analyzing the relationship between requirement and design

5. Performing project and configuration management

6. Building system prototypes

7. Containing code and accompanying documents.

8. Validation and verification, interfacing with external environments.

CASE TOOLS AND REQUIREMENT ENGINEERING

A good and effective requirements engineering tool needs to incorporate the best practices of
requirements definition and management. The requirements Engineering approach should be
highly iterative with the goal of establishing managed and effective communication and
collaboration. Thus, a CASE tool must have the following features from the requirements
engineering viewpoint:

∙ a dynamic, rich editing environment for team members to capture and manage requirements

∙ to create a centralized repository

∙ to create task-driven workflow to do change management, and defect tracking

Page 48 of 49
CASE TOOLS AND DESIGN AND IMPLEMENTATION

In general, some CASE tools support the analysis and design phases of software development.
Some of the tools supported by the design tools are:

∙ Structured Chart.

∙ Program Document Language (PDL).

∙ Optimization of ER and other models.

∙ Flow charts.

∙ Database design tools.

∙ File design tools.

Page 49 of 49