Practical 1

Problem Statement with Purpose, Scope, Literature Review,

and Future Scope

Aim: Identify a relevant problem or project definition. Write a detailed problem

statement for the system, along with its Purpose, Scope, Existing system details with a
literature review and mention Future scope of the system.

Employee Management System

1.Introduction
Managing employees is a big part of running any organization. It involves keeping track of their
details, performance, and communication. Doing this manually or with outdated systems often leads
to mistakes and wasted time. An Employee Management System (EMS) can solve these problems
by organizing everything in one place and making processes faster and easier.
1.1 Problem Statement
Right now, many organizations handle employee data using paper records or old systems. This can
lead to mistakes, delays, and difficulties in finding or updating information. An EMS can automate
these tasks, helping organizations save time and reduce errors while improving productivity.
1.2 Purpose of the System
The purpose of an EMS is to make it easy to manage employee information, track performance, and
handle tasks like attendance, payroll, and leave requests. It provides tools for HR staff to add,
update, and view employee records quickly and efficiently.
1.3 Scope of the System
The scope of the Employee Management System includes the following key functionalities:
• Employee Records: A central place to store employee details like name, job title, and contact
info.
• Performance Tracking: Tools to monitor and review employee performance.
• Attendance and Leave: Track attendance, approve leave requests, and calculate leave
balances.
• Payroll Integration: Automatically calculate salaries based on attendance and other data.
• Access Control: Limit access to sensitive information to authorized users only.
• Reports: Create reports on attendance, performance, and other metrics.
• Search Function: Find employee details using filters like name or department.
This system is perfect for medium and large organizations that need a secure and scalable solution.

1
1.4 Existing System and Literature Review(can be in tabular format also)
In the past, organizations managed employee data manually, which was slow and error-prone. Over
time, desktop-based systems were introduced, but they lacked flexibility. Today, web-based systems
like BambooHR and Zoho People make managing employees easier by offering cloud storage,
mobile access, and better features.

Modern systems also use AI to analyze data and give recommendations, and mobile apps let
employees check attendance or request leave on the go. Cloud-based systems are now common, as
they are cost-effective and easy to maintain. However, challenges like high costs, training needs,
and data security still exist.

System Type Description Limitations

Manual System Employee records were kept

Prone to errors, time-
on paper, and processes were
consuming, hard to maintain.
handled manually.

Desktop-Based Systems Installed on local computers, Limited access, no real-time

allowing basic digital storage updates.
of employee data.

Web-Based Systems Online systems for accessing Requires continuous internet

employee data from anywhere and regular maintenance.
with internet connectivity.

Cloud-Based Systems Cloud platforms offer Higher cost, dependency on

advanced features like mobile external providers.
access and AI integration.

AI-Powered Systems Use artificial intelligence for Needs advanced infrastructure

predictive analysis and task and expertise.
automation.
Modern Employee Management Systems also integrate with mobile devices, allowing employees to
check attendance, request leave, and update personal details on the go. Cloud-based systems have
gained popularity for their flexibility and reduced need for on-site servers.

Despite these advancements, challenges persist. Implementation costs can be high for small
organizations, and training is necessary for effective use. Data security is also a critical concern
when dealing with sensitive employee information.

Limitations
• The system might be expensive for smaller organizations.
• Customization might be needed to fit specific needs.
• It requires stable internet and IT infrastructure to work properly.

2
2. Future Scope
The Employee Management System has a bright future, with many new possibilities to make it even
better and easier to use. Here are some key ideas for improvement:
• Artificial Intelligence and Machine Learning Integration
• Advanced AI algorithms can enhance personalized recommendations, helping users
discover new resources based on their interests, borrowing history, and search
behavior.
• Automated classification and metadata extraction for new materials can minimize
manual cataloging efforts.
• Predictive analytics can be used to analyze trends in library usage, suggesting
resource acquisitions tailored to the changing needs of the community.
• Enhanced Search and Discovery
• The adoption of Natural Language Processing (NLP) will allow more intuitive and
human-like search experiences. Users will be able to find resources by asking questions
or using conversational queries.
• Semantic search capabilities can help users find related materials, even with vague or
imprecise search terms, increasing the chances of resource discovery.
• Smart Libraries Using IoT (Internet of Things)
• IoT-enabled libraries can offer real-time inventory tracking of physical resources,
ensuring books and materials are accurately located.
• Self-service kiosks, integrated with IoT, could enable seamless borrowing and returning
workflows, even during non-operational hours.
• Cloud-Based and Distributed Systems
• Greater reliance on cloud-based services will facilitate centralized management for
multi-branch libraries and consortiums.
• Real-time data synchronization across branches will ensure users have consistent
experiences regardless of their location.
• Cloud LMS will lower maintenance costs, as libraries outsource software updates and
infrastructure management to service providers.
• Mobile-First and Progressive Web Applications (PWA)
Future LMS platforms will increasingly cater to mobile users with apps and PWAs,
providing on-the-go access to resources, reminders, and digital catalogs.Augmented Reality
(AR) enhancements can allow users to navigate physical libraries or browse through
bookshelves digitally using mobile
• Employee Engagement and Feedback
Employee engagement is essential for boosting productivity and retaining talent. Integrating
feedback mechanisms and engagement features into an Employee Management System
(EMS) creates a more connected and motivated workforce.

3
• Conclusion
An Employee Management System makes managing employees easier and more efficient. It saves
time, reduces errors, and improves productivity by automating routine tasks. As technology
improves, these systems will become even smarter and more useful for businesses everywhere. It is
a valuable tool for modern organizations, helping manage employee data and streamline HR
processes. By adopting advanced technologies like AI, IoT, and cloud services, organizations can
improve efficiency and employee satisfaction. The system will continue to evolve, providing better
solutions for the changing needs of the workforce.

4
 Practical-2

Planning and Scheduling, for System Development

Aim: Perform Project Planning & scheduling by define and design effective policies,
methodologies, and strategies to achieve the objectives of the Employee Management System.
Create a schedule by assigning tasks, allocating resources, and estimating budgets and time frames.

Project planning and scheduling are essential steps in system development. These processes involve
setting objectives, breaking tasks into manageable parts, allocating resources, and estimating
timelines to ensure successful project completion. In the case of an Employee Management System
(EMS), planning includes defining system features, designing its architecture, developing the
application, and ensuring timely delivery.Scheduling assigns deadlines and milestones, helping track
progress, manage risks, and allocate resources effectively.

An Employee Management System (EMS) is software that simplifies tasks like employee data
management, performance tracking, leave management, and payroll processing. Proper project
planning and scheduling ensure that the system meets organizational needs and is delivered on time.

2. Project Planning and Objectives

Project planning defines goals, allocates resources, and schedules activities for efficient
development. The Employee Management System aims to automate employee-related tasks,
improve human resource efficiency, and provide a user-friendly experience.Key steps in planning
ensure the project is delivered on time and maintains high quality.

2.1. Choice of Process Model: Agile Model

The Agile Model is a modern software development methodology that emphasizes iterative progress,
flexibility, and collaboration. Unlike the traditional Waterfall Model, Agile breaks the project into
small, manageable cycles called “sprints,” which typically last 1-2 weeks. At the end of each sprint,
a working version of the software is reviewed, allowing for continuous improvement..

Reason for choosing Agile model

• Flexibility: Agile allows for changes in requirements, even in the middle of development.
• Frequent Deliverables: The system is built in smaller parts, ensuring continuous progress.
• Improved Collaboration: Regular feedback from stakeholders leads to better outcomes.
• Reduced Risk: Frequent testing and adjustments reduce the chances of project failure.

Phases of the Agile Model Applied to EMS

5
 Concept and Inception

Objective: Define the project scope and gather initial requirements.

o Identify the core features: employee registration, leave management,

payroll processing, and performance tracking.

o Discuss the basic architecture and resource needs. o Deliverable :

Initial project backlog and user stories.

Design and Prototyping (Sprint 2-3)

Objective: Create system designs and prototypes for key features.

Design Steps:

o Develop wireframes for the user interface.

o Plan the database schema. Deliverable: Wireframes, database schema, and basic
working prototypes.Develop user interface mockups for user-friendly interaction with
the system.

o Deliverable: Wireframes, database schema, and basic working prototypes.

Development and Iterative Builds (Sprint 4-10)

Objective: Develop the core features in multiple sprints. Each sprint focuses on a specific
module:.

Development Steps:

o Sprint 4-5: Employee Registration and Data

Management Module o Sprint 6-7: Leave Management
and Attendance Tracking
o Sprint 8: Payroll Processing o Sprint 9: Performance
Evaluation o Sprint 10: Notification System and Reports

Deliverable: Working versions of each module.

Testing and Feedback (Continuous)

Objective: Ensure the system’s quality through continuous testing.

o Conduct unit testing for each module. o Perform integration testing to

check how modules work together. o Collect feedback from users and
improve the system accordingly. o Deliverable: Fully tested and
refined EMS.

6
Deployment and User Training (Sprint 11-12) Objective:

Deploy the EMS and train users.

Deployment Steps:

o Set up the system on the organization’s infrastructure. o Conduct user

training to ensure a smooth transition to the new system.
o Provide ongoing support and maintenance to address any bugs or
updates.
Deliverable: Fully deployed EMS and trained HR staff.
2.2 Project Scheduling
Scheduling organizes tasks, resources, and timelines to ensure the project’s timely delivery. It
involves breaking the project into phases, defining dependencies, estimating durations, and
allocating resources.
Purpose of Scheduling
1. Organize Tasks: Creates a clear roadmap for completing all activities.
2. Define Priorities: Helps identify task dependencies and prioritize critical milestones.
3. Allocate Resources: Ensures the right people and tools are available for each phase.
4. Monitor Progress: Tracks performance against planned timelines.
5. Avoid Delays: Reduces the risk of missed deadlines.
Key Elements of Scheduling in LMS

1. Task Identification:
Identify specific tasks needed to develop and deploy the LMS, such as requirement
gathering, module design, testing, and deployment.
2. Task Sequencing and Dependencies:
Some tasks depend on others to be completed first. For
example: o The User Management Module depends on
database design. o Testing can only begin once all modules are
implemented.
3. Estimating Task Duration:
Estimate the time required to complete each activity based on complexity and available
resources.
4. Resource Allocation:
Assign team members to specific tasks according to their expertise. Example:
o The Database Developer works on database design during weeks 2–3.
o QA Engineers conduct testing during weeks 8–9.
5. Milestones:
Define key checkpoints in the project, such as completion of requirement analysis, testing,
and deployment.

2.3 Overview of the Schedule

The LMS schedule spans 10 weeks and consists of the following phases:

7
 Table :1 Schedule Overview
Task Duration Description
Requirement Analysis 1 week Document functional and non-functional requirements.
System Design 2 weeks Create system architecture, data flowcharts, and mockups.
Employee Registration Develop features for employee registration and
1 week
Module management.
Leave Management Module 1 week Implement leave tracking and approvals
Payroll Module 1 week Create payroll processing functionality.
Performance Tracking
1 week Develop performance evaluation features.
Module
Notification and Reports
1 week Implement reminders, notifications, and reporting.
Module
Conduct system testing, including unit and integration
Testing 1 week
testing
Deployment & Training 1 week Deploy EMS and train HR staff..
2.3.1 Project scheduling Using Gantt Chart
A Gantt Chart is a visual scheduling tool that shows tasks along a timeline, their durations, dependencies,
and milestones. Below is an illustration of how the EMS tasks are scheduled over 7 Sprint.

Figure 1: Gant chart

A well-structured schedule ensures that the Employee Management System development progresses
systematically while maximizing efficiency, meeting deadlines, and delivering a high-quality product. By
visualizing timelines and resource usage through tools like Gantt charts, the project achieves its goals in
a planned and controlled manner.

2.4 Resource Allocation

Efficient resource allocation ensures that tasks are completed smoothly:

● Project Manager: Oversees planning, progress tracking, and manage deliverables.

8
 ● System Analyst: Handles requirements gathering and documentation.
● Database Developer: Designs and optimizes the database.
● Front-End Developer: Creates an intuitive user interface for both librarians and members.
● Back-End Developer: Implements APIs, system modules, and business logic.
● QA Engineer: Conducts thorough testing of the system.

2.5 Risks and Mitigation

Every project involves risks that can delay or derail progress. For the EMS, common risks include
scope creep, resource shortages, and technical issues. These are mitigated by:

● Changing Requirements: Mitigated by frequent reviews and updates.

● Resource Shortages: Addressed through cross-training team members.
● Technical Challenges: Solved by regular testing and stakeholder feedback.

2.6 Deliverables
Key deliverables for the EMS project include:

● Requirements Document: Detailed functional and non-functional requirements.

● System Design Artifacts: Wireframes, database schemas, and workflows.
● Functional EMS: A fully developed, tested, and deployed system.
● Training Materials: User manuals and training sessions.
● Testing Reports: Results of system testing and quality assurance.

By following the Agile Model, the development of the Employee Management System becomes more flexible
and adaptable to changes. Each sprint ensures steady progress and allows for continuous improvements. The
scheduling and resource allocation strategies help the project stay on track, while risk mitigation strategies
ensure a successful outcome. Through effective planning, the EMS will meet organizational requirements and
provide a seamless user experience.

9
 Practical 3
Cost and Effort Estimation for Software Development
Aim

Perform a cost and effort estimation for the Employee Management System (EMS) by understanding
the scope of the software to be developed.

Cost estimation and effort analysis are essential for planning and managing software projects,
helping predict the required resources, time, and budget. Function Point Analysis (FPA) is a widely
used method to estimate software size, effort, and cost. It measures the functionality delivered to the
user, independent of programming languages or technologies.

Function points are calculated based on five key components: External Inputs (EI), External Outputs
(EO), External Inquiries (EQ), Internal Logical Files (ILF), and External Interface Files (EIF). Each
component is assigned a weight based on its complexity (Low, Medium, High), and these are
summed up to determine the system's size. This quantitative measure is then used with productivity
rates or cost factors to estimate the total effort (in person-hours) and cost of the project, ensuring
accurate and standardized planning.

3.1 Cost and Effort Estimation

To estimate the cost and effort for developing a Employee Management System (EMS) using
Function Point Analysis (FPA), the following steps can be utilized.

3.2 Understand the Scope of the System

The Employee Management System typically includes the following modules:

1. User Management: Manage employees and HR users.

2. Attendance Management: Track employee attendance and leaves.
3. Payroll Processing: Automate salary calculations and tax deductions.
4. Performance Evaluation: Generate performance reports and track progress.
5. Authentication: Secure login/logout functionality for users.

3.3 Identify and Classify Function Types

FPA involves categorizing system components into five elements:

1. External Inputs (EI): Inputs provided to the system.

2. External Outputs (EO): Outputs generated by the system.
3. External Inquiries (EQ): User-driven queries.
4. Internal Logical Files (ILF): Logical files/data tables maintained within the system.

Dimpal Bagda (92310103023) 10 TC4 - C

 5. External Interface Files (EIF): Files/data from external systems.

3.1 Table: Functionality Classification

Functionality Type Complexity Count
Employee Registration EI Low 1
Login/Logout EI Low 1
Manage Attendance EI Medium 2
Payroll Processing EO Medium 2
Generate Reports EO Medium 1
Employee Data Table ILF Medium 1
Attendance Records ILF Medium 1
3.4 Assigning Weight for Functions
3.2 Table: Function Weights
Type Low Medium High
EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10
3.5 Calculating Unadjusted Function Points (UFP)
Using the counts and weights listed above:

3.3 Table: Unadjusted Function Points Calculation

Type Complexity Count Weight Total FP
EI Low 2 3 6
EI Medium 2 4 8
EO Medium 2 5 10
ILF Medium 2 10 20
Total UFP 44

3.6 Adjust for Complexity Factors

