Business Analysis Diagrams

Created By – Diwakar Singh

Business Process Model And Notation
BPMN 2.0 is an open standard notation system based on a flowcharting technique that
is used to model business processes. The standard is widely used in business process
management since it is easily understood by business users while also providing
technical users with the ability to represent and implement complex processes.

History of BPMN2.0:
BPMN was originally developed by the Business Process Management Initiative (BPMI)
in 2004. In 2005 BPMI merged with the Object Management Group (OMG). One year
later BPMN was formally adopted as a standard by OMG. BPMN 2.0 was developed in
2010 but was not released until 2013.

Benefits of BPMN2.0:

1. It helps stakeholders gain a better understanding of a process through a universally

understood language.
2. It helps to close the gap between the various stages of business process
BPMN2.0 – High Level Overview
Business Process
Business Process Examples
BPMN 2.0 tools
Below are the tools that can be used to make BPMN2.0 diagrams:

• Aris
• Draw.io
• Visio
• Lucid Chart
Questions to ask before making BPMN2.0 diagram
Before making BPMN2.0 diagrams you should ask your stakeholders below
questions:
• What level of BPMN2.0 diagram is needed? There are 4 levels of BPMN2.0
diagram – L0, L1, L2, L3.
• Are there any assumptions to be made?
Tokens in BPMN2.0
It is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed.

Token is born when a Start Event is triggered (e.g. by receiving a Message, when some condition becomes
true or for a plain Start Event simply when some employee starts the process).

Token then follows the Sequence Flow (it cannot use Message Flows or other arrows) and flows through a
process (passing through elements such as Gateways or Tasks/Sub-processes) right till the End Event where
it is consumed.
Important thing about token is that it helps figure out what can happen in a process.

In the beginning all Activities in a process are Inactive. When a Token arrives Activity becomes Ready.
Understanding Token in detail
BPMN2.0 Elements and Symbols
There are 4 primary elements of BPMN: Flow Objects, Connecting Objects, Swimlanes
and Artifacts.

• Flow objects. These are the core elements of BPMN. It form the overall workflow. The
three main flow objects are called events, activities, and gateways. Events are triggers
that start, alter, or complete a process. Activities are tasks performed by individuals or
technology. Gateways are not decision points, it just helps to direct the flow of the
process.
• Swimlanes. A pool includes the participants in a process. Swimlanes show the
activities for each participant.
• Connecting objects. Illustrate how the elements of a process relate to one another.
There are three types of connecting objects: sequence flows, message flows,
and associations. Sequence flows show the order that activities will be performed.
Message flows show communications between departments. Associations shows the
relationship between an artifact to an event, activity, or gateway.
• Artifacts. Artifacts are used to provide additional information about a process. There
BPMN2.0 Flow Objects - Events
Events represents an event in a business process.

Start event symbol – It signals the first step of a business process

Intermediate event symbol – It represents any event that occurs between a start and end event.

End event symbol – It signals the final step in a process

BPMN2.0 – Event Symbols(Message Start)

A message start event can be used to start a process instance using a named message. Points to keep in
mind while using message start event.

• The name of the message start event must be unique across a given process definition, i.e., a process
definition must not have multiple message start events with the same name.
• The name of the message start event must be unique across all deployed process definitions. The
engine throws an exception upon deployment of a process definition in case one or more message
start events reference a message with the same name as a message start event already deployed by a
different process definition.
BPMN2.0 Message Start Example
Intermediate Catch Event
An Intermediate Catch Event indicates that something is happening between the start and end of a process.
Intermediate Events affect the flow of a process, but do not start or directly terminate the process.

Intermediate Catch Event is used to:

•Show where messages are expected or sent within a process.
•Show delays that are expected within a process.
•Interrupt normal flow through exception handling.

Types of Intermediate Catch Events are the following:

• Message Catching Intermediate Event

• Timer Catching Intermediate Event
• Conditional Catching Intermediate Event
BPMN2.0 – Event Symbols(Message Intermediate Catching)

