ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

LAB MANUAL
CS-606: Skill Development

An e-commerce platform needs an ML-based price prediction system to forecast

product prices based on demand, seasonality, and competitor pricing.

Submitted By: Submitted to:

Jatin Patidar Prof. Bharti Bhattad
0827CS221111 AITR, CSE

B. Tech - Computer Science and Engineering

Department of Computer Science and Engineering
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

LABORATORY MANUAL CONTENTS

This manual is intended for the Third Year students of Computer Science and
Engineering in the subject of Skill Development. This manual typically contains
practical/Lab Sessions related to the subject to enhance understanding.

The time spent on getting the design right before you start programming will
almost always save you time in the end. It's much, much easier to make major
changes on a design, which is after all just squiggly lines on paper, and then it is to
make changes in hundreds or thousands of lines of code.

The design process is typically split into distinct phases: Object Oriented Design
(OOD) and Design Pattern.

Students are advised to thoroughly go through this manual rather than only topics
mentioned in the syllabus as practical aspects are the key to understanding and
conceptual visualization of theoretical aspects covered in the books.

Good Luck for your Enjoyable Laboratory Sessions

 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Instruction for Laboratory Student

- Make entry in the Log Book as soon as you enter the Laboratory.
- All the students should sit according to their roll numbers starting from
their left to right.
- All the students are supposed to enter the terminal number in the log book.
- Do not change the terminal on which you are working.
- All the students are expected to get at least the algorithm of the
program/concept to be implemented.
- Strictly observe the instructions given by the teacher/Lab Instructor

Instruction for Laboratory Teachers

- Submission related to whatever lab work has been completed should be

done during the next lab session. The immediate arrangements for
printouts related to submission on the day of practical assignments.
- Students should be taught for taking the printouts under the observation
of lab teacher.
- The promptness of submission should be encouraged by way of marking
and evaluation patterns that will benefit the sincere students
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Vision of the Institute

To be an academic leader for the development of human potential so as to meet
the global challenges.
Mission of the Institute
- To create an intellectually stimulating learning environment.
- To impart value based, innovative, and research-oriented education.
- To develop positive attitude with communication skills.
- To increase employability and entrepreneurship through collaboration with
industries and professional organizations.
Vision of the CSE Department
To be an excellence hub to develop computer professionals who serve the society
through technical expertise with ethical practices.
Mission of the CSE Department
- To impart technical education with industry associations to enrich
intellectual ability.
- To provide a learning environment for enhancing innovation, research, and
values.
- To develop employability and entrepreneurial aptitude in collaboration
with professional organizations.
- To inculcate professional behavior, positive attitude, and effective
communication skills.
Program Educational Objectives (PEOs)- Engineering Graduates will
- PEO1: Acquire knowledge and skills for a successful career, higher studies,
research, or entrepreneurship.
- PEO2: Work independently and collaboratively on multi-disciplinary
projects to ideate and innovate sustainable solutions.
- PEO3: Imbibe lifelong learning, professional and ethical attitude for
embracing global challenges.
Program Specific Outcomes (PSOs)- Engineering Graduates will be able to
- PSO1: Apply apt tools and languages for emerging computing paradigms
such as AI/ML, Blockchain, Cloud Computing, Data Science, IoT, and RPA.
- PSO2: Adopt modern software engineering practices for project
development to address real-life industrial and societal problems.
- PSO3: Develop sustainable software solutions emphasizing open-source
technologies.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Program Outcomes (POs): Engineering Graduates will be able to

Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex engineering
problems.
Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of mathematics,
natural sciences, and engineering sciences.
Design/development of solutions: Design solutions for complex engineering problems and
design system components or processes that meet the specified needs with appropriate
consideration for the public health and safety, and the cultural, societal, and environmental
considerations.
Conduct investigations of complex problems: Use research-based knowledge and research
methods including design of experiments, analysis and interpretation of data, and synthesis of
the information to provide valid conclusions.
Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern
engineering and IT tools including prediction and modelling to complex engineering activities
with an understanding of the limitations.
The engineer and society: Apply reasoning informed by the contextual knowledge to assess
societal, health, safety, legal and cultural issues and the consequent responsibilities relevant to
the professional engineering practice.
Environment and sustainability: Understand the impact of the professional engineering
solutions and societal and environmental contexts, and demonstrate the knowledge of, and
need for sustainable development.
Ethics: Apply ethical principles and commit to professional ethics and responsibilities and norms
of the engineering practice.
Individual and team work: Function effectively as an individual, and as a member or leader in
diverse teams, and in multidisciplinary settings.
Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend and write
effective reports and design documentation, make effective presentations, and give and receive
clear instructions.
Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member and
leader in a team, to manage projects and in multidisciplinary environments.
Life-long learning: Recognize the need for, and have the preparation and ability to engage in
independent and life-long learning in the broadest context of technological change.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Course Educational Objectives

CEO1 Understand the basics of software development life cycle as a

product.
CEO2 Understand the current requirements of industries for software
standards
CEO3 Implement the software as a product using different design
patterns
CEO4 Apply the software development techniques in real life
applications.
CEO5 Understand the existing software solutions and correlate with the
SDLC, design patterns and software standards

Course Outcomes

Upon completion of this subject / course the student will be able

CEO1 Specify, classify, implement, analyze and develop applications
using various SDLC models like Linear sequential, prototype,
Evolutionary models
CEO2 Understand, classify, analyze and develop applications using
Various software standards.
CEO3 Understand, classify, implement various types of design patterns
(Creational, Behavioural, structural); understand and analyze each
design pattern using java program
CEO4 Understand, classify, implement various types of design patterns
(Presentation layer, Integration layer, business layer ); Analyze the
problem statement make UML diagram and code the program in
java .
CEO5 Able to describe the SDLC, design patterns and software standards
applicable to the existing software systems.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

List of Programs
S.No. Practical
1. Identifying the requirements from problem statements.
2. Estimation of Project Metrics
3. Modeling UML Use Case Diagrams and Capturing Use Case Scenarios
4. E-R Modeling from the Problem Statements
5. Modeling UML Class Diagrams and Sequence Diagrams
6.
Introduction to Design patterns. Describe the organization of catalog
along with the following design patterns.
a. Creational Patterns.
b. Structural Patterns.
c. Behavioral Patterns.

7.
Write a program to implement the following concepts in java.
a. Method overriding.
b. Interface.
c. Abstract class.

8. a. Write a Program to implement Factory pattern.

