Se Pratham Kakkar

ADGITM Software Engineering Lab
DR. AKHILESH DAS GUPTA INSTITUTE OF TECHNOLOGY & MANAGEMENT

Department of Information Technology
SOFTWARE ENGINEERING LAB

Paper Code: ETCS 353
Submitted to: Submitted by:

Ms. Neetu Swarup Pratham Kakkar
Assistant Professor 09115603120
IT Dept. T7
Pratham Kakkar
09115603120
T7
INDEX
S.no Name of Program Date Signature
Group B
1. To write the problem statement of 27/08/2021
student result management system.
2. Write the software requirement 03/09/2021
specification document for result
management system.
3. Draw use case diagram through the 10/09/2021
software Start UML.
4. Draw the data flow diagrams at Level 0 17/09/2021
and Level 1 for student result
management system.
5. To draw the Activity diagram for 24/09/2021
6. To draw the Sequence diagram for 08/10/2021
ATM.
7. To draw the Sequence diagram for 08/10/2021
8. To draw the Class Diagram for student 19/10/2021
result management system.
9. To draw the Collaboration Diagram 26/10/21
for student result management system.
10. To draw the State Chart Diagram for 02/11/2021
11. To perform various testing using the 09/11/2021
testing tool unit testing, integration
testing for a sample code of the
suggested system.
12. Estimation of effort using FP 09/11/2021
Estimation for chosen system.
13. To draw the Component Diagram for 01/12/2021
student result management system and
ordering system.
14. To draw the Deployment Diagram for 08/12/2021
Pratham Kakkar
09115603120
T7
EXPERIMENT- 1
AIM: To write the problem statement of STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU
THEORY:
A university conducts M.Tech course over 4 semesters, divided into 4 branches, namely CSE, IT ECE and
EEE. The students are offered 4 theory papers and 3 lab papers in all semesters. The theory papers offered in
the 3rd semester are categorized as either 'Core' or 'Elective. Core papers do not have alternative subject
whereas elective papers have 2 other alternative subjects. Thus, a student can take up any subject out of the 3
given choices.
The evaluation of each subject is done out of 100 marks. For theory paper, the division of externals and
internals is 75+25 for respectively. For lab paper, the division is 60+40 for externals and internals respectively.
During the semester, minor exams are conducted for each semester. Students are also required to submit
assignments as directed by the corresponding faculty and maintain Lab records for practical. Based on the
students' performance in minor exams, assignments, Lab records and attendance, marks are given out of 25 in
theory paper and 40 in lab paper. These marks account for internal evaluation if the students. At the end of
each semester major exams are conducted in each subject (theory as well as practical). The theory papers are
evaluated out of 75 marks and lab papers are evaluated out of 60 marks. Thus, the total marks of a student in
a subject are obtained by adding the marks obtained in internal and external evaluation.
The students are required to submit a project report based on their industry training performed by the student
in 4th semester. They are evaluated out of 100 marks based on the executable project, report submitted, the
presentation given and the viva response.
A student's total score of 40 or higher is considered "pass”, otherwise “fail". If a student fails in a subject, he
or she must reappear in that subject next year to achieve the required percentage.
The requirement is to develop a system that will manage information about subjects offered in different
semesters, students enrolled in different semesters, electives opted by the students and marks obtained by the
students in different semesters. The system should also have the ability to generate mark sheet for each student
semester-wise. Semester-wise detailed marks list and student performance report also need to be generated as
well.
CONCLUSION: Problem statement of STUDENT RESULT MANAGEMENT SYSTEM has been written
successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 2
AIM: Write the software requirement specification document for RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word
THEORY:
An SRS is basically an organization's understanding (in writing) of a customer or potential client's system
requirements and dependencies at a particular point in time (usually) prior to any actual design or development
work. It's a two-way insurance policy that assures that both the client and the organization understand the
other's requirements from that perspective at a given point in time.
Well-designed, well-written SRS accomplishes four major goals:
i. It provides feedback to the customer.
ii. It decomposes the problem into component parts.
iii. It serves as an input to the design specification.
iv. It serves as a product validation check.
The basic issues that the SRS shall address are the following:
a. Functionality. What is the software supposed to do?
b. External interfaces. How does the software interact with people, the system’s hardware, other hardware,
and other software?
c. Performance. What is the speed, availability, response time, recovery time of various software functions,
etc.?
d. Attributes. What is the portability, correctness, maintainability, security, etc. considerations?
PROCEDURE:
IEEE Standard SRS Template
1. INTRODUCTION
This document aims at defining the overall software requirements for STUDENT RESULT
MANAGEMENT SYSTEM. Efforts have been made to define the requirements exhaustively and
accurately. The final product will contain the features/functionality mentioned in this document.
1.1 PURPOSE
This specification document describes the capabilities that will be provided by the software application
STUDENT RESULT MANAGEMENT SYSTEM. It also states the various required constraints by
which the system will abide. The intended audiences for this document are the development team,
testing team and end users of the product.
1.2 SCOPE
The software product STUDENT RESULT MANAGEMENT SYSTEM will be an MIS and
Reporting application that will be used for result preparation and management of B. Tech Program
of a University. The application will manage the information about various students enrolled in
this course in different years, the subjects offered during different semesters of the course, the
students’ choices for opting different subjects, and the marks obtained by various students in
various subjects in different semesters.
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Pratham Kakkar
09115603120
T7
Following abbreviations have been used throughout this document: -