A Message Catching Intermediate Event is used to receive a message. When a token arrives at the message
intermediate catching event it will wait there until a message with the proper name arrives.
BPMN2.0-Event Symbols(Message Boundary Event)
Interrupting Non-Interrupting

Boundary events are catching events that are attached to an activity. This means that while
the activity is running, the message boundary event is listening for named message. When
this is caught, two things might happen, depending on the configuration of the boundary
event:
•Interrupting boundary event: The activity is interrupted and the sequence flow going out
of the event is followed.
•Non-interrupting boundary event: One token stays in the activity and an additional token
is created which follows the sequence flow going out of the event.
Message Boundary Interrupting Event Example
Message Boundary Event Non-Interrupting Example
BPMN2.0-Event Symbols(Message Intermediate Throwing event)

A Message Intermediate Throwing event sends a message to an external service.

BPMN2.0-Event Symbols(Message End Event)

When process execution arrives at a Message End Event, the current path of execution is ended and a message is sent.
BPMN2.0 – Event Symbols(Timer)
Timer events are events which are triggered by a defined timer. They can be used as start event, intermediate
event or boundary event. Boundary events can be interrupting or not.

Timer start – A timer start event is used to create process instance at a given time. It
can be used both for processes which should start only once and for processes that
should start in specific time intervals.

Timer Intermediate catching – A timer intermediate event acts as a stopwatch. When an execution arrives
in catching event activity, a timer is started. When the timer fires (e.g., after a specified interval), the
sequence flow going out of the timer intermediate event is followed.

A timer boundary event acts as a stopwatch and as an alarm clock. When an execution arrives in the activity to which the
boundary event is attached, a timer is started. When the timer fires (e.g., after a specified interval), the activity is
interrupted and the sequence flow going out of the timer boundary event are followed.
There is the difference between an interrupting and a non interrupting timer event. The interrupting event is the default.
The non-interrupting event leads to the original activity not being interrupted, the activity stays there.
BPMN2.0 Timer Event Example
BPMN2.0-Event Symbols(Conditional Start)
The conditional event defines an event which is triggered if a given condition is evaluated to true.

A conditional start event can be used to start a process by evaluating some condition. One process can have one or
more conditional start events.
If more than one conditions are fulfilled the respective number of processes will be triggered.
When deploying a process definition with conditional start events, the following considerations apply:
•The condition of the conditional start event must be unique across a given process definition, i.e., a process
definition must not have multiple conditional start events with the same condition. The engine throws an exception
upon deployment of a process definition in case two or more conditional start events contain the same condition.
•Process versioning: Upon deployment of a new version of a process definition, the conditional subscriptions of the
previous version are cancelled. This is also the case for conditional events that are not present in the new version.
BPMN2.0 – Event Symbols(Conditional Intermediate Event)
A conditional intermediate event is an intermediate event with a Boolean condition as
its trigger. The event trigger further workflow execution when the condition evaluates
to true and its outgoing flow is taken.

The event must define the expression property. When a conditional intermediate
event is placed in the process workflow, it has one incoming flow, one outgoing flow
and the execution starts when the incoming flow transfers to the event.

When a conditional intermediate event is placed on an activity boundary, the

execution is triggered at the same time as the activity execution. If the event is non
interrupting, the event triggers continuously while the condition is true.
Conditional Event Example
BPMN2.0 Gateways
Gateways are used to control how Sequence Flows interact as
they converge and diverge within a Process. It is used to control the flow of the
process so it must not be confused with decisions. They do not make the
decisions, they only direct the flow according to the decisions previously made.

Types of Gateways in BPMN2.0:

• Exclusive Gateway
• Inclusive Gateway
• Parallel Gateway
• Complex Gateway
• Event Gateway
• Exclusive Start Gateway
• Parallel Start Gateway
BPMN2.0 – Exclusive Gateway