b. Write a program to implement abstract factory.
9. a. Write a Program to implement Singleton pattern.
b. Write a Program to implement Composite design pattern.
10. Case Study : Banking System
11. Describe the Methods to analyze the complexity of design patterns
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Experiment: 1
Identifying the Requirements from Problem Statements
Introduction
Requirement identification is the first and most important step in software development.
Before starting design, coding, or testing, it is necessary to understand what the client
needs. In our project, we are developing an ML-based price prediction system for an e-
commerce platform to forecast product prices based on demand, seasonality, and
competitor pricing. Clear and verified requirements help in building software that meets
user expectations.
In most cases, business analysts with domain knowledge discuss with clients to gather
requirements and define the necessary features of the system. Properly identified
requirements ensure smooth development and avoid confusion later in the project.
Requirements
Software requirements describe the features and functions of a system. They define what
the system should do and how it should behave. Requirements can be clear or hidden,
known or unknown, expected or unexpected from the client’s perspective.
The requirements for the ML-based price prediction system define the features and
functionalities necessary to accurately forecast product prices based on demand,
seasonality, and competitor pricing. These requirements ensure that the system meets user
expectations and provides accurate predictions for e-commerce businesses.
Characteristics of Requirements
For our ML-based price prediction system, the requirements must have the following
characteristics
Unambiguity: The system should provide clear and well-defined price predictions. For
example, if the system predicts price fluctuations, it should specify whether the price is
increasing or decreasing and by how much, avoiding vague outputs.
Consistency: The system must process data uniformly and avoid conflicting outputs. For
example, if two similar products with the same demand and seasonal trends are analyzed,
their predicted price range should be consistent.
Completeness: The system should cover all essential factors influencing price prediction,
such as historical demand, competitor pricing, seasonal trends, and product categories. It
should not leave out any critical variables that impact pricing decisions.
Categorization of Requirements
User Requirements
User requirements are written in simple terms to ensure e-commerce business owners and
stakeholders understand them clearly. These include:
• The system should allow users to input product details such as name, category, and
base price.
• Users should be able to view predicted prices based on demand and market trends.
• The system should generate reports and insights to help users make pricing
decisions.
System Requirements
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
System requirements are technical specifications meant for developers and testers to
ensure proper implementation. These include:
• The system should use machine learning algorithms to analyze demand, seasonality,
and competitor pricing.
• It should process large datasets efficiently and provide price predictions within a
specified time frame.
• The system must integrate with the e-commerce platform's database to fetch
relevant data for accurate forecasting.
Requirements can be classified into two groups based on what they describe
Functional Requirements (FRs)
Functional requirements define what the system should do. These are the core features and
functionalities necessary for the ML-based price prediction system.
Data Collection and Processing
The system should collect historical product pricing data from the e-commerce platform’s
database. It should fetch demand trends, seasonal variations, and competitor pricing
information from external sources. The system should process and clean raw data to
remove inconsistencies before analysis.
Machine Learning-Based Price Prediction
The system should implement machine learning models (such as regression models or
deep learning algorithms) to predict product prices. It should analyze past trends,
customer demand patterns, and seasonal fluctuations to generate accurate price forecasts.
Users should be able to input a product’s category, base price, and demand level, and the
system should return the predicted price.
User Interaction and Input Management
The system should provide a user-friendly dashboard for e-commerce sellers to input
product details. Users should be able to upload product lists in bulk (e.g., CSV or Excel files)
for price prediction. The system should allow manual adjustments to prediction
parameters based on specific business needs.
Prediction Output and Insights
The system should display predicted prices with confidence levels (e.g., 90% accuracy). It
should generate visual reports and graphs showing pricing trends over different time
periods. Users should receive recommendations on whether to increase, decrease, or
maintain the current price based on competitor trends and demand.
Integration with E-Commerce Platform
The system should be able to connect with the e-commerce platform’s API to automatically
fetch product data. It should provide an option to update product prices on the platform
based on prediction results. The system should support integration with popular e-
commerce platforms such as Amazon, Flipkart, or Shopify.
Non-Functional Requirements (NFRs)
Non-functional requirements define how the system should behave, ensuring performance,
security, scalability, and usability.
Performance Requirements
The system should process and return price predictions within 5 seconds for a single
product. It should handle bulk predictions (e.g., 10,000 products) within 1-2 minutes. The
system should ensure real-time updates when new demand or competitor data is available.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
Scalability Requirements
The system should be able to handle large datasets, supporting thousands of products at a
time. It should dynamically scale based on the number of users accessing the system
simultaneously. Cloud-based infrastructure should be used to ensure high availability and
efficient resource allocation.
Accuracy and Reliability
The prediction model should maintain an accuracy rate of at least 90%, ensuring reliable
forecasts. The system should allow continuous training and updating of ML models to
improve accuracy over time. It should provide error margins for each prediction to help
users make informed decisions.
Security Requirements
The system should encrypt user and pricing data to prevent unauthorized access. It should
implement role-based access control (RBAC) to ensure that only authorized users can
modify price predictions. User authentication should be performed through secure login
mechanisms such as two-factor authentication (2FA).
Usability Requirements
The system should have an intuitive and easy-to-use interface for e-commerce sellers. It
should provide tooltips and explanations to help users understand prediction results. The
system should offer multi-language support for better accessibility in different regions.
Maintainability and Upgradability
The system should support regular updates to improve ML model performance. It should
be built with a modular architecture, allowing easy addition of new features. The system
should maintain logs of past predictions for future reference and analysis.
Preparing Software Requirements Specifications
A Software Requirements Specification (SRS) is a formal document that describes the
software system's functional and non-functional requirements in a structured manner. It
acts as a blueprint for software development and serves as a communication bridge
between clients, developers, and stakeholders.
Clear Understanding – It provides a detailed description of the system to be developed,
ensuring that all stakeholders have a shared understanding of the project.
Prevents Ambiguity – By documenting requirements clearly and unambiguously,
misunderstandings between clients and developers are minimized.
Legal Agreement – The SRS serves as a formal contract between the client and the
development team, preventing disputes regarding project scope.
Efficient Development – It guides developers, testers, and designers in building the
software according to predefined requirements.
Future Maintenance – The document acts as a reference for future updates,
enhancements, and debugging of the system.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
SRS for ML-Based Price Prediction System
1. Introduction
1.1 Purpose
The purpose of this project is to develop an ML-based price prediction system for an e-
commerce platform. The system will forecast product prices based on demand trends,
seasonality, and competitor pricing to help sellers optimize their pricing strategies.
1.2 Scope
• The system will collect and process pricing data from e-commerce platforms and
competitors.
• It will use machine learning models to analyze trends and predict optimal prices.
• The platform will provide a user-friendly dashboard for sellers to input product
details, view predictions, and generate reports.
• The system will integrate with e-commerce APIs to update prices in real-time.
• It will ensure scalability, security, and performance optimization to handle large
datasets and multiple users.
1.3 References
• IEEE Standard for Software Requirements Specification (IEEE 830-1998)
• E-commerce market reports on pricing strategies
2. Overall Description
2.1 Product Perspective
• This system is independent but can integrate with existing e-commerce platforms.
• It will be deployed on cloud-based infrastructure for high availability and scalability.
• The system will use historical sales data, competitor pricing, and seasonal trends to
generate accurate price predictions.
2.2 Product Features
1. Automated Data Collection – Fetches pricing, demand, and competitor data from
multiple sources.
2. Price Prediction Model – Uses ML algorithms to suggest optimal pricing.
3. User Dashboard – Allows manual input, bulk uploads, and graphical reports.
4. Real-time Integration – Connects with e-commerce APIs to update prices
dynamically.
5. Security & Access Control – Ensures data encryption and user authentication.
2.3 User Characteristics
• E-commerce sellers and business owners looking for data-driven pricing strategies.
• Users with basic to advanced technical knowledge of pricing and analytics.
2.4 Constraints
• The system must process predictions within 5 seconds for a single product.
• It must support bulk uploads of up to 10,000 products.
• Data collection must comply with privacy regulations and not violate competitor
policies.
3. Specific Requirements
3.1 Functional Requirements
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
1. Data Processing: Collects and cleans pricing data.
2. Prediction Algorithm: Uses ML to forecast prices.
3. User Input: Allows manual and bulk data entry.
4. Output Reports: Provides graphs, insights, and recommendations.
5. Integration: Syncs with e-commerce platforms via APIs.
3.2 Non-Functional Requirements
1. Performance: Must handle large datasets efficiently.
2. Scalability: Supports increasing user load dynamically.
3. Security: Implements data encryption and user authentication.
4. Availability: The system must be accessible 24/7.

