Software Engineering & Testing Methodologies Lab (CSP 357)

Software Engineering Lab File

B. TECH 3rd YEAR

SEMESTER: 5th
SESSION: 2024-2025

Submitted By:
Mohd Tabish
2022486143
Section-C (G2)

Submitted To:
Saurabhi Chaudhary
Assistant Professor
Computer Science and Engineering Department

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

SHARDA SCHOOL OF ENGINEERING & TECHNOLOGY
SHARDA UNIVERSITY, GREATER NOIDA
 SCHOOL OF ENGINEERING & TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

COURSE COURSE TITLE L T P C

CODE Software Engineering & Testing
Methodologies 0 0 2 1
CSP 357
CO1: Examine the need of developing software solutions CO2:
Understanding the modelling language (UML)
CO3: Adapt techniques and tools necessary for software testing practices. CO4:
Prepare test plans and cases for different applications.
CO5: To develop skills in software test automation and management using the latest tools
CO6: Design test plan for an application and test the software for performance measuring using
automated testing tools

LIST OF EXPERIMENTS
S. COURSE
EXPERIMENT NAME OUTCOME Date Signature
NO.
Design requirement analysis and develop Software
1 Requirement Specification Sheet (SRS) for CO1
suggested systems in IEEE standard.
Draw the user's view analysis for the suggested
2 system: Usecase diagram, Activity Diagram and CO2
State chart Diagram.
Draw the structural view diagram for the system:
3 Class diagram, object diagram and Sequence CO2
diagram
Perform Unit testing of calculator program
4 CO3
using Junit testing framework.
Perform Integration testing of calculator
5 CO3
program using Junit testing framework
Design Test Case for Inventory Management
6 CO4
System based on System Specification
Design Test cases and perform manual testing of
7 CO5
the module of Flipkart (as an example)
 Experiment No – 1

Design requirement analysis and develop Software Requirement Specification Sheet

(SRS) for suggested systems in IEEE standard.

SyntaxLab: Coding and

Educational Platform
Version 1.0 approved

Prepared by : Mohd Tabish Mahmood

System ID : 2022486143
Sharda University : School of Engineering and Technology
Table of Contents

1. Introduction .......................................................................................................................... 3
1.1 Problem Definition ......................................................................................................... 3
1.2 Purpose ............................................................................................................................ 3
1.3 Product Scope ................................................................................................................. 3
2. Overall Description .............................................................................................................. 3
2.1 Product Perspective........................................................................................................ 3
2.2 Product Functions .......................................................................................................... 4
2.3 User Classes and Characteristics .................................................................................. 4
2.4 Operating Environment................................................................................................. 4
2.5 Design and Implementation Constraints ..................................................................... 5
2.6 User Documentation ....................................................................................................... 5
2.7 Assumptions and Dependencies .................................................................................... 5
3. External Interface Requirements ....................................................................................... 5
3.1 User Interfaces ................................................................................................................ 6
3.2 Hardware Interfaces ...................................................................................................... 6
3.3 Software Interfaces ........................................................................................................ 6
3.4 Communications Interfaces ........................................................................................... 6
4. Functional Requirements .................................................................................................... 6
4.1 User Requirements ......................................................................................................... 6
4.2 System Requirements ..................................................................................................... 7
5. Nonfunctional Requirements .............................................................................................. 7
5.1 Performance Requirements ........................................................................................... 7
5.2 Safety Requirements ...................................................................................................... 8
5.3 Security Requirements................................................................................................... 8
5.4 Software Quality Attributes .......................................................................................... 8
6. Conclusion ............................................................................................................................ 8
Appendix: Glossary ................................................................................................................. 8
References ................................................................................................................................. 9
1. Introduction

1.1 Problem Definition

Current platforms for coding profile management lack the ability to aggregate data from
multiple coding sites and integrate with educational institutions for course and assignment
management. This creates a fragmented experience for students and educators, making it
difficult to track progress and manage coursework efficiently. Additionally, the existing
solutions do not provide sufficient tools for educators to monitor student performance and
engagement, leading to a gap in effective learning and teaching strategies.

1.2 Purpose

The purpose of Codetracker is to provide a unified platform for Computer Science Engineers
to manage their coding profiles, track their progress, complete courses, and share their
achievements. It will also allow educational institutions to create and manage courses,
assignments, and lectures, enhancing the learning experience. By centralizing this information,
Codetracker aims to streamline the educational process, improve student engagement, and
facilitate better performance tracking for both students and educators.

