Madhav Institute of Technology and Science, Gwalior

(A Govt. Aided UGC Autonomous & NAAC Accredited Institute Affiliated to RGPV, Bhopal)

Department of Information Technology

A
Practical File
on

Software Engineering (280403)

SUBMITTED BY
Ashish Kumar Dwivedi
0901AM211016
4th Semester
Artificial Intelligence and Machine Learning (AIML)

SUBMITTED TO
Bulbul Agrawal
Dr. Vikram Rajpoot
 Experiment – 1
Identify the requirements from problem statements.

Introduction: -
Requirements identification is the first step of any software development project. Until the requirements of a
client have been clearly identified, and verified, no other task (design, coding, testing) could begin. Usually
business analysts having domain knowledge on the subject matter discuss with clients and decide what
features are to be implemented.
In this experiment we will learn how to identify functional and non-functional requirements from a given
problem statement. Functional and non-functional requirements are the primary components of a Software
Requirements Specification.

Objectives: -
After completing this experiment, you will be able to:
 Identify ambiguities, inconsistencies and incompleteness from a requirements specification.
 Identify and state functional requirements.
 Identify and state non-functional requirements.

Requirements: -
Sommerville defines "requirement" [1] as a specification of what should be implemented. Requirements
specify how the target system should behave. It specifies what to do, but not how to do. Requirements
engineering refers to the process of understanding what a customer expects from the system to be developed,
and to document them in a standard and easily readable and understandable format. This documentation will
serve as reference for the subsequent design, implementation and verification of the system.

It is necessary and important that before we start planning, design and implementation of the software
system for our client, we are clear about it's requirements. If we don't have a clear vision of what is to be
developed and what all features are expected, there would be serious problems, and customer dissatisfaction
as well.

Characteristics of Requirements: -
Requirements gathered for any new system to be developed should exhibit the following three properties:
 Unambiguity: There should not be any ambiguity what a system to be developed should do. For
example, consider you are developing a web application for your client. The client requires that
enough number of people should be able to access the application simultaneously. What's the
"enough number of people"? That could mean 10 to you, but, perhaps, 100 to the client. There's an
ambiguity.
  Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose one of the clients
say that it the radiation level inside the plant exceeds R1, all reactors should be shut down. However,
another person from the client side suggests that the threshold radiation level should be R2. Thus,
there is an inconsistency between the two end users regarding what they consider as threshold level
of radiation.
 Completeness: A particular requirement for a system should specify what the system should do and
also what it should not. For example, consider a software to be developed for ATM. If a customer
enters an amount greater than the maximum permissible withdrawal amount, the ATM should
display an error message, and it should not dispense any cash.

Categorization of Requirement : -
Based on the target audience or subject matter, requirements can be classified into different types, as stated
below:
 User requirements: They are written in natural language so that both customers can verify their
requirements have been correctly identified.
 System requirements: They are written involving technical terms and/or specifications, and are meant
for the development or testing teams
Requirements can be classified into two groups based on what they describe:
 Functional requirements (FRs): These describe the functionality of a system -- how a system should
react to a particular set of inputs and what should be the corresponding output.
 Non-functional requirements (NFRs): They are not directly related what functionalities are expected
from the system. However, NFRs could typically define how the system should behave under certain
situations. For example, a NFR could say that the system should work with 128MB RAM. Under
such condition, a NFR could be more critical than a FR.
Non-functional requirements could be further classified into different types like:
 Product requirements: For example, a specification that the web application should use only plain
HTML, and no frames.
 Performance requirements: For example, the system should remain available 24x7
 Organizational requirements: The development process should comply to SEI CMM level 4
and some other are
Portability, Security, Maintainability, Reliability, Scalability, Performance, Reusability,
Flexibility

Functional Requirements: -
Identifying Functional Requirements
Given a problem statement, the functional requirements could be identified by focusing on the following
points:
Identify the high-level functional requirements simply from the conceptual understanding of the problem.
For example, a Library Management System, apart from anything else, should be able to issue and return
books.
Identify the cases where an end user gets some meaningful work done by using the system. For example, in
a digital library a user might use the "Search Book" functionality to obtain information about the books of
his interest.
If we consider the system as a black box, there would be some inputs to it, and some output in return. This
black box defines the functionalities of the system. For example, to search for a book, user gives title of the
book as input and get the book details and location as the output.
Any high-level requirement identified could have different sub-requirements. For example, "Issue Book"
module could behave differently for different class of users, or for a particular user who has issued the book
thrice consecutively.

Preparing Software Requirements Specifications: -

Once all possible FRs and non-FRs have been identified, which are complete, consistent, and non-
ambiguous, the Software Requirements Specification (SRS) is to be prepared. IEEE provides a template [iv],
also available here, which could be used for this purpose. The SRS is prepared by the service provider, and
verified by its client. This document serves as a legal agreement between the client and the service provider.
Once the concerned system has been developed and deployed, and a proposed feature was not found to be
present in the system, the client can point this out from the SRS. Also, if after delivery, the client says a new
feature is required, which was not mentioned in the SRS, the service provider can again point to the SRS.
The scope of the current experiment, however, doesn't cover writing a SRS.
Case study: -
Project Definition: -
 Historically, operations such as student information, admission forms, accept from process, merit list
