DFDs_and_Algorithms.pptx

DFDs and Algorithms
Module 3: Learning Objectives 6 - 9

Dataflow Diagrams
Learning Objective 6

What is a Data Flow Diagram?
• A data-flow diagram (DFD) is a graphical depiction of how data moves through
an information system.
• DFDs may also be used to visualize data processing (structured design).
• Data Flow Diagrams are used as a method of expressing a system at any degree
of detail using a visual network of symbols that depicts data flows, data
storage, data processes, and data sources/destinations.
• The goal of data flow diagrams is to serve as a semantic link between users and
system engineers.

The schematics are as follows:
• Graphical, eliminating thousands of words
• Logical representations, modeling WHAT a system does, rather than physical
models showing HOW it does it
• Hierarchical, showing systems at any level of detail
• Jargon-less, allowing user understanding and reviewing.

• The purpose of data flow diagramming is to create a model of a system that
everyone can understand.
• The diagrams serve as the foundation for structured systems analysis.
• Other structured systems analysis tools, such as data structure diagrams, data
dictionaries, and procedure-representing approaches such as decision tables,
decision trees, and structured English, supplement data flow diagrams.

DFD Symbols – External Entity
• An external entity is a source or destination of a data
flow that is not within the scope of the investigation.
• It represents sources of data to the system or
destinations of data from the system.
• A business process diagram only depicts entities that
generate or receive data.
• A square with a meaningful and unique identity is
utilized as the symbol.
External Entity

DFD Symbols – External Entity
• It is customary for all the information represented within a system to have come
from and/or been passed on to an external source or receiver.
• These external entities can be replicated on a diagram to prevent data flow lines
from crossing.
• A stripe is painted across the left-hand corner when they are repeated.
• Adding a lowercase letter to each entity on the diagram is a smart method to
distinguish them.

DFD Symbols – Process
• A process demonstrates the translation or manipulation of data flows inside a system.
• The process symbol represents an activity that transforms or manipulates the data.
• The emblem is a rectangular box with three descriptive elements.
• The first thing that displays is an identifying number in the upper left-hand corner.
• This is assigned at the top level randomly and serves as a unique reference.

• Second, a location displays to the right of the identifier and explains where
the process occurs in the system. This might be a department or a piece of
hardware.
• Finally, a descriptive title is added in the box's center. This should be a
straightforward imperative statement with a specified verb, such as
‘maintain customer records' or 'find driver.'
Process

• When identifying processes, avoid glossing over them without fully comprehending their
significance.
• The inclusion of ambiguous phrases in the descriptive title box, such as 'process' or 'update,'
is an indication that this has occurred.
• The most important thing to remember is that the description must make sense to the
person who will be utilizing the diagram.

• Data Flow double headed arrows can be used (to show two-way flows) on all but bottom
level diagrams.
• Furthermore, like most other symbols, a data flow at a certain level of a diagram can be
dissected into several data flows at lower levels.
• Data Storage Facilities each store should be assigned a letter followed by an arbitrary
number.

DFD Symbols – Data Flow
• A data flow diagram depicts the movement of information from its
origin to its destination. It represents the movement of data through
the diagram.
• A data flow is depicted as a line with arrowheads indicating the flow
direction.
• Information is always flowing to or from a process and can be written,
spoken, or electronic.
• Each data flow can be identified by the processes or data storage at
its beginning and end, as well as by a description of its contents.
Data Flow

DFD Symbols – Data Store
• A data store is a storage location for information within a system.
• It is symbolized as a thin open-ended rectangle.
• Data stores can be long-term files, such as sales ledgers, or they can
be short-term accumulations, such as batches of papers waiting to be
processed.
• Each data store should be assigned a unique reference followed by an
arbitrary number.
Data Store

DFD Symbols – Resource Flow
• A resource flow depicts the movement of any physical material from its origin to
its destination.
• As a result, they are sometimes referred to as physical flows.
• A meaningful name should be given to the actual material in issue.
• Resource flows are often limited to early, high-level diagrams and are employed
when a depiction of the actual movement of materials is thought to be
significant to the study.

DFD Procedure
The procedure for producing a DFD is as follows:
1. Identify and list external entities that provide inputs to/receive outputs from the system.
2. Identify and list external entity inputs and outputs
3. Draw a context diagram with the system in the middle and other entities transmitting and
receiving data flows
4. Identify the business functions that fall within the scope of the system
5. Discover the data links that exist between business functions

