Software Engineering Lab

EXP NAME OF THE PAGE

NO: EXPERIMENT: NO:
1
Agile vs. Waterfall Simulation

2
Component-Based Development (CBD)

3
write a java program to implement the LOC Matrics

4 Development of problem statements

5 Preparation of Software Requirement Specification Document, Design

Documents and Testing Phase related documents

6 Preparation of Software Configuration Management and Risk Management

related documents

Study and usage of any Design phase CASE tool

7

8 Performing the Design by using any Design phase CASE tools

9 Develop test cases for unit testing and integration testing

10 Develop test cases for various white box and black box testing techniques
Software Engineering Lab

PRACTICAL 1

Aim : Agile vs. Waterfall Simulation

This demonstrates the key differences between the rigid Linear Sequential Model (Waterfall) and a flexible Agile Process
Model in handling new requirements. The Waterfall process struggles with changes, while the Agile process adapts by
incorporating the change into a future development cycle (sprint).
import time

def waterfall_process():
print("--- Starting Waterfall Development ---")

# Phase 1: Requirements Gathering (All features defined upfront)

print("Phase 1: Requirements Analysis and Planning")
features = ["Goal Setting", "Progress Tracking", "Initial Gamification concept"]
print(f" Requirements gathered for: {', '.join(features)}")

# Phase 2: Design
print("\nPhase 2: System Design")
print(" Designing database schemas and UI/UX layouts based on all requirements.")

# Phase 3: Implementation
print("\nPhase 3: Implementation and Coding")
print(" Building all features according to the design specifications.")

# Client introduces new requirement during implementation

new_req = "Advanced Gamification (badges, leaderboards)"
print(f"\n--- Late-Stage Requirement Change: Client wants '{new_req}' ---")
print(" This change requires significant rework of the design and code. The project schedule is now at risk.")

# Phase 4: Testing
print("\nPhase 4: Verification and Testing")
print(f" Testing completed for all initial features. Now, a major re-test is needed for the '{new_req}' feature.")

print("\n--- Waterfall Process Result: Major schedule and budget impact due to late change. ---")

def agile_process():
print("--- Starting Agile Development (using Sprints) ---")

# Initial backlog with main features

product_backlog = ["Goal Setting", "Progress Tracking"]
print(f"Initial Product Backlog: {product_backlog}")

sprint_number = 1

# Sprint 1
print(f"\n--- Sprint {sprint_number}: Focus on Core Features ---")
sprint_backlog = ["Goal Setting"]
print(f" Executing Sprint {sprint_number} (2 weeks). Focus: {sprint_backlog[0]}")
[Link](1) # Simulate work
print(f" '{sprint_backlog[0]}' feature is now complete and delivered.")

# Client feedback
print("\n--- Mid-Project Client Review ---")
new_req = "Advanced Gamification (badges, leaderboards)"
 print(f" Client feedback: They would like to add a new requirement: '{new_req}'.")
product_backlog.append(new_req)
print(f" New requirement added to the Product Backlog. No disruption to the current sprint.")

sprint_number += 1

# Sprint 2
print(f"\n--- Sprint {sprint_number}: Adding new and existing features ---")
sprint_backlog = ["Progress Tracking", new_req]
print(f" Executing Sprint {sprint_number} (2 weeks). Focus: {', '.join(sprint_backlog)}")
[Link](1) # Simulate work
print(f" Both '{' and '.join(sprint_backlog)}' features are now complete and delivered.")

print("\n--- Agile Process Result: New feature was smoothly integrated in a later sprint. ---")

# Execute the simulations

waterfall_process()
print("\n" + "="*50 + "\n")
agile_process()