process, pending/doubtful case, and admission forms waiting list process were done manually
writing this information on paper
 Clerical staff for recording day to day transactions generally maintains this system
 Computerization enables to keep record of reservation transaction through the historic records of
business transactions.

Functional Requirements: -
1) Student information
 " In this system student detail are filled student details like student no, name, mark
 sheet, etc. are filled.
 It is used when the new student is taking admission in the school when all the
 personal detail of a student is filled up.
 If student is transferred from the other college then all the details of that is written in that.
2) Fees register file: -
In this we store which student has pay fees and which student fees and which student fees are pending.

3) Merit list and waiting list: -

In this which student has which merit no, and he can get the admission in this college and which should have
probability about the forget admission in this college.
4) Admitted student’s file: -
In this we can also see the admitted student divisions.

5) Division wise register file: -

In this system we can also see the admitted students’ divisions.
6) Generate various report: -
As per the requirement all the reports is generated reports like approved merit
list, waiting list, various admission reports, waiting list, various admission
reports, fees collected report etc.

Nonfunctional requirement :->

 This system is used by only the authorized person.
 In this system only for Engineering student no other college course.
 In this system we cannot see information of student who are cancelled who have does not pay the
fee.
 Experiment – 2
Estimation of project metrics using estimation techniques like COCOMO model

Introduction: -
Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of the most
generally used software estimation models in the world. COCOMO predicts the efforts and schedule of a
software product based on the size of the software.

Project Estimation Techniques: -

A software project is not just about writing a few hundred lines of source code to achieve a particular
objective. The scope of a software project is comparatively quite large, and such a project could take several
years to complete. However, the phrase "quite large" could only give some (possibly vague) qualitative
information. As in any other science and engineering discipline, one would be interested to measure how
complex a project is. One of the major activities of the project planning phase, therefore, is to estimate
various project parameters in order to take proper decisions. Some important project parameters that are
estimated include:

 Project size: What would be the size of the code written say, in number of lines, files, modules?
 Cost: How much would it cost to develop a software? A software may be just pieces of code, but one
has to pay to the managers, developers, and other project personnel.
 Duration: How long would it be before the software is delivered to the clients?
 Effort: How much effort from the team members would be required to create the software?

The necessary steps in this model are:

 Get an initial estimate of the development effort from evaluation of thousands of delivered lines of
source code (KDLOC).
 Determine a set of 15 multiplying factors from various attributes of the project.
 Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e.,
multiply the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form used in
the static single variable models, using KDLOC as the measure of the size. To determine the initial
effort Ei in person-months the equation used is of the type is shown below

Ei=a*(KDLOC)b

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded
 1.Organic: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is reasonably
small, and the team members are experienced in developing similar methods of projects. Examples
of this type of projects are simple business systems, simple inventory management systems, and data
processing systems.

2. Semidetached: A development project can be treated with semidetached type if the development
consists of a mixture of experienced and inexperienced staff. Team members may have finite
experience in related systems but may be unfamiliar with some aspects of the order being developed.
Example of Semidetached system includes developing a new operating system (OS), a Database
Management System (DBMS), and complex inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software being

developed is strongly coupled to complex hardware, or if the stringent regulations on the operational
method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a unit
of person month) and development time from the size of estimation in KLOC(Kilo Line of code)
efforts estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks,
etc.

According to Boehm, software cost estimation should be done through three stages:
 Basic Model
 Intermediate Model
 Detailed Model
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

Objectives: -

 Categorize projects using COCOMO, and estimate effort and development time required for
a project
 Estimate the program complexity and effort required to recreate it using Halstead's metrics
The model consists of three levels of estimation: -
Basic COCOMO: - This level provides a rough estimate of the cost of a software
project, based on the size of the project and a few other basic factors, and the
formula for estimation is
Effort = a * (KDSI)b PM
Tdev = 2.5 * (Effort)c Months , where
 • KDSI is the estimated size of the software expressed in Kilo Delivered
Source Instructions
• a, b, c are constants determined by the category of software project
• Effort denotes the total effort required for the software development,
expressed in person months (PMs)
• Tdev denotes the estimated time required to develop the software (expressed
in months)
Intermediate COCOMO model: -The basic COCOMO model considers that
effort and development time depends only on the size of the software. However,
in real life there are many other project parameters that influence the
development process. The intermediate COCOMO take those other factors into
consideration by defining a set of 15 cost drivers (multipliers) . Thus, any
project that makes use of modern programming practices would have lower
estimates in terms of effort and cost. Each of the 15 such attributes can be rated
on a six-point scale ranging from "very low" to "extra high" in their relative
order of importance. Each attribute has an effort multiplier fixed as per the
rating. The product of effort multipliers of all the 15 attributes gives the Effort
Adjustment Factor (EAF).
EAF is used to refine the estimates obtained by basic COCOMO as follows:
Effort|corrected = Effort * EAF
Tdev|corrected = 2.5 * (Effort| corrected) c
Complete COCOMO model: - Both the basic and intermediate COCOMO
models consider a software to be a single homogeneous entity -- an assumption,
which is rarely true. The complete COCOMO model provide a far more
accurate estimate of project metrics. The Complete COCOMO Model provides a
more detailed estimate of the cost of a software project than either the Basic
COCOMO Model or the Intermediate COCOMO Model. This allows for a
better understanding of the factors that can impact the cost of a software project,
and helps to identify areas where cost savings can be made