The Value Adjustment Factor (VAF) is a multiplier applied to the Unadjusted Function Points (UFP)
to adjust for the specific characteristics of the software system.

Formula:
VAF = 0.65 + (TDI × 0.01)
AFP = UFP × VAF
Where TDI (Total Degree of Influence) is the sum of the ratings for 14 General System
Characteristics (GSCs).

Dimpal Bagda (92310103023) 11 TC4 - C

TDI Calculation: TDI = 3 + 2 + 4 + 3 + 4 + 5 + 4 + 5 + 3 + 2 + 4 + 4 + 3 + 3 = 53

VAF = 0.65 + (53 × 0.01) = 0.65 + 0.53 = 1.18

AFP = 44 × 1.18 = 52

3.7 Effort Estimation

Effort (Person-Months) = AFP / Productivity Rate

3.4 Table: Productivity Rates

Complexity Level Productivity Rate (FP/Person-Month)
Simple 25–30
Moderate 15–20
Complex 7–10
Using a productivity rate of 20 FP/Person-Month:
Effort = 52 / 20 = 2.6 Person-Months

3.8 Cost Estimation

Cost = Effort × Developer Monthly Cost

Assuming Developer Monthly Cost = $5,000:

Cost = 2.6 × 5000 = $13,000

(Note: Cost and effort values are based on assumptions.)

3.9 Conclusion
Function Point Analysis (FPA) provides a structured approach to estimating software development
costs and effort. By analyzing system functionalities, classifying them into function types, and
applying standard weightage, we can derive accurate estimations. The EMS, estimated at 52 function
points, requires approximately 2.6 person-months of effort and a $13,000 budget for development.
These estimations enable better planning, budgeting, and resource allocation for the successful
execution of the project.

Dimpal Bagda (92310103023) 12 TC4 - C

 Practical 4
Software Requirement Specification (SRS) Development for the
Employee Management System
Aim : Creating a Software Requirements Specification (SRS) for an Employee Management
System (EMS) involves detailing the system's functionalities, interfaces, performance metrics,
attributes, and design constraints. Below is a structured outline tailored to your requirements.
4. Software Requirement Specification (SRS)
A Software Requirement Specification (SRS) is a structured document that defines the
functionalities, constraints, and requirements of a software system. It serves as a foundation for
development, testing, and stakeholder communication.
4.1 Overview
The Employee Management System (EMS) is designed to automate and streamline human resource
processes within an organization. It aims to enhance efficiency in managing employee data,
attendance, payroll, performance evaluations, and other HR-related functions. By digitizing these
processes, the EMS seeks to reduce administrative workload, minimize errors, and provide real-time
insights into workforce management.
4.2 Identifying Risks in the EMS
The primary purpose of the EMS is to provide a centralized platform for managing employee
information, attendance records, payroll processing, performance assessments, and other HR
functions. The system will enable HR personnel to efficiently handle administrative tasks, ensure
compliance with labor laws, and support strategic decision-making through data analytics.
4.3 Document Conventions
This document follows structured formatting using numbered sections, bullet points, and industry-
standard terminology for clarity and ease of reference. It is intended for stakeholders such as HR
Managers, System Administrators, Developers, and Testers involved in the development,
implementation, and maintenance of the EMS.
4.4 Overall Description
This section provides an overview of the system’s purpose, functions, and constraints.
Product Perspective
The EMS is a standalone software application that integrates with existing organizational
infrastructure. It replaces manual HR processes with a centralized database, ensuring data
consistency and accessibility.
Product Functions The
system will provide:
● Employee Information Management: Maintain comprehensive records of employees,
including personal details, employment history, and qualifications.
● Attendance Tracking: Monitor employee attendance, including clock-in/clock-out times,
leaves, and absences.

Dimpal Bagda (92310103023) 13 TC4 - C

 ● Payroll Processing: Automate salary calculations, deductions, and generate payslips.
● Performance Management: Facilitate performance evaluations, goal setting, and feedback
collection.
● Leave Management: Manage various types of leaves, approvals, and balances.
● Reporting and Analytics: Generate reports on employee performance, attendance, payroll,
and other HR metrics.
Users of the EMS
● HR Managers: Oversee HR operations, manage employee records, and generate reports.
● Employees: Access personal information, request leaves, and view payslips.
● System Administrators: Maintain system integrity, manage user access, and ensure data
security.
General Constraints
The system must comply with data privacy regulations applicable in the organization's jurisdiction. It
should support at least 10,000 employee records.The system must be operational 24/7 with minimal
downtime.

4.5 Specific Requirements

Continuous monitoring ensures risks are managed throughout the development cycle. Strategies
include:
● Regular risk assessment meetings.
● Use of project management tools for tracking.
● Conducting periodic system testing.
● Documenting risk resolution processes.
4.5.1 Functional Requirements
Functional requirements describe what the system should do:
1. User Authentication & Authorization: Secure login and role-based access.
2. Tour Package Management: CRUD (Create, Read, Update, Delete) operations for tour
listings.
3. Booking & Payment: Secure transactions for hotels, transport, and activities.
4. Itinerary Management: Users can customize and manage trip details.
5. Search & Filter: Advanced search for destinations, hotels, and services.
6. Reviews & Feedback: Users can submit reviews and ratings.
7. Reports & Analytics: Generate reports on bookings and revenue.

4.5.2 External Interfaces

External interfaces define how the system interacts with users, hardware, and other software
components:
1. User Interface (UI): A web and mobile-friendly dashboard for user interaction.
2. Hardware Interface: The system must support barcode scanners for tickets and mobile
devices for bookings.

Dimpal Bagda (92310103023) 14 TC4 - C

 3. Software Interfaces: The system integrates with SQL/NoSQL databases for data
management.
4. Communication Interfaces: The system supports email, SMS, and push notifications for
travel updates.

4.5.3 Non-Functional Requirements

Non-functional requirements describe system performance, security, and usability expectations:
1. Performance: The system must handle 500+ concurrent users, with response times under
2 seconds.
2. Security: Implements encryption, multi-level authentication, and role-based access.
3. Usability: The UI should be user-friendly, accessible, and follow WCAG guidelines.
4. Scalability: The system must support expansion without performance degradation.
5. Availability: Ensures maximum uptime with automated backups.
4.5.4 Design Constraints
Design constraints are limitations that affect the implementation and architecture of the Employee
Management System (EMS). These constraints ensure that the system is developed within
predefined technical, security, and operational guidelines. Design constraints define system
limitations:
1. Database Management: Support SQL and NoSQL databases based on scalability needs.
2. Technology Stack: Built using Node.js for the backend, React.js for the frontend, and
MongoDB for storage.
3. Security Compliance: Encryption, GDPR compliance, and multi-factor authentication
(MFA).
4. Performance Optimization: Load balancing and caching mechanisms for high
availability.
4.5.5 System Attributes
1. Portability: The system must be accessible on Windows, macOS, Linux, and mobile devices.
2. Maintainability: Modular design for easy updates and fixes.
3. Reliability: Ensures consistent operation with failover mechanisms.
4. Scalability: The system must handle increasing users and bookings efficiently.
5. Interoperability: Ability to integrate with third-party services like hotels and airlines.
6. Extensibility: Allows future enhancements with minimal modifications.
4.5.6 Implementation details and Hardware Requirements
This section defines the required hardware specifications:So for EMS requires a cloud-based or
dedicated server for hosting.
Minimum hardware requirements:
● Processor: Intel i5 or higher
● RAM: 8GB or higher
● Storage: 500GB SSD or higher
● Internet: High-speed connection for real-time updates.

Dimpal Bagda (92310103023) 15 TC4 - C

4.6 Conclusion
Effective risk management is crucial for successful software development. By identifying, analyzing,
and mitigating risks in the Employee Management System, potential challenges can be minimized,
ensuring smooth development and deployment.
Practical 5

System Analysis and Design for the Selected System

Aim: Perform system analysis on selected system.
1)Systems analysis (what the system should do)
2) Systems design (how to accomplish the objective of the system.)

