PCTE Group of

Institutes, Ludhiana

BCA SEM 4

Software Engineering Laboratory

SUB-CODE: UGCA1924

PRACTICAL FILE

Submitted by: Aryan

Roll no: 2223152/2244197
E-mail: [email protected]

Submitted to: Mrs. Kamalpreet Kaur

Table of Content
S.NO CONTENT PAGE
. NO.
1. Identify project scope and objective of given problem:
a. College automation system.
b. Banking Management System
2. Develop software requirements specification for (1 a.) and (1 b.)
problem.
3. Develop UML Use case model for a problem.
4. Develop Class diagrams
5. Develop DFD model (level-0, level-1 DFD and Data dictionary)
of the project
6. Develop sequence diagram
7. Develop DFD model (level-0, level-1 DFD and Data
dictionary) of the project
8. Develop sequence diagram
9. Develop Structured design for the DFD model developed
10. Develop the waterfall model, prototype model and spiral
model of the product
11. Explain with reason which model is best suited for the
product
12. Develop a working protocol of any of two problem
13. Use LOC, FP and Cyclomatic Complexity Metric of
abovementioned problem
14. Find Maintainability Index and Reusability Index of
abovementioned problem
 15. Using any Case Tool find number of statements, depth and
complexity of the prototype

Practical 1
Identify project scope and objective of given problem:

a. College automation system.

b. Banking Management System

a. College Automation System:

Project Scope:

The scope of the College Automation System includes the development and
implementation of a comprehensive software solution tailored for managing various
administrative and academic processes within a college or educational institution.
This system aims to streamline and automate tasks such as student enrollment, class
scheduling, attendance tracking, examination management, grading, and overall
student information management. Additionally, it may involve features for faculty
management, resource allocation, and reporting.

Project Objectives:
 Efficient Student Management: Enable the efficient handling of student
records, including enrollment, personal details, academic performance, and
attendance.

Automated Class Scheduling: Develop a system for automated creation and

management of class schedules, taking into account various factors such as
room availability, faculty schedules, and student preferences.

Examination Management: Implement features for exam scheduling, result

processing, and generation of transcripts or grade reports.

Faculty Management: Provide tools for managing faculty details, class

assignments, and performance evaluations.

Resource Allocation: Optimize the allocation of resources such as classrooms,

laboratories, and equipment to enhance overall operational efficiency.

Reporting and Analytics: Incorporate reporting tools to generate various reports

for administrators, faculty, and students. Analytics features may help in
identifying trends and areas for improvement.

User Authentication and Security: Ensure a secure system with proper user
authentication mechanisms to protect sensitive information.

b. Banking Management System:

Project Scope:

The scope of the Banking Management System involves creating a software

solution to automate and manage various banking operations. This includes core
banking functions such as customer account management, transactions, loans, and
other financial services. The system may also encompass features related to online
banking, mobile banking, and integration with other banking channels.

Project Objectives:

Customer Account Management: Develop a system for creating and

managing customer accounts, including personal details, account balances,
and transaction histories.

Transaction Processing: Implement secure and efficient transaction processing

for various banking activities such as deposits, withdrawals, fund transfers,
and bill payments.

Loan Management: Provide functionalities for handling loan applications,

approvals, disbursements, and repayments.

Online and Mobile Banking: Integrate online and mobile banking features to
allow customers to access their accounts, make transactions, and manage
their finances remotely.

Security and Compliance: Ensure the system complies with security standards
and regulations to protect customer information and financial transactions.

Reporting and Audit Trails: Include reporting tools and audit trails to monitor
and analyze banking activities for compliance, risk management, and
decisionmaking.
 Integration with External Systems: Enable integration with other financial
systems, payment gateways, and external services to enhance the overall
banking experience.

In both cases, the project scope and objectives should be further refined based on
detailed requirements gathered from stakeholders and a thorough analysis of the
specific needs of the college or banking institution.

Practical 2
Develop software requirements specification for a.
College Automation System
b. Banking Management System

a. College Automation System

1. Introduction

1.1 Purpose

The purpose of this document is to outline the requirements for the development of
the College Automation System (CAS), a comprehensive software solution
designed to streamline and automate various administrative and academic processes
within a college or educational institution.

1.2 Scope
CAS will cover student information management, class scheduling, attendance
tracking, examination management, faculty management, resource allocation,
reporting, and analytics.