Halstead's Complexity Metrics

Halstead took a linguistic approach to determine the complexity of a program. According to him, a computer
program consists of a collection of different operands and operators. The definition of operands and operators
could, however, vary from one person to another and one programming language to other. Operands are
usually the implementation variables or constants -- something upon which an operation could be performed.
Operators are those symbols that affects the value of operands. Halstead's metrics are computed based on the
operators and operands used in a computer program. Any given program has the following four parameters:

 n1: Number of unique operators used in the program

 n2: Number of unique operands used in the program
 N1: Total number of operators used in the program
 N2: Total number of operands used in the program
Using the above parameters one compute the following metrics:

 Program Length: N = N1 + N2
 Program Vocabulary: n = n1 + n2
 Volume: V = N * lg n
 Difficulty: D = (n1 * N2) / (2 * n2)
 Effort: E = D * V
 Time to Implement: T = E / 18 (in seconds)
The program volume V is the minimum number of bits needed to encode the program. It represents the
size of the program while taking into account the programming language.
The difficulty metric indicates how difficult a program is to write or understand.
Effort denotes the "mental effort" required to develop the software, or to recreate the same in another
programming language .

Observation: -
Case Study: - Cost Estimation for a New Software Project

Project Background: A software development company has been approached by a client to develop a new
software project. The client has provided the following information:
The project size is estimated to be 50,000 lines of code (LOC).
The development will be done in-house, with a team of 10 developers.
The development will be done using the latest technologies and tools.
The development environment is expected to be stable and well-defined.
The project is expected to have a moderate level of complexity.
Using the COCOMO model, the software development company can estimate the cost and effort required
to complete the project.

Step 1: Determine the Project Mode

The first step in the COCOMO model is to determine the project mode, which determines the level of detail
required in the estimate. There are three modes in COCOMO: Organic, Semi-Detached, and Embedded.
In this case study, the development will be done in-house, with a well-defined development environment,
so the project mode is Semi-Detached.

Step 2: Determine the Cost Driver Scale Factor

The next step is to determine the cost driver scale factor, which takes into account various factors that
affect the cost and effort of the project, such as the project size, complexity, and development environment.
For the Semi-Detached mode, the cost driver scale factor can be calculated using the following formula:

Cost Driver Scale Factor = 3.2 * (KLOC)^0.5 * (PM)^E

Where:
KLOC = Project size in thousands of lines of code (LOC/1000)
PM = Project Mode adjustment factor
E = Cost driver exponent
For this case study, the project size is 50,000 LOC, so KLOC = 50,000/1000 = 50.
The PM adjustment factor for the Semi-Detached mode is 1.05, and the cost driver exponent is 0.38.

So, Cost Driver Scale Factor = 3.2 * (50)^0.5 * (1.05)^0.38 = 3.4

Step 3: Calculate the Effort and Cost

Finally, the effort and cost can be calculated using the following formulas:
Effort = 2.5 * (KLOC)^1.05 * (Cost Driver Scale Factor)
Cost = Effort * Average Staffing Level * Staffing Cost
For this case study, the average staffing level is 10 developers, and the staffing cost is $100 per hour.
So, Effort = 2.5 * (50)^1.05 * (3.4) = 385.5 person-months
Cost = 385.5 * 10 * $100 = $385,500
Based on these calculations, the software development company can estimate that the project will require
an effort of 385.5 person-months and a cost of $385,500 to complete.
Advantages of COCOMO Model in Software Engineering:

Advantage Description

Simple and The COCOMO model is simple to use and straightforward, making it easy
straightforward for software engineers to understand and implement.

The COCOMO model can be easily reused for different software projects,
Reusable reducing the time and effort required to develop new cost models.

The COCOMO model provides a useful and reliable estimate of the cost of
a software project, enabling project managers to make informed decisions
Cost estimation about resource allocation.

The COCOMO model takes into account important project characteristics

Consideration of such as project size, development environment, and personnel experience,
project characteristics which helps to produce more accurate cost estimates.

Disadvantages of COCOMO Model in Software Engineering:

Disadvantage Description

The COCOMO model is based on a number of assumptions, which can

Limited accuracy result in a limited accuracy of the cost estimates produced.

The COCOMO model is a one-size-fits-all approach, which can be

Lack of flexibility limiting for projects that have unique or specialized requirements.
 Disadvantage Description

