Software Engineering Lab

Name : Shubham pandey

Branch : IT – 2
Roll No : 10613203121

Submitted to : Ms. Gurpreet kaur

Experiment - 1 :

Aim : Introduction to Entity relationship diagram (ERD)

Theory :

An Entity-Relationship (ER) diagram is a graphical representation of the data model that defines the
entities involved in a system and the relationships between them. It's a visual tool used in database
design to illustrate the structure of a database and the way data is related within it. ER diagrams are an
integral part of the entity-relationship modeling method, a widely used approach to conceptualizing and
defining data requirements.

Here are some key components and concepts related to ER diagrams:

1. Entities:

- An entity is a real-world object, concept, or thing that has data stored in a database. For example,
in a university database, entities could include Student, Course, and Instructor.

- Entities are represented by rectangles in an ER diagram.

2. Attributes:

- Attributes are properties or characteristics of entities. For instance, a Student entity may have
attributes like StudentID, Name, and DateOfBirth.

- Attributes are typically represented as ovals connected to their respective entities.

3. Relationships:

- Relationships describe the associations and interactions between entities. They indicate how entities
are connected to each other.

- Relationships are represented by diamond shapes in an ER diagram, and lines connect them to
the related entities.

4. Cardinality:

- Cardinality defines the number of instances of one entity that can be related to the number of
instances of another entity.
 - Common cardinality notations include "1" (one), "M" (many), and "0" (zero). For example, a
relationship between Student and Course entities might have a cardinality of "1:N," indicating that one
student can enroll in multiple courses, but a course can have many students.

5. Primary Key:

- A primary key is a unique identifier for an entity. It ensures that each record in a table can
be uniquely identified.

- In an ER diagram, the primary key is usually underlined.

6. Foreign Key:

- A foreign key is a field in a table that is used to link the table with the primary key of another table.
It establishes a connection between two tables in a relational database.

- In an ER diagram, a foreign key is represented similarly to a primary key.

ER diagrams are essential during the initial stages of database design as they help stakeholders,
including designers and end-users, to understand the data model and the relationships between
different components. They serve as a blueprint for creating a database schema, which is the actual
structure of the database.

Entity-Relationship (ER) diagrams, cardinality refers to the numerical relationships between entities
participating in a relationship. Cardinality helps define how many instances of one entity can be related
to how many instances of another entity. There are three main types of cardinality notation used in ER
diagrams:

1. One-to-One (1:1):

- In a one-to-one relationship, one instance of an entity is related to exactly one instance of another
entity, and vice versa.

- This is represented by the "1" notation on one side of the relationship line connecting the entities.

Example: A "Person" entity is related to a "Passport" entity in a one-to-one relationship, as each

person has only one passport, and each passport belongs to only one person.
2. One-to-Many (1:N):

- In a one-to-many relationship, one instance of an entity is related to many instances of

another entity, but each instance of the second entity is related to only one instance of the first
entity.

- This is represented by the "1" notation on the side of the relationship line corresponding to the "one"
side, and the "M" (or "N") notation on the side of the relationship line corresponding to the "many"
side.

Example: A "Department" entity is related to "Employee" entities in a one-to-many relationship, as

each department can have many employees, but each employee is associated with only one
department.

3. Many-to-Many (M:N):

- In a many-to-many relationship, many instances of one entity can be related to many instances of
another entity.

- This is represented by the "M" (or "N") notation on both sides of the relationship line.

Example: A "Student" entity is related to a "Course" entity in a many-to-many relationship, as each

student can enroll in multiple courses, and each course can have multiple students.

Cardinality notation helps to define the business rules governing the relationships between entities,
guiding the implementation of these relationships in the database schema. It ensures that the database
accurately represents the real-world scenarios and allows for proper data retrieval and manipulation.
Experiment - 2 : Draw ER Diagram of

1. Library Management System

2. Hospital Management System
Experiment - 3 :

Aim : Introduction to Data flow diagram (DFD)

Theory :

A Data Flow Diagram (DFD) is a visual representation that depicts the flow of data within a system and
the processes that transform that data. It's a modelling technique used in software engineering for
analyzing and designing information systems. DFDs provide a clear and concise way to represent how
data moves through a system, making them valuable tools for understanding, documenting, and
communicating the flow of information in a process or system.