It is represented by either a diamond with an X, or without the X. It is used to create alternative paths within
a Process flow. For a given instance of the Process, only one of the paths can be taken.
When the execution of a workflow arrives at this gateway, all outgoing sequence flows are evaluated in the
order in which they are defined. The sequence flow whose condition evaluates to true is selected for
propagating the token flow.
Note that the semantics of an outgoing sequence flow:
•In general, in BPMN 2.0, all sequence flows whose conditions evaluate to true are selected to continue in a
parallel way. When using an exclusive gateway, only one sequence flow is selected.
•If no sequence flow can be selected, an exception will be thrown. To ensure a sequence flow will always be
selected, have no condition on one of your flows.
Exclusive Gateway Example
BPMN2.0- Inclusive Gateway

An inclusive Gateway specifies that one or more of the available paths will be taken. They
could all be taken, or only one of them.

1. Unlike the Exclusive Gateway, all condition Expressions are evaluated.

2. The true evaluation of one condition Expression does not exclude the evaluation of
other condition Expressions
3. All Sequence Flows with a true evaluation will be traversed by a token
4. Since each path is considered to be independent, all combinations of the paths MAY be
taken, from zero to all
5. However, it should be designed so that at least one path is taken.
Inclusive Gateway Example
BPMN2.0 – Parallel Gateway

Parallel gateways are used to represent two tasks in a business flow. A parallel gateway is used to visualize
the concurrent execution of activities. A parallel gateway models a fork into multiple paths of execution, or a
join of multiple incoming paths of execution.
•Fork – all outgoing sequence flows are followed in parallel, creating one concurrent execution for each
sequence flow.
•Join – all concurrent executions arriving at the parallel gateway wait at the gateway until execution has
completed for each of the incoming sequence flows. The process then continues.

A parallel gateway can have both fork and join behavior if there are multiple incoming and outgoing
sequence flows for the same parallel gateway. In this case, the gateway will first join all the incoming
sequence flows, before splitting into multiple concurrent paths of execution.
Parallel Gateway Examples
BPMN2.0 – Event Based Gateway
The Event-Based Gateway represents a branching point in the Process where the
alternative paths that follow the Gateway are based on Events that occur rather than the
evaluation of the process flow that lead to this point. A specific Event such as the receipt
of a message from a customer, determines the path that will be taken.

An event-based gateway must have at least two outgoing sequence flows. Each
sequence flow must to be connected to an intermediate catch event of type timer
or message.
When an event-based gateway is entered then the workflow instance waits at the
gateway until one of the events is triggered. When the first event is triggered then
the outgoing sequence flow of this event is taken. No other events of the gateway
can be triggered afterward.
Event Based Gateway Example
BPMN2.0 - Activities
It is a work that company or organization performs in a business process.
Activities can be performed by person or a system. It can be task or sub-
processes.

There are 3 types of activities in BPMN2.0

1. Task
2. Sub Process
3. Call Activity
Task
A person or applications will perform the task when it is executed.

In BPMN 2.0, there are different types of tasks identified for use in representing more
specific behavior that tasks might represent. Here is a list of BPMN 2.0 task type:

•Service Task
•Send Task
•Receive Task
•User Task
•Manual Task
•Business Rule Task
•Script Task
Task – Service Task

A Service Task is a Task that uses a Web service, an automated application, or other
kinds of service in completing the task.
Task – Send Task

A Send Task is represents a task that sends a Message to another lane or pool. The Task
is completed once the Message has been sent.
Task – Receive Task

A Receive Task indicates that the process has to wait for a message to arrive in order
to continue. The Task is completed once the message has received.
Task – User Task

A User Task represents that a human performer performs the Task with the use of a
software application.
Task – Manual Task

A Manual Task is a Task that is performed without the aid of any business process
execution engine or any application.
Task – Business Rule Task

Business rules describe initially in plain words how operations,

definitions, and constraints are applied by an organization. They can
apply to many different things like people, processes, or overall
corporate behavior.