1.3 Product Scope

Codetracker aims to:

● Aggregate coding profile data from various platforms.
● Display user data attractively and create shareable profile cards.
● Integrate with educational institutions for assignment, lecture, and course management.
● Provide built-in courses for students to complete and manage their streaks.
● Offer analytics and reporting tools.
● Support collaboration features for group assignments and peer reviews.
● Provide a feedback system for educators and students to communicate effectively.

2. Overall Description

2.1 Product Perspective

Codetracker is a web-based application designed to aggregate and display coding profile data.
It will integrate with various coding platforms and educational institutions, providing a
comprehensive solution for students and educators. The platform will serve as a central hub
for all coding-related activities, enabling users to seamlessly transition between learning,
practicing, and showcasing their coding skills.

2.2 Product Functions

● Profile Aggregation: Collect and display data from multiple coding platforms such as
GitHub, LeetCode, and HackerRank.
● Dashboard: Provide a user-friendly dashboard to track progress, view statistics, and
manage profiles.
● Profile Cards: Generate shareable profile cards showcasing user achievements.
● Course Management: Allow educators to create and manage courses, assignments, and
lectures.
● Built-in Courses: Offer pre-designed courses for students to enhance their skills.
● Streak Management: Enable students to track and manage their coding streaks.
● Analytics and Reporting: Provide tools for analyzing performance and generating
reports.
● Collaboration Tools: Support group assignments, peer reviews, and feedback
mechanisms.

2.3 User Classes and Characteristics

● Students: Typically computer science students or coding enthusiasts who want to

manage their coding profiles and track their progress. They will have varying levels of
coding proficiency and will use the platform to complete courses and share their
achievements.
● Educators: Professors, lecturers, or instructors at educational institutions who need to
manage student profiles, create courses, assign tasks, and track student progress. They
will have access to advanced features for course and student management.
● Administrators: Individuals responsible for overseeing the platform's overall usage,
managing user access, ensuring data integrity, and maintaining system performance.
They will have the highest level of access and control over the platform's features and
settings.

2.4 Operating Environment

● Web-Based Application: Accessible via modern web browsers (Chrome, Firefox,

Safari, Edge) on both desktop and mobile devices.
 ● Cloud Hosting: Hosted on reliable cloud services (AWS, Azure, or similar) to ensure
scalability, availability, and security.
● APIs: Integration with various coding platforms and educational institution systems
through APIs for seamless data exchange.

2.5 Design and Implementation Constraints

● Data Privacy: Must adhere to data privacy regulations (e.g., GDPR) to protect user
information.
● API Compatibility: Ensure compatibility with major coding platforms' APIs for data
aggregation.
● Scalability: Design a scalable architecture to handle a large number of users and data.
● User Interface: Create an intuitive and responsive user interface to enhance user
experience.

2.6 User Documentation

User documentation will include:

● User Guides: Detailed guides for students, educators, and administrators on how to use
the platform.
● Tutorials: Step-by-step tutorials covering common tasks and features.
● FAQs: Frequently asked questions to address common queries and issues.
● Support: Contact information and support resources for troubleshooting and assistance.
2.7 Assumptions and Dependencies

● Stable APIs: Coding platforms will provide stable and accessible APIs for data
integration.
● Internet Access: Educational institutions and users will have reliable internet access
and compatible devices.
● Basic Knowledge: Users will have basic knowledge of web navigation and coding
platforms to use the platform effectively.

3. External Interface Requirements

3.1 User Interfaces

● Intuitive UI: Design an intuitive and user-friendly interface that provides easy
navigation and accessibility.
● Responsive Design: Ensure the platform is responsive and works well on both desktop
and mobile devices.
● Dashboard: Provide a comprehensive dashboard for students, educators, and
administrators to manage their profiles, courses, and assignments.
● Profile Management: Create interfaces for profile creation, management, and sharing.

3.2 Hardware Interfaces

● Compatibility: Ensure compatibility with a wide range of desktop and mobile devices.
● No Special Hardware: No special hardware requirements beyond standard computing
devices with internet access.

3.3 Software Interfaces

● Coding Platform APIs: Integrate with APIs from coding platforms such as GitHub,
LeetCode, and HackerRank for data aggregation.
● Educational Systems: Integrate with educational institution systems (LMS, etc.) for
course and student management.
● Authentication: Use OAuth for secure authentication and user management.

