Department of Information Technology

Practical Lab File

SOFTWARE ENGINEERING
(PC-IT- 306LA)

Submitted by Submitted to
Tanisha Garg Ms. Neha Bhatia
2822648 Assistant Professor

Panipat Institute of Engineering & Technology, Panipat

(Affiliated to Kurukshetra University, Kurukshetra)
May 2025
 INDEX

S.no Date Signature

1 Study and categorize the generic phases of software

development and maintenance.

2 Study various software development models.

3 Study various types of feasibility study and steps in doing

feasibility study.

4 Study the various steps for doing requirement analysis of any

project.

5 Write algorithm and draw flow chart to implement the

constructive cost estimation model (COCOMO).

6 Draw a DFDs of Crop Disease Prediction Model.

7 Draw a Use Case diagram of Crop Disease Prediction Model.

 8 Making use of object oriented design, implement a student
& employee record system using the concept of inheritance
and class diagram.

9 Draw Activity diagram for student admission process.

10 Draw sequence diagram for library management system.

11 Develop a complete test strategy for the program to find

greatest among 3 numbers.
 Program – 1
Aim: Study and categorise the generic phases of software development
and maintenance.

1. Planning & Analysis

The first phase of the SDLC is the project planning stage where you are gathering
business requirements from your client or stakeholders. This phase is when you
evaluate the feasibility of creating the product, revenue potential, the cost of
production, the needs of the end-users, etc. To properly decide what to make, what not
to make, and what to make first, you can use a feature prioritization framework that
takes into account the value of the software/update, the cost, the time it takes to build,
and other factors.

Once it is decided that the software project is in line with business and stakeholder
goals, feasible to create, and addresses user needs, then you can move on to the next
phase.

2. Define Requirements
This phase is critical for converting the information gathered during the planning and
analysis phase into clear requirements for the development team. This process guides
the development of several important documents: a software requirement specification
(SRS) or product specification, a Use Case document, and a Requirement Traceability
Matrix document.

3. Design
The design phase is where you put pen to paper—so to speak. The original plan and
vision are elaborated into a software design document (SDD) that includes the system
design, programming language, templates, platform to use, and application security
measures. This is also where you can flowchart how the software responds to user
actions.

In most cases, the design phase will include the development of a prototype model.
Creating a preproduction version of the product can give the team the opportunity to
visualize what the product will look like and make changes without having to go
through the hassle of rewriting code.

4. Development
The actual development phase is where the development team members divide the
project into software modules and turn the software requirement into code that makes
the product. This SDLC phase can take quite a lot of time and specialized
development tools. It’s important to have a set timeline and milestones so the software
developers understand the expectations and you can keep track of the progress in this
stage.

In some cases, the development stage can also merge with the testing stage where certain
tests are run to ensure there are no critical bugs.

Keep in mind, different types of product development software will have different specialties
so you’ll want to pick the one that suits you best.

5. Testing
Before getting the software product out the door to the production environment, it’s
important to have your quality assurance team perform validation testing to make sure
it is functioning properly and does what it’s meant to do. The testing process can also
help hash out any major user experience issues and security issues.

In some cases, software testing can be done in a simulated environment. Other simpler tests
c`an also be automated.

The types of testing to do in this phase:

• Performance testing: Assesses the software's speed and scalability under
different conditions
• Functional testing: Verifies that the software meets the requirements
• Security testing: Identifies potential vulnerabilities and weaknesses
• Unit-testing: Tests individual units or components of the software
• Usability testing: Evaluates the software's user interface and overall user experience
• Acceptance testing: Also termed end-user testing, beta testing, application
testing, or field testing, this is the final testing stage to test if the software
product delivers on what it promises

6. Deployment
During the deployment phase, your final product is delivered to your intended user.
You can automate this process and schedule your deployment depending on the type.
For example, if you are only deploying a feature update, you can do so with a small
number
of users (canary release). If you are creating brand-new software, you can learn more
about the different stages of the software release life cycle (SRLC).

7. Maintenance
The maintenance phase is the final stage of the SDLC if you’re following the waterfall
structure of the software development process. However, the industry is moving
towards a more agile software development approach where maintenance is only a
stage for further improvement. In the maintenance stage, users may find bugs and
errors that were missed in the earlier testing phase. These bugs need to be fixed for
better user experience and retention. In some cases, these can lead to going back to the
first step of the software development life cycle.

The SDLC phases can also restart for any new features you may want to add in your next
release/update.

Fig 1.1:Software development lifecycle

 Program – 2
Aim: Study various software development models.
Software development models are various processes or methods that are chosen for project
development depending on the objectives and goals of the project. Many development life cycle
models have been developed to achieve various essential objectives. Models specify the various steps
of the process and the order in which they are executed. Some of the common software development
models are:
1) Waterfall Model:
It is one of the oldest and traditional software development mode. It follows a linear and sequential
approach, where each phase is completed before moving to the next. This model is best suited for
projects with well-
defined requirements and minimal expected changes.

Fig 2.1:Waterfall Model

Phases Levels of the Waterfall Model:

1) Feasibility Study:
• Assesses whether the project is practical and achievable. Includes technical, economic
and operational feasibility analysis.
2) Requirements Analysis & Specifications:
• Involves gathering all functional and non-functional requirements. Requirements are
documented in a Software Requirement Specification (SRS) document.
 3) Design:
• The system architecture and design are created based on the specifications, including
high- level design (HLD) and low-level design (LLD).
4) Integration & System Testing:
• All modules are integrated and tested as a complete system. Testing ensures software
meets requirements and functions correctly.
5) Coding & Unit Testing:
• Developers write the code based on the design specifications. Unit testing ensures each
module functions correctly.
6) Deployment and Maintenance:
• The software is released to the customer and maintained overtime. Advantages:
• Well – Structured and easy to manage.
• Good for projects with fixed requirements.
• Clear documentation at each stage.

Disadvantages:
• There is no backtracking.
• It assumes that only correct things happen at every phase of the model, which isn’t
practically possible.

2) Prototype Model:
The Prototype Model is a software development approach where a working prototype (a rough
version of the final product) is built early to gather user feedback before full-scale development.
This model is iterative and helps refine requirements based on real user interactions.

Phases of Prototype Model:

1) Requirement Gathering:
•Gathering of initial requirements, focusing on key functionalities that need to be prototyped.
2) Quick Design:
•Create a basic system structure, this is the not the final design but a rough model for feedback.
3) Prototype Development:
•A basic working prototype is built, it includes limited functionalities and a temporary user
interface
4) Customer Feedback:
•Customers / Users interact with the prototype and provide feedback.
5) Refinement & Incorporation:
 •Feedback is collected and the requirements are refined and incorporated as per the suggestions.
6) Final Development:
• The prototype phase is repeatedly performed until the acceptance of the prototype.
• After the acceptance the actual system is developed by applying a
model, generally iterative waterfall model.
•The prototype is generally discarded or used as a base for final development.

Fig 2.2: Prototype Model

Advantages of Prototype Model:
•Early User involvement.
•Reduces Development Risks
•Better Requirement Clarity
Disadvantages of Prototype
Model:
•Time consuming
•Costly
•May lead to delaying completion depending upon requested changes

3) Evolutionary Model:
The Evolutionary Model is an iterative software development approach where the system is
developed in stages, gradually improving through multiple versions. Each version incorporates user
feedback and refinements, making it ideal for projects with evolving requirements.

Phases of the Evolutionary Model:

1) Requirement Gathering:
• Gathering of initial requirements, focusing on key features for the first version.
 2) Identification of features:
•Features along with core features are identified.
3) Development of Core Feature:
• Core feature is developed by applying iterative waterfall model.
4) Customer Feedback:
• The initial version is provided to customers and refinement is done as per the feedback.
5) Development of Next feature:
• The next identified feature is developed using the iterative waterfall model, the
customers are provided with this updated version for feedback.
6) Deployment & Maintenance:
• Once all the features have been developed the system is deployed and maintained.

Fig 2.3: Evolutionary Model

Advantages of Evolutionary Model:

• Handles changing requirements
• Early System Delivery
• Improved user satisfaction
Disadvantages of Evolutionary
Model:
• Time consuming
• Higher Cost • Complex Management
 4) Spiral Model:
The Spiral Model is a risk-driven software development approach that combines iterative
development with elements of the Waterfall Model. It is best suited for large, complex, and high-
risk projects, where continuous risk assessment and iterative refinement are necessary.

Fig 2.4: Spiral Model

Phases of the Spiral Model:
The Spiral Model consists of four main phases, repeated in each spiral (iteration). Every cycle
result in a more refined version of the software.
1. Objective Setting & Requirements Analysis:
• Identify system requirements, constraints, define objectives, risks, and alternatives.
2. Risk Analysis & Prototyping:
• Identify potential project risks and develop a prototype to test feasibility and
gather user feedback. Modify requirements or design if risks are too high.
3. Development & Testing:
• Design and develop the system based on feedback and perform unit, integration,
and system testing.
4. Evaluation & Planning for the Next Iteration:
•Gather user feedback and evaluate project progress decide whether to continue
refining or proceed to final deployment.

Advantages of Spiral Model:

• Early Risk Detection
• Frequent User Feedback
• Improved Software Quality
Disadvantages of Spiral Model:
• Expensive & Time – Consuming
• Complex Management
• Not Suitable for Small Projects

Comparison Table:

Aspect Waterfall Model Prototype Model Evolutionary Spiral Model

Model

Approach & Sequential, linear;Build and refine

Iterative, Risk-driven,iterative; High
Flexibility Low flexibility prototype; evolving; flexibility
High flexibility High
flexibility

Best for & Fixed, clear Unclear requirements; Frequent Large, complex projects
Feedback requirements; Frequent feedback updates, with risk
Little feedback changes; management;
until testing Regular Frequent feedback
feedback

Cost & Time High cost of Prototype may incur Cost High initial cost for
changes; high costs due decreases planning and risk
Fixed timeline to iterations with each analysis
iteration

Risk Management No risk Limited risk managementRisks identified Explicit focus on risk
management; through prototyping and mitigated analysis and
Difficult to handle in iterations mitigation in each
changes cycle
 Program – 3
Aim: Study various types of feasibility study and steps in doing feasibility study
A feasibility study is a structured analysis conducted to determine the viability of a proposed project
or business idea before committing significant resources. It helps decision-makers understand the
potential strengths and weaknesses of the project, the risks involved, and whether the initiative is
worth pursuing.

Types of Feasibility Study:

1. Technical Feasibility:
• Assesses whether the organization has—or can obtain—the technology, expertise,
and resources needed to meet project requirements. It considers the hardware,
software, equipment, and technical skills necessary for the project's success.
2. Economic or Financial Feasibility:
• Examines the cost-effectiveness of the project by analysing the investment required
versus the expected returns. This type of study involves a cost-benefit analysis,
looking at both short-term and long-term financial impacts, including cash flow,
profitability, and potential funding sources.
3. Legal Feasibility:
• Focuses on identifying any legal or regulatory issues that could affect the project.
This involves ensuring compliance with local, regional, and national laws, as well as
industry-specific regulations, permits, and zoning laws.
4. Operational Feasibility:
• Evaluates how well the proposed project will fit into the existing organizational
structure and whether the current operational processes can support the new project.
This study considers the
project’s impact on day-to-day operations, staffing, and management systems.
5. Schedule (or Time) Feasibility:
• Analyses whether the project can be completed within a reasonable time frame. This
includes assessing timelines, deadlines, and the availability of necessary resources to
meet the project’s milestones.
6. Market Feasibility:
• Investigates the market conditions, including demand, competition, and customer
behaviour. This type often involves market research and surveys to validate the
potential for market acceptance and profitability of the product or service.
 7. Environmental Feasibility:
• Examines the potential environmental impacts of the project and whether it complies
with
environmental regulations. This study is especially important for projects that involve
significant land use or resource consumption.

Steps in Conducting a Feasibility Study

1. Preliminary Analysis (Screening):
• Idea Assessment: Quickly evaluate the concept to see if it merits a more indepth study.
• Objective Definition: Clearly state the purpose and scope of the feasibility study.
2. Defining the Project Scope and Objectives:
• Detailed Description: Outline the project, its goals, and what success would look like.
• Assumptions and Constraints: Identify any assumptions made and potential
limitations
(financial, time, resources).
3. Conducting a Market Analysis:
• Market Research: Study market trends, target demographics, and customer needs.
• Competitive Analysis: Evaluate the competition to understand market saturation
and unique selling propositions.

Fig 3.1 Steps of Feasibility Study

4. Technical Evaluation:
• Resource Assessment: Determine if current technology and skills can meet the
project’s demands.
• System Requirements: Identify necessary technology, equipment, and expertise.
5. Financial Analysis:
• Cost Estimation: Prepare detailed cost projections including initial investment,
operational costs, and contingencies.
• Revenue Projections: Estimate future revenue streams and potential profitability.
• Funding Sources: Identify possible funding sources and financial risks.
6. Legal and Regulatory Review:
• Compliance Check: Assess applicable laws, licenses, and regulatory requirements.
• Risk Assessment: Identify legal risks and potential hurdles.
7. Operational Feasibility Study:
• Organizational Impact: Examine how the project fits within the existing
structure and its impact on operations.
• Human Resources: Evaluate if additional personnel or training is needed.
8. Risk Analysis:
• Identify Risks: List potential risks (technical, financial, legal, etc.).
• Mitigation Strategies: Develop strategies to manage and mitigate these risks.
9. Consolidation and Reporting:
• Data Synthesis: Bring together all findings into a coherent report.
• Recommendations: Provide a clear recommendation on whether to proceed,
modify, or abandon the project, supported by evidence from the study.
10. Decision Making:
• Stakeholder Review: Present the study’s findings to key decision-makers.
• Final Decision: Decide on the project’s future based on the detailed analysis.
 Program – 4
Aim: Study the various steps for doing requirement analysis of any project
In essence, a requirement can be understood in three ways:
1. User Perspective:
• A condition or capability needed by a user to solve a problem or achieve an objective.
2. System Perspective:
• A condition or capability that a system or its component must meet or possess to
satisfy a contract, standard, specification, or other formally imposed documents.
3. Documented Representation:
• A recorded or written representation of the above conditions or capabilities.

Software requirement analysis simply means complete study, analyzing, describing software
requirements so that requirements that are genuine and needed can be fulfilled to solve problem.
There are several steps involved in analyzing Software requirements. Steps involved in Requirement
Analysis:
1. Identify Stakeholders:
• Objective: Determine who will be affected by or have influence over the project.
• Actions:
o List internal (team members, management) and external (customers,
suppliers) stakeholders.
o Conduct interviews or meetings to understand their expectations.

2. Gather Requirements:
• Objective: Collect detailed and clear inputs regarding what the project
should achieve.
• Techniques:
o Interviews & Workshops: Direct discussions to capture individual needs.
o Surveys & Questionnaires: Gather data from a larger audience.
o Observation: Study current workflows to identify gaps.
o Document Analysis: Review existing documents to extract historical and
contextual requirements.
 Fig 4.1: Requirement Analysis
3. Categorize Requirements:
• Objective: Organize the gathered information to manage and prioritize effectively.
• Categories:
o Functional Requirements: Specific features, operations, or behaviors.
o Non-Functional Requirements: Performance, usability, security, and
reliability criteria.
o Business Requirements: High-level objectives that justify the project.
o Technical Requirements: System constraints and technology standards.

4. Analyze and Refine Requirements:

• Objective: Ensure that the requirements are complete, consistent, and feasible.
• Actions:
o Validate each requirement to check for clarity and alignment with project goals.
o Identify and resolve any conflicts or redundancies.
o Develop use cases, flowcharts, or models to better understand
interactions.
5. Document Requirements:
• Objective: Create a clear, structured requirements specification document.
• Components:
o Detailed descriptions of functional and non-functional requirements.
o Assumptions, constraints, and acceptance criteria.
o Diagrams (e.g., UML, flowcharts) to visualize processes.
6. Prioritize Requirements:
• Objective: Determine which requirements are most critical for project success.
• Approaches:
 o MoSCoW Method: Classify requirements as Must-have, Should-
have, Could-have, or Won’t-have.
o Value vs. Effort Analysis: Prioritize based on the impact on business value
relative to implementation effort.
7. Validate Requirements:
• Objective: Ensure all stakeholders agree on the requirements and that they are
achievable.
• Actions:
o Review the documented requirements with stakeholders. o Use
prototypes or mock-ups to verify that the requirements meet user
expectations.
o Conduct feasibility studies and consistency checks.
8. Manage and Track Requirements:
• Objective: Keep the requirements current as the project evolves.
• Techniques: o Implement version control to track changes. o Develop a traceability
matrix linking requirements to design, development, and testing stages.
o Establish a change management process to handle modifications efficiently.
 Program – 5
Aim: Write algorithm and draw flow chart to implement the constructive cost estimation model
(COCOMO).

The COCOMO Model is a procedural cost estimate model for software projects and is often used as
a process of reliably predicting the various parameters associated with making a project such as
size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981. The key parameters
that define the quality of any software product, which are also an outcome of COCOMO, are
primarily effort and schedule:
• Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
• Development Time: This simply means the amount of time required for the completion of
the job, which is, of course, proportional to the effort put in. It is measured in the units of
time such as weeks, and months.
Types of Projects in the COCOMO Model
In the COCOMO model, software projects are categorized into three types based on their
complexity, size, and the development environment. These types are:
• Organic: A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also the
team members have a nominal experience regarding the problem.
• Semi-detached: A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various programming
environments lie in between organic and embedded. The projects classified as Semi-
Detached are comparatively less familiar and difficult to develop compared to the organic
ones and require more experience better guidance and creativity. For example: Compilers or
different Embedded Systems can be considered Semi-Detached types.
• Embedded: A software project requiring the highest level of complexity, creativity, and
experience requirement falls under this category. Such software requires a larger team size
than the other two models and also the developers need to be sufficiently experienced and
creative to develop such complex models.

COCOMO Algorithm:
1. Start
2. Input the estimated size of software project in KLOC (Kilo Lines of Code).
3. Choose the project type:
 • Organic
• Semi – Detached
• Embedded
4. Determine the effort equation parameters based on the project type:
• Organic: a = 2.4, b = 1.05
• Semi – Detached: a = 3.0, b = 1.12
• Embedded: a = 3.6, b = 1.2
5. Determine the development time equation parameters based on the project type:
• Organic: A = 2.5, b = 0.38
• Semi – Detached: A = 2.5, b = 0.35
• Embedded: A = 2.5, b = 0.32
6. Compute Efforts and Development time:
• Effort = a * (KLOC)^b
• Development Time (Tdev) = A*(Effort)^B
7. End
COCOMO Flowchart:

Fig 5.1: COCOMO Flowchart

Code:
import java.util.Scanner;
public class Cocomo {
public static void main(String[] args) {
Scanner in = new Scanner(System.in);
System.out.println("Enter the value of
KLOC"); int kloc = in.nextInt();
System.out.println("Enter the choice of Model \n 1.Organic \n 2.Semi-
Detached \n 3.Embedded");
int choice = in.nextInt();
float a1 = 0 , a2 = 0 , b1 = 0, b2 =
0; if(choice == 1){
a1 = 2.4f;
a2 = 1.05f;
 b1 = 2.5f;
b2 =
0.38f;
}
else if(choice == 2)
{ a1 = 3.0f;
a2 =
1.12f; b1
= 2.5f; b2
= 0.35f;
}
else if(choice == 3)
{ a1 = 3.6f;
a2 = 1.2f;
b1 = 2.5f;
b2 =
0.32f;
}
else{
System.out.println("INVALID CHOICE !!!");
}
double effort = a1 * Math.pow(kloc,a2);
int Tdev = (int)(b1 * Math.pow(effort,b2)) + 1;
System.out.println("Effort = " + effort + " PM");
System.out.println("Development Time = " + Tdev + "
OUTPUT:

Fig 5.2: Organic Project Fig 5.3: Semi-Detached Project

Fig 5.4: Embedded Project

 Program - 6
Aim: Study the concept in developing data flow diagram (DFD) and
Draw DFDs for Diverse Medicinal Plants Interactive Platform.

A Data Flow Diagram (DFD) is a traditional visual representation of the information

flows within a system. A neat and clear DFD can depict the right amount of the
system requirement graphically. It can be manual, automated, or a combination of
both.
It shows how data enters and leaves the system, what changes the information, and where data
is stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It
may be used as a communication tool between a system analyst and any person who
plays a part in the order that acts as a starting point for redesigning a system. The
DFD is also called as a data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in
a DFD, suppress that urge! A diamond-shaped box is used in flow charts to represents
decision points with multiple exists paths of which the only one is taken. This implies
an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.
Standard symbols for DFDs are derived from the electric circuit
diagram analysis and are shown in fig below:
Circle: A circle (bubble) shows a process that transforms data inputs into data
outputs. Data Flow: A curved line shows the flow of data into or out of a process or
data store. Data Store: A set of parallel lines shows a place for the collection of data
items. A data store indicates that the data is stored which can be used at a later stage or
by the other processes in a different order. The data store can have an element or
group of elements.
Source or Sink: Source or Sink is an external entity and acts as a source of system
inputs or sink of system outputs.
 Levels in Data Flow Diagrams (DFD)
The DFD may be used to perform a system or software at any level of abstraction.
Infact, DFDs may be partitioned into levels that represent increasing information
flow and functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here,
we will see primarily three levels in the data flow diagram, which are: 0-level
DFD, 1- level DFD, and 2-level DFD.

Medicinal plants identify process using DFD:

0- level DFD
The Level-0 DFD, also called the context diagram for the Diverse Medicinal Plants
Interactive Platform system, is shown in the figure. As the bubbles are decomposed
into less abstract levels, the corresponding data flow may also need to be
decomposed further to represent more granular steps of the prediction process.

Fig 6.1 Level-0 DFD

1- level DFD
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In
this level, we highlight the main objectives of the system and breakdown the high-
level process of 0-level DFD into subprocesses.

Fig 6.2 Level-1 DFD

 EXPERIMENT - 7
Aim: Draw use case diagram for Diverse Medicinal Plants Interactive
Platform. A Use Case Diagram is a type of Unified Modelling Language (UML) diagram that
represents the interaction between actors (users or external systems) and a system under
consideration to accomplish specific goals. It provides a high-level view of the system’s
functionality by illustrating the various ways users can interact with it.

Fig 7.1 Use-Case Diagram Notations

Use Case Diagram Notations

UML notations provide a visual language that enables software developers, designers, and
other stakeholders to communicate and document system designs, architectures, and
behaviours in a consistent and understandable manner.
1. Actors
Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases
and receive the outcomes. Proper identification and understanding of actors are crucial for
accurately modeling system behavior.
2. Use Cases
Use cases are like scenes in the play. They represent specific things your system can do. In the
online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or
“Update Product Information”. Use cases are represented by ovals.
3. System Boundary
The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that are
external to it. The system boundary is typically represented by a rectangular box that surrounds
all the use cases of the system.
Purpose of System Boundary:
• Scope Definition: It clearly outlines the boundaries of the system, indicating
which components are internal to the system and which are external actors or entities
interacting with the system.
• Focus on Relevance: By delineating the system’s scope, the diagram can focus on
illustrating the essential functionalities provided by the system without unnecessary
details about external entities.

4. Use Case Diagram Relationships

In a Use Case Diagram, relationships play a crucial role in depicting the interactions between
actors and use cases. These relationships provide a comprehensive view of the system’s
functionality and its various scenarios. Let’s delve into the key types of relationships and
explore examples to illustrate their usage.

4.1 Association Relationship

The Association Relationship represents a communication or interaction between an actor and
a use case. It is depicted by a line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality described by the use case.

Example: Online Banking System

• Actor: Customer
• Use Case: Transfer Funds
• Association: A line connecting the “Customer” actor to the “Transfer Funds”
use case, indicating the customer’s involvement in the funds transfer process.

Fig 7.2 Association

4.2 Include Relationship
The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included use
case. This relationship promotes modular and reusable design.

Example: Social Media Posting

• Use Cases: Compose Post, Add Image
• Include Relationship: The “Compose Post” use case includes the functionality of
“Add Image.” Therefore, composing a post includes the action of adding an
image.

Fig 7.3 Include

4.3 Extend Relationship

The Extend Relationship illustrates that a use case can be extended by another use case under
specific conditions. It is represented by a dashed arrow with the keyword “extend.” This
relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
• Use Cases: Book Flight, Select Seat
• Extend Relationship: The “Select Seat” use case may extend the “Book
Flight” use case when the user wants to choose a specific seat, but it is an
optional step.

Fig 7.4 Extend

4.4 Generalization Relationship
The Generalization Relationship establishes an “is-a” connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case.

Example: Vehicle Rental System

• Use Cases: Rent Car, Rent Bike
• Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized
versions of the general use case “Rent Vehicle.”

Fig 7.5 Generalization

5. How to draw a Use Case diagram in UML?
Step 1: Identify Actors
Determine who or what interacts with the system. These are your actors. They can be users,
other systems, or external entities.
Step 2: Identify Use Cases
Identify the main functionalities or actions the system must perform. These are your use cases.
Each use case should represent a specific piece of functionality.
Step 3: Connect Actors and Use Cases
Draw lines (associations) between actors and the use cases they are involved in.
This represents the interactions between actors and the system.
Step 4: Add System Boundary
Draw a box around the actors and use cases to represent the system boundary. This defines the
scope of your system.
Step 5: Define Relationships
If certain use cases are related or if one use case is an extension of another, you can indicate
these relationships with appropriate notations.
 Step 6: Review and Refine
Step back and review your diagram. Ensure that it accurately represents the interactions and
relationships in your system. Refine as needed.
Step 7: Validate
Share your use case diagram with stakeholders and gather feedback. Ensure that it aligns
with their understanding of the system’s functionality.

Let’s understand how to draw a Use Case diagram with the help of an Cop Disease
Prediction System:
To create a Use Case Diagram for the Crop Disease Prediction Model, we need to define the
actors, use cases, and relationships between them. Here's how it looks based on the diagram:
1. Actors:
• Farmer: The end-user who captures and uploads crop images, predicts diseases, and
receives treatment suggestions.
• Agri Expert: An agricultural expert who can view prediction history and help improve the
model.
• System Admin: Manages the system, updates the database, and handles user and model
management.

2. Use Cases:
• Capture Image: Farmer captures an image of the affected crop.
• Upload Image: Farmer uploads the captured crop image into the system.
• Predict Disease: The system processes the image to predict crop disease.
• View Result: Farmer views the disease prediction output.
• Suggest Treatment: System suggests treatments or solutions for the predicted disease.
• View History: Agri Expert accesses historical disease prediction records.
• Train Model: Agri Expert or Admin retrains the model using updated datasets.
• Update Database: Admin updates the dataset used for training and predictions.
• Manage Users: Admin manages user access and roles within the system.

3. Relations:
• Farmer:

o Capture Image
o Upload Image
o Predict Disease
 o View Result
o Suggest Treatment
• Agri Expert:
o View History
o Train Model
• System Admin:

o Train Model
o Update Database
o Manage Users

Below is the use case diagram of an Diverse Medicinal Plants Interactive Platform:

Fig 7.6 Use-Case Diagram

 Program – 8
Aim: Making use of object-oriented design, implement a student &employee record system using
the concept of inheritance and class diagram.

Object-Oriented Design (OOD) is a software design approach where a system is organized around
real-world entities called objects. These objects are instances of classes, which define both data
(attributes) and behaviors (methods). OOD focuses on modeling software using the same principles
that describe physical objects, making systems more natural to design and understand.
OOD is based on the key principles of Object-Oriented Programming (OOP) and is widely used in
modern development for building reliable and scalable applications.
Benefits of Object-Oriented Design
• Reusability:
o Classes can be reused in multiple parts of the system or in different
projects. Inheritance also allows sharing of common code.
• Modularity:
o Since the code is divided into separate classes, it's easier to develop, test, and
maintain each part independently.
• Encapsulation:
o By keeping internal object details hidden, encapsulation enhances data security and
integrity. Changes to one part of the code do not affect others unexpectedly. •
Scalability:
o The system can be easily extended by adding new classes or modifying existing ones
without disrupting the whole application.
• Maintainability:
o The clear structure and separation of concerns make it easier to identify and fix bugs,
update features, and optimize performance.
• Flexibility:
o Through polymorphism and dynamic binding, the system can adapt to new
requirements and behaviors with minimal changes.
Code:
class Person {
protected String
name; protected int
age; protected String
gender;
public Person(String name, int age, String
gender) { this.name = name;
this.age = age;
 }
public void displayInfo() {
System.out.println("Name: " + name + ", Age: " + age + ", Gender: " + gender);
}
}
class Student extends Person
{ private String
studentID; private String
course; private int year;
public Student(String name, int age, String gender, String studentID, String
course, int year) {
super(name, age, gender);
this.studentID = studentID;
this.course = course;
this.year = year;
}
@Override
public void displayInfo()
{ super.displayInfo();
System.out.println("Student ID: " + studentID + ", Course: " + course + ",
Year: "
+ year);
}
}
class Employee extends Person
{ private String
employeeID; private String
department; private double
salary;
public Employee(String name, int age, String gender, String employeeID,
String department, double salary) {
super(name, age, gender);
this.employeeID =
employeeID; this.department
= department; this.salary =
salary;
}
@Override
public void displayInfo() { super.displayInfo();
System.out.println("Employee ID: " + employeeID + ", Department: " +
department +
",
Salary: " + salary);
}
}
public class Main {
public static void main(String[] args) {
Student s = new Student("Alice", 20, "Female", "S123", "Computer
Science", 2); Employee e = new Employee("Bob", 35, "Male", "E456",
"IT", 50000); s.displayInfo();
System.out.println(
); e.displayInfo();
}
}
Output:

Fig 8.1 OOD code

Class Diagram:
• A class diagram is a visual representation of the structure of a system in object-oriented design. It
shows the classes, their attributes (fields), methods (functions), and the relationships between
those classes.
• A class diagram consists of several key components that help define the structure of a system. The
class itself is represented by a rectangle divided into three sections: the top section displays the
class name, the middle section lists the attributes (properties or fields) of the class, and the bottom
section contains the methods (functions or operations) associated with the class.
• Attributes are the variables or properties of the class, usually shown in the middle part of the
rectangle, and their visibility is indicated with symbols such as + for public, - for private, and # for
protected. Methods are the functions that belong to the class, listed in the bottom section, and like
attributes, their visibility can be marked using the same symbols.
• Relationships between classes are essential in class diagrams, showing how classes interact. These
include associations (depicted as solid lines), arrows to show directionality (e.g., inheritance or
dependencies), and inheritance (represented by a solid line with a triangle arrowhead pointing to the
parent class). Aggregation or composition shows a "whole-part" relationship, indicated by a
diamond shape at the "whole" class.
• The visibility of attributes and methods in a class diagram determines their accessibility— public (+),
private (), or protected (#). Finally, multiplicity defines how many instances of a class are involved in
a relationship, such as one-to-many or many-to-many. These components together create a visual map
of how classes and objects interact within a system.

Fig 8.2 Class Diagram

 Program - 9
Aim: Draw activity diagram for student admission process
Activity diagrams are an essential part of the Unified Modeling Language (UML) that help visualize
workflows, processes, or activities within a system.
An Activity Diagram is a behavioral diagram in the Unified Modeling Language (UML) that
graphically represents workflows of stepwise activities and actions. They show the dynamic aspects
of a system and are particularly useful for modeling the flow of control or data between different
activities.
Key Components:
1. Activities: Represented as rounded rectangles, indicating tasks or operations.
2. Start Node: A filled black circle that marks the beginning of the workflow.
3. End Node: A filled black circle inside a larger circle that signifies the end.
4. Decision Node: A diamond shape used for branching the flow based on conditions.
5. Merge Node: A diamond shape where multiple flows converge.
6. Fork Node: A horizontal or vertical line that splits a single flow into multiple parallel flows.
7. Join Node: Merges concurrent flows back into a single flow.
8. Flow/Control Arrows: Indicate the direction of workflow between activities.
9. Swimlanes: Partition the diagram to show which part of the organization or system
performs each activity.
Purpose of Activity Diagrams:
• Visualizing complex workflows.
• Modeling business processes or software algorithms.
• Illustrating parallel processes and decision points. • Depicting user interactions in systems.

Fig 9.1 Student_Admission_AD

 Program – 10
Aim: Draw sequence diagram for library management system.
A Sequence Diagram is a UML tool used to represent the interaction between objects in a
timeordered sequence. It focuses on how system components communicate through message
exchanges, making it ideal for modeling dynamic behavior in software systems.

Key Concepts:
• Actors
o External entities (e.g., users, systems) that interact with the system.
• Objects / Components
o System parts that send or receive messages (e.g., modules, classes).
• Lifelines
o Vertical dashed lines showing an object’s presence over time.
• Messages
o Horizontal arrows representing calls, signals, or responses between lifelines.
• Activation Bars
o Rectangles on lifelines indicating when an object is actively performing an operation.
• Loops / Conditions
• Used to represent repeated or conditional interactions (e.g., retry loops, if/else).

Uses:
• Visualizing use case flows (e.g., login, checkout, book issue).
• Designing and debugging system interactions.
• Documenting business logic or service workflows.
• Supporting test case design and validation.

Benefits:
• Clarifies system behavior over time.
• Helps spot design flaws early.
• Bridges the gap between requirements and implementation.
Fig 10.1 Library Management System
 Program – 11
Aim: Develop a complete test strategy for the program to find greatest among 3
numbers. Test Strategy:
This test strategy outlines how we will verify the functionality of the program find_greatest(a, b, c)
that identifies the greatest number among three given inputs. The strategy covers Black Box Testing
(functional testing based on input-output) and White Box Testing (structural testing based on
internal code paths).
Test Objectives:
• Correctness: Ensure the program correctly identifies the largest number from three input
numbers.
• Robustness: Ensure the program handles various edge cases, including negative numbers,
zeros, and equal values.
• Performance: Ensure that the program executes correctly and efficiently for a wide range
of inputs.
• Boundary Conditions: Validate the program's handling of edge cases such as equal
numbers, negative numbers, or zero.
Test Types:
1. Black Box Testing:
• This testing method focuses on the program's output based on various input
combinations, without considering the internal logic or structure.
• The test cases will primarily focus on the functional correctness of the program,
verifying that it produces the correct greatest number.
2. White Box Testing:
• This testing method checks the internal logic and code coverage.
• It ensures that all decision paths and branches in the program are tested to verify that
all conditions (e.g., a >= b and a >= c, b >= a and b >= c, and c >= a and c >= b) are
adequately tested.
Test Plan:
1. Black Box Testing:
The goal is to validate the functionality based on various combinations of inputs without considering
the code structure.
Test Scenarios and Cases:
• Scenario 1: Testing with positive numbers.
o Test Case 1: find_greatest(3, 5, 2) ▪ Expected Output: 5
 Rationale: Regular case with positive numbers to test standard functionality.
 • Scenario 2: Testing with negative numbers.
o Test Case 2: find_greatest(-3, -5, -2)
 Expected Output: -2
 Rationale: Ensures that the function correctly identifies the greatest
among negative numbers.
• Scenario 3: Testing with all equal numbers.
o Test Case 3: find_greatest(4, 4, 4)
 Expected Output: 4
 Rationale: Tests how the function handles equality, ensuring it can return
one of the values when all are equal.
• Scenario 4: Testing with zero and mixed values.
o Test Case 4: find_greatest(0, -2, 5) ▪ Expected Output: 5
 Rationale: Verifies that zero and positive numbers are handled correctly.
Test Execution Criteria:
• Pass Criteria: The program must return the expected value for each test case.
• Fail Criteria: If the program returns an incorrect value for any test case, it will be
considered a failure.
2. White Box Testing:
This type of testing focuses on testing the internal logic of the program by ensuring that all code paths
and conditions are covered.
Test Scenarios and Cases:
• Scenario 1: Path where a >= b and a >= c.
o Test Case 1 (Path 1): find_greatest(5, 3, 2)
 Expected Output: 5
 Rationale: This tests the case where a is the greatest and the program
follows the path a >= b and a >= c.
• Scenario 2: Path where b >= a and b >= c.
o Test Case 2 (Path 2): find_greatest(2, 6, 4)
 Expected Output: 6
 Rationale: This tests the case where b is the greatest and the program
follows the path b >= a and b >= c.
• Scenario 3: Path where c >= a and c >= b.
o Test Case 3 (Path 3): find_greatest(2, 3, 5)
 Expected Output: 5
 Rationale: This tests the case where c is the greatest and the program
follows the path c >= a and c >= b.
 • Scenario 4: Equality condition (a == b == c).
o Test Case 4 (Equality Condition): find_greatest(4, 4, 4)
 Expected Output: 4
 Rationale: This tests the case where all input values are equal, and the
program should handle this correctly.
Test Execution Criteria:
• Pass Criteria: The program must follow the correct decision path and return the
expected result for each test case.
• Fail Criteria: If any of the paths are not followed correctly or if the function returns an
incorrect result, it will be considered a failure.

Code:
public class GreatestFinder {
public static int findGreatest(int a, int b, int
c) { if (a >= b && a >= c) {
return a;
} else if (b >= a && b >= c) {
return b;
} else {
return c;
}
}
public static void blackBoxTests()
{ int result = findGreatest(3,
5, 2);
System.out.println("Black Box Test Case 1: " + (result == 5 ? "Passed"
: "Failed"));
result = findGreatest(-3, -5, -2);
System.out.println("Black Box Test Case 2: " + (result == -2 ? "Passed"
: "Failed"));
result = findGreatest(4, 4, 4);
System.out.println("Black Box Test Case 3: " + (result == 4 ? "Passed"
: "Failed"));
result = findGreatest(0, -2, 5);
System.out.println("Black Box Test Case 4: " + (result == 5 ? "Passed"
: "Failed"));
}
public static void whiteBoxTests()
{ int result = findGreatest(5,
3, 2);
System.out.println("White Box Test Case 1 (Path 1): " + (result == 5 ?
"Passed" : "Failed"));
result = findGreatest(2, 6, 4);
System.out.println("White Box Test Case 2 (Path 2): " + (result == 6 ?
"Passed" : "Failed"));
result = findGreatest(2, 3, 5);
System.out.println("White Box Test Case 3 (Path 3): " + (result == 5 ?
 result = findGreatest(4, 4, 4);
System.out.println("White Box Test Case 4 (Equality Condition): " +
(result
== 4 ? "Passed" : "Failed"));
}
public static void main(String[] args)
{ System.out.println("Running Black Box Tests...");
blackBoxTests();
System.out.println("\nRunning White Box Tests...");
whiteBoxTests();
}
}

Output:

Fig 11.1: Testing Results