It provides a mechanism for a process to provide input to a Business Rules Engine and
then obtain the output provided by the Business Rules Engine.
Business Rule Task - Example
Task – Script Task

A Script Task is executed by a business process engine. The task defines a script that the
engine can interpret. When the task begin, the engine will execute the script. The Task
will be completed when the script is completed.
BPMN2.0 Sub Process
A Sub-Process is an activity that contains other activities, gateways, events, and so on,
which in itself forms a process that is part of the bigger process. A Sub-Process is
completely defined inside a parent process (that’s why it’s often called an embedded Sub-
Process).

Constraints in using sub-process:

• A Sub-Process can only have one 'start event', no other start event types are allowed. A
Sub-Process must at least have one 'end event'. Note that the BPMN 2.0 specification
allows the omission of the start and end events in a Sub-Process
• Sequence flows cannot cross Sub-Process boundaries.
BPMN2.0 Sub Process Types
Types of BPMN2.0 sub process:

• Loop
• Multi-instance
• Compensation
• Ad-hoc
• Compensation and ad-hoc
BPMN2.0 sub process example
BPMN2.0 - Swimlanes
Swimlane objects in BPMN are rectangular boxes that represent participants of a
business process. A swim lane may contains flow objects that are performed by that lane
(participant), except for black box that must have an empty body.

Swimlanes may be arranged horizontally or vertically. They are semantically the same but
just different in representation. For horizontal Swimlanes, process flows from left to
right, while process in vertical Swimlanes flow from top to bottom.

There are two kinds of Swimlanes: Pools and Lanes.

Swimlanes - Pools
Pools represent participants in a business process. It can be a specific entity
(e.g. department) or a role (e.g. Administrator).

Inside a pool, there are flow elements. They represent the works that the
pool needs to perform under the process being modeled. However, there is
one kind of pool that has no content at all. It is known as the Blackbox
pool. Blackbox pool is often used when modeling entities external to the
business process. As it is external, its internal flow does not have any
impact on the process being modeled, hence can be skipped, producing a
Blackbox.
Pools - Examples
Swimlanes - Lanes
Lanes are sub-partition of pools. Same as pools, lanes can be used to
represent specific entities or roles who are involved in the process.
Swimlanes - Examples
BPMN2.0 – Connecting Objects
BPMN 2.0 defines four basic connecting objects: Sequence Flow, Message Flow
and two types of Associations. These connecting objects are graphically
represented with the following arrows.
Connecting Objects - Definition
• Sequence Flow - It is used to represent the order of Flow elements in process and
choreography models.

• Message Flow - It is used to show the flow of messages between two participants that
are able to send and receive them. In BPMN, two separate Pools in a Collaboration
Diagram will represent the two Participants.

• Data Association - It is used to show the flow of information between Activities in a

business process.

• Association – It is used to link Artefacts with other BPMN (graphical) elements.

Connecting Objects - Examples
BPMN2.0 - Artifacts
In business process modeling, BPMN Artifacts can be used to include additional
information about a process. There are two types of BPMN Artifacts: Group and Text
Annotation. You can use them to organize tasks and sub-processes or to add
comments/notes in describing process elements.
Artifacts - Grouping
BPMN Group is a visual container to use in creating informal, arbitrary grouping for elements
in a business process diagram. You can create a Group to contain elements that belong
together based on some common characteristic.
Artifacts - Annotations
A BPMN Text Annotation is simply a note – a note to process element or to the business
process itself. You can use Text Annotation to include addition information to flow
objects. Because Text Annotation is presented directly on the diagram, readers can
easily see the information without the need to drill-down into the specification of
elements.
Data Objects - Examples
Use Case Diagram
It is a diagram that captures high level functionality of a system using
notations for actors, use cases, and relationship among them. It summarizes
the details of your system's users (also known as actors) and their
interactions with the system.

