GALGOTIAS UNIVERSITY

SCHOOL OF COMPUTING SCIENCE & ENGINEERING

Software Engineering and Testing Methodologies

R1UC502B

Name of the Student:

Semester

Roll. No.

Batch

Submitted To
List of Experiments
Experiment Experiment Name Page
No. Number
1 Prepare a Software Requirement Specification (SRS) document in 04
line with the IEEE recommended standards for Airline
Reservation System.
2 Prepare a software requirement specification (SRS) for passport 09
automation system or Digi yatra system.
3 Draw the Entity relationship diagram for any school at Galgotias 13
University's
4 Draw the data flow diagrams at level 0 and level 1 for GU 18
Examination Board.
5 Design the Use case diagram, Class Diagram, Activity diagram, 21
Sequence diagram for ATM Operations.
6 Design the Use case diagram, Class Diagram, Activity diagram, 40
Sequence diagram for GU library Management System.
7 Design the Use case diagram, Class Diagram, Activity diagram, 49
Sequence diagram, Component diagram, Deployment Model for
GU - SCSE.
8 To develop a Railway Reservation System that allows users to 56
book, cancel, and manage train reservations, enabling efficient
and user-friendly railway service management.
9 To develop an Expert System for prescribing medicines based on 67
given symptoms, enabling Remote Diagnostics and
Patient/Hospital Management.
10 To develop a test case for unit testing by using JUnit Tool. 78
11 To develop a test case for Integration testing by using JUnit Tool. 82
12 Design and develop a program in a Java language to solve the 87
triangle problem defined as follows. Accept three integers which
are supposed to be the three sides of a triangle and determine the
three values represent an equilateral triangle, isosceles triangle,
and scalene triangle or they do not form a triangle at all. Assume
that the upper limit for the size of any side is 10. Derive test cases
for your program based on boundary value analysis, and execute
the test cases and discuss the results.

2
Experiment: 1
Prepare a Software Requirement Specification (SRS) document in line with the IEEE
recommended standards for Airline Reservation System.

Procedure:
Software Requirements Specification (SRS) Document
1. Introduction

1.1 Purpose
The purpose of this Software Requirements Specification (SRS) document is to provide a
comprehensive description of the Airline Reservation System (ARS). This document will serve
as a guide for the development, validation, and maintenance of the ARS, ensuring all
stakeholders have a clear understanding of the system's requirements.

1.2 Scope
The Airline Reservation System is designed to manage flight reservations, ticketing, and
passenger information. It will support functionalities for booking flights, checking flight
availability, managing user accounts, and generating reports. The system will be used by airline
staff and passengers.

1.3 Definitions, Acronyms, and Abbreviations

- **ARS**: Airline Reservation System
- **UI**: User Interface
- **API**: Application Programming Interface
- **DBMS**: Database Management System
- **CRUD**: Create, Read, Update, Delete

1.4 References
- IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications
- Airline industry standards and guidelines
1.5 Overview
This document is organized into the following sections:
- Introduction
- Overall Description

3
- Specific Requirements
- Appendices

2. Overall Description

2.1 Product Perspective

The ARS will be a web-based application accessible from both desktop and mobile devices. It
will interact with external systems for payment processing and flight data synchronization. The
system will be built using a three-tier architecture comprising a presentation layer, application
layer, and data layer.

2.2 Product Functions

- **Flight Booking**: Allow users to search for flights, select seats, and book tickets.
- **Flight Management**: Enable airline staff to manage flight schedules, seat availability,
and cancellations.
- **User Management**: Provide functionalities for user registration, login, and profile
management.
- **Payment Processing**: Integrate with payment gateways to process transactions.
- **Reporting**: Generate various reports related to bookings, cancellations, and revenue.

2.3 User Classes and Characteristics

- **Passengers**: Individuals who book flights and manage their bookings.
- **Airline Staff**: Employees who manage flights, seat allocations, and handle customer
support.
- **Administrators**: Users who manage system configurations, user permissions, and overall
system maintenance.

2.4 Operating Environment

- **Client**: Web browsers (Chrome, Firefox, Safari, Edge)
- **Server**: Web server (Apache, Nginx), Application server (Java EE, .NET)
- **Database**: Relational DBMS (MySQL, PostgreSQL, Oracle)

4
2.5 Design and Implementation Constraints
- Compliance with data protection regulations (e.g., GDPR)
- Integration with existing airline databases and payment systems
- Scalability to handle peak loads during high-demand periods

2.6 Assumptions and Dependencies

- Users have access to the internet and a compatible web browser.
- Payment gateway services are available and operational.
- Flight data synchronization with external systems is reliable.

3. Specific Requirements

3.1 Functional Requirements

3.1.1 Flight Booking

- The system shall allow users to search for available flights based on origin, destination, and
date.
- The system shall provide a list of available flights with options for seat selection.
- The system shall enable users to book seats and generate a booking confirmation.

3.1.2 Flight Management

- The system shall allow airline staff to add, update, or delete flight schedules.
- The system shall allow staff to view and manage seat availability and booking status.

3.1.3 User Management

- The system shall provide user registration, login, and password recovery functionalities.
- The system shall allow users to view and update their profile information.

3.1.4 Payment Processing

- The system shall integrate with a payment gateway to handle transactions.
- The system shall provide secure payment processing and generate payment receipts.

5
3.1.5 Reporting
- The system shall generate reports on bookings, cancellations, and revenue.
- Reports shall be available in various formats (e.g., PDF, CSV).

3.2 Non-Functional Requirements

3.2.1 Performance
- The system shall support up to 10,000 concurrent users.
- Response time for flight search queries shall be under 3 seconds.

3.2.2 Security
- The system shall implement SSL encryption for data transmission.
- User data shall be stored securely with access control mechanisms in place.

3.2.3 Usability
- The system shall have an intuitive and user-friendly interface.
- The system shall provide help documentation and customer support features.

3.2.4 Reliability
- The system shall have an uptime of 99.9% and provide backup and recovery solutions.

3.2.5 Maintainability
- The system shall be designed for easy maintenance and updates.
- Code shall follow standard coding practices and be documented thoroughly.

3.3 Interface Requirements

3.3.1 User Interfaces

- The system shall provide a web-based UI for both passengers and airline staff.
- The UI shall be responsive and accessible on various devices.

3.3.2 Hardware Interfaces

- The system shall be compatible with standard server hardware and network configurations.

6
3.3.3 Software Interfaces
- The system shall interface with external payment gateways and flight data services.
- The system shall use RESTful APIs for integration with other services.

3.3.4 Communication Interfaces

- The system shall support HTTP/HTTPS for communication between clients and servers.
- Email notifications shall be sent for booking confirmations and updates.

4. Appendices

4.1 Glossary
- **Booking Confirmation**: An email or notification sent to users confirming their flight
reservation.
- **Seat Allocation**: The process of assigning a specific seat to a booked flight.

4.2 Analysis Models

- **Use Case Diagrams**: Illustrating the interactions between users and the system.
- **Data Flow Diagrams**: Depicting the flow of information within the system.
4.3 Issues
- Potential issues related to integration with third-party systems.
- User feedback and system performance monitoring.

Result:
This SRS document provides a comprehensive outline of the Airline Reservation System's
requirements. Each section ensures that all stakeholders have a clear understanding of
the system's capabilities, constraints, and interfaces.

