Data Flow Diagrams: Not Always Effective..

Data Flow Diagramming Mistakes

DFDs look easy on the surface – after all, what’s hard about writing down a few
bubbles and arrows? In practice the techniques proves to be somewhat more
difficult than one might first think.

This final blog post considers some of the common mistakes that occur when one first
tries to build DFDs. There are several common types of mistakes. One that is
easy to check for and correct involves using so-called illegal data flows.

Illegal Data Flows

One of the patterns of data flow analysis is that all flows must begin with or
end at a processing step. This makes sense, since presumably data cannot simply
metastasize on its own without being processed. This simple rule means that the following mistakes can be fairly easily identified and corrected in a DFD.

Black Holes, Grey Holes and Miracles

A second class of DFD mistakes arise when the outputs from one processing step do not match its inputs. It is not hard to list situations in which this might occur:

• A processing step may have input flows but no output flows. This situation is sometimes called a black hole.
• A processing step may have output flows but now input flows. This situation is sometimes called a miracle.
• A processing step may have outputs that are greater than the sum of its inputs – e.g., its inputs could not produce the output shown. This situation is sometimes referred to as a grey hole.

I hope my blog posts have helped you understand the difference between Flow charts and DFD’s, the advantages of choosing each one, and also the disadvantages that come with them!

Thanks for reading!

Creating Flowcharts

So, in the blogs so far, I have tried to help to make it easier to understand what Flowcharts and DFD’s are, their properties and their uses. I have also gone through some rules to help with the drawing of them for the exam. However, I find that the best it is a lot easier to understand something while being shown it rather than reading it in a textbook or a blog. So, in this blog I will share a tutorial video which I found very helpful when trying to learn more about flowcharts. The video is a guide on how to create Flowcharts using Microsoft Visio. I hope you also find it useful.

 

My Final post on Flowcharts

Well this is my sixth and final post. My group and I have covered many topics. Some of these include the uses of Flowcharts, how flowcharts are applied in a business environment, how to construct a Flowchart, the differences between DFD’s and Flowcharts and even there purpose and use. Starting this blog I had no idea how important Flowcharts are in business. They provide a visual aid in presentations. They often help explain what words cannot. This is vital in business especially when using power – point.

This is one of the most simple Flowcharts I found that explain it.

http://www.breezetree.com/articles/what-is-a-flow-chart.htm

Other things to note. An “as is Flowchart” is an overview of your business processes. A DFD is linked to the flow of info in a computer program. This differs from Flowcharts. Always give the Flowchart a title.

That about sums it up. The purpose of this blog was to learn about Flowcharts and DFD’s while also learning how to blog properly. I learned both over the last few weeks. I’d like to thank my group members for working so well and providing so much feedback. Thank you 🙂

Common mistakes in Flowcharts

well this is my second last post and i am going to cover the most common mistakes people and businesses make when constructing a Flowchart .This is a subject i haven’t addressed yet but my group members have mentioned briefly. I am going to add to their points and also make my own unique ones.

There are several common Flowchart mistakes. These can range from design to content and even the wrong colours. Here are the common mistakes I found :

• Scale = Many Flowcharts are re-sized to try and fit them into presentations on a single page. As a result these charts are unreadable. This is especially true in power point presentations. So the remedy is to fit the Flowcharts over multiple pages to rid the confusion.
• Excessive Colours = People often overdo colour and it takes away the real message of the Flowchart. Use colour but don’t let it distract the reader too much.
• Wrong Flow Symbols = use the correct shape of the symbols for their given action. I’ve spoken about this in previous posts. All shapes must be the same size to attain consistency. Otherwise the Flowchart will look uneven.
• Spacing Problems = Try to keep the spacing equal between every shape. This will make the chart look even the whole way through.
• Direction issues = Flowcharts should generally go in one of two directions. These are from left to right or more commonly top to bottom. Try not to mix the two and choose one. Connectors should be used when liking the shapes

This website was helpful.

http://www.breezetree.com/articles/common-flowchart-mistakes.htm