5. System Analysis and Design

The Employee Management System (EMS) is a software solution designed to streamline the
management of employees in an organization. It automates operations such as employee records,
attendance tracking, payroll management, leave management, and performance evaluation. The
system enhances efficiency, reduces manual errors, and improves the overall administrative
workflow.
5.1 System Analysis
The Employee Management System aims to achieve the following objectives:

● Efficient Employee Record Management: Maintain a centralized database of employee

details, ensuring accurate and easy accessibility.
● Automated Attendance Tracking: Reduce manual intervention by automatically recording
employee attendance and working hours.
● Payroll Automation: Simplify salary calculation by automating deductions, bonuses, and net
pay generation.
● Leave Management: Streamline leave applications, approvals, and tracking with automated
workflows.
● Performance Evaluation: Automate performance review processes with rating systems and
feedback collection.
● Scalability: Ensure the system can handle increasing numbers of employees and data without
performance degradation.
5.1.1Gather System Requirements
Functional Requirements :The system includes a User Management Module, allowing
administrators to create, update, and delete user accounts. Users have different roles such as Admin,
HR, and Employee each with distinct privileges. The Employee Management Module enables
admins to add, update, and remove employee records while managing employees based on genre,
author, and availability. The Book Search and Catalog Module allows users to search books using
filters like name, department , id and salary.
● User Management Module: Allows administrators to create, update, and delete employee
records. Users include Admin, HR, and Employee, each with different access privileges.

Dimpal Bagda (92310103023) 16 TC4 - C

 ● Attendance Module: Tracks employee check-in, check-out, and working hours, recording
daily attendance status.
● Payroll Module: Automates salary calculations by including base salary, deductions, and
bonuses.
● Leave Management Module: Enables employees to apply for leave, with automated approval
workflows and leave balance tracking.
● Performance Management Module: Handles performance reviews, ratings, and feedback
submissions.
● Reporting and Analytics Module: Generates detailed reports on employee records, attendance
trends, payroll data, and performance metrics.
Non Functional Requirements: The system must ensure high performance by providing fast
response times for Admin searches and transactions. Scalability is crucial to handle an increasing
number of users efficiently. The user interface should be intuitive and user-friendly, ensuring ease of
access. Security is a priority, with encrypted sensitive data and restricted unauthorized access.
Maintainability is also important, allowing for easy updates and feature enhancements. Finally, the
system must be highly reliable, ensuring uninterrupted operation without failures
● Performance: The system should provide fast response times for employee searches and
payroll processing.
● Scalability: It should handle an increasing number of employees and growing data efficiently.
● User Interface: The UI should be intuitive and user-friendly for easy navigation.
● Security: Employee data should be encrypted, and unauthorized access must be restricted.
● Reliability: Ensure consistent and uninterrupted operation with minimal downtime.
5.1.2 Analyze the Current System
Existing Issues
The current manual record-keeping system is prone to errors and inconsistencies, making employee
presence tracking difficult. Overdue fine calculations lack automation, leading to discrepancies.
Without automated reporting, data analysis becomes cumbersome.
● The current manual employee management system is prone to errors and inconsistencies in
attendance and payroll records.
● Payroll calculations lack automation, leading to inaccuracies in salary and deduction
processing.
● Leave requests are manually handled, causing delays in approvals.
● Lack of automated performance evaluation results in delayed feedback and appraisals.
Gaps Identified
To improve efficiency, a centralized database is required for managing records effectively. Salary
transactions should be automated to reduce manual workload. Security measures need to be
enhanced to protect sensitive data. A reporting system is essential for tracking key performance
indicators and improving decision-making.A centralized database is needed for efficient employee
record management.Automated payroll processing is necessary to eliminate manual errors.Improved
security features are required to safeguard sensitive employee data.Detailed reporting capabilities for
better decision-making and HR insights.

Dimpal Bagda (92310103023) 17 TC4 - C

5.2 System Design
The Employee Management System (EMS) utilizes a microservices architecture with modules for Employee
Profiles, Attendance, Payroll, Performance, Leave, and User Management. It features a web and mobile
interface connected via RESTful APIs, storing data in a secure relational database (e.g., PostgreSQL). Security
measures include encryption and role-based access control, while performance is optimized through caching
and load balancing to ensure scalability and reliability.
5.2.1 Architectural Design
The Employee Management System follows a three-tier architecture to ensure efficient functionality:

1. Presentation Layer: A web-based user interface that allows employees, HR, and admins to
interact with the system.
2. Business Logic Layer: Handles core functionalities such as attendance tracking, payroll
processing, and leave management.
3. Database Layer: Stores all employee records, attendance logs, payroll data, leave requests,
and performance reviews.

5.2.2 User Interface Design

The user interface (UI) is designed to be intuitive, visually appealing, and easy to navigate. The
system provides different dashboards for users based on their roles (Admin, HR, and Emplyees).
Key UI components include:

● Login Page: Secure login screen with role-based authentication.

● Admin Dashboard: Displays employee records, attendance summaries, and report generation
options.
● HR Dashboard: Manages payroll, leave requests, and performance evaluations.
● Employee Dashboard: Allows employees to view their attendance, leave balances, and
performance reviews.
● Payroll Screen: Displays salary details, deductions, bonuses, and net pay.
● Leave Application Screen: Allows employees to apply for leave and view approval status.
● Performance Review Screen: Displays employee ratings and feedback history.
● Notification System: Pop-up and email alerts for payroll updates, leave approvals, and
performance review submissions.

5.2.3 Module Description

User Management Module
The User Management Module in the Employee Management System handles employee registration,
profile updates, and role-based access control. It ensures that only authorized users can access
specific features by implementing authentication and authorization mechanisms.
Attendance Module
he Attendance Module automates the tracking of employee attendance through biometric or manual
entries. It maintains daily attendance logs and generates detailed reports for monitoring employee
punctuality and working hours.

Dimpal Bagda (92310103023) 18 TC4 - C

Payroll Module
The Payroll Module streamlines salary calculations by automatically factoring in base pay,
deductions, and bonuses. It also tracks salary disbursement history and tax details, ensuring accurate
financial record-keeping.

Leave Management Module

The Leave Management Module allows employees to apply for leave, track approval status, and
view their remaining leave balances. It manages the entire leave process by generating detailed leave
reports.

Performance Management Module

The Performance Management Module facilitates performance reviews by recording employee
ratings and collecting feedback from supervisors. It generates performance evaluation reports that
help in assessing employee productivity and identifying areas for improvement

Report Generation Module

Report Generation Module creates comprehensive reports on employee data, attendance trends,
payroll summaries, and performance metrics, providing valuable insights for HR and management
decision-making

5.2.4 Database Design and ER diagram

The database design of the Employee Management System is structured to efficiently store and manage
information related to employee , users, transactions. It ensures data integrity, consistency, and fast retrieval of
information. The database follows a relational model, with multiple interconnected tables representing
different entities and their relationships.

The database design for the Employee Management System is structured to efficiently store and
manage information related to employees, attendance, payroll, and performance. It ensures data
integrity, consistency, and fast retrieval.

Entities and Relationships:

● Employee (Emp_ID, Name, Email, Role, Department, Salary) – Stores employee details.
● Attendance (Attendance_ID, Emp_ID, Date, Status, Working_Hours) – Tracks daily
attendance.
● Payroll (Payroll_ID, Emp_ID, Base_Salary, Deductions, Bonuses, Net_Salary) – Manages
salary records.
● Leave (Leave_ID, Emp_ID, Leave_Type, Start_Date, End_Date, Status) – Tracks leave
applications.
● Performance (Perf_ID, Emp_ID, Rating, Feedback, Review_Date) – Stores performance
review data.
The ER diagram ensures structured relationships between employees, attendance, payroll, and
performance, facilitating efficient data management and retrieval.

Dimpal Bagda (92310103023) 19 TC4 - C

 Figure 5.1 ER Diagram

Dimpal Bagda (92310103023) 20 TC4 - C

 Practical 6