3.4 Communications Interfaces

● HTTPS: Ensure all data transmission is secure using HTTPS protocols.

● APIs: Provide well-documented APIs for integration with external systems.
● Notifications: Implement email and in-app notifications for important updates and
alerts.

4. Functional Requirements

4.1 User Requirements

 ● Account Creation: Users can create an account using email or OAuth authentication.
● Profile Submission: Users can submit usernames from supported coding platforms.
● Data Aggregation: The system will fetch and display aggregated data from multiple
coding platforms.
● Profile Sharing: Users can create and share profile cards showcasing their
achievements.
● Course Enrollment: Students can enroll in and complete built-in courses.
● Streak Management: Students can track and manage their coding streaks.
● Course Creation: Educators can create and manage courses, assignments, and lectures.
● Progress Tracking: Educators can track student progress and performance.
● Analytics and Reporting: Provide tools for generating performance analytics and
reports.

4.2 System Requirements

● Data Fetching: The system must fetch and update user data from coding platforms
regularly.
● Responsive Dashboard: Provide an intuitive and responsive dashboard for all user
classes.
● Course Management: Allow educators to create, manage, and assign courses,
assignments, and lectures.
● Analytics Tools: Provide tools for analyzing performance and generating reports.
● Data Privacy: Ensure data privacy and security through encryption and compliance
with regulations.
● Scalability: Design a scalable architecture to handle a large number of users and data.

5. Nonfunctional Requirements
5.1 Performance Requirements

● Concurrency: The system should handle up to 10,000 concurrent users without

performance degradation.
● Data Updates: Data updates should occur within 5 minutes of submission to ensure
timely information.
5.2 Safety Requirements

● Data Backup: Ensure data backup and recovery procedures are in place to prevent data
loss.
● Error Handling: Implement robust error handling and logging mechanisms to address
and resolve issues promptly.

5.3 Security Requirements

● Access Control: Implement role-based access control to manage user permissions and
access levels.
● Data Encryption: Encrypt sensitive data both in transit and at rest to protect user
information.
● Regular Audits: Conduct regular security audits and vulnerability assessments to
maintain system security.

5.4 Software Quality Attributes

● Usability: Ensure the platform is intuitive, user-friendly, and easy to navigate for all
user classes.
● Reliability: Design the system to be highly available and minimize downtime through
robust architecture.
● Scalability: Ensure the platform can scale with increasing users and data without
compromising performance.
● Maintainability: Design the system to be maintainable and updatable with minimal
disruption to users.

6. Conclusion

Codetracker aims to provide a comprehensive solution for coding profile management and
educational integration, enhancing the learning experience for students and simplifying
management tasks for educators. By centralizing coding profile data and integrating with
educational systems, Codetracker will streamline the process of tracking progress, managing
courses, and sharing achievements.

Appendix: Glossary
 ● API (Application Programming Interface): A set of functions and procedures
allowing the creation of applications that access the features or data of an operating
system, application, or other service.
● OAuth (Open Authorization): An open standard for access delegation commonly used
as a way to grant websites or applications limited access to users’ information without
exposing passwords.
● GDPR (General Data Protection Regulation): A regulation in EU law on data
protection and privacy in the European Union and the European Economic Area.
● LMS (Learning Management System): A software application for the administration,
documentation, tracking, reporting, automation, and delivery of educational courses,
training programs, or learning and development programs.

References

1. GitHub. (2024). GitHub REST API v3 Documentation. Retrieved from

https://docs.github.com/en/rest
2. LeetCode. (2024). LeetCode API Documentation. Retrieved from
https://leetcode.com/api
3. HackerRank. (2024). HackerRank API Documentation. Retrieved from
https://www.hackerrank.com/api
4. Hardt, D. (2012). The OAuth 2.0 Authorization Framework. IETF. Retrieved from
https://datatracker.ietf.org/doc/html/rfc6749
5. Amazon Web Services. (2024). AWS Documentation. Retrieved from
https://aws.amazon.com/documentation/
6. Moodle. (2024). Moodle LMS Documentation. Retrieved from https://docs.moodle.org
7. W3C. (2018). Web Content Accessibility Guidelines (WCAG) 2.1. Retrieved from
https://www.w3.org/TR/WCAG21/
 Experiment No – 2