The COCOMO model does not take into account the possibility of
Inadequate consideration of changing project requirements, which can significantly impact the cost
changing requirements of a software project.

The COCOMO model assumes a traditional, hierarchical project team

Inflexibility with regards to structure, which may not reflect the team structure of modern software
project team structure development projects.
 Experiment – 3
Introduction to StarUML

Introduction: -
Open-source modeling software that is used in Unified Modelling Language where system and software
modeling is supported with the UML concept to generate code for different languages by providing
different types of UML diagrams to develop a fast and flexible UML platform so that requirements and
design are given before starting the project where it is called as a big upfront design approach for the users
who require the software designs to improve their project and hence to support their UML design diagrams
in the system. In this topic, we are going to learn about StarUML.
How StarUML works?: -
Below are the points explaining the works of starUML:
 StarUML is an open source software that can be installed directly from the homepage of the website
and it is licensed under GNU Public License. A new project by approach link on the home page is
available from where an empty project can be selected. Set as the default approach should be
unchecked so that users can create projects of customized versions. On the model explorer, by
selecting the untitled model, go to Add or Design model, and Add or Design diagrams. This will help
to create the diagrams of the user’s taste and modify them based on the functionalities.
 The profile can be set, which gives different symbols and conventions to be used. It is important to
include a Java profile in the project so that java code is generated. If multiple users are working on the
same project, it is good to describe better understanding. Save the project in a suitable location to
access it easily. The class can be created from the toolbox and a proper name can be given to the same.
Attributes can be added to the same. The data type should be selected, and the design model can be
expanded to see the full view of the project created. An interface is created by selecting the interface
and suppressing the operations option. This will make the user see the interface with the diagrams in
view.
 UML class diagrams can be created easily with the help of StarUML. While creating the diagram, java
stub code is easily generated in the diagrams and hence if any changes have to be made in the
diagram, it can be done by modifying the diagram in the backend. While creating the diagram, code is
generated but not specifically on the class structures. To modify the structures, the code can be edited
and the functionalities of the structure can be added. Thus, the code describes what each structure does
in the diagram.
 There are many options available to modify the diagram drawn. It is easy to draw it with the options
given and once familiar, anyone can draw it easily.
Benefits: -
Below are the benefits of staruml in detail:
A most important advantage is that the user can generate codes from the diagram drawn. Anyone who is
not interested in the front-end diagrams can use the backend coding to add the functionality, change the
diagram to their need, and modify it as per the usage by changing the Java code. This makes reverse
engineering possible i.e. generating a diagram from the code that is formed initially from the diagram
drawn.
 The user interface is known to all as it uses visual studio along with other coding languages such as C and
C#. Also, the diagrams drawn in UML software can be exported into JPG.XMI formats help the user to
identify and check the patterns in different formats and to explore more options.
StarUML is faster, flexible, and can be extended to accommodate other codes in the diagram. The
extensive features make the users fall in love. If mistakes happen, we can undo and make adjustments. This
feature is not applicable in some UML tools.
Anyone can understand the framework, and hence the architecture can be modified for the extensive use of
the software. Performance and security can be tracked easily with the help of StarUML. Documentation is
provided with proper guidelines to improve the business processes. StarUML is the visual language that
communicates information to the users in a diagrammatic manner.
The tools in StarUML help to know the requirements in the system and apply the design patterns so that
proper analysis can be done to understand and modify the diagrams. These tools are open source and for
more high requirements, tools can be purchased from the software vendors.

Applications of StarUML in various fields: -

 Unified modeling diagrams and class diagrams can be created easily in StarUML that can be used in
the design industry to know the product flow from one field to another and also to analyze the
product’s usage in different fields. Properties of the product can be incorporated within the diagram so
that the user can easily understand the product and modify the properties if needed. Data modeling
helps to know the product and apply the properties to other streams.
 In the manufacturing industry, the user can know the number of products with their varieties. With the
knowledge of inventory in the industry, product manufacturing can be controlled and directed
efficiently. Diagrams direct the user about the steps to be done, manage the goods to shipment, and do
the transaction with the customers. These understandings can be done with the help of a single
diagram rather than using an entire record.
 In the hospitality sector and hospitals, the UML diagram can direct visitors to the proper places. The
doctors in hospitals can be made to go through the diagram once to know the routine timetable they
should follow daily. In hotels, available provisions can be drawn with the help of a UML diagram so
that the visitors will get to know the privileges at a glance.
 Diagrams help to save time and to understand the process flow better. StarUML helps to know the
class diagrams and to know the process so that the users can change or get the knowledge of the same.
Conclusion: -
StarUML is a software tool for creating UML (Unified Modeling Language) diagrams. It provides features
for creating class diagrams, use case diagrams, state diagrams, activity diagrams, and other types of UML
diagrams. StarUML supports modeling and reverse engineering of source code, and has a user-friendly
interface that makes it easy to use for software developers, analysts, and designers.
 Experiment – 4