Explanation
The code first runs the waterfall_process function, which follows a linear path. When the new requirement is introduced,
the program highlights the crisis on the horizon effect: it requires a painful and costly re-evaluation of previous phases
(design and implementation), which is a core weakness of the Waterfall model.
Next, the agile_process function simulates sprints. The new requirement is simply added to the product backlog and
prioritized for a future sprint. This demonstrates agility—the ability to adapt to change without derailing the entire project.
The code shows that the new feature is implemented and delivered smoothly in the next development cycle.
 Practical 2
Aim: Component-Based Development (CBD)
This pr uses Python classes to represent reusable software components. It shows how these pre-built components can be
assembled to quickly construct a larger application, demonstrating the core principle of Component-Based Development
(CBD).
# Component 1: UserAuthentication
class UserAuthentication:
"""A reusable component for managing user logins and security."""
def login(self, username, password):
print(f" -> {username} is authenticated successfully.")
return True

def logout(self, username):

print(f" -> {username} has logged out.")

# Component 2: NotificationSystem
class NotificationSystem:
"""A reusable component for sending different types of notifications."""
def send_email(self, recipient, message):
print(f" -> Email notification sent to {recipient}: '{message}'.")

def send_sms(self, phone_number, message):

print(f" -> SMS notification sent to {phone_number}: '{message}'.")

# Component 3: DataReporting
class DataReporting:
"""A reusable component for generating reports from data."""
def generate_report(self, data_type):
print(f" -> Generating a report for {data_type} data.")
# Simulating report generation logic
report = f"Report for {data_type}: Data analysis complete."
return report

# The main application that assembles the components

class StudentPortal:
def _init_(self):
# Assemble the pre-built components
[Link] = UserAuthentication()
[Link] = NotificationSystem()
[Link] = DataReporting()
print("Student Portal created by assembling pre-built components.")

def run(self):
print("\n--- Student Portal Main Menu ---")
username = "[Link]"

# Use the UserAuthentication component

if [Link](username, "password123"):
print("\nDisplaying user dashboard...")

# Use the DataReporting component to show grades

print([Link].generate_report("Grades"))

# Use the NotificationSystem component to send an alert

[Link].send_email(username + "@[Link]", "Your grades are now available!")
 [Link](username)

# Instantiate and run the application

portal = StudentPortal()
[Link]()

Explanation
The solution defines three independent classes (UserAuthentication, NotificationSystem, DataReporting) which act as self-
contained software components. They have clearly defined interfaces (methods like login, send_email, generate_report).
The StudentPortal class demonstrates how these components are "assembled" by creating instances of them within its
_init_ method. The main run method then orchestrates these components to perform the portal's functions. This approach
showcases the key benefits of CBD:
* Reusability: The components could be used in other applications (e.g., an HR portal, a library system).
* Faster Development: The portal is built quickly by leveraging pre-existing, tested components.
* Maintainability: Changes to the authentication logic, for example, only affect the UserAuthentication component, without
impacting the rest of the system.
 Practical 3

Aim : write a java program to implement the LOC matrics

Code:
import [Link];
import [Link];
import [Link];

public class CountLOC {

public static int countLOC(String filename) {

int loc = 0;
try (BufferedReader br = new BufferedReader(new FileReader(filename))) {
String line;
while ((line = [Link]()) != null) {
line = [Link]();
// Ignore blank lines and single-line comments
if (![Link]() && ![Link]("//")) {
loc++;
}
}
} catch (IOException e) {
[Link]("Error reading file: " + [Link]());
}
return loc;
}

public static void main(String[] args) {

if ([Link] == 0) {
[Link]("Please provide a Java file path as an argument.");
return;
}

String filename = args[0];

int loc = countLOC(filename);
[Link]("Lines of Code in " + filename + ": " + loc);
}
}

Explanation : This program traverses a directory, analyzes all .java files, and calculates the following
metrics for each file and the total project:
• Total Lines: All lines in the file, including code, comments, and whitespace.

• Blank Lines: Lines containing only whitespace.