A Use Case Diagram can help project team members discuss and represent:
• Scenarios in which your system or application interacts with people,
organizations, or external systems.
• Goals that your system or application helps those entities (known as
actors) achieve.
• The Scope of your system
Origin of Use Case Diagram
These days use case modeling is often associated with UML, although it has
been introduced before UML existed. Its brief history is as follow:

•In 1986, Ivar Jacobson first formulated textual and visual

modeling techniques for specifying use cases.

•In 1992 his co-authored book Object-Oriented Software Engineering - A Use

Case Driven Approach helped to popularize the technique for capturing
functional requirements, especially in software development.
Use Case Diagram – Purpose?
A use case diagram doesn't go into a lot of detail—for example, don't expect it to model
the order in which steps are performed. Instead, a proper use case diagram depicts a high-
level overview of the relationship between use cases, actors, and systems.

It can be applied for:

• Representing the goals of system-user interactions

• Defining and organizing functional requirements in a system

• Specifying the context and requirements of a system

• Modeling the basic flow of events in a use case

Components of Use Case Diagram
There are 4 key elements of Use Case Diagram:

1. Use Cases
2. Systems
3. Actors
4. Associations.
Sample Use Case Diagram
Use Case Diagrams – Components in detail
Actors: Actor is someone who interacts with use case(system functions) and has a responsibility toward the
system (inputs), and has expectations from the system (outputs). It is similar to the concept of users and is named
by a noun. It always stays away from the system boundary. Primary actors initiates/triggers the use case and their
goal is fulfilled by use case. Secondary actors provide information to the system and is sometimes referred to as
an external system. Primary actors are usually shown on the left of the system boundary and secondary actors
are shown towards the right. An actor can be a human or a system.

Use Cases: It represents system functions and is named by verb + noun. Each Actor must be linked to a use case,
while some use cases may not be linked to actors.

•Association: The participation of an actor in a use case is shown by connecting an actor to a use case by a solid
link. Actors may be connected to use cases by associations, indicating that the actor and the use case
communicate with one another using messages. Association can be between use cases and between actors.

•System: The system boundary is potentially the entire system as defined in the requirements document. For
large and complex systems, each module may be the system boundary. For example, for an ERP system for an
organization, each of the modules such as personnel, payroll, accounting, etc. can form a system boundary for
use cases specific to each of these business functions. The entire system can span all of these modules depicting
the overall system boundary
Use Case Diagram – Identifying Actors
• Who are the system’s primary users?
• Who requires system support for daily tasks?
• Who are the system’s secondary users?
• What hardware does the system handle?
• Which other (if any) systems interact with the system in question?
• Do any entities interacting with the system perform multiple roles as
actors?
• Which other entities (human or otherwise) might have an interest in the
system's output?
Association – Between Actors and Use Case
Associations between Use Cases - Include
When a use case is depicted as using the functionality of another use case, the relationship between the use cases is
named as include or uses relationship.

An include relationship is depicted with a directed arrow having a dotted line. The tip of arrowhead points to the child use
case and the parent use case connected at the base of the arrow. The stereotype "<<include>>" identifies the relationship
as an include relationship.
Association between Use Case - Extend
When an optional behavior is added to use Case then it can be shown through Extend relationship. It helps
keep the base use case unchanged while adding more specifics or conditional changes. Here base use case
is independent of the extend use case.

The stereotype "<<extends>>" identifies as an extend relationship

Associations between Use Case - Generalization
A generalization relationship is a parent-child relationship between use cases. The child use case is an enhancement of the
parent use case. Generalization is shown as a directed arrow with a triangle arrowhead. The child use case is connected at
the base of the arrow. The tip of the arrow is connected to the parent use case.