7
Experiment: 2
Prepare a Software Requirement Specification (SRS) document in line with the IEEE
recommended standards for Passport Automation System.

Procedure:
1.1 Objective
The purpose of this document is to specify the requirements for the Passport Automation
System (PAS). This system aims to streamline the process of passport application, renewal,
and management by automating manual tasks and improving efficiency.

1.2 Scope
The PAS will automate the following processes:
 Application submission
 Document verification
 Payment processing
 Status tracking
 Printing and distribution of passports

1.3 Definitions, Acronyms, and Abbreviations

 PAS: Passport Automation System
 API: Application Programming Interface
 UI: User Interface
 DBMS: Database Management System

1.4 References
 ISO/IEC 27001: Information security management systems
 National Passport Guidelines [Country-specific guidelines]

2. Overall Description
2.1 Product Perspective
The PAS will be a web-based application integrated with a backend database and document
management system. It will provide interfaces for applicants, administrative staff, and
government officials.

8
2.2 Product Functions
The system will support the following functions:
 User registration and authentication
 Passport application submission and tracking
 Document upload and verification
 Payment gateway integration
 Passport issuance and printing

2.3 User Classes and Characteristics

 Applicants: Individuals applying for new passports or renewals. They need a user-
friendly interface to submit applications and track their status.
 Administrative Staff: Responsible for verifying documents, processing applications,
and managing records.
 Government Officials: Review and approve applications and ensure compliance with
regulations.

2.4 Operating Environment

 Client: Web browsers (Chrome, Firefox, Edge)
 Server: Linux-based server environment
 Database: SQL-based DBMS (e.g., MySQL, PostgreSQL)

2.5 Design and Implementation Constraints

 Compliance with local data protection regulations.
 Integration with existing government databases and systems.

2.6 Assumptions and Dependencies

 Availability of reliable internet access for users.
 Integration with external verification services.

3. Specific Requirements
3.1 Functional Requirements
3.1.1 User Registration and Authentication
 Users must be able to register with personal information and verify their identity.
 The system should support password recovery and multi-factor authentication.

9
3.1.2 Passport Application Submission
 Users can fill out and submit passport applications online.
 The system should allow users to upload required documents in various formats.
3.1.3 Document Verification
 Administrative staff should be able to review and verify uploaded documents.
 Integration with third-party verification services for authenticity checks.
3.1.4 Payment Processing
 Integration with a secure payment gateway for processing fees.
 Users should receive confirmation of payment.
3.1.5 Status Tracking
 Applicants should be able to track the status of their application in real-time.
 Notifications via email or SMS for status updates.
3.1.6 Passport Issuance and Printing
 System-generated passport documents must meet government standards.
 Integration with printers for passport issuance.

3.2 Non-Functional Requirements

3.2.1 Performance
 The system should handle up to 10,000 concurrent users.
 Response time for user actions should be less than 2 seconds.
3.2.2 Security
 Data encryption for user information and documents.
 Regular security audits and compliance with data protection regulations.
3.2.3 Usability
 The UI should be intuitive and accessible to users with varying technical skills.
 Support for multiple languages as required.
3.2.4 Reliability
 The system should have an uptime of 99.9%.
 Regular backups and disaster recovery plans.
3.2.5 Maintainability
 The code should follow best practices for documentation and modularity.
 The system should be easily upgradable to accommodate future enhancements.

10
4. External Interface Requirements
4.1 User Interfaces
 Web-based user interface with responsive design.
 Admin dashboard with tools for managing applications and user accounts.
4.2 Hardware Interfaces
 Integration with passport printers.
 Scanners for document verification.
4.3 Software Interfaces
 APIs for payment gateway integration.
 Integration with existing government databases.
4.4 Communications Interfaces
 Support for email and SMS notifications.
 Secure communication protocols for data exchange.

5. Other Requirements
5.1 Legal and Regulatory Requirements
 Compliance with national and international passport regulations.
 Adherence to data protection laws and standards.
5.2 Documentation
 User manuals for applicants and administrative staff.
 Technical documentation for system maintenance and upgrades

Result:
This SRS document provides a comprehensive outline of the passport automation system
requirements. Each section ensures that all stakeholders have a clear understanding of
the system's capabilities, constraints, and interfaces.

11
Experiment: 3
Prepare an entity relationship diagram for any school at Galgotias University.

Tools:
 Microsoft Visio / LucidChart.

ER Model:
 An Entity-Relationship Model represents the structure of the database with the help of
a diagram.
 ER Modelling is a systematic process to design a database as it would require to analyze
all data requirements before implementing the database.

Symbols Used in ER Diagrams

 Rectangles: This Entity Relationship Diagram symbol represents entity types

 Ellipses: This symbol represents attributes

 Diamonds: This symbol represents relationship types

 Lines: It links attributes to entity types and entity types with other relationship types

 Primary key: Here, it underlines the attributes

 Double Ellipses: Represents multi-valued attributes

12
13
1. ER Diagram for Student Management System

14
2. ER Diagram for Examination Process

15
 3. ER Diagram for University Management System

Result:
This diagram helps in understanding the structure and flow of data within the system,
supporting efficient database design and management for university operations.

16
Experiment 4:
Draw the data flow diagrams at level 0 and level 1 for GU Examination Board.

Tools:
 Microsoft Visio

DFD
 In Software engineering DFD (data flow diagram) can be drawn to represent the system
of different levels of abstraction.
 It is a graphical representation of data flow in any system.
 It is capable of illustrating incoming data flow, outgoing data flow and store data.
 Data flow diagram describes anything about how data flows through the system.

Levels in Data Flow Diagram (DFD)

DFDs can be divided into different levels, which provide varying degrees of detail about the
system.
Level 0 Data Flow Diagram (DFD)
 Level 0 is the highest-level Data Flow Diagram (DFD), which provides an overview of
the entire system.
 It shows the major processes, data flows, and data stores in the system, without
providing any details about the internal workings of these processes.
1- Level Data Flow Diagram (DFD)

 1-Level provides a more detailed view of the system by breaking down the major
processes identified in the level 0 Data Flow Diagram (DFD) into sub-processes.

2- Level Data Flow Diagram (DFD)

 2-Level provides an even more detailed view of the system by breaking down the sub-
processes identified in the level 1 Data Flow Diagram (DFD) into further sub-
processes.

17
 3- Level Data Flow Diagram (DFD)
 3-Level is the most detailed level of Data Flow Diagram (DFDs), which provides a
detailed view of the processes, data flows, and data stores in the system.

Session management

Exam management course management

Examination
management
system
Student management System user
management

Login management

Zero level DFD Exam management system

18
 Student management Generate Student
report

Class management Generate class report

Examination
management
system
Branch management Generate branch
report

login management Check user login

details

System user Generate system user

management report

First level DFD Exam Management System

Result:
This diagram helps in understanding the DFD.

19
Experiment: 5
Design the Use case diagram, Class Diagram, Activity diagram, State Chart diagram,
Sequence diagram, Collaboration diagram, Deployment diagram and also generate the
code automatically by testing the test cases for ATM Operations by using the rational
rose enterprise edition software.

Architectural views of UML (Unified Modelling Language)

 The user model view