1.3 Definitions, Acronyms, and Abbreviations

● SRS: Software Requirements Specification

● CAS: College Automation System

2. Overall Description

2.1 Product Perspective

CAS will be a standalone system that interfaces with existing college databases for
student and faculty information. It will be accessible through a web-based interface.

2.2 Product Features

Student Management

Class Scheduling

Attendance Tracking

Examination Management

Faculty Management

Resource Allocation

Reporting and Analytics

 2.3 User Classes and Characteristics

● Administrator: Manages the overall system and data.

● Faculty: Manages class-related activities.

● Student: Accesses personal and academic information.

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

● Intuitive web-based interface for administrators, faculty, and

students.

3.1.2 Hardware Interfaces

● Compatible with standard hardware used in the college.

3.1.3 Software Interfaces

● Integration with existing college databases for seamless data

retrieval.

3.2 Functional Requirements

3.2.1 Student Management

● Add, modify, and delete student records.

● Track enrolment status, academic performance, and

attendance.
3.2.2 Class Scheduling

● Automatically generate and manage class schedules.

● Consider room availability, faculty schedules, and student

preferences.

3.2.3 Attendance Tracking

● Record and track student attendance.

● Generate attendance reports.

3.2.4 Examination Management

● Schedule exams, record results, and generate transcripts.

3.2.5 Faculty Management

● Add, modify, and delete faculty records.

● Assign classes and manage performance evaluations.

3.2.6 Resource Allocation

● Optimize allocation of classrooms, laboratories,

and equipment.

3.2.7 Reporting and Analytics

● Generate various reports for administrators, faculty, and

students.
 ● Provide analytics for identifying trends and areas for
improvement.

4. Non-functional Requirements

4.1 Performance Requirements

● System response time: 2 seconds for standard operations.

4.2 Security Requirements

● User authentication for all roles.

● Data encryption for sensitive information.

4.3 Scalability

● The system should handle a minimum of 1000 concurrent users.

5. Constraints

5.1 Regulatory

● Compliance with data protection and privacy regulations.

5.2 Technology

● Development to be done using XYZ programming language and ABC database.

b. Banking Management System

1. Introduction
 1.1 Purpose

This document outlines the requirements for the development of the Banking
Management System (BMS), a software nsolution aimed at automating and
managing various banking operations.

1.2 Scope

BMS will cover customer account management, transaction processing, loan

management, online and mobile banking, security and compliance, reporting, and
integration with external systems.

1.3 Definitions, Acronyms, and Abbreviations

● SRS: Software Requirements Specification

● BMS: Banking Management System

2. Overall Description

2.1 Product Perspective

BMS will be a standalone system interfacing with banking databases. It should be

accessible through web and mobile interfaces for customers.

2.2 Product Features

Customer Account Management

Transaction Processing

Loan Management
 Online and Mobile Banking

Security and Compliance

Reporting and Audit Trails Integration

with External Systems

2.3 User Classes and Characteristics

● Bank Administrator: Manages overall system and data.

● Bank Staff: Performs various banking operations.

● Customer: Accesses accounts and manages finances.

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

● Intuitive web and mobile interfaces for bank staff and

customers.

3.1.2 Hardware Interfaces

● Compatible with standard banking hardware and security

systems.

3.1.3 Software Interfaces

● Integration with core banking systems and payment gateways.

3.2 Functional Requirements
3.2.1 Customer Account Management

● Add, modify, and delete customer accounts.

● Track account balances and transaction histories.

3.2.2 Transaction Processing

● Process deposits, withdrawals, fund transfers, and bill

payments.

● Ensure real-time updates of account balances.

3.2.3 Loan Management

● Handle loan applications, approvals, disbursements, and

repayments.

3.2.4 Online and Mobile Banking

● Provide secure online and mobile banking services for

customers.

3.2.5 Security and Compliance

● User authentication for all roles.

● Data encryption for sensitive information.

3.2.6 Reporting and Audit Trails

 ● Generate reports for compliance, risk management, and
decision-making.

● Maintain audit trails for all banking activities.

3.2.7 Integration with External Systems

● Seamless integration with other financial systems and external

services.

4. Non-functional Requirements

4.1 Performance Requirements

● System response time: 3 seconds for standard operations.

4.2 Security Requirements

● Compliance with banking industry security standards.

4.3 Scalability

● The system should handle a minimum of 5000 concurrent users.