Examples:

A system may be required to suggest the most competitive price for a product
based on historical data and current market trends. This is a functional
requirement. How frequently these predictions should be updated (e.g., in
real-time or at scheduled intervals) is a non-functional requirement, as it
impacts system performance and responsiveness.

Description:
An ML-Based Price Prediction System helps e-commerce platforms forecast product
prices using machine learning algorithms by analyzing historical sales data, demand
trends, seasonal variations, and competitor pricing. This system enables businesses
to set optimal prices dynamically, maximizing profitability while maintaining
competitiveness.

The system continuously monitors and processes data, detecting market fluctuations
and adjusting pricing strategies accordingly. By leveraging advanced predictive models
such as regression analysis, time-series forecasting, and deep learning techniques,
it provides real-time insights and automated price adjustments.
Key Features:
Data Collection & Processing – Aggregates data from various sources, including competitor
websites, sales history, and customer behavior.

Machine Learning Models – Uses supervised and unsupervised learning techniques

to predict price trends and recommend optimal prices.

Dynamic Pricing Strategy – Adapts pricing based on market conditions, customer demand,
and stock availability.

User Dashboard & Analytics – Provides an intuitive interface with reports, graphs, and
real-time price recommendations.

Integration with E-Commerce Platforms – Seamlessly integrates with online marketplaces

and inventory management systems.

Scalability & Performance – Handles large datasets efficiently and ensures quick price
updates.

Security & Compliance – Ensures data privacy and compliance with market regulations.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Experiment 2
Estimation of Project Metrics

Introduction
Project estimation is a crucial step in software development that helps in planning,
managing, and allocating resources efficiently. It involves estimating various software
metrics such as effort, cost, time, and size to ensure the successful execution of a project.
Without accurate estimation, projects may face delays, budget overruns, or resource
shortages.
In this experiment, we will focus on estimating project metrics for our ML-based price
prediction system for an e-commerce platform. The estimation process will help us
determine the effort required, development time, and resource allocation based on
different estimation techniques.
Project Estimation Techniques
Project estimation techniques are used to predict the key parameters that define the scope
and complexity of a project. These techniques provide insights into effort, cost, size, and
time estimation, ensuring better planning and risk management.
Important Parameters for Estimation
Some of the key parameters that should be estimated in a software project include-
Effort Estimation: Measures the amount of work required to complete the project.
Typically measured in Person-Months (PM) or Person-Hours (PH). Helps in determining
the number of developers needed.
Cost Estimation: Helps in budgeting and resource allocation. Includes costs for
development, testing, deployment, maintenance, and infrastructure.
Time Estimation: Predicts the total time required to develop the software. Helps in
defining project milestones and deadlines.
Size Estimation: Determines the amount of code or functionalities required. Measured in
Lines of Code (LOC) or Function Points (FP).
Complexity Estimation: Assesses the difficulty level of implementing the software.
Impacts the effort, cost, and time required.

To estimate these parameters, we use well-known project estimation models such as

COCOMO and Halstead's method.
COCOMO (Constructive Cost Model): The COCOMO model is a widely used
software estimation technique developed by Barry Boehm. It helps in predicting the effort,
cost, and time required for software development based on project size.
COCOMO classifies software projects into three categories based on their complexity, size,
and development environment. These categories are-
Organic Mode: Organic projects are small and simple software systems that involve a small
team with good experience working in a familiar environment. These projects have well-
defined requirements and minimal complexity.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Characteristics:
• Small-sized project (typically up to 50 KLOC).
• Well-understood problem and solution.
• Simple and stable development environment.
• Requires minimal innovation or research.
• The development team has good experience with similar projects.
Examples:
• Payroll management system.
• Basic inventory management system.
• Simple web applications.

Semi-Detached Mode: Semi-detached projects have moderate complexity and involve a

mix of experienced and less experienced developers. These projects may have partially
defined requirements, requiring some level of research and design modifications.
Characteristics:
• Medium-sized project (typically between 50 KLOC to 300 KLOC).
• Moderate complexity with some uncertain requirements.
• Team consists of a mix of experienced and less-experienced developers.
• Some level of research or customization is required.
Examples:
• A database management system with real-time data updates.
• Medium-sized e-commerce platforms.
• Financial or business analytics software.

Embedded Mode: Embedded projects are highly complex and critical systems that involve
strict requirements, real-time processing, and deep hardware/software integration. These
projects require extensive planning, documentation, and testing due to their critical nature.
Characteristics:
• Large-sized projects (above 300 KLOC).
• Complex and highly structured requirements.
• Requires strict documentation, validation, and verification.
• Often involves real-time constraints and deep integration with hardware.
• Typically developed for military, aviation, healthcare, or industrial automation.
Examples:
• Flight control systems.
• Real-time operating systems.
• Autonomous vehicle software.
• Space exploration systems.