Introduction to Flow Charts (using StarUML)
Introduction: -
A flowchart is a type of diagram that represents a process or a system, by showing the steps or tasks
involved and the flow of control from one step to another. The flowchart uses symbols, such as rectangles,
diamonds, and arrows, to represent the different elements of the process, making it easy to understand and
communicate.
Flowcharts are widely used in various fields, such as software development, project management, business
processes, and many others, to represent processes graphically, analyze them for efficiency and identify
bottlenecks, and communicate the process to stakeholders.
In software development, flowcharts are often used to represent algorithms, logic, or the flow of control in
a program. In project management, flowcharts can be used to represent the different phases and tasks
involved in a project, and their dependencies. In business processes, flowcharts can be used to represent the
steps involved in a process, such as order processing, customer service, and many others.
Overall, flowcharts provide a visual representation of a process that helps to understand, analyze, and
communicate the process more effectively.

Representation: -

Some common symbol and their uses: -

Below is a table that summarizes the commonly used symbols in flowcharts:
 Symbol Description

Represent the beginning and end of the process. Typically, represented by an oval with
Start/End "Start" or "End" written inside.

Represent a task or an action in the process. Typically, represented by a rectangle with

Process the task name or description written inside.

Represent a branching point in the process where the flow splits based on certain
Decision conditions. Typically, represented by a diamond shape with a question inside.

Represent the inputs and outputs of a process. Typically, represented by

Input/Output parallelograms.

Represent the flow of control between elements. Typically, represented by arrows

Connector connecting the elements.

Represent a document or a record used in the process. Typically, represented by a

rectangle with the document name or description written inside and with a folded
Document corner.

Data Represent data stored in the process. Typically, represented by a cylinder.

It's important to note that different modeling techniques may use slightly different symbols, but the basic
concepts remain the same.
Process to make Flow-Chart in StarUML: -
1) Launch the StarUML software in your system
2) Goto Model>Add Diagram>Flowchart Diagram

3) Now start making your Flowchart using above information and UI of StarUML

Example: - The given below flowchart represents our Lab routine.

 Experiment – 5
E-R modeling from the problem statements
Introduction: - ER-modeling is a data modeling method used in software engineering to produce a
conceptual data model of an information system. Diagrams created using this ER-modeling method
are called Entity-Relationship Diagrams or ER diagrams or ERDs.

Purpose of ERD
The database analyst gains a better understanding of the data to be contained in the database through
the step of constructing the ERD.
The ERD serves as a documentation tool.
Finally, the ERD is used to connect the logical structure of the database to users. In particular, the
ERD effectively communicates the logic of the database to users.

Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An
entity is denoted as a rectangle in an ER diagram. For example, in a school database, students,
teachers, classes, and courses offered can be treated as entities. All these entities have some attributes
or properties that give them their identity.

Entity Set
An entity set is a collection of related types of entities. An entity set may include entities with
attribute sharing similar values. For example, a Student set may contain all the students of a
school; likewise, a Teacher set may include all the teachers of a school from all faculties. Entity
set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values. For
example, a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a student's
name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.

There are four types of Attributes:

1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity
among the entity set. For example, the roll_number of a student makes him identifiable among
students.
There are mainly three types of keys:

Super key: A set of attributes that collectively identifies an entity in the entity set.
Candidate key: A minimal super key is known as a candidate key. An entity set may have more
than one candidate key.
Primary key: A primary key is one of the candidate keys chosen by the database designer to
uniquely identify the entity set.
2. Composite attribute: An attribute that is a combination of other attributes is called a composite
attribute. For example, In student entity, the student address is a composite attribute as an address is
composed of other characteristics such as pin code, state, country.
 3. Single-valued attribute: Single-valued attribute contain a single value. For example,
Social_Security_Number.

4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a multi-
valued attribute. Multi-valued attributes are depicted by the double ellipse. For example, a person
can have more than one phone number, email-address, etc.
5. Derived attribute: Derived attributes are the attribute that does not exist in the physical database,
but their values are derived from other attributes present in the database. For example, age can be
derived from date of birth. In the ER diagram, Derived attributes are depicted by the dashed ellipse.
3. Relationships
The association among entities is known as relationship. Relationships are represented by the
diamond-shaped box. For example, an employee works_at a department, a student enrolls in a course.
Here, Works_at and Enrolls are called relationships
Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a relationship too
can have attributes. These attributes are called descriptive attributes.
Degree of a relationship set
The number of participating entities in a relationship describes the degree of the relationship. The
three most common relationships in E-R models are:
1. Unary relationship: This is also called recursive relationships. It is a relationship between the
instances of one entity type. For example, one person is married to only one person.
2. Binary relationship: It is a relationship between the instances of two entity types. For example,
the Teacher teaches the subject.
3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the
relationships "may have" provide the association of three entities, i.e., TEACHER, STUDENT, and
SUBJECT. All three entities are many-to-many participants. There may be one or many participants
in a ternary relationship.

