SOFTWARE ENGINEERING LAB

PRACTICAL FILE
(BCS-651)

Department of Computer Science and Engineering

G.L. Bajaj Institute of Technology and Management

Plot No.2,Name:
APJShivang
AbdulSharma
Kalam Road, Knowledge Park 3, Greater Noida
SUBMITTED BY:

Semester: 6 Uttar Pradesh, India, Pin-201306

Section: F
Roll No: 2301920100298
Group: G1 Session : 2025-26
SUBMITTED TO:
SUBMITTED BY:
Mr. Harshit Thakur SUBMITTED TO:
(Assistant Professor) Mr. Panchanan
Name : Aman Yadav
Section : H (Assistant Professor)
Semester : 6
Roll No : 2301921690008
Group : G1
[Link]. Experiments Experiment Submission Grade Signature
Date Date
1 Prepare SRS document in line with the
IEEE recommended standards.
2 Draw the use case diagram and specify
the role of each of the actors. Also
state the precondition, post condition
and function of each use case.
3 Draw the activity diagram.
4 Identify the classes. Classify them as
weak and strong classes and draw the
class diagram.
5 Draw the sequence diagram for any two
scenarios.
6 Draw the collaboration diagram.
7 Draw the component diagram.
8 Draw the state chart diagram.
9 Perform forward engineering in java.
(Model to code conversion)
10 Perform reverse engineering in java.
(Code to Model conversion)
11 Draw the deployment diagram.
 Experiment No.:1

AIM:
Prepare a SRS document in line with the IEEE recommended standards.
Description:
An SRS is basically an organization's understanding (in writing) of a customer or potential client's system
requirements and dependencies at a particular point in time (usually) prior to any actual design or
development work. It's a two-way insurance policy that assures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a software
system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any
required constraints by which the system must abide. The SRS also functions as a blueprint for completing
a project with as little cost growth as possible. The SRS is often referred to as the "parent" document
because all subsequent project management documents, such as design specifications, statements of work,
software architecture specifications, testing and validation plans, and documentation plans, are related to it.
It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer
design suggestions, possible solutions to technology or business issues, or any other information other than
what the development team understands the customer's system requirements to be.

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

· It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary
to address those problems. Therefore, the SRS should be written in natural language (versus a
formal language, explained later in this article), in an unambiguous manner that may also include
charts, tables, data flow diagrams, decision tables, and so on.
· It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
· It serves as an input to the design specification. As mentioned previously, the SRS serves as the
parent document to subsequent documents, such as the software design specification and statement
of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so
that a design solution can be devised.
· It serves as a product validation check. The SRS also serves as the parent document for testing and
validation strategies that will be applied to the requirements for verification.
·
SRSs are typically developed during the first stages of "Requirements Development," which is the initial
product development phase in which information is gathered about what requirements are needed—and
not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and
perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current
business environment. The actual specification, then, is written after the requirements have been gathered
and analyzed.
 A sample of basic SRS( DriftSentinel ):

1. Introduction:
1.1 Purpose
This document provides a detailed description of the requirements for DriftSentinel, a real-time
MLOps framework designed to monitor deployed machine learning systems for data drift and data
poisoning attacks. It serves as a reference for developers, stakeholders, and evaluators to understand
system functionality and constraints.
1.2 Document Conventions
· “Shall” indicates mandatory requirements
· “Should” indicates recommended requirements
· “May” indicates optional features
1.3 Intended Audience
· Software Developers
· Machine Learning Engineers
· Project Evaluators / Faculty
· System Architects
1.4 Additional Information
This system focuses on post-deployment monitoring of machine learning models and ensures their
reliability and security in dynamic environments.
1.5 Contact Information / Team Members
Project Name: DriftSentinel
1.6 References
· IEEE SRS Documentation Standards
· MLOps Best Practices
· Statistical Drift Detection Method
2. Overall Description:
2.1 Product Perspective
DriftSentinel is a monitoring layer that operates alongside deployed machine learning models. It
continuously analyzes incoming data streams to detect anomalies and distribution shifts.
2.2 Product Functions
· Real-time model inference monitoring
· Data drift detection
· Data poisoning detection
· Alert generation and logging
· Automated retraining trigger
· Model version management
2.3 User Classes and Characteristics
User Type Description
Admin Monitors alerts and system logs
ML Engineer Manages model lifecycle and retraining
End User Sends prediction requests
 2.4 Operating Environment