5. Constraints

5.1 Regulatory

● Compliance with banking regulations and data protection laws.

5.2 Technology

● Development to be done using XYZ programming language and ABC database.

Practical
3
Develop UML Use case model for a problem.

a. College Automation System b. Banking Management

System

College Automation System

Banking Management System
Practical
4
CLASS DIAGRAM FOR

a. College Automation System b. Banking Management

System

College Automation System

Banking Management System

Practical
5
Represent Project Scheduling Of Above Mentioned Projects
1. College Automation System:

Phase 1: Planning and Requirements Gathering

• Define project scope and objectives: This involves identifying the boundaries of the

project and what it aims to achieve.

• Gather requirements from stakeholders: Meet with faculty, staff, and students to

understand their needs and expectations from the automation system.

Phase 2: System Design

• Design database schema: Plan the structure of the database to efficiently store and

retrieve data related to students, courses, grades, etc.

• Design user interface: Create mockups or prototypes of the user interface to ensure it's

intuitive and user-friendly.

• Define system architecture: Decide on the overall architecture of the system, including

technology stack and frameworks to be used.

Phase 3: Development

• Implement backend logic: Write code to handle processes such as student enrollment,

course registration, and grade calculation.

• Develop frontend modules: Build the user interface components based on the design

specifications.
• Integrate database and user interface: Connect the frontend and backend components

to ensure seamless interaction.

Phase 4: Testing

• Conduct unit testing: Test individual components/modules to verify their correctness.

• Perform integration testing: Ensure that different parts of the system work together as

expected.

• Execute system testing: Test the entire system to validate its functionality and

performance.

Phase 5: Deployment

• Deploy the system in a test environment: Install the system on a test server for further

validation and testing.

• Conduct user acceptance testing: Allow stakeholders to interact with the system and

provide feedback.

• Make necessary adjustments: Address any issues or bugs identified during testing

before final deployment.

Phase 6: Maintenance and Support

Practical
• Provide user training: Conduct training sessions for faculty, staff, and students

on how to use the system effectively.

• Fix bugs and issues: Address any reported problems and release patches or

updates as needed.

• Regular maintenance and updates: Perform routine maintenance tasks and

implement enhancements to keep the system up-to-date and secure.

2. Banking Management System:

Phase 1: Planning and Analysis

• Define project scope and objectives: Determine the goals and deliverables of

the banking management system project.

• Conduct market research: analyse the banking industry, identify competitors,

and understand market trends.

• Gather requirements from stakeholders: Consult with bank managers,

employees, and customers to gather their needs and expectations.

Phase 2: System Design

• Design database structure: Create a robust database schema to store banking

transactions, customer information, etc.

• Design user interface: Design a user-friendly interface for bank employees to

perform various tasks efficiently.

• Define security measures: Implement security protocols to safeguard

sensitive data and prevent unauthorized access.

Phase 3: Development

• Develop core banking modules: Build modules for account management,

transaction processing, loan processing, etc.

• Implement security features: Integrate encryption, authentication, and

authorization mechanisms to ensure data security.

• Integrate with external systems: Connect the banking system with payment
gateways, ATM networks, and other external systems.

Phase 4: Testing

• Conduct unit testing: Test individual functions and modules to verify their

correctness.

• Perform integration testing: Test the integration of different components to

ensure they work together smoothly.

• Execute system testing: Test the entire system to validate its functionality,

performance, and security.

Phase 5: Deployment

• Deploy the system in a controlled environment: Install the banking system in

a controlled environment to minimize disruption to bank operations.

• Conduct user acceptance testing: Allow bank employees to test the system

and provide feedback before full deployment.

• Address any issues identified during testing: Fix any bugs or issues

discovered during testing to ensure a smooth deployment process.

Phase 6: Training and Transition

• Provide training to bank staff: Train bank employees on how to use the new

banking system effectively.

• Migrate data from legacy systems: Transfer data from existing systems to the

new banking system without data loss or corruption.

• Ensure smooth transition: Plan and execute the transition from the old

system to the new system with minimal disruption to bank operations.

Phase 7: Maintenance and Support

• Provide ongoing support and maintenance: Offer technical support to bank

employees and address any issues or concerns that arise.

• Regular updates and enhancements: Release updates and enhancements to

the banking system to improve functionality, security, and performance.

• Address security vulnerabilities: Monitor for security threats and