A generalization relationship means that a child use case inherits the behavior and meaning of the parent use case. The child
may add or override the behavior of the parent.
Generalization – Example
How to create a Use Case Diagram?
1.List main system functions (use cases) in a column: think of
business events demanding system’s response – users’
goals/needs to be accomplished via the system
2.Draw ovals around the function labels
3.Draw system boundary
4.Draw actors and connect them with use cases
5. Specify include, extend, and generalization relationships
between use cases
Data Flow Diagram
Data flow diagrams are used to graphically represent the flow of data from one
component to another component in a business information system. Through
DFD we can give overview of the system without going into the deep detail of
the system.

They can be used to analyze an existing system or model a new one. Like all the
best diagrams and charts, a DFD can often visually “say” things that would be
hard to explain in words, and they work for both technical and nontechnical
audiences.
Logical DFD vs physical DFD
These are the two categories of a data flow diagram: Logical and Physical.

A logical DFD focuses on the business and business activities, while a physical DFD looks at
how a system is implemented. So while any data flow diagram maps out the flow of
information for a process or system, the logical diagram provides the “what” and the
physical provides the “how.” They are two different perspectives on the same data flow,
each designed to visualize and improve the system. The logical DFD describes the business
events that take place and the data required for each event.

It provides a solid basis for the physical DFD, which depicts how the data system will work,
such as the hardware, software, paper files and people involved. In tandem, the logical and
physical can fully visualize the current state and model the new state to be considered and
then implemented.
Logical DFD vs Physical DFD - Example
Components of DFD
External Entity – Also known as actors, sources or sinks, and terminators, external entities produce and consume data that flows
between the entity and the system being diagrammed. These data flows are the inputs and outputs of the DFD. Since they are external
to the system being analyzed, these entities are typically placed at the boundaries of the diagram. They can represent another system
or indicate a subsystem.

Process – An activity that changes or transforms data flows. Since they transform incoming data to outgoing data, all processes must
have inputs and outputs on a DFD. This symbol is given a simple name based on its function, such as “Ship Order,” rather than being
labeled “process” on a diagram. In Gane-Sarson notation, a rectangular box is used and may be labeled with a reference number,
location of where in the system the process occurs and a short title that describes its function. Processes are typically oriented from top
to bottom and left to right on a data flow diagram.

Data Store – A data store does not generate any operations but simply holds data for later access. Data stores could consist of files held
long term or a batch of documents stored briefly while they wait to be processed. Input flows to a data store include information or
operations that change the stored data. Output flows would be data retrieved from the store.

Data Flow – Movement of data between external entities, processes and data stores is represented with an arrow symbol, which
indicates the direction of flow. This data could be electronic, written or verbal. Input and output data flows are labeled based on the
type of data or its associated process or data store, and this name is written alongside the arrow.
DFD- Symbols and Notations
Stating the type of data – D, M, T
Each data store which is drawn in a Data Flow Diagram are prefixed by a letter, which is 'D'
by default. The letter indicates the kind of data the data store holds. The letter 'D' is used to
represent a persistent computerized data, which is probably the most common kind of data
type in a typical information system.

Besides computerized data, data can also be held for a short time in temporary. We call this
kind of data transient data and is represented by letter 'T’.

Sometimes, data is stored without the use of a computer. We call this kind of data manual
data and is represented by letter 'M'. Finally, if the data is stored without using computer
and also is held for a short time, this is known as manual transient data and is represented
by T(M).
Rules for making DFD diagrams
1.Process labels should be verb phrases; data stores are represented by nouns
2.A data store must be associated with at least a process
3.An external entity must be associated with at least a process
4.Don't let it get too complex; normally 5 - 7 average people can manage processes
5.DFD is non-deterministic - The numbering does not necessarily indicate sequence, it's
useful in identifying the processes when discussing with users
6.Datastores should not be connected to an external entity, otherwise, it would mean that
you're giving an external entity direct access to your data files
7.Data flows should not exist between 2 external entities without going through a process
8.A process that has inputs but without outputs is considered to be a black-hole process
Cautions while preparing DFD
Keep in mind that Data Flow Diagram was designed for representing the
exchange of information. Connectors in a Data Flow Diagram are for
representing data, not for representing process flow, step or anything else.
When we label a data flow that ends at a data store "a request", this means we
are passing a request as data into a data store. Although this may be the case
in implementation level as some of the DBMS do support the use of functions,
which intake some values as parameters and return a result, in Data Flow
Diagram, we tend to treat data store as a sole data holder that does not
possess any processing capability.
Common mistakes while making DFD diagram
Data Flow Diagram – Levels and Layers
DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or
beyond. The necessary level of detail depends on the scope of what you are
trying to accomplish.

DFD level 0 is also called context diagram and is at very high level. As you
keep on adding details in your DFD diagram, the level increases accordingly.

There is no specific definition or criteria for DFD levels.

DFD – Level 0 diagram(Context Diagram)
It’s a basic overview of the whole system or process being analyzed or modeled. It’s
designed to be an at-a-glance view, showing the system as a single high-level process, with
its relationship to external entities. It should be easily understood by a wide audience,
including stakeholders, business analysts, data analysts and developers.
DFD – Level 1 diagram
DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram. You will highlight the main functions
carried out by the system, as you break down the high-level process of the Context Diagram into its subprocesses.
DFD – Level 2 diagram
DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to reach the necessary level of
detail about the system’s functioning.
Entity Relationship Diagram
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities”
such as people, objects or concepts relate to each other within a system. ER Diagrams are
most often used to design or debug relational databases in the fields of software
engineering, business information systems, education and research.

ER diagrams are related to data structure diagrams (DSDs), which focus on the relationships
of elements within entities instead of relationships between entities themselves. ER
diagrams also are often used in conjunction with data flow diagrams (DFDs), which map out
the flow of information for processes or systems.
Uses of ER Diagram
•Database design: ER diagrams are used to model and design relational databases, in terms of logic and
business rules (in a logical data model) and in terms of the specific technology to be implemented (in a
physical data model.) In software engineering, an ER diagram is often an initial step in determining
requirements for an information systems project. It’s also later used to model a particular database or
databases. A relational database has an equivalent relational table and can potentially be expressed that way
as needed.
•Database troubleshooting: ER diagrams are used to analyze existing databases to find and resolve problems
in logic or deployment. Drawing the diagram should reveal where it’s going wrong.
•Business information systems: The diagrams are used to design or analyze relational databases used in
business processes. Any business process that uses fielded data involving entities, actions and interplay can
potentially benefit from a relational database. It can streamline processes, uncover information more easily
and improve results.
•Business process re-engineering (BPR): ER diagrams help in analyzing databases used in business process re-
engineering and in modeling a new database setup.
Levels of ER Model
ER Models are typically drawn at up to three levels of detail:

•Conceptual data model: The highest-level view containing the least detail. Its value is
showing overall scope of the model and portraying the system architecture. For a system of
smaller scope, it may not be necessary to draw. Instead, start with the logical model.

•Logical data model: Contains more detail than a conceptual model. More detailed
operational and transactional entities are now defined. The logical model is independent of
the technology in which it will be implemented.

•Physical data model: One or more physical model may be developed from each logical
model. The physical models must show enough technology detail to produce and implement
the actual database.
Limitations of ER Diagram
•Only for relational data: Understand that the purpose is to show relationships. ER
diagrams show only that relational structure.

•Not for unstructured data: Unless the data is cleanly delineated into different fields, rows
or columns, ER diagrams are probably of limited use. The same is true of semi-structured
data, because only some of the data will be useful.

•Difficulty integrating with an existing database: Using ER Models to integrate with an

existing database can be a challenge because of the different architectures.
Components of ER Diagram
An ER Diagram has basically 3 components:

1. Entity - A definable thing—such as a person, object, concept or event—that can have data stored about it. Think of
entities as nouns. Examples: a customer, student, car or product.

2. Attribute - A property or characteristic of an entity.