Types of COCOMO Models: COCOMO (Constructive Cost Model) has three variations
based on the level of detail and complexity required for estimating software effort, cost, and
time. These are:
1. Basic COCOMO
2. Intermediate COCOMO
3. Detailed COCOMO
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Basic COCOMO Model: The Basic COCOMO model provides an initial estimate of effort and
time based only on the number of lines of code (LOC) in the software. It does not consider
project complexity, developer experience, or tools.
Effort (PM) = a × (KLOC)^b
Time (T) = c × (Effort)^d
Where:
• PM (Person-Months) = Effort required
• T (Time in Months) = Estimated development time
• KLOC (Kilo Lines of Code) = Thousands of lines of source code
• a, b, c, d = Constants based on project type (Organic, Semi-Detached, Embedded)

Project Types & Constants for Basic COCOMO

Project Type a b c d Example Projects
Organic 2.4 1.05 2.5 0.38 Simple inventory system, payroll system
Semi- Medium-size e-commerce website, financial
3.0 1.12 2.5 0.35
Detached applications
Flight control system, real-time OS, robotics
Embedded 3.6 1.20 2.5 0.32
software

Our ML-based price prediction system does not fit well with the Basic COCOMO model
because it does not account for data complexity, AI training, or integration requirements.
Basic COCOMO is too simplistic for estimating our project accurately.

Intermediate COCOMO Model: The Intermediate COCOMO model improves on the Basic
model by considering 15 cost drivers such as software complexity, developer experience,
tool availability, and reliability requirements.
Effort (PM) = a × (KLOC)^b × EAF
Time (T) = c × (Effort)^d
Where EAF (Effort Adjustment Factor) is based on 15 cost drivers, including-
• Product attributes (Complexity, reliability)
• Hardware attributes (Execution time, memory usage)
• Personnel attributes (Experience, team capability)
• Project attributes (Development tools, schedule constraints)
Project Types & Constants for Intermediate COCOMO
Project Type a b c d Example Projects
Organic 3.2 1.05 2.5 0.38 Small e-commerce websites, inventory systems
Semi- Our ML-based price prediction system,
3.0 1.12 2.5 0.35
Detached medium-size applications
Large-scale banking software, real-time AI
Embedded 2.8 1.20 2.5 0.32
models
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Our project requires machine learning models, APIs, and database management, making it
moderately complex. The Intermediate COCOMO model is the best fit because it considers
developer expertise, tool availability, and AI-related complexities.

Detailed COCOMO Model: The Detailed COCOMO model extends the Intermediate model by
dividing the entire project into multiple components (subsystems/modules) and estimating each
part separately. It provides the most precise estimation but requires detailed breakdowns of
modules.
Uses the same Effort (PM) = a × (KLOC)^b × EAF, but applied to each module separately.
Factors in additional elements like design complexity, software reuse, and module
interdependence.
Detailed COCOMO Estimation Approach
Phase Effort Distribution (%) Time Distribution (%)
Planning & Requirements 6% 10%
System Design 16% 19%
Coding & Implementation 60% 38%
Testing & Debugging 18% 33%

Our ML-based project is not large enough to require a Detailed COCOMO model. If we split
the project into separate ML modules, APIs, frontend, and backend, then Detailed COCOMO
could be applied for better accuracy. However, Intermediate COCOMO is more practical for
our needs.

Final Comparison and Best Fit for Our Project

COCOMO Applicability to
Pros Cons Best For
Model Our Project
Inaccurate, Not suitable
Simple and
Basic COCOMO ignores Small projects (ignores AI
quick
complexity complexity, APIs)
More accurate, Medium-
Intermediate Requires cost Best fit for our
considers cost complexity
COCOMO driver values project
drivers projects
Most accurate, Time-
Detailed Large, high- Not required for
estimates per consuming,
COCOMO risk projects our project
module complex

Halstead's Method
Halstead’s Software Metrics method, developed by Maurice Halstead, is used to measure
software complexity, size, and effort based on the number of operators and operands in the
source code. It helps in determining the project’s difficulty and effort required for
development.
Halstead's Metrics Formulae:

Halstead’s model defines several metrics-

 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
Program Vocabulary (n)
n=n1+n2n = n_1 + n_2n=n1+n2
n1n_1n1 = Number of unique operators
n2n_2n2 = Number of unique operands
Program Length (N)
N=N1+N2N = N_1 + N_2N=N1+N2
N1N_1N1 = Total occurrences of operators
N2N_2N2 = Total occurrences of operands
Volume (V) – Measures the size of the implementation.
V=N×log2(n)
Difficulty (D) – Represents how difficult it is to write or understand the program.
D=(n1/2)×(N2/n2)
Effort (E) – Determines the total effort required.
E=D×V
Since our project involves an ML-based system, Halstead’s method can be applied to
estimate the complexity of the ML model’s code, API integrations, and data processing
algorithms. Using this method, we can determine the overall effort required in terms of
coding complexity and testing effort.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Experiment 3
Modeling UML Use Case Diagrams and Capturing Use
Case Scenarios

Introduction
A Use Case Diagram is a key component of Unified Modeling Language (UML) used to
visualize the functional requirements of a system. It helps in identifying how different users
(actors) interact with the system and what functionalities the system should provide.
For our project, which is an ML-based price prediction system for an e-commerce platform,
a Use Case Diagram will-
• Clearly define user interactions with the system.
• Help developers understand system requirements in a structured way.
• Identify relationships between various functionalities and users.
• Ensure all possible scenarios (normal and exceptional cases) are captured.
This diagram is useful for both technical and non-technical stakeholders, as it represents
the system in a simplified and visual format.
Use Case Diagrams
A Use Case Diagram represents the interactions between users (actors) and the system
functionalities (use cases). It shows, Who interacts with the system? (Actors), What
functionalities the system provides? (Use Cases) and How users interact with these
functionalities? (Relationships)
Components of a Use Case Diagram
Actor: An actor represents an external entity (user or system) that interacts with the
software system. Actors can be human users, external systems, or hardware devices that
perform actions in the system.
Classification of Actors: Actors are classified into two types-
Type Description Example in Our Project
Primary Directly interacts with the Admin, Seller, Buyer
Actor system
Secondary Supports or assists in the ML Model, Payment Gateway,
Actor background External API
Use Case: A Use Case represents a specific function or service that the system provides.
Each use case describes a user goal, such as predicting product prices, checking competitor
pricing, or placing an order.
System Boundary (Subject): The system boundary defines the scope of the system,
showing what functionalities are included. For our project, the system boundary represents
the ML-based price prediction system that interacts with buyers, sellers, and other external
entities.
Association (Relationships Between Actors and Use Cases): The association defines
the interaction between actors and use cases.
Common types of associations:
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
Direct Association (Simple Line): Represents direct interaction (e.g., Buyer → Predict
Price).
Include Relationship (<<include>> arrow): A use case includes another use case (e.g.,
“Predict Price” includes “Fetch Competitor Data”).
Extend Relationship (<<extend>> arrow): A use case extends another under certain
conditions (e.g., “Apply Discount” extends “Purchase Product” when a promotional offer is
available).

