Lab Manual

Software Engineering Lab

(KCS-661)

Prepared by: Ms. Mekhala

Designation: Assistant Professor
Computer Science and Engineering Department

Department of Computer Science and Engineering

GL Bajaj Institute of Technology and Management
Plot No.2, APJ Abdul Kalam Road, Knowledge Park 3, Greater
Noida
Uttar Pradesh, India, Pin-201306

Table of Contents

I. Vision & Mission of Institute

II. Vision & Mission of Department
III. Program Educational Objectives
IV. Program Outcomes
V. Course Outcomes with Bloom Taxonomy
VI. Program Specific Outcomes
VII. Course Scheme as per University
VIII. Course Syllabus as per University
IX. Mapping of Cos- Pos & PSOs
X. Rubrics used for Continuous Evaluation for lab session
XI. Experiment List (1 ……… n) (all programs as per university list mapped
with COs & PSOs)
Each experiment contains followings.
a) Objective of the Experiment
b) Code
c) Output (Snapshot)
XII. Course Beyond syllabus (at least 2 experiments mapped with COs & PSOs)
Each experiment contains followings.
a) Objective of the Experiment
b) Code
c) Output (Snapshot)
 INSTITUTE VISION & MISSION
VISION:

● To be an institute of repute, providing professionally competent and socially sensitive

engineers.

MISSION:

● To equip with the latest technologies to be globally competitive professionals.

● To inculcate qualities of leadership, professionalism, corporate understanding and

executive competence.

● To imbibe and enhance human values, ethics and morals in our students.

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

VISION OF THE DEPARTMENT

To build strong teaching environment that responds to the need of industry and challenges
of society.

MISSION OF THE DEPARTMENT

M1: Developing strong mathematical & computing skill set among the students.

M2: Extending the role of computer science and engineering in diverse areas like Internet of
things (IoT), Artificial intelligence & Machine Learning and Data Analytics.

M3: Imbibing the students with a deep understanding of professional ethics and high integrity to
serve the Nation.

M4: Providing an environment to the students for their growth both as individuals and as globally
competent Computer Science professional and encouragement for innovation & start-up culture.

PROGRAM EDUCATIONAL OUTCOMES (PEOs)

PEO1: Graduates will work in the area of application software development, artificial
intelligence & Machine learning, data analytics, and Internet of things.

PEO2: Graduates will become successful software professional with leadership and managerial
quality in the modern software industry based on their strong skill on theoretical and practical
foundation.

PEO3: Graduates will exhibit professional ethics and moral value with capability of working as
an individual and as a team to contribute towards the needs of the industry and society.

PROGRAMME OUTCOMES (POs)

Engineering Graduates will be able to:

1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering

fundamentals, and an engineering specialization to the solution of complex engineering
problems.

2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.
3. Design/development of solutions: Design solutions for complex engineering problems
and design system components or processes that meet the specified needs with
appropriate consideration for the public health and safety, and the cultural, societal, and
environmental considerations.

4. Conduct investigations of complex problems: Use research-based knowledge and

research methods including design of experiments, analysis and interpretation of data,
and synthesis of the information to provide valid conclusions.

5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modeling to complex
engineering activities with an understanding of the limitations.

6. The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, healthy ,safety,legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.

7. Environment and sustainability: Understand the impact of the professional engineering

solutions in societal and environmental contexts, and demonstrate the knowledge of and
need for sustainable development.

8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities
and norms of the engineering practice.

9. Individual and team work: Function effectively as an individual, and as a member or

leader in diverse teams, and in multidisciplinary settings.

10. Communication: Communicate effectively on complex engineering activities with the

engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give
and receive clear instructions.

11. Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member
and leader in a team, to manage projects and in multidisciplinary environments.

12. Life-long learning: Recognize the need for, and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.
 Course Outcomes with Bloom Taxonomy

COs COURSE OUTCOMES BLOOMS

TAXONOMY
Identify ambiguities, inconsistencies and incompleteness from a K2, K4
CO 1 requirements specification and state functional and non-functional
requirement
CO 2 Identify different actors and use cases from a given problem statement and K3, K5
draw use case diagram to associate use cases with different types of
relationship
K4, K5
CO 3 Draw a class diagram after identifying classes and association among them
Graphically represent various UML diagrams , and associations among K4, K5
CO 4
them and identify the logical sequence of activities undergoing in a system
and represent them pictorially
Able to use modern engineering tools for specification, design, K3, K4
CO 5
implementation and testing

PROGRAM SPECIFIC OUTCOMES

(PSOs)

PSO.1: Student will be able to use problem solving skills to develop efficient algorithmic
solutions.

PSO.2: Student will be able to develop solution for a given problem in the area of artificial
intelligence, data analytics, computer vision and IOT through conducive environment and
infrastructure.
 Subject Code: KCS 661

Subject Name: Software Engineering Lab

Faculty Name: Ms. Mekhala

Evaluation Scheme:

Software Engineering 25 25 50 1
1 KCS 661 0 0 2
Lab
 Software Engineering Lab (KCS 651)

COs COURSE OUTCOMES

Identify ambiguities, inconsistencies and incompleteness from a requirements
KCS651.1 specification and state functional and non-functional requirement
Identify different actors and use cases from a given problem statement and draw use
KCS651.2 case diagram to associate use cases with different types of relationship

KCS651.3 Draw a class diagram after identifying classes and association among them
Graphically represent various UML diagrams, and associations among them and
KCS651.4 identify the logical sequence of activities undergoing in a system, and represent them
pictorially
Able to use modern engineering tools for specification, design, implementation and
KCS651.5
testing

Mapping of Program Outcomes with Course Outcomes (COs)

CO-PO Matrix
Course PO1 PO2 PO3 PO4 PO5 PO6 P07 PO8 PO9 PO10 PO11 PO12
Outcomes
KCS651.1 2 2 2 1 2 - - - - - - 1

KCS651.2 - -
2 2 2 2 3 - - - - 1

KCS651.3 2 3 3 2 3 - - - - - - 1

KCS651.4 2 3 3 2 3 - - - - - - 1

KCS651.5 - -
2 3 3 2 2 - - - - 1

CO-PSO Matrix
COs PSO1 PSO2
KCS-661.1 - -
KCS-661.2 2 1
KCS-661.3 2 1
KCS-661.4 2 1
 List of Experiments

1 Prepare a SRS document in line with the IEEE recommended standards.

2 Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.

3 Draw the activity diagram.

4 Identify the classes. Classify them as weak and strong classes and draw the class
diagram.
5 Draw the sequence diagram for any two scenarios.
6 Draw the collaboration diagram.
7 Draw the component diagram.
8 Draw the state chart diagram.
9 Perform forward engineering in java. (Model to code conversion)
10 Perform reverse engineering in java. (Code to Model conversion)
11 Draw the deployment diagram.
12. To prepare DATA FLOW DIAGRAM for any project.
13. Draw the Er -modeling diagram.
 Grade Policy for Laboratory
We give the grades to the students i.e. A/α, B/β, C/γ for their performance in lab as per the given table:
Performance Record Viva-Voce

Attention Time line Experimental Knowledge

Effectiveness Presentation Expression

Discipline Quality of Content Communication

Dedication Competence Confidence

The grades α, β, γ/ A, B, C are awarded in lab record, lab performance and viva voce as per the above define
table.

Grade Range of marks

A/α 4-5 Marks

B/β 3-4 Marks

C/γ 2-3 marks

 Experiment No: 1
AIM:Prepare a SRS document in line with the IEEE recommended standards.

Outcome: Can produce the requirements in a SRS document.

Objective: Prepare a SRS document in line with the IEEE recommended standards.

Description:

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.

The SRS document itself states in precise and explicit language those functions and capabilities a
software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as
well as states any required constraints by which the system must abide. The SRS also functions as a
blueprint for completing a project with as little cost growth as possible. The SRS is often referred to
as the "parent" document because all subsequent project management documents, such as design
specifications, statements of work, software architecture specifications, testing and validation plans,
and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer
design suggestions, possible solutions to technology or business issues, or any other information other than
what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary to
address those problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.
It decomposes the problem into component parts. The simple act of writing down software requirements in a
well-designed format organizes information, places borders around the problem, solidifies ideas, and helps
break down the problem into its component parts in an orderly fashion.
It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent
document to subsequent documents, such as the software design specification and statement of work.
Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design
solution can be devised.

It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies
that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial product
development phase in which information is gathered about what requirements are needed--and not. This
information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The
actual specification, then, is written after the requirements have been gathered and analyzed.

A sample of basic SRS

1. Introduction

1.1 Purpose

1.2 Document conventions

1.3 Intended audience

1.4 Additional information

1.5 Contact information/SRS team members

1.6 References

2. Overall Description

2.1 Product perspective

2.2 Product functions

2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces
 3.2 Hardware interfaces

3.3 Software interfaces

3.4 Communication protocols and interfaces

4. System Features
4.1 System feature
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirement
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
\6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list

Appendix B: To be determined
 Experiment No: 2
AIM:Draw the use case diagram and specify the role of each of the actors. Also state the precondition, post
condition and function of each use case

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse,
colored monitor.

Software Requirements: draw.ioUML, Windows XP.

Outcome: Can produce the requirements in Use Case diagram.

Description: According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.” Use case diagrams are often used to:

Provide an overview of all or part of the usage requirements for a system or organization in the form of an
essential model or a business model.

Communicate the scope of a development project

Model your analysis of your usage requirements in the form of a system use case model

Use case models should be developed from the point of view of your project stakeholders and not from the
(often technical) point of view of developers

Creating Use Case Diagrams

we start by identifying as many actors as possible. You should ask how the actors interact
with the system to identify an initial set of use cases. Then, on the diagram, you connect the
actors with the use cases with which they are involved. If actor supplies information, initiates
the use case, or receives any information as a result of the use case, then there should be an
association between them.

Conclusion: The Use case diagram was made successfully by following the steps described above.
 Experiment No: 3
AIM:Draw the activity diagram.
Outcome: Can produce the activity diagram for requirements modeling.

Objective: To Draw a sample activity diagram for real project or system.

Description:

Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.

Software Requirements: Drawio UML, Windows XP,

Theory:
Actors:
1. Customer: Initiates the process of browsing, searching, and purchasing products.
2. Admin: Manages the products, user accounts, and resolves issues.
Use Cases:
1. Browse Products:
Precondition: Customer is logged in.
Postcondition: List of products is displayed.
Function: Allows the customer to view available products.
2. Search Products:
Precondition: Customer is logged in.
Postcondition: Search results are displayed.
Function: Enables the customer to search for specific products.
3. Add to Cart:
Precondition: Customer is logged in and has selected a product.
Postcondition: Product is added to the cart.
Function: Allows the customer to add products to their shopping cart.
4. Checkout:
Precondition: Customer has products in the cart.
Postcondition: Order is placed, and payment is processed.
Function: Enables the customer to finalize the purchase.
5. Manage Products:
Precondition: Admin is logged in.
Postcondition: Product database is updated.
Function: Allows the admin to add, edit, or remove products.
6. Manage Users:
Precondition: Admin is logged in.
Postcondition: User accounts are updated.
Function: Allows the admin to manage customer accounts.
Output
figure1. Modeling a business process with a UML Activity Diagram
 Experiment No: 4
AIM:. Identify the classes. Classify them as weak and strong classes and draw the class diagram.
Outcome: Class diagram helps to understand the static structure of a system. It

shows relationships between classes, objects, attributes, and operations.

Objective: Identify the classes. Classify them as weak and strong classes and

draw the class diagram.

Description:

Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.

Software Requirements: Drawio UML, Windows XP

Description:
A class diagram models the static structure of a system. It shows relationships between classes, objects,
attributes, and operations.

As mentioned above, and as seen in Diagram 1, classes are represented by rectangular symbols,
and different arrows are used to represent the relationship between classes. Note that class
diagrams don’t depict any interactions between classes.

Here is a detailed breakdown of the different symbols used when constructing class diagrams.
Class

The class name is always shown in the first section, the attributes in the second, and
operations in the third. Attributes are values that define a class. Classes can carry
out processes known as operations.

Note: there can be a fourth section (responsibility), which is an optional section for
including additional information about the class.
 Visibility

Visibility symbols are used to determine the accessibility of the information

contained in classes.

Note: The “+” represents public operations, vice versa, “-” represents private
operations. Plus, “#” is for the protected operations.

As mentioned above, class diagrams can represent relationships between classes. There are seven
relationships that are commonly shown in class diagrams. They are association (the most common
being bidirectional and unilateral association), inheritance, realization/implementation, dependency,
aggregation, composition, and multiplicity.

Bidirectional Association

A bilateral association is represented by a straight line connecting

two classes. It simply demonstrates that the classes are aware of
their relationship with each other.
Unilateral Association

A unilateral association is represented by an open arrowhead

connecting one class to another. It shows that one class is aware
of its relationship with another class.

Inheritance

Indicate a “child-parent” relationship between classes. The child

class is a specialized, sub-class of the parent.
Realization/Implementation

One class implements the behavior specified by another class.

Dependency

As the name suggests, one class depends on another. A dashed

arrow shows this.
Aggregation

This represents a unilateral relationship between classes. One

class is part of, or subordinate to, another. In this instance, the
child and parent classes can exist independently.

Composition

It is a form of aggregation where one class is dependent on

another. One class is a part of the other. In this instance, the child
classes and parent classes cannot exist independently.

Multiplicity

Multiplicity is used to determine how many times an attribute

occurs. In this example, this house has exactly one kitchen and at
least one bedroom.

Output
 Experiment No: 5

Aim: Draw the sequence diagram for any two scenarios.

Outcome: Can draw the sequence diagram.

Objective: Drawing the sequence diagram

Hardware Requirements:Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard and
mouse, colored monitor.

Software Requirements: DRAWIO. UML, Windows XP

Theory:

UML sequence diagrams model the flow of logic within the system in a visual manner, enabling the user both
to document and validate the logic, and are commonly used for both analysis and design purposes. Sequence
diagrams are the most popular UML artifact for dynamic modeling, which focuses on identifying the behavior
within your system. Sequence diagrams, along with class diagrams and physical data models are the most
important design-level models for modern application development.

Sequence diagrams are typically used to model:

1 Usage scenarios. A usage scenario is a description of a potential way the system is used.
The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may
also be one entire pass through a use case, such as the logic described by the basic course of
action or a portion of the basic course of action, plus one or more alternate scenarios. The
logic of a usage scenario may also be a pass through the logic contained in several use cases.
For example, a student enrolls in the university, and then immediately enrolls in three
seminars.

2.The logic of methods. Sequence diagrams can be used to explore the logic of a complex
operation, function, or procedure. One way to think of sequence diagrams, particularly highly
detailed diagrams, is as visual object code.

3. The logic of services. A service is effectively a high-level method, often one that can be invoked by a wide
variety of clients. This includes web-services as well as business transactions implemented by a variety of
technologies such as CICS/COBOL or CORBA-compliant object request brokers (ORBs).

Output
 Experiment No: 6
Experiment Name: Collaboration diagram .

Outcome: Students will be able to draw the collaboration diagram

Objective: draw the collaboration diagram using drawioUML.

Description:
Collaboration diagrams ar relatively easy to draw. They show the relationship between objects and the order
of messages passed between them. The objects are listed as icons and arrows indicate the messages being
passed between them. The numbers next to the messages are called sequence numbers. As the name
suggests, they show the sequence of the messages as they are passed between the objects. There are
many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used, as the
example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.

Output
 Experiment No: 7

AIM:Draw the state chart diagram

Outcome: Can produce the state chart diagram for requirements modeling.

Objective: To Draw a sample activity diagram for real project or system.

Description:

Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.

Software Requirements: Drawio UML, Windows XP,

Theory:
UML primarily uses diagrams to represent systems. These diagrams can be broken down into two types:
behavioural UML diagrams, and structural UML diagrams.

UML is an extremely versatile and widely-recognised language. It is the standard language used by many
developers, as well as an increasing number of business professionals. Its flexibility means that it can be
applied to a number of IT or business-related situations, so that you can make it applicable to the system or
technology you are using.

Output
 Experiment No: 8

Aim:Draw the component diagram.

Outcome: Can draw the Component diagram.

Objective: Drawing the component diagram

Description: A component is something required to execute a stereotype function.

Examples of stereotypes in components include executables, documents, database tables,
files, and library files.

Components are wired together by using an assembly connector to connect the required
interface of one component with the provided interface of another component. This
illustrates the service consumer - service provider relationship between the two
components.

An assembly connector is a "connector between two components that defines that one
component provides the services that another component requires. An assembly connector
is a connector that is defined from a required interface or port to a provided interface or
port."

When using a component diagram to show the internal structure of a component, the
provided and required interfaces of the encompassing component can delegate to the
corresponding interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as
specified by its ports) to the internal realization of that behavior by the component’s
parts."[1]

The example above illustrates what a typical insurance policy administration system might
look like. Each of the components depicted in the above diagram may have other
component diagrams illustrating its internal structure.

component is represented by a rectangle with either the keyword "component" or a

stereotype in the top right corner: a small rectangle with two even smaller rectangles jutting
out on the left.

The lollipop, a small circle on a stick, represents an implemented or provided interface. The
socket symbol is a semicircle on a stick that can fit around the lollipop. This socket is a
dependency or needed interface.

The component diagram notation set now makes it one of the easiest UML diagrams to
draw. Figure 1 shows a simple component diagram using the former UML 1.4 notation; the
example shows a relationship between two components: an Order System component that
uses the Inventory System component. As you can see, acomponent in UML 1.4 was drawn
as a rectangle with two smaller rectangles obtruding from its left side.
 Experiment No: 9
Aim: Perform forward engineering in java. (Model to code conversion)

Forward engineering involves translating a higher-level model or design into actual code. In the context of
Java, this typically means going from a design or model (such as a UML class diagram) to Java code. I'll
provide a simple example where we'll create a Java class based on a hypothetical model.

Let's say we have a class diagram with a class named Person having attributes name and age. Here's how you
might forward engineer this into Java code:

1. Model (UML Class Diagram):

2. Forward Engineering to Java Code:

// Person.java

public class Person {

// Attributes

private String name;

private int age;

// Constructors

public Person() {

// Default constructor

}
public Person(String name, int age) {

this.name = name;

this.age = age;

// Getters and Setters

public String getName() {

return name;

public void setName(String name) {

this.name = name;

public int getAge() {

return age;

public void setAge(int age) {

this.age = age;

// Other methods if needed

 @Override

public String toString() {

return "Person{" +

"name='" + name + '\'' +

", age=" + age +

'}';

Conclusion

This Java class corresponds to the Person class in our model. It has private attributes (name and age),
constructors, getters, setters, and a toString method for better representation.

This is a basic example, and in real-world scenarios, you might have more complex relationships, methods, or
other elements in your model that need to be translated to Java code. The key is to understand the structure
and behavior of your model and represent that in Java classes and methods.
 Experiment No: 10
Aim: Perform reverse engineering in java. (Code to Model conversion)

Reverse engineering involves analyzing existing code to create a higher-level model or design representation.
In the context of Java, this typically means going from Java code to a model, such as a UML class diagram.
Here, I'll provide a simple example of reverse engineering a Java class into a UML class diagram.

Let's say we have the following Java class:

// Person.java

public class Person {

// Attributes

private String name;

private int age;

// Constructors

public Person() {

// Default constructor

public Person(String name, int age) {

this.name = name;

this.age = age;

// Getters and Setters

public String getName() {

return name;

}
public void setName(String name) {

this.name = name;

public int getAge() {

return age;

public void setAge(int age) {

this.age = age;

// Other methods

public void celebrateBirthday() {

age++;

System.out.println("Happy Birthday, " + name + "! You are now " + age + " years old.");

@Override

public String toString() {

return "Person{" +

"name='" + name + '\'' +

 ", age=" + age +

'}';

Now, let's represent this Java class in a simplified UML class diagram:

+---------------------+

| Person |

+---------------------+

| - name: String |

| - age: int |

+---------------------+

| + Person() |

| + Person(name: String, age: int) |

| + getName(): String |

| + setName(name: String): void |

| + getAge(): int |

| + setAge(age: int): void |

| + celebrateBirthday(): void |

| + toString(): String|

+---------------------+

Conclusion
In this UML class diagram:

● Attributes are represented as fields within the class.

● Constructors are listed with their parameter names and types.
● Methods are listed with their names, return types (if applicable), and parameter names and types.

Note that this is a simplified example. In a real-world scenario, you might have more complex relationships,
associations, and other UML elements. Reverse engineering tools and techniques can assist in automatically
generating UML diagrams from existing codebases, providing a visual representation of the software
architecture.
 Experiment No: 11
AIM:Draw the deployment diagram.
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse,
colored monitor.

Software Requirements: draw.ioUML, Windows XP.

Outcome: Can produce the requirements in Use Case diagram.

Description

UML Deployment Diagram describes the software system's specifications and the physical hardware system
required to run the software. The Deployment Diagram also determines the installation of the software on the
hardware. UML Deployment Diagram maps software segments of a method to the device that is going to
implement it.

Deploymnet diagram symbols

Output
 Experiment No: 12

AIM: Draw the Er -modeling diagram.

REQUIREMENTS:
Hardware Interfaces
● Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM
● Screen resolution of at least 800 x 600 required for proper and complete viewing of screens.
Higher resolution would not be a problem.
● CD ROM Driver

Software Interfaces

● Any window-based operating system (Windows 95/98/2000/XP/NT)

● WordPad or Microsoft Word

THEORY

ERD stands for Entity Relationship Diagram. It is a type of visual model that describes different elements in a
specific domain. ER diagrams are widely used in software engineering and database management. People use
them to study the links between separate entities to create an organized and robust database. ER diagrams look
like flow charts to some extent. To draw an ER diagram, you need to identify all the entities, know the
relationships between all the entities, and add attributes for each entity.

There are many to create an ER diagram online using different diagrammatic tools. One such tool to create an
ER diagram online is Edraw Max Online. Edraw Max is an online graphic creator that can be used to create
different types of charts, graphs, and diagrams in just a few simple steps. To learn how to make an Entity
Relationship diagram in the process of a few steps, please check out our ER diagram tutorial below.
 Experiment No: 13

AIM: To prepare DATA FLOW DIAGRAM for any project.

REQUIREMENTS:
Hardware Interfaces
● Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM
● Screen resolution of at least 800 x 600 required for proper and complete viewing of screens.
Higher resolution would not be a problem.
● CD ROM Driver

Software Interfaces

● Any window-based operating system (Windows 95/98/2000/XP/NT)

● WordPad or Microsoft Word

THEORY
Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

Data Flow Diagram Notations

You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane &
Sarson.

OUTPUT