DFD Procedure
6. Certify receipt of data supplied via personal contact and vice versa
7. Monitor and record what occurs to each data flow that enters the system (data transfer,
data storage, data transformation/processing).
8. Try to link any diagram elements into a preliminary draft
9. Ensure that all data flows have a source and a destination.
10. Ensure that data originating from a data storage is entered

DFD Procedure
11. Redraw to simplify, ponder and question result
12. Review with "informed“ perspective
13. Repeat above steps as needed

DFD - Things to Keep In Mind
Setting system boundaries is a critical decision:
• External entities contribute to establishing the location of the border.
• An interface system can be represented as a separate entity.
• To ensure system control, the external entity's input may need to be dictated.
Customers, for example, may be required to submit purchases or refund requests
including specified information, which may need the use of a system to assist in the
completion of a form.

Setting system boundaries is a critical decision:
• The use of output by management, such as reports, may necessitate some consensus
on strategies to be implemented, which may imply that the entity becomes part of
the system rather than external to it.
• When in doubt, incorporate the external entity as a process within the system and
then assess with those involved.

Label your procedures precisely and colorfully:
• A procedure with the output "Report" and the label "Produce Report" informs a
reviewer virtually little.
• If you're having problems categorizing anything on the diagram, it's probably because
you don't understand it well enough.
• Choose your names with consideration.

Think logically rather than physically:
• Ignore things like medium, color, typeface, layout, packaging, timing, sequencing, and
so on.
• Consider "what" rather than "how."
• Something logical can be physically accomplished in more than one manner.
• Including "when," "where," and "how" indicates that you are getting physical.

Consider data flow rather than control flow:
• Data flows are data routes.
• Consider what data is required to complete a procedure or update a data storage.
• A data flow diagram is not a flowchart and should not include loops or control
transfers.
• Consider the data flows, methods, and storage required to move a data structure
through a system.

First and foremost, consider what occurs to a "good" transaction:
• Because they are so focused on the branches of the trees, people tend to lose sight of
the forest.
Confusion will not persuade reviewers:
• A good data flow diagram will be so easy to understand that others will wonder what
took you so long.
Data store-to-data-store, external entity-to-external-entity, and external entity-to-data-store
connections are seldom appropriate:
• Data flows with an arrowhead on each end generate labeling confusion.
• They should not be used.

Do not try to put everything you know on the DFD:
• The diagram should serve as index and outline.
• The index/outline will be "fleshed out" in the data dictionary, data structure
diagrams, and procedure specification techniques.

Algorithms for Problem-Solving

Problem Solving
• A problem-solving strategy is a plan of action used to solve a problem.
• Different strategies are coupled with various action plans.
• Trial and error, for example, is a well-known approach:
• "If at first you don't succeed, try, try again," as the old saying goes, explains
trial and error.
• In terms of your faulty printer, check the ink levels first, and if that doesn't
work, make sure the paper tray isn't jammed.
• Perhaps the printer isn't linked to your laptop.
• When using trial and error, you would keep trying different solutions until you
found one that worked.
• Although trial and error is not one of the most time-efficient tactics, it is
widely employed.

Algorithms for Problem Solving
• An algorithm is a problem-solving method that provides step-by-step instructions for
achieving a desired result.
• Consider an algorithm to be a recipe with highly explicit instructions that results in a
well put together dish
• Every time they are conducted, they provide the same desired result.

Algorithms for Problem Solving
• Algorithms are widely employed in our daily lives, particularly in computer science.
• When you conduct an Internet search, search engines such as Google utilize algorithms
to determine which entries will display first in your list of results.
• Facebook also uses algorithms to determine which posts appear on your newsfeed.

Characteristics of a Good Algorithm

Characteristics of A Good Algorithm
Characteristics of a good algorithm include:
• Specified Input
• Specified Output
• Definitiveness
• Effectiveness
• Finiteness

Specified Input
• Input is data entered to be transformed during computation in order to produce the
output.
• You should consider input as the data needed to begin to get the desired result
• Input precision requires that you know what kind of data, how much and what form
the data should be

Specified Output
• The output is data resulting from a completed process
• It is the data resulting from the computation (your intended result)
• An algorithm should have 1 or more well-defined outputs, and should match the
desired output.
• Often, the name of the algorithm gives you an idea of the output. For example,
“Algorithm to compute batting average” lets us know that the output would be the
batting average.
• Output precision requires that you know what kind of data, how much and the form
the output should be in (or even if there will be any output)