Use Case Diagram for ML-Based Price Prediction System

Actors (Users in the system)

• Buyer → A user who wants to check product price predictions before purchasing.
• Seller → A user who lists products and monitors competitor prices.
• Admin → A user who manages the system and maintains ML models.
Use Cases (Functionalities of the system)
• Buyer can:
o Predict Product Price
o View Competitor Pricing
o Place Order
• Seller can:
o List Products
o View Competitor Pricing
o Check Demand Trends
• Admin can:
o Manage Users
o Manage ML Model
o Generate Sales Reports
Relationships in the Diagram
• Direct Association (→): Shows who interacts with which function.
• Include Relationship (<<include>>)
o Some use cases depend on others.
o Example: Predict Product Price includes Fetch Competitor Data and Analyze
Demand & Seasonality because price prediction requires this information.
• Extend Relationship (<<extend>>)
o Some features are optional or happen only in certain conditions.
o Example: Apply Discount extends Place Order because not all orders will
have discounts.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Use Case Relationships: In UML Use Case Diagrams, relationships define how different
use cases and actors interact within the system. These relationships help structure the
system in a logical way, ensuring clarity and maintainability.
Types of Use Case Relationships
Association (Simple Connection)
• Definition: Represents a direct interaction between an actor and a use case.
• Usage: Shows who can perform which function in the system.
• Notation: A solid line between an actor and a use case.
• Example in Our Project:
o Buyer → (Predict Product Price) → A buyer can use the price prediction
feature.
o Seller → (View Competitor Pricing) → A seller can check competitor prices.

Include Relationship (<<include>>)

• Definition: When one use case is always required as part of another use case.
• Usage: Helps avoid repetition by reusing common use cases.
• Notation: A dashed arrow with the <<include>> keyword, pointing to the
included use case.
• Example in Our Project:
o (Predict Product Price) → <<include>> → (Fetch Competitor Data)
Explanation: To predict product prices, the system must fetch competitor pricing, so this
action is always included.
o (Predict Product Price) → <<include>> → (Analyze Demand & Seasonality)
Explanation: Demand and seasonal factors are essential for accurate price prediction.

Extend Relationship (<<extend>>)

• Definition: Represents an optional behavior that happens only under certain
conditions.
• Usage: Used for features that are not always required in a use case.
• Notation: A dashed arrow with the <<extend>> keyword, pointing to the
extended use case.
• Example in Our Project:
o (Place Order) → <<extend>> → (Apply Discount)
Explanation: A discount is applied only if a promotional offer is available, making it an
extended feature of placing an order.

Generalization (Inheritance in Use Cases & Actors)

• Definition: Represents a parent-child relationship between actors or use cases.
• Usage: When one use case (or actor) is a specialized version of another.
• Notation: A solid line with a hollow triangle pointing towards the more general
entity.
• Example in Our Project: Admin △— Buyer
Explanation: The Admin can have all the privileges of a Buyer, but not vice versa.
o (Manage Users) △— (Approve Seller Registration)
Explanation: Managing users is a general function, but approving sellers is a specialized
action of it.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Notations of Use Case Relationships

Relationship Symbol Description Example in Our Project
Type
Association Solid Line (—) Direct interaction Buyer → (Predict
between Actor & Product Price)
Use Case
Include Dashed Arrow (→) One use case always (Predict Product Price)
with <<include>> requires another → <<include>> → (Fetch
Competitor Data)
Extend Dashed Arrow (→) One use case (Place Order) →
with <<extend>> optionally extends <<extend>> → (Apply
another Discount)
Generalization Solid Line (△—) One use case or Admin △— Buyer
with Hollow actor inherits
Triangle another
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Experiment 4
E-R Modeling from the Problem Statements

Introduction
A database is an organized collection of data that allows for efficient storage, retrieval, and
management. For any large-scale system, like an E-commerce platform, having a structured
database is crucial to handle information about buyers, sellers, products, pricing, demand,
and competitors.
Before implementing a database, it is important to visualize how different entities (such as
users, products, and transactions) interact with each other. The Entity-Relationship (E-R)
Model helps in designing a structured database by representing entities, attributes, and
relationships in a clear diagram.
By designing an E-R Model, we can: Identify key components of the system. Establish
relationships between different entities. Ensure data consistency and efficient querying.
Entity Relationship (E-R) Model
An entity relationship diagram (ERD) shows the relationships of entity sets stored in a
database. An entity in this context is an object, a component of data.
Entities – Objects or things that exist in the system (e.g., Buyer, Seller, Product).
Attributes – Characteristics of an entity (e.g., Product Name, Price, Demand Level).
Relationships – How entities interact with each other (e.g., Buyer purchases Product).

Below is the E-R diagram for our ML-Based Price Prediction System
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Entities Defined:
• Buyer: Represents users who purchase products.
• Seller: Represents individuals or companies selling products.
• Product: Stores details of products available on the platform.
• Category: Defines product classification (e.g., Electronics, Clothing).
• CompetitorPricing: Stores competitor pricing data.
• ML_Model: Represents the machine learning model used for price prediction.
• Transaction: Records product purchases made by buyers.
Relationships & Associations:
• A Buyer makes a Transaction (Purchases a Product).
• A Product is part of a Transaction.
• A Seller lists a Product.
• A Product belongs to a Category.
• A Product has Competitor Pricing.
• The ML Model predicts the price of a Product.

Entity Set and Relationship Set

Entity Set: An entity set is a collection of similar types of entities. In our project, the main
entity sets are
• Buyer Set = {Buyer1, Buyer2, Buyer3, …}
• Seller Set = {Seller1, Seller2, Seller3, …}
• Product Set = {Product1, Product2, Product3, …}
• Category Set = {Electronics, Clothing, Furniture, …}
Relationship Set: A relationship set is a collection of relationships between entities. Some
important relationships in our project include-
• Purchases = { (Buyer1, Product2), (Buyer3, Product1), … }
• Lists = { (Seller1, Product5), (Seller2, Product3), … }
• Predicts = { (ML Model, Product Price) }

