l.

V.V.P. Engineering College – Rajkot

Department of Computer Engineering

Lab Manual
Software Engineering (3150711)
A.Y. – 2023-24 (ODD)
Semester – V
Vision of the Institute
To be an exemplary institute, transforming students into competent
professionals with human values.

Mission of the Institute

●​ To​ provide​ a​ conducive​ academic​ environment​

for strengthening technical capabilities of the students.

●​ To strengthen linkage with industries, alumni and

professional bodies.

●​ To organise various co-curricular and extra-curricular

activities for overall development of the students.

●​ To practice good​ governance and conduct value-based

activities for making students responsible citizens.
Vision of the Department
Transforming students into globally efficient professionals with
moralvalues.

Mission of the Department

●​ To provide a strong foundation of computer engineering

through effective teaching learning process.

●​ To enhance industry linkage & alumni network for better

placement and real-world exposure.

●​ To provide various opportunities & platforms for all round

development of students & encourage them for value-
based practices.
 Department Of Computer Engineering

Program Educational Objectives(PEOs)

Graduates will be able to

●​ Apply computer engineering theories, principles and skills to

meet the challenges of the society.

●​ Communicate​ effectively,​ work​ collaboratively​ and​

manifest professionalism with ethics.

●​ Exhibit life-long learning attitude​ and​ adapt​ to​

rapid technological changes in industry.

●​ Advance their career in industry, pursuehigher education

or become an entrepreneur.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 1:
Identifying the requirements from the problem statement via role play.

What are requirements?

Requirements are:

1.​User Needs:
●​ Essential conditions or functionalities that users require to address a problem
or accomplish a specific goal.
2.​System Criteria:
●​ Conditions or capabilities that a system or its components must possess to
fulfil contractual agreements, standards, specifications, or other formal mandates.

Types of requirements:

Functional requirements:

These are the requirements that the end user specifically demands as basic facilities
that the system should offer. All these functionalities need to be necessarily
incorporated into the system as a part of the contract. These are represented or stated
in the form of input to be given to the system, the operation performed and the output
expected.

Non-functional requirements:

These are basically the quality constraints that the system must satisfy according to the
project contract. The priority or extent to which these factors are implemented varies
from one project to another. They are also called non-behavioral requirements.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Domain: Virtual Skills Swap

Abstracts:

Virtual Skill Swap is a web-based platform that enables users to exchange skills by
connecting with others who want to learn and teach. Instead of traditional paid courses,
users list the skills they can teach and those they wish to learn. The system matches users
based on their preferences, allowing them to schedule sessions and grow together
through peer-to-peer [Link] project promotes accessible, collaborative, and
cost-free learning, built using modern web technologies for a seamless user experience.

Functional requirements:

​ User Registration and Login:

●​Users can sign up and log in using email/password or third-party authentication
(e.g., Google).
●​Password reset functionality.

​ Profile Management:
●​Users can create and update their profiles.
●​Profiles must display skills offered and skills wanted.
●​Option to add availability, bio, and profile picture.

​ Skill Listing and Search:

●​Users can add multiple skills they can teach and learn.
●​Skills are searchable and filterable by category, level, or keyword.

​ Request & Schedule Sessions:

●​Users can send/accept skill swap requests.
●​Calendar or time slot system to propose and confirm session times.

​ Messaging System:
●​Users can chat within the platform to discuss session details.
●​Optional: Video chat integration for live sessions.

​ Notifications:
●​Email or in-app notifications for new matches, messages, and session reminders.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

​ Skill Rating & Feedback:

●​After each session, users can rate each other and leave feedback.
●​Helps improve trust and quality control.

​ Dashboard:
●​Users can view upcoming sessions, pending requests, and profile insights.

​ Admin Panel:
●​Admin can manage users, reported content, and monitor platform activity.
●​Option to manage skill categories and feedback.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Non-functional requirements:

​ Performance
●​The system should respond to user actions (e.g., login, matching, messaging) within 2
seconds.
●​It should support at least 100 concurrent users without noticeable slowdown.

​ Scalability
●​The architecture should allow easy scaling to accommodate more users and sessions in
the future.
●​Use of scalable backend (e.g., [Link] with MongoDB/MySQL) and hosting (e.g., Cloud
services).

​ Usability
●​The platform must have a clean, intuitive, and responsive UI suitable for all devices
(mobile, tablet, desktop).
●​Clear navigation, minimal learning curve, and accessible design.

​ Reliability and Availability

●​The system should have 99.5% uptime.
●​Scheduled maintenance should not affect peak usage hours.

​ Security
●​User data must be securely stored and transmitted (use of HTTPS and password
encryption).
●​Role-based access control (e.g., users vs. admin).
●​Protection against common attacks like SQL injection, XSS, and CSRF.

​ Maintainability
●​Codebase should be modular and well-documented to support future updates or
bug fixes.
●​Follows coding standards and version control practices (e.g., Git).

​ Portability
●​The application should be deployable across different environments (e.g.,
Windows, Linux servers).
●​Should run smoothly on all modern web browsers.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 2:
Prepare SRS document for identify problem statement.

What is SRS?

​ A software requirements specification (SRS) is a description of a software system

to be developed. It lays out functional and non-functional requirements, and may
include a set of use cases that describe user interactions that the software must
provide.

​ Every software has specific goals and serves particular purposes. Each goal and
purpose translate a process or several processes that the software aims to solve or
to automate. To deliver the right software product, we should define well the
software from the beginning.

​ System requirement specification or SRS frameworks software development, it

documents every operation and dictates how software should behave, it can be as
detailed as what a button should do and should be as complete and correct as
possible.

​ The purpose of a specification document is to describe the behavior as well as the

different functionalities of an application or software in a specific environment.

Why SRS?

​ In order to fully understand one’s project, it is very important that they come up
with a SRS listing out their requirements, how are they going to meet it and how
will they complete the project.

​ It helps the team to save upon their time as they are able to comprehend how are
going to go about the project. Doing this also enables the team to find out about the
limitations and risks early on.

The specific goals of the SRS are:

​ Facilitating reviews.
​ Describing the scope of work.
​ Providing a reference to software designers (i.e. navigation aids, document).
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

​ Providing a framework for testing primary and secondary use cases.

​ Including features to customer requirements.
​ Providing a platform for on-going refinement.

Characteristics of SRS:

​ The SRS should be complete and consistence.

​ The modification like logical and hierarchical must be
allowed in SRS.
​ The requirement should be easy to implement.
​ Each requirement should be uniquely identified.
​ The statement in SRS must be unambiguous means it should have only one
meaning.
​ All the requirement must be valid for the specified project.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Virtual Skills Swap

1.​Introduction

1)​Purpose

▪​ This project aims to build a collaborative web platform where