In general, "n" entities can be related by the same relationship and is known as N-ary relationship.

Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the number
of entities of other sets via relationship set.

Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity set B
and vice versa. Let us assume that each student has only one student ID, and each student ID is
assigned to only one person. So, the relationship will be one to one.
 2. One to many: When a single instance of an entity is associated with more than one instances of
another entity then it is called one to many relationships. For example, a client can place many orders;
a order cannot be placed by many customers.
3. Many to One: More than one entity from entity set A can be associated with at most one entity of
entity set B, however an entity from entity set B can be associated with more than one entity from
entity set A. For example - many students can study in a single college, but a student cannot study in
many colleges at the same time.
4. Many to Many: One entity from A can be associated with more than one entity from B and vice-
versa. For example, the student can be assigned to many projects, and a project can be assigned to
many students.
In Entity-Relationship (ER) diagrams, various symbols are used to represent entities, attributes,
relationships, and cardinalities. Below is a table that summarizes the commonly used symbols in ER
diagrams:

Symbol Description

Rectangle Represent an entity. The name of the entity is written inside the rectangle.

Represent an attribute of an entity. The name of the attribute is written inside the
Ellipse ellipse.

Represent a relationship between two entities. The name of the relationship is

Diamond written inside the diamond.

Line Connect entities to their attributes or to other entities to show the relationships.

Single Arrowhead Indicates a one-to-one (1:1) relationship between entities.

Double Arrowhead Indicates a one-to-many (1:N) relationship between entities.

Crow's Foot Indicates a many-to-many (M:N) relationship between entities.

 Symbol Description

Bar above an
attribute Indicates that the attribute is a primary key.

It's important to note that different modeling techniques may use slightly different symbols, but the basic
concepts remain the same.

Objectives: -
Identify entity sets, their attributes, and various relationships
Represent the data model through ER diagram

Entity-Relationship diagram: -
The given below Entity-Relationship diagram represents our library management system.
 Experiment-6
Introduction to Use-case Diagram (using Star UML)

Introduction:
Use-case diagrams describe the high-level functions and scope of a system. These diagrams also identify the
interactions between the system and its actors. A use case diagram is used to represent the dynamic behavior
of a system. 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 tells how the user handles a system.
A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that is used to represent the
interactions between actors and systems. The primary purpose of a Use Case Diagram is to capture the
functional requirements of a system. Use case diagram is a platform that can provide a common
understanding for the end-users, developers, and the domain experts. It is used to capture the basic
functionality i.e., use cases, and the users of those available functionality, i.e., actors, from a given problem
statement.

Use Case Diagrams are useful for modeling the functional requirements of a system, by capturing the
interactions between the actors (users or systems) and the system being developed. Use Case Diagrams
provide a high-level view of the functional requirements and can be used to validate the functional
requirements with stakeholders, to identify potential problems, and to identify areas where the functional
requirements can be improved.

A Use Case Diagram is typically composed of the following elements:

Actors-The users that interact with a system. An actor can be a person, an organization, or an outside
system that interacts with your application or system. They must be external objects that produce or
consume data.

Use Case: Represent the functional requirements of the system, by representing the interactions between
the actors and the system. Use Cases are represented as ovals and are named using verb-noun phrases that
describe the interactions.

Association Lines: Represent the relationships between actors and use cases. Association lines connect
actors to use cases to indicate that the actor interacts with the use case.
System Boundary: Represents the boundary of the system being developed. The system boundary is
represented as a rectangle that surrounds the use cases and actors.

Include Relationship: Represents a relationship between use cases, where one use case includes the
behavior of another use case. The include relationship is represented as a directed arrow that points from
the including use case to the included use case.

Extend Relationship: Represents a relationship between use cases, where one use case extends the behavior
of another use case. The extend relationship is represented as a directed arrow that points from the
extending use case to the extended use case.

Generalization Relationship: Represents a relationship between actors, where one actor is a generalization
of another actor. The generalization relationship is represented as a solid arrow with an open arrowhead
that points from the specialized actor to the generalized actor.

Use-case Diagram:
 Experiment – 7
Aim: Modelling Data Flow Diagrams.

Theory:
DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is represented
by DFD. It also gives insight into the inputs and outputs of each entity and the process itself. DFD does
not have control flow and no loops or decision rules are present. Specific operations depending on the type
of data can be explained by a flowchart.
It is a graphical tool, useful for communicating with users ,managers and other personnel. it is useful for
analyzing existing as well as proposed system.
It provides an overview of
 What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.
There are four main components of a DFD:

Processes: These are the actions or activities that transform the data from one form to another. Processes are
represented as rectangles in a DFD.

Data Flows: These are the paths that the data takes as it moves through the system. Data flows are represented
as arrows in a DFD.

Data Stores: These are the places where the data is stored within the system. Data stores are represented as
rectangles with two parallel lines at the top and bottom in a DFD.

External Entities: These are the sources or destinations of the data outside of the system. External entities are
represented as squares in a DFD.

Levels of DFD:
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD are as
follows:
 0-level DFD: It represents the entire system as a single bubble and provides an overall picture of the