Draw the user’s view analysis for suggested systems: Use case diagram, Activity diagram
and state chart diagram
1. Use Case Diagram-
A Use Case Diagram is a type of diagram in the Unified Modeling Language (UML) that visually represents
the functional requirements of a system. It shows the interactions between various actors (users or other
systems) and the system itself, outlining what the system does (its use cases) without detailing how it does it.

Use Case Diagram Notations:

1. Actor:
• Represents an entity that interacts with the system
• Depicted as a stick figure.

2. Worker:
• A specific type of actor that performs actions within the system.
• Represented as an actor figure within an oval, indicating a specialized role.
3. Relation:
• A connection between an actor and a use case.
• Shown as a straight line connecting the actor to the use case.
4. Generalization:
• Represents an inheritance relationship between use cases or actors.
• Depicted as a solid line with a hollow arrowhead pointing to the more general.
5. Include:
• Indicates that one use case is always called within another use case.
• Shown as a dashed arrow labeled "<<include>>."
6. Extend:
• Represents optional or conditional behavior that extends a base use case.
• Shown as a dashed arrow labelled "<<extend>>."
 Figure 1 Use Case Diagram for Coding Profile Management System

1. Actors:
● User
● Admin
2. Use Cases:
Account Creation: Use can create their account to the System
Manage Coding Profile: User can manage their coding profiles by filling in all the details.
Track progress: User can track their Coding Progress
Complete Courses: The user can apply to a course and complete it.
Share Achievements: User can share their achievements badge with the community
Real-Time-Notification: for engagement of users
2. Activity Diagram-
Activity diagrams show the steps involved in how a system works, helping us understand the flow of control.
They display the order in which activities happen and whether they occur one after the other (sequential) or at
the same time (concurrent). These diagrams help explain what triggers certain actions or events in a system.
● An activity diagram starts from an initial point and ends at a final point, showing different decision
paths along the way.
● They are often used in business and process modeling to show how a system behaves over time.

Activity Diagram Notations:

1. Activity (Action)
● Symbol: Rounded rectangle.
● Description: Represents a task or action in the system. Activities represent the individual steps or
actions that are performed.
● Example: "Login", "Verify User", "Generate Report".
2. Initial Node (Start)
● Symbol: Filled circle.
● Description: Represents the start point of the activity diagram, indicating the beginning of the flow of
control.
● Example: The initial action when a user opens the application.
3. Final Node (End)
● Symbol: Filled circle with a border (bullseye).
● Description: Indicates the end point of the process. When this node is reached, the process flow
terminates.
● Example: "Exit", "End Process".
4. Decision Node
● Symbol: Diamond.
● Description: A decision point in the flow, where the flow diverges based on a condition (like an "if"
statement).
● Example: "Is User Valid?" with two paths (Yes, No).
5. Merge Node
● Symbol: Diamond (same as decision node).
● Description: Merges multiple incoming flows into one, without any decision or branching logic.
● Example: After a decision point, various paths might merge back into a single flow.
6. Fork Node
● Symbol: Horizontal or vertical bar.
● Description: Splits a flow into multiple parallel flows. This node creates concurrent paths in the
activity diagram.
● Example: "Process Data" splits into two activities: "Validate Data" and "Save Data".
7. Join Node
● Symbol: Horizontal or vertical bar (same as the fork node).
● Description: Joins multiple parallel flows into a single flow. This node indicates that all incoming
paths must complete before moving to the next activity.
● Example: After processing data in parallel tasks, the flow converges to the next task.
8. Swimlane
● Symbol: Vertical or horizontal columns.
● Description: Divides the activity diagram into different lanes to show responsibility or ownership of
each activity. Each lane represents a different actor, system component, or process.
● Example: A swimlane might separate activities performed by "User", "System", or "Database".
9. Activity Final Node
● Symbol: Circle with a cross inside.
● Description: Represents the final completion of an activity, which stops the flow within the activity
diagram.
● Example: When all processes in a workflow are completed and the activity stops.
10. Object Node
● Symbol: Rectangle with a folded corner.
● Description: Represents an object or data in the system, showing when an object is being used or
modified during the process.
● Example: "Customer Order" object is passed between activities like "Process Order" or "Ship Order".
11. Control Flow
● Symbol: Solid arrow.
● Description: Represents the flow of control from one activity or node to another. It directs the path of
the execution.
● Example: An arrow from the "Start" node to the first activity.
12. Object Flow
● Symbol: Dashed arrow.
● Description: Represents the flow of data or objects between activities or nodes. It shows the transfer
of information or objects.
● Example: An object representing a "Customer Order" passed from one activity to the next.
13. Signal
● Symbol: Arrow with a dashed line.
● Description: Represents the sending or receiving of a signal between components in a system. This is
used to trigger an action or response.
● Example: A signal sent when a user presses a button or an event is triggered.
14. Time Event
● Symbol: A clock symbol.
● Description: Represents events triggered by time, such as delays or time-based conditions.
● Example: "After 5 minutes, send reminder."
15. Expansion Node
● Symbol: Rectangle with an "X" symbol inside.
● Description: Represents iterations or expansions, indicating that the process will loop or repeat for
each element in a collection.
● Example: For each "Item" in a shopping cart, the activity "Apply Discount" is performed.
16. Interruptible Activity Region
● Symbol: Rectangle with a dashed line inside.
● Description: An activity region where the flow can be interrupted, often used for emergency stopping
or exception handling.
● Example: A "Process Order" region that can be interrupted if a "Payment Failure" occurs.
Online Shopping Application Activity Diagram
3. State Chart Diagram-
A state diagram is a uml diagram which is used to represent the condition of the system or part of the system
at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state transitions.