Definite
• Algorithms must be specific in identifying or specifying every step and the order
the steps should be taken in
• Definiteness of an algorithm means specifying the sequence of operations for
converting input to output
• Details of each step should be specified as well. For example, error handling

Effective
• For an algorithm to be effective, the steps required to get the desired output
must be doable.
• For an algorithm to be effective, it means that all those steps that are required
to get to output must be feasible with the available resources.
• It should not contain any unnecessary and redundant steps which could make an
algorithm ineffective.

Finite
• The algorithm must eventually come to an end
• Stopping may mean that you get the expected output, or you get a response
indicating that no solution can be achieved
• Finiteness is not usually an issue for non-computer algorithms
• Computer algorithms often repeat instructions with different data and as such
finiteness is a potential issue

Other Characteristics of Algorithms
Algorithms should:
• Be general and applicable to several cases
• Use resources efficiently (quick speed and use minimal RAM/Disk space)
• Be understandable so the operations are clear to readers
• Be clear and precise despite the language used:
• Natural languages are ambiguous (words or phrases may have many meanings)
• Programming languages are formal languages with clear, unambiguous rules

Ways of Representing Algorithms

English-Like Algorithms (Narrative)
• An algorithm can be written in a variety of ways.
• It can be written in basic English, although this style has several disadvantages.
• Natural language can be ambiguous and hence lacks the quality of being definite.
• Each step of an algorithm should be explicit and have only one meaning.
• English-like algorithms are not thought to be suitable for the majority of activities.

Flowcharts
• Flowcharts pictorially depict a process.
• They are easy to understand and are commonly used in the case of simple problems.

Pseudocode
• Pseudocode is an informal way of programming description that does not require any strict
programming language syntax or underlying technology.
• Pseudocode has an advantage of being easily converted into any programming language.
• This way of writing algorithm is most acceptable and most widely used.
• In order to write a pseudocode, one must be familiar with the conventions of writing it.

Pseudocode – Format
• Single line comments start with //
• Multi-line comments occur between /* and */
• Blocks are represented using brackets. Blocks can be used to represent
compound statements or the procedures:
{ statements }
• Statements are delimited by semicolon.

• Assignment statements indicates that the result of evaluation of the expression
will be stored in the variable.
< variable > = < expression >
• The boolean expression 'x > y' returns true if x is greater than y, else returns false.
• The boolean expression 'x < y' returns true if x is less than y, else returns false.
• The boolean expression 'x <= y' returns true if x is less than or equal to y, else
returns false.

• The boolean expression 'x >= y' returns true if x is greater than or equal to y, else returns false.
• The boolean expression 'x != y' returns true if x is not equal to y, else returns false.
• The boolean expression 'x == y' returns true if x is equal to y, else returns false.
• The boolean expression 'x AND y' returns true if both conditions are true, else returns false.
• The boolean expression 'x OR y' returns true if any of the conditions is true, else returns false.
• The boolean expression 'NOT y' returns true if the result of x evaluates to false, else returns false.

• if< condition >then< statement >
• This condition is an enhancement of the above 'if' statement. It can also handle the case
where the condition isn't satisfied.
if< condition >then< statement1 >else< statement2 >

• switch case (C or C++)
case { :< condition 1 >: < statement 1 > ..... ..... ..... :< condition n >: <
statement n > :default: < statement n+1 > }
• while loop
while< condition >do { statements }
• do-while loop
repeat statements until< condition >

• for loop
for variable = value1 to value2 { statements }
• input instruction
Read
• Output instruction
Print

• The name of the algorithm is < name > and the arguments are stored in the < parameter list >
Algorithm< name > (< parameter list >)

Objectives 6 – 9 Complete!

SOURCES
• https://course.oeru.org/ipsy102/learning-pathways/cognition-language-and-problem-
solving/problem-solving-strategies/
• http://sofia.cs.vt.edu/cs1114-ebooklet/chapter4.html
• https://www.igi-global.com/dictionary/algorithms-aided-sustainable-urban-design/988 ·
• https://course.oeru.org/ipsy102/learning-pathways/cognition-language-and-problem-
solving/problem-solving-strategies/
• https://dev.to/yogeswaran79/ways-of-writing-an-algorithm-2io3

DFDs_and_Algorithms.pptx

More Related Content

Similar to DFDs_and_Algorithms.pptx

Recently uploaded

DFDs_and_Algorithms.pptx