Attributes of Entities: Attributes define the properties of an entity.

Entity Attributes
Buyer Buyer_ID, Name, Email, Location
Seller Seller_ID, Name, Business Name, Rating
Product Product_ID, Name, Price, Category, Demand Level
Competitor Pricing Competitor_ID, Competitor Name, Competitor Price
ML Model Model_ID, Algorithm Used, Accuracy
Category Category_ID, Category Name

Different Types of Keys

In database design, keys are used to uniquely identify records in a table and establish
relationships between tables. Here, we will discuss different types of keys with respect to
our ML-Based Price Prediction System for an E-commerce Platform.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Primary Key: A Primary Key (PK) is a unique identifier for each record in a table. It ensures
that no two records in a table have the same value for this column(s).
1. It must be unique for each row.
2. It cannot be NULL.
3. A table can have only one primary key.
Example
• In the Buyer table, Buyer_ID is the Primary Key because each buyer must have a
unique ID.
• In the Product table, Product_ID is the Primary Key as each product has a unique
identifier.
Buyer_ID (PK) Name Email Location
101 Ramesh [email protected] Indore
102 Sita [email protected] Bhopal

Candidate Key: A Candidate Key is a column or set of columns that can be a Primary Key.
It is a potential unique identifier for a table. Among multiple candidate keys, one is chosen
as the Primary Key, and the others are called Alternate Keys. Example
• In the Buyer table, both Buyer_ID and Email are unique.
o Buyer_ID (Chosen as Primary Key)
o Email (Candidate Key, since it is also unique)

Alternate Key: A Candidate Key that is not selected as the Primary Key is called an
Alternate Key. Example
• In the Product table, both Product_ID and Name (if unique) could be candidate keys.
• If we select Product_ID as the Primary Key, then Name (if unique) becomes an
Alternate Key.

Foreign Key: A Foreign Key (FK) is a column in one table that refers to the Primary Key of
another table. It helps in maintaining relationships between tables. Example
• In the Transaction table, Buyer_ID is a Foreign Key referencing Buyer_ID in the Buyer
table.
• In the Product table, Category_ID is a Foreign Key referencing Category_ID in the
Category table.
Transaction_ID (PK) Buyer_ID (FK) Product_ID (FK) Purchase_Date
201 101 301 2025-03-05

Super Key: A Super Key is a set of one or more attributes that can uniquely identify a row
in a table.
• A Super Key can contain extra attributes that are not needed for uniqueness.
• Every Primary Key is a Super Key, but not every Super Key is a Primary Key.
Example
• In the Buyer table, {Buyer_ID, Email, Name} is a Super Key, but {Buyer_ID} alone is
enough to uniquely identify records.
• {Product_ID, Name, Price} in the Product table is a Super Key, but {Product_ID} alone
can act as a Primary Key.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Composite Key: A Composite Key is formed when two or more columns together uniquely
identify a record, but individually, they may not be unique.Example
• In the Transaction table, Buyer_ID and Product_ID together form a Composite Key,
ensuring that a buyer can purchase the same product multiple times.

Unique Key:A Unique Key is like a Primary Key, but it allows NULL values. It ensures
that no two records have the same value in this column. Example
• In the Seller table, Business_Name should be Unique, as no two sellers should have
the same business name.

Summary Table for Different Types of Keys in Our Project

Key Type Definition Example from Our Project
Primary Uniquely identifies a record. Buyer_ID in the Buyer table.
Key
Candidate Possible choices for Primary Key. Buyer_ID and Email in the Buyer
Key table.
Alternate Candidate Key not chosen as Email in the Buyer table.
Key Primary Key.
Foreign Key Links one table to another. Buyer_ID in the Transaction table
(references Buyer table).
Super Key A set of attributes that uniquely {Buyer_ID, Email, Name} in Buyer
identifies a record. table.
Composite Combination of two or more {Buyer_ID, Product_ID} in the
Key attributes to uniquely identify a Transaction table.
record.
Unique Key Ensures uniqueness but allows Business_Name in the Seller table.
NULL values.

Entity Generalization and Specialization

Entity Generalization: Generalization is the process of combining two or more entities
with similar attributes into a single, higher-level entity. It helps reduce redundancy and
creates a more structured database design.
Example: In our ML-based Price Prediction System, we have Buyers and Sellers. Both have
common attributes such as User_ID, Name, Email, and Phone Number. Instead of
maintaining them as separate entities, we can generalize them under a superclass entity
called "User".

User (Generalized Entity) Buyer (Specialized Entity) Seller (Specialized Entity)

• User_ID (Primary Key) • Buyer_ID (Primary Key) • Seller_ID (Primary Key)
• Name • Address • Business_Name
• Email • Purchase_History • Product_List
• Phone Number

Entity Specialization: Specialization is the reverse of Generalization. It is the process of

 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
breaking down a higher-level entity into two or more specialized entities based on certain
conditions.
Example: In our system, Products can be categorized into Electronics, Clothing, and
Groceries. Instead of storing all products in a single table, we can create specialized entities.

Product (General Entity) Electronics (Specialized Entity)

• Product_ID (PrimaryKey) • Warranty_Period
• Name • Power_Consumption
• Price
• Category

Clothing (Specialized Entity) Groceries (Specialized Entity)

• Fabric_Type • Expiry_Date
• Size • Organic/Non-Organic

Mapping Cardinality: Mapping Cardinality defines the number of relationships that can
exist between two entities. It helps in designing the relationships between tables in the
database. There are four types of mapping cardinality-
One-to-One (1:1) Relationship: Each entity in one table is related to only one entity in
another table. Example- A Seller has only one associated Business Profile.
Seller_ID (PK) Name Business_Profile_ID (FK)

201 Ramesh BP101

202 Sita BP102

Ensures unique mapping between two tables. Used when entities have a direct dependency.
One-to-Many (1:M) Relationship: One entity in the first table is related to multiple
entities in the second table. Example- One Seller can have multiple Products.
Seller_ID (PK) Name Product_ID (PK) Product_Name Seller_ID (FK)

201 Ramesh 301 Laptop 201

202 Sita 302 Mobile 201

303 T-shirt 202

Helps in managing multiple records efficiently. Reduces data duplication.

Many-to-One (M:1) Relationship: Many entities from the first table can be related to one
entity in the second table. Example- Many Buyers can place orders under one specific
Delivery_Agent.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
Buyer_ID (PK) Name Delivery_Agent_ID (FK)