State Chart Diagram Annotations

1. State
● Symbol: Rounded rectangle (also known as a "state box").
● Description: Represents a specific condition or situation during the life of an object where it satisfies
some condition, performs some activity, or waits for an event.
● Example: "Idle", "Processing", "Completed", "Error".
2. Initial State (Start State)
● Symbol: Solid black circle.
● Description: Marks the starting point of the state machine when the object is first created. The initial
state represents the first state an object enters when it begins its lifecycle.
● Example: The initial state of a system could be "Idle" or "Waiting for Input".
3. Final State (End State)
● Symbol: Solid black circle with a concentric border (bullseye).
● Description: Indicates the end of the state machine's operation, where no further transitions are
possible. Once the object reaches the final state, the process is considered complete.
● Example: A "Completed" or "Error" state indicating the end of a task.
4. Transition
● Symbol: Solid arrow.
● Description: Represents the movement from one state to another in response to an event. Transitions
often have triggers (events) and conditions associated with them.
● Example: A transition might go from the "Idle" state to the "Processing" state when an event like
"Start Process" occurs.
5. Event
● Symbol: Label written on a transition arrow.
● Description: An event that triggers a transition from one state to another. An event can be an
external signal, message, or time-based condition.
● Example: "Start Process", "Timer Expiry", "User Input".
6. Guard Condition
● Symbol: A condition written in square brackets [] next to a transition.
● Description: A boolean expression that must be true for the transition to occur. If the guard
condition is not satisfied, the transition is not triggered.
● Example: [temperature > 100] – The transition from the "Heating" state to the "Cooling" state occurs
only if the temperature exceeds 100.
7. Action
● Symbol: Action written after a slash / on a transition line.
● Description: An action that is executed when a transition occurs, typically as a result of an event. An
action is typically an operation that happens during the state transition.
● Example: Start Process / initialize data – This indicates that when the transition occurs, the action
"initialize data" will be executed.
8. Pseudo-State (Fork, Join, Choice, and Junction)
● Symbol: A diamond shape (used for decision-making or for branching).
● Description: A pseudo-state represents a state that doesn’t involve an actual object but is used to
control the flow of states. It helps in controlling concurrency, branching, or combining multiple
transitions.
9. History State
● Symbol: A circle with an "H" inside.
● Description: Represents the last active state before an object left a certain state. It helps an object
resume its activity from the last known state when it re-enters a composite state.
● Example: If a process was interrupted, the history state allows the process to resume from the point
it left off.
10. Composite State
● Symbol: A state containing nested sub-states, typically represented by a larger rounded rectangle that
contains smaller states.
● Description: A state that contains other states (sub-states) inside it, representing a hierarchical
structure where the object may be in one of several possible states within this composite state.
● Example: A "Processing" state might have sub-states like "Downloading", "Verifying", and
"Saving".
11. Entry / Exit Actions
● Symbol: Keywords entry and exit inside a state.
● Description: Represents actions that occur when entering or exiting a state.
 ● Example: In the "Processing" state, an entry action might be "Initialize variables," and an exit action
