Department of Computer Science

and Engineering

Software Engineering Lab

Subject code: KCS651

Submitted By: Submitted To:

Name: Pritam Kumar Ms. Haripriya Sahu
Roll no: 200960100030
Semester: 6th
 INDEX

Experiment Experiment Name Date of Date of Faculty Signature

NO. Conduction Submission

1. Develop Requirements specification

for a given problem

2. Draw the Use case diagram and

specify the role of each of the
actors.
3. Draw the Class diagram for any
system after identifying classes and
association among them.

4. Draw the E-R diagram for any

system.
5. Draw the Activity diagram for any
system.

6. Draw the Sequence diagram for any

two scenarios.

7. Draw the Collaboration diagram for

any system.

8. Draw the State chart diagram for

any system

9. Draw the Component diagram for

any system

10. Draw the Deployment diagram for

any system

11. Introduction to Selenium testing

tool
 Experiment-1
Aim: To develop Requirements specification for a given problem
Procedure:

Step 1:
Introduction:
Purpose
Identify the product whose software requirements are specified in this document. Describe
the scope of the product that is covered by this SRS, particularly if this SRS describes only
part of the system or a single Sub-System. Describe the different types of user that the
document is intended for, such as developers, project managers, marketing staff, users,
testers, and documentation writers. Describe what the rest of this SRS contains and how it is
organized. Suggest a sequence for reading the document, beginning with the overview
sections and proceeding through the sections that are most pertinent to each reader type.
Project Scope
Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If
a separate vision and scope document is available, refer to it rather than duplicating its
contents here. An SRS that specifies the next release of an evolving product should contain its
own scope statement as a subset of the long-term strategic product vision.

Step 2:
Overall Description:
Product Perspective
Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS defines a component of a larger
system, relate the requirements of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that shows the major components of
the overall system, subsystem interconnections, and external interfaces can be helpful.
Product Features
Summarize the major features the product contains or the significant functions that it
performs or lets the user perform. Only a high level summary is needed here. Organize the
functions to make them understandable to any reader of the SRS. A picture of the major
groups of related requirements and how they relate, such as a top level data flow diagram or a
class diagram, is often effective.
User Classes and Characteristics
Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical
expertise, security or privilege levels, educational level, or experience. Describe the pertinent
characteristics of each user class. Certain requirements may pertain only to certain user
classes. Distinguish the favoured user classes from those who are less important to satisfy.
Operating Environment
Describe the environment in which the software will operate, including the hardware
platform, operating system and versions, and any other software components or applications
with which it must peacefully coexist.
Design and Implementation Constraints
Describe any items or issues that will limit the options available to the developers. These
might include: corporate or regulatory policies; hardware limitations (timing requirements,
memory requirements); interfaces to other applications; specific technologies, tools, and
databases to be used; parallel operations; language requirements; communications protocols;
security considerations; design conventions or programming standards (for example, if the
customer’s organization will be responsible for maintaining the delivered software).
Step 3:
System Features:
This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section
by use case, mode of operation, user class, object class, functional hierarchy, or combinations
of these, whatever makes the most logical sense for your product.
System Feature 1
Don’t really say “System Feature 1.” State the feature name in just a few words.

1) Description and Priority:

Provide a short description of the feature and indicate whether it is of High, Medium, or Low
priority. You could also include specific priority component ratings, such as benefit, penalty,
cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).
2) Stimulus/Response Sequences:
List the sequences of user actions and system responses that stimulate the behaviour defined
for this feature. These will correspond to the dialog elements associated with use cases.

3) Functional Requirements:
Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should respond to
anticipated error conditions or invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary.

<Each requirement should be uniquely identified with a sequence number or a meaningful tag
of some kind.>

REQ-1:
REQ-2:
Step 4:
External Interface Requirements:
User Interfaces
Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style
guides that are to be followed, screen layout constraints, standard buttons and functions (e.g.,
help) that will appear on every screen, keyboard shortcuts, error message display standards,
and so on. Define the software components for which a user interface is needed. Details of
the user interface design should be documented in a separate user interface specification.
Hardware Interfaces
Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device
types, the nature of the data and control interactions between the software and the hardware,
and communication protocols to be used.
Software Interfaces
Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages coming into the system and
going out and describe the purpose of each. Describe the services needed and the nature of
communications. Refer to documents that describe detailed application programming
interface protocols. Identify data that will be shared across software components. If the data
sharing mechanism must be implemented in a specific way (for example, use of a global data
area in a multitasking operating system), specify this as an implementation constraint.

Communications Interfaces
Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.

Non -functional Requirements:

Performance Requirements
If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make
suitable design choices. Specify the timing relationships for real time systems. Make such
requirements as specific as possible. You may need to state performance requirements for
individual functional requirements or features.
Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as
well as actions that must be prevented. Refer to any external policies or regulations that state
safety issues that affect the product’s design or use. Define any safety certifications that must
be satisfied.
Security Requirements
Specify any requirements regarding security or privacy issues surrounding use of the product
or protection of the data used or created by the product. Define any user identity
authentication requirements. Refer to any external policies or regulations containing security
issues that affect the product. Define any security or privacy certifications that must be
satisfied.
Software Quality Attributes
Specify any additional quality characteristics for the product that will be important to either
the customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness,
testability, and usability. Write these to be specific, quantitative, and verifiable when possible.
At the least, clarify the relative preferences for various attributes, such as ease of use over
ease of learning.
Other Requirements
Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse objectives
for the project, and so on. Add any new sections that are pertinent to the project.
 Experiment-2
Aim: To draw the Use case diagram and specify the role of each of the actors.
Theory: A use case diagram is used to represent the dynamic behaviour of a system. It
encapsulates the system's functionality by incorporating use cases, actors, and their
relationships. It models the tasks, services, and functions required by a system/subsystem of
an application.
Symbols/Components:

Actor specifies a role played by a user or any other system that interacts with
the subject.

Use case is a list of steps, typically defining interactions between an actor

and a system, to achieve a goal.

Package is used to group elements, and to provide a namespace for the

grouped elements.

Objects are model elements that represent instances of a class or of classes.

Interfaces are model elements that define sets of operations that other model
elements, such as classes, or components must implement.

Constraint is an extension mechanism that enables you to refine the

semantics of a UML model element.

Note contains comments or textual information

Use Case diagram of Library management System :
 Experiment-3
Aim: To draw the Class diagram for any system after identifying classes and association
among them.

Theory: The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them. A class consists of its
objects, and also it may inherit from other classes. A class diagram is used to visualize,
describe, document various different aspects of the system, and also construct executable
software code. It shows the attributes, classes, functions, and relationships to give an
overview of the software system.

Symbols/Components:

Classes and interfaces in UML show architecture and

features of the designed system.

Aggregation is a special type of association in which objects are assembled or

configured together to create a more complex object. An aggregation describes a group of
objects and how you interact with them.

Dependency relationship is a relationship in which one element, the client,

uses or depends on another element, the supplier.

Composition represents whole-part relationships and is a form of aggregation.

Generalization is a relationship in which one model element (the child) is

based on another model element (the parent).

Association is a relationship between two classifiers, such as classes or use

cases, that describes the reasons for the relationship and the rules that govern the relationship.
Class diagram of library Management System
 Experiment-4
Aim: To draw the E-R diagram for any system.
Theory: ER-modelling is a data modelling method used in software engineering to produce a
conceptual data model of an information system. Diagrams created using this ER-modelling
method are called Entity-Relationship Diagrams or ER diagrams or ERDs.

Symbols/Components:
Entity Relationship diagram of library Management System
 Experiment-5
Aim: To draw the Activity diagram for any system

Theory: In UML, the activity diagram is used to demonstrate the flow of control within the
system rather than the implementation. It models the concurrent and sequential activities. The
activity diagram helps in envisioning the workflow from one activity to another. It put
emphasis on the condition of flow and the order in which it occurs. The flow can be
sequential, branched, or concurrent, and to deal with such kinds of flows, the activity diagram
has come up with a fork, join, etc. It is also termed as an object-oriented flowchart. It
encompasses activities composed of a set of actions or operations that are applied to model
the behavioural diagram.

Symbols/Components :

Represents the beginning of a process or workflow in an

Start symbol
activity diagram.

Activity symbol Indicates the activities that make up a modelled process..

Connector symbol Shows the directional flow, or control flow, of the activity.

Joint symbol/ Combines two concurrent activities and re-introduces them

Synchronization bar to a flow where only one activity occurs at a time.

Fork symbol Splits a single activity flow into two concurrent activities.

Represents a decision and always has at least two paths

Decision symbol branching out with condition text to allow users to view
options.

Placed next to a decision marker to let you know under what

Condition text
condition an activity flow should split off in that direction.

Marks the end state of an activity and represents the

End symbol
completion of all flows of a process.
Activity Diagram of Library Management System:
 Experiment-6

Aim: To draw the Sequence diagram for any two scenarios.

Theory: The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a time-ordered sequence of events, such that
these lifelines took part at the run time. In UML, the lifeline is represented by a vertical bar,
whereas the message flow is represented by a vertical dotted line that extends across the
bottom of the page. It incorporates the iterations as well as branching.

Symbols/Components:

Lifeline represents each instance in an interaction.

Activate is used to denote participant activation. Once a participant is activated,

its lifeline appears.

Objects are model elements that represent instances of a class or of classes.