· Operating System: Windows / Linux
· Programming Language: Python
· Deployment: Docker containers
· Optional: Cloud platforms (AWS, GCP, Azure)
2.5 User Environment
· API-based interaction
· Monitoring dashboard (optional)
· Command-line interface for backend
2.6 Design and Implementation Constraints
· Must support real-time data processing
· Should maintain low latency
· Must integrate with MLflow
· Must use streaming architecture
2.7 Assumptions and Dependencies
· Availability of training and baseline data
· Continuous incoming data stream
· Stable network connectivity

3. External Interface Requirements:

3.1 User Interfaces
· REST API for prediction requests
· Optional dashboard for monitoring system metrics
3.2 Hardware Interfaces
· Standard computing systems
· Optional cloud infrastructure
3.3 Software Interfaces
· MLflow (model registry)
· Apache Kafka (data streaming)
· PostgreSQL (database)
3.4 Communication Interfaces
· HTTP/HTTPS protocols
· Kafka messaging system

4. System Features:
4.1 Real-Time Monitoring System:
Description and Priority
Continuously monitors incoming inference data.
Priority: High
Action / Result
Captures and stores input data for analysis.
Functional Requirements
· The system shall log all incoming data
 · The system shall process data in real time
4.2 Drift Detection Module:
Description and Priority
Detects statistical changes in data distribution.
Priority: High
Action / Result
Triggers alerts when drift is detected.
Functional Requirements
· The system shall compute PSI, KL Divergence, KS Test
· The system shall compare live data with baseline data
· The system shall generate drift scores
4.3 Data Poisoning Detection Module:
Description and Priority
Detects anomalous or malicious inputs.
Priority: High
Action / Result
Flags suspicious data and logs events.
Functional Requirements
· The system shall use anomaly detection techniques
· The system shall detect abnormal input patterns
· The system shall monitor confidence variations
4.4 Decision Engine:
Description and Priority
Determines system response based on analysis.
Priority: High
Action / Result
Triggers alerts or retraining processes.
Functional Requirements
· The system shall evaluate thresholds
· The system shall initiate mitigation actions
4.5 Model Management System:
Description and Priority
Manages model versions and updates.
Priority: Medium
Action / Result
Stores and updates model versions.
Functional Requirements
· The system shall maintain version history
· The system shall support rollback
· The system shall track performance metrics

5. Other Non-Functional Requirements:

5.1 Performance Requirements:
 · Response time should be less than 200 ms
· System must support real-time processing
· Efficient handling of streaming data
5.2 Safety Requirements:
· Prevent corrupted data from retraining
· Ensure system stability under load
5.3 Security Requirements:
· Input validation mechanisms
· Secure API endpoints
· Logging of suspicious activity
· Controlled model updates
5.4 Software Quality Attributes:
Attribute Requirement
Continuous monitoring
Reliability
without failure
Scalability Handle increased data load
Maintainability Modular system design
Availability High uptime
5.5 Project Documentation:
· SRS Document
· Design Specification
· Testing Plan
· Deployment Guide
5.6 User Documentation:
· API usage guide
· Setup instructions
· Monitoring guidelines
Conclusion:
DriftSentinel ensures reliable and secure machine learning deployment by detecting data drift and malicious inputs
in real time. It provides automated monitoring and response mechanisms to maintain model performance. This
document outlines the requirements needed to build an effective MLOps monitoring system.
 Experiment No.:2

AIM:
Draw the use case diagram and specify the role of each of the actors. Also state the precondition, post
condition and function of each use case.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.
Software Requirements:
[Link], Windows XP.
Description:
A use case diagram represents the interaction between users (actors) and the system. It helps in understanding
system functionality from a user’s perspective and defines the scope of the system.
In this phase, DriftSentinel focuses on model inference, real-time monitoring, drift detection, poisoning detection,
and dashboard visualization, without including retraining or model management.
Actors and Their Roles:
1. End User (Client)
· Sends input data for prediction
· Receives prediction results
2. Admin
· Monitors system alerts
· Views dashboard and logs
3. System (DriftSentinel)
· Performs prediction
· Detects drift and anomalies
· Generates alerts
Use Cases
1. Send Prediction Request
2. Generate Prediction
3. Stream Data to Monitoring System
4. Detect Data Drift
5. Generate Alerts
6. View Monitoring Dashboard
Use Case Specifications
Use Case 1: Send Prediction Request
· Actor: End User
· Precondition: System is active and API is available
· Postcondition: Input data is sent to the system
· Function: Sends data for prediction
Use Case 2: Generate Prediction
· Actor: System
· Precondition: Input data received
· Postcondition: Prediction output generated
· Function: Processes input using ML model
Use Case 3: Stream Data to Monitoring System
· Actor: System
 · Precondition: Prediction completed