vulnerabilities and take measures to mitigate them to ensure the security of the

banking system and customer data

Practical 6

Use Any Model For Estimating The Effort, Schedule And

Cost Of Software Project
Estimating effort, schedule, and cost for software projects requires specific models

considering project characteristics.

Here are some common models to consider:

1. Function Point Analysis (FPA): Measures project size based on the

functionality delivered. It counts specific user functions and data elements, and

then applies weightings for complexity. FPA tools exist to assist in calculation. 2.

COCOMO Model: Considers project size (lines of code) along with

influencing factors like team experience and project maturity. Different versions

(Basic, Intermediate, and Detailed) are available, requiring varying levels of

project information.

3. Three-Point Estimation: Uses optimistic, pessimistic, and most likely estimates

for tasks to build a statistically robust schedule and cost estimation. It accounts for

uncertainty and potential variations in task duration.

Applying these models to your College Management System:

• FPA: Identify user functions like student registration, course enrollment,
attendance recording, etc. Count functions and data elements, apply complexity
weights, and use an FPA tool to estimate effort in person months.
• COCOMO: Estimate the total lines of code required for the system’s different
modules. Choose a COCOMO version based on available project information
and adjust for team experience and project maturity. The model generates effort,
schedule, and cost estimates.Three-Point Estimation: Break down project tasks
into smaller units (design, development, testing) and estimate their durations for
each scenario (optimistic, pessimistic, most likely). Calculate averages and
standard deviations to build a realistic time and cost estimation for the project.

Remember:

• These models provide approximate estimates, not guarantees.

• Accuracy relies on accurate project information and input values.

• Consider adapting models and incorporating your domain knowledge for better

results.

• Always factor in contingencies for risks and uncertainties.

Additional Points:

• Cost is a function of effort, team rates, infrastructure, and other factors. Utilize

your organization’s cost estimation practices for calculating project costs.

• Scheduling your project involves identifying task dependencies and allocating

resources effectively. Utilize scheduling tools like Gantt charts based on your

chosen estimation model.

Practical 7

Develop The Dfd Model (Level-0, Level-1 Dfd And Data

Dictionary) Of The Weather Forecasting Application With
User Customised Alerts Project
LEVEL 0

At Level 0, we have two main external entities:

• User Interface: This represents the interface through which users interact with
the application.
• Weather Data Provider: This represents the external source of the application
fetches weather data.
• The only process at this level is the Weather Forecasting System, which acts
as the central component of the application. The data flows depict the
interaction between the entities and the system, showing that weather data is
 received from the Weather Data Provider and user inputs are received from
the User Interface.

LEVEL1

• At Level 1, we delve deeper into the processes and data flows within the
Weather Forecasting System:
• User Management: This process handles user registration, authentication, and
account management.
• Alerts Customization: This process allows users to customize their alert
preferences, storing these settings for each user.
• Weather Data Retrieval: This process fetches weather data from the external
Weather Data Provider, parses it, and stores it for further processing.
• Alerts Generation: This process evaluates weather conditions against
userdefined alert settings, generates alerts accordingly, and stores them for
delivery.
 • Alerts Delivery: This process selects appropriate notifications based on user
preferences and sends them to the User Interface for display.

• The data stores hold relevant information such as customized alert settings,
retrieved weather data, and generated alerts. Data flows illustrate the flow of
information between the User Interface, external Weather Data Provider, and
various processes within the system.

LEVEL 2

At Level 2, we further decompose the processes to show more detailed

subprocesses:

• Alerts Customization: This process includes sub-processes for user input

validation, storage of customization settings, and alert configuration.
• Weather Data Retrieval: This process includes sub-processes for making API
requests, parsing data, and storing retrieved weather data.
•

Alerts Generation: This process includes sub-processes for evaluating alert

conditions, processing alert rules, and storing generated alerts.
• Alerts Delivery: This process includes sub-processes for creating
notifications, selecting appropriate notifications for users, and sending
notifications to the User Interface.
Practical 8

Develop Sequence Diagram For Library Management System

Practical 9

Develop Structured Design For The Dfd Model Developed

Level 0 DFD Structured Design External Entities:

• User Interface:

➢ Represents the interface through which users interact with the application.

• Weather Data Provider:

➢ Represents the external source providing weather data to the application.

Processes:

• Weather Forecasting System:

➢ Represents the main process that interacts with external entities to manage