• Comment Lines: Lines consisting solely of comments. This includes both single-line ( // ) and multi-line
( /* ... */ ) comments.

• Logical Lines of Code (LLOC): A more refined metric that counts executable statements, typically
defined as lines ending with a semicolon, curly brace, or a complete statement
 Practical 4

AIM: To develop problem statements for a library management system.

Problem Statement:
Statement of a current issue/problem that requires timely action to improve the situation.
Process Flow of Library Management System:

➔ A Book Bank lends books and magazines to member, who is registered in the system.
➔ Also it handles the purchase of new titles for the Book Bank.
➔ Popular titles are brought into multiple copies.
➔ Old books and magazines are removed when they are out or date or poor in condition.
➔ A member can reserve a book or magazine that is not currently available in the book bank, so that when it is
returned or purchased by the book bank, that person is notified.
➔The book bank can easily create, replace and delete information about the tiles, members, loans and
reservations from the system.
Components:
➔ Problem
➔ Proposed Solution
➔ Solution(s) and its implementation steps

Roles & Responsibilities:

a) Librarian:
→ Admin
→ Adding & modifying books etc.
→ Inventory maintenance

b) Member:
→ Registered users
→ Search available books
→ Order & book return

c) System:
→ Notifications for overdue, availability of book etc.
I Inputs:
→ Author Name
→ Published Year
→ Price
→ Book ID
→ User details like id, password for logging in
→ Communication Details

Problems/Constraints:

→ Updating difficulties on account of adding of new books regularly.

→ Faster due date notification(s).
→ Internet Bandwidth
→ Unavailability of e-b

PRACTICAL 5

AIM:
Preparation of Software Requirement Specification Document, Design Documents and Testing Phase
Related documents.
Preparation of Software Requirement Specification Document:

Users Characteristics:

Student: They are the people who desire to obtain the books and submit the information to the
database.

Librarian: He has the certain privileges to add the books and to approval of the reservation of books.

System Modules:

Log in: Secure registration of student and librarian by filling online registration form.

Book bank: Book bank contains all the books. New book added to the book bank with book no,
titlename, author, edition, publisher name details to the database. Any book is deleted if damaged.
Update of the book information also done.

Operations: student and administrator perform their operations like add book, delete book,update
information, view book details are implemented in log in Web Pages.

Non-functional requirements:

Privacy: privacy maintained for each and every user by providing user credentials username
and password.

Portability: installation on multiple platforms and execution of software.

Design Document:
➔ Algorithm, Data Structure, Architecture and other support Information is maintained in a design
document.
Diagrams:

a. Use Case:
→ System details summary & all users in the system.
b. Activity:
→ System behavior (inclusive of dynamic aspects).

c. Sequence:
→ Message flow with the time stamp.
d. Class:
→ System Structure (Name, Attributes, Operations).
e. State Chart:
→ States specific to components/objects of a system.
f. Deployment:
→ System architecture with respect to execution.
Test Plan Document:
➔ Test plan document contains all the catalog information of test strategies, objectives, schedule,
estimations and resources required to complete the project.
➔ A “Test Case” refers to the actions required to verify a specific feature or functionality in software
testing.
Test Case Design Template:

Test Description: Test Expected Actual Pre- Pass/Fail: Remarks:

Case Steps: Results: Results: Requisites:
ID:
Software Engineering Lab

PRACTICAL 6

AIM:
Preparation of Software Configuration Management and Risk Management related documents for library
management system.

Preparation of Software Configuration Management

➔ Forms basis for End User License Agreement (EULA).

➔ All the compatibilities of implementing the system can be known.

Software Requirements:

Operating System: Windows 7/10

Front end : J2EE

Back end : MySQL Server

IDE used : NetBeans

Hardware Requirements:

Processor: i3 or higher

RAM : 4 GB

Hard Disk drive: 500 GB

Risk Management:

➔ Relates to the factors that have negative impact on the software project.

➔ Categorized into

i. Known risks

ii. Unknown risks

