DELHI TECHNOLOGICAL UNIVERSITY

(Formerly Delhi College of Engineering)

Shahbad Daulatpur, Bawana Road,
Delhi-110042

Department of Computer Science

Software Engineering Laboratory File

(Smart-Home Management System)

Submitted To: Submitted By:

Shree Govind Jee (2K22/CO/530)

1
2
 Experiment–5
AIM: - To draw the ER Diagram for the above specified problem.
THEROY:
• Entity Relationship Model: An Entity-Relationship Model (ERM) is an abstract and
conceptual representation of data. ER is a database modeling method, used to produce a
type of conceptual schema or semantic data model of a system, often are rational database,
and its requirements in a top-down fashion. The diagrams created by this process are called
entity relationship (ER) diagrams. An entity may be defined as a thing which is recognized
as being capable of an independent existence and can be uniquely identified.
• ER Diagram:

• Entity: An entity may be a physical object such as a house or car, an event such as a
house sale or car service or a concept such as customer transaction or order. Entities can
be thought of as nouns.
For example: a computer, an employee, a song, a mathematical theorem. Entities are
drawn as rectangles.

• Relationship: A relationship captures how entities are related to one another. Relationship
sets are drawn as diamonds. If an entity set participates in a relationship set, they are
connected with a line.
For example: A performs a relationship between an artist and a song, a proved
relationship between a mathematician and a theorem. Relationships illustrate how two
entities share information in the database structure.

3
 • Cardinality: Cardinality specifies how many instances of an entity relate to one instance
of another entity. Ordinality is also closely linked to cardinality. While cardinality
specifies the occurrence sofa relationship, ordinality describes the relationship as either
mandatory or optional. Cardinality basically specifies the maximum number of
relationships while ordinality specifies the absolute minimum number of relationships.

Discussion:
In software engineering, an ER model is useful and commonly made to represent things a
business needs to remember in order to perform business processes. ER model basically
becomes an abstract data model that defines a data or information structure which can be
implemented in a database.

Findings and Learning’s:

We learnt what an Entity Relationship Model is. We also learnt the importance of an ER
model. We then found out how to develop an ER model from scratch. We also learnt about
the different components involved in ER models such as Entity, Relationship, Cardinality,
Ordinality.

4
 Experiment–6
AIM: - To draw different levels of DFD for smart home management system.
THEROY:
• Data Flow Diagram:
A data flow diagram is a traditional visual representation of the information flows within
a system. A neat and clear DFD can depict the right amount of the system requirement
graphically. It can be manual, automated or a combination of both.
It show data centers and leaves the system, what changes the information and where data
is stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It
may be used as a communication tool between a system analyst and any person who plays
a part in order to act as a starting point for redesigning the system. The DFD is also called
a data flow graph or a bubble chart.
The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows in a flowchart represent the order
of events whereas arrows in DFD represent flowing data. A DFD does not involve
any order of events.
3. Suppress logical decisions. If you ever have the urge to draw a diamond shaped
box in a DFD, suppress that urge. A diamond shaped box is used in flow charts to
represent decision points with multiple exit parts of which only one is taken, this
implies an ordering of events which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error
handling until the end of the analysis.

• Symbols used in data flow diagram

a. Circle: A circle shows a process that transforms data inputs into data
outputs. Data flow. A curved line shows the flow of data into or out of a
process or data store.
b. Data-Store: A set of parallel lines shows a place for the collection of data
items. A data store indicates that data is stored and can be retrieved at a
later stage or by other processes in a different order. The data store can
have an element or a group of elements.
c. Source or sink: Source or sink is an external entity and acts as a source of
system inputs or sink of system outputs.

• Levels in Data-Flow Diagram

The data flow diagram may be used to perform a system or software at any level of
abstraction. In fact data flow diagrams may be partitioned into levels that represent
increasing information flow and functional details Levels in DFD are numbered 0, 1, 2 or
beyond. Here we will see primarily three levels in the data flow diagram which are level-
0 DFD, level-1 DFD and level- 2 DFD.

5
 I. Level–0 DFD: It is also known as the fundamental system model a context diagram.
It represents the entire software requirement in a single bubble with input and
output data denoted by incoming and outgoing arrows then the system is
decomposed and described as a DFD with multiple bubbles. Part of the system
represented by each of these Bubbles are then decomposed and documented as
more and more detailed DFDs.
This process may berepeated at as many levels as necessary until theprogram at
hand is well understood. It is essential to preserved he number of inputs and
outputs between levels. Thus, if bubble “A” has two inputs “X1” and “X2” and
one output “Y” then the expanded DFD that represents “A” should have exactly
two external inputs and one external output.
II. Level–1 DFD: In level-1 DFD, a context diagram is decomposed into multiple
bubbles. In this level we highlight the main objective of the system and break
down the high-level process of level-0 DFD into subprocesses.
III. Level–2 DFD: Level-2 DFD goes one process deeper into parts of level-1 DFD.
It can be used to project or record the specific details about the system
functioning.

DFDs for smart home management system

Level – 0 DFD

Level–2 DFD

6
MUSIC SYSTEM:

Level-1 DF

7
Discussion:
The purpose of a data flow diagram is to graphically represent the flow of data from data
stores to processes, processes to entities and from one process to another.

Findings and Learning’s:

We are successfully able to make data flow diagrams of a given system. We also learnt and
understood different levels of data flow diagrams and how to draw them progressively.

8
 Experiment–7

AIM: - To convert DFD to a structure chart.

THEORY:
• DataFlow Diagram
Data Flow Diagram is a graphical representation of flow of data in an information system.
It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD
does not mention anything about how data flows through the system. There is a prominent
difference between DFD and a Flowchart. The flowchart depicts flow of control in program
modules. DFDs depict flow of data in the system at various levels. DFD doesn’t contain
any control or branch elements.
Data Flow Diagrams are classified as follows:
a. Logical DFD: This type of DFD concentrates on the system process and flow of
data in the system.
b. Physical DFD: This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the implementation.

• Structure Chart
Structure Chart is a chart derived from a Data Flow Diagram. It represents the system in
more detail than DFD. It breaks down the entire system in to the lowest functional
modules, describes functions and sub-functions of each module of the system to a greater
detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.
Here are the symbols subsiding construction of Structure Chart:
a. Module: H represents process or subroutine or task. A control module branches to
more than one sub- module. Library Modules are reusable and invokable from any
module.

b. Condition: It is represented by a small diamond at the base of the module. It depicts that
the control module can select any subroutine based on some condition.

9
c. Jump: An arrow is shown pointing inside the module to depict that the control will
jump in the middle of the sub-module.

d. Loop: A curved arrow represents a loop in the module. All sub-modules covered by
loop repeat execution of module.

e. Data Flow: A directed arrow with an empty circle at the end represents data flow

10
 f. Control Flow: A directed arrow with a filled circle at the end represents control
flow.

Discussion:
Structure charts are charts which show breakdown of a system to its lowest manageable levels.
They are useful in structured programming to arrange program modules into a tree.

Findings and Learning’s:

We learnt about what structure charts are, and we also learned why they are useful. Next, we
learnt and converted a DFD into a structure chart. Each module is represented by a box which
contains the module’s name. The tree structure visualizes the relationships between modules.

11
 Experiment–8
AIM: - To develop c code to calculate effort and time period using different forms
of COCOMO model.
THEORY: -
COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there could
be three categories of software projects: organic, semi detached, and embedded. The
classification is done considering the characteristics of the software, the development team and
environment. These product classes typically correspond to application, utility and system
programs, respectively. Data processing programs could be considered as application programs.
Compilers, linkers, are examples of utility programs. Operating systems, real-time system
programs are examples of system programs. One could easily apprehend that it would take much
more time and effort to develop an OS than an attendance management system.
The concept of organic, semidetached, and embedded systems are described below.
a. Organic: A development project is said to be of organic type, if
• The project deals with developing a well understood application.
• The development team is small.
• The team members have prior experience in working with similar types of
projects.
b. Semi detached: A development project can be categorized as semidetached type, if
• The team consists of some experienced as well as in experienced staff.
• Team members may have some experience on the type of system to be developed.
c. Embedded: Embedded type of development project are those, which
• Aimtodevelopsoftwarestronglyrelatedtomachine hardware.
• Teamsizeisusuallylarge.
The basic COCOMO model helps to obtain a rough estimate of the project parameters. It
estimates effort and time required for development in the following way:
Where,
• KDS Iist he estimated size of the software expressed in Kilo Delivered Source
instructions.
• a, b, care 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).

CODE: -
#include<iostream>
#include<bits/stdc++.h>
usingnamespacestd; intfround(float x){
int a;
x=x+0.5;
a=x;
return(a);
12
 }

voidcalculate(floattable[][4],intn,charmode[][15],intsize){

floateffort,time;intmodel;
if(size>=2&&size<=50)model=0;//organic
else if(size>50 && size<=300) model=1; //semi-detached
else if(size>300) model=2; //embeddedcout<<"Themodeis"<<mode[model];
effort = table[model][0]*pow(size,table[model][1]);
time = table[model][2]*pow(effort,table[model][3]);
cout<<"\nEffort = "<<effort<<" Person- Month";
cout<<"\nDevelopmentTime="<<time<<" Months";
}

int main(){
floattable[3][4]={2.4,1.05,2.5,0.38,3.0,1.12,2.5,0.35,3.6,1.20,2.5,0.32};
charmode[][15]={"Organic","Semi-Detached","Embedded"};
intsize=110; calculate(table,3,mode,size);

return 0;
}

OUTPUT: -

Discussion:
The purpose of this code is to find effort and development time required beforehand so that one
knows what resources they have to gather.

Findings and Learning’s:

We learnt how to use the COCOMO model and its advantages. We also learnt to calculate effort
and development time using the COCOMO model.

13
 Experiment–9
AIM: - To develop test cases using boundary value analysis for the identification
of a triangle.
THEORY: - Boundary Value Analysis (BVA) is a software testing technique
where test cases are designed using boundary values. BVA is based on the single
fault assumption (aka critical fault assumption) which states that failures are rarely
the product of two or more simultaneous faults. Hence, while designing test cases
for BVA we keep all but one variable to the nominal value and allow the
remaining variable to take the extreme value.
a. Test Case Design for BVA: While designing the test cases for BVA first we determine
the number of input variables in the problem. For each input variable, we then determine
the range of values it can take. Then we determine the extreme values and nominal
values for each input variable.
If an input variable‘t’ takes values in range [l,r] then the extreme values for t will be t = l,
t = l+1, t = r-1, t = r. The nominal value can be any value in the range (l, r). In most BVA
implementations, it is taken as middle value of range i.e. (r + l)/2.
Under the single fault assumption, the total number of test cases in BVA for a problem
with ‘n’ inputs is 4n+1. The 4n corresponds to the test cases with four extreme values of
each variable keeping the other n-1 variable at nominal value. The one additional case is
where all variables are held at a nominal value.

b. Boundary Value Analysis for Triangle: Triangle Problem accepts three integers a, b, c
as three sides of the triangle. We also define a range for the sides of the triangle as [l, r]
where l > 0. It returns the type of triangle (Scalene, Isosceles, Equilateral, Not a
Triangle) formed by a, b, c. For three sides to form a triangle, the sum of two side’s
shoulder ways is greater than the third side. If all sides are equal then it is an Equilateral
triangle. If two sides are equal then it is an Isosceles triangle. If none of the sides are
equal then it is a scalene triangle. Let's take the range for the side of the triangle to be [1,
100] and thus nominal value will be 50.
Now since the number of input variables is 3 (sides of triangle) therefore, total cases will
be 4n+1 = 4*3+1 = 13 test cases.

CODE: -

#include<stdio.h>
int main(){
int a, b, c, result;
printf("Enterthevaluesofa,bandc:");
scanf("%d%d%d",&a,&b,&c);
if( ( ( a + b ) > c ) && ( ( b + c ) > a ) && ( ( c + a ) > b ) ){
if((a==b)&&(b==c)) printf("\nEquilateralTriangle");
else if((a==b)||(b==c)||(c==a)) printf("\nIsoscelesTriangle");
else printf("\nScaleneTriangle");}

14
 else printf("\nNotaTriangle"); return0;
}
Test Cases

TestCaseNo. a b c ExpectedOutput

T1 1 50 50 Isosceles

T2 2 50 50 Isosceles

T3 99 50 50 Isosceles

T4 100 50 50 NotaTriangle

T5 50 50 50 Equilateral

T6 50 1 50 Isosceles

T7 50 2 50 Isosceles

T8 50 99 50 Isosceles

T9 50 100 50 NotaTriangle

T10 50 50 1 Isosceles

T11 50 50 2 Isosceles

T12 50 50 99 Isosceles

T13 50 50 100 NotaTriangle

OUTPUT:

Discussion:
Boundary Value Analysis helps to test the software we have written. It checks for the input
values near the boundary that have a higher chance of error. Every partition has its maximum
and minimum values and these maximum and minimum values are the boundary values of a
partition.

Findings and Learning’s:

We are successfully able to test the program we have written for classification of triangles by
generating test cases using BVA. We also learned that mostly error happens on the extreme
values of the input variables involved

15