101 Ravi DA001

102 Priya DA001
103 Aman DA002

Useful for managing relationships with a centralized entity. Reduces data redundancy.

Many-to-Many (M:M) Relationship: Many entities in the first table can be related to many
entities in the second table. This relationship requires an intermediate (junction) table to
store the mapping. Example- A Buyer can purchase multiple Products, and a Product can
be bought by multiple Buyers.
Buyer_ID (PK) Name Product_ID (PK) Product_Name
101 Ravi 301 Laptop
102 Priya 302 Mobile

Buyer_ID (FK) Product_ID (FK) Purchase_Date

101 301 2025-03-05

102 302 2025-03-06
101 302 2025-03-07

Manages complex relationships efficiently. Allows flexibility in product purchasing.

Graphical Notations for ER Diagram

Here is a table explaining the Graphical Notation of an ER Diagram with terms, diagrams,
and descriptions:
Term Diagram Description
Entity (Strong Represents a real-world object that has a
◻️ (Rectangle)
Entity) unique identity (e.g., Product, Buyer, Seller).
An entity that cannot exist without a strong
◻️ (Double entity. It depends on another entity for its
Weak Entity
Rectangle) identification (e.g., Order_Item depends on
Order).
Represents a property of an entity (e.g.,
Attribute (Oval)
Product_Name, Price).

Primary Key (Oval with A unique attribute that identifies an entity (e.g.,
Attribute underline) Product_ID, Buyer_ID).
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING
Multivalued An attribute that can have multiple values (e.g.,
(Double Oval)
Attribute Phone_Numbers of a Buyer).
An attribute derived from other attributes (e.g.,
Derived Attribute (Dashed Oval)
Age derived from Date_of_Birth).
Represents a relationship between entities (e.g.,
Relationship (Diamond)
Buys relationship between Buyer and Product).
A relationship where a weak entity depends on
Weak (Double
a strong entity (e.g., Contains relationship
Relationship Diamond)
between Order and Order_Item).
Each entity in the first table is related to only
One-to-One (1:1) (Entity) ◻️ ——
one entity in the second table (e.g., Seller has
Relationship ◻️ (Entity) one Business_Profile).

One-to-Many (Entity) ◻️ —— One entity in the first table is related to

(1:M) ◽◽◽> ◻️ multiple entities in the second table (e.g., Seller
Relationship (Entity) sells many Products).

Many-to-Many Many entities in the first table can be related to

(Entity) ◻️ <—>
(M:M) many entities in the second table (e.g., Buyers
◻️ (Entity)
Relationship purchase multiple Products).

Importance of ER Modeling: Entity-Relationship (ER) modeling is crucial in

database design as it helps visualize the structure of a system and its relationships before
implementing it in a Relational Database Management System (RDBMS).
Key Importance of ER Modeling
Clear Visualization – ER diagrams provide a graphical representation of entities,
attributes, and their relationships, making it easy to understand the database structure.
Efficient Database Design – Helps in identifying redundant data, dependencies, and
constraints, ensuring normalized and optimized database design.
Better Communication – ER models help developers, analysts, and stakeholders
collaborate effectively by offering a shared understanding of the system.
Minimizing Errors – Early detection of data inconsistencies and anomalies prevents costly
modifications in later development stages.
Supports Database Normalization – Helps in defining primary keys, foreign keys, and
constraints, reducing data duplication and ensuring data integrity.
Foundation for RDBMS Implementation – Acts as a blueprint for converting conceptual
design into relational database tables, relationships, and constraints.
Example:- For our ML-based price prediction system, ER modeling helps define entities
like Products, Sellers, Buyers, Orders, and their relationships, ensuring an optimized and
scalable database for storing and retrieving pricing, demand, and competitor data.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Steps to Implement a RDBMS

To implement a Relational Database Management System (RDBMS) from an ER model,
follow these key steps:
Identify Entities and Relationships: Define the main entities (e.g., Product, Buyer, Seller,
Order) and how they relate (e.g., Buys, Sells).
Convert ER Model to Relational Schema: Convert entities into database tables with
attributes as columns. Define primary keys (PK) and foreign keys (FK) to establish
relationships.
Normalize the Database: Apply normalization techniques (1NF, 2NF, 3NF) to remove
redundancy and ensure consistency. Example: Avoid storing the same product price in
multiple places to prevent inconsistency.
Define Constraints and Relationships Apply constraints like NOT NULL, UNIQUE,
CHECK, FOREIGN KEY to maintain data integrity. Example: Ensure that Product_Price is
always greater than zero.
Create Tables in RDBMS: Use SQL commands like:
CREATE TABLE Product (
Product_ID INT PRIMARY KEY,
Product_Name VARCHAR(255),
Category VARCHAR(100),
Price DECIMAL(10,2),
Demand_Level VARCHAR(50)
);
Populate Data and Test: Insert test data into tables to check correctness and performance
of queries. Example:
INSERT INTO Product (Product_ID, Product_Name, Category, Price, Demand_Level)
VALUES (101, 'Smartphone', 'Electronics', 25000.00, 'High');
Implement Queries and Views: Write SQL queries for data retrieval and manipulation
based on project needs. Example: Fetch products with high demand:
SELECT * FROM Product WHERE Demand_Level = 'High';
Develop Stored Procedures and Indexing: Use stored procedures for complex operations
and indexes for faster searches.
Perform Testing and Optimization: Check for performance issues, security
vulnerabilities, and scalability.
Integrate with Application and ML Model: Connect the database with the application and
ML model to fetch real-time data for price prediction.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Experiment 5
Modeling UML Class Diagrams and Sequence Diagrams