→ Known risks are the “predictable” risks that can be easily categorized.

Example: Staffing, Code errors etc.

→ Unknown risks are the “unpredictable” risks that cannot be identified and categorized easily.

Example: Natural disasters, epidemic, recession etc.

Software Engineering Lab
Software Engineering Lab

PRACTICAL 7

AIM:
Study and usage of any Design phase CASE tool

Design phase CASE tool:

CASE Tool: STARUML

How to Install StarUML on Windows 10

➔ Star UML is a UML (Unified Modeling Language) tool introduced by MKLab. It is an open-source
modeling tool that supports the UML framework for system and software modeling. StarUML is
based on UML version 1.4, which provides 11 different types of diagrams and it accepts UML 2.0
notation. Version 2.0 was released for beta testing under a property license.

➔ StarUML is actively supporting the MDA (Model Driven Architecture). It supports the UML profile
concept and allowing it to generate code for multiple languages. It also provides a number of bug
fixes and improved compatibility with the modern versions of the Windows Operating System.

➔ StarUML is mostly used by the Agile and small development teams, professional persons and used
by the educational institutes.

Features of StarUML:

1. It supports multi-platform such as Mac OS, Windows, and Linux.

2. It involves UML [Link] compliant.

3. Includes Entity-Relationship Diagram (ERD), Data-Flow Diagram (DFD) and Flowchart

diagrams.

4. It creates multiple windows.

5. It has modern UX and dark and light themes.

6. Featured with retina (High-DPI) display support.

7. Includes model-driven development.

8. It has open Application Programming Interface (API).

Software Engineering Lab

9. Supports various third-party extensions.

10. Asynchronous model validation.

11. It can export to HTML docs.

Steps to Download and Install StarUML

Step 1: Go on the browser, type in the URL “StarUML”.

Step 2: Click on the very first search “Download-StarUML”.

Step 3: There will be 3 Operating Systems (OS) options, click on the option as per the devise OS.

Step 4: Now, right-click on the downloaded file, select “Show in Folder” option.

Step 5: Click on the open file, a popup window opens, click on the “Yes” button.

Step 6: Installation gets start. After installation popup opens to ask to buy a license. If you
Software Engineering Lab

Practical 8

Aim:To design performance using Design phase CASE Tool.

CASE Tool: StarUML

Use Case Diagrams:

The book bank use cases are:

1. book_issue

2. book_return

3. book_order

4. book_entry

5. search book_details

Actors Involved:
1. Student
2. Librarian
3. Vendor
I) Usecase Name: Search Book_Details
The librarian initiates this use case when any member returns or request the book and checking ifthe
book is available.
Precondition: The librarian should enter all Book details.
Normal Flow: Build message for librarian who search the book.
Post Condition: Send message to respective member who reserved the book.

II) Usecase Name: Book_ Issue

Initiated by librarian when any member wants to borrow the desired book. If the book is
available, the book is issued.
Precondition: Member should be valid member of library.
Normal Flow: Selected book will be issued to the member.
Alternative Flow: If book is not available then reserved book use case should be initiate. Post
Condition: Update the catalogue.

III) Usecase Name: Book_Order

Initiated by librarian when the requested book is not available in the library at that moment. The book
is reserved for the future and issued to the person when it is available.
Software Engineering Lab

Precondition: Initiatedonly when book is not available.

Normal Flow: It reserved the book if requested.
Post Condition: Mention the entry in catalogue for reservation.

IV) Usecase Name: Book_Return

Invoked by the librarian when a member returns the book.
Precondition: Member should be valid member of library.
Normal Flow: Librarian enters bookid and system checks for return date of the book.
AlternativeFlow: System checks for return date and if it returned late fine message will be displayed.

Post Condition: Check the status of reservation.

V) Usecase Name: Book_Entry