Here are key components and concepts related to Data Flow Diagrams:

1. Processes:

- Processes represent the activities or transformations that occur within the system. They are depicted
as circles or ovals in a DFD.

- Each process takes input data, processes it in some way, and produces output data.

2. Data Flows:

- Data flows represent the movement of data between processes, data stores, and external entities.
They are depicted as arrows in a DFD.

- Data flows show the direction in which data is moving and help visualize the flow of information
through the system.

3. Data Stores:

- Data stores represent repositories where data is stored. These can be databases, files, or any
other storage system.

- Data stores are depicted as rectangles in a DFD.

4. External Entities:

- External entities are sources or destinations of data that interact with the system but are not part of
it. They can be people, other systems, or organizations.
 - External entities are represented by rectangles with lines connecting them to processes or data
stores.

5. Data Sources and Sinks:

- Data sources and sinks are specific types of external entities. A data source is an external entity that
provides data to the system, while a data sink is an external entity that receives data from the system.

6. Data Flow Diagram Levels:

- DFDs can be developed at different levels of detail. The levels range from a high-level overview
(context diagram) to detailed diagrams that show individual processes.

- Context Diagram: Provides an overview of the entire system, showing the interactions between
the system and external entities.

- Level 0 Diagram: Represents the main processes and data stores within the system.

- Lower-Level Diagrams: Provide more detail by breaking down processes into sub-processes.

DFDs are useful in system analysis and design because they allow stakeholders, including analysts,
designers, and end-users, to visualize the flow of information and understand the functionality of a
system. They help in identifying data input sources, data processing, data storage, and data output
destinations, contributing to a clearer understanding of the overall system architecture.

Data Flow Diagrams (DFDs) are categorized into different levels or types based on the level of detail and
abstraction they provide. The main types of DFDs include:

1. Context Diagram (Level 0 DFD):

 The context diagram is the highest-level DFD and provides an overview of the entire system. It
shows the interactions between the system and external entities (sources and sinks of data).
 The focus is on the system as a whole, without delving into internal details.
2. Level 1 DFD:
 Level 1 DFDs break down the processes of the context diagram into more detailed
subprocesses. Each major process in the context diagram is decomposed into its constituent
subprocesses.
 The goal is to provide a more detailed view of the system's functionality while maintaining
a high-level perspective.
3. Level 2 DFD and Beyond:
 As the need for more detail arises, additional levels of DFDs can be created. Level 2 DFDs
break down the subprocesses from Level 1 into even more detailed subprocesses.
 The process of decomposition can continue to Level 3, Level 4, and so on, depending on the
complexity of the system and the level of detail required for analysis and design.
Experiment - 4 : Construct Data flow diagram :

1. Library Management System

2. Hospital Management System
Experiment - 5 :

Aim : Introduction to Use case diagram.

Theory :

A Use Case Diagram is a visual representation that depicts the interactions between different actors and
the system itself within a specific environment or context. It's a widely used tool in software engineering
and systems engineering to capture and define the functional requirements of a system from an end-
user's perspective. Use Case Diagrams are part of the Unified Modeling Language (UML), a standardized
modeling language for software development.

Here are key components and concepts related to Use Case Diagrams:

1. Actor:

- An actor is an external entity that interacts with the system. Actors can be individuals, groups,
or other systems that play a role in the use of the system.

- Actors are represented by stick figures in a Use Case Diagram.

2. Use Case:

- A use case represents a specific functionality or behavior of the system that yields a measurable
result for one or more actors.

- Use cases are depicted as ovals in a Use Case Diagram.

3. System Boundary:

- The system boundary defines the scope of the system and separates it from its external actors. It
is represented by a box that encloses the use cases.

4. Association:

- An association is a relationship between an actor and a use case. It indicates that the actor is involved
in the described functionality.

- Associations are represented by lines connecting actors and use cases, with an arrow pointing
toward the associated element.
5. Include Relationship:

- An include relationship is used to show that one use case includes the functionality of another
use case. It is represented by a dashed arrow.

6. Extend Relationship:

- An extend relationship is used to indicate that one use case can extend the behavior of another
use case under certain conditions. It is represented by a dashed arrow with an "extends" keyword.

7. Generalization (Inheritance):

- Generalization in Use Case Diagrams represents the relationship between a more general use case
(parent) and a more specialized use case (child). It is depicted using an arrow with a triangle.

Use Case Diagrams are valuable for several reasons:

- Communication:

- Use Case Diagrams provide a high-level, visual representation of the system's functionality, making it
easier for stakeholders to understand and discuss system requirements.

- Requirements Analysis:

- They help in identifying and capturing functional requirements by focusing on how users interact
with the system.

- System Design:

- Use Case Diagrams can serve as a foundation for system design, helping in the allocation of
responsibilities and the identification of necessary components.
- Testing:

- Use cases can be used as a basis for defining test cases, ensuring that the system meets the
specified user requirements.

By illustrating the interactions between actors and use cases, Use Case Diagrams offer a user-centric
perspective on system behaviour, aiding in the development of software systems that align with user
needs and expectations.
Experiment - 6 :

Aim : Construct use case diagrams :

1. Library Management System

2. Hospital Management System
Experiment – 7 :

 Aim: Introduction to SRS and to Prepare a SRS Document for University Management System.

 Requirements:

1. SOFTWARE REQUIREMENT- Microsoft Word

2. HARDWARE REQUIREMENT- Computer, Keyboard, Mouse, CPU

 Theory:

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.

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

i. It provides feedback to the customer.

ii. It decomposes the problem into component parts.

iii. It serves as an input to the design specification.

iv. It serves as a product validation check.

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

a. Functionality. What is the software supposed to do?

b. External interfaces. How does the software interact with people, the system’s hardware,
other hardware, and other software?

c. Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?

d. Attributes. What is the portability, correctness, maintainability, security, etc.

considerations?
  Procedure:
IEEE Standard SRS Template

1. INTRODUCTION
This document aims at defining the overall software requirements for UNIVERSITY
MANAGEMENT SYSTEM. Efforts have been made to define the requirements exhaustively
and accurately. The final product will contain the features/functionality mentioned in this
document.
1.1 PURPOSE
This specification document describes the capabilities that will be provided by the
software application UNIVERSITY MANAGEMENT SYSTEM. It also states the various
required constraints by which the system will abide. The intended audiences for this
document are the development team, testing team and end users of the product.

1.2 SCOPE
The software product UNIVERSITY MANAGEMENT SYSTEM will be an MIS and
Reporting application that will be used for result preparation and management of B.
Tech Program of a University. The application will manage the information about
various students enrolled in this course in different years, the subjects offered
during different semesters of the course, the students’ choices for opting different
subjects, and the marks obtained by various students in various subjects in different
semesters.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Following abbreviations have been used throughout this document: -

B. Tech Bachelor of Technology

CSE Computer Science Engineering
IT Information Technology
EEE Electrical and Electronic Engineering
ECE Electronics and Communication Engineering
DBA Database Administrator
SRMS Student Result Management System
 1.4 REFERENCES

(i) University website: For information about course structure of B. Tech Program
(ii) IEEE Recommended Practice for Software Requirement Specifications – IEEE Std
830-1993

1.5 OVERVIEW

The rest of this SRS document describes the various system requirements, interfaces, features and
functionalities in detail.

2. OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

Online University Management System software is used to maintain and manage
the result of the student. This software helps the user to maintain and manage the
result of the student. This software helps the user to easy access the result of
students. This software is also helpful for the administrator because he can easily
bring changes to the records of the student.

2.1.1 HARDWARE INTERFACES Server Side

The web application will be hosted on one of the department’s Linux servers
and connecting to one of the school Oracle Database servers.The web server is
listening on the web standard port, port 80. Client Side The system is a web-
based application; clients are requiring using a modern web browser such as
Mozilla Firebox 1.5, Internet Explorer 6 and Enable Cookies. The computer
must have an Internet connection in order to beable to access the system.

2.1.2 USER INTERFACES

All pages of the system are following a consistent theme and clear structure.
The occurrence of errors should be minimized through the use of checkboxes,
radio buttons and scroll down in order to reduce the amount of text input
from user. JavaScript implement in HTML in order to provide a Data Check
before submission. HTML Tables to display result to give a clear structure that
easy to understand by user. Error message should be located beside the error
 input which clearly highlighted and tell user how to solve it. If system error, it
should provide the contact methods.

The System should provide a feedback form for all users to give comments or asking
questions. It should provide a FAQ to minimize the workload of system administrator.

2.1.3 SOFTWARE INTERFACES Server Side

The UOP already has the required software to host a Java web application. An
Apache Webserver will accept all requests from the client and forward SUMS
specific requests to
Tomcat 5.5Servlet Container with J2EE 5.0 and Strut 1.2.8 hosting SUMS. A
development database will be hosted locally (using MySQL); the production
database is hosted centrally (using Oracle). Client Side
An OS is capable of running a modern web browser which supports HTML
version 3.2or higher.
2.2 USER CHARACTERSTICS
The users of the system are students, teachers and the administrators
who maintain the system. The users are assumed to have basic
knowledge of the computers and Internet browsing. The administrators
of the system to have more knowledge of the internals of the system
and is able to rectify the small problems that may arise due to disk
crashes, power failures and other catastrophes to maintain the system.
The proper user interface, user’s manual, online help and the guide to
install and maintain the system must be sufficient to educate the users
on how to use the system without any problems.

2.3 GENERAL CHARACTERSTICS

The result of all the users must be stored in a database that is accessible
by the Online University Management System. The university result
security system must be compatible with the Internet applications. The
Online University Management System is connected to the university
computer and is running all 24 hours a day. The users must have their
correct usernames and passwords to enter into the Online University
Management System.

2.4 ASSUMPTIONS AND DEPENDENCIES

The users have sufficient knowledge of computers. The University
computer should have Internet connection and Internet server
capabilities. Theusers know the English language, as the user interface
will be provided in English. The product can access the university
student database.
 3. FUNCTIONAL DESCRIPTION

3.1 FUNCTIONALITY

3.1.1 LOGIN CAPABILITIES

The system shall provide the users with login capabilities.
3.1.2 MOBILE DEVICES
The Online University Management System is also supported on
mobile devices such as cell phones.
3.1.3 ALERTS
The system can alert the administrator in case of any problems.
3.1.4 USABILITY
The system shall allow the users to access the system from the
Internet using HTML or its derivative technologies. The system
uses a webbrowser as an interface. Since all users are familiar with
the general usage of browsers, no specific training is required. The
system is user friendly and self-explanatory.

3.2 RELIABILITY
The system has to be very reliable due to the importance of dataand the
damages incorrect or incomplete data can do.

3.3 AVAILABILITY
The system is available 100% for the user and is used 24 hrs aday and
365 days a year. The system shall be operational 24 hours a day and 7
days a week.

3.4 MEAN TIME BETWEEN FAILURES (MTBF)

The system will be developed in such a way that it may fail once in a
year.

3.5 MEAN TIME TO REPAIR (MTTR)

Even if the system fails, the system will be recovered back up within an
hour or less.

3.6 ACCURACY
The accuracy of the system is limited by the accuracy of the speedat
which the employees of the library and users of the library use the
system.

3.7 MAXIMUM BUGS OR DEFECT RATE

Not specified.

3.8 ACCESS RELIABILITY

 The system shall provide 100% access reliability.

4. PERFORMANCE RESPONSE TIME

The Splash Page or Result page should be able to be downloaded within a minute
using a 56K modem. The result is refreshed every two minutes. The accesstime for
a mobile device should be less than a minute. The system shall respond tothe
member in not less than two seconds from the time of the request submittal.
The system shall be allowed to take more time when doing large processing
jobs.

 Conclusion:
Studied the software requirement specification document for UNIVERSITY MANAGEMENT SYSTEM
successfully.
Experiment -8 :

Aim : Introduction to Data Dictionary.

Theory :

A Data Dictionary is a centralized repository that provides a detailed description of the data used in a
database or information system. It serves as a reference document for data definitions, relationships,
attributes, and other metadata. The primary purpose of a Data Dictionary is to ensure consistency and
accuracy in the management and usage of data across an organization. It is an essential tool for data
management, database design, and application development.

Here are key components and concepts related to Data Dictionaries:

1. Data Elements:

- Data Elements are the fundamental building blocks of data. Each data element represents a distinct
piece of information, such as a field in a database table or a variable in a program.

- The Data Dictionary defines and describes each data element, including its name, data type,
length, and any validation rules.

2. Data Types:

- Data Types specify the kind of data that a particular data element can hold. Common data types
include integers, characters, dates, and floating-point numbers.

- The Data Dictionary provides information about the data type associated with each data element.

3. Attributes:

- Attributes describe additional characteristics or properties of a data element. This may include
information such as whether a data element is mandatory, its default value, or any constraints on its
values.

- Attributes help define the behavior and usage of data elements.

4. Domains:

- Domains are sets of valid values for a specific data element. They define the range or set of
acceptable values for a particular attribute.

- The Data Dictionary may include information about the domains associated with data elements.

5. Relationships:

- In the context of databases, relationships describe how different tables or data entities are
connected. The Data Dictionary provides details about the relationships between tables, including
primary and foreign keys.

6. Metadata:

- Metadata refers to data about data. The Data Dictionary serves as a repository for metadata,
containing information about the origin, format, usage, and ownership of data within the organization.

7. Data Integrity Rules:

- Data Integrity Rules define the conditions that must be satisfied for the data to remain accurate and
consistent. These rules may include constraints, validation criteria, and business rules.

- The Data Dictionary documents and enforces data integrity rules.

8. Data Governance:

- Data Governance involves the management and oversight of data-related processes, policies, and
standards within an organization. A Data Dictionary is a key tool for enforcing and maintaining data
governance practices.

The Data Dictionary plays a crucial role in promoting data quality, standardization, and understanding
across an organization. It serves as a reference for database administrators, data analysts, developers,
and other stakeholders involved in the design, implementation, and maintenance of databases and
information systems.
Experiment - 9 : Construct Data Dictionary :

1. Library Management System

2. Hospital Management System

 Library Management System

 Hospital Management System
Experiment – 10 :

Aim : Introduction to sequence diagram and collaboration diagram

Theory :

A Collaboration Diagram, also known as a Communication Diagram, is a visual representation that shows
the interactions and collaborations among objects or components in a system. It is part of the Unified
Modeling Language (UML), a standardized modeling language for software engineering and system
design. Collaboration diagrams provide a dynamic view of a system, emphasizing the interactions that
take place among different objects over time.

Key components and concepts related to Collaboration Diagrams include:

1. Objects:

- Objects represent instances of classes or components in the system. Each object has a name and may
have attributes and methods associated with it.

- Objects are depicted as rectangles with the object's name at the top, and they can be arranged in a
horizontal or vertical sequence.

2. Links:

- Links illustrate the communication or interaction between objects. They are represented by lines
connecting the objects.

- The link can have a name to describe the interaction, and it may include an arrow indicating the
direction of communication.

3. Messages:

- Messages are the communication events between objects. They represent the invocation of methods
or the passing of information from one object to another.

- Messages are shown on the links and may include the method name, parameters, and return values.

4. Lifelines:
 - Lifelines represent the existence of an object over a period of time. They are typically drawn as a
vertical dashed line extending from the object.

- Lifelines show the timeline of an object's participation in interactions.

5. Activation Bars:

- Activation bars are used to represent the period during which an object is actively processing a
message. They are drawn as horizontal lines on the lifelines.

- Activation bars provide a visual indication of when an object is executing a particular method.

6. Focus of Control:

- Focus of control indicates which object is currently in control or actively processing a message. It is
shown by a bold vertical bar on the lifeline.

- The focus of control helps in understanding the sequence of interactions between objects.

7. Collaboration Use (Optional):

- Collaboration Use is an optional element that allows the reuse of collaboration diagrams in different
contexts. It represents the use of a collaboration (set of interactions) by an object or a component.

Collaboration diagrams are particularly useful for illustrating the runtime behavior of a system,
emphasizing the flow of messages and the order of interactions between objects. They are valuable
during the design and development phases to ensure that the system components interact as intended.
Collaboration diagrams complement other UML diagrams, such as class diagrams and sequence
diagrams, by providing a dynamic perspective on system behavior.
Experiment - 11 :

Aim : Construct a sequence diagrams.

Experiment – 12 :

Aim : Introduction to class Diagram.

Theory :

A Class Diagram is a type of Unified Modeling Language (UML) diagram used in software engineering to
visually represent the structure of a system and the relationships between its classes or objects. It
provides a static view of the system, emphasizing the static relationships and attributes of classes. Class
diagrams are a fundamental tool in object-oriented modeling and design, helping to visualize the
architecture and design of software systems.

Key components and concepts related to Class Diagrams include:

1. Class:

- A class represents a blueprint or template for creating objects. It defines a set of attributes
(properties) and methods (functions) that are common to all objects of that type.

- In a class diagram, a class is typically represented as a rectangle divided into three compartments: the
top compartment contains the class name, the middle compartment lists the class attributes, and the
bottom compartment lists the class methods.

2. Object:

- An object is an instance of a class. It represents a specific entity in the system and has its own set of
attribute values.

- Objects are instances of classes and are not explicitly represented in class diagrams but are
associated with the classes they instantiate.

3. Attributes:

- Attributes are the properties or characteristics of a class. They define the data members of the class
and are listed in the middle compartment of the class rectangle.

- Each attribute has a name and a data type (e.g., integer, string) that specifies the type of data it can
store.
4. Methods:

- Methods are functions or operations that can be performed by objects of a class. They represent the
behavior of the class and are listed in the bottom compartment of the class rectangle.

- Each method has a name, parameters, and a return type.

5. Association:

- Association represents the relationships between classes. It shows how classes are connected and
interact with each other.

- Associations are depicted as lines connecting the participating classes, and they may include
multiplicity (indicating the number of instances involved in the relationship).

6. Multiplicity:

- Multiplicity describes the number of instances of one class associated with the number of instances
of another class in an association.

- Common multiplicity notations include "0..1" (zero or one), "1" (exactly one), "0.." (zero or more),
and "1.." (one or more).

7. Inheritance (Generalization):

- Inheritance represents an "is-a" relationship between classes, where one class (subclass or derived
class) inherits the attributes and methods of another class (superclass or base class).

- In a class diagram, inheritance is depicted by an arrow with a hollow triangle pointing from the
subclass to the superclass.

Class diagrams are valuable for both analysis and design phases of software development. They help in
visualizing the structure of a system, promoting code reuse through inheritance, and ensuring that the
system's classes and their relationships are well-defined and aligned with the intended design. Class
diagrams are often created in conjunction with other UML diagrams, such as use case diagrams and
sequence diagrams, to provide a comprehensive view of a software system.
Experiment – 13 :

Aim : Construct class Diagram

1. Library Management System

2. Hospital Management System

Library Managemet System :

Hospital Managemt System :
Experiment - 14 :

Aim : Introduction to activity diagram

Theory :

An Activity Diagram is a type of Unified Modeling Language (UML) diagram that provides a visual
representation of the workflow or activities within a system or a business process. It is particularly
useful for modeling the dynamic aspects of a system, focusing on the flow of actions and the sequence
in which they occur. Activity diagrams are widely used in software engineering and business process
modeling to depict the steps, decisions, and interactions that take place during the execution of a
process.

Key components and concepts related to Activity Diagrams include:

1. Activity:

- An activity represents a specific task or operation within the system. Activities can range from simple
actions to complex processes.

- In an activity diagram, activities are depicted as rounded rectangles.

2. Action:

- An action is a specific operation or step within an activity. It represents the smallest unit of work in an
activity diagram.

- Actions are depicted as rectangles with rounded corners.

3. Control Flow:

- Control flow arrows show the sequence in which activities or actions are performed. They depict the
order of execution in the process.

- Control flow arrows are represented by arrows connecting activities and actions.

4. Decision Node:
 - A decision node represents a point in the process where a decision must be made. Depending on the
outcome of the decision, different paths or branches are taken.

- Decision nodes are depicted as diamonds, and they have multiple outgoing control flow arrows
representing possible outcomes.

5. Merge Node:

- A merge node represents a point in the process where multiple paths converge after different
decisions or branches.

- Merge nodes are depicted as diamonds with multiple incoming control flow arrows.

6. Fork Node and Join Node:

- A fork node represents a point in the process where multiple parallel activities or actions can occur
simultaneously.

- A join node represents the point where parallel paths converge back into a single path.

7. Initial Node and Final Node:

- An initial node represents the starting point of the activity diagram. It shows where the process
begins.

- A final node represents the end point of the activity diagram, indicating the completion of the
process.

8. Swimlanes:

- Swimlanes are used to partition activities in the diagram based on the responsible entities or
components. They help organize and clarify the responsibilities of different actors or system
components.

Activity diagrams are beneficial for a variety of purposes, including:

- Process Modeling: They can model complex business processes, workflows, or system behaviors.
- Requirements Analysis: They help in understanding and refining system requirements by visualizing the
flow of activities.

- System Design: They assist in designing the logic and sequencing of actions within a system.

- Communication: They provide a visual and easy-to-understand representation of how a process or

system functions, facilitating communication among stakeholders.

Activity diagrams are often created in conjunction with other UML diagrams, such as use case diagrams
and sequence diagrams, to provide a comprehensive view of a system's functionality and behaviour.
Experiment – 15 :

Aim : Construct Activity Diagram :

1. Library Management System

2. Hospital Management System
Experiment – 16 :

Aim : Introduction to state transition diagram.

Theory :

A State Transition Diagram, also known as a State Machine Diagram, is a type of Unified Modeling
Language (UML) diagram that represents the states an object or system can be in and the transitions
between those states. State transition diagrams are particularly useful for modeling the behavior of
systems that exhibit different states and transition between them based on certain events or conditions.

Key components and concepts related to State Transition Diagrams include:

1. State:

- A state represents a condition or situation in the life of an object or system during which it satisfies
some condition, performs some activity, or waits for an event.

- States are depicted as rounded rectangles in a state transition diagram.

2. Transition:

- A transition represents a change of state triggered by an event or condition. It indicates the

movement from one state to another.

- Transitions are represented by arrows connecting states, and they are labeled with the triggering
event and any associated actions.

3. Event:

- An event is an occurrence that triggers a state transition. It can be an external stimulus, an internal
condition, or the passage of time.

- Events are typically labeled on the arrows representing transitions.

4. Action:

- An action is an operation or activity that is performed in response to an event during a state

transition. It describes what happens when a transition occurs.

- Actions are often associated with transitions and are depicted near the arrows.
5. Initial State:

- The initial state represents the starting point of the state transition diagram. It is the state in which
the object or system exists initially.

- The initial state is usually denoted by an arrow pointing into the state.

6. Final State:

- The final state represents the end point of the state transition diagram. It is the state in which the
object or system ends its life or operation.

- The final state is depicted as a circle or rounded rectangle with double borders.

7. Guard Condition:

- A guard condition is a condition that must be true for a transition to occur. It specifies additional
criteria for the transition to take place.

- Guard conditions are sometimes represented in square brackets next to the transition arrows.

State transition diagrams are valuable for modeling the dynamic behavior of systems that can be in
different states and transition between them based on events. They are commonly used in software
engineering to model the behavior of objects, classes, and systems, especially those with complex and
event-driven behavior.

State transition diagrams are useful in various domains, including:

- Embedded Systems: Modeling the behavior of devices that operate in different states based on inputs
and events.

- User Interfaces: Representing the different states and transitions in interactive applications.

- Communication Protocols: Describing the behavior of systems that communicate with each other
based on certain conditions.
- Control Systems: Modeling the states and transitions in systems that respond to changes in their
environment.

State transition diagrams provide a clear and visual way to represent the behavior of systems, making
them easier to understand and communicate among stakeholders.
Experiment – 17 :

Aim : Construct state transition diagram :

1. Library Management System

2. Hospital Management System