could be "Cleanup resources."
12. Fork and Join
● Fork:
o Symbol: Horizontal or vertical line dividing the flow into multiple parallel transitions.
o Description: Indicates parallel transitions or actions that occur simultaneously.
● Join:
o Symbol: Horizontal or vertical line merging multiple paths into one.
o Description: Combines parallel activities or transitions back into a single flow.
13. Signal
● Symbol: A dashed line with an arrow.
● Description: A signal used to represent asynchronous communication or notifications between
states.
● Example: A system may send a signal when a specific condition is met, such as signal Timeout from
one state to another.

Online Shopping Application State Diagram

 Experiment No – 3
Draw the structural view diagram for the system: Class diagram, object diagram and
Sequence diagram.
1. Class Diagram :

Class diagrams are a type of UML (Unified Modeling Language) diagram used in software engineering to
visually represent the structure and relationships of classes within a system i.e. used to construct and
visualize object-oriented systems.

UML Class Notations

Class notation is a graphical representation used to depict classes and their relationships in
object-oriented modeling.

1. Class Name:
● The name of the class is typically written in the top compartment of the class box and is
centered and bold.
2. Attributes:
● Attributes, also known as properties or fields, represent the data members of the class. They
are listed in the second compartment of the class box and often include the visibility (e.g.,
public, private) and the data type of each attribute.
3. Methods:
● Methods, also known as functions or operations, represent the behavior or functionality of the
class. They are listed in the third compartment of the class box and include the visibility (e.g.,
public, private), return type, and parameters of each method.
 4. Visibility Notation:
● Visibility notations indicate the access level of attributes and methods. Common visibility
notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o # for protected (visible to subclasses)
o ~ for package or default visibility (visible to classes in the same package)

Relationships between classes

Online Shopping Application Class Diagram

2. Object Diagram:

An Object Diagram can be referred to as a screenshot of the instances in a system and the relationship
that exists between them.
● An object diagram in UML is useful because it provides a clear and visual representation of specific
instances of classes and their relationships at a particular point in time, aiding in understanding and
communicating the structure and interactions within a system.
● In other words, “An object diagram in the Unified Modeling Language (UML), is a diagram that
shows a complete or partial view of the structure of a modeled system at a specific time.

Object Diagram Notation

1. Objects or Instance specifications

When we instantiate a classifier in a system, the object we create represents an entity which exists in the
system. We can represent the changes in object over time by creating multiple instance specifications. We
use a rectangle to represent an object in an object diagram.
2. Attributes and Values
Inside the object box, attributes of the object are listed along with their specific values.
3. Link
We use a link to represent a relationship between two objects. We represent the number of participants on
the link for each, at the end of the link. The term link is used to specify a relationship between two instance
specifications or objects. We use a solid line to represent a link between two objects.
4. Dependency Relationships
We use a dependency relationship to show when one element depends on another element. A dependency is
used to depict the relationship between dependent and independent entities in the system.
5. Association
Association is a reference relationship between two objects (or classes). An association line connects two
object boxes, representing a relationship between instances of two classes. We use association when one
object references members of the other object. Association can be uni-directional or bi-directional. We use
an arrow to represent association.

6. Aggregation
Aggregation represents a “has a” relationship. We use a hollow diamond on the containing object with a line
which joins it to the contained object.
● Aggregation is a specific form of association.
● It is a kind of parent-child relationship however it isn’t inheritance.
● Aggregation occurs when the lifecycle of the contained objects does not strongly depend on the
lifecycle of container objects.
7. Composition
Composition is a type of association where the child cannot exist independent of the other. We use a filled
diamond on the containing object with a line which joins it to the contained object. Composition is also a
special type of association. It is also a kind of parent child relationship but it is not inheritance. So whenever
independent existence of the child is not possible we use a composition relationship.
3. Sequence Diagram:

Sequence diagrams are a type of UML (Unified Modeling Language) diagram that visually represent the
interactions between objects or components in a system over time. They focus on the order and timing of
messages or events exchanged between different system elements. The diagram captures how objects
communicate with each other through a series of messages, providing a clear view of the sequence of
operations or processes.

Key Notations of Sequence Diagrams in UML:

1. Object (Actor/Participant)
● Symbol: A rectangle with the name of the object or actor, placed at the top of the diagram, often with
a dashed vertical line beneath it called the lifeline.
● Description: Represents an object or an actor (external entity like a user) that participates in the
interaction. Actors are typically placed on the left or right side of the diagram, while objects are shown
in the center.