- Use Case Diagram - The functionality of a system.
 The structural model view
- Class Diagram - The static structure of a system.
- Object Diagram - The static structure of a system at a particular time.
 The behavioural model view
- Sequence Diagram - Interaction among elements of a system in a time sequence.
- Collaboration diagram - Interaction among elements and their relations organized in
time and space.
- State Diagram - The status condition and responses of the elements of a system.
- Activity Diagram - The activities of the system.
 The implementation model view
- Component Diagram - The organization of the elements realizing the system.
 The Environment model view
- Deployment diagram - Configuration of environment elements and the mapping of
elements realizing the system into them.

Software Required:
 Rational Rose Enterprise Edition / MS Visio / Visual Paradigm

1. Use Case Diagram

Drawing a use case diagram
Create a use case diagram through resource icons. Move the mouse over a shape and press
a resource icon that can create use case. Drag it and then release the mouse button until it
reaches to your preferred place. The source shape and the newly created use case are
connected. Finally, name the newly created use case.
Identify the Actors:

20
  Customer
 Client
 Bank officer
 Bank System
 ATM Machine (Optional, can be treated as an actor or part of the system)
Identify the Use Cases:
 Withdraw Cash
 Check Balance
 Deposit Funds
 Transfer Funds
 Change PIN
 Print Statement
 Contact Bank

Procedure:
I. Open Rational Rose Enterprise Edition.
II. Select Rational Unified Process from the dialog box.
III. Under use case view package  select use case model.
IV. Now identify your actors according to the question. For Eg: Customer, ATM etc.
V. Create actors under the actor package. (Select  Actors package  Right click 
New  Actor).
VI. Add all the actors under the actor’s package.
VII. Now rename those actors as customer, ATM etc.
VIII. Create use cases under the use case package. (Select  Use cases package  Right
click  New  use case).
IX. Add all the use cases under the use cases package.
X. Now rename those use cases as Insert Card, Enter Password etc.
XI. Right Click Use cases view Package  New  use case diagram.
XII. Now rename it as “ATM Scenario”.
XIII. Now double click the ATM Scenario use case diagram under the use case view
package (Double click  ATM Scenario  Drag and drop the actors and use cases
in the Use Case Diagram: Use case view / ATM Scenario window.
XIV. Connect the actor with the use case through unidirectional associations.
XV. Draw as in the figure given below.

21
Use Case Diagrams:
a) ATM Scenario

Client

Transfer funds

22
b) An example of use case diagram for Bank ATM subsystem

c) An Example of Bank ATM Transactions and Customer Authentication

23
 d) An Example of Bank ATM Maintenance, Repair, Diagnostics Use Cases.

1. Class Diagram
Classes:
 ATM
o Attributes: location, id
o Methods: validateCard(), ejectCard(), displayMessage()
 Card

24
 o Attributes: cardNumber, expiryDate, PIN
o Methods: validatePIN()
 Account
o Attributes: accountNumber, balance
o Methods: checkBalance(), withdraw(), deposit(), transfer()
 Transaction
o Attributes: transactionID, date, amount
o Methods: executeTransaction()
 BankSystem
o Attributes: listOfAccounts
o Methods: authenticateCard(), processTransaction(), updateAccount()

Note:
A sample class diagram is provided below; use the class details of above to generate
different class diagrams. It is not limited!

Procedure – Class Diagram

I. Right Click  Logical View  New  Class diagram.
II. Rename it as ATM Processing.
III. Double click  ATM Processing  Drag and drop the class icon at the window.
IV. While dropping there might be a chance of getting actor symbol at the window (To
Change it into class  Right Click  Open specification  Make the stereotype as
blank, so that you will see only the class).

25
 V. By selecting class  right click  new attributes and new operations according to the
figure given below.
VI. Link all the classes by their associations.
VII. Draw as in the figure given below.

26
Class Diagram:
ATM Processing:

2. Activity Diagram

Procedure – Activity Diagram

I. Right Click  Logical View  New  Activity diagram.
II. Rename it as ATM Process.
III. Double click  ATM Process  Drag and drop the apt icons at the window.
IV. Draw as in the figure given below.

27
Activity Diagram for ATM Process:

Insert
card

Enter
PIN

Connect Not connected

Enter
transition
Any more transaction

No more transaction

Remove
card

28
 3. State chart Diagram
Procedure – State chart Diagram
I. Right Click  Logical View  New  state chart diagram.
II. Rename it as ATM scenario.
III. Double click  ATM scenario  Drag and drop the apt icons at the window.
IV. Draw as in the figure given below.

29
 ATM Scenario State Transition Diagram

4. Sequence Diagram
Procedure – Sequence Diagram
I. Right Click  Logical View  New  sequence diagram.
II. Rename it as ATM Process.
III. Double click  ATM Process  Drag and drop the apt icons at the window.
IV. Draw as in the figure given below.

30
Sequence Diagram for ATM Processing:

ac : B : Bank
account client
1: Insert card

31
5. ATM scenario for Collaboration diagram
Note:
If you are using Rational Rose Enterprise Edition software, simply click the F5 key
on your keyboard to build a collaboration diagram. Other software requires that you
design the diagram below exactly or adjust it to meet your needs.

32
 6. ATM scenario for Component diagram
Procedure – Component Diagram
I. Right Click  Component View  New  Component diagram.
II. Rename it as ATM Process.
III. Double click  ATM Process  Drag and drop the apt icons at the window.
IV. Draw as in the figure given below.

33
 7. ATM Scenario for Deployment Diagram
Procedure – Deployment Diagram
I. Double click  Deployment View.
II. Draw as in the figure given below.

To Generate Code:
i. Open the component diagram.
ii. Select the component individually  right click  open specification  Language
 ANSI C++.
iii. Similarly do all the components and set the language into ANSI C++.

34
iv. Select Realizes  Right click the class name ATM, customer etc  select assign.

35
36
 v. Similarly do the same with all the components.
vi. At the final stage select Main Program.

vii. Right Click  open specification  Language ANSI C++  Realizes  Assign.
viii. Once realizes done  right the Main Program  ANSI C++  Generate Code.
(Select your path where to generate the code).

37
Sample Code:
#ifndef ATM_H_HEADER_INCLUDED_993CE905
#define ATM_H_HEADER_INCLUDED_993CE905

//##ModelId=66C357B1007F
class ATM
{
};

#endif /* ATM_H_HEADER_INCLUDED_993CE905 */

Result:
The above program was successfully compiled, and codes were generated.

38
Experiment: 6
Design the Use case diagram, Class Diagram, Activity diagram, Sequence diagram,
Collaboration diagram, Deployment diagram and also generate the code automatically
by testing the test cases for Library Management System Operations by using the rational
rose enterprise edition software.

Software Required:
 Rational Rose Enterprise Edition / MS Visio / Visual Paradigm

2. Use Case Diagram

Drawing a use case diagram
Create a use case diagram through resource icons. Move the mouse over a shape and press
a resource icon that can create use case. Drag it and then release the mouse button until it
reaches to your preferred place. The source shape and the newly created use case are
connected. Finally, name the newly created use case.
Identify the Actors:
 Librarian
 User
 Admin
Identify the Use Cases:
 Register
 Purchase
 Reserve
 Update