B. Tech Bachelor of Technology
CSE Computer Science Engineering
IT Information Technology
EEE Electrical and Electronic Engineering
ECE Electronics and Communication Engineering
DBA Database Administrator
SRMS Student Result Management System
1.4 REFERNECES
(i) University website: For information about course structure of B. Tech Program
(ii) IEEE Recommended Practice for Software Requirement Specifications – IEEE Std 830-1993
1.5 OVERVIEW
The rest of this SRS document describes the various system requirements, interfaces, features and
functionalities in detail.
2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
Online Student Result Management System this software is used to maintain and manage the result
of the student. This software helps the user to easy access the result of students. This software is
also helpful for the administrator because he can easily bring changes to the records of the student.
2.1.1 HARDWARE INTERFACES
Server Side
The web application will be hosted on one of the department’s Linux servers and
connecting to one of the school Oracle Database servers. The web server is listening on the
web standard port, port 80.
Client Side
The system is a web-based application; clients are requiring using a modern web browser
such as Mozilla Firebox 1.5, Internet Explorer 6 and Enable Cookies. The computer must
have an Internet connection in order to be able to access the system
2.1.2 USER INTEFACES
All pages of the system are following a consistent theme and clear structure. The occurrence
of errors should be minimized through the use of checkboxes, radio buttons and scroll down
in order to reduce the amount of text input from user. JavaScript implement in HTML in
order to provide a Data Check before submission. HTML Tables to display result to give a
clear structure that easy to understand by user. Error message should be located beside the
error input which clearly highlight and tell user how to solve it. If system error, it should
provide the contact methods. The System should provide a feedback form for all users to
give comments or asking questions. It should provide a FAQ to minimize the workload of
system administrator.
2.1.3 SOFTWARE INTERFACES
Server Side
The UOP already has the required software to host a Java web application. An Apache
Webserver will accept all requests from the client and forward SUMS specific requests to
Tomcat 5.5Servlet Container with J2EE 5.0 and Strut 1.2.8 hosting SUMS. A development
Pratham Kakkar
09115603120
T7
database will be hosted locally (using MySQL); the production database is hosted centrally
(using Oracle).
Client Side
An OS is capable of running a modern web browser which supports HTML version 3.2 or
higher.
2.2 USER CHARACTERISTICS
The users of the system are students, teachers and the administrators who maintain the system. The
users are assumed to have basic knowledge of the computers and Internet browsing. The administrators
of the system to have more knowledge of the internals of the system and is able to rectify the small
problems that may arise due to disk crashes, power failures and other catastrophes to maintain the
system. The proper user interface, user’s manual, online help and the guide to install and maintain the
system must be sufficient to educate the users on how to use the system without any problems.
2.3 GENERAL CHARACTERISTICS
The result of all the users must be stored in a database that is accessible by the Online Student Result
Management System. The university result security system must be compatible with the Internet
applications. The Online Student Result Management System is connected to the university
computer and is running all 24 hours a day. The users must have their correct usernames and
passwords to enter into the Online Student Result Management.
2.4 ASSUMPTIONS AND DEPENDENCIES
The users have sufficient knowledge of computers. The University computer should have Internet
connection and Internet server capabilities. The users know the English language, as the user
interface will be provided in English. The product can access the university student database.
3. FUNCTIONAL DESCRIPTION
3.1 FUNCTIONALITY
3.1.1 LOGIN CAPABILITIES
The system shall provide the users with login capabilities.
3.1.2 MOBILE DEVICES
The Online Student Result Management System is also supported on mobile devices such as
cell phones.
3.1.3 ALERTS
The system can alert the administrator in case of any problems.
3.1.4 USABILITY
The system shall allow the users to access the system from the Internet using HTML or its
derivative technologies. The system uses a web browser as an interface. Since all users are
familiar with the general usage of browsers, no specific training is required. The system is
user friendly and self-explanatory.
3.2 RELIABILITY
The system has to be very reliable due to the importance of data and the damages incorrect
or incomplete data can do.
3.3 AVAILABILITY
The system is available 100% for the user and is used 24 hrs a day and 365 days a year. The system
shall be operational 24 hours a day and 7 days a week.
3.4 MEAN TIME BETWEEN FAILURES (MTBF)
The system will be developed in such a way that it may fail once in a year.
3.5 MEAN TIME TO REPAIR (MTTR)
Even if the system fails, the system will be recovered back up within an hour or less.
Pratham Kakkar
09115603120
T7
3.6 ACCURACY
The accuracy of the system is limited by the accuracy of the speed at which the employees of the
library and users of the library use the system.
3.7 MAXIMUM BUGS OR DEFECT RATE
Not specified.
3.8 ACCESS RELIABILITY
The system shall provide 100% access reliability.
4. PERFORMANCE
RESPONSE TIME
The Splash Page or Result page should be able to be downloaded within a minute using a 56K modem.
The result is refreshed every two minutes. The access time for a mobile device should be less than a
minute. The system shall respond to the member in not less than two seconds from the time of the
request submittal. The system shall be allowed to take more time when doing large processing jobs.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 3
AIM: Draw use case diagram through the software Start UML.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, Star UML
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. It depicts the high-level functionality of a system
and also tells how the user handles a system. The main purpose of a use case diagram is to portray the dynamic
aspect of a system. It accumulates the system's requirement, which includes both internal as well as external
influences.
Notations of Use Case Diagram:
1.Use cases
A use case describes a function that a system performs to achieve the user’s goal. A use case must yield an
observable result that is of value to the user of the system.
2.Actors
An actor represents a role of a user that interacts with the system that you are modelling. The user can be a
human user, an organization, a machine, or another external system.
3.Subsystems
In UML models, subsystems are a type of stereotyped component that represent independent, behavioural
units in a system. Subsystems are used in class, component, and use-case diagrams to represent large-scale
components in the system that you are modelling.
4.Relationships in use-case diagrams
In UML, a relationship is a connection between model elements. A UML relationship is a type of model
element that adds semantics to a model by defining the structure and behaviour between the model elements.
Pratham Kakkar
09115603120
T7
CONCLUSION: Use Case Description of STUDENT RESULT MANAGEMENT SYSTEM has been
written successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 4
AIM: Draw the data flow diagrams at Level 0 and Level 1 for STUDENT RESULT MANAGEMENT
SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
THEORY:
Data flow diagram (DFD) is a diagram being used frequently in software design. It visually represents the
flow of data throughout processes in a given system. DFD shows the kind of information that will be input to
and output from processes as well as where the data will be stored. A typical information system involves
processing a lot of information and processes. The purpose of Data Flow Diagrams is to view systems as a
whole with its scopes and boundaries while it illustrates the movement of information between components.
The focus of DFD is on the flow of data throughout the system, not process flow. DFD allows readers to easily
see how the system will operate by knowing the kind and flow of information involved. Unlike other diagrams,
DFD can be drawn at different levels, based on the purpose they are drawn to serve.
Context Data Flow Diagram:
Context DFD is sometimes referred to as level 0 DFD. It’s the top-level diagram among all, which illustrates
the entire system in its relationship to any external entities.
Data Flow Diagram Level 1:

Level 1 DFD is the level under the context-DFD. It illustrates the main functions within the system. Level 1
breakdown the context level by including more details. It represents how the data enters and exits the system,
where it is stored and how the basic processes convert it from one form to another.
DFD Diagram Notations

External Entity
An external entity can represent a human, system or subsystem. It is where certain data comes from or goes
to. It is external to the system we study, in terms of the business process. For this reason, people used to draw
external entities on the edge of a diagram.
Process
A process is a business activity or function where the manipulation and transformation of data take place. A
process can be decomposed to a finer level of details, for representing how data is being processed within the
process.
Data Store
A data store represents the storage of persistent data required and/or produced by the process. Here are some
examples of data stores: membership forms, database tables, etc.
Data Flow
Pratham Kakkar
09115603120
T7
A data flow represents the flow of information, with its direction represented by an arrowhead that shows at
the end(s) of flow connector.
Level 0 – Data Flow Diagram
Pratham Kakkar
09115603120
T7
Level 1 – Data Flow Diagram
CONCLUSION: Level – 0 and Level – 1 Data Flow Diagram (DFD) for STUDENT RESULT
MANAGEMENT SYSTEM have been drawn successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 5
AIM: To draw the Activity diagram for STUDENT RESULT MANAGEMENT SYSTEM
REQUIREMENTS:
THEORY:
Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential, branched, or concurrent.
Activity diagrams deal with all type of flow control by using different elements such as fork, join, etc.
The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic behaviour
of the system. Other four diagrams are used to show the message flow from one object to another but activity
diagram is used to show message flow from one activity to another.
It does not show any message flow from one activity to another. Activity diagram is sometimes considered as
the flowchart. Although the diagrams look like a flowchart, they are not. It shows different flows such as
parallel, branched, concurrent, and single.
Symbol Name Use
Start/ Initial Used to represent the starting point or the initial