system.
 1-level DFD: It represents the main functions of the system and how they interact with each other.
 2-level DFD: It represents the processes within each function of the system and how they interact
with each other.
 3-level DFD: It represents the data flow within each process and how the data is transformed and
stored.
Advantages of DFD:
 It helps us to understand the functioning and the limits of a system.
 It is a graphical representation which is very easy to understand as it helps visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical person because they are
very easy to understand.

Disadvantages of DFD:
 At times DFD can confuse the programmers regarding the system.
 Data Flow Diagram takes long time to be generated, and many times due to these reasons analysts
are denied permission to work on it.

DFD on online banking:

 Experiment – 8
Aim: State chart and Activity Modelling.

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 behavioral diagram.

Components of an Activity Diagram:

Initial Node: This is the starting point of the activity diagram, represented by a solid circle.

Activity: Activities represent the tasks or actions that occur in the system or process. They are represented by
rectangles with rounded corners.

Decision Node: This node represents a decision point in the process where the flow of activity can take
different paths. It is represented by a diamond shape.

Merge Node: This node represents the merging of different paths of activity back into a single flow. It is
represented by a diamond shape with a plus sign inside.

Fork Node: This node represents the branching of activity into multiple concurrent paths. It is represented
by a solid vertical line with multiple arrows.

Join Node: This node represents the merging of multiple concurrent paths of activity back into a single flow.
It is represented by a solid vertical line with multiple arrows and a circle at the end.

Final Node: This node represents the end of the activity diagram and the completion of the process. It is
represented by a solid circle with a border.

Object Node: This node represents an object in the system that participates in the activity flow. It is
represented by a rectangle with a thick border.
Control Flow: This is the directional arrow that connects the different nodes and represents the flow of
activity between them. It is represented by a solid line with an arrowhead.

Flow Final: This is a special type of final node that represents the end of a flow within an activity. It is
represented by a solid circle with a border and a small x inside.

Activity diagram on Money withdrawal from ATM:

 Experiment – 9
Aim: Designing Test Suites

Introduction
Development of a new software, like any other product, remains incomplete until it subjected to exhaustive
tests. The primary objective of testing is not to verify that all desired features have been implemented
correctly. However, it also includes verification of the software behavior in case of "bad inputs".

In this experiment we discuss in brief about different types of testing and provide mechanisms to have
hands-on experience on unit testing.

Software Testing
Testing software is an important part of the development life cycle of a software. It is an expensive
activity. Hence, appropriate testing methods are necessary for ensuring the reliability of a program.
According to the ANSI/IEEE 1059 standard, the definition of testing is the process of analyzing a
software item, to detect the differences between existing and required conditions i.e. defects/errors/bugs
and to evaluate the features of the software item.

The purpose of testing is to verify and validate a software and to find the defects present in a software.
The purpose of finding those problems is to get them fixed.

Verification is the checking, or we can say the testing of software for consistency and conformance by
evaluating the results against pre-specified requirements.
Validation looks at the systems correctness, i.e., the process of checking that what has been specified is
what the user wanted.
Defect is a variance between the expected and actual result. The defect’s ultimate source may be traced to
a fault introduced in the specification, design, or development (coding) phases.
Standards for Software Test Documentation
IEEE 829-1998 is known as the 829 Standard for Software Test Documentation. It is an IEEE standard
that specifies the form of a set of documents for use in software testing. There are other different
standards discussed below.

IEEE 1008, a standard for unit testing

IEEE 1012, a standard for Software Verification and Validation
IEEE 1028, a standard for software inspections
IEEE 1044, a standard for the classification of software anomalies
IEEE 1044-1, a guide to the classification of software anomalies
IEEE 830, a guide for developing system requirements specifications.
IEEE 730, a standard for software quality assurance plans
IEEE 1061, a standard for software quality metrics and methodology
IEEE 12207, a standard for software life cycle processes and life cycle data
BS 7925-1, a vocabulary of terms used in software testing.
BS 7925-2, a standard for software component testing
Testing Frameworks
Following are the different testing frameworks:

 jUnit - for Java unit test

 Selenium - is a suite of tools for automating web applications for software testing purposes, plugin
for Firefox.
 HP QC - is the HP Web-based test management tool. It familiarizes with the process of defining
releases, specifying requirements, planning tests, executing tests, tracking defects, alerting on
changes, and analyzing results. It also shows how to customize project
 IBM Rational - Rational software has a solution to support business sector for designing,
implementing, and testing software.
Need for Software Testing
There are many reasons for why we should test software, such as:

 Software testing identifies the software faults. The removal of faults helps reduce the number of
system failures. Reducing failures improves the reliability and the quality of the systems.
 Software testing can also improve the other system qualities such as maintainability, usability, and
testability.
 To meet the condition that the last few years of the 20th century systems had to be shown to be
free from the ‘millennium bug’.
 To meet the different legal requirements.
 To meet industry specific standards such as the Aerospace, Missile and Railway Signaling