individuals can connect to teach and learn skills from one another. By
enabling users to list the skills they can offer and those they wish to
learn, the system facilitates mutual skill exchange without any
monetary [Link] encourages peer-to-peer learning, promotes
community engagement, and provides an accessible alternative to
traditional education.

2)​Document conventions

▪​ Version History:
o​ Version: 2.0.0
o​ Date: 15th July, 2025
o​ Author: Zaheen Vora and Mahek Zinzuvadiya
o​ Description: Bugs and minor error fixing. Also, low data
consumption.

3)​Intended Audience And Reading Suggestions

▪​ Developers and Technical Team Members: To refer to system

requirements, architecture, and technical components for development
and maintenance.

▪​ Testers: In order to have an exact list of the features and functions that
has to respond according to requirements and provided diagrams.

▪​ End Users: In order to get familiar with the idea of the project and
suggest other features that would make it even more functional.

▪​ This project is a prototype for The Virtual Skills Swap Website. This has
been implemented under the guidance of college professors.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

4)​Project Scope

▪​ This project aims to develop a web-based platform that facilitates

peer-to-peer skill exchange. The system will allow users to register,
create profiles, list skills they can teach, and specify skills they wish to
learn. Based on mutual interests, the platform will enable users to
connect, communicate, and schedule learning sessions.

▪​ The project will cover:

▪​ User authentication and secure profile management

▪​ Skill listing with tags, categories, and search/filter functionality

▪​ Smart matching algorithm to connect users with complementary skill

sets

▪​ In-app messaging for communication between matched users

▪​ Session scheduling and notification system

▪​ Feedback and rating system for quality control

▪​ Admin panel to manage users, content, and reports

5)​References
1.​ [Link]
2.​ [Link]
3.​ [Link]
4.​ [Link]
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

2.​ Overall description

1)​Product Perspective

▪​ Virtual Skill Swap is an independent web application designed for

peer-to-peer skill exchange. Unlike traditional e-learning platforms, it
connects users to mutually teach and learn without payment. It follows
a modular structure with a frontend, backend, and database, and may
integrate tools like Google login or video calling APIs. The platform is
scalable and built for future enhancements.

2)​Product Features
▪​ User registration and login

▪​ Profile creation with skills to teach and learn

▪​ Skill-based user matching

▪​ Skill exchange requests and approvals

▪​ In-app chat system

▪​ Session scheduling

▪​ Ratings and feedback

▪​ User dashboard

▪​ Notifications

▪​ Admin panel

3)​User classes and characteristics

▪​ Learners: Users who want to acquire new [Link] be beginners or

intermediate-level in the skill they want to [Link] browse, request
sessions, and rate teachers.

▪​ Teachers:Users who are willing to share their [Link]

beprofessionals, hobbyists, or skilled [Link] list teachable
skills, accept requests, and conduct sessions.

▪​ Swappers (Learner + Teacher): Users who want to both teach and

[Link] common user type on the [Link] in mutual skill
exchange with others.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

▪​ Administrator: Manages platform users, feedback, and

[Link] reported users and ensures community guidelines are
[Link] system stability and updates.

4)​Operating environment
▪​ Operating System: Windows, Mac OS, Linux, Ubuntu

▪​ Processor: Intel Core i5 or equivalent

▪​ Processor Speed: 2.5 GHz or higher

▪​ RAM: 2 GB or above

▪​ Disk Space: Minimum 1 GB free space

▪​ Browser Support: Latest versions of Chrome, Firefox, Edge, Safari

▪​ Internet Connection: Required for full functionality (real-time matching,

messaging, etc.)
​
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

5)​Design and implementation constraints

▪​ The system will be a web-based application, accessible via modern web

browsers on any operating system (Windows, Linux, Mac OS, Ubuntu).

▪​ The application will use MySQL as the database management system

for storing user data, skills, messages, and session details.

▪​ Front-end:
o​ HTML
o​ CSS
o​ JavaScript

▪​ Back-end
o​ JAVA or PHP
o​ MySQL

6)​Assumption and Dependencies

▪​ The code of product should be free with compilation errors.

▪​ The product with simple interface which is understood simply by users.

3.​System features

1)​functional requirements

▪​ Skill Selection:
Users can select or enter the skills they want to learn and the skills they are
willing to teach.

▪​ User Matching:
The system automatically matches users based on mutual skill interests and
availability.

▪​ Profile Management:
Users can create and update their profiles, including personal info, skills,
availability, and a short bio.

▪​ Session Scheduling:
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Users can set their available time slots and schedule one-on-one learning
sessions with matched users.

▪​ In-app Messaging:
Matched users can chat securely within the platform to plan and coordinate
learning sessions.

▪​ Skill Swap Request:

Users can send or accept skill swap requests to begin the exchange.

▪​ Ratings and Feedback:

After each session, users can rate their partners and leave feedback to
maintain quality and trust.

▪​ Notifications:
Users receive alerts for new matches, messages, session reminders, and
request statuses.

▪​ Admin Panel:
Admin can manage user accounts, reported issues, and system content (like
skill categories).
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

4.​External Interface requirements

1)​User Interfaces

▪​ We build a product on web with using HTML, CSS, JavaScript.

▪​ To handle backend of this product, will use java and PHP.

▪​ With combination of front and back-end this product will easily usable
and perform task related to service provider.

2)​Hardware Interfaces

▪​ System with abilities to handle browsing efficiently

▪​ GPS

▪​ 2GB Ram

▪​ Low memory

▪​ Internet

3)​Software Interfaces

▪​ Operating System: Windows, Linux, Mac OS

▪​ Front End: HTML, Bootstrap, CSS , JavaScript

▪​ Back End: MySQL, java, PHP

4)​Communication Interfaces
▪​ All communication is carried out through online mode via the web
platform.
▪​ Users can send and receive messages through the in-app chat system after a
successful skill match.
▪​ System notifications are used to confirm:

▪​ Skill swap requests

▪​ Session scheduling
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

▪​ Session reminders

▪​ Feedback received

▪​ Optional integration of email notifications for booking confirmations and

updates.

5.​Non-functional Requirements

1)​Performance Requirements
▪​ The system will manage skill swap bookings based on user-defined
conditions (skills, availability, location, etc.).
▪​ It will efficiently perform searching and matching operations using filters
like skill type, user rating, and time slots.
▪​ The platform will be entirely online, accessible through modern web
browsers.
▪​ Response time for key actions (e.g., search, request, messaging) should be
within 2–3 seconds under normal load.

2)​Safety Requirements
▪​ Users will have access to a "Forgot Password" feature to recover their
account securely.

▪​ Inactive login sessions will automatically expire after 5–10 days for
security, requiring the user to log in again.

▪​ All sensitive data (passwords, session tokens) will be encrypted and

securely stored.

▪​ Unauthorized access to admin or user features will be restricted using

role-based access control.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