Classes in UML show architecture and features of the designed system.

Message is an element that defines a specific kind of communication

between instances in an interaction.

Actor specifies a role played by a user or any other system that interacts with the
subject.

Note contains comments or textual information.

Constraint is an extension mechanism that enables you to refine the

semantics of a UML model element.
A. Sequence diagram of Library Management System
B. Sequence diagram of Online Shopping System
 Experiment-7
Aim: To draw the Collaboration diagram for any system.
Theory: The collaboration diagram is used to show the relationship between the objects in a
system. Both the sequence and the collaboration diagrams represent the same information but
differently. Instead of showing the flow of messages, it depicts the architecture of the object
residing in the system as it is based on object-oriented programming. An object consists of
several features. Multiple objects present in the system are connected to each other. The
collaboration diagram, which is also known as a communication diagram, is used to portray
the object's architecture in the system.

Symbols/Components:

Objects are model elements that represent instances of a class or of classes.

Multi-object represents a set of lifeline instances.

Association role is optional and suppressible.

Delegation is like inheritance done manually through object composition.

Link to self is used to link the objects that fulfil more than one role.

Constraint is an extension mechanism that enables you to refine the

semantics of a UML model element.

Note contains comments or textual information.

Collaboration diagram of library Management System
 Experiment-8
Aim: To draw the State chart diagram for any system.

Theory: The state machine diagram is also called the State chart or State Transition diagram,
which shows the order of states underwent by an object within the system. It captures the
software system's behaviour. It models the behaviour of a class, a subsystem, a package, and
a complete system. It tends out to be an efficient way of modelling the interactions and
collaborations in the external entities and the system. It models event-based systems to handle
the state of an object. It also defines several distinct states of a component within the system.
Each object/component has a specific state.

Symbols/Components:

State defines current condition of an event or activity. State diagram is ofen

used to describe state changes triggered by events.

Start state symbol signals the first step of a process.

End state symbol stands for the result of a process.

Transition takes operation from one state to another and represents the
response to a particular event. A single transition comes out of each state or activity,
connecting it to the next state or activity.

Constraint is an extension mechanism that enables you to refine the

semantics of a UML model element.

Note contains comments or textual information.

State Chart diagram of ATM System
 Experiment-9
Aim: To draw the Component diagram for any system.

Theory: A component diagram is used to break down a large object-oriented system into the
smaller components, so as to make them more manageable. It models the physical view of a
system such as executables, files, libraries, etc. that resides within the node. It visualizes the
relationships as well as the organization between the components present in the system. It
helps in forming an executable system. A component is a single unit of the system, which is
replaceable and executable.

Symbols/Components:

Component represents a modular part of a system. A component defines its

behaviour in terms of provided and required interfaces.

Package is used to group elements, and to provide a namespace for the

grouped elements.

Package container is used to define UML elements such as classes, use cases,
and components.

Dependency relationship is a relationship in which one element, the client,

uses or depends on another element, the supplier.

Generalization is a relationship in which one model element (the child) is

based on another model element (the parent).

Constraint is an extension mechanism that enables you to refine the

semantics of a UML model element.

Note contains comments or textual information.

Component diagram of library Management System
 Experiment-10
Aim: To draw the Deployment diagram for any system.

Theory: The deployment diagram visualizes the physical hardware on which the software
will be deployed. It portrays the static deployment view of a system. It involves the nodes and
their relationships. It ascertains how software is deployed on the hardware. It maps the
software architecture created in design to the physical system architecture, where the
software will be executed as a node. Since it involves many nodes, the relationship is shown
by utilizing communication paths.

Symbols/Components:

Component represents a modular part of a system. A component defines its behaviour in

terms of provided and required interfaces.

Interface A circle that indicates a contractual relationship. Those objects that realize the
interface must complete some sort of obligation.

Artifacts: A box with the header ">" and then the name of the file .

Node: There are two types of nodes in a deployment diagram: device nodes and execution
environment nodes. Device nodes are computing resources with processing capabilities and
the ability to execute programs. Some examples of device nodes include PCs, laptops, and
mobile phones.

An execution environment node, or EEN, is any computer system that resides within a device
node. It could be an operating system, a JVM, or another servlet container.
Deployment diagram of Online Shopping System
 Experiment-11