weather data and user interactions.

Data Flows:

• From User Interface to Weather Forecasting System:

➢ Carries user requests and interactions to the system.

• From Weather Data Provider to Weather Forecasting System:

➢ Provides weather data to the system for processing. Level 1 DFD Structured

Design Weather Forecasting System:

1. Processes:
• User Management:

➢ Manages user registration, authentication, and profile management.

• Alerts Customization:

➢ Handles customization of alert settings based on user preferences.

• Weather Data Retrieval:

➢ Fetches weather data from external source (Weather Data Provider API).

• Alerts Generation:

➢ Evaluates weather conditions against user-defined settings to generate alerts.

• Alerts Delivery:

➢ Delivers alerts to users via notifications using Twilio API.

2. Data Stores:

• Customization Settings Storage:

➢ Stores customized alert settings for each user.

• Weather Data Storage:

➢ Stores retrieved weather data for further processing.

• Generated Alerts Storage:

➢ Stores generated alerts based on weather conditions and user settings.

3. Data Flows:

➢ Various data flows between processes to manage user requests, weather data, alert
settings, and alert delivery.

Level 2 DFD Structured Design (Selected Processes): Alerts

Customization:
1. Processes:

• User Input Validation:

➢ Validates user input for alert customization.

• Customization Settings Storage:

➢ Stores user-customized alert settings.

• Alerts Configuration:

➢ Configures alerts based on user settings.

Weather Data Retrieval:

1. Processes:

• API Request:

➢ Sends request to Weather Data Provider API.

• Data Parsing:

➢ Parses received weather data.

• Data Storage:

➢ Stores parsed weather data for further use.

Alerts Generation:

1. Processes:

• Alert Conditions Evaluation:

➢ Evaluates weather conditions against user-defined alert settings.

• Alert Rules Processing:

➢ Processes rules to generate alerts.

• Alerts Storage:

➢ Stores generated alerts for delivery.

Alerts Delivery:

1. Processes:

• Notification Creation:

➢ Creates notifications for generated alerts.

• User Notification Selection:

➢ Selects appropriate notifications for users.

• Notification Sending:

➢ Sends notifications to users via Twilio API.

Practical 10

Develop The Waterfall Model, Prototype Model And Spiral Model

Library Management System
Waterfall Model:
The waterfall model is a sequential software development process where progress flows

steadily downwards through the phases of conception, initiation, analysis, design,

construction, testing, deployment, and maintenance.

Phases:

1. Requirements Gathering: Define the requirements for the Library Management System
by interviewing stakeholders such as librarians, patrons, and administrators. Document
these requirements comprehensively.

2. System Design: Create a detailed system design based on the requirements gathered.
This includes the architecture of the system, database design, user interface design, and
module design.

3. Implementation: Develop the Library Management System according to the design

specifications. This involves coding, unit testing, and integration testing of the
various components.

4. Testing: Conduct thorough testing of the system to ensure it meets the specified
requirements and functions correctly. This includes functional testing, performance
testing, and user acceptance testing.

5. Deployment: Deploy the Library Management System to the production

environment. This may involve installation, configuration, and data migration.
6. Maintenance: Provide ongoing support and maintenance for the system, including bug
fixes, updates, and enhancements as required.

Prototype Model:
The prototype model involves creating a simplified version of the Library Management

System to gather feedback and refine requirements iteratively.

Steps:

1. Identify Basic Requirements: Identify the core functionalities that the Library
Management System must have.

2. Develop Prototype: Develop a basic prototype of the system with limited functionality.
Focus on implementing the most critical features first.

3. Gather Feedback: Demonstrate the prototype to stakeholders such as librarians, patrons,

and administrators to gather feedback on its usability and functionality.

4. Refine Requirements: Based on the feedback received, refine the requirements and
update the prototype accordingly.

5. Iterate: Continue to iterate on the prototype, adding new features and refining
existing ones based on ongoing feedback from stakeholders.

6. Finalize: Once the prototype meets the desired requirements and stakeholders are
satisfied, finalize the design and move into full-scale development.
Spiral Model:
The spiral model combines elements of both waterfall and prototype models, emphasizing
risk analysis and iterative development.

Phases:

1. Planning: Identify objectives, constraints, and alternative solutions. Plan the

development process.

2. Risk Analysis: Evaluate potential risks associated with the project, such as
technical challenges or changing requirements.
3. Prototype Development: Develop a prototype to address the most critical risks and
validate key design decisions.