Node state of an activity
Activity / Used to represent the activities of the process

Action State
Action Used to represent the executable sub-areas of an

activity
Control Used to represent the flow of control from one

Flow / Edge action to the other
Pratham Kakkar
09115603120
T7
Object Flow Used to represent the path of objects moving

/ Control through the activity
Edge
Activity Used to mark the end of all control flows within

Final Node the activity
Flow Final Used to mark the end of a single control flow

Node
Decision Used to represent a conditional branch point with

Node one input and multiple outputs
Merge Node Used to represent the merging of flows. It has

several inputs, but one output.
Fork Used to represent a flow that may branch into two

or more parallel flows
Merge Used to represent two inputs that merge into one

output
Pratham Kakkar
09115603120
T7
CONCLUSION: Activity diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 6
AIM: To draw the Sequence diagram for ATM.
REQUIREMENTS:
THEORY:
A sequence diagram simply depicts interaction between objects in a sequential order i.e., the order in which
these interactions take place. We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in a system function. These diagrams
are widely used by businessmen and software developers to document and understand requirements for new
and existing systems.
Sequence Diagram Notations –
1.Actors – An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we aim to model
using the UML diagram. We use actors to depict various roles including human users and other external
subjects.
2.Lifelines – A lifeline is a named element which depicts an individual participant in a sequence diagram. So
basically, each instance in a sequence diagram is represented by a lifeline. Lifeline elements are located at the
top in a sequence diagram.
3.Messages – Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline. We represent messages using arrows. Lifelines and messages form the core of
a sequence diagram. Messages can be broadly classified into the following categories:
Synchronous messages – A synchronous message waits for a reply before the interaction can move forward.
The sender waits until the receiver has completed the processing of the message. The caller continues only
when it knows that the receiver has processed the previous message i.e., it receives a reply message.
Asynchronous Messages – An asynchronous message does not wait for a reply from the receiver. The
interaction moves forward irrespective of the receiver processing the previous message or not.
Self-Message – Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U-shaped arrow.
Reply Message – Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrowhead with a dotted line. The interaction moves
forward only when a reply message is sent by the receiver.
4.Guards – To model conditions we use guards in UML. They are used when we need to restrict the flow of
messages on the pretext of a condition being met. Guards play an important role in letting software developers
know the constraints attached to a system or a particular process.
Pratham Kakkar
09115603120
T7
CONCLUSION: Sequence diagram for ATM have been drawn successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 7
AIM: To draw the Sequence diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
THEORY:
CONCLUSION: Sequence diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 8
AIM: To draw the Class Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
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. It constitutes class names, attributes, and functions in a separate
compartment that helps in software development.
Vital components of a Class Diagram:
1.Upper Section: The upper section encompasses the name of the class. A class is a representation of similar
objects that shares the same relationships, attributes, operations, and semantics. Some of the following rules
that should be taken into account while representing a class are given below:
Capitalize the initial letter of the class name.
Place the class name in the centre of the upper section.
A class name must be written in bold format.
The name of the abstract class should be written in italics format.
2.Middle Section: The middle section constitutes the attributes, which describe the
quality of the class. The attributes have the following characteristics:
The attributes are written along with its visibility factors, which are public (+), private
(-), protected (#), and package (~).
The accessibility of an attribute class is illustrated by the visibility factors.
A meaningful name should be assigned to the attribute, which will explain its usage inside the class.
3.Lower Section: The lower section contains methods or operations. The methods are represented in the form
of a list, where each method is written in a single line. It demonstrates how a class interacts with data.
4.Relationships
In UML, relationships are of three types:
Dependency: A dependency is a semantic relationship between two or more classes where a change in one
class cause changes in another class. It forms a weaker relationship.
Generalization: A generalization is a relationship between a parent class (superclass) and a child class
(subclass). In this, the child class is inherited from the parent class.
Association: It describes a static or physical connection between two or more objects. It depicts how many
objects are there in the relationship.
5.Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more
specific than association. It defines a part-whole or part-of relationship. In this kind of relationship, the child
class can exist independently of its parent class.
6.Composition: The composition is a subset of aggregation. It portrays the dependency between the parent
and its child, which means if one part is deleted, then the other part also gets discarded. It represents a whole-
part relationship.
Pratham Kakkar
09115603120
T7
CONCLUSION: Class diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 9
AIM: To draw the Collaboration Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
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.
Notations of a Collaboration Diagram:
1.Objects: The representation of an object is done by an object symbol with its name and class underlined,
separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
The object is represented by specifying their name and class.
It is not mandatory for every class to appear.
A class may constitute more than one object.
In the collaboration diagram, firstly, the object is created, and then its class is specified.
To differentiate one object from another object, it is necessary to name them.
2.Actors: In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each actor
has its respective role and name. In this, one actor initiates the use case.
3.Links: The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a solid line. The
link helps an object to connect with or navigate to another object, such that the message flows are attached to
links.
4.Messages: It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labelled arrow, which is placed near a link.
The messages are sent from the sender to the receiver, and the direction must be navigable in that particular
direction. The receiver must understand the message.
Pratham Kakkar
09115603120
T7
CONCLUSION: Collaboration diagram for STUDENT RESULT MANAGEMNT SYSTEM have been
drawn successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 10
AIM: To draw the State Chart Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
THEORY:
The state machine diagram is also called the Statechart 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.
Notation of a State Machine Diagram:
1.Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled circle.
2.Final state: It represents the final state (end) of a system. It is denoted by a filled circle present within a
circle.
3.Decision box: It is of diamond shape that represents the decisions to be made on the basis of an evaluated
guard.
4.Transition: A change of control from one state to another due to the occurrence of some event is termed as
a transition. It is represented by an arrow labelled with an event due to which the change has ensued.
5.State box: It depicts the conditions or circumstances of a particular object of a class at a specific point of
time. A rectangle with round corners is used to represent the state box.
Pratham Kakkar
09115603120
T7
CONCLUSION: State chart diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 11
AIM: To perform various testing using the testing tool unit testing, integration testing for a sample code of
the suggested system.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
THEORY:
Unit Testing is important because software developers sometimes try saving time doing minimal unit testing
and this is myth because inappropriate unit testing leads to high-cost Defect fixing during System Testing,
Integration Testing and even Beta Testing after application is built.
Unit tests help to fix bugs early in the development cycle and save costs.
It helps the developers to understand the testing code base and enables them to makechanges quickly
Good unit tests serve as project documentation
Unit tests help with code re-use. Migrate both your code and your tests to your newproject. Tweak the code
until the tests run again.
Unit Testing is of two types
Manual
Automated
Unit testing is commonly automated but may still be performed manually. Software Engineering does not
favour one over the other but automation is preferred. A manual approachto unit testing may employ a step-
by-step instructional document.
The Unit Testing Techniques are mainly categorized into three parts which are Black box testing that involves
testing of user interface along with input and output, White box testing that involves testing the functional
behaviour of the software application and Gray box testingthat is used to execute test suites, test methods, test
cases and performing risk analysis.
Code coverage techniques used in Unit Testing are listed below:
Statement Coverage
Decision Coverage
Branch Coverage
Pratham Kakkar
09115603120
T7
Condition Coverage
Finite State Machine Coverage
Unit testing relies on mock objects being created to test sections of code that are not yet part of a complete
application. Mock objects fill in for the missing parts of the program.
For example, you might have a function that needs variables or objects that are not created yet.In unit testing,
those will be accounted for in the form of mock objects created solely for the purpose of the unit testing done
on that section of code.
There are several automated unit test software available to assist with unit testing. We will provide a few
examples below:
Junit: Junit is a free to use testing tool used for Java programming language. It providesassertions to identify
test method. This tool test data first and then inserted in the pieceof code.
NUnit: NUnit is widely used unit-testing framework use for all .net languages. It is an open-source tool which
allows writing scripts manually. It supports data-driven tests which can run in parallel.
JMockit: JMockit is open-source Unit testing tool. It is a code coverage tool with lineand path metrics. It
allows mocking API with recording and verification syntax. This tool offers Line coverage, Path Coverage,
and Data Coverage.
EMMA: EMMA is an open-source toolkit for analyzing and reporting code written in Java language. Emma
support coverage types like method, line, basic block. It is Java- based so it is without external library
dependencies and can access the source code.
PHPUnit: PHPUnit is a unit testing tool for PHP programmer. It takes small portions of code which is called
units and test each of them separately. The tool also allows developers to use pre-define assertion methods to
assert that a system behave in a certain manner.
Integration testing is defined as a type of testing where software modules are integrated logically and tested
as a group. A typical software project consists of multiple software modules, coded by different programmers.
The purpose of this level of testing is to expose defects in the interaction between these software modules
when they are integrated
Integration Testing focuses on checking data communication amongst these modules. Hence it is also termed
as 'I & T' (Integration and Testing), 'String Testing' and sometimes 'Thread Testing'.
Integration Test Case differs from other test cases in the sense it focuses mainly on the interfaces & flow of
data/information between the modules. Here priority is to be given for theintegrating links rather than the unit
functions which are already tested.
Pratham Kakkar
09115603120
T7
Sample Integration Test Cases for the following scenario: Application has 3 modules say'Login Page',
'Mailbox' and 'Delete emails' and each of them is integrated logically.
Here do not concentrate much on the Login Page testing as it's already been done in UnitTesting. But
check how it's linked to the Mail Box Page.
Similarly Mail Box: Check its integration to the Delete Mails Module.
Software Engineering defines variety of strategies to execute Integration testing, viz.
Big Bang Approach

Incremental Approach: which is further divided into the following
Top-Down Approach
Bottom-Up Approach
Sandwich Approach - Combination of Top Down and Bottom Up
CONCLUSION:
Studied unit testing and integration testing with examples successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 12
AIM: Estimation of effort using FP Estimation for chosen system.
REQUIREMENTS:
THEORY:
A Function Point (FP) is a unit of measurement to express the amount of business functionality, an information
system (as a product) provides to a user. FPs measure software size. They are widely accepted as an industry
standard for functional sizing.
FP Counting Process involves the following steps −
Step 1 − Determine the type of count.
Step 2 − Determine the boundary of the count.
Step 3 − Identify each Elementary Process (EP) required by the user.
Step 4 − Determine the unique EPs.
Step 5 − Measure data functions.
Step 6 − Measure transactional functions.
Step 7 − Calculate functional size (unadjusted function point count).
Step 8 − Determine Value Adjustment Factor (VAF).
Step 9 − Calculate adjusted function point count.
CONCLUSION:
Studied FP Estimation with examples successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 13
AIM: To draw the Component Diagram for STUDENT RESULT MANAGEMENT SYSTEM and
ORDERING SYSTEM.
REQUIREMENTS:
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 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.
Notations:
1. Component: A component is a physical and replaceable part of the system that provides or uses set
of interfaces. A component is shown as a rectangle with tabs.
2. Interfaces: A component can be connected with other components through interfaces. An interface is
a collection of operations that are used to specify services of components. A component can provide
an interface or can use services of a component.
3. Dependencies: A dependency exists between two elements. Changes to the definition of one element
may cause changes to the other. It is represented as dashed line with an arrow.
4. Realization: A component realizes an interface by providing service through interface. It is indicated
with a dashed line and a hollow arrow head.
5. Artifacts: It is used to record keeping for further reference. Attributes and operations can be added to
the artifacts.
Pratham Kakkar
09115603120
T7
CONCLUSION: Component diagram for STUDENT RESULT MANAGEMNT SYSTEM and

ORDERING SYSTEM have been drawn successfully.
Pratham Kakkar
09115603120
T7
EXPERIMENT- 14
AIM: To draw the Deployment Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
THEORY:
A deployment diagram is a UML diagram type that shows the execution architecture of a system, including
nodes such as hardware or software execution environments, and the middleware connecting them.
Deployment diagrams are typically used to visualize the physical hardware and software of a system. Using
it you can understand how the system will be physically deployed on the hardware. Deployment diagrams
help model the hardware topology of a system compared to other UML diagram types which mostly outline
the logical components of a system.
Notations:
1. Node: A node, represented as a cube, is a physical entity that executes one or more components,
subsystems or executables. A node could be a hardware or software element.
2. Artifacts: Artifacts are concrete elements that are caused by a development process. Examples of
artifacts are libraries, archives, configuration files, executable files etc.
3. Communication Association: This is represented by a solid line between two nodes. It shows the path
of communication between nodes.
CONCLUSION: Deployment diagram for STUDENT RESULT MANAGEMNT SYSTEM have been
drawn successfully.
Pratham Kakkar
09115603120
T7

Se Pratham Kakkar

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Se Pratham Kakkar

Uploaded by

Copyright:

Available Formats

ADGITM Software Engineering Lab

DR. AKHILESH DAS GUPTA INSTITUTE OF TECHNOLOGY & MANAGEMENT

SOFTWARE ENGINEERING LAB

Submitted to: Submitted by:

Following abbreviations have been used throughout this document: -

Data Flow Diagram Level 1:

DFD Diagram Notations

Level 0 – Data Flow Diagram

Level 1 – Data Flow Diagram

Symbol Name Use

Start/ Initial Used to represent the starting point or the initial

Activity / Used to represent the activities of the process

Action Used to represent the executable sub-areas of an

Control Used to represent the flow of control from one

Object Flow Used to represent the path of objects moving

Activity Used to mark the end of all control flows within

Flow Final Used to mark the end of a single control flow

Decision Used to represent a conditional branch point with

Merge Node Used to represent the merging of flows. It has

Fork Used to represent a flow that may branch into two

Merge Used to represent two inputs that merge into one

CONCLUSION: Sequence diagram for ATM have been drawn successfully.

Software Engineering defines variety of strategies to execute Integration testing, viz.

Big Bang Approach

CONCLUSION: Component diagram for STUDENT RESULT MANAGEMNT SYSTEM and

You might also like