standards.
Test Cases and Test Suite
A test case describes an input description and an expected output description. Input is of two types:
preconditions (circumstances that hold prior to test case execution) and the actual inputs that are identified
by some testing methods. The set of test cases is called a test suite. We may have a test suite of all possible
test cases.

Types of Software Testing

Testing is done in every stage of software development life cycle, but the testing done at each level of
software development is different in nature and has different objectives. There are different types of testing,
such as stress testing, volume testing, configuration testing, compatibility testing, recovery testing,
maintenance testing, documentation testing, and usability testing. Software testing are mainly of following
types.

1. Unit Testing
2. Integration Testing
3. System Testing

Unit Testing
Unit testing is done at the lowest level. It tests the basic unit of software, that is the smallest testable piece
of software. The individual component or unit of a program are tested in unit testing. Unit testing are of
two types.
  Black box testing: This is also known as functional testing, where the test cases are designed based
on input output values only. There are many types of Black Box Testing but following are the
prominent ones.
- Equivalence class partitioning: In this approach, the domain of input values to a program is divided into
a set of equivalence classes. e.g., Consider a software program that computes whether an integer number
is even or not that is in the range of 0 to 10. Determine the equivalence class test suite. There are three
equivalence classes for this program. - The set of negative integers - The integers in the range 0 to 10 -
The integer larger than 10

- Boundary value analysis: In this approach, while designing the test cases, the values at boundaries of
different equivalence classes are taken into consideration. e.g. In the above given example as in
equivalence class partitioning, a boundary values based test suite is {0, -1, 10, 11 }

White box testing: It is also known as structural testing. In this testing, test cases are designed based on
examination of the code. This testing is performed based on the knowledge of how the system is
implemented. It includes analyzing data flow, control flow, information flow, coding practices, exception,
and error handling within the system, to test the intended and unintended software behavior. White box
testing can be performed to validate whether code implementation follows intended design, to validate
implemented security functionality, and to uncover exploitable vulnerabilities. This testing requires access
to the source code. Though white box testing can be performed any time in the life cycle after the code is
developed, but it is a good practice to perform white box testing during the unit testing phase.
Integration Testing
Integration testing is performed when two or more tested units are combined into a larger structure. The
main objective of this testing is to check whether the different modules of a program interface with each
other properly or not. This testing is mainly of two types:

1. Top-down approach
2. Bottom-up approach

In bottom-up approach, each subsystem is tested separately and then the full system is tested. But the top-
down integration testing starts with the main routine and one or two subordinate routines in the system.
After the top-level ‘skeleton’ has been tested, the immediately subroutines of the ‘skeleton’ are combined
with it and tested.

System Testing
System testing tends to affirm the end-to-end quality of the entire system. System testing is often based on
the functional / requirement specification of the system. Non-functional quality attributes, such as
reliability, security, and maintainability are also checked. There are three types of system testing

Alpha testing is done by the developers who develop the software. This testing is also done by the client
or an outsider with the presence of developer or we can say tester.
Beta testing is done by very few numbers of end users before the delivery, where the change requests are
fixed, if the user gives any feedback or reports any type of defect.
User Acceptance testing is also another level of the system testing process where the system is tested for
acceptability. This test evaluates the system's compliance with the client requirements and assess whether
it is acceptable for software delivery.
An error correction may introduce new errors. Therefore, after every round of error-fixing, another testing
is carried out, i.e., called regression testing. Regression testing does not belong to either unit testing,
integration testing, or system testing, instead, it is a separate dimension to these three forms of testing.

Regression Testing

The purpose of regression testing is to ensure that bug fixes and new functionality introduced in a software
do not adversely affect the unmodified parts of the program [2]. Regression testing is an important activity
at both testing and maintenance phases. When a piece of software is modified, it is necessary to ensure that
the quality of the software is preserved. To this end, regression testing is to retest the software using the test
cases selected from the original test suite.

Example-
Write a program to calculate the square of a number in the range 1-100.

Output-

Inputs Outputs
I1 : -2 O1 : Beyond the
range I2 : 0 O2 : Beyond the
range
I3 : 1 O3 : Square of 1 is 1
I4 : 100 O4 : Square of 100 is
10000I5 : 101 O5 : Beyond the range
I6 : 4 O6 : Square of 4 is 16
I7 : 62 O7 : Square of 62 is
3844Test Cases
T1 : {I1 ,O1}
T2 : {I2 ,O2}
T3 : {I3, O3}
T4 : {I4, O4}
T5 : {I5, O5}
T6 : {I6, O6}
T7 : {I7, O7}
Some Remarks:
A prevalent misconception among the beginners is that one should be concerned with testing only
after coding ends. Testing is, in fact, not a phase towards the end. It is rather a continuous process.
The efforts for testing should begin in the form of preparation of test cases after the requirements have
been finalized. The Software Requirements Specification (SRS) document captures all featuresto be
expected from the system. The requirements so identified here should serve as a basis towards
preparation of the test cases. Test cases should be designed in such a way that all target features could
be verified. However, testing a software is not only about proving that it works correctly. Successful
testing should also point out the bugs present in the system, if any.