Procedure:
I. Open Rational Rose Enterprise Edition.
II. Select Rational Unified Process from the dialog box.
III. Under use case view package  select use case model.
IV. Now identify your actors according to the question. For Eg: User tc.
V. Create actors under the actor package. (Select  Actors package  Right click 
New  Actor).
VI. Add all the actors under the actor’s package.
VII. Now rename those actors as User, Librarian etc.

39
 VIII. Create use cases under the use case package. (Select  Use cases package  Right
click  New  use case).
IX. Add all the use cases under the use cases package.
X. Now rename those use cases as Issue Book etc.
XI. Right Click Use cases view Package  New  use case diagram.
XII. Now rename it as “Librarian Scenario”.
XIII. Now double click the Librarian Scenario use case diagram under the use case view
package (Double click  LMS Scenario  Drag and drop the actors and use cases
in the Use Case Diagram: Use case view / Librarian Scenario window.
XIV. Connect the actor with the use case through unidirectional associations.
XV. Draw as in the figure given below.

Use Case Diagrams:

Librarian Scenario

Purchase
Register

Lends
Reserve

Librarian1 User1

Update
Take

Reservation Return

3. Class Diagram
Procedure – Class Diagram
VIII. Right Click  Logical View  New  Class diagram.
IX. Rename it as Library System.
X. Double click  Library Processing  Drag and drop the class icon at the window.

40
 XI. While dropping there might be a chance of getting actor symbol at the window (To
Change it into class  Right Click  Open specification  Make the stereotype as
blank, so that you will see only the class).

XII. By selecting class  right click  new attributes and new operations according to the
figure given below.
XIII. Link all the classes by their associations.
XIV. Draw as in the figure given below.

41
 Class Diagram – Library Management System:

4. Activity Diagram

Procedure – Activity Diagram

V. Right Click  Logical View  New  Activity diagram.
VI. Rename it as Library.
VII. Double click  Library  Drag and drop the apt icons at the window.
VIII. Draw as in the figure given below.

42
Activity Diagram for Library Management System:

43
 5. Sequence Diagram
Procedure – Sequence Diagram
V. Right Click  Logical View  New  sequence diagram.
VI. Rename it as Library Process.
VII. Double click  Library Process  Drag and drop the apt icons at the window.
VIII. Draw as in the figure given below.

Sequence Diagram for Library Processing:

44
 6. Library scenario for Collaboration diagram
Note:
If you are using Rational Rose Enterprise Edition software, simply click the F5 key
on your keyboard to build a collaboration diagram. Other software requires that you
design the diagram below exactly or adjust it to meet your needs.

1.User id
2.Register
3.Receive
8.Return
User Librarian
7.Take

4.Valid 2.checks
5.Not 9.Update

Data base

7. Librarian scenario for Component diagram

Procedure – Component Diagram
V. Right Click  Component View  New  Component diagram.
VI. Rename it as LMS.
VII. Double click  LMS  Drag and drop the apt icons at the window.
VIII. Draw as in the figure given below.

45
 Borrow_books

8. LMS Scenario for Deployment Diagram

Procedure – Deployment Diagram
III. Double click  Deployment View.
IV. Draw as in the figure given below.

Book
registrat...

Provides

To Generate Code:
ix. Open the component diagram.

46
 x. Select the component individually  right click  open specification  Language
 ANSI C++.
xi. Similarly do all the components and set the language into ANSI C++.
xii. Select Realizes  Right click the class name User, Librarian etc  select assign.
xiii. Similarly do the same with all the components.
xiv. At the final stage select Main Program.
xv. Right Click  open specification  Language ANSI C++  Realizes  Assign.
xvi. Once realizes done  right the Main Program  ANSI C++  Generate Code.
(Select your path where to generate the code).

Sample Code:
#ifndef LIBRARY_H_HEADER_INCLUDED_993CE905
#define LIBRARY_H_HEADER_INCLUDED_993CE905

//##ModelId=66C357B1007F
Class Library
{
};

#endif /* LIBRARY_H_HEADER_INCLUDED_993CE905 */

Result:
The above program was successfully compiled, and codes were generated.

47
Experiment: 7

Design the Use case diagram, Class Diagram, Activity diagram, Sequence diagram,
Component diagram, Deployment Model for GU - SCSE.

School of Computer Science and Engineering (GU) system. We'll include the Use Case
Diagram, Class Diagram, Activity Diagram, Sequence Diagram, Component Diagram,
and Deployment Diagram.

1. Use Case Diagram

Actors:

 Student
 Faculty
 Administrator
 Registrar

Use Cases:

 Student:
o Register for Courses
o View Grades
o View Timetable
o Submit Assignments
o View Course Materials
 Faculty:
o Create/Update Course
o Grade Assignments
o Post Course Materials
o View Class Roster
 Administrator:
o Manage Student Records
o Manage Faculty Records
o Manage Course Catalog
o Generate Reports
 Registrar:
o Enroll Students in Courses
o Manage Timetable
o Issue Transcripts

Use Case Diagram:

sql
Copy code
+ +
| School of Computer Science and |
| Engineering System |
| |

48
| + + + + |
| | Student | | Faculty | |
| + + + + |
| | | | | |
| | + Register | | + Create/ | |
| | for Courses | | Update | |
| | + View Grades | | Course | |
| | + View Timetable| | + Grade | |
| | + Submit | | Assignments| |
| | Assignments | | + Post | |
| | + View Course | | Course | |
| | Materials | | Materials | |
| + + + + |
| |
| + + + + |
| | Administrator | | Registrar | |
| + + + + |
| | | | | |
| | + Manage | | + Enroll | |
| | Student | | Students | |
| | Records | | in Courses| |
| | + Manage | | + Manage | |
| | Faculty | | Timetable | |
| | Records | | + Issue | |
| | + Manage | | Transcripts| |
| | Course | | | |
| | Catalog | | | |
| | + Generate | | | |
| | Reports | | | |
| + + + + |
+ +

2. Class Diagram

Classes:

 Student
o Attributes: studentID, name, email, enrolledCourses
o Methods: registerCourse(), viewGrades(), viewTimetable(),
submitAssignment()
 Faculty
o Attributes: facultyID, name, email, coursesTaught
o Methods: createCourse(), gradeAssignment(), postMaterials(), viewRoster()
 Course
o Attributes: courseID, title, description, credits, schedule
o Methods: addMaterial(), updateCourse(), assignGrade()
 Administrator
o Attributes: adminID, name, email
o Methods: manageStudentRecords(), manageFacultyRecords(),
manageCourseCatalog(), generateReports()

49
  Registrar
o Attributes: registrarID, name, email
o Methods: enrollStudents(), manageTimetable(), issueTranscripts()
 Assignment
o Attributes: assignmentID, title, dueDate, courseID
o Methods: submit(), grade()

Class Diagram:

scss
Copy code
+ +
| Student |
+ +
| - studentID |
| - name |
| - email |
| - enrolledCourses|
+ +
| + registerCourse() |
| + viewGrades() |
| + viewTimetable() |
| + submitAssignment()|
+ +
|
|
v
+ +
| Course |
+ +
| - courseID |
| - title |
| - description |
| - credits |
| - schedule |
+ +
| + addMaterial() |
| + updateCourse() |
| + assignGrade() |
+ +
|
|
v
+ +
| Assignment |
+ +
| - assignmentID |
| - title |
| - dueDate |
| - courseID |

50
+ +
| + submit() |
| + grade() |
+ +
|
|
v
+ +
| Faculty |
+ +
| - facultyID |
| - name |
| - email |
| - coursesTaught |
+ +
| + createCourse() |
| + gradeAssignment()|
| + postMaterials() |
| + viewRoster() |
+ +
|
|
v
+ +
| Administrator |
+ +
| - adminID |
| - name |
| - email |
+ +
| + manageStudentRecords() |
| + manageFacultyRecords() |
| + manageCourseCatalog() |
| + generateReports() |
+ +
|
|
v
+ +
| Registrar |
+ +
| - registrarID |
| - name |
| - email |
+ +
| + enrollStudents() |
| + manageTimetable()|
| + issueTranscripts() |
+ +

51
3. Activity Diagram

Activity Diagram for Registering for a Course:

sql
Copy code
+ +
| Start |
+ +
|
v
+ +
| Login to System |
+ +
|
v
+ +
| Search Courses |
+ +
|
v
+ +
| Select Course |
+ +
|
v
+ +
| Check Availability|
+ +
|
v
+ +
| Register for Course|
+ +
|
v
+ +
| Confirmation |
+ +
|
v
+ +
| End |
+ +

4. Sequence Diagram

Sequence Diagram for Registering for a Course:

scss

52
Copy code
Student System Course Registrar
| | | |
| Login() | | |
|------------>| | |
| | | |
| SearchCourses() | | |
|------------>| | |
| | RetrieveCourses() | |
| |<------------ | |
| | | |
| SelectCourse() | | |
|------------>| | |
| | | |
| | CheckAvailability() | |
| |<------------ | |
| | | |
| RegisterForCourse() | | |
|------------>| | ProcessRegistration()|
| | |< ------------- |
| | | |
| | Confirmation()| |
|<------------ | | |
| | | |

5. Component Diagram

Components:

 User Interface (UI)

o Handles user interactions, login, and display
 Application Server
o Business logic for handling course registrations, grading, etc.
 Database
o Stores student records, course details, grades, etc.
 Authentication Service
o Manages user authentication and authorization

Component Diagram:

sql
Copy code
+ + + + + +
| User Interface |----->| Application |----->| Database |
| | | Server | | |
+ + + + + +
|
v
+ +
| Authentication Service |

53
 + +

6. Deployment Diagram

Nodes:

 Client Machine
o Hosts User Interface
 Application Server
o Hosts Application Server component and Authentication Service
 Database Server
o Hosts the Database

Deployment Diagram:

sql
Copy code
+ + + +
| Client Machine | | Application Server |
| | | |
|+ +| |+ +|
| | User || | | Application | |
| | Interface | | | | Server ||
|+ +| |+ +|
+-----------------+ | | Authentication | |
| | Service ||
|+ +|
+ +
|
v
+ +
| Database Server |
| |
|+ +|
| | Database | |
|+ +|
+ +

These diagrams provide a comprehensive overview of the School of Computer Science and
Engineering system, including its actors, components, and interactions. They cover the main
functionalities and show how different parts of the system work together.

54
Experiment: 8
To develop a Railway Reservation System that allows users to book, cancel, and manage
train reservations, enabling efficient and user-friendly railway service management

1. Use Case Diagram

Actors:
 Passenger
 Booking Agent
 Admin
 Train System
Use Cases:
 Passenger:
o Search Trains
o Book Ticket
o Cancel Booking
o View Booking History
o Modify Booking
 Booking Agent:
o Assist Booking
o Cancel Booking
o Modify Booking
o View Booking History
 Admin:
o Manage Train Schedules
o Manage Train Details
o Generate Reports
o Manage Users
 Train System:
o Validate Ticket
o Update Train Status
o Notify System of Changes
Use Case Diagram:
sql
Copy code

55
+ +
| Railway Reservation System |
| |
| + + + +|
| | Passenger | | Booking | |
| +-----------------+ | Agent | |
| | | +--------- + |
| | + Search Trains | | + Assist | |
| | + Book Ticket | | Booking | |
| | + Cancel Booking| | + Cancel | |
| | + View History | | Booking | |
| | + Modify Booking| | + Modify | |
| | | | Booking | |
| +-----------------+ | + View ||
| | History | |
| + + + +|
| | Admin | |
| + ---------------- + |
| | | |
| | + Manage Train | |
| | Schedules | |
| | + Manage Train | |
| | Details | |
| | + Generate | |
| | Reports | |
| | + Manage Users | |
| + ---------------- + |
| |
| + ---------------- + |
| | Train System | |
| + ---------------- + |
| | | |
| | + Validate Ticket| |
| | + Update Train | |

56
| | Status | |
| | + Notify System | |
| | of Changes | |
| +-----------------+ |
+ +
2. Class Diagram
Classes:
 Passenger
o Attributes: passengerID, name, email, phone
o Methods: searchTrains(), bookTicket(), cancelBooking(),
viewBookingHistory(), modifyBooking()
 Booking Agent
o Attributes: agentID, name, email
o Methods: assistBooking(), cancelBooking(), modifyBooking(),
viewBookingHistory()
 Admin
o Attributes: adminID, name, email
o Methods: manageTrainSchedules(), manageTrainDetails(), generateReports(),
manageUsers()
 Train
o Attributes: trainID, trainNumber, route, schedule, seatsAvailable
o Methods: updateStatus(), getTrainDetails()
 Booking
o Attributes: bookingID, passengerID, trainID, bookingDate, status
o Methods: createBooking(), cancelBooking(), modifyBooking()
 Schedule
o Attributes: scheduleID, trainID, departureTime, arrivalTime, source,
destination
o Methods: updateSchedule()
 Ticket
o Attributes: ticketID, bookingID, seatNumber, issueDate
o Methods: validateTicket()
Class Diagram:
scss

57
Copy code
+ +
| Passenger |
+ +
| - passengerID |
| - name |
| - email |
| - phone |
+ +
| + searchTrains() |
| + bookTicket() |
| + cancelBooking()|
| + viewBookingHistory() |
| + modifyBooking() |
+ +
|
|
v
+ +
| Booking |
+ +
| - bookingID |
| - passengerID |
| - trainID |
| - bookingDate |
| - status |
+ +
| + createBooking()|
| + cancelBooking()|
| + modifyBooking()|
+ +
|
|
v

58
+ +
| Train |
+ +
| - trainID |
| - trainNumber |
| - route |
| - schedule |
| - seatsAvailable |
+ +
| + updateStatus() |
| + getTrainDetails() |
+ +
|
|
v
+ +
| Schedule |
+ +
| - scheduleID |
| - trainID |
| - departureTime |
| - arrivalTime |
| - source |
| - destination |
+ +
| + updateSchedule() |
+ +
|
|
v
+ +
| Ticket |
+ +
| - ticketID |

59
| - bookingID |
| - seatNumber |
| - issueDate |
+ +
| + validateTicket() |
+ +
|
|
v
+ +
| Booking Agent |
+ +
| - agentID |
| - name |
| - email |
+ +
| + assistBooking()|
| + cancelBooking()|
| + modifyBooking()|
| + viewBookingHistory() |
+ +
|
|
v
+ +
| Admin |
+ +
| - adminID |
| - name |
| - email |
+ +
| + manageTrainSchedules() |
| + manageTrainDetails() |
| + generateReports() |

60
| + manageUsers() |
+ +
3. Activity Diagram
Activity Diagram for Booking a Ticket:
sql
Copy code
+ +
| Start |
+ +
|
v
+ +
| Search Trains |
+ +
|
v
+ +
| Select Train and |
| Enter Details |
+ +
|
v
+ +
| Check Seat |
| Availability |
+ +
|
v
+ +
| Confirm Booking |
+ +
|
v
+ +

61
| Payment Process |
+ +
|
v
+ +
| Generate Ticket |
+ +
|
v
+ +
| End |
+ +
4. Sequence Diagram
Sequence Diagram for Booking a Ticket:
scss
Copy code
Passenger System Train Booking
| | | |
| SearchTrains()| | |
|-------------->| | |
| | RetrieveTrainDetails() |
| |------------>| |
| | | |
| | | TrainDetails() |
| |<------------| |
| | | |
| SelectTrain() | | |
|-------------->| | |
| | | |
| | CheckAvailability() |
| |------------>| |
| | | Availability() |
| |<------------| |
| | | |

62
 | ConfirmBooking() | | |
|-------------->| | |
| | | |
| | CreateBooking() | |
| |----------- >| |
| | | |
| | | BookingCreated() |
| |<------------| |
| | | |
| GenerateTicket() | | |
|-------------->| | |
| | | |
| | GenerateTicket() | |
| |----------- >| |
| | | TicketGenerated() |
| |<------------| |
| | | |
5. Component Diagram
Components:
 User Interface (UI)
o Handles user interactions, booking forms, and ticket generation
 Application Server
o Business logic for booking, cancellations, and updates
 Train Management Service
o Manages train schedules, seat availability, and status updates
 Database
o Stores passenger details, bookings, train schedules, and tickets
Component Diagram:
sql
Copy code
+ + + + + +
| User Interface |----->| Application Server|----->| Train |
| | | | | Management |
| | | | | Service |

63
+ + + + + +
|
v
+ +
| Database |
+ +
6. Deployment Diagram
Nodes:
 Client Machine
o Hosts the User Interface
 Application Server
o Hosts the Application Server and Train Management Service
 Database Server
o Hosts the Database
Deployment Diagram:
sql
Copy code
+ + + +
| Client Machine | | Application Server |
| | | |
|+ +| |+ +|
| | User || | | Application ||
| | Interface | | | | Server ||
|+ +| |+ +|
+ + |+ +|
| | Train Management|
| | Service |
|+ +|
|
v
+ +
| Database Server |
| |
|+ +|

64
 | | Database ||
|+ +|
+ +
These diagrams provide a detailed view of the Railway Reservation System, capturing user
interactions, system components, and deployment strategies. They help in understanding how
the system works and how different parts interact with each other.

65
Experiment: 9
To develop an Expert System for prescribing medicines based on given symptoms,
enabling Remote Diagnostics and Patient/Hospital Management.

1. Use Case Diagram

Actors:
 Patient
 Doctor
 Administrator
 Remote Diagnostic System
Use Cases:
 Patient:
o Submit Symptoms
o View Prescriptions
o Update Personal Information
o Request Remote Consultation
 Doctor:
o Review Symptoms
o Diagnose Condition
o Prescribe Medication
o View Patient History
o Consult with Remote Diagnostics
 Administrator:
o Manage User Accounts
o Manage Medicine Database
o Generate Reports
o Oversee System Operations
 Remote Diagnostic System:
o Analyze Symptoms
o Recommend Initial Diagnosis
o Validate Prescriptions
Use Case Diagram:
sql
Copy code

66
+ +
| Expert System for |
| Prescribing Medicines |
| Based on Symptoms |
| |
| + + + + |
| | Patient | | Doctor | |
| + + + + |
| | | | | |
| | + Submit | | + Review | |
| | Symptoms | | Symptoms | |
| | + View | | + Diagnose | |
| | Prescriptions| | Condition | |
| | + Update | | + Prescribe | |
| | Information | | Medication| |
| | + Request | | + View | |
| | Remote | | Patient | |
| | Consultation | | History | |
| +----------------+ | + Consult | |
| | with | |
| +----------------+ | Remote | |
| | Administrator | | Diagnostics | |
| + + + + |
| | | |
| | + Manage | |
| | User Accounts| |
| | + Manage | |
| | Medicine | |
| | Database | |
| | + Generate | |
| | Reports | |
| | + Oversee | |
| | System | |
| | Operations | |

67
| +----------------+ |
| |
| +----------------+ |
| | Remote Diagnostic | |
| | System | |
| +----------------+ |
| | | |
| | + Analyze | |
| | Symptoms | |
| | + Recommend | |
| | Initial | |
| | Diagnosis | |
| | + Validate | |
| | Prescriptions| |
| +----------------+ |
+ +
2. Class Diagram
Classes:
 Patient
o Attributes: patientID, name, symptoms, medicalHistory, contactInformation
o Methods: submitSymptoms(), viewPrescriptions(), updateInformation(),
requestRemoteConsultation()
 Doctor
o Attributes: doctorID, name, specialty, contactInformation
o Methods: reviewSymptoms(), diagnoseCondition(), prescribeMedication(),
viewPatientHistory(), consultRemoteDiagnostics()
 Administrator
o Attributes: adminID, name, contactInformation
o Methods: manageUserAccounts(), manageMedicineDatabase(),
generateReports(), overseeSystemOperations()
 Symptom
o Attributes: symptomID, description, severity
o Methods: getDescription(), getSeverity()
 Diagnosis

68
 o Attributes: diagnosisID, condition, recommendedTreatment
o Methods: getCondition(), getRecommendedTreatment()
 Medication
o Attributes: medicineID, name, dosage, sideEffects
o Methods: getDosage(), getSideEffects()
 Prescription
o Attributes: prescriptionID, patientID, medicationID, issueDate
o Methods: createPrescription(), updatePrescription()
 RemoteDiagnosticSystem
o Attributes: systemID, analysisAlgorithm
o Methods: analyzeSymptoms(), recommendDiagnosis(), validatePrescriptions()
Class Diagram:
scss
Copy code
+ +
| Patient |
+ +
| - patientID |
| - name |
| - symptoms |
| - medicalHistory |
| - contactInfo |
+ +
| + submitSymptoms() |
| + viewPrescriptions()|
| + updateInformation() |
| + requestRemoteConsultation() |
+ +
|
|
v
+ +
| Symptom |

+ +

69
| - symptomID |
| - description |
| - severity |
+ +
| + getDescription()|
| + getSeverity() |
+ +
|
|
v
+ +
| Diagnosis |
+ +
| - diagnosisID |
| - condition |
| - recommendedTreatment |
+ +
| + getCondition() |
| + getRecommendedTreatment() |
+ +
|
|
v
+ +
| Medication |
+ +
| - medicineID |
| - name |
| - dosage |
| - sideEffects |
+ +
| + getDosage() |
| + getSideEffects() |
+ +

70
 |
|
v
+ +
| Prescription |
+ +
| - prescriptionID |
| - patientID |
| - medicationID |
| - issueDate |
+ +
| + createPrescription() |
| + updatePrescription() |
+ +
|
|
v
+ +
| Doctor |
+ +
| - doctorID |
| - name |
| - specialty |
| - contactInfo |
+ +
| + reviewSymptoms() |
| + diagnoseCondition()|
| + prescribeMedication()|
| + viewPatientHistory() |
| + consultRemoteDiagnostics() |
+ +
|
|
v

71
+ +
| Administrator |
+ +
| - adminID |
| - name |
| - contactInfo |
+ +
| + manageUserAccounts() |
| + manageMedicineDatabase()|
| + generateReports() |
| + overseeSystemOperations() |
+ +
|
|
v
+ +
| RemoteDiagnosticSystem |
+ +
| - systemID |
| - analysisAlgorithm |
+ +
| + analyzeSymptoms() |
| + recommendDiagnosis() |
| + validatePrescriptions() |
+ +
3. Activity Diagram
Activity Diagram for Prescribing Medication:
sql
Copy code
+ +
| Start |
+ +
|
v

72
+ +
| Submit Symptoms |
+ +
|
v
+ +
| Analyze Symptoms |
+ +
|
v
+ +
| Diagnose Condition|
+ +
|
v
+ +
| Recommend |
| Medication |
+ +
|
v
+ +
| Generate Prescription |
+ +
|
v
+ +
| Notify Patient |
+ +
|
v
+ +
| End |
+ +

73
4. Sequence Diagram
Sequence Diagram for Prescribing Medication:
scss
Copy code
Patient System RemoteDiagnosticSystem Doctor
| | | |
| SubmitSymptoms()| | |
|---------------> | | |
| | AnalyzeSymptoms()| |
| |---------------->| |
| | | Analyze() |
| | |<--------------- |
| | DiagnoseCondition()| |
| |---------------->| |
| | | Diagnose() |
| | |<--------------- |
| | RecommendMedication()| |
| |---------------->| |
| | | Recommend() |
| | |<--------------- |
| | GeneratePrescription()| |
| |---------------->| |
| | | Generate() |
| | |<--------------- |
| | NotifyPatient() | |
| |<---------------- | |
| | | |
5. Component Diagram
Components:
 User Interface (UI)
o Handles interactions with the patient and doctor, including symptom
submission and prescription viewing
 Expert System Engine
o Processes symptoms, diagnoses conditions, and recommends treatments

74
  Remote Diagnostic Service
o Analyzes symptoms and provides initial diagnosis
 Database
o Stores patient records, medical history, medications, and prescriptions
Component Diagram:
sql
Copy code
+ + + + + +
| User Interface |----->| Expert System Engine |----->| Database |
| | | | | |
| | | +-----------------+ | | + ------------- + |
| | | | Symptom || | | Patient ||
| | | | Diagnosis || | | MedicalData | |
| | | | Medication || | | Prescriptions| |
| | | + ---------------- + | | + ------------- + |
+ + + + + +
|
v
+ +
| Remote Diagnostic Service|
| |
|+ +|
| | Analyze Symptoms ||
| | Recommend Diagnosis | |
| | Validate Prescriptions | |
|+ +|
+ +
6. Deployment Diagram
Nodes:
 Client Device
o Hosts the User Interface
 Application Server
o Hosts the Expert System Engine and Remote Diagnostic Service
 Database Server

75
 o Hosts the Database
Deployment Diagram:
sql
Copy code
+ + + +
| Client Device | | Application Server |
| | | |
|+ +| |+ +|
| | User || | | Expert System ||
| | Interface || | | Engine ||
|+ +| |+ +|
+ + |+ +|
| | Remote Diagnostic | |
| | Service ||
|+ +|
|
v
+ +
| Database Server |
| |
|+ +|
| | Database ||
|+ +|
+ +
These diagrams provide a structured overview of the Expert System, including user
interactions, system components, and deployment strategies. They are essential for
understanding the system's architecture and ensuring that all functionalities are well
integrated.

76
Experiment: 10
To develop a test case for unit testing by using JUnit Tool.

Aim:
The aim of developing a test case for unit testing is to ensure that individual components of a
software application function correctly and reliably. Key objectives include:
1. Verify Functionality: Confirm that each unit of code behaves as expected.
2. Identify Bugs Early: Detect and fix defects before they propagate to later stages.
3. Facilitate Refactoring: Ensure that code changes do not break existing functionality.
4. Improve Code Quality: Encourage better design practices and maintainability.
5. Enhance Documentation: Provide clear examples of how code is expected to behave.
6. Support Continuous Integration: Automate testing to maintain code stability.
7. Increase Confidence: Boost trust in the reliability of the software system.

Tool Download
 IntelliJ IDEA
https://www.jetbrains.com/idea/download/?section=windows

Procedure:
A. Open a new Project.
B. Select Java  name as Junittesting  click gradle  Groovy click create
button.
C. Under your project  click buildgradle  copy and paste only the dependency under
parenthesis.
D. Right-click on the src/main/java directory, select "New" > "Java Class", and name it
(e.g., Calculator.java):
public class Calculator {
public int add(int a, int b) {
return a + b;
}
}
E. Right-click on the src/test/java directory, select "New" > "Java Class", and name it
(e.g., CalculatorTest.java):
import static org.junit.jupiter.api.Assertions.assertEquals;

77
 import org.junit.jupiter.api.Test;

public class CalculatorTest {

@Test
public void testAddition() {
Calculator calculator = new Calculator();
assertEquals(5, calculator.add(2, 3));
}
}
F. Run the Tests:
Right-click on the test class (CalculatorTest.java) in the Project Explorer.
Select "Run 'CalculatorTest'" or use the green arrow icon in the gutter next to the test
method.
G. View Test Results:
After running the tests, the results will appear in the Run window at the bottom. You
can see which tests passed or failed.
Sample Output:

Note: Test was passed

78
Note: Test was failed

JUnit Overview
JUnit is a widely used testing framework for Java applications. It provides annotations,
assertions, and test runners to facilitate the creation and execution of unit tests, ensuring that
individual parts of the code (units) function correctly.
Key Features
1. Annotations: JUnit uses annotations to define test methods and manage test execution:
o @Test: Marks a method as a test case.
o @Before: Runs before each test method, often used for setup.
o @After: Runs after each test method, often used for cleanup.
o @BeforeClass and @AfterClass: Run once before and after all tests in a class.
2. Assertions: JUnit provides a variety of assertion methods to check expected outcomes:
o assertEquals(expected, actual): Checks if two values are equal.
o assertTrue(condition): Checks if a condition is true.
o assertFalse(condition): Checks if a condition is false.
o assertNull(object): Checks if an object is null.
o assertNotNull(object): Checks if an object is not null.
3. Test Runners: JUnit provides different test runners to execute tests. The most common
one is the JUnitCore class, which runs tests and outputs results.
4. Parameterized Tests: Allows running the same test with different input values.

79
 5. Integration with Build Tools: JUnit easily integrates with build tools like Maven and
Gradle, making it straightforward to automate testing.

Assertion:
An assertion is a statement in the Java programming language that enables you to test your
assumptions about your program. For example, if you write a method that calculates the speed
of a particle, you might assert that the calculated speed is less than the speed of light. Each
assertion contains a boolean expression that you believe will be true when the assertion
executes. If it is not true, the system will throw an error. By verifying that the boolean
expression is indeed true, the assertion confirms your assumptions about the behavior of your
program, increasing your confidence that the program is free of errors. Experience has shown
that writing assertions while programming is one of the quickest and most effective ways to
detect and correct bugs. As an added benefit, assertions serve to document the inner workings
of your program, enhancing maintainability.

Result:
The experiment successfully generated assertions that validate the user’s assumptions,
confirming the expected behavior of individual components. This process in IntelliJ IDEA
ensured that each unit of code functioned correctly in isolation, contributing to overall software
quality.

80
Experiment No: 11
To develop a test case for Integration testing by using JUnit Tool.

Aim:
The aim of developing a test case for integration testing is to verify that multiple components
of a software application work together as intended. This includes ensuring that:
1. Correct Interaction: Validate the interactions between integrated units (e.g., services,
databases) to confirm they collaborate properly.
2. Data Flow: Ensure data is correctly passed between components without errors.
3. System Behavior: Check that the system behaves as expected when components are
integrated, identifying any interface issues.
4. Identify Integration Issues: Detect problems arising from the integration of different
modules early in the development cycle.

Tool Download
 IntelliJ IDEA
https://www.jetbrains.com/idea/download/?section=windows

Procedure:
A. Open a new Project.
B. Select Java  name as Junittesting  click gradle  Groovy click create
button.
C. Under your project  click buildgradle  copy and paste only the dependencies.
(Fully)
plugins {
id 'java'
}

group 'com.example'
version '1.0-SNAPSHOT'

repositories {
mavenCentral()
}

81
 dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter:5.8.1'
}

test {
useJUnitPlatform()
}

Sync Gradle:
Click on the Refresh icon in the Gradle tool window to sync the dependencies.

D. Create Application Classes

Create the Package Structure:
o Under src/main/java, create a package (e.g., com.example).
o Inside this package, create the following classes  name as 
CalculatorRepository.

package com.example;

public class CalculatorRepository {

public String getData() {
return "Sample Data";
}
}

o Inside this package, create the another class  name as  CalculatorService.

package com.example;

public class CalculatorService {

private final CalculatorRepository repository;

82
 public CalculatorService(CalculatorRepository
repository) {
this.repository = repository;
}

public int add(int a, int b) {

return a + b;
}

public String fetchData() {

return repository.getData();
}
}
E. Create Integration Test Class
Create the Test Package:
Under src/test/java, create the same package structure (e.g., com.example).
Create the Integration Test Class:
Inside this package, create the class  name as  CalculatorServiceIntegrationTest.
package com.example;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

public class CalculatorServiceIntegrationTest {

private CalculatorService calculatorService;

@BeforeEach
public void setUp() {
CalculatorRepository repository = new CalculatorRepository();
calculatorService = new CalculatorService(repository);
}

83
 @Test
public void testAdd() {
assertEquals(5, calculatorService.add(2, 3));
}

@Test
public void testFetchData() {
assertEquals("Sample Data", calculatorService.fetchData());
}
}