· Postcondition: Data sent to monitoring pipeline
· Function: Streams input and output data for analysis
Use Case 4: Detect Data Drift
· Actor: System
· Precondition: Sufficient data collected
· Postcondition: Drift score generated
· Function: Compares current data with baseline distribution
Use Case 5: Generate Alerts
· Actor: Admin
· Precondition: Drift or anomaly detected
· Postcondition: Alert generated
· Function: Notifies abnormal system behavior
Use Case 6: View Monitoring Dashboard
· Actor: Admin
· Precondition: System running
· Postcondition: Metrics displayed
· Function: Displays drift, anomalies, and system logs

Conclusion
The use case diagram of DriftSentinel clearly represents interactions between users and the system in the monitoring
phase. It focuses on prediction, drift detection, anomaly detection, and visualization, providing a clear understanding
of system functionality without involving retraining processes.
 Experiment No.:3

AIM:
Draw the activity diagram.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.
Software Requirements:
[Link], Windows XP.
Theory:
An activity diagram represents the workflow of a system by showing the sequence of activities and
decision points. It helps in understanding how different components of the system interact during
execution.
In DriftSentinel, the activity diagram illustrates the flow from user request → model inference →
monitoring → drift detection → alert generation → dashboard visualization.
Actors:
1. End User (Client)
· Sends input data for prediction
· Receives prediction results
2. Admin
· Monitors alerts
· Views dashboard
3. System (DriftSentinel)
· Performs prediction
· Monitors incoming data
· Detects data drift
· Generates alerts
Activities:
1. Send Prediction Request
· Precondition: System is active and API is available
· Postcondition: Input data received
· Function: User sends data for prediction
2. Generate Prediction
· Precondition: Input data received
· Postcondition: Prediction output generated
· Function: System processes input using ML model
3. Stream Data to Monitoring System
· Precondition: Prediction completed
· Postcondition: Data sent to monitoring pipeline
· Function: Stores input data for analysis
4. Detect Data Drift
· Precondition: Sufficient data collected
· Postcondition: Drift score generated
 · Function: Compares current data with baseline
5. Generate Alert
· Precondition: Drift detected
· Postcondition: Alert generated
· Function: Notifies admin about drift
6. View Dashboard
· Precondition: System running
· Postcondition: Monitoring metrics displayed
· Function: Shows drift and system logs

Output:

Conclusion:
The activity diagram of DriftSentinel represents the workflow of the system from prediction to drift
detection and alert generation. It clearly shows how the system monitors real-time data and ensures
reliability without including advanced features like retraining or anomaly detection.
 Experiment No.:4

AIM:
Identify the classes. Classify them as weak and strong classes and draw the class diagram.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.
Software Requirements:
[Link], Windows XP.
Theory:
A class diagram models the static structure of a system. It shows relationships between classes, objects,
attributes, and operations.

As mentioned above, and as seen in Diagram 1, classes are represented by rectangular symbols, and
different arrows are used to represent the relationship between classes. Note that class diagrams don’t
depict any interactions between classes.

Class

The class name is always shown in the first section, the attributes in the second,
and operations in the third. Attributes are values that define a class. Classes can
carry out processes known as operations.

Note: there can be a fourth section (responsibility), which is an optional section for
including additional information about the class.

Visibility

Visibility symbols are used to determine the accessibility of the information

contained in classes.
As mentioned above, class diagrams can represent relationships between classes. There are
seven relationships that are commonly shown in class diagrams. They are association (the most
common being bidirectional and unilateral association), inheritance, realization/implementation,
dependency, aggregation, composition, and multiplicity.

Bidirectional
Association

A bilateral association is represented by a straight line

connecting two classes. It simply demonstrates that the
classes are aware of their relationship with each other.

Unilateral
Association

A unilateral association is represented by an open arrowhead

connecting one class to another. It shows that one class is
aware of its relationship with another class.

Inheritance

Indicate a “child-parent” relationship between classes. The

child class is a specialized, sub-class of the parent.
Realization/Impleme
ntatio n

One class implements the behavior specified by another class.

Dependency

As the name suggests, one class depends on another. A

dashed arrow shows this.

Aggregation

This represents a unilateral relationship between classes. One

class is part of, or subordinate to, another. In this instance, the
child and parent classes can exist independently.
 Composition

It is a form of aggregation where one class is dependent on

another. One class is a part of the other. In this instance, the
child classes and parent classes cannot exist independently.

Multiplicity

Multiplicity is used to determine how many times an attribute

occurs. In this example, this house has exactly one kitchen
and at least one bedroom.

Output:

Conclusion:
The class diagram of DriftSentinel represents the static structure of the system by identifying key
components and their relationships.
 Experiment No.:5

AIM:
Draw the sequence diagram for any two scenarios.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
[Link] UML, Windows XP
Theory:
UML sequence diagrams model the flow of logic within a system in a visual manner. They help in
documenting and validating system behavior by showing interactions between different components over
time.
Sequence diagrams are widely used for dynamic modeling and are essential for understanding how
different parts of a system communicate during execution.
Output:

Conclusion:
The sequence diagrams for DriftSentinel illustrate the dynamic interaction between system components
during prediction and drift detection processes. They help in understanding the flow of data and control,
ensuring that the system behavior is clearly defined and validated.
 Experiment No.:6

AIM:
Draw the collaboration diagram.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
[Link] UML, Windows XP
Theory:
Collaboration diagrams (also known as communication diagrams) represent the interactions between
objects in a system. They show how objects are connected and how messages are passed between them.
Objects are represented as nodes, and arrows indicate the flow of messages. Sequence numbers (such as 1,
1.1, 1.2, etc.) are used to show the order of interactions between objects.
These diagrams help in understanding system communication and object relationships.
Collaboration Flow (Message Sequence):
Scenario: Prediction → Monitoring → Drift Detection → Alert

Output:

Conclusion:
The collaboration diagram of DriftSentinel illustrates the interaction between system components and the
sequence of message exchanges. It provides a clear understanding of how data flows from the user to the
monitoring system and how drift detection leads to alert generation and visualization on the dashboard.
 Experiment No.:7

AIM:
Draw the component diagram.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
[Link] UML, Windows XP
Theory:
A component is something required to execute a stereotype function. Examples of stereotypes in
components include executables, documents, database tables, files, and library files.
Components are wired together by using an assembly connector to connect the required interface of one
component with the provided interface of another component. This illustrates the service consumer -
service provider relationship between the two components.
An assembly connector is a "connector between two components that defines that one component provides
the services that another component requires. An assembly connector is a connector that is defined from a
required interface or port to a provided interface or port."
When using a component diagram to show the internal structure of a component, the provided and required
interfaces of the encompassing component can delegate to the corresponding interfaces of the contained
components.
A delegation connector is a "connector that links the external contract of a component (as specified by its
ports) to the internal realization of that behavior by the component’s parts." Examples include APIs,
databases, services, and libraries.
Components interact using:
· Provided Interfaces (lollipop) → services offered
· Required Interfaces (socket) → services needed
These interactions define the relationship between system modules and help in understanding system
architecture.
Components Identified in DriftSentinel:
1. API Service (FastAPI)
2. Model Inference Component
3. Monitoring Engine
4. Drift Detection Component
5. Alert Service
6. Dashboard UI
7. Database
Flow of Interaction:
1. API Service → Model Inference
2. Model Inference → Monitoring Engine
3. Monitoring Engine → Drift Detection
4. Drift Detection → Alert Service
 5. Alert Service → Dashboard UI
6. Monitoring Engine → Database
Output:

Conclusion:
The component diagram of DriftSentinel represents the modular architecture of the system by illustrating
how different components interact with each other. It provides a clear understanding of system structure
and the flow of data between modules, ensuring maintainability and scalability.
 Experiment No.:8

AIM:
Draw the state chart diagram.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
[Link] UML, Windows XP
Theory:
UML uses diagrams to represent systems, which are broadly categorized into behavioral and structural
diagrams. A state chart diagram is a behavioral diagram that represents the different states of a system
and transitions between those states based on events.
It helps in understanding how a system behaves over time in response to inputs and conditions.
States Identified in DriftSentinel:
1. Idle State
2. Receiving Request
3. Processing Prediction
4. Monitoring Data
5. Detecting Drift
6. Alert Generated
7. Displaying Dashboard
Output:

Conclusion:
The state chart diagram of DriftSentinel represents the different states of the system and how it transitions
from receiving a request to detecting drift and generating alerts. It clearly illustrates system behavior.
 Experiment No.:9

AIM:
To perform forward engineering in Java (Model to Code Conversion).
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
Java, Windows XP
Theory:
Forward engineering is the process of converting a high-level model such as a UML class diagram into
actual code. In Java, this involves translating classes, attributes, and methods from the design into Java
classes.
This ensures that the implementation follows the system design accurately.
Example:
1. UML Class Diagram (Text Format):

2. Forward Engineering to Java Code:

// [Link]

public class Person {

// Attributes
private String name;
private int age;

// Default Constructor
public Person() {
}

// Parameterized Constructor
public Person(String name, int age) {
[Link] = name;
[Link] = age;
}

// Getter Methods
public String getName() {
return name;
}

public int getAge() {

return age;
}

// Setter Methods
public void setName(String name) {
[Link] = name;
}

public void setAge(int age) {

[Link] = age;
}

// toString Method
@Override
public String toString() {
return "Person{name='" + name + "', age=" + age + "}";
}

// Main Method (Example Usage)

 public static void main(String[] args) {
Person p1 = new Person("Rohan", 21);
[Link](p1);

[Link](22);
[Link]([Link]());
}
}
Conclusion:
The UML class diagram is successfully converted into Java code using forward engineering. The Person
class includes attributes, constructors, getter and setter methods, and a toString method. This demonstrates
how system design can be translated into a working implementation using Java.
 Experiment No.:10

AIM:
To perform reverse engineering in Java (Code to Model Conversion).
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
Java, Windows XP
Theory:
Reverse engineering is the process of analyzing existing code to derive a higher-level model or design
representation. In Java, this typically involves converting source code into UML diagrams such as class
diagrams.
This helps in understanding system structure, relationships, and functionality, especially when
documentation is not available.
Example:
1. Given Java Code
// [Link]

public class Person {

// Attributes
private String name;
private int age;

// Constructors
public Person() {
}

public Person(String name, int age) {

[Link] = name;
[Link] = age;
}

// Getters and Setters

public String getName() {
return name;
}

public void setName(String name) {

[Link] = name;
}
 public int getAge() {
return age;
}

public void setAge(int age) {

[Link] = age;
}

// Other Method
public void celebrateBirthday() {
age++;
[Link]("Happy Birthday, " + name + "! You are now " + age + " years old.");
}

// toString Method
@Override
public String toString() {
return "Person{name='" + name + "', age=" + age + "}";
}
}

2. Reverse Engineered UML Class Diagram (Text Format):

Explanation:
· Attributes → Converted from private variables
· Constructors → Represent object initialization
· Methods → Represent class behavior
· Access modifiers (+ / -) → Show visibility
Conclusion:
Reverse engineering successfully converts Java code into a UML class diagram, providing a clear visual
representation of the system structure. This helps in understandingand maintaining software systems.
 Experiment No.:11

AIM:
Draw the deployment diagram.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor.
Software Requirements:
Java, Windows XP
Theory:
A UML Deployment Diagram represents the physical architecture of a system by showing how software
components are deployed on hardware nodes. It illustrates the relationship between hardware devices and
software artifacts.
Deployment diagrams help in understanding how the system will run in a real-world environment and how
different components interact across machines.
Nodes Identified:
1. Client Device (User System)
· Sends API requests
· Displays dashboard
2. Application Server
· Hosts API Service
· Contains Model Inference component
· Runs Monitoring Engine
3. Processing Unit (Drift Detection Server)
· Executes drift detection logic
4. Database Server
· Stores logs and monitoring data
· Dashboard

Deploymnet diagram symbols:

Output:

Conclusion:
The deployment diagram of DriftSentinel illustrates how system components are distributed across
different hardware nodes. It provides a clear view of system architecture and helps in understanding how
the application operates in a real-world environment.