Introduction
In software development, Unified Modeling Language (UML) diagrams play a crucial role
in designing and understanding a system before implementation. Among these, Class
Diagrams and Sequence Diagrams help in defining the static structure and dynamic
behaviour of a system.
Class Diagram represents the blueprint of a system by defining classes, attributes, methods,
and relationships among objects. Sequence Diagram illustrates the flow of interactions
between objects over time, showing how they communicate with each other.
For ML-based price prediction system, UML diagrams help in designing the system
structure and behaviour efficiently.
• The Class Diagram defines key entities like Product, Buyer, Seller, Order, and their
attributes, methods, and relationships.
• The Sequence Diagram models the interaction between components during price
prediction, data retrieval, and user transactions.
By creating these diagrams, we visualize system components, ensure correctness, reduce
design errors, and simplify development.
Structural and Behavioural Aspects
In UML modeling, a system is analyzed based on two main aspects-
Structural Aspects (Static View): The structural aspect defines the static components of
a system, including classes, objects, attributes, methods, and relationships. It remains
constant unless modified by developers. Components of Structural Aspects:
Class Diagram – Defines classes, attributes, methods, and relationships.
Object Diagram – Represents real-world instances of classes with their current values.
Component Diagram – Shows system components and their dependencies.
Deployment Diagram – Defines hardware and software deployment of the system.
For our price prediction system, structural aspects include:
Class Diagram: Defines entities like Product, Seller, Buyer, Order, and their relationships.
Component Diagram: Shows how ML model, database, and web application interact.
Deployment Diagram: Defines how our system is hosted (e.g., Cloud, Local Server).
Behavioural Aspects (Dynamic View): The behavioural aspect defines the dynamic
behaviour and interactions of system components. It focuses on how objects interact and
change over time. Components of Behavioural Aspects:
Sequence Diagram – Represents interactions between objects over time.
Activity Diagram – Describes workflow or business processes. State Machine Diagram –
Represents state transitions of an object.
Use Case Diagram – Defines user interactions with the system.
For our ML-based price prediction system, behavioural aspects include:
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Sequence Diagram: Models interactions like "Price Prediction Flow", where data is
fetched from the database, processed by the ML model, and displayed to the user.
Activity Diagram: Describes steps in "Product Price Analysis", where demand, seasonality,
and competitor prices are analyzed.
State Machine Diagram: Represents how a Product transitions between states like
"Listed", "In Demand", "Discounted", and "Out of Stock".

Class Diagram
A Class Diagram is a structural UML diagram that represents the static structure of a
system. It shows the classes, attributes, methods, and relationships between different
components of the system.
In our ML-based price prediction system, the class diagram helps in
• Defining the main entities involved in price prediction.
• Understanding relationships between various components like Product, Seller,
Buyer, Price Predictor, etc.
• Providing a clear blueprint for developers to implement the system efficiently.
Elements in a Class Diagram
A class diagram consists of the following elements:
Classes: A class is a blueprint that defines the properties and behaviors of objects. Each
class contains:
• Attributes (data members)
• Operations/Methods (functions that define behaviour)
Example
Class Name Attributes Operations (Methods)
product_id, name, category, price, calculatePrice(),
Product
demand_level, competitor_price getDetails()
addProduct(),
Seller seller_id, name, rating
updateProduct()
purchaseProduct(),
Buyer buyer_id, name, purchase_history
viewProduct()
predictPrice(),
PricePredictor algorithm_type, training_data
trainModel()
placeOrder(),
Order order_id, buyer_id, product_id, status
cancelOrder()

Attributes (Properties of a Class): Attributes store data values of an object. Example:

The Product class has attributes like product_id, name, category, price.
Operations (Methods of a Class): Operations define functions that can be performed on
an object. Example: PricePredictor class has the method predictPrice() that forecasts the
price of a product.
Relationships Between Classes
Relationships define how classes are connected in the system. There are four main types:
1) Association 2) Aggregation 3) Composition 4) Multiplicity
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Association (Simple Connection Between Two Classes)

Represents a basic relationship between two classes. Example: A Buyer can purchase
multiple Products, but a product can be purchased by many buyers.

Aggregation (Weak Relationship, Whole-Part Relationship)

A weaker form of association where one class is a part of another, but it can exist
independently. Example: A Seller has multiple Products, but products can exist without the
seller.

Composition (Strong Whole-Part Relationship)

A strong relationship, where the child object cannot exist without the parent.Example: An
Order must contain a Product. If an order is deleted, the product inside the order is also
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

deleted from that order record.

Multiplicity (One-to-One, One-to-Many, Many-to-Many Relationships)

Defines how many instances of one class relate to another class. Example
Relationship Multiplicity Example in Our Project
One-to-One
1..1 Each Product has one PricePredictor instance.
(1:1)
One-to-Many
1..* A Seller can add multiple Products.
(1:M)
Many-to-Many A Buyer can purchase many Products, and a Product
*..*
(M:N) can be purchased by many buyers.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Sequence Diagram
A Sequence Diagram is a type of UML behavioral diagram that represents how objects
interact with each other over time. It depicts:
• Objects (instances of classes) involved in the system.
• Messages exchanged between objects in a specific order.
• The sequence of interactions to perform a particular operation.
For our ML-based price prediction system, the Sequence Diagram is useful in:
• Understanding how a user (buyer/seller) interacts with the system.
• Visualizing how the Price Predictor model processes data.
• Analyzing how different components like Product, Order, and Buyer interact.
Elements of a Sequence Diagram
A Sequence Diagram consists of several key elements:
Lifeline (Represents an Object): Definition: A lifeline represents a participant (object or
class) in the interaction. Represented by a vertical dashed line. Example in Our Project:
Buyer, Seller, Product, PricePredictor, and Order have lifelines.

Buyer Product PricePredictor

| | |

|-----------------------------------------------|--------------------------------------------------| (Lifelines)

Messages (Communication Between Objects)

Messages show how objects interact by sending and receiving information. There are
different types of messages in a sequence diagram.
Synchronous Message (Direct Call & Wait for Response)
Sender waits for a response from the receiver before proceeding. Denoted by A solid arrow
with a filled arrowhead. Example- The Buyer requests a Product price, and the system
processes it before responding.

Asynchronous Message (Call Without Waiting for Response)

The sender does not wait for a response before continuing. Denoted by A solid arrow with
an open arrowhead. Example- The PricePredictor system fetches data from Training
Dataset asynchronously.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE
DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

Reply Message (Response to a Call)

Represents the return of data from a method. Denoted by A dashed arrow with an open
arrowhead. Example- The Product returns the calculated price to the Buyer.

Self Message (An Object Calls Its Own Method)

Represents an object calling a method on itself. Denoted by A solid arrow that loops back
to the same lifeline. Example- The PricePredictor calls its trainModel() function on itself.

Destroy Message (Object Deletion)

Represents when an object is deleted or removed from memory. Denoted by A big ‘X’ at the
end of the lifeline. Example- When an Order is canceled, it is removed from the system.

Below is the Sequence Diagram for a Buyer purchasing a Product and using the Price
Prediction system.

• Buyer views available products in the

catalog.
• Product Catalog displays the list of
products.
• Buyer requests predicted price from the
PricePredictor.
• The PricePredictor trains the ML model
and provides the forecasted price.
• The Buyer places an order for the
product.
• The Order System verifies stock
availability.
• The Order is confirmed, and a response
is sent back to the Buyer.