F. Run the Integration Tests

Using IntelliJ IDEA:
o Right-click on the CalculatorServiceIntegrationTest.java file.
o Select Run 'CalculatorServiceIntegrationTest'.

Sample Output:

Note: Test was passed

84
Note: Test was failed

Result:
The experiment successfully generated assertions that validate the user’s assumptions,
confirming the correct functionality of integrated components. This process in IntelliJ IDEA
ensured that all interactions between modules behaved as expected, enhancing overall software
reliability.

85
Experiment 12
Test Case Name : Boundary Value Analysis for triangle problem

Design and develop a program in a Java language to solve the triangle problem defined as
follows. Accept three integers which are supposed to be the three sides of a triangle and
determine the three values represent an equilateral triangle, isosceles triangle, and scalene
triangle or they do not form a triangle at all. Assume that the upper limit for the size of any side
is 10. Derive test cases for your program based on boundary value analysis, and execute the
test cases and discuss the results.

Source Code:
import java.util.Scanner;

public class triangle_BVA {

public static void main(String[] args) {
int t=0;
System.out.println("Enter 3 integers which are sides of triangle\n");
Scanner in = new Scanner(System.in);
int a = in.nextInt();
int b = in.nextInt();
int c = in.nextInt();
in.close();

if(a<0 || a>10)
{
System.out.println("a is out of range");
t=1;
}
if(b<0 || b>10)
{
System.out.println("b is out of range");

86
 t=1;
}
if(c<0 || c>10)
{
System.out.println("c is out of range");
t=1;
}
if(!(t==1))
{
if(a<b+c && b<a+c && c<a+b)
{
System.out.println("triangle can be formed\n");
if((a==b)&&(b==c))
System.out.println("Equilateral triangle");
else if((a!=b)&&(a!=c)&&(b!=c))
System.out.println("Scalene triangle");
else
System.out.println("Isosceles triangle");
}
else

System.out.println("triangle cannot be formed");

}
else
return;
}
}