4. Evaluation: Review the prototype with stakeholders to gather feedback and assess its
effectiveness.

5. Development: Develop the Library Management System incrementally, addressing high-

risk areas first and adding functionality with each iteration.

6. Testing: Test the system thoroughly at each iteration to identify andmitigate any issues.

7. Deployment: Deploy the system to production once it meets the desired requirements and
has been thoroughly tested.

8. Maintenance: Provide ongoing support and maintenance for the system, incorporating
feedback and making updates as needed.
Each of these models has its strengths and weaknesses, and the choice of which to use
depends on factors such as project requirements, timeline, budget, and the level of
stakeholder involvement. For a Library Management System, where requirements may
evolve over time and user feedback is crucial, a combination of the prototype and spiral
models may be particularly suitable.
Practical 11

Explain With Reason Which Model Is Best Suited For Library

Management System
Choosing the most suitable Software Development Life Cycle (SDLC) model for a Library

Management System (LMS) depends on various factors such as project requirements,

timeline, budget, and stakeholder involvement. Here's an analysis of which SDLC model

might be most suitable for an LMS:

1. Waterfall Model:

The waterfall model is a traditional sequential approach to software development. It

involves completing one phase before moving on to the next, making it suitable for projects
with well-defined requirements and a stable scope.

Suitability for LMS:

•
If the requirements for the LMS are well-defined and unlikely to change
significantly throughout the project, the waterfall model could be suitable.

• In cases where there's a clear understanding of what the LMS needs to do

and how it will function, the waterfall model provides a structured approach to
development, ensuring each phase is completed thoroughly before moving on to
the next.

• However, if there's a possibility of evolving requirements or if stakeholders

may require frequent demonstrations and adjustments, the waterfall model may not
be the best choice.

Practical 12

Develop A Working Protocol For Any Of Two Problem

1. Protocol for a Chat Application:
This protocol outlines the communication between the client and
server components of a chat application. It's based on a client-server
architecture using TCP/IP sockets.
Protocol Overview:
Connection Establishment:
• Client initiates a TCP connection with the server.
• Server accepts the connection request.
• Upon successful connection establishment, both client and server exchange
acknowledgment messages. Message Exchange:
• Client sends a message request containing the sender's username and the message
content.
•
• Server receives the message request and broadcasts it to all connected clients.
• Clients receive the broadcasted message and display it to the user. User
Authentication:

Clients send login credentials (username and password) to the server for
authentication.
• Server verifies the credentials against a user database.
• Upon successful authentication, the server sends an acknowledgment message to
the client.
• If authentication fails, the server sends an error message to the client.
User List Update:
• Server maintains a list of connected users.
• When a new client connects or disconnects, the server updates the user list and
broadcasts it to all connected clients.
• Clients receive the updated user list and display it to the user.
• Disconnecting from Server:
• Clients send a disconnect request to the server.
• Server acknowledges the disconnect request and terminates the connection.
• Client closes the connection and exits the application.

2.Protocol for a File Transfer Application:

This protocol defines the communication between a client and server for
transferring files over a network using FTP (File Transfer Protocol).
Protocol Overview:
Connection Establishment:
• Client initiates a TCP connection with the server.
• Server accepts the connection request.
• Upon successful connection establishment, both client and server exchange
acknowledgment messages.
Authentication:
•
• Client sends login credentials (username and password) to the server for
authentication.
• Server verifies the credentials against a user database.
• Upon successful authentication, the server sends an acknowledgment message to
the client.

• If authentication fails, the server sends an error message to the client.

File Transfer:

Client requests a file transfer operation (e.g., upload or download).

• Server validates the request and responds with an acknowledgment message.

For file upload:

• Client sends the file to the server in chunks or as a whole,depending on the

protocol implementation.

• Server receives the file and saves it to the specified location.

• For file download:

• Client sends a request specifying the file to download.

• Server retrieves the requested file and sends it to the client in chunks or as a
whole.

Listing Files:
• Client requests a list of files available on the server.

• Server retrieves the list of files from the specified directory and sends it to the
client.

Disconnecting from Server:

• Clients send a disconnect request to the server.

•
• Server acknowledges the disconnect request and terminates the connection.

• Client closes the connection and exits the application.