Well I hope I’ve highlighted some of the major mistakes with Flowcharts. This should help you all to make better charts that can be read easily 🙂

Differences Between Flowcharts and DFD’s

There are many differences between flowcharts and DFD’s.

1. A flow chart details the processes to follow, whereas a Data Flow Diagram details the flow of data through a system

2. On a flow chart processes are shown one at a time, whereas with a Data Flow Diagram the processes operate at the same time.

3. Processes on flowcharts are part of a single program with consistent timing, whereas processes on a Data Flow Diagram can have dramatically different timing, eg. daily, weekly. etc.

4. A flow chart describes the program being used, whereas a data flow diagram determines the flow of data, eg. between subroutines, or between other different programs.

5. There are 2 types of Data Flow Diagram’s, logical and physical, whereas there are 4 different types of flowcharts: systems flowchart, deployment flowchart, top-down flowchart and logic flowchart.

 

Data Flow Diagrams

Introduction.DFD show how data through inputs and outputs is processed by a system. Data flow diagrams are made up of 4 vital components (Processes, External entities, data flows and Data stores.

I went through the notes and they said Dfd’s were easy to understand. I totally disagree. This is how I simplify it.
4 components of dfd.
1. Processes convert incoming data flows to outgoing data flows.
2.External entities are objects outside the system with which the system is in contact with. They are the things giving and receiving the systems inputs and outputs.
3.Data flows are lines, tunnels, pipelines (whatever you want to call them) with which information goes. N.B Every data flow must be labelled with what type of data is flowing through.
4.Data Stores save data within the system. They are sometimes referred to as “files”.

Data Flow diagrams and Security Requirements.

So far throughout my blogs I have given; a basic introduction to both flowcharts and data flow diagrams, informed you all of the different types, the advantages, the construction of flowcharts and DFDs, the use of flowcharts in the healthcare system and for my final blog I’m going to concentrate on how DFDs can be used within web security requirements.

When identifying applications, process and data, a data flow diagram is a good place to start. As I said in a previous blog, a data flow diagram is to identify the process in a system and the data that flows in and out of the process. Data flow consists of four symbols; external entity, process, data flow and data store. Data flow documentation consists of the data elements contained in the flow as well as the entity associated with the data elements. An example of a data flow diagram with four symbols can be seen below:

Data flow diagrams can be useful in helping you specify your security requirements and to help when beginning a new web development project.  Although there is a whole literature around the usage of DFDs, you don’t necessarily have to be fancy about it; you can just use simple boxes to illustrate where data will be stored and lines to indicate where data will be flowing.

This is a very simple example of  a high-level DFD where the process and flow are easily understood.

A very important aspect is trust boundaries, where the data comes from or goes someplace where you don’t completely trust,for example the internet. When the diagram is drawn, they begin to look for security related issues. Threat Modelling is often used to pick out certain security related issues which may need to be addressed. Sometimes this can result in some complications and it is very easy to lose sight of where you are and what you are looking to achieve.

If you or your company have previous knowledge of Threat Modelling then you could use it.

Your data is stored in the data store. Ideally data should be stored in as little places as possible. In some cases you may be storing more data than what is necessary. If you are processing data which falls under Data Protection Legislation then you would need to encrypt any data which is stored on portable media, such as USB sticks or laptops. Devices which store sensitive or confidential information should be securely destroyed at the end of their life.

For data flows you should help you specify the security requirements that your application will need to meet. For example, now you should have a better idea of where you need to encrypt your data, perform validation, authenticate the user etc.

But,you need to be careful. There could be areas where there is data stored where you mightn’t have thought about. If it is stored externally, then you may need to think about mechanisms such as encryption.

Situations will arise sometimes, where you need to extract production data to assist in troubleshooting. This could mean enabling application logging, or copying files to other systems where it can be analysed. You should have procedures  in place to make sure that this information is deleted when the troubleshooting has been completed. Also disable any logging which you may have turned on during the troubleshooting.

Data Flow Diagrams are a useful tool in helping you specify the security requirements that your application needs to meet. This is a  is relatively simple and informal approach and is easy to understand. In particular, it does not use Threat Modelling techniques to analyse your risks.

This is my last blog so I hope you all enjoyed reading them and that they will be helpful to ye for revision 🙂 Best of luck to everyone in the exams 🙂
References:

http://www.docstoc.com/docs/document-preview.aspx?doc_id=69490571

http://blog.alexisfitzg.com/2010/10/data-flow-diagrams-and-security.html

Go with the Flow (The final Part)

So this is the beginning of the end, well for the blogs anyway. We‘ve learned a lot about flow charts and DFDs over my past blogs and other bloggers as well. To summarise quickly we learned
• What is a flowchart and what are their benefits
• What exactly is a DFD and what does it stand for?(Data flow Diagram ,Duh!)
• The symbols
• How and to make them
• And how they can improve exam performance

It is this blogger’s hope that you can now appreciate the how important flow charts are. And if there is positive purpose of this blog entry it is that you will become more aware of how often flow charts are being used in day to day life.

Computer programmers need to make a flow chart for computers to figure out what people need e.g. what are the processes, where can the can we insert a decision option and what are the alternatives uses for the computer user.

Answering those annoying telephone customers services where they give a “decision” like press one for x or press four for y.

The first thing you see on a D.V.D, when it’s in a D.V.D player, is the first “entity” of home menu

Inserting your credit card number to buy a product in a website requires a process and perhaps a decision on whether you would like updates from the website

To conclude, it’s been a pleasure. The whole point of these blogs was to learn more about our topic and how to use social media. But also and more importantly have, to have fun. I’ve certainly have a lot of fun as you can tell by my informal entries. I hope you found blogs informative and also amusing. As cheesy as sounds Il end this blog and complete my entry list by using the words I start every blog with. So good bye for now and remember always
“Go with the Flow”

Common mistakes in DFD’s…

In the blog I will discuss some of the commonly made mistakes in regards of Data Flow Diagrams.

Illegal Data Flows

• These are mistakes that are easy to check for and easily corrected.
• One of the patterns of data flow analysis is that all flows must begin with or end at a processing step because obviously data cannot simply metastasize on its own without being processed
• This simple rule means that the following mistakes can be fairly easily identified and corrected in a DFD. Diagram
• Diagram below to explain:

Diagramming mistakes

A second class of DFD’s mistakes result from when the outputs from one processing step do not match its inputs. For example:

• A processing step may have input flows but no output flows. This situation is sometimes called a black hole.
• A processing step may have output flows but now input flows. This situation is sometimes called a miracle.
• A processing step may have outputs that are greater than the sum of its inputs – e.g., its inputs could not produce the output shown. This situation is sometimes referred to as a grey hole.

 

DFDs are not flow charts

This mistake however is more difficult to identify then the two previous.

• Flow chart diagrams can be useful for describing programming logic or understanding a single sequence of process activities.
• Flow charts often show both processing steps and data “transfer” steps, DFDs only show “essential” processing steps.
• Flow charts might include arrows without labels: DFDs never show an unnamed data flow.
• Flow charts show conditional logic, DFDs don’t.
• Flow charts show different steps for handling each item of data, DFDs might include several data items on a single flow arrow.

 

 

Decomposing Data Flow Diagrams…

In this blog I will break down Data Flow Diagrams to try and gain a better understanding of how the system works.

• DFD’s deals with problems by allowing more detailed assessments of the high level processes.
• This is achieved by breaking up each process into as many sub-processes as believed to be necessary.
• Any process on a DFD may be broken down into several sub-processes which, when observed collectively, make up that process
• The decomposition of a DFD into lower level DFDs is known as levelling
• The DFD that shows the entire system is known as the top level.
• The DFDs that contain more in thorough views of the level 1 process make up level 2 DFDs
• Any level 2 process that is further decomposed gives rise to a level 3 DFD and it continues.