Sample Output

87
Test Case Name : Boundary Value Analysis for triangle problem
Experiment Number 12
Test Data : Enter the 3 integer value (a, b and c)

Pre-condition: 1 ≤ a ≤ 10, 1 ≤ b ≤ 10 and 1 ≤ c ≤ 10 and a < b + c, b < a + c and

c <a + b

Brief Description: Check whether given value for an Equilateral, Isosceles, Scalene
triangle or can't from a triangle.

Min Min + 1 Normal Max-1 Max

a 1 2 5 9 10
b 1 2 5 9 10
c 1 2 5 9 10

Triangle Problem – Boundary Value Test Case for Input Data

Case Description Input Data Expected Output Actu Status
ID a b c al
Outp
ut
1 Enter the normal value for a, 5 5 1 Should display the message
b and c min value for c Isosceles triangle
2 Enter the normal value for a, 5 5 2 Should display the message
b and min + 1 value for c Isosceles triangle
3 Enter the normal value for a, 5 5 5 Should display the message
b and c Equilateral triangle

88
 4 Enter the normal value for a, 5 5 9 Should display the message
b and max – 1 value for c Isosceles triangle
5 Enter the normal value for a, 5 5 10 Should display the message
b and max value for c Not a triangle
6 Enter the normal value for a 5 1 5 Should display the message
, c and min value for b Isosceles triangle
7 Enter the normal value for a, 5 2 5 Should display the message
c and min + 1 for b Isosceles triangle
8 Enter the normal value for a 5 9 5 Should display the message
, c and max – 1 value for b Isosceles triangle
9 Enter the normal value for a, 5 10 5 Should display the message
c and max value for b Not a triangle
10 Enter the normal value for 1 5 5 Should display the message
b, c and min value for a Isosceles triangle
11 Enter the normal value for 2 5 5 Should display the message
b, c and min + 1 value for a Isosceles triangle
12 Enter the normal value for 9 5 5 Should display the message
b, c and max – 1 for a Isosceles triangle
13 Enter the normal value for 10 5 5 Should display the message
b, c and max value for a Not a triangle
14 Enter the value for a, b, c 2 3 4 Should display the message
Scalene triangle

Note:
After executing the Java program, record the "Actual Output and Status" of your test
cases.

89