3. Relationship - How entities act upon each other or are associated with each other
ERD Cardinality
Primary Key and Foreign Key
Composite keys
Understanding ER in a Table - Customer
Order Table
Product Table
Shipment Table
Primary Keys, Foreign Keys, Composite Primary Key - Examples
Bridge Table
Activity Diagram
The activity diagram is a flowchart to represent the flow of control among the activities in a
system. So, we basically depict workflows visually using an activity diagram. An activity
diagram focuses on condition of flow and the sequence in which it happens. We describe or
depict what causes a particular event using an activity diagram.

An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed. The flow of operation
can be sequential, branched, or concurrent. The activity diagram is sometimes considered as
a flowchart. Although the diagram looks like a flowchart but it is not.
Components of Activity Diagram
1. Start Node – The black small filled circle is the standard notation for an initial state before an activity take place.

2. Final activity node – The black circle that looks like a selected radio button is the symbol for the end state of
activity.

3. Activity – The activity symbols are the basic building blocks of an activity diagram and usually have a short description
of the activity that they represent.
4. Control flow – A solid line with an arrow represent the direction flow of the activities. The arrow points in the direction of
progressing activities.

5. Join Node – A join combines two concurrent activities back into a flow.

6. Fork Node – A fork splits single activity into two concurrent activities.
Fork and Join - Example
7. Decision – Diamond shape where two paths coming out of a decision and the condition text lets you know which options
are mutually exclusive.

8. Condition – It is placed next to a decision marker to let you know under what condition an activity flow should split off in
that direction.

9. Merge Node – Two activities are merged with condition and only one activity flows forward.
10. Final Flow Node – It represents the end of a specific process flow.
11. Partition – It is also known as swim lanes which are used to represent or group actions carried out by different actors in
a single thread.

12. Note – It is used to add relevant comment to elements.

13. Time event - This refers to an event that stops the flow for a time; an hourglass depicts it.
Class Diagrams
Class Diagram is one of the most popular structural UML diagrams that helps to visualize, describe(what must be
present in the system being modeled), and document different aspects of the system that has to be designed.

A UML class diagram has 3 sections:

1. Top section - It represents the name of the class. A class represents an object or a set of objects that share a
common structure and behavior.

2. Middle section - It represents the attributes of the class. Attributes are a significant piece of data containing
values that describes each instance of the class. The attributes are shown by visibility factors such as public (+),
private (-), protected (#), and package (~).

3. Lower section - It represents the methods of the class. Methods are also called operations or functions that
allows you to specify any behavioral feature of a class. The methods are represented in the form of a list, where
each method is written in a single line. It demonstrates how a class interacts with data.
Class Diagrams – Visibility factors
• Private (-) : They can't be accessed by any other class or sub class.

• Public(+) : This is just opposite to private and can be accessed by any other class.

• Protected(#) : This can only be accessed by same class or sub class.

• Package(~) : This can be used by any other class as long as it is in the same package.
Class Diagrams - Relationships
1. Inheritance - It means the subclass(child) inherits all the methods and properties of super class. It is also
known as generalization and is symbolized with a straight connected line with a closed arrowhead pointing
towards the superclass(parent).

2. Association - It describes a static or physical connection between two or more objects. It depicts how many
objects are there in the relationship. It is shown by a straight line.

3. Aggregation - An aggregation is a subset of association that defines a part-whole or part-of relationship. In

this kind of relationship, the child class can exist independently of its parent class. It is shown by a line with
open diamond.

4. Composition - The composition is a subset of aggregation. It portrays the dependency between the parent
and its child, which means a child object wouldn't be able to exist if parent object is discarded. It represents
a whole-part relationship. It is shown by a line with closed diamond.
Class Diagrams – Additional Components
Multiplicity - It allows you to set numerical constraints on your relationship. It
defines a specific range of allowable instances of attributes. In case if a range is
not specified, one is considered as a default multiplicity.

Abstract Class - It is a type of class where no objects can be a direct entity of it.
It can can neither be declared nor be instantiated and is is written in italics.
Class Diagram - Example