2. Lifeline
● Symbol: A vertical dashed line that extends from the object/actor symbol downward.
● Description: Represents the presence of an object or actor over time during the interaction. The lifeline
is an indication of the existence of an object throughout the duration of the interaction, often showing
the object's participation in sending or receiving messages.

3. Activation (Execution Occurrence)

● Symbol: A thin rectangular bar placed on the lifeline, usually placed on top of the lifeline.
● Description: Indicates the period during which an object is active, performing an operation. It shows
when an object is involved in the execution of an action.

4. Message
● Symbol: A horizontal arrow between lifelines (objects or actors). The arrow points from the sender to
the receiver.
● Description: Represents the communication or interaction between objects. Messages are exchanged
to invoke methods or functions, and the arrow's direction indicates the flow of control.
● Types of Messages:
o Synchronous Message: A solid arrow with a filled arrowhead (the sender waits for a response
before proceeding).
o Asynchronous Message: A solid arrow with an open arrowhead (the sender does not wait for
a response).
o Return Message: A dashed arrow with an open arrowhead (indicates the return of a response
from a method call).

5. Actor
● Symbol: A stick figure or a named rectangle (actor) placed outside the main sequence.
● Description: Represents an external entity, such as a user, system, or another subsystem, that interacts
with the system being modeled.

6. Return Message
● Symbol: A dashed arrow with an open arrowhead.
● Description: Represents a response or return of control from the receiver back to the sender. It
typically follows a method call or synchronous message, indicating the completion of the operation.
7. Self-Message (Self-Call)
● Symbol: An arrow from the object’s lifeline to itself, indicating that an object is calling one of its own
methods.
● Description: Represents a message sent by an object to itself, which is useful for modeling internal
processing, like calling a method within the same object.

8. Alt (Alternative)
● Symbol: A rectangular frame with the keyword "alt" written inside.
● Description: Represents an alternative condition or decision. The sequence diagram inside the "alt"
frame can have different paths based on certain conditions or guards.

9. Loop (Looping)
● Symbol: A rectangular frame with the keyword "loop" written inside.
● Description: Represents a repetitive action or loop, where a sequence of messages is repeated for each
iteration or condition.

10. Opt (Optional)

● Symbol: A rectangular frame with the keyword "opt" written inside.
● Description: Represents an optional sequence or behavior. The interaction occurs only if a specific
condition or event happens.

11. Combined Fragment

● Symbol: A rectangular box that contains multiple interactions. It is used to represent control structures
such as alternatives, loops, or options.
● Description: Combined fragments are used to group messages that have a specific condition, like "alt",
"loop", "opt", "par" (parallel), etc.

12. Interaction Use

● Symbol: A rectangle with the name of a sequence diagram and an arrow pointing to it.
● Description: Represents the inclusion of another sequence diagram. It's used to break down complex
scenarios into smaller, reusable sequences.
 Sequence Diagram of Online Shopping Website

Experiment No – 4
Perform Unit testing of Calculator program using Junit testing framework.
JUnit is a Testing Framework. The Junit 5 is the latest version of the testing framework, and it has a lot of
features when compared with Junit 4. JUnit 5, also known as JUnit Jupiter. It introduces several new features
and improvements over its predecessor, JUnit 4, making it more powerful and flexible for writing and running
tests.
The JUnit 5 version has three different modules for defining and performing different functionalities in testing.
The components are:
● JUnit Platform
● JUnit Jupiter
● JUnit Vintage

Step 1: Create a Calculator Program

public class Calculator {
public int add(int a, int b) {
return a + b;
}
 public int subtract(int a, int b) {
return a - b;
}
public int multiply(int a, int b) {
return a * b;
}
public double divide(int a, int b) throws ArithmeticException {
if (b == 0) {
throw new ArithmeticException("Cannot divide by zero");
}
return (double) a / b;
}
}

Step 2: Add JUnit Dependencies

<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.7.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.7.0</version>
<scope>test</scope>
</dependency>
</dependencies>