3)​Security Requirements
▪​ The system uses authentication mechanisms to ensure that only
registered users can log in and access the platform.
▪​ Unauthorized access is prevented through login validation, session
management, and role-based access controls.
▪​ Sensitive user data, including passwords, will be encrypted and securely
stored
▪​ Session expiration and logout mechanisms are implemented to enhance
security.
▪​ Admin access is restricted and protected through elevated permissions.

4)​Software Quality Attributes

1)​ Functionality: The software reliably performs all intended functions
such as skill matching, messaging, session booking, and user
management.

2)​ Reliability:The platform operates consistently and accurately under

normal conditions, even with multiple users and varying data inputs.

3)​ Usability: Designed with a user-friendly interface, allowing users to

navigate the platform easily, with minimal learning curve.

4)​ Efficiency: Optimized for fast responses and minimal resource

consumption, even while handling searches, matches, and multiple
sessions.

​ ​ 5) Maintainability:Built with a modular structure to allow easy ​

​ ​ ​ updates, feature additions, and bug fixes without disrupting existing
​ ​ ​ functionality.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 3:
Estimation of project matrixes for problem statement.

Project Estimation Techniques:

A software endeavour encompasses more than crafting a mere few hundred lines of
code to fulfil a specific goal. The scale of a software project is notably extensive,
potentially spanning multiple years for fruition. Nevertheless, the term "extensive"
might only provide a somewhat imprecise qualitative insight. Similar to other fields of
science and engineering, there exists a curiosity to quantify the intricacy of a project.
Thus, a pivotal task during the project's planning stage involves predicting diverse
project metrics to facilitate well-informed decisions.

Some important project parameters:

​ Project Size: This refers to the scale of the codebase, indicated by factors such as
the number of lines of code, the count of files, and the organization into modules.
​ Cost: This entails the financial resources required for software development,
including expenses for managers, developers, and other project-related personnel,
despite software essentially being code components.
​ Duration: The time span needed for the completion and delivery of the software
product to the clients.
​ Effort: This quantifies the collective work and input from team members
necessary for the creation and development of the software.

COCOMO:

​ Boehm developed COCOMO, a method for estimating software project

costs.
​ He classified projects into three types: organic (small and familiar),
semi-detached (moderate), and embedded (complex and large).
​ This classification hinges on the software's complexity, the team's
experience, and the project's setting.

1)​ Organic: A development project is said to be of organic type, if

​ The project deals with developing a well understood application
​ The development team is small
​ The team members have prior experience in working with similar types
of projects.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

2)​ Semidetached: A development project can be categorized as semidetached type, if

​ The team consists of some experienced as well as inexperienced staff
​ Team members may have some experience on the type of system to
be developed.

3)​ Embedded: A development project can be categorized as embedded type, if

​ Aims to develop a software strongly related to machine hardware
​ Team size is usually large.

Basic COCOMO Model:

​ The basic COCOMO model helps to obtain a rough estimate of the

project parameters. E = a*(KLOC)b

Software Project a b

Organic 2.4 1.05

Semi Detached 3.0 1.12

Embedded 3.6 1.20

​ The effort is measured in Person-Months and as evident from the formula

is dependent on Kilo-Lines of code.
​ These formulas are used as such in the Basic Model calculations, as not
much consideration of different factors such as reliability, expertise is taken
into account, henceforth the estimate is rough.

Intermediate Model:

​ The intermediate COCOMO take those other factors into consideration by

defining a set of 15cost drivers (multipliers).Classification of Cost Drivers and
their attributes:

1)​Product attributes –
●​ Required software reliability extent
●​ Size of the application database
●​ The complexity of the product

2)​Project attributes –
●​ Use of software tools
●​ Application of software engineering methods
●​ Required development schedule.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

3)​Hardware attributes –
●​ Memory constraints
●​ Run-time performance constraints
●​ The volatility of the virtual machine environment
●​ Required turnabout time

4)​Personnel attributes –
●​ Analyst capability
●​ Software engineering capability
●​ Applications experience
●​ Virtual machine experience
●​ Programming language experience

​ The project manager rates 15 parameters on a scale of one to three for a

project. These ratings determine cost driver values from a table. These values
are multiplied to calculate the Effort Adjustment Factor (EAF).
​ The project's effort is then estimated using the formula: E = (a * (KLOC)^b) * EAF.

Software
Project a b

Organic 3.2 1.05

Semi detached 3.0 1.12

Embedded 2.8 1.20

Table 1.1: values for COCOMO models

Embedded Model:
.
​ Detailed COCOMO incorporates all characteristics of the intermediate
version with an assessment of the cost driver’s impact on each step of the
software engineering process.
​ The detailed model uses different effort multipliers for each cost driver attribute.
​ The Six phases of detailed COCOMO are:
1.​ Planning and requirements
2.​ System design
3.​ Detailed design
4.​ Module code and test
5.​ Integration and test
6.​ Cost Constructive model.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Case Study :
Virtual Skills Swap
1.​ Project Description :
●​ The project involves developing a platform where users can exchange
skills by teaching and learning from one another. Users can list the skills
they are willing to teach (e.g., guitar, graphic design, coding) and the
skills they want to learn. The system matches users based on these
preferences.
●​ Users can browse available skill partners, check their expertise and
availability, and schedule learning sessions online. The platform
promotes free, peer-to-peer learning and aims to make education more
accessible and collaborative.z

2.​ Categorization as "Semi-Detached" :

●​ The project is categorized as "Semi-Detached" due to its moderately
familiar application area.
●​ It involves a moderate-sized development team.
●​ The team consists of a mix of experienced and inexperienced members.

3.​ Project Size Estimate :

●​ The estimated size of the project is 6,000 Lines of Code (KLOC).

4.​ Effort Adjustment Factors (EAF) :

●​ EAF is determined based on project-specific attributes.
●​ For "Semi-Detached" projects, assume EAF = 1.15.

5.​ Effort Calculation :

●​ Effort = a * (KLOC)^b * EAF PM
●​ For "Semi-Detached" category, where a = 3.0, b = 1.12

●​ Effort = 3.2 * (6)^1.12 * 1.15 PM

≈ 20.389 PM (person-months)

6.​ Development Time Calculation :

●​ Time of development (Tdev) = 2.5 * (Effort)^d Months
●​ For "Semi-Detached" category, assume d = 0.35.

●​ Tdev = 2.5 * (20.389)^0.35 Months

≈ 7.475 Months
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

7.​ Summary :
●​ Effort: Approximately 20.389 person-months.
●​ Development Time: Approximately 7.475 month

8.​ Implications and Considerations:

●​ The Semi-Detached COCOMO model accounts for team dynamics and
flexibility in development.
●​ The project involves creating a user-friendly interface for browsing and
booking service providers.
●​ Integration with service providers' schedules and availability is a
crucial aspect.
●​ Data security and user privacy must be maintained, adding complexity to
the project.
●​ Ongoing maintenance and updates might extend the project timeline.

9.​ Project Variability :

●​ Keep in mind that these estimations are based on assumptions and
historical data.
●​ The actual development effort and time could vary due to
unforeseen challenges, changes in requirements, and team
dynamics.
●​ Regular project tracking and adjustments might be necessary.

So, the project can be categorized as semi-detached cocomo model and is supposed to
be completed by 8 months.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 4:
Modelling UML Use Case Diagrams and Capturing Use Case Scenarios.

Use case diagram:

A use case diagram is a visual representation of how a system interacts with its users
(actors) and the various functions or features (use cases) it provides. Use case
diagrams are commonly used in software engineering and systems analysis to depict
the high-level functionality of a system.

Some important parameters:

1.​ Actors:
▪​ Actors represent external entities that interact with the system. They can
be people, other systems, or even hardware devices.
▪​ Actors are depicted as stick figures or labelled rectangles at the
periphery of the diagram.
2.​ Use Cases:
▪​ Use cases represent specific functions or features that the system provides
to its actors.
▪​ Use cases are depicted as ovals within the diagram and are connected to
actors by lines.

3.​ Relationships:
▪​ Lines connecting actors and use cases represent relationships or
interactions.
▪​ There are mainly two types of relationships: association and
include/extend relationships.
▪​ Association: A solid line connecting an actor and a use case indicates that
the actor interacts with that use case.
▪​ Include Relationship: A dashed line with an arrow pointing to an included
use case indicates that the behaviour of one-use case is included in another
use case.
▪​ Extend Relationship: A dashed line with an arrow pointing to an extending
use case indicates that the behaviour of one-use case can be extended by
another use case under certain conditions.

4.​ System Boundary:

▪​ The use case diagram often includes a system boundary, which is a box that
encapsulates all the use cases and actors.
▪​ It visually defines the scope of the system under consideration.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

5.​ Generalization/Inheritance
▪​ Actors or use cases can be organized into a hierarchy using generalization
relationships.
▪​ This is represented by a solid line with an arrowhead pointing to the more
general actor or use case.

6.​ Multiplicity:
▪​ Multiplicity notations can be added to relationships to indicate how
many instances of an actor can be associated with a use case and vice
versa.
▪​ For example, "1..*" means one or more instances, while "1" means exactly
one instance.

7.​ System Functionality:

▪​ Use case diagrams provide a high-level overview of the system's
functionality without diving into the implementation details.
▪​ They help stakeholders understand what the system does from a user's
perspective.

8.​ Requirements Analysis:

▪​ Use case diagrams serve as a foundation for gathering and analysing
requirements for the system.
▪​ They help in identifying the main functions and interactions needed in
the system.

9.​ Communication Tool:

▪​ Use​ case​ diagrams​ are​ a​ valuable​ communication​ tool​
between stakeholders, including developers, designers, and project
managers.
▪​ They facilitate discussions about system functionality and help in reaching
a shared understanding.

10.​Evolution and Documentation:

▪​ Use case diagrams can evolve throughout the development process as
requirements change or become more detailed.
▪​ They also serve as documentation for the system's high-level functionality,
aiding in maintenance and future development.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Use Case Notations:

​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Virtual Skills Swap:

Use case diagram

Notations :
1.​ Actors:
1)​ Learner: Individuals looking to learn new skills.
2)​ Teacher: Individuals that teaches skills in return of other skills .
3)​ Admin: Manages the users and the website.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

2.​ Use Cases:

1)​ Registration:
✔​ Actor: Learner,Teacher
✔​ Description: Users create accounts by providing personal information,
including name, email, and password. This step ensures user access to the
platform.

2)​ Login:
✔​ Actor: Learner,Teacher
✔​ Description: Registered users enter their credentials (username/email and
password) to access the platform's features and their personalized
accounts.

3)​ Forgot Password:

✔​ Actor: Learner,Teacher
✔​ Description: Users who forget their passwords can request a password
reset. The system sends a password reset link or code to the user's
registered email for account recovery.

4)​ Verification:
✔​ Actor: Learner,Teacher
✔​ Description: After registration, users receive a verification email. Clicking
the link confirms their email addresses. Additionally, email is used for
important notifications.

5)​ Create Profile:

✔​ Actor: Learner,Teacher
✔​ Description: Users can create their profile by providing their skills,
name,email,and password.

6)​ Search for matches:

✔​ Actor: Learner,Teacher
✔​ Description: Users search for the skills they want to learn or want to teach
and then they find the matches.

7)​ Send match request:

✔​ Actor: Learner
✔​ Description: The learner sends the match request to the teacher who
knows the skill which the learner wants to learn.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

8)​ Accept match request:

✔​ Actor: Teacher
✔​ Description: The teacher can accept th match request sent by the learner if
they want to teach the skill.

9)​ Chat:
✔​ Actor: Learner,Teacher
✔​ Description: The users can chat with each other when they want to
schedule the session of learning and can solve doubts.

10) Feedback :
✔​ Actor: Learner,Teacher,Admin
✔​ Description: The users can give the feedback about how was the
experience of learning and teaching skills and the admin can work on the
changes by seeing the feedback.

11) Edit Profile:

✔​ Actor: Learner,Teacher
✔​ Description: Users can update their profile information, including personal
details, contact information, and preferences. This ensures their profiles
remain current and accurate.

12) Manage users:

✔​ Actor: Admin
✔​ Description: The admin manage all the users as well as the whole website.

13) Browsing skills:

✔​ Actor: Learner,Teacher

✔​ Description: User can search the skills they want to learn by browsing the
skills.

14) Logout:
✔​ Actor: Learner,Teacher

✔​ Description:The user can logout of their profiles by this activity.

​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 5:
E-R Modelling from the Problem Statements.

ER (Entity Relationship) diagram:

​ ER model stands for an Entity-Relationship model. It is a high-level data model.

This model is used to define the data elements and relationship for a specified
system.
​ It develops a conceptual design for the database. It also develops a very simple and
easy to design view of data.
​ In ER modelling, the database structure is portrayed as a diagram called an
entity- relationship diagram.

Components of ER diagram:

ER diagram Notations:
1.​ Entity:
▪​ Entities are objects or concepts that represent important data. They are
typically nouns, e.g. customer, supervisor, location, or promotion.
▪​ Strong entities exist independently from other entity types. They always
possess one or more attributes that uniquely distinguish each occurrence of
the entity.
▪​ Weak entities depend on some other entity type. They don't possess unique
attributes (also known as a primary key) and have no meaning in the
diagram without depending on another entity.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

2.​ Relationship:
▪​ Relationships are meaningful associations between or among entities. They
are usually verbs, e.g. assign, associate, or track.
▪​ Weak relationships, or identifying relationships, are connections that exist
between a weak entity type and its owner.

3.​ Attributes:
▪​ Attributes are characteristics of an entity, a many-to-many relationship, or
a one-to- one relationship.
▪​ Multivalued attributes are those that are capable of taking on more than
one value.
▪​ Derived attributes are attributes whose value can be calculated from
related attribute values.

4.​ Association:

▪​ Relationships illustrate an association between two tables. In the physical

data model, relationships are represented by stylized lines.
▪​ Cardinality and ordinarily, respectively, refer to the maximum number of
times an instance in one entity can be associated with instances in the
related entity, and the minimum number of times an instance in one entity
can be associated with an instance in the related entity.
▪​ Cardinality and ordinarily are represented by the styling of a line and its
endpoint, as denoted by the chosen notation style.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Virtual Skills Swap:

ER diagram

Entities:

1.​ User:
✔​ Attributes: user_id (primary key),Name,Email,profile_id
2.​ Admin:
✔​ Attributes: admin_id(primary key),user_id(foreign key)
3.​ Profile:
✔​ Attributes:profile_id(primary key),Bio,Skills,Profile Pic
4.​ Message:
✔​ Attributes: message_id(primary key),sender_id(foreign key),receiver_id(foreign
key),Content
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

5.​ Skills:
✔​ Attributes: skill_id(primary key),Skill Name,Description
6.​ Request:
✔​ Attributes: request_id(primary key),sender_rid(foreign
key),receiver_rid(foreign key),skill_id(foreign key),Status
7.​ Feedback:
✔​ Attributes: feedback_id(primary key),from_user_id,to_user_id,Rating,Comment
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Relationships:

1.​ User - Profile (One-to-One):

✔​ Each user has one profile, connected by profile_id (User holds a FK to Profile).

2.​ User - Admin (One-to-One):

✔​ An admin is a user with additional privileges. The Admin entity has a user_id
foreign key pointing to the User entity.

3.​ User - Message (One-to-Many):

✔​ A user can send multiple messages—sender_id is FK to User.
✔​ A user can receive multiple messages—receiver_id is FK to User.

4.​ User - Request (One-to-Many):

✔​ A user (sender) can initiate many requests—sender_id is FK to User.
✔​ A user (receiver) can accept many requests—receiver_id is FK to User.

5.​ Request - Skills(Many-to-One):

✔​ Each Request references a Skill via skill_id (Request holds FK to Skill).

6.​ Profile - Skills(Many-to-Many):

✔​ Each Profile can have multiple Skills (as described by the Skills field).
✔​ Each Skill can belong to multiple Profiles.
✔​ This usually requires a separate junction/entity table (e.g., ProfileSkills) with
combinations of profile_id and skill_id.

7.​ Feedback - User (Many-to-One):

✔​ from_user_id is a FK to User (feedback given by user)
✔​ to_user_id is a FK to User (feedback received by user)
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 6:
Identifying Domain Classes from the Problem Statements.

Class diagram:

​ In software engineering, a class diagram in the Unified Modelling Language (UML)

is a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, operations (or methods), and the
relationships among objects.

Purpose of Class diagram:

1.​ Shows static structure of classifiers in a system

2.​ Diagram provides a basic notation for other structure diagrams prescribed by UML
3.​ Helpful for developers and other team members too
4.​ Business Analysts can use class diagrams to model systems from a business
perspective.

Class Notation:
A class notation consists of three parts:

1.​Class Name:
​ The name of the class appears in the first partition.

2.​Class Attributes:
​ Attributes are shown in the second partition.
​ The attribute type is shown after the colon.
​ Attributes map onto member variables (data members) in code.

3.​Class Operations (Methods):

​ Operations are shown in the third partition. They are services the class
provides.
​ The return type of a method is shown after the colon at the end of the method
signature.
​ The return type of method parameters is shown after the colon following the
parameter name.
​ Operations map onto class methods in code.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Virtual Skills Swap:

Classes:
1.​ User
✔​ Attributes: user_id(PK) : int, Name : String, Email : String, profile_id(FK) :int
✔​ Methods:
●​ register()
●​ login()
●​ updateProfile()

2.​ Admin
✔​ Attributes:admin_id(PK) : int, user_id (FK) : int
✔​ Methods:
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

●​ approveUser()
●​ removeUser()
●​ viewAllUsers()
●​ manageFeedback()

3.​ Profile
✔​ Attributes: profile_id(PK) : int, Bio : String, Skills : String, Profile Pic : String
✔​ Methods:
●​ updateBio()
●​ updateSkills()
●​ updateProfilePic()
●​ viewProfile()

4.​ Message
✔​ Attributes: message_id(PK) : int, sender_id : int, receiver_id : int, Content : String
✔​ Methods:
●​ sendMessage()
●​ getMessageByUser()
●​ deleteMessage()

5.​ Skills
✔​ Attributes: skill_id(PK) : int, Skill Name : String, Description : String
✔​ Methods:
●​ addSkill()
●​ updateSkill()
●​ deleteSkill()
●​ getAllSkills()

6.​ Feedback
✔​ Attributes: feedback_id(PK) : int,from_user_id : int, to_user_id : int, Rating : int,
Comment : String
✔​ Methods:
●​ addFeedback()
●​ updateFeedback()
●​ deleteFeedback()
●​ viewFeedbackForUser()

7.​ Request
✔​ Attributes: request_id(PK) : int, sender_rid : int, receiver_rid : int, Status :
String, skill_id (FK) : int
✔​ Methods:
●​ createRequest()
●​ updateStatus()
●​ getRequestsByUser()
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Relationships:

1.​ User - Profile (One-to-One):

✔​ Each user has one profile, connected by profile_id (User holds a FK to Profile).

2.​ User - Admin (One-to-One):

✔​ An admin is a user with additional privileges. The Admin entity has a user_id
foreign key pointing to the User entity.

3.​ User - Message (One-to-Many):

✔​ A user can send multiple messages—sender_id is FK to User.
✔​ A user can receive multiple messages—receiver_id is FK to User.

4.​ User - Request (One-to-Many):

✔​ A user (sender) can initiate many requests—sender_id is FK to User.
✔​ A user (receiver) can accept many requests—receiver_id is FK to User.

5.​ Request - Skills(Many-to-One):

✔​ Each Request references a Skill via skill_id (Request holds FK to Skill).

6.​ Profile - Skills(Many-to-Many):

✔​ Each Profile can have multiple Skills (as described by the Skills field).
✔​ Each Skill can belong to multiple Profiles.
✔​ This usually requires a separate junction/entity table (e.g., ProfileSkills) with
combinations of profile_id and skill_id.

7.​ Feedback - User (Many-to-One):

✔​ from_user_id is a FK to User (feedback given by user)
✔​ to_user_id is a FK to User (feedback received by user)
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 7:
State chart and Activity Modelling for problem statement.

State Chart Diagram

​ A State chart diagram describes a state machine.
​ State machine can be defined as a machine which defines different states of an
object and these states are controlled by external or internal events.
​ As State chart diagram defines the states, it is used to model the lifetime of an
object.
​ State chart diagrams are also used for forward and reverse engineering of a
system.
​ State chart dynamic nature of a system.

Purpose
​ To model the dynamic aspect of a system.
​ To model the life time of a reactive system.
​ To describe different states of an object during its life time.
​ Define a state machine to model the states of an object.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Activity diagram:

​ An activity diagram is a type of UML (Unified Modelling Language) diagram used in

software engineering and other fields to visually represent the flow of activities
and actions within a system, process, or workflow.

Here are some key elements and symbols commonly used in activity diagrams:

1.​ Initial Node: Represents the starting point of the activity diagram and is usually
depicted as a solid circle.

2.​ Activity: Represents a specific action or task within the process. It is usually
shown as a rounded rectangle with a verb or brief description inside.

3.​ Decision Node (Diamond): Represents a decision point in the process where one
or more alternative paths can be taken. Depending on the outcome of the decision,
the flow follows different paths.

4.​ Merge Node (Diamond): Represents the merging of multiple flow paths into a
single path after a decision has been made.

5.​ Fork Node (Bar): Indicates the parallel execution of multiple activities or paths. It
splits the flow into two or more concurrent paths.

6.​ Join Node (Bar): Indicates the convergence of multiple parallel paths into a single
path.

7.​ Final Node: Represents the end point of the activity diagram and is usually
depicted as a solid circle with a border.

8.​ Control Flow Arrow: Arrows connecting various elements to show the sequence
or flow of activities. These arrows indicate the order in which activities are
executed or decisions are made.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Activity – 1: User Registration & Skill Setup

​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Activity – 2: Skill Matching Process

​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Activity – 3: Session Scheduling & Learning

​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 8:
Modelling​ UML​ Class​ Diagrams and Sequence​ diagrams for problem
statement.

UML Class diagram:

​ In software engineering, A UML class diagram is a visual tool for illustrating class
structure and relationships in software. It's crucial in object-oriented system
design and documentation.

Purpose of Class diagram:

To visualize and document the structure of a software system, including classes,

attributes, and relationships. They aid in design, communication, and identifying
structural issues, facilitating effective software development.

The key components of a UML class diagram include:

1)​ Class: Represents a blueprint for creating objects in the software system. It has
three compartments: name, attributes, and methods.
2)​ Attributes: Properties or data members of a class, listed within the class
rectangle's attribute compartment. Attributes include names and data types.
3)​ Methods: Functions or operations that a class can perform, listed within the class
rectangle's method compartment. They include names, parameters, and return
types.
4)​ Associations: Depict relationships between classes and show how they
collaborate. Associations have names, roles, and multiplicities.
5)​ Aggregation and Composition: Represent part-whole relationships between
classes. Aggregation is a weaker form of composition.
6)​ Inheritance (Generalization): Indicates that one class inherits attributes and
methods from another. Represented as a solid line with an arrowhead.
7)​ Dependency: Shows that one class relies on another, often for method calls.
Depicted with a dashed line and an arrowhead.
8)​ Interfaces: Represented as circles, defining a contract of methods that
implementing classes must adhere to.
9)​ Abstract Classes: Displayed in italics, abstract classes often have abstract methods
without implementations.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Sequence diagram:

​ A sequence diagram is a type of interaction diagram that shows the order of

messages sent between objects. It's a Unified Modeling Language (UML) diagram.
​ Sequence diagrams are used by software developers and business professionals to
understand requirements.
​ The first message typically starts at the top left of the sequence diagram and
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

moves horizontally across lifelines from left to right.

​ Sequence diagrams are also known as: Event diagrams, Event scenarios.
​ A sequence diagram shows:
1.​ A set of objects or roles
2.​ Messages sent and received by the objects
3.​ Parallel vertical lines (lifelines) that represent different processes or objects
that live simultaneously
4.​ Horizontal arrows that represent the messages exchanged between the objects
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Purpose of Sequence Diagram

​ Model high-level interaction between active objects in a system

​ Model the interaction between object instances within a collaboration that realizes
a use case
​ Model the interaction between objects within a collaboration that realizes an
operation
​ Either model generic interactions (showing all possible paths through the
interaction) or specific instances of a interaction (showing just one path through
the interaction)
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 9:
Modelling Data Flow Diagrams for problem statement.

DFD diagram:

​ A data flow diagram (DFD) is a graphical or visual representation using a

standardized set of symbols and notations to describe a business's operations
through data movement.
​ They are often elements of a formal methodology such as Structured Systems
Analysis and Design Method.
​ DFDs can resemble flow charts or Unified Modelling Language (UML), but they are
not meant to represent details of software logic.
​ Data Flow Diagrams (DFD) are graphical representations of a system that illustrate
the flow of data within the system. DFDs can be divided into different levels, which
provide varying degrees of detail about the system.
​ Mainly 3 levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and
2-level DFD.

1)​ Level 0 DFD:

Provides an overview of the entire system, highlighting major processes, data flows,
and data stores, omitting internal process details.

2)​ Level 1 DFD:

Offers a more detailed view by breaking major processes from Level 0 into sub-
processes and specifying their associated data flows and data stores.

3)​ Level 2 DFD:

Further breaks down Level 1 sub-processes into smaller sub-processes with
accompanying data flows and data stores.

4)​ Level 3 DFD:

The most detailed level, used for complex systems, showcasing processes with in-
depth input, processing, output details, and associated data flows and data stores.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Symbols of DFD:

Using any convention’s DFD rules or guidelines, the symbols depict the four components
of data flow diagrams.

1.​ External entity:

An outside system that sends or receives data, communicating with the system
being diagrammed. They are the sources and destinations of information
entering or leaving the system.

2.​ Process:
Any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on
business rules.

3.​ Data store:

Files or repositories that hold information for later use, such as a database table or
a membership form. Each data store receives a simple label, such as “Orders.”

4.​ Data flow:

The route that data takes between the external entities, processes and data stores.
It portrays the interface between the other components and is shown with arrows,
typically label with a short data name, like “Billing details.”
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Data Flow Diagrams:

DFD Level 0

​ Level 0 DFDs, also known as context diagrams, are the most basic data flow
diagrams.
​ They provide a broad view that is easily digestible but offers little detail. Level 0
data flow diagrams show a single process node and its connections to external
entities.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

DFD Level 1

​ Level 1 DFDs are still a general overview, but they go into more detail than a
context diagram.
​ In a level 1 data flow diagram, the single process node from the context diagram is
broken down into sub processes.
​ As these processes are added, the diagram will need additional data flows and
data stores to link them together.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

DFD Level 2:

​ Level 2 DFDs simply break processes down into more detailed sub processes.
​ Level 3 data flow diagrams are detailed enough that it doesn’t usually make
sense to break them down further.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 10:
Estimation of Test Coverage Metrics and Structural Complexity for problem
statement.

Introduction:
​ A visual representation of flow of control within a program may help the developer
to perform static analysis of his code.
​ One could break down his program into multiple basic blocks, and connect them
with directed edges to draw a Control Flow Graph (CFG). A CFG of a program helps
in identifying how complex a program is. It also helps to estimate the maximum
number of test cases one might require to test the code.
​ In this experiment, we will learn about basic blocks and how to draw a CFG using
them. We would look into paths and linearly independent paths in context of a CFG.
Finally, we would learn about McCabe's cyclomatic complexity, and classify a given
program based on that.

Theory:-

Control Flow Graph:

​ A control flow graph (CFG) is a directed graph where the nodes represent different
instructions of a program, and the edges define the sequence of execution of such
instructions. Figure 1 shows a small snippet of code (compute the square of an
integer) along with it's CFG. For simplicity, each node in the CFG has been labeled
with the line numbers of the program containing the instructions.
​ A directed edge from node #1 to node #2 in figure 1 implies that after execution of
the first statement, the control of execution is transferred to the second instruction.
int x = 10, x_2 = 0; x_2 = x * x; return x_2;

Figure 1: A simple program and it's CFG

​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

​ A program, however, doesn't always consist of only sequential statements. There

could be branching and looping involved in it as well. Figure 2 shows how a CFG
would look like if there are sequential, selection and iteration kind of statements in
order.

Figure 2: CFG for different types of statements

​ A real life application seldom could be written in a few lines. In fact, it might consist
of thousand of lines. A CFG for such a program is likely to become very large, and it
would contain mostly straight-line connections. To simplify such a graph different
sequential statements could be grouped together to form a basic block.

Computing Cyclomatic Complexity:

​ Let G be a given CFG. Let E denote the number of edges, and N denote the number of
nodes. Let V(G) denote the Cyclomatic complexity for the CFG. V(G) can be obtained
in either of the following three ways:

​ Method #1: V(G) = E - N + 2

​ Method #2: V(G) could be directly computed by a visual inspection of the CFG:V(G)
= Total number of bounded areas + 1It may be noted here that structured programming
would always lead to a planar CFG.
​ Method #3: If LN be the total number of loops and decision statements in a
program, then V(G) = LN + 1

​ In case of object-oriented programming, the above equations apply to methods of a

class. Also, the value of V(G) so obtained is incremented by 1 considering the entry
point of the method.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

​ A quick summary of how different types of statements affect V(G) could be found in.
Once the complexities of individual modules of a program are known, complexity of
the program (or class) could be determined by,
V(G) = SUM( V(Gi) ) - COUNT( V(Gi) ) + 1
where COUNT( V(Gi) ) gives the total number of procedures (methods) in the program
(class).

Optimum Value of Cyclomatic Complexity

​ A set of threshold values for Cyclomatic complexity has been presented in, which we
reproduce below.

V(G) Module Category Risk

1-10 Simple Low

11-20 More complex Moderate

21-50 Complex High

> 50 Unstable Very high

​ It has been suggested that the Cyclomatic complexity of any module should not
exceed. Doing so would make a module difficult to understand for humans.
​ If any module is found to have Cyclomatic complexity greater than 10, the module
should be considered for redesign.
​ Note that, a high value of V(G) is possible for a given module if it contains multiple
cases in C like switch-casestatements.
​ McCabe had exempted such modules from the limit of V(G) as 10.

Merits:
​ McCabe's Cyclomatic complexity has certain advantages:
•​ Independent of programming language
•​ Helps in risk analysis during development or maintenance phase
•​ Gives an idea about the maximum number of test cases to be executed (hence,
the required effort) for a given module
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Demerits:
​ Cyclomatic complexity doesn't reflect on cohesion and coupling of modules.
​ McCabe's Cyclomatic complexity was originally proposed for procedural languages.
​ One may look in to get an idea of how the complexity calculation could be modified
for object-oriented languages. In fact, one may also wish to make use of Chidamber-
Kemerer metrics (or any other similar metric), which has been designed for object-
oriented programming.
​ Cyclomatic complexity is a source code complexity measurement that is being
correlated to a number of coding errors.
​ It is calculated by developing a Control Flow Graph of the code that measures the
number of linearly-independent paths through a program module.
​ Lower the Program's cyclomatic complexity, lower the risk to modify and easier to
understand.
​ It can be represented using the below formula:

Example of Cyclomatric Complexity

​ Cyclomatic complexity = E - N + 2*P

​ where, 🡪 E = number of edges in the flow graph.

🡪 N = number of nodes in the flow graph.

🡪 P = number of nodes that have exit points

​ Example :

IF A = 10 THEN
IF B > C
THEN A = B
ELS
EA=C
ENDIF
ENDIF
Print A
Print B
Print C
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

​ The Cyclomatic complexity is calculated using the above control flow diagram that
shows seven nodes(shapes) and eight edges (lines), hence the
​ Cyclomatic complexity = E - N + 2*P
​ Cyclomatic complexity is 8 - 7 + 2*1 = 3
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Experiment 11:
Designing Test Suites

Introduction
​ Development of a new software, like any other product, remains incomplete until it
subjected to exhaustive tests. The primary objective of testing is not to verify that all
desired features have been implemented correctly. However, it also includes
verification of the software behaviour in case of “bad inputs.”
​ In this experiment we discuss in brief about different types of testing, and provide
mechanisms to have hands-on experience on unit testing.

Theory:- Software Testing

​ Testing software is an important part of the development life cycle of a software. It is
an expensive activity. Hence, appropriate testing methods are necessary for ensuring
the reliability of a program. According to the ANSI/IEEE 1059 standard, the
definition of testing is the process of analysing a software item, to detect the
differences between existing and required conditions i.e. defects/errors/bugs and to
evaluate the features of the software item.
​ The purpose of testing is to verify and validate a software and to find the defects
present in a software.
​ The purpose of finding those problems is to get them fixed.
Verification is the checking or we can say the testing of software for consistency
and conformance by evaluating the results against pre-specified requirements.
Validation looks at the systems correctness, i.e. the process of checking that what
has been specified is what the user actually wanted.
Defect is a variance between the expected and actual result. The defect’s ultimate
source may be traced to a fault introduced in the specification, design, or
development (coding) phases.

Standards for Software Test Documentation

​ IEEE 829-1998 is known as the 829 Standard for Software Test Documentation. It is
an IEEE
​ standard that specifies the form of a set of documents for use in software testing.
There are other different standards discussed below.
▪​ IEEE 1008, a standard for unit testing
▪​ IEEE 1012, a standard for Software Verification and Validation
▪​ IEEE 1028, a standard for software inspections
▪​ IEEE 1044, a standard for the classification of software anomalies
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

▪​ IEEE 1044-1, a guide to the classification of software anomalies

▪​ IEEE 830, a guide for developing system requirements specifications
▪​ IEEE 730, a standard for software quality assurance plans
▪​ IEEE 1061, a standard for software quality metrics and methodology
▪​ IEEE 12207, a standard for software life cycle processes and life cycle data
▪​ BS 7925-1, a vocabulary of terms used in software testing
▪​ BS 7925-2, a standard for software component testing

Testing Frameworks

Following are the different testing frameworks:

​ jUnit - for Java unit test
​ Selenium - is a suite of tools for automating web applications for software testing
purposes, plugin for Firefox
​ HP QC - is the HP Web-based test management tool. It familiarizes with the process of
defining releases, specifying requirements, planning tests, executing tests, tracking
defects, alerting on changes, and analyzing results. It also shows how to customize
project.
​ IBM Rational - Rational software has a solution to support business sector for
designing, implementing and testing software.

Need for Software Testing

There are many reasons for why we should test software, such as:
​ Software testing identifies the software faults. The removal of faults helps reduce the
number of system failures. Reducing failures improves the reliability and the quality
of the systems.
​ Software testing can also improves the other system qualities such as maintainability,
usability, and testability.
​ In order to meet the condition that the last few years of the 20th century systems had
to be shown to be free from the ‘millennium bug’.
​ In order to meet industry specific standards such as the Aerospace, Missile and
Railway Signaling standards.

Test Cases and Test Suite

​ A test case describes an input descriptions and an expected output descriptions.

Input are of two types: preconditions (circumstances that hold prior to test case
execution) and the actual inputs that are identified by some testing methods. The set
of test cases is called a test suite.
​ We may have a test suite of all possible test cases.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Types of Software Testing

​ Testing is done in every stage of software development life cycle, but the testing done
at each level of software development is different in nature and has different
objectives. There are different types of testing, such as stress testing, volume testing,
configuration testing, compatibility testing, recovery testing, maintenance testing,
documentation testing, and usability testing.
​ Software testing are mainlyof following types
1.​ Unit Testing
2.​ Integration Testing
3.​ System Testing

Unit Testing

​ Unit testing is done at the lowest level. It tests the basic unit of software, that is the
smallest testable piece of software. The individual component or unit of a program
are tested in unit testing. Unit testing are of two types.

​ Black box testing: This is also known as functional testing, where the test cases are
designed based on input output values only. There are many types of Black Box
Testing but following are the prominent ones.
​ Equivalence class partitioning: In this approach, the domain of input values to a
program is divided into a set of equivalence classes. e.g. Consider a software
program that computes whether an integer number is even or not that is in the
range of 0 to 10. Determine the equivalence class test suite. There are three
equivalence classes for this program. - The set of negative integer - The integers
in the range 0 to 10 - The integer larger than 10
​ Boundary value analysis: In this approach, while designing the test cases, the
values at boundaries of different equivalence classes are taken into consideration.
e.g. In the above given example as in equivalence class partitioning, a boundary
values based test suite is { 0, -1, 10, 11 }

​ White box testing: It is also known as structural testing. In this testing, test cases are
designed on the basis of examination of the code. This testing is performed based on
the knowledge of how the system is implemented. It includes analyzing data flow,
control flow, information flow, coding practices, exception and error handling within
the system, to test the intended and unintended software behavior. White box testing
can be performed to validate whether code implementation follows intended design,
to validate implemented security functionality, and to uncover exploitable
vulnerabilities. This testing requires access to the source code. Though white box
testing can be performed any time in the life cycle after the code is developed, but it is
a good practice to perform white box testing during the unit testing phase.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Integration Testing

​ Integration testing is performed when two or more tested units are combined into a
larger structure. The main objective of this testing is to check whether the different
modules of a program interface with each other properly or not. This testing is mainly
of two types:
1.​ Top-down approach
2.​ Bottom-up approach
​ In bottom-up approach, each subsystem is tested separately and then the full system
is tested.
​ But the top-down integration testing starts with the main routine and one or two
subordinate routines in the system. After the top-level ‘skeleton’ has been tested, the
immediately subroutines of the ‘skeleton’ are combined with it and tested.

System Testing
​ System testing tends to affirm the end-to-end quality of the entire system. System
testing is often based on the functional / requirement specification of the system.
Non-functional quality attributes, such as reliability, security, and maintainability are
also checked.
​ There arethree types of system testing
​ Alpha testing is done by the developers who develop the software. This testing is
also done by the client or an outsider with the presence of developer or we can
say tester.
​ Beta testing is done by very few number of end users before the delivery, where
the change requests are fixed, if the user gives any feedback or reports any type
of defect.
​ User Acceptance testing is also another level of the system testing process where
the system is tested for acceptability. This test evaluates the system’s compliance
with the client requirements and assess whether it is acceptable for software
delivery.
​ An error correction may introduce new errors. Therefore, after every round of error-
fixing, another testing is carried out, i.e. called regression testing. Regression testing
does not belong to either unit testing, integration testing, or system testing, instead, it
is a separate dimension to these three forms of testing.

Regression Testing

​ The purpose of regression testing is to ensure that bug fixes and new functionality
introduced in a software do not adversely affect the unmodified parts of the program.
Regression testing is an important activity at both testing and maintenance phases.
When a piece of software is modified, it is necessary to ensure that the quality of the
software is preserved. To this end, regression testing is to retest the software using
the test cases selected from the original test suite.
​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​230470107209
​

Example: Write a program to calculate the square of a number in the range 1-100

#include
<stdio.h> Int
main(){
int n, res;
printf(“Enter a number:
“); scanf(“%d”, &n);
if (n >= 1 && n <= 100) {
res = n * n;
printf(“\n Square of %d is %d\n”;, n, res);
}
else if (n<= 0 || n > 100)
printf(“Beyond the range”);
return 0;
}

Output:
Inputs Outputs
I1: -2 O1: Beyond the
range I2: 0 O2: Beyond the
range I3: 1 O3: Square of 1
is 1
I4: 100 O4: Square of 100 is 10000 I5:
101 O5: Beyond the range
I6: 4 O6: Square of 4 is 16
I7: 62 O7: Square of 62 is 3844
Test Cases
T1: {I1 ,O1}
T2: {I2 ,O2}
T3: {I3, O3}
T4: {I4, O4}
T5: {I5, O5}
T6: {I6, O6}
T7: {I7, O7}

Some Remarks:

​ Testing is not a phase that occurs after coding; it's an ongoing process that begins
early, even before coding is done. Test cases are prepared based on the finalized
requirements in the SRS document to verify system features. Good testing not only
validates correct software functioning but also identifies any existing bugs. It's a
continuous, proactive practice integral to the entire software development process
from the start.