These protocols provide a structured approach to communication between client
and server components for different types of software projects. They define the
sequence of messages exchanged, error handling mechanisms, and procedures for
connection establishment and termination, ensuring reliable and efficient
communication between distributed components .
P
Practical 13
Use Loc, Fp, And Cyclomatic Complexity Metric Of The
Above-Mentioned Problem
1. Chat Application:

Functional Programming:

• In a functional programming approach, we can leverage functions as first-class

citizens and immutable data structures.

• We can design the chat application with pure functions that take input and
produce output without side effects.

• For example, we can define functions for message broadcasting, user

authentication, and updating user lists, each operating on immutable data
structures.

Lines of Code (LOC) and Cyclomatic Complexity:

• The chat application may have several components such as client-side code,
serverside code, and auxiliary functions.

• LOC can be measured for each component to assess its size and complexity.

• Cyclomatic complexity can be calculated for critical functions, such as

authentication or message broadcasting, to evaluate their structural complexity
and potential for errors.

• By using functional programming techniques, we can potentially reduce the LOC

and cyclomatic complexity by favoring pure functions and eliminating mutable
state.

2. File Transfer Application:

Functional Programming:
• In the file transfer application, we can apply functional programming
principles to handle file operations, such as reading from or writing to files.

• We can use pure functions to encapsulate file-related operations, ensuring

data integrity and minimizing side effects.

• For example, functions for file upload, download, and file listing can be
designed as pure functions that operate on immutable data structures.

Lines of Code (LOC) and Cyclomatic Complexity:

• Similar to the chat application, we can measure LOC for each component of
the file transfer application.

• The file transfer application may have components for client side and
serverside operations, as well as auxiliary functions for file handling.

• Cyclomatic complexity can be calculated for critical functions involved in

file transfer operations, such as upload and download functionalities.

• By applying functional programming techniques, we can potentially reduce

the LOC and cyclomatic complexity of the file transfer application by promoting
modularity and composability through pure functions and immutable data
structures.
P
Practical 14
Find The Maintainability Index And Reusability Index Of
The Above-Mentioned Problem
To calculate the maintainability index and reusability index for the chat application
and file transfer application, we need to consider various factors such as
modularity, documentation, complexity, and cohesion. Here's a general approach to
assess these indices:

1. Maintainability Index:

The maintainability index measures how easily a software system can be

maintained and modified. It typically considers factors such as complexity, code
duplication, and documentation.

To calculate the maintainability index, we can use the following formula: MI

= 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 *

ln(Lines of Code) Where:

• HalsteadVolume is a measure of the size and complexity of the program.

• CyclomaticComplexity measures the complexity of the control flow.

• LinesofCode represents the total number of lines of code.

We can calculate the values of these parameters for each application and then plug
them into the formula to get the maintainability index.

2. Reusability Index:
The reusability index measures the extent to which components of a software
system can be reused in other projects. Factors such as modularity, encapsulation,
and abstraction contribute to reusability.

To calculate the reusability index, we can assess the following:

• Modularity: Are the components of the application well-separated and
loosely coupled, making them easier to reuse?

• Encapsulation: Are the implementation details of each component hidden,

allowing them to be used independently?

• Abstraction: Are the interfaces and APIs designed to be generic and

adaptable to different contexts?
We can assign scores to each factor and calculate the weighted average to obtain
the reusability index.

Practical 15
Using Any Case Tool Find Number Of Statements, Depth,
And Complexity Of The Prototype
1. SonarQube:
SonarQube is an open-source platform for continuous inspection of code quality. It
supports multiple programming languages and provides a range of metrics to
evaluate software quality.
Steps to use SonarQube:
• Install and configure SonarQube on your system or server.
• Integrate SonarQube with your project's build process or use it as a standalone
tool.
• Run SonarQube analysis on your project's source code.
• SonarQube will generate a detailed report containing various metrics, including
the number of statements, depth, and complexity of the software.
• Analyze the generated report to understand the software's quality and identify
areas for improvement.
P
To use any of these tools, follow these general steps:
1. Install the tool on your system or integrate it into your development
environment.
2. Configure the tool to analyze your project's source code.

3. Run the analysis and review the generated reports to identify software quality

metrics such as lines of code, cyclomatic complexity, nesting depth, etc.

4. Use these metrics to assess the quality of your software and make improvements
as needed.
These tools can provide valuable insights into your software's complexity and
quality, helping you maintain and improve your codebase over time.