Data flow diagrams (1 Viewer)
- Thread starter Fiona
- Start date
sunny
meh.
- Joined
- Jul 7, 2002
- Messages
- 5,350
- Gender
- Male
- HSC
- 2002
A case of doco-phobia! 
Lets for a second forget about all the funny symbols that the DFD tries to throw at you.
Right!
Now lets consider this system:
I want a system that gives me a UAI 10 points higher that what I tell it - just to make me feel good about myself, and the system will save this UAI so I can drool over it later
So, obviously the system needs someone to tell it what the input UAI is.
Then, the system will need something, some process, to add 10 to this UAI.
And of course, this new UAI is outputted back to me and to be saved. So we now have these several things:
- someone to input the UAI
- add 10 to the UAI
- make the new UAI pretty on a document
- show me the new UAI
- saving the UAI
First of all, the person inputting the information into the system is not part of the system. ie, an external entity. So, according to the rules of the DFDs, this needs a square box around it.
Then, now that "me" has been created in the DFD, what does he do? He enters the UAI into the system. This is a process, and again by the rules of the DFD, this needs a circle around it.
Now that the old UAI is in the system, another process is used to add 10 to this, and another process to prettify this new UAI back to me, and a storage device to save the UAI (an opened box)
In most DFD questions you will encounter, you will be given a scenario of some required or built system and you will need to make a DFD for it. You can get around most of these by first identifying the elements of the systeml, working out their relationships with each other, and deciding what element of the DFD they are.
Lets for a second forget about all the funny symbols that the DFD tries to throw at you.
Right!
Now lets consider this system:
I want a system that gives me a UAI 10 points higher that what I tell it - just to make me feel good about myself, and the system will save this UAI so I can drool over it later
So, obviously the system needs someone to tell it what the input UAI is.
Then, the system will need something, some process, to add 10 to this UAI.
And of course, this new UAI is outputted back to me and to be saved. So we now have these several things:
- someone to input the UAI
- add 10 to the UAI
- make the new UAI pretty on a document
- show me the new UAI
- saving the UAI
First of all, the person inputting the information into the system is not part of the system. ie, an external entity. So, according to the rules of the DFDs, this needs a square box around it.
Then, now that "me" has been created in the DFD, what does he do? He enters the UAI into the system. This is a process, and again by the rules of the DFD, this needs a circle around it.
Now that the old UAI is in the system, another process is used to add 10 to this, and another process to prettify this new UAI back to me, and a storage device to save the UAI (an opened box)
In most DFD questions you will encounter, you will be given a scenario of some required or built system and you will need to make a DFD for it. You can get around most of these by first identifying the elements of the systeml, working out their relationships with each other, and deciding what element of the DFD they are.
Fosweb
I could be your Doctor...
Sunny - you have much too much free time. (especially during exams...)
Just remember:
1. People (ie Clients/Customers/Users etc...) all go in boxes.
2. Tasks the program completes (the processes) go in circles.
3. The actual data (variables) passed between these tasks get written on the lines. These 'flow' around the diagram... hence the name DFD.
4. Anything written to or loaded from a file (ie a Database) gets put in an open box on its side... You still have to write the Data going to this if you are saving, or coming from this is you are loading.
Context diagram: (Or "0 Level" DFD)
Shows the whole system as one process. No data is written on the lines. Context diagrams have an External Entity (i.e. the User), then a line to one process (Usually the name or logical overall function of the system), then a line to another External Entity.
You should always do a context diagram first.
Just remember:
1. People (ie Clients/Customers/Users etc...) all go in boxes.
2. Tasks the program completes (the processes) go in circles.
3. The actual data (variables) passed between these tasks get written on the lines. These 'flow' around the diagram... hence the name DFD.
4. Anything written to or loaded from a file (ie a Database) gets put in an open box on its side... You still have to write the Data going to this if you are saving, or coming from this is you are loading.
Context diagram: (Or "0 Level" DFD)
Shows the whole system as one process. No data is written on the lines. Context diagrams have an External Entity (i.e. the User), then a line to one process (Usually the name or logical overall function of the system), then a line to another External Entity.
You should always do a context diagram first.
Fosweb
I could be your Doctor...
yeah - i know he has... but i was referring to uni exams...