Aim: Introduction to Selenium testing tool
What is Selenium?
Selenium is a free, open-source automation testing suite for web applications across different
browsers and platforms. It is somewhat similar to HP Quick-Test Pro (QTP, currently UFT).
However, Selenium focuses on automating web-based applications.
Testing done using Selenium is usually referred to as Selenium testing. Remember, only
testing web applications is possible with Selenium. You cannot use it to test desktop
applications or mobile applications.
Selenium Overview
Selenium Definition: It is a free automation testing suite of tools used for only testing web
applications. There is no need to feel disappointed due to the fact that it only helps in testing
web applications because various other software have got you covered.
There are many tools available for testing desktop and mobile applications, such as IBM’s
RFI, HP’s QPI, Appium, etc. However, the aim of this Selenium tutorial is to make you
understand the testing of dynamic web applications and why Selenium is the best for it.
Since Selenium is an open-source tool, there is no licensing cost involved, which is a
significant benefit over other testing tools. Other reasons behind Selenium’s ever-growing
popularity are as follows:
Test scripts are often written in any of these programming languages—Java, Python, C#,
PHP, Ruby, Perl, and .Net.
Tests can be carried out in any of these operating systems—Windows, Mac, or Linux.
Tests can be carried out using any of these browsers—Mozilla Firefox, Internet Explorer,
Google Chrome, Safari, or Opera.
It can be integrated with tools such as TestNG in selenium and JUnit for managing test cases
and generating reports.
It is integrated with Maven, Jenkins, and Docker to achieve continuous testing.
Now, take a deeper look at Selenium Automation Testing, which has revolutionized the
development pipeline.
History of Selenium
Selenium was the first tool that allowed users to control a browser with the help of any
language. It allowed professionals to automate various processes, but it had a set of
drawbacks since it was not possible to perform automation testing on certain things with
JavaScript. Besides, with web applications getting complex, the restrictions of the tool only
started to increase.
Soon, Simon Stewart, from Google, got tired of the limitations of Selenium. He required a
testing tool that was capable of communicating with the browser directly, and hence, he came
up with WebDriver. A few years later, Selenium merged with WebDriver. This tool allowed
professionals to do automation testing by using a single tool, which was much more efficient.
Who Developed Selenium?
There are numerous developers who built Selenium as it is not a single tool but a collection
of several tools. Jason Huggins, an engineer who worked in Thought Works, was the first to
realize that the web application that he was working on often required testing. This is when
he came up with Selenium. He figured out that it was inefficient to conduct manual testing on
applications repeatedly as it took a lot of time and effort. He built a JavaScript program that
could control the actions of the browser automatically and called it Java-Script Test-Runner.
This tool was later called Selenium.
Why Selenium?
Selenium is a tool for automating testing across many web browsers. Selenium
WebDriver supports a variety of browsers, including Google Chrome, Mozilla Firefox, Safari,
and Internet Explorer, and allows you to simply automate browser testing across different
browsers.
While Selenium has several advantages, the following are a few of the more important ones,
which describe why most people choose Selenium over testing tools.
 It guarantees software development life cycle (SDLC) process agility and
transparency among cross-functional teams.
 It offers less involvement of hardware.
 It is open-source and platform-independent.
 It has a user-friendly interface that makes it simple to build and execute test scripts.
 It provides excellent visibility for testing end-to-end apps.
 The automation test suites may be reused and tested on a variety of browsers and
operating systems.
 Its flexibility is enhanced by features such as test case regrouping and refactoring
What is Selenium Used For?
Most programmers and developers who build website applications and wish to test them
every now and then use Selenium. One of the biggest advantages of Selenium, which has
made it so popular, is its flexibility. Any individual who creates web programs can use
Selenium to test the code and applications. Further, professionals can debug and perform
visual regression tests as per the requirements of the website or code.
In most organizations, it is the job of quality analyst (QA) engineers to test web applications
by using Selenium. They are required to write scripts that can help in maximizing accuracy
and test coverage to make changes in the project and maintain the infrastructure of the test.
QA engineers are responsible for developing test suites that can identify bugs, using which
they can inform stakeholders about the benchmarks set for the project. The primary goal of
QA engineers is to ensure efficiency and test coverage and increase productivity.
 Selenium vs QTP
The comparison based on the performance factor of Selenium and another popular
automation testing tool, QTP, is shown below.
Comparison Between Selenium and QTP (Now UFT)
Quick-Test Professional (QTP) is a proprietary automation testing tool, previously owned by
Mercury Interactive, before being acquired by Hewlett Packard in 2006.

Selenium QTP

Is open-source, i.e., it is free to use Is Commercial

Is highly extensible Has limited add-ons

Runs tests across different browsers Can only be used in Windows

Supports various operating systems Supports mobile app test automation (iOS and Android)
using the HP solution called HP Mobile Center

Supports mobile devices Need to have the application under test to be visible on
the desktop

Execute tests in parallel while the browser is minimized Executes only in parallel using HP Quality Center,
which is a paid product

It is pretty clear from the above comparison why Selenium is the most popular automation
tool. However, there are several other nuances in Selenium testing, and you need to
understand which one is the most applicable Selenium tool for your requirements.