The purchase book use-case when new books invoke it or magazines are added to the library.
Precondition: Not available or more copies are required.
Normal Flow: Enter bookid, author information, publication information, purchased date, prize
and number of copies.
Post Condition: Update the information in catalogue.

Figure 1. Use case diagram for Book Bank System

Software Engineering Lab

Activity Diagrams:

➔ They are used to describe the business and operational step-by-step workflows of components
in a system.

➔ An activity diagram shows the overall flow of control.

Figure 2. Activity Diagram for Book Bank System [borrow book]

➔ An activity is shown as a roundedbox containing the name of the operation. This activity
diagram describes the behavior of the system.
Software Engineering Lab

Figure 3. Activity Diagram for Book Bank System [order book]

Figure 4. Activity Diagram for Book Bank System [Return book]

Software Engineering Lab

Sequence Diagram:
➔ A sequence diagram represents the sequence and interactions of a given USE-CASE or scenario.
Sequence diagrams can capture most of the information about the system.

➔ Most object-to-object interactions and operations are considered events and events include signals, inputs,
decisions, interrupts, transitions and actions to or from users or external devices.

➔ An event also is considered to be any action by an object that sends information. The event line represents
a message sent from one object to another, in which the “form” object is requesting an operation be
performed by the “to” object.

➔ The “to” object performs the operation using a method that the class contains. It is also represented by the
order in which things occur and how the objects in the system sendmessage to one another.

Figure 5. Sequence Diagram for Book Issue & Return

Software Engineering Lab

Collaboration Diagram:

Figure 6. Collaboration Diagram for Book Issue & Return

Class Diagram:

➔ The class diagram, also referred to as object modeling is the main static analysis diagram.
➔ The main task of object modeling is to graphically show what each object will do in the problem
domain.
➔ The problem domain describes the structure and the relationships among objects.

The ATM system class diagram consists of five classes:

1. Student

2. Book

3. Issue

4. Return

5. Vendor

6. Details
 1) Student:

➔ It consists of twelve attributes and three operations.

➔ The attributes are enroll no, name, DOB, father name, address, dept name, batch and
book limits.
➔ The operations of this class are addStInfo(), deleteStInfo(), modifyStInfo().

2) Book:

➔ It consists of ten attributes and four operations.

➔ This class is used to keep book information such as author, title, vendor, price, etc.

3) Issue:

➔ It consists of eight attributes and two operations to maintain issue details such as, issue
date, acc no of issued book, name of the student who borrowed book.

4) Return:

➔ It consists of eight attributes and two operations to maintain issue details such as, issue
date, acc no of issued book, name of the student who borrowed book.

5) Students:

➔ The attributes of this class are name, dept, year, bcode no.
➔ The operation is display students ().

6) Details:

➔ The attributes of this class are book name, author, bcode no. The operations are delete
details().
 Figure 7. Class Diagram for Book Bank System

State Chart Diagram

It consists of state, events and activities. State diagrams are a familiar technique to describe the
behavior of a system. They describe all of the possible states that a particular object can get into and
how the object's state changes as a result of events that reach the object.

Figure 8. State Chart Diagram for Book Bank System

 Practical 9

Aim: To develop test cases for unit testing and integration testing.

Unit Testing:
→ It is a software development process in which the smallest testable parts of an application,
called “units”, are individually scrutinized for proper operation.

→ Software developers and sometimes QA staff complete unit tests during the development process.

Integration Testing:

→ It is a type of software testing where components of the software are gradually integrated and then
tested as a unified group.
→ Usually, these components are already working well individually, but they may
break whenintegrated with other components.
 Practical 10

Aim: To develop test cases for various white box and black box testing techniques.

White Box Testing:

It is a form of application testing that provides the tester with complete knowledge of the application
Being tested, including access to source code and design documents.
Black Box Testing:
It is a form of testing that is performed with no knowledge of a system's internals, can be carried out
to evaluate the functionality, security, performance, and other aspects of an application.