Step 3: Write JUnit Test Cases

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
class CalculatorTest {
Calculator calculator = new Calculator();
@Test
void testAdd() {
assertEquals(5, calculator.add(2, 3), "2 + 3 should equal 5");
assertEquals(-1, calculator.add(-2, 1), "-2 + 1 should equal -1");
}
@Test
void testSubtract() {
assertEquals(1, calculator.subtract(3, 2), "3 - 2 should equal 1");
assertEquals(-3, calculator.subtract(-2, 1), "-2 - 1 should equal -3");
}
@Test
void testMultiply() {
assertEquals(6, calculator.multiply(2, 3), "2 * 3 should equal 6");
assertEquals(-6, calculator.multiply(-2, 3), "-2 * 3 should equal -6");
}
@Test
void testDivide() {
assertEquals(2.0, calculator.divide(6, 3), "6 / 3 should equal 2.0");
assertEquals(-2.0, calculator.divide(-6, 3), "-6 / 3 should equal -2.0");
}
@Test
void testDivideByZero() {
assertThrows(ArithmeticException.class, () -> calculator.divide(1, 0), "Division by zero should throw
ArithmeticException");
}
}

Output
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
 Experiment No – 5
Perform Integration testing of calculator program using Junit testing framework.
Integration testing is a software testing technique that focuses on verifying the interactions and data exchange
between different components or modules of a software application. The goal of integration testing is to
identify any problems or bugs that arise when different components are combined and interact with each other.
Integration testing is typically performed after unit testing and before system testing. It helps to identify and
resolve integration issues early in the development cycle, reducing the risk of more severe and costly problems
later on.

Integration test approaches

There are four types of integration testing approaches. Those approaches are the following:
1. Big-Bang Integration Testing
● It is the simplest integration testing approach, where all the modules are combined and the functionality
is verified after the completion of individual module testing.
● In simple words, all the modules of the system are simply put together and tested.
● This approach is practicable only for very small systems. If an error is found during the integration
testing, it is very difficult to localize the error as the error may potentially belong to any of the modules
being integrated.
2. Bottom-Up Integration Testing
In bottom-up testing, each module at lower levels are tested with higher modules until all modules are tested.
The primary purpose of this integration testing is that each subsystem tests the interfaces among various
modules making up the subsystem. This integration testing uses test drivers to drive and pass appropriate data
to the lower-level modules.

3. Top-Down Integration Testing

Top-down integration testing technique is used in order to simulate the behaviour of the lower-level modules
that are not yet integrated. In this integration testing, testing takes place from top to bottom. First, high-level
modules are tested and then low-level modules and finally integrating the low-level modules to a high level
to ensure the system is working as intended.
4. Mixed Integration Testing
A mixed integration testing is also called sandwiched integration testing. A mixed integration testing follows
a combination of top down and bottom-up testing approaches. In top-down approach, testing can start only
after the top-level module have been coded and unit tested. In bottom-up approach, testing can start only after
the bottom level modules are ready.

Step 1: Create a Calculator Program

public class Calculator {
public int add(int a, int b) {
return a + b;
}
public int subtract(int a, int b) {
return a - b;
}
public int multiply(int a, int b) {
return a * b;
}
public double divide(int a, int b) throws ArithmeticException {
if (b == 0) {
throw new ArithmeticException("Cannot divide by zero");
}
return (double) a / b;
}
}

Step 2: JUnit Test Class for Integration Testing

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
class CalculatorIntegrationTest {
private Calculator calculator;
@BeforeEach
void setUp() {
calculator = new Calculator();
}
@Test
void testAddThenMultiply() {
// Perform (2 + 3) * 4
int additionResult = calculator.add(2, 3);
int multiplicationResult = calculator.multiply(additionResult, 4);
assertEquals(20, multiplicationResult, "The result of (2 + 3) * 4 should be 20");
}
@Test
void testSubtractThenDivide() {
// Perform (8 - 2) / 3
int subtractionResult = calculator.subtract(8, 2);
double divisionResult = calculator.divide(subtractionResult, 3);
assertEquals(2.0, divisionResult, "The result of (8 - 2) / 3 should be 2.0");
}
@Test
void testComplexExpression() {
// Perform (2 + 3) * (6 - 1) / 5
int additionResult = calculator.add(2, 3);
int subtractionResult = calculator.subtract(6, 1);
int multiplicationResult = calculator.multiply(additionResult, subtractionResult);
double finalResult = calculator.divide(multiplicationResult, 5);
assertEquals(5.0, finalResult, "The result of (2 + 3) * (6 - 1) / 5 should be 5.0");
 }
@Test
void testDivideByZero() {
assertThrows(ArithmeticException.class, () -> calculator.divide(5, 0), "Division by zero should throw an
ArithmeticException");
}
}
Output
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec