BCA III – SAD Compiled By: GIRIJA 1

UNIT 2: Process and Conceptual Modeling [6 Hrs.]

a. Introduction to Data Flow Diagram (DFD)
b. Concepts used in drawing DFDs
c. DFD Design (up to level 2)
d. Conceptual Modeling
e. Entity Relationship Diagrams

A. Introduction to Data Flow Diagram (DFD)

A data flow diagram (DFD) maps out the flow of information for any process or system. It 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 shows how data enters and leaves the system, what changes the information, and where data
is stored.

The purpose of data flow diagram is to show the “flow” and transformation of data through the
system. These diagrams are used as visualization tool to help the audience get a better idea of
what exactly is going on in the system.

The DFDs are use to :

i. discuss with the user a diagrammatic interpretation of the process in the system and
clarify what is currently being performed.
ii. determine what the new system should be able to do and what information is required
for each different process the should be carried out.
iii. Check that the completed system conforms to its intended design.
iv. provides easy presentation and communication between technical and non technical
staff.

Components of Data Flow Diagram

The components of Data Flow Diagram are always the same but there are different diagrammatic
notations used. The notation used here is one adopted by a methodology known as structured
systems analysis and design methods there are four different symbols that are normally used on
a DFD. The elements represented are :
 External entities
 Processes
 Data stores
 Data Flows
BCA III – SAD Compiled By: GIRIJA 2

 External Entities: Represented by rectangles or squares, entities can be external actors or

system units interacting with the system. They can be sources or destinations of data.
 Processes: Represented by circles, ovals, or rectangles, processes are used to transform
incoming data flow into outgoing data flow.
 Data Stores: Often represented by two horizontal lines, these indicate data repositories
like databases or other storage mechanisms where data rests.
 Data Flow: Represented by arrows, these show the direction and route of data as it moves
through the system. It signifies what kind of information will be input and output from
the system.
 BCA III – SAD Compiled By: GIRIJA 3

Benefits of Data Flow Diagram:

 Clarity: Offers a clear visual representation of data flow in a system.
 Communication: Serves as a common language for effective communication among
stakeholders.
 Process Identification: Helps define and understand processes within a system.
 Data Source/Destination: Identifies where data originates and its destinations for better
tracking.
 Data Store Identification: Recognizes and defines where data is stored.
 System Understanding: Provides a holistic view of the entire system's functionalities.
 Redundancy Detection: Reveals redundancies, aiding in optimization.
 Efficient Problem-Solving: Pinpoints issues quickly for efficient troubleshooting.
 Project Planning: Useful in breaking down a system for better project planning.
 Documentation: Acts as a visual guide for future reference and knowledge transfer.

B. Concepts used in drawing DFDs

Rules to design Data Flow Diagram
 Data can not flow between two entities. – Data flow must be from entity to a process or a
process to an entity. There can be multiple data flows between one entity and a process.

 Data can not flow between two data stores Data flow must be from data store to a process
or a process to an data store. Data flow can occur from one data store to many process.

 Data can not flow directly from an entity to data store – Data Flow from entity must be
processed by a process before going to data store and vice versa.

 A process must have at least one input data flow and one output data flow – Every process
must have input data flow to process the data and an output data flow for the processed
data.

 A data store must have at least one input data flow and one output data flow – Every data
store must have input data flow to store the data and an output data flow for the retrieved
data.

 Two data flows can not cross each other.

 All the process in the system must be linked to minimum one data store or any other
process.
BCA III – SAD Compiled By: GIRIJA 4
 BCA III – SAD Compiled By: GIRIJA 5

Levels of DFDs
Data Flow Diagrams can be structured at various levels of abstraction. Each level offers a more
detailed representation of the system’s data flow and processes than the level above it. Here
are the different levels of DFDs:

0-Level DFD:
 This diagram represents the entire system as a single process or "bubble."
 This is the highest-level DFD, which provides an overview of the entire system. It shows
the major processes, data flows, and data stores in the system, without providing any
details about the internal workings of these processes.
 It illustrates the external entities that interact with the system, such as users, other
systems, or external data sources.
 The focus is on providing an overview of the system's boundaries and the primary
interactions between the system and its environment.
 This level helps stakeholders understand the system's scope without getting into intricate
details.

Fig: 0 DFD for an order system.

 BCA III – SAD Compiled By: GIRIJA 6

1-Level DFD:
 This level provides a more detailed view of the system by breaking down the major
processes identified in the level 0 DFD into sub-processes. Each sub-process is depicted
as a separate process on the level 1 DFD. The data flows and data stores associated with
each sub-process are also shown.
 Major processes are identified along with their interrelationships, showcasing the main
activities within the system.
 Data flows between processes and external entities are introduced, highlighting how
data moves through the system.
 This level provides a fundamental understanding of the system's key functionalities and
how it interacts with external entities.

Fig: 1 DFD for an order system.

 BCA III – SAD Compiled By: GIRIJA 7

2-Level DFD:
 This level provides an even more detailed view of the system by breaking down the sub-
processes identified in the level 1 DFD into further sub-processes. Each sub-process is
depicted as a separate process on the level 2 DFD. The data flows and data stores
associated with each sub-process are also shown.
 Additional details are introduced, such as data stores, data transformations, and specific
data flows within each process.
 This level offers a more granular view of the system's internal workings, making it
particularly useful for system designers and analysts.
 It may focus on specific modules or components of the system, providing insights into
their functionalities.

Fig: 2 DFD for an order system.

 BCA III – SAD Compiled By: GIRIJA 8

Example: Context and top level DFD diagram for Customer Relationship Management

Fig: Context Diagram of CRM

Fig: Top Level DFD

 BCA III – SAD Compiled By: GIRIJA 9

D. Conceptual Modeling
Conceptual modeling is the process of developing an abstract model or graphical representation
using real-world concepts or ideas. During conceptual modeling, various assumptions are made
regarding how the system functions. Conceptual models also illustrate the dominant processes
in a system and how they are linked. These processes may include factors known to drive change
in the system, or they may encompass the consequences of change in the factors themselves.

Aspect Explanation

– Conceptual Modeling is a process used in various disciplines, including software

engineering, business analysis, and information systems, to represent abstract
Concept
ideas or concepts visually. It involves creating models that capture essential elements,
Overview
relationships, and characteristics of a system, process, or domain, providing a high-
level abstraction of complex realities.

– The primary purpose of Conceptual Modeling is to

facilitate communication, understanding, and documentation. It helps stakeholders,
Purpose and
including designers, developers, and end-users, visualize and clarify the structure,
Importance
behavior, and requirements of a system or concept. It plays a vital role in
the requirements analysis and design phases of projects.

– Entities: These represent objects or concepts within the modeled domain. Entities
have attributes that describe their properties.
– Relationships: These indicate connections or associations between entities,
providing insights into how entities interact.
Key Concepts
– Attributes: These define the characteristics or properties of entities, helping to
describe them in more detail.
– Constraints: Constraints specify rules or conditions that entities and relationships
must adhere to.

– Various modeling languages are used for Conceptual Modeling, such as Entity-
Relationship Diagrams (ERD) for database modeling, Unified Modeling Language
Modeling
(UML) for software design, and Business Process Model and Notation (BPMN) for
Languages
business process modeling. These languages provide standardized
symbols and notations for modeling.

– Identification: In this initial phase, stakeholders identify the entities, relationships,

and attributes that need to be represented in the model.
– Abstraction: The model’s focus is on the most important and relevant aspects,
abstracting away unnecessary details.
Process Steps
– Visualization: Visual representations (e.g., diagrams) are created to depict the
identified concepts and their relationships.
– Validation: Stakeholders review the model for accuracy and completeness,
ensuring it aligns with the intended concept or system.
 BCA III – SAD Compiled By: GIRIJA 10

Aspect Explanation

– Documentation: The model serves as a documented artifact, providing a reference

for future discussions, decisions, and implementations.

– Conceptual Modeling finds applications in diverse fields, including database

design, software engineering, business process analysis, system architecture,
Applications
and scientific modeling. It is valuable whenever a conceptual representation of a
complex system or idea is needed.

– Challenges in Conceptual Modeling include ensuring the model’s

accuracy, alignment with stakeholders’ expectations, and maintainability over
Challenges
time. Effective modeling requires domain knowledge, and misunderstandings can
lead to miscommunication and design flaws.

– Conceptual Modeling is often an iterative process that evolves as the project

progresses and as stakeholders’ understanding deepens. Changes to the model can
Iterative Nature
occur as requirements evolve or as new insights emerge during development or
analysis.

– Successful Conceptual Modeling often involves collaboration among various

stakeholders, including subject matter experts, designers, developers, and end-
Collaboration
users. Effective communication is key to ensuring that the model accurately reflects
the intended concept.

– Beyond its immediate use, Conceptual Modeling provides valuable

Documentation documentation that can aid in knowledge transfer, training, and future decision-
Value making. It serves as a foundation for further development and helps
maintain consistency in understanding over time.

– Emerging trends in Conceptual Modeling include the integration of semantic web

Emerging technologies for more semantic-rich models, the application of ontology
Trends modeling for knowledge representation, and the use of domain-specific modeling
languages for more specialized domains.

Below are some of the most commonly used conceptual modelling techniques:
Data flow modeling (DFM)
A basic technique where the elements of a system are graphically represented by data flow.
Instead of illustrating complex system details, DFM gives context to major system functions.

Event-driven process chain (EPC)

A technique primarily used to improve business process flows. An EPC is comprised of events that
define what state a process is in or the rules by which it operates.
 BCA III – SAD Compiled By: GIRIJA 11

To progress through events, a function or active event must be executed. This technique is
commonly seen in resource planning, logistics, and process improvement.

Entity relationship modeling (ERM)

This modelling technique is typically seen in software systems.
Here, database models and information systems are represented by entity-relationship
diagrams, with entities denoting functions, objects, or events.

Unified Modelling Language (UML)

Unified Modeling Language (UML) is a general-purpose modeling language. The main aim of
UML is to define a standard way to visualize the way a system has been designed.
 We use UML diagrams to portray the behaviour and structure of a system.
 UML helps software engineers, businessmen, and system architects with modelling,
design, and analysis.
 The Object Management Group (OMG) adopted Unified Modelling Language as a
standard in 1997. It’s been managed by OMG ever since.
 The International Organization for Standardization (ISO) published UML as an approved
standard in 2005. UML has been revised over the years and is reviewed periodically.

Different Types of UML Diagrams

UML is linked with object-oriented design and analysis. UML makes use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
 BCA III – SAD Compiled By: GIRIJA 12

Structural UML Diagrams:

Class Diagram:
 Depicts static structure of a system.
 Shows classes, methods, and attributes.
 Identifies relationships between classes.

Composite Structure Diagram:

 Represents internal class structure and interactions.
 Details parts, ports, connectors.
 Similar to class diagrams but focuses on parts.

Object Diagram:
 Screenshot of instances and their relationships.
 Depicts actual classifiers at a specific time.
 Shows instances and relationships from class diagrams.
 BCA III – SAD Compiled By: GIRIJA 13

Component Diagram:
 Organizes physical components in a system.
 Models implementation details.
 Illustrates relationships between software elements.
 BCA III – SAD Compiled By: GIRIJA 14

Deployment Diagram:
 Represents system hardware and software.
 Shows distribution of software artifacts.
 Used for distributed or deployed systems.

Package Diagram:
 Organizes packages and their dependencies.
 Helps group UML diagrams meaningfully.
 Primarily used for class and use case diagrams.
 BCA III – SAD Compiled By: GIRIJA 15

Behavioral UML Diagrams:

State Machine Diagrams:
 Represents system or part conditions over time.
 Behavioral diagram with finite state transitions.
 Also called State machines or State-chart Diagrams.

Activity Diagrams:
 Illustrates flow of control in a system.
 Models sequential and concurrent activities.
 Focuses on workflow and event causes.
 BCA III – SAD Compiled By: GIRIJA 16

Use Case Diagrams:

 Depicts system functionality and interactions.
 Illustrates functional requirements.
 Provides high-level view without implementation details.

Sequence Diagram:
 Shows object interactions in sequential order.
 Describes how objects function over time.
 Used for documenting system requirements.
 BCA III – SAD Compiled By: GIRIJA 17

Communication Diagram:
 Displays sequenced messages between objects.
 Focuses on objects and relationships.
 Represents similar info as Sequence diagrams.

Timing Diagram:
 Special form of Sequence diagrams.
 Depicts object behavior over a time frame.
 Shows time and duration constraints.
 BCA III – SAD Compiled By: GIRIJA 18

Interaction Overview Diagram:

 Simplifies complex interactions.
 Mixture of activity and sequence diagrams.
 Models a sequence of actions.
 BCA III – SAD Compiled By: GIRIJA 19

E. Entity Relationship Diagrams

Entity-Relationship Diagrams 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.

The Entity Relationship Diagram explains the relationship among the entities present in the
database. ER models are used to model real-world objects like a person, a car, or a company and
the relation between these real-world objects. In short, the ER Diagram is the structural format
of the database.
Why Use ER Diagrams?
 ER diagrams are used to represent the E-R model in a database, which makes them easy to
be converted into relations (tables).
 ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.
 ER diagrams require no technical knowledge and no hardware support.
 These diagrams are very easy to understand and easy to create even for a naive user.
 It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists
of these symbols:

 Rectangles: Rectangles represent Entities in the ER Model.

 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
 Double Rectangle: Double Rectangle represents a Weak Entity.
BCA III – SAD Compiled By: GIRIJA 20
 BCA III – SAD Compiled By: GIRIJA 21

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.

Entity
An Entity may be an object with a physical existence – a particular person, car, house, or
employee – or it may be an object with a conceptual existence – a company, a job, or a university
course.
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other
Entity in the Schema. It has a primary key, that helps in identifying it uniquely, and it is
represented by a rectangle. These are called Strong Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some
entity type exists for which key attributes can’t be defined. These are called Weak Entity types.
Attributes
Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes that define entity type Student. In ER diagram, the
attribute is represented by an oval.

Attribute
 BCA III – SAD Compiled By: GIRIJA 22

1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute.
For example, Roll_No will be unique for each student. In ER diagram, the key attribute is
represented by an oval with underlying lines.

Key Attribute
2. Composite Attribute
An attribute composed of many other attributes is called a composite attribute. For example,
the Address attribute of the student Entity type consists of Street, City, State, and Country. In ER
diagram, the composite attribute is represented by an oval comprising of ovals.

Composite Attribute
3. Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example, Phone_No (can
be more than one for a given student). In ER diagram, a multivalued attribute is represented by
a double oval.

Multivalued Attribute
 BCA III – SAD Compiled By: GIRIJA 23

4. Derived Attribute
An attribute that can be derived from other attributes of the entity type is known as a derived
attribute. e.g.; Age (can be derived from DOB). In ER diagram, the derived attribute is represented
by a dashed oval.

Derived Attribute
Relationship Type and Relationship Set
A Relationship Type represents the association between entity types. For example, ‘Enrolled in’
is a relationship type that exists between entity type Student and Course. In ER diagram, the
relationship type is represented by a diamond and connecting the entities with lines.

Entity-Relationship Set
Cardinality
The number of times an entity of an entity set participates in a relationship set is known as
cardinality. Cardinality can be of different types:
1. One-to-One: When each entity in each entity set can take part only once in the relationship,
the cardinality is one-to-one. Let us assume that a male can marry one female and a female can
marry one male. So the relationship will be one-to-one.
the total number of tables that can be used in this is 2.

one to one cardinality

 BCA III – SAD Compiled By: GIRIJA 24

2. One-to-Many: In one-to-many mapping as well where each entity can be related to more than
one relationship and the total number of tables that can be used in this is 2. Let us assume that
one surgeon deparment can accomodate many doctors. So the Cardinality will be 1 to M. It
means one deparment has many Doctors.
total number of tables that can used is 3.

one to many cardinality

3. Many-to-One: When entities in one entity set can take part only once in the relationship set
and entities in other entity sets can take part more than once in the relationship set, cardinality
is many to one. Let us assume that a student can take only one course but one course can be
taken by many students. So the cardinality will be n to 1. It means that for one course there can
be n students but for one student, there will be only one course.
The total number of tables that can be used in this is 3.

many to one cardinality

4. Many-to-Many: When entities in all entity sets can take part more than once in the
relationship cardinality is many to many. Let us assume that a student can take more than one
course and one course can be taken by many students. So the relationship will be many to many.
the total number of tables that can be used in this is 3.

many to many cardinality

 BCA III – SAD Compiled By: GIRIJA 25

Example: ER diagram of Library Management System

Q1. Construct an E-R diagram for a car-insurance company whose customers own one or more cars each.
Each car has associated with it zero to any number of recorded accidents.
 BCA III – SAD Compiled By: GIRIJA 26

Q2. Construct an E-R diagram for a hospital with a set of patients and a set of medical doctors. Associate
with each patient a log of the various tests and examinations conducted. Answer: See Figure 2.2

Q3. A university registrar’s office maintains data about the following entities:

a) courses, including number, title, credits, syllabus, and prerequisites;

b) course offerings, including course number, year, semester, section number, instructor(s), timings,
and classroom;
c) students, including student-id, name, and program; and
d) Instructors, including identification number, name, department, and title. Further, the enrollment
of students in courses and grades awarded to students in each course they are enrolled for must
be appropriately modeled.
Construct an E-R diagram for the registrar’s office. Document all assumptions that you make about
the mapping constraints.
BCA III – SAD Compiled By: GIRIJA 27

Assignments:
1. Define Data Flow Diagrams (DFDs) and explain their purpose in system analysis and
design.
2. Identify and explain the different symbols used in DFDs and their respective roles in
illustrating data flow.
3. Describe the process of context-level DFD creation, including identifying external
entities, data flows, and the main system process.
4. Explain the purpose of level-0 and level-1 DFDs and outline the steps involved in
decomposing a context-level DFD into these levels.
5. Define conceptual modeling and explain its role in representing the data entities and
relationships within a system.
6. Describe the Entity-Relationship (ER) model and its key components: entities,
attributes, and relationships.
7. Differentiate between different types of relationships in an ER model (e.g., one-to-
one, one-to-many, many-to-many) and provide examples for each.
8. Explain the concept of cardinality and ordinality in ER modeling and their importance
in representing data relationships accurately.
9. Compare and contrast DFDs and ER models, highlighting their strengths and
limitations as tools for process and data analysis.