User’s view Analysis
Aim: Perform the user's view analysis for the suggested system by drawing Use case Diagram.

6. User View Analysis

User’s view analysis is the process of understanding the interactions of different users with the system.
It helps in identifying the functionalities required by different users and ensures that the system meets
their needs effectively.

6.1 Purpose of Use-Case:

The Use case diagram is used to gather the requirements of a system. It is used to get an out side
view of a system. It Identifies the external and internal factors influencing the system. It is also
used to show the interaction among the requirements.

6.2 Notations of Use-Case:

Notation Description Visual Representation

Actor
● Someone interacts with use case (system function).
● Named by noun.

● Actor plays a role in the business

● Similar to the concept of user, but a user can play different roles.
Use Case

● System function(process-automated or manual) ●

Named by verb+ Noun(or Noun Phrase).
Communication Link
The participation of an actor in a use case is shown by
connecting an actor to a use-case by a solid link. Actors may
be connected to use cases by associations, indicating that the
actor and the use-case communicate with one another using
messages.
Boundary of system
● The system boundary is potentially the entire system as
defined in the requirements document. For large and complex
systems, each module may be the system boundary.

Dimpal Bagda(92310103023) 21 TC4-C

 Extends

● Example: Indicates that an "Invalid-Password" use case may

include the behavior specified by base use case "Login
Account".
● Depict with a directed arrow having a dotted line. The tip of
arrow head points to the base use case and the child use case is
connected at the base of the arrow. The
stereotype"<<extends>>"identifies as an extend relationship
Include
● When a use case is depicted as using the functionality of another
use case, the relationship between the use cases is named as
include or uses relationship.
● A use case includes the functionality described in another use
case as a part of its business process flow.
Thestereotype"<<include>>"identifiestherelationshipasaninclud
erelationship.
Generalization

● A generalization relationship is a parent-child relationship

between use cases.

6.3 User’s View Analysis for Library Management System

User’s view analysis is the process of understanding the interactions of different users with the system. It helps
in identifying the functionalities required by different users and ensures that the system meets their needs
effectively.

Actors in the System

An actor is an entity that interacts with the system. The Employee Management System has the following
actors:

1.HR Managers:
● Login to the system.
● Track employee activities and records.
● Generate reports related to employee performance and attendance.
● Oversee payroll processing.
● Manage attendance records.

2.System Administrators:
● Login to the system.
● Check attendance details of employees.
● Provide technical support for system-related issues.

Dimpal Bagda(92310103023) 22 TC4-C

 3.Employee
● Apply for leave through the system. ● View their attendance records. ● Check and
download payslips

Use Cases
A use case represents a specific functionality of the system that is performed by an actor. The key use cases of
the Employee Management System are:

For HR Managers:
● Login – Access the system securely.
● Track Employee – Monitor employee records and performance.
● Generate Reports – Create reports related to attendance, payroll, and employee performance.
● Oversee Payroll – Manage salary processing and payroll details.
● Manage Attendance – Record and analyze employee attendance.

For System Administrators:

● Check Attendance – Verify attendance records for employees.
● Technical Support – Provide assistance with system errors and technical issues.

For Administrators:
● Apply for Leave – Submit leave requests for approval. ● View Attendance – Check personal attendance
history.
● Check Payslips – View and download salary slips.

Figure 1: use case diagram

Dimpal Bagda(92310103023) 23 TC4-C

 Practical 7
Structural View Diagram
Aim: To Design structural view diagram for the selected system using class Diagram, Object
Diagram, and Component Diagram.

7.1 Structural View Diagrams

Structure diagrams depict the static structure of the elements in your system. i.e., how one object
relates to another.It shows the things in the system – classes, objects, packages or modules, physical
nodes, components, and interfaces. Since structure diagrams represent the structure, they are used
extensively in documenting the software architecture of software systems. The Seven UML structural
diagrams are roughly organized around the major groups of things you’ll find when modeling a
system. Since structure diagrams represent the structure, they are used extensively in documenting
the software architecture of software systems.
Table 7.1:Structural View Diagram
Structural Diagram Brief Description
Composite Structure It shows the internal structure of a classifier, classifier
Diagram interactions with the environment through ports, or
behavior of a collaboration.
Deployment Diagram It shows a set of nodes and their relationships that
illustrates the static deployment view of an architecture.
Package Diagram It groups related UML elements into a collection of
logically related UML structure.
Class Diagram It shows a set of classes, interfaces, and collaborations
and their relationships, typically, found in modeling
object-oriented systems.
Object Diagram It shows a set of objects and their relationships, which
is the static snapshots of instances of the things found
in class diagrams.
Component Diagram It shows a set of components and their relationships
that illustrates the static implementation view of a
system.
7.1.1 Class Diagram
The UML Class diagram is a graphical notation used to construct and visualize object oriented
systems. A class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's:
● classes,
● their attributes,
● operations (or methods),
● and the relationships among objects.
Purpose of Class diagram:

Dimpal Bagda(92310103023) 24 TC4 - C

 ● Class diagram is a static diagram.
● It represents the static view of an application.
● Class diagram is not only used for visualizing, describing, and documenting different aspects
of a system but also for constructing executable code of the software application.
Notations Class Notation
A class notation consists of three parts:

1.Class Name
● The name of the class appears in the first partition.
2.Class Attributes
● Attributes are shown in the second partition.
● The attribute type is shown after the colon.
● Attributes map onto member variables (data members) in code.
3.Class Operations (Methods)
● Operations are shown in the third partition. They are services the class provides.
● The return type of a method is shown after the colon at the end of the method signature.
● The return type of method parameters is shown after the colon following the parameter
name.
● Operations map onto class methods in code
●

The graphical representation of the class - MyClass as shown above:

● MyClass has 3 attributes and 3 operations
● Parameter p3 of op2 is of type int
● op2 returns a float
● op3 returns a pointer (denoted by a *) to Class6

4.Class Relationships
A class may be involved in one or more relationships with other classes. A relationship can be one of
the following types: (Refer to the figure on the right for the graphical representation of relationships).
Inheritance (or Generalization):
● Represents an "is-a" relationship.
● An abstract class name is shown in italics.
● SubClass1 and SubClass2 are specializations of Super Class.
● A solid line with a hollow arrowhead that point from the child to the parent class

Dimpal Bagda(92310103023) 25 TC4 - C

Simple Association:
● A structural link between two peer classes.
● There is an association between Class1 and Class2
● A solid line connecting two classes

Aggregation:
A special type of association. It represents a "part of" relationship.
● Class2 is part of Class1.
● Many instances (denoted by the *) of Class2 can be associated with Class1.
● Objects of Class1 and Class2 have separate lifetimes.
● A solid line with an unfilled diamond at the association end connected to the class of
composite

Composition:
A special type of aggregation where parts are destroyed when the whole is destroyed.
● Objects of Class2 live and die with Class1.
● Class2 cannot stand by itself.
● A solid line with a filled diamond at the association connected to the class of composite.

Dependency:
● Exists between two classes if the changes to the definition of one may cause changes to the
other (but not the other way around).
● Class1 depends on Class2
● A dashed line with an open arrow
Multiplicity
How many objects of each class take part in the relationships and multiplicity can be expressed as:
● Exactly one - 1
● Zero or one - 0..1
● Many - 0..* or *
● One or more - 1..*

Dimpal Bagda(92310103023) 26 TC4 - C

7.1.2 Class Diagram for Library Management system

Figure 7.1 class diagram

Dimpal Bagda(92310103023) 27 TC4 - C

7.1.2 Object Diagram
Object diagrams are a visual representation in UML (Unified Modeling Language) that illustrates the
instances of classes and their relationships within a system at a specific point in time. They display
objects, their attributes, and the links between them, providing a snapshot of the system’s structure
during execution.
An object diagram in UML is useful because it provides a clear and visual representation of specific
instances of classes and their relationships at a particular point in time, aiding in understanding and
communicating the structure and interactions within a system.

Object Diagram Notations

The object diagram in UML uses specific notations to represent instances of classes and their
relationships at a particular moment in time.

1. Objects or Instance specifications

When we instantiate a classifier in a system, the object we create represents an entity which exists in
the system. We can represent the changes in object over time by creating multiple instance
specifications. We use a rectangle to represent an object in an object diagram

2.Attributes and Values

Inside the object box, attributes of the object are listed along with their specific values.

7.1.3 Object Diagram for A Library Management System

An Object diagram showing aggregation in library system

Dimpal Bagda(92310103023) 28 TC4 - C

7.1.4 Component Diagram
Component-based diagrams are essential tools in software engineering, providing a visual
representation of a system’s structure by showcasing its various components and their interactions.
These diagrams simplify complex systems, making it easier for developers to design, understand, and
communicate the architecture.

Components of Component-Based Diagram

1. Component
Represent modular parts of the system that encapsulate functionalities. Components can be software
classes, collections of classes, or subsystems.
Symbol: Rectangles with the component stereotype («component»). Function:
Define and encapsulate functionality, ensuring modularity and reusability.

2. Interfaces
Specify a set of operations that a component offers or requires, serving as a contract between the
component and its environment.
Symbol: Circles (lollipops) for provided interfaces and half-circles (sockets) for required interfaces.
Function: Define how components communicate with each other, ensuring that components can be
developed and maintained independent.

3.Relationships
Depict the connections and dependencies between components and interfaces.
● Symbol: Lines and arrows.
-Dependency (dashed arrow): Indicates that one component relies on another.

Dimpal Bagda(92310103023) 29 TC4 - C

 -Association (solid line): Shows a more permanent relationship between components. -
Assembly connector: Connects a required interface of one component to a provided interface
of another.

● Function: Visualize how components interact and depend on each other, highlighting
communication paths and potential points of failure.
●

4. Ports
Role: Represent specific interaction points on the boundary of a component where interfaces are
provided or required.
Symbol: Small squares on the component boundary.
Function: Allow for more precise specification of interaction points, facilitating detailed design and
implementation.

5. Artifacts
Represent physical files or data that are deployed on nodes.
Symbol: Rectangles with the artifact stereotype («artifact»).
Function: Show how software artifacts, like executables or data files, relate to the components.

Dimpal Bagda(92310103023) 30 TC4 - C

 6. Nodes
Represent physical or virtual execution environments where components are deployed.
Symbol: 3D boxes.
Function: Provide context for deployment, showing where components reside and execute within the
system’s infrastructure.

7.1.5 Component Diagram of A Library Management system

Dimpal Bagda(92310103023) 31 TC4 - C

 Practical 8
Function -Oriented diagram

Aim: Design function-oriented diagram for the selected system using Data Flow Diagrams
8.1 Data Flow Diagrams(DFD)
Purpose of Data Flow Diagrams:
A data flow diagram (DFD) maps out the flow of information for any processor system.
It uses defined symbols like rectangles, circles and arrows, plus short text labels, to
show data inputs, outputs, storage points and the routes between each destination.

Notations of Data Flow Diagrams:

● Entities:
- Entities include source and destination of the data. Entities are represented by
rectangle with their corresponding names. ● Process:
- The tasks performed on the data is known as process. Process is represented by
circle. Somewhere round edge rectangles are also used to represent process. ● Data
Storage:
- Data storage includes the database of the system. It is represented by rectangle with
both smaller sides missing or in other words within two parallel lines.
● Data Flow:
- The movement of data in the system is known as dataflow. It is represented with the
help of arrow. The tail of the arrow is source and the head of the arrow is destination.

8.1.1 Levels of Data Flow Diagrams:

Dimpal Bagda(92310103023) 32 TC4 - C

 ● In Software engineering DFD (data flow diagram) can be drawn to represent the system
of different levels of abstraction. Higher-level DFDs are partitioned into low levels-
hacking more information and functional elements. Levels in DFD are numbered 0, 1, 2or
beyond. Here, we will see mainly 3 levels in the data flow diagram, which are:0-level
DFD,1-level DFD, and2-levelDFD.
● 0-level DFD:
- It is also known as a context diagram. It’s designed to be an abstraction view, showing
the system as a single process with its relationship to external entities. It represents
the entire system as a single bubble within put and output data indicated by
incoming/outgoing arrows.
● 1-level DFD:
- In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes.
In this level, we highlight the main functions of the system and breakdown thehigh-
levelprocessof0-levelDFDinto sub processes.
● 2-level DFD:
- 2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan or
record the specific/necessary detail about the system’s functioning.
8.1.2 DFD of Library Management system
Level 0(Context level diagram )

Figure 8.1 Level 0 DFD

Level 1

Dimpal Bagda(92310103023) 33 TC4 - C

 Figure 8.2 Level 1 DFD

Practical 9
Behavioral View diagram
Aim: Design the behavioral view diagram for the selected system. Use following diagrams
1. Interaction Diagrams a. Sequence Diagrams b. Collaboration Diagram
Dimpal Bagda(92310103023) 34 TC4 - C
2. State–Chart Diagrams
3. Activity Diagrams

Behavioral diagrams are used to visualize, specify, construct, and document the dynamic aspects of
a system. It shows how the system behaves and interacts with itself and other entities (users, other
systems). They show how data moves through the system, how objects communicate with each
other, how the passage of time affects the system, or what events cause the system to change
internal states. Since behavior diagrams illustrate the behavior of a system, they are used extensively
to describe the functionality of software systems. As an example, the activity diagram describes the
business and operational step-by-step activities of the components in a system. In other words, a
behavioral diagram shows how the system works ‘in motion’, that is how the system interacts with
external entities and users, how it responds to input or event and what constraints it operates under.

9.1 Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system
Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.
Terminology of Interaction diagram:
- An interaction diagram contains lifelines, messages, operators, state invariants and
constraints. Lifeline
A lifeline represents a single participant in an interaction. It describes how an instance of
a specific classifier participates in the interaction. A life line represents a role that an
instance of the classifier may play in the interaction.
Various attributes of a lifeline,

❖ Name
- It is used to refer to the life line within a specific interaction.
- The name of a life line is optional.
❖ Type
- It is the name of a classifier of which the life line represents an instance.
❖ Selector
- It is a Boolean condition which is used to select a particular instance that satisfies the
requirement.
- Select or attribute is also optional.
Messages
● A message is a specific type of communication between two lifelines in an interaction. A message
involves following activities ● A call message which is used to call an operation. ● A message to
create an instance.
● A message to destroy an instance.
● For sending a signal.
Message Type Description Example

Dimpal Bagda(92310103023) 35 TC4 - C

Synchronous Sender waits for receiver to complete objectA.method()
before continuing
Asynchronous Sender continues without waiting for sendMessage()
response
Return Represents return of control or data from return value
receiver to sender
Create Indicates creation of a new object new Object()
Delete Indicates termination of an object object.destroy()
Self-Message An object sends a message to itself this.doSomething()
Found Message originates outside the system or External API call
Message is unidentified
Lost Message Message is sent but the destination is Log message not
unknown or not modeled saved
State in variants and constraints
- When an instance or a lifeline receives a message, it can cause it to change the state.
- A state is a condition or a situation during a life time of an object at which it satisfies
some constraint, performs some operations, and waits for some event.
- In an interaction diagram, not all messages cause changes to change the state of an
instance.
Some messages donot have the values of some attributes. It has no side effects on the state of an
object.
Operator
An operator specifies an operation on how the operands are going to be executed.
- The operators in UML support operations on data in the form of branching as well as an
iteration. Various operators can be used to ensure the use of iteration and branching in the
UML model.
Iteration
- In an interaction diagram, we can also show iteration using an iteration expression.
- An iteration expression consists of an iteration specifier and an optional iteration clause.
There is no pre-specified syntax for UML iteration.
Branching
- In an interaction diagram, we can represent branching by adding guard conditions to the
messages. Guard conditions are used to check if a message can be sent forward or not. - A
message is sent forward only when its guard condition is true.
- A message can have multiple guard conditions, or multiple messages can have the same
guard condition.
- Branching in UML is achieved with the help of alt and opt, operators.
Types of Interaction diagram:

● Different types of interaction diagrams defined in UML:

● Sequence diagram

Dimpal Bagda(92310103023) 36 TC4 - C

 ● Collaboration diagram
● Timing diagram
9.1.1 Sequence diagram
Sequence Diagrams are interaction diagrams that detail how operations are carried out. They capture
the interaction between objects in the context of a collaboration. Sequence Diagrams are time focus
and they show the order of the interaction visually by using the vertical axis of the diagram to
represent time what messages are sent and when. Purpose of Sequence Diagram
● Model high-level interaction between active objects in a system
● Model the interaction between object instances within a collaboration that realizes a use case
● Model the interaction between objects within a collaboration that realizes an operation
● Either model generic interactions (showing all possible paths through the interaction) or
specific instances of a interaction (showing just one path through the interaction)

Sequence Diagram Notation

Notation Symbol
Actor
● A type of role played by an entity
that interacts with the subject (e.g.,
by exchanging signals and data)
● External to the subject (i.e., in the
sense that an instance of an actor is
not a part of the instance of its
corresponding subject).
● Represent roles played by human
users, external hardware, or other
subjects.
Lifeline
● A lifeline represents an individual
participant in the Interaction.

Activations
● A thin rectangle on a lifeline) represents the period
during which an element is performing an operation.
● The top and the bottom of the of the rectangle are
aligned with the initiation and the completion time
respectively

Dimpal Bagda(92310103023) 37 TC4 - C

Call Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Call message is a kind of message that represents an
invocation of operation of target lifeline.

Return Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Return message is a kind of message that represents
the pass of information back to the caller of a
corresponded former message.

Self Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Self message is a kind of message that represents the
invocation of message of the same lifeline.

Recursive Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Recursive message is a kind of message that represents
the invocation of message of the same lifeline. It's
target points to an activation on top of the activation
where the message was invoked from.

Create Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Create message is a kind of message that represents
the instantiation of (target) lifeline.

Destroy Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Destroy message is a kind of message that represents
the request of destroying the lifecycle of target lifeline.

Dimpal Bagda(92310103023) 38 TC4 - C

Duration Message
● A message defines a particular communication
between Lifelines of an Interaction.
● Duration message shows the distance between two
time instants for a message invocation.

Note
A note (comment) gives the ability to attach various remarks
to elements. A comment carries no semantic force, but may
contain information that is useful to a modeler.
Message and Focus of Control
● An Event is any point in an interaction where something occurs.
● Focus of control: also called execution occurrence, an execution occurrence
● It shows as tall, thin rectangle on a lifeline)
● It represents the period during which an element is performing an operation. The top and the
bottom of the rectangle are aligned with the initiation and the completion time respectively.

Sequence Fragments
● Sequence fragments make it easier to create and maintain accurate sequence diagrams
● A sequence fragment is represented as a box, called a combined fragment, which encloses a
portion of the interactions within a sequence diagram
● The fragment operator (in the top left cornet) indicates the type of fragment
● Fragment types: ref, assert, loop, break, alt, opt, neg
Operator Fragment Type
alt Alternative multiple fragments: only the one whose condition is true will execute.
opt Optional: the fragment executes only if the supplied condition is true. Equivalent to an alt
only with one trace.
par Parallel: each fragment is run in parallel.
loop Loop: the fragment may execute multiple times, and the guard indicates the basis of
iteration.

Dimpal Bagda(92310103023) 39 TC4 - C

region Critical region: the fragment can have only one thread executing it at once.
neg Negative: the fragment shows an invalid interaction.
ref Reference: refers to an interaction defined on another diagram. The frame is drawn to
cover the lifelines involved in the interaction. You can define parameters and a return
value.
sd Sequence diagram: used to surround an entire sequence diagram.

9.1.2 Collaboration Diagram (Communication diagram)

Collaboration diagrams (known as Communication Diagram) are used to show how objects
interact to perform the behavior of a particular use case, or a part of a use case. Along with
sequence diagrams, collaboration are used by designers to define and clarify the roles of the
objects that perform a particular flow of events of a use case. They are the primary source of
information used to determining class responsibilities and interfaces.

● A Collaboration is a collection of named objects and actors with links connecting them. They collaborate
in performing some task.
● A Collaboration defines a set of participants and relationships that are meaningful for a given set of
purposes
● A Collaboration between objects working together provides emergent desirable functionalities in Object-
Oriented systems
● Each object (responsibility) partially supports emergent functionalities
● Objects are able to produce (usable) high-level functionalities by working together
● Objects collaborate by communicating (passing messages) with one another in order to work together

Notations of Collaboration Diagram

Objects
An object is represented by an object symbol showing the name of the object and its class
underlined, separated by a colon:
Object_name : class_name
You can use objects in collaboration diagrams in the following ways:
● Each object in the collaboration is named and has its class specified
● Not all classes need to appear
● There may be more than one object of a class
● An object’s class can be unspecified. Normally you create a collaboration diagram with
objects first and specify their classes later.

Dimpal Bagda(92310103023) 40 TC4 - C

 ● The objects can be unnamed, but you should name them if you want to discriminate different
objects of the same class.

Actors
Normally an actor instance occurs in the collaboration diagram, as the invoker of the interaction. If
you have several actor instances in the same diagram, try keeping them in the periphery of the
diagram.
● Each Actor is named and has a role
● One actor will be the initiator of the use case

Links
Links connect objects and actors and are instances of associations and each link corresponds to an
association in the class diagram Links are defined as follows:
● A link is a relationship among objects across which messages can be sent. In collaboration
diagrams, a link is shown as a solid line between two objects.
● An object interacts with, or navigates to, other objects through its links to these objects.
● A link can be an instance of an association, or it can be anonymous, meaning that its
association is unspecified.
● Message flows are attached to links, see Messages.

Messages
A message is a communication between objects that conveys information with the expectation that
activity will ensue. In collaboration diagrams, a message is shown as a labeled arrow placed near a
link.
● The message is directed from sender to receiver
● The receiver must understand the message
● The association must be navigable in that direction

Steps for Creating Collaboration Diagrams

1. Identify behavior whose realization and implementation is specified

2. Identify the structural elements (class roles, objects, subsystems) necessary to carry out the
functionality of the collaboration
● Decide on the context of interaction: system, subsystem, use case and operation
3. Model structural relationships between those elements to produce a diagram showing the
context of the interaction
4. Consider the alternative scenarios that may be required ● Draw instance level
collaboration diagrams, if required.
● Optionally draw a specification level collaboration diagram to summarize the
alternative scenarios in the instance level sequence diagrams

9.2 State–Chart Diagrams

Purpose of State-Chart diagram:

Dimpal Bagda(92310103023) 41 TC4 - C

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

9.3 Activity Diagram

Purpose of Activity Diagram:
An activity diagram shows business and software processes as a progression of actions.
These actions can be carried out by people, software components or computers. Activity
diagrams are used to describe business processes and use cases as well as to document the
implementation of system processes.
Notations of Activity Diagram:

Dimpal Bagda(92310103023) 42 TC4 - C

Synchronization
● A join node joins multiple concurrent flows back
into a single outgoing flow.
● A fork and join mode used together are often
referred to as synchronization.

Dimpal Bagda(92310103023) 43 TC4 - C

Synchronization
● A join node joins multiple concurrent flows back in
to a single outgoing flow.
● A fork and join mode used together are often
referred to as synchronization.

Time Event
● This refers to an event that stops the flow for a
time; an hour glass depicts it.

Merge Event
● A merge event brings together multiple flows that
are not concurrent.
Sent and Received Signals
● They appear in pairs of sent and received signals,
because the state can't change until a response is
received.
Interrupting Edge
● They An event, such as a cancellation, that
interrupts the flow denoted with a lightning
bolt.

Sequence Diagram of Employee Management System

Dimpal Bagda(92310103023) 44 TC4 - C

Collaboration Diagram for Employee Management system

Dimpal Bagda(92310103023) 45 TC4 - C

State chart Diagram for Employee Management system

Dimpal Bagda(92310103023) 46 TC4 - C

Activity Diagram for Employee Management

Dimpal Bagda(92310103023) 47 TC4 - C

 Practical 10
Case Study on Various Testing Tools
Aim: Conduct a case study on different software testing tools. The study should include the
following:

1. Tool Overview: Provide an overview of several commonly used testing tools, including their
features and capabilities.
2. Types of Testing Supported: Discuss the types of testing each tool supports (e.g., unit testing,
integration testing, system testing, regression testing).
3. Comparison: Compare and contrast the tools in terms of ease of use, compatibility, cost, and
effectiveness.
4. Practical Applications: Analyze the real-world application of these tools in software development
projects.
5. Pros and Cons: Highlight the advantages and disadvantages of each testing tool based on your
research.

1. Tool Overview

1.1. Selenium

 Overview: Selenium is an open-source tool primarily used for automating web browsers. It
provides a suite of tools for different aspects of automation (Selenium WebDriver, Selenium IDE,
and Selenium Grid).
 Features:
o Supports multiple programming languages (Java, Python, C#, Ruby, etc.).
o Cross-browser testing support (Chrome, Firefox, Internet Explorer, etc.).
o Can automate web applications across different operating systems.
o Provides integration with CI/CD tools like Jenkins.

1.2. JUnit

 Overview: JUnit is a widely used testing framework for Java applications. It supports unit testing
and is widely adopted in the Java development community.
 Features:
o Framework for writing and running tests.
o Annotations for setting up and running tests (e.g., @Test, @Before, @After).
o Integration with build tools like Maven and Gradle.
o Supports test-driven development (TDD) practices.

1.3. LoadRunner

 Overview: LoadRunner is a performance testing tool developed by Micro Focus. It is used for
load testing and stress testing to simulate multiple virtual users interacting with an application.

Dimpal Bagda(92310103023) 48 TC4 - C

  Features:
o Simulates thousands of virtual users to test the performance under load.
o Supports multiple protocols (HTTP, SOAP, Web Services, etc.).
o Advanced analysis and reporting capabilities.
o Integration with other Micro Focus tools.

1.4. Postman

 Overview: Postman is a popular tool for testing APIs. It provides a user-friendly interface for
designing, sending, and analyzing HTTP requests and responses.
 Features:
o Supports RESTful API testing.
o Can create and execute automated API test scripts.
o Allows parameterization and data-driven testing.
o Supports collection management and automated testing using Postman Collections.

1.5. TestComplete

 Overview: TestComplete is an automated testing tool for functional testing of desktop, web, and
mobile applications.
 Features:
o Supports keyword-driven and script-based testing.
o Integrates with CI/CD tools.
o Record-and-playback functionality for ease of use.
o Cross-platform testing support (Windows, macOS, and mobile platforms).

2. Types of Testing Supported

2.1. Selenium

 Types of Testing Supported:

o Functional Testing: Automates functional test cases for web applications.
o Regression Testing: Re-running tests after changes to ensure that no new issues are
introduced.
o Smoke Testing: Verifies that basic functionalities work after the deployment of the
application.

2.2. JUnit

 Types of Testing Supported:

o Unit Testing: Testing individual components or units of code to ensure they function
correctly.
o Integration Testing: Can be used for integration testing to check if different units or
modules work together.

Dimpal Bagda(92310103023) 49 TC4 - C

 o Test-Driven Development (TDD): JUnit promotes the TDD approach by allowing
developers to write tests before writing the actual code.

2.3. LoadRunner

 Types of Testing Supported:

o Performance Testing: Measures how well an application performs under varying load
conditions.
o Stress Testing: Tests the system's stability by applying heavy load to the system beyond
its capacity.
o Scalability Testing: Measures how well the application can scale up or down under
varying load conditions.

2.4. Postman

 Types of Testing Supported:

o API Testing: Allows testing of RESTful APIs and web services.
o Regression Testing: Validates if existing API functionality works after modifications.
o Load Testing: Using Postman’s Collection Runner to simulate multiple requests to check
the API's performance.

2.5. TestComplete

 Types of Testing Supported:

o Functional Testing: Ensures that the application works as expected.
o Regression Testing: Verifies that the application functions as expected after changes.
o UI Testing: Verifies that the user interface behaves correctly across different platforms.
o Performance Testing: While not as extensive as LoadRunner, it can be used for some
basic performance checks.

3. Comparison of Testing Tools

Feature Selenium JUnit LoadRunner Postman TestComplete

Ease of Use Moderate Easy (Designed Moderate Easy (User- Easy (Record-and-
(Requires for Java devs) (Requires friendly playback)
scripting) expertise) interface)
Compatibilit Cross- Java-based Primarily for web Cross-platform Cross-platform
y browser, (Platform applications (Windows, (Windows,
Cross- dependent) macOS) macOS)
platform
Cost Free (Open- Free (Open- Expensive Free (Basic Expensive
source) source) (Commercial) version), Paid (Commercial)
plans
Effectiveness Highly Highly Highly effective Highly effective Effective for
effective for effective for for load testing for API testing functional testing
web apps unit tests

Dimpal Bagda(92310103023) 50 TC4 - C

4. Practical Applications

4.1. Selenium

 Real-World Application: Selenium is commonly used by QA teams to automate repetitive

testing tasks for web applications. It is particularly useful for regression testing, where web
applications undergo frequent changes, and manual testing can be time-consuming.

4.2. JUnit

 Real-World Application: JUnit is extensively used by Java developers for unit testing and is
integrated into build systems like Maven and Gradle. It is a staple tool in Test-Driven
Development (TDD) workflows.

4.3. LoadRunner

 Real-World Application: LoadRunner is used by performance testing teams to simulate load

conditions on applications, particularly when preparing for product launches or when a system is
expected to handle a large number of users.

4.4. Postman

 Real-World Application: Postman is widely used by developers and QA testers for API testing.
It is often employed in scenarios where microservices or REST APIs need to be tested
independently of the front-end interface.

4.5. TestComplete

 Real-World Application: TestComplete is used in agile environments for automated functional

testing of both web and desktop applications. It is often employed by testing teams to automate
test execution and ensure that code changes do not break existing functionality.

5. Pros and Cons

5.1. Selenium

 Pros:
o Open-source and free to use.
o Supports various programming languages and browsers.
o Strong community support and widespread adoption.
 Cons:

Dimpal Bagda(92310103023) 51 TC4 - C

 o Requires programming knowledge.
o Not ideal for testing desktop applications.
o Setup and configuration can be complex.

5.2. JUnit

 Pros:
o Simple and easy to use for Java developers.
o Seamlessly integrates with other tools in the Java ecosystem.
o Encourages Test-Driven Development.
 Cons:
o Limited to Java applications.
o Cannot be used for functional or UI testing.

5.3. LoadRunner

 Pros:
o Powerful tool for performance and load testing.
o Simulates thousands of virtual users to test scalability.
o Detailed reporting and analysis.
 Cons:
o Expensive, with a high cost for licensing.
o Steep learning curve for beginners.

5.4. Postman

 Pros:
o Free for basic usage.
o User-friendly interface and easy to set up.
o Great for API testing and automated script execution.
 Cons:
o Limited to API testing; cannot handle UI or functional testing.
o Lacks advanced performance testing features.

5.5. TestComplete

 Pros:
o Supports functional, regression, and performance testing.
o Easy to use with record-and-playback functionality.
o Cross-platform testing for web, mobile, and desktop applications.
 Cons:
o Expensive commercial product.
o May not be suitable for very complex testing scenarios.

Conclusion

Dimpal Bagda(92310103023) 52 TC4 - C

Each testing tool has its strengths and weaknesses, making them suitable for different scenarios. The
selection of a tool depends on the specific needs of the project, the type of testing required, the
development environment, and the team's expertis

Dimpal Bagda(92310103023) 53 TC4 - C