Data Flow Diagram Level 2 | Computer Engineering | Information

June 10, 2018 | Author: Anonymous | Category: Documents
Share Embed


Short Description

For example, the top level DFD (also known as a Context diagram) is a level 0 DFD, level 1 DFD refers to the initial dec...

Description

Data Flow Diagram (DFD) Description  A Data Flow Diagram (DFD) tracks processes and their data paths within the business or system boundary under investigation. A DFD defines each domain boundary and illustrates the logical movement and transformation of data within the defined boundary. The diagram shows 'what' input data enters the domain 'what' logical processes the domain applies to that data and 'what' output data leaves the domain. !ssentially a DFD is a tool for  process modelling and one of the oldest. Uses  A Data Flow Diagram is useful for establishing the boundary of the busi bu sine ness ss or sy syst stem em do doma main in (t (the he sp sphe here re of an anal aly ysi sis s ac acti tivi vity ty)) un unde der  r  inve in vest stig igat atio ion. n. "t id iden enti tifi fies es any e# e#te terna rnall en enti titi ties es alo along ng wi with th th thei eirr da data ta interfaces that interact with the processes of interest. A DFD can be a useful tool (particularly when used as a top DFD $ refer to %onte#t diagram) diagram) for helping secure stakeholder agreement (sign$off) on the pro&ect scope. "t is also a useful tool for breaking down a process into its sub$processes for  closer analysis. Application  A Data Flow Diagram can be modelled early in the reuirements elicitation process of the Analysis phase within the ystem Development ife %ycle (D%) to define the pro&ect scope. A DFD can also be created throughout the th e D D% % to in inve vest stig igat ate e an as aspec pectt of th the e sy syst stem. em. "f nec neces essa sary ry eac each h proc pr oces ess s un unde derr st stud udy y wi with thin in a DF DFD D can be br brok oken en do dow wn in into to it its s su sub$ b$ processes on a new DFD to show more details. A sub$process in turn can be broken down further to reveal its sub$processes on a new DFD and so on until sufficient analysis is reached. The activity of drilling down the DFD leve le vels ls is ca call lled ed 'f 'fun unct ctio iona nall de deco comp mpos osit itio ion' n' wi with th th the e re resu sult ltin ing g new DF DFD D referred to as a 'levelled DFD'. For e#ample the top level DFD (also known as a %onte#t diagram) diagram) is a level * DFD level + DFD refers to the initial decomposition level , DFD to a second level decomposition and so on. Audience The pr The prim imary ary au audi dienc ence e in invo volv lved ed wi with th a DF DFD D ar are e st stak akeh ehold older ers s su such ch as pro&ect sponsors managers and sub&ect matter e#perts who provide the

information for a DFD and are the same people who should approve each DFD. -ro&ect managers and reuirements teams are also involved to plan the pro&ect work. Components  A DFD can be assembled from the following four components Process: A process is a logical activity that transforms or manipulates Process: A incoming data within the domain under investigation. A process can be regarded as a 'black bo#'/ it receives input processes it and produces output. A rounded rectangle (or circle) represents a process under study. !ach process is labelled inside its rectangle to describe its function or  purpose. "t is common to use a verb$noun phrase for naming a process e.g. 0%heck stock1 and 02eserve product1. "f several Data Flow Diagrams reference each other (e.g. as in a decomposed levelled DFD structure) each process should be tagged with a numbering scheme or identifier to show the hierarchical relationships between them. For e#ample 'process +.*' +. *' in le leve vell * DFD ca can n de deco comp mpos ose e in into to 'p 'pro roce cess ss +. +.+' +' 'p 'pro roce cess ss +. +.,' ,' 'process +.3' etc in level + DFD. imilarly 'process +.+' in level + DFD can decompose further into 'process +.+.+' 'process +.+.,' etc in level , DFD and so on. "t is usual to place the level identifier above the process name with a hori4ontal line separating them. Externall entity Externa entity:: An e#ternal entity sits outside the domain of interest and supplies data to or receives data from the domain. An e#ternal entity is referred to as an e#ternal source or sink (destination) for data flowing in and out of the domain. A rectangle defines an e#ternal entity and is labelled wit ith h a no noun un ph phra rase se in insi side de it its s re rect ctan angl gle e to de desc scri ribe be an or orga gani nisa sati tion on process machine or person (i.e. a thing) that is outside the domain under  analysis. !#amples of naming an e#ternal entity are 0-ayment company1 0tore locator1 '5ainframe server' and 0%ustomer1. 6ote an e#ternal entity in a DFD is not permitted to transform data/ only a process can. Data flow: A flow: A data flow represents the path of data moving through the domain under analysis. anal ysis. A data flow shows the movement of data d ata between a process and an e#ternal entity a process and another process and a process and a data store (data repository). An arrow is the symbol used to connect a process with other DFD components. !ach arrow should be labelled appropriately to describe the data being passed e.g. 0%ustomer  details1 detail s1 02e&ected order1 and 'toc 'tock k level lookup' are common common.. A data flow can move the same type of data in both directions in which case both ends

information for a DFD and are the same people who should approve each DFD. -ro&ect managers and reuirements teams are also involved to plan the pro&ect work. Components  A DFD can be assembled from the following four components Process: A process is a logical activity that transforms or manipulates Process: A incoming data within the domain under investigation. A process can be regarded as a 'black bo#'/ it receives input processes it and produces output. A rounded rectangle (or circle) represents a process under study. !ach process is labelled inside its rectangle to describe its function or  purpose. "t is common to use a verb$noun phrase for naming a process e.g. 0%heck stock1 and 02eserve product1. "f several Data Flow Diagrams reference each other (e.g. as in a decomposed levelled DFD structure) each process should be tagged with a numbering scheme or identifier to show the hierarchical relationships between them. For e#ample 'process +.*' +. *' in le leve vell * DFD ca can n de deco comp mpos ose e in into to 'p 'pro roce cess ss +. +.+' +' 'p 'pro roce cess ss +. +.,' ,' 'process +.3' etc in level + DFD. imilarly 'process +.+' in level + DFD can decompose further into 'process +.+.+' 'process +.+.,' etc in level , DFD and so on. "t is usual to place the level identifier above the process name with a hori4ontal line separating them. Externall entity Externa entity:: An e#ternal entity sits outside the domain of interest and supplies data to or receives data from the domain. An e#ternal entity is referred to as an e#ternal source or sink (destination) for data flowing in and out of the domain. A rectangle defines an e#ternal entity and is labelled wit ith h a no noun un ph phra rase se in insi side de it its s re rect ctan angl gle e to de desc scri ribe be an or orga gani nisa sati tion on process machine or person (i.e. a thing) that is outside the domain under  analysis. !#amples of naming an e#ternal entity are 0-ayment company1 0tore locator1 '5ainframe server' and 0%ustomer1. 6ote an e#ternal entity in a DFD is not permitted to transform data/ only a process can. Data flow: A flow: A data flow represents the path of data moving through the domain under analysis. anal ysis. A data flow shows the movement of data d ata between a process and an e#ternal entity a process and another process and a process and a data store (data repository). An arrow is the symbol used to connect a process with other DFD components. !ach arrow should be labelled appropriately to describe the data being passed e.g. 0%ustomer  details1 detail s1 02e&ected order1 and 'toc 'tock k level lookup' are common common.. A data flow can move the same type of data in both directions in which case both ends

should show the arrows. Data flows are also useful for identifying interfaces which will need closer data analysis (e.g. !2 data modelling). 6ote that a data flow is considered to be withi within n the domain of the process under study whereas an e#ternal entity is not. Data store: A store: A data store represents a logical data repository accessible within the domain under study. A data store can be a place where data is crea cr eate ted d re read ad ch chan ange ged d an and d st stor ored ed te temp mpor orar aril ily y or pe perm rman anen entl tly y by a process. A thin rectangle with the right side open (or two hori4ontal parallel lines) shows a data store and is labelled with a noun phrase inside its rectangle to describe the data stored e.g. '7rder records' and '7nline catalogue'. -hysically a data store can represent a file or a database system. 6ote a data store is not permitted to process data. Note: Ther Th ere e ar are e tw two o ma main in st styl yles es of di diag agra ramm mmat atic ic no nota tati tion ons s fo forr Da Data ta Fl Flow ow Diagrams/ 8ane 9 arson notation set (e.g. rounded suare symbol for a process missing right$sided thin rectangle symbol for a data store) and :ourdon's notation (e.g. circle symbol for a process parallel hori4ontal lines symbol for a data store). ;hile there are guiding principles and rules for using Data Flow Diagrams in pr prac acti tic ce th they ey ar are e no nott nec eces essa sari rily ly al alw way ays s fo folllo low wed ed.. o ome me DF DFD D pract pra ctit itio ioner ners s ad add d new sy symbo mbols ls or ad adapt apt th the e ru rule les s to su suit it th thei eirr nee needs ds.. ometimes this could be useful but the important point is that whatever the princip prin ciples les or rul rules es they should be appl applied ied cons consist istent ently ly thr throug oughout hout the pro&ect. The following are some of the principles and rules for using Data Flow Diagrams Principles: ;ithin a DFD the e#ternal environment (i.e. e#ternal entities) sends data into the domain under analysis where it is transformed as it moves from one pr proc oces ess s to ano anoth ther er in insi side de th the e dom domai ain. n. Th The e pro proce cess ssed ed dat data a fi final nally ly returns to the e#ternal environment as output data.  A DFD is designed to be broken down or decomposed into a hierarchical tree structure of Data Flow Diagrams (DFD levels) with each child DFD revealing more details than its parent. Rules:  A process and a data store must each have incoming and outgoing data flows.  A process and a data store can each have one or more input data flows and one or more output data flows.

 A process can connect to any other component including to another  process.  An e#ternal entity must send its outgoing data flow only to a process.  An e#ternal entity must receive an input data flow only from a process.  A data store receives an incoming data flow only from a process.  A data store sends an output data flow only to a process. 7nly a process is permitted to transform or change data. Development The following steps present guidelines for developing Data Flow Diagrams Define Defin e the process: tart a DFD by identifying each process under study and naming it appropriately. "f the process needs to be broken down into sub$p su b$proc roces esse ses s fo forr fu furt rthe herr ana analy lysi sis s ad add d a num numbe berin ring g sc schem heme e to eac each h process to show the hierarchical relationships between the parent and child processes (see '-rocess' under %omponent section). Also label each DFD with a descriptive name for referencing purposes appending its levelled DFD seuence identifier appropriately. appr opriately. Identify external entities: "dentify each e#ternal entity that interacts or  impacts the process of interest and label each one with a descriptive name. Connect data flows: %onnect each e#ternal entity to the process under  investigation by an arrow to show its data flow direction. 6ame each data flow clearly and as close to it as possible so as to avoid confusing the name with other data d ata flows close by. Identify data stores: Add stores: Add any an y identified data store on the diagram diagra m label it and connect its data flow to its associated process. Repeat the steps for each levelled DD: 2epeat the above steps for  each levelled DFD that is discovered or needed for further analysis. Finally name nam e eac each h DF DFD D co cons nsis iste tent ntly ly fo forr ref refer erenc encin ing g ba back ck to it th throu rough ghou outt th the e pro&ect. !ips: % disc-ssion on this exercise can be !o-nd at the end o! this chapter . Exercise 14

Decompose the ?ideo 6ental evel 1 DFD process "loan o! video# into a evel & DFD. % disc-ssion on this exercise can be !o-nd at the end o! this chapter . Review Question 2

Create a evel 1 DFD !or the 2state %gency case st-dy based on the context diagram !rom the previo-s 6eview @-estion and the case st-dy text. % disc-ssion on this review A-estion can be !o-nd at the end o! this chapter . Review Question 3

Create a evel & DFD !or the "invoice client# process o! the 2state %gency case st-dy  based on the evel 1 DFD !rom the previo-s 6eview @-estion and the case st-dy text. % disc-ssion on this review A-estion can be !o-nd at the end o! this chapter . ummar! and recap Context diagrams

$he Context Diagram is drawn -p at the o-tset o! analysis, and is -sed to establish the analysis !ramewor. It involves establishing the bo-ndaries o! the system and the scope o! the investigation, to ens-re that no essential areas are omitted !rom the investigationB and so that reso-rces are not wasted on detailed wor in areas o-tside o!  the system scope. $he analyst m-st establish a clear overview o! the system -nder investigation, and identi!y the activities and in!ormation that are necessary !or the b-siness to meet its obectives. $his may be done in cons-ltation with a single -ser, with a broad b-t adeA-ately detailed nowledge o! all areas incl-ded within the scope, or in

cons-ltation with a gro-p o! -sers. %lternatively, partial views obtained individ-ally !rom a n-mber o! -sers may be combined to give the complete pict-re. $he Context Diagram, sometimes called evel 0 Data Flow Diagram, is drawn -sing a single process, appropriately labelled, to represent the entire system. %ll data !lows into and o-t o! the system, to and !rom external so-rces and recipients, are shown aro-nd the edge o! the process. $he types o! in!ormation !lowing within the system will be a!!ected by the nat-re o! system being investigated. $he c-rrent system may be entirely man-al or it may be  partly comp-terised b-t reA-iring maor enhancements. %n existing comp-ter system may no longer meet -sers# reA-irements, or may no longer be s-pported (either by external s-ppliers or internal I$ reso-rces). In some cases there may be no existing system in place to s-pport, !or example, a new area o! the b-siness or new legislation, in which case it may be necessary to investigate how other organisations have addressed the iss-e. %ll systems have both !ormal components  s-pported by set proced-res and str-ct-red in!ormation s-ch as !orms, records and !iles 3 as well as in!ormal aspects 3 which operate thro-gh int-ition and -dgement 3 which -ses conversation and other -nstr-ct-red in!ormation. $he -nstr-ct-red as well as str-ct-red in!ormation !lows need to be considered d-ring investigation o! the c-rrent system. Levels

4ost practical systems will have many h-ndreds o! processes. Clearly, i! these were all shown on one data3!low diagram then we wo-ld hardly be any better o!! than i! we had -sed a single text doc-ment to describe the system. owever, we do need to thin  abo-t all these processes and describe them. $o resolve this problem, data3!low diagrams can have a n-mber o! levels and the whole system is represented by a set o! levelled data3!low diagrams. $he top3most level is called the context diagram or level 0 diagram. n it there is a single process represented by a plain box (with no divisions) representing the system as a whole. $he remainder o! the diagram is all o! the external entities and the data3 !lows between them and the system. $h-s, the diagram gives the context !or the system  where the bo-ndaries are between the system and the rest o! the world. $he next level which is simply called the level one diagram shows the maor  processes o! the system. %ll o! the external entities are still shown b-t now the  processes which receive inp-ts and generate o-tp-ts are also shown and also the data3

!lows between these processes. $he level one diagram is said to expand the process in the context diagram. E-st as the level one diagram expands the context diagram so a second level diagram expands a process in the level one diagram. $he only di!!erence is that the second level diagram has a box aro-nd it which loos lie the original process box b-t the lower section is big eno-gh to draw a diagram in. $he inp-ts and o-tp-ts to the  process become inp-ts and o-tp-ts to the new diagram. o- show the processes and data stores s-pplying the inp-ts or receiving the o-tp-ts o-tside o! the box !or the  process. ther than that, a level two diagram loos -st lie a level3one data3!low diagram with data3stores, processes and data3!lows between them. %lso lie a level one, data3!lows cannot !low directly to or !rom a data store to o-tside o! the process. Geca-se each process in the level one diagram may be expanded to a level two diagram, level two in !act consists o! a set o! diagrams. $he remaining levels wor in the same way. 2ach level is a set o! diagrams expanding the processes in a diagram on the previo-s level 3 a third level diagram expands a  process on a second level diagram, a !o-rth level process expands a process on a third level diagram and so on. $he levels stop when the analyst !eels that all processes have  been described in s-!!icient detail. +ote di!!erent processes can be expanded to di!!erent levels. n the level one diagram, there may be one process which does not need any expansion whilst another one may be very complex and is expanded thro-gh several levels o! diagrams. How to Make Data!ow Diagrams

E-st as !or logical data str-ct-res, to mae a data3!low diagram we m-st analyHe the reA-irements (case st-dy) and describe the system in terms o! the components o! data3 !low diagrams. :everal attempts will be needed be!ore a !inal and complete model o! the system can be prod-ced. 7n!ort-nately, -nlie a logical data3str-ct-re, there is no straight!orward way to  progress thro-gh developing a data3!low diagram. We are aiming there!ore to get a seleton model on the paper which we can then wor with and develop more !-lly. 2ach stage will be ill-strated with examples !rom the !ollowing 2state %gent case st-dy.

Estate "gent case stud!

Clients wishing to p-t their property on the maret visit the estate agent, who will tae details o! their ho-se, !lat or b-ngalow and enter them on a card which is !iled according to the area, price range and type o! property . 8otential b-yers complete a similar type o! card which is !iled by b-yer name in an %9  binder. Weely, the estate agent matches the potential b-yer# reA-irements with the available  properties and sends them the details o! selected properties. When a sale is completed, the b-yer con!irms that the contracts have been exchanged, client details are removed !rom the property !ile, and an invoice is sent to the client. $he client receives the top copy o! a three part set, with the other two copies being !iled. n receipt o! the payment the invoice copies are stamped and archived. Invoices are checed on a monthly basis and !or those acco-nts not settled within two months a reminder (the third copy o! the invoice) is sent to the client. #denti$! the s!stem %oundaries

$he easiest place to maing a data3!low model o! a system is to identi!y what the external entities o! the system are and what inp-ts and o-tp-ts they provide. $hese give yo- the bo-ndary between the system and the rest o! the world. 2xternal entities m-st provide inp-ts or receive o-tp-ts. $here are -s-ally one or two which stand o-t as obvio-sly interacting with the system b-t not being part o! the system. In the 2state %gent system, Client and G-yer stand o-t as good candidates !or external entities. thers may be harder to spot b-t once again consider no-ns in the case st-dy and add them to a list o! possible external entities. It may be tempting to add 2state %gent as an external entity as it obvio-sly interacts with the system. owever, the estate agent is in !act part o! the system in that he or she manip-lates the data within the system. %nother way to thin abo-t it is that the estate agent will act-ally be replaced by the new system and so does not need to appear on the data3!low diagram. From the list o! candidates !or external entities, determine what inp-ts they provide and what o-tp-ts they receive. I! a candidate entity does not seem to provide data into

the system or receive data !rom the system then it is not an external entity and can be disco-nted (!or now). E-st as !or the logical data str-ct-re, an external entity stands !or the type o! thing interacting with the system so all clients and all b-yers are represented by the Client and G-yer external entities. aving identi!ied the external entities there are two ways o! progressing !rom here. Goth are eA-ally sensible approaches and are covered in the next two s-bsections. Follow inputs

2ach inp-t to the system m-st be received by a process. $his gives -s a nat-ral way to start b-ilding -p the model. First, tae one o! the more signi!icant external entities and one o! the main inp-ts it  provides. In o-t case a Client providing 8roperty Details is a good place to start. Draw a b-bble !or the entity, a data !low !or the inp-t and a process which receives the inp-t. From the case st-dy, there sho-ld something which s-ggest what happens when this data comes in and this will be the name o! the process. For 8roperty Details, the case st-dy says that the estate agent enters the details on a card and !iles them. :o the  process name sho-ld be either 6ecord Details or 6eceive Details. 2very process m-st have at least one o-tp-t so !or the process in hand, consider what the o-tp-ts m-st be and p-t labeled arrows on the diagram !or the o-tp-ts. $he data m-st be changed by a process and so sho-ld have a di!!erent name !rom the inp-t. data. 8roperty Details are taen and recorded as a property on the !ile so the o-tp-t co-ld be -st something lie 6ecorded 8roperty or more simple 8roperty.  +ow start again only -sing this o-tp-t as a new inp-t. It m-st either go to another  process, to a data store or to an external entity. It sho-ld be clear !rom the case st-dy what happens. I! a new process is needed then do the same again. Find a sensible name !or the  process -sing the case st-dy, determine and label the o-tp-ts and then !ollow the o-tp-ts. I! the data is stored then add a data store to the diagram, name it sensibly !rom the case st-dy and draw the o-tp-t arrow going into the data store. $his what happens in to 8roperty and so we add the data store 8roperties.

I! the o-tp-t is an o-tp-t !rom the system then simply add the external entity which receives the o-tp-t. When the data is !inally o-tp-t or comes to rest in a data store, go bac and !ollow any o! the other o-tp-ts which may have been de!ined on the way. When they are exha-sted, choose a new inp-t and !ollow that thro-gh in exactly the same way. Follow events

%nother way to approach b-ilding -p a data3!low model is to consider what happens in the system. $he case st-dy will o-tline a n-mber o! events, happenings. $here m-st  be processes in the system which respond to these events or even mae them happen. Identi!y these processes and then add the data inp-ts which are -sed by the process and determine the o-tp-ts. For example, in the estate agent example, there is the phrase 'When a sale is completed...*. $his is an event 3 a sale is completed. From the case st-dy, we see that lots o! things then happen the b-yer con!irms exchange o! contracts so this is an inp-t to some processB the client details are removed !rom the !ile and invoice is sent o-t. $his is the process. % sensible name might be 6ecord :ale or possibly 6eceive :ale Con!irmation. $he data needed is the inp-t !rom the G-yer and client details which are on !ile. $his m-st mean there is a data store somewhere on the diagram holding this in!ormation. I! there is not one there already then add it. %nd the o-tp-t m-st be an invoice to the Client. From here on, the approach is the same as !ollowing inp-ts. For any new o-tp-ts, wor o-t where those o-tp-ts m-st go and i! it is to a process !ollow them as i! they were inp-ts to the new process. 4ost processes can be !o-nd in the case st-dy -sing either techniA-e o! !ollowing inp-ts or !ollowing events. owever, some processes are related to temporal events and so can only be !o-nd by !ollowing events. %s the name s-ggests, temporal events are events which occ-r at speci!ic times. $hey are not prompted to happen by the arrival o! new data b-t rather beca-se a certain time has been reached. $hese events o!ten appear in case st-dies beginning with  phrases s-ch as 'nce a month...* or '%t the end o! every day,...*. owever, once these have been identi!ied, prod-cing the model by !ollowing this event is ex actly the same as !or any other event.

In the estate agent system, there are two temporal events there is a weely matching o! potential b-yers with propertiesB invoices and reminders are sent o-t on a monthly  basis. $ho-gh time is the trigger the processes carrying o-t temporal events, time is generally not shown on the data3!low diagram. $his is beca-se the time aspect is o!ten  -st a practical implementation rather than rigid necessity. For example, the matching o! b-yers and properties at the estate agents need not be weely. It is probably done weely so that it always gets done and also so that it does not interr-pt the other daily  b-siness. With an a-tomated system, it may be possible to match b-yers with  properties as soon as any new details on either arrive. Where time is cr-cial to a process, say acco-nting done at the end o! a !inancial year, then this can be re!lected in the name o! the process. For example, 'Calc-late end o! year pro!its*. Fill in gaps

%!ter b-ilding a model which handles each inp-t or each event, it is worth going over the processes de!ined so !ar. For each process, as the A-estion 'Does this process have all the in!ormation it needs to per!orm its tas>*. For instance, i! a process sends o-t invoices, does it have all the details o! the invoice and the address o! where the invoice sho-ld go> I! the answer is '+o* then add a data3!low into the process which consists o! the data needed by the  process. I! there are several, clearly distinct items o! data needed then yo- may need an arrow !or each item. +ow try to identi!y the so-rce o! the data. First, see i! the data can be !o-nd already inside the system either on a data store or as a res-lt o! a process. I! not, it may be that the data can be obtained by processing some o! the existing data in which case add a new process which taes the existing data and maes the data yo- reA-ire. r, the data may be available b-t !rom the case st-dy it is clear that there is a time3lag between the process that prod-ces the data and the  process which -ses it. :imply add a data store where the data can reside till it is needed. I! there is still no so-rce !or the data then it co-ld be !rom an external entity. In which case, this is a new inp-t to the system. It may not be explicitly mentioned in the case st-dy b-t i! it is necessary then it sho-ld be added. aving added the new inp-t !rom the appropriate entity, go bac and correct the context diagram.

$his is an important tas. I! there is not eno-gh data to s-pport a tas then the system will not !-nction properly. ! co-rse, to be on the sa!e side yo- co-ld have all the data going to all the processes G-t this is not really a sol-tion beca-se with a large system this wo-ld not be practical. aving checed over all the processes, chec that all the o-tp-ts have been generated. %ll o! the inp-ts sho-ld have been covered already b-t this does not mean that all the o-tp-ts have been prod-ced. I! there is still an o-tp-t which does not appear on the diagram, try to see i! there is a process where it co-ld come !rom. I! there is no sensible candidate, add a process and begin to wor bacwards. What inp-ts does the new process need> Where do these inp-ts come !rom> $his tas is almost the same as the one -st described. %ny le!t over o-tp-ts m-st have come !rom a process. -tp-ts cannot come !rom data stores or external entities. I! there is no sensible way to !it the o-tp-t into the diagram then it may be that it is not a sensible o-tp-t !or the system yo- are c-rrently considering. 7se the case st-dy to con!irm this. Finally, chec the data stores. Data m-st get onto a data store somehow and generally data on a data store is read. For each data store, identi!y when the store is either written to or read by considering the processes which may -se the data. %lso, -se the case st-dy to see that yo- have not missed any arrows to or !rom a data store. &epeat

Gy this stage, yo- will have considered all the inp-ts, all the o-tp-ts and prod-ced a !irst dra!t o! the data3!low model o! the system. 6eview the case st-dy, looing !or !-nctionality described which is not per!ormed by the model. In partic-lar, loo !or temporal events as these are sometimes hidden implicitly in the text. Where necessary, add new processes that per!orm the omitted !-nctions and -se the method o! !ollowing events to wor o-t their inp-ts and o-tp-ts. Fill in the gaps o! the model in exactly the same way as was done to prod-ce the !irst attempt. $he model can be declared !inished when yo- have considered every word in the case st-dy and decided that it is not relevant or that it is incorporated in some way into the model

Making levels

For all systems, it is -se!-l to mae at least two levels  the context diagram and the level one diagram. In !act, when in the earlier description o! how to create DFDs yowere told to start by identi!ying the external entities and then to identi!y the inp-ts and o-tp-ts o! the system, yo- were learning how to prod-ce the context diagram. $he rest o! the description was how to prod-ce the level one diagram. Whenever yo- per!orm data !low modeling start in exactly this way, prod-cing a context diagram and then a level one diagram. ! co-rse, in prod-cing the level one diagram yo- may realiHe yo- need more inp-ts and o-tp-ts and possibly even more external entities. In this case, simply add the new data3!lows and the new entities to the level one diagram and then go bac and add them to the context diagram so that  both diagrams still balance. Conversely, yo- may realiHe that some o! the inp-ts and o-tp-ts yo- originally identi!ied are not relevant to the system. 6emove them !rom the level one diagram and then go bac to the context diagram and mae it balance by removing the same inp-ts and o-tp-ts. $his constant balancing between diagrams is very common when doing leveling. What abo-t maing more levels> $here are two reasons !or maing more levels. $he !irst is the obvio-s one 3 yo-, as the analyst, have not !-lly described a process to yo-r  satis!action so yo- expand that process into a next level diagram. $he new diagram is  b-ilt in -st the same way that a level one is b-ilt !rom a context diagram only the new inp-ts and o-tp-ts are precisely to the data !lows to and !rom the process yo- are expanding. $he second reason is that yo- realiHe the diagram yo- are woring on is becoming cl-ttered and -nclear. $o simpli!y the diagram, collect together a !ew o! the processes. Ideally, these processes sho-ld be related in some way. 6eplace them with a single  process and treat the original collection o! processes as a lower level expanding the new process. $he inp-ts and o-tp-ts to the new process are whatever inp-ts and o-tp-ts that are needed to mae the diagrams balance. 6emember to re3n-mber the old processes to show that they have been moved down a level. When doing this, i! there is a data3store which interacts with these processes and only these processes then this too can be p-t on the lower level diagram. Do not gro-p random processes together to mae a lower level diagram. $his will only end -p in a tangle o! arrows and -nrelated processes. % good g-ide as to whether or not yo- have chosen a sensible collection is to try and come -p with a new name

!or the replacement process. I! yo- cannot do this then yo- have probably made too general a gro-ping. 8erhaps leave o-t one or two processes or try a di!!erent gro-ping. %lways bear in mind that levelling is meant to simpli!y and clari!y the diagrams and i!  this cannot be done then it may be best to leave the diagram as it is. "alancing

$he ey to s-ccess!-lly leveling is to mae the diagrams balance. For example, i! a second level diagram expands a !irst level process then all the inp-ts to the process m-st be inp-ts to the second level diagram and all the o-tp-ts !rom the process m-st  be o-tp-ts on the second level diagram. 4oreover, there m-st be no other inp-ts and o-tp-ts. $o be partic-lar, all the inp-ts and o-tp-ts o! the system which appear on the context diagram m-st appear on the level one diagram and there sho-ld be no other inp-ts and o-tp-ts on the level one diagram. $his does not mean there can be no changes to the higher levels o! a set o! diagrams. When prod-cing a lower level diagram, the analyst may realiHe that a new inp-t is needed !or the process to be able to carry o-t its tas. In which case, the analyst sho-ld add this data3!low as an inp-t and then add the inp-t as a data3!low to the original process. I! needs be, this inp-t may be added at several levels higher -p. $he analyst may add new o-tp-ts in the same way. %s long the diagrams always balance, inp-ts and o-tp-ts can be added and removed wherever necessary. #um$ering

 +-mbering in a leveled set o! diagrams is important as the n-mbers help yo- to !ind yo-r way aro-nd the levels. It is mostly easily described by example. :-ppose 6eceive rder is the process n-mbered ; on the level one diagram (6emember, n-mbers do not indicate any order, they are simply labels) and this is expanded to a level two diagram. $he process n-mbers on the level two diagram w ill be ;.1, ;.&, ;.; and so on. :-ppose now that, process ;.9 on the level two diagram is 6egister +ew C-stomer and needs !-rther expansion to a level three diagram. $he process n-mbers on this diagram will be ;.9.1, ;.9.&, ;.9.; and so on. Gasically, the r-le is i! / is the n-mber o! the process yo- wish to expand, then the n-mbers on the next level are /.1, /.&, /.;... . $he same applies !or data stores. Data stores that appear in a level two diagram expanding a process labeled 9 in the level one diagram will be n-mbered D9.1. D9.&,

D9.; and so on. Deeper levels will be D9.1.1, D9.1.&, the n-mbering scheme being  -st the same as !or processes.  +ote tho-gh, it is not the data stores that are expanded. $hey may simply appear in the expansion o! a process. %rocess Descri&tions

%n analyst may de!ine a process where no !-rther expansion is appropriate beca-se there are no separate s-b3processes which may mae -p the original process. owever, the analyst may still wish to describe the process in more detail as it is a  partic-larly di!!ic-lt or tricy process. In this case, the analyst writes down a process description !or the process. $his can tae any !orm which the analyst thins appropriate. $raditional !lowcharts co-ld be -sed or plain 2nglish. 4ore common is what is called str-ct-red 2nglish. $his loos lie 2nglish only it is written more lie a comp-ter lang-age. It -sed to avoid the problem that di!!erent people reading the same piece o! plain 2nglish may -nderstand di!!erent things. We will not cover writing process descriptions in great detail b-t yo- sho-ld at least now what one is. 'alidation

It sho-ld be clear that prod-cing data3!low diagrams can be complicated. It is very easy in all o! this to mae simple mistaes. % ro-tine chec -sing the !ollowing A-estions sho-ld mae s-re that yo- !ind these. $he !irst set o! A-estions re!er to a single diagram so i! yo- have a set o! leveled data3!low diagrams then yo- need to mae these checs !or each diagram. 1. Is every data3!low attached to a process at either the beginning or the end o! the arrow> &. Is every data3!low labeled with a sensible no-n> ;. Does every process have at least one inp-t and at least one o-tp-t> 9. Is every process named sensibly (no -ses o! words lie 'process* or 'handle*) with an action and what is acted -pon> ($he template is 'Do something to something*) =. Is every data store named with the type o! thing it stores in the pl-ral>

J. Where data stores and external entities have been shown several times on one diagram, do all instances have a 'diagonal* line> K. %re there any data3!lows which cross> I! so, try and add more external entities or data stores to avoid the crossing. $his second set o! A-estions is speci!ically abo-t leveling and so sho-ld be ased abo-t the set o! diagrams as a whole. •

Do all diagrams balance> $hat is, where a diagram expands a process in a higher level, are the inp-ts and o-tp-ts to the process identical to the inp-ts and o-tp-ts on the expanded, lower level diagram>



%re all external entities shown on both the context diagram and level one diagram>



%re all o! the processes and data stores n-mbered correctly>

%ll data3!low diagrams are an aid to comm-nication between the analyst. %ltho-gh they may be correct and acc-rate, a messy or tangled data3!low model will red-ce comm-nication as s-rely as a long3winded text description. $o avoid this, as the diagrams evolve, re3draw them whenever they begin to get cl-ttered or have several corrections on them. % simple re3arrangement o! the components may be s-!!icient to greatly improve a diagram. &eading and $urther work 6ead -p abo-t process modelling and requirements analysis  specification  !rom

yo-r boos and other reso-rces. Creating and checking DFDs with ELEC' "D

o- may recall !rom -nit 0& descriptions o! the s-pporting role o! C%:2 tools !or system development. Drawing DFDs on pen and paper by hand is very laborio-s, and maing changes means starting the diagram again in many cases. Drawing DFDs is  possible -sing a general p-rpose drawing tool  s-ch as 4: Draw, and -sing the simple drawing tools in word processors s-ch as 4: WordB however, while s-ch diagrams can be changed and mistaes "-ndone#, the res-lt are diagrams treated by the comp-ter as simply boxes, n-mbers and text. :imple drawing tool will not always  provide all the symbols yo- need, or any !acilities !or "exploding# diagrams to lower levels etc.

% C%:2 tool written !or DFDs can provide s-ch !acilities as •

%ll symbols !or DFDs L text boxes in the right places



"intelligent# moving o! connecting data!low arrows



integrity validation o! diagrams (s-ch as balancing between levels o! diagrams, and ens-ring data !lows do not go straight !rom one data store to another)



a-tomated levelling o! diagrams (so, !or example, any process !ro m a level 1 DFD can be exploded into a level & DFD with all reA-ired data !lows and shared data stores)



-se o! system data dictionaries so that models representing di!!erent views o! the same system (DFD, 26D, 2) can be integrated

 (dvantages o) using C(*E tools like *ELEC+ **(DM Create a new &ro,ect 

Create a new proect !ro"ect # $ew %%%

o- will need to provide a name !or the title o! the proect (here we have entered DFD 01), and yo- need to state the directory in which the proect !iles will be stored (here we have stated the directory cMtempMd!d01). I! yo- are creating the proect in a new directory (recommended) yo-#ll probably get a dialog box asing yo- to explicitly create the directory

%n I+F dialog will then be presented to con!irm that the new proect !iles have been s-ccess!-lly created in yo-r chosen directory

Create a new Context diagram D-D

Create a new diagram !ile &ile # $ew %%% o-#ll be presented with the "Create +ew Diagram# dialog

o- will need to enter a s-itable !ile name (here we have chsen "d!dN01#), and choose "DFD# !rom the "$ype o! Diagram# list o! diagram types (combo3box). o- will then be presented with a choice o! the ind o! DFD yo- wish to create

%t this point we are creating a context diagram, so choose the top option "Context Diagram#. :22C$ ::%D4 will create a new context diagram !or yo-, a-tomatically creating a single process on yo-r new diagram labelled ":ystem context#

C.anging t.e name o) t.e s/stem &rocess $ox 

$o change this de!a-lt ":ystem Context# name to the name o! o-r system we do the !ollowing (we shall call o-r ystem "?ideo 6ental $D#) •

:elect the process box with the mo-se



6ight b-tton clic to get the pop-p men- 'dit%%% (dd ) Links ) Child *iagram ) +sage%%% *elete



From this pop-p men-, choose the !irst option 'dit%%% $he "Context +ode 2ditor# dialog will then be displayed, in which yo- can change the name !rom ":ystem Context# to "?ideo 6ental $D#

o- sho-ld now have a context diagram with the process (context node) "?ideo 6ental $D#

 (dding an external entit/ to a context diagram D-D

$o add an external entity to a context diagram, yo- !irst need to have created a new context diagram (or opened an existing one). o- need to right3b-tton clic on the white bacgro-nd o! the diagram (i.e. don#t clic over a process box or other diagram obect) to get the !ollowing pop-p men- 'xternal entity ) &ree format text ) &ree format box. Choose the !irst o! these items, 'xternal entity . o- will now be o!!ered a dialog in which to enter the name o! the external entity

In this dialog enter an appropriate entity name (we shall entered "C-stomer# at this  point). o- sho-ld now have a context diagram with this new external entity

 (dding 0D letters to external entities

We can add an ID letter to this entity by selecting and right clicing the entity to get the !ollowing pop-p men- 'dit%%% (dd ) I*, Links ) +sage %%% *elete Choose ID !rom this men-, and enter an ID letter (or letters) (here we entered the ID "c#)

$he entity sho-ld now appear with this ID in the -pper part o! the ellipse on the diagram

Deleting an item )rom a diagram

$o delete an item !rom a diagram, !irst clic on the item to select it. For example we might wish to delete the :-pplier external entity item !rom o-r diagram. nce the item has been selected press the D2 ey (or choose Delete !rom the right b-tton dropdown men-). o- will then be ased to con!irm that yo- wish to delete the item.

I! yo- answer 2: the item will be deleted !rom the diagram.

 (dding a data !ow to a context diagram D-D

Ge!ore adding a data !low, ens-re the system process box and the external entity have  been created on the diagram !irst

We shall add a payment data !low !rom C-stomer to the system. :elect the so-rce o! the data !low, so we shall select the C-stomer external entity

 +ow right b-tton clic over this entity to get a pop-p men- 'dit%%% (dd ) I*, Links ) +sage%%% *elete . From the "%dd O option choose "Data Flow#  yo- will now have a data !low !rom the entity "r-bber banding# (shown by the dotted line) wherever yomo-se the mo-se.

$o mae the data !low go into the system, clic the system process box. o- will the  be prompted to enter the name !or this data !low (here we entered "payment#)

o- sho-ld now have a data !low on yo-r DFD

 (dding a das.ed $oundar/ $ox to a D-D

o- may wish to mae the system bo-ndary more explicit on a context diagram by adding a dashed box aro-nd the system. $o create a dashed box -st right b-tton clic on the white bacgro-nd o! the diagram, to get the !ollowing pop-p men- 'xternal entity, &ree format text, &ree format box. From this men- choose "Free Format Gox#. % small dashed box will be added to yo-r diagram

$o change the position o! this box, yo- need to select it with the mo-se (clic on one o! the sides). When the box is selected yo- will see siHing and editing points displayed at each corner, and in the middle o! each side

o- can now -se the mo-se to move each corner or side into an appropriate position to show the bo-ndary

Decom&osing a context diagram into a level 1 D-D

First yo- need to have created or opened yo-r context diagram

:elect and right clic on the system process box to get the !ollowing pop-p men- 'dit%%% (dd ) Links ) Child diagram ) +sage%%% *elete . From this menchoose "Child diagram O DFD O Po to#. I! no child diagram (level 1 DFD) has been created previo-sly !or this process, the !ollowing @72:$I+ dialog will be displayed

:ince we are creating a new diagram, choose +ew !rom this dialog. o- will then be ased to state a !ile name (we chose "d!dN0&#) and the type o! diagram. $he diagram type sho-ld be DFD

o- will then be ased to choose a title !or the new diagram (here we chose "evel 1 DFD#)

:elect ::%D4 may then tae a !ew seconds to add all the data !lows and external entities onto the lower level diagram.

nce it has !inished :elect ::%D4 will present to yo- the new child diagram, which will have each data !low and exteral entity already added to it

 (dding a &rocess to a level 1 D-D

First yo- need to have created or opened yo-r level 1 DFD

6ight b-tton clic somewhere on the white bacgro-nd o! the diagram (i.e. not on a diagram obect), to get the !ollowing pop-p men- !rocess, *ata -tore, Manual -tore, .ransient *ata, .ransient Manual, /esource -tore, 'xternal 'ntity, &ree &ormat .ext, &ree &ormat 0ox . From this men- choose "8rocess#. o- will then be ased !or the name o! this new process (we entered "create new c-stomer#)

$he new process box sho-ld appear on yo-r diagram. $he ID o! the process will have  been a-tomatically n-mbered, so i! the !irst process to be added, it will be n-mbered 1

 +ote that the ID o! the process can be changed by right clicing the item and choosing ID, and editing the n-mber (in the same way the IDs o! external entities can be changed)

 (ttac.ing data !ows to a &rocess on a level 1 D-D

First yo- need to have created or opened yo-r level 1 DFD

:elect the data !low yo- wish to connect to the process. When the data !low is selected yo- will see siHing and editing points displayed at each corner, and in the middle o! each side

$o mae one end o! a data !low become connected to a process box, -se the mo-se to drag and draw the end o! the data !low somewhere over the process box. $he data !low arrow will "r-bber band# as a dotted line !ollowing yo-r mo-se

:elect ::%D4 sho-ld then redraw the diagram with the data !low connected to the  process box

$his techniA-e wors both with data !lows into a process (where the arrow end is dropped into the process box), and with data !lows o-t o! a process (where the non3 arrow end o! the data !low is dropped into the process box)

Reducing t.e num$er o) times an entit/ a&&ears on a level 1

When yo- create a level 1 DFD each data !low is created on the new child DFD with its own external entity

In many cases this can lead to a more complicated ("b-sy#) diagram than necessary   altho-gh there are times when having an entity notated in more than one place on a diagram can red-ce crossed data !lows and aid clarity. In the same way that a "loose# end o! a data !low can be attached to a process (see earlier section), so too can the end o! a data !low attached to an entity be moved, and attached to another diagram obect, s-ch as another instance o! the same entity. First the data !low in A-estion m-st be connected to its appropriate diagram obect. In this example there are two data !lows !rom the C-stomer external entity, both !lowing into the process "create new c-stomer#. %!ter each data !low has been connected to the  process the diagram loos as !ollows

We shall now mae the "payment# data !low leave !rom the same instance o! the C-stomer external entity as "persnal details#.

$he "payment# data !low is selected, and the siHing and editing points are shown

 +ow the so-rce end o! the data !low (where it is connectged to the C-stomer external entity) needs to be dragged and dropped into the desired instance o! the C-stomer entity (the one above). $he data !low will "r-bber band# as a dotted line when being moved in this !ashion

nce dropped both data !lows sho-ld now be attached to the same instance o! the external entity

$he other instance o! the C-stomer external entity can now be deleted !rom the diagram

 (dding a data store to a D-D

Create or open the DFD to which yo- wish to add a data store

6ight clic the bacgro-nd o! the diagram (i.e. not over an item) to get the !ollowing  pop-p men- !rocess, *ata -tore, Manual -tore, .ransient *ata, .ransient Manual, /esource -tore, 'xternal 'ntity, &ree &ormat .ext, &ree &ormat 0ox . From this men- choose "Data :tore#. o- will then be ased the name o! the data store to create (here we have entered "c-stomer !ile#)

$he data store sho-ld then be added to yo-r diagram

Data !lows are created and lined to data stores in -st the same way as to processes and external entities.

 +ote that the ID o! the data store is created a-tomatically, b-t can be changed by right clicing the item and choosing ID. Decom&osing a &rocess to a lower level diagram

$o decompose a process into a lower level DFD is the same process as creating a level 1 DFD !rom system process on the context diagram. First select the process yo- wish to decompose (here we have selected process & "loan o! video#)

$he right b-tton clic to get the !ollowing pop-p men- 'dit%%% (dd ) Links ) Child diagram ) +sage%%% *elete . From this men- choose "Child diagram O DFD O go to#. o- will then be ased to create a new diagram (-nless previo-sly a the process has  been decomposed)

Choosing +2W will res-lt in a dialog where yo- have to choose a !ile name (we chose "p&Nlev&#) and the type o! diagram (choose DFD)

:elect ::%D4 will then tae a !ew seconds to process all data !lows into and o-t o! the process, and will create a diagram with all those data !lows already created !or yo-

8rocesses, data stores and new data !lows can be created in this diagram in the normal way

"alancing consistenc/ c.ecking D-Ds in **(DM

%s mentioned above, one o! the maor advantages o! C%:2 tools lie :elect ::%D4 is that they can per!orm certain types o! validation on diagrams (and between di!!erent models as well).

Consider the !ollowing level 1 DFD, and the decomposed process & "loan o! item# diagrams. $he level 1 DFD !or the ?ideo %gent case st-dy

$he level & DFD !or process "& oan o! video#

%s yo- may have noticed, these diagrams are not balanced !or the !ollowing reasons •

%n extra data !low has been added in the level & DFD o! "loan item recorded# into data store "D& :toc File#



%n error has been introd-ced in the name o! a copy o! the data !low "over d-e items# as "overd-eitem# !rom data store "D& :toc File#to process "s.1 process loan reA-est#.

%ltho-gh care!-lly -sing the process decomposition !acilities in :elect ::%D4 sho-ld avoid any balancing errors, diagrams may have been prod-ced separately by di!!erent analysts, or perhaps errors were introd-ced when simpli!ying a diagram. %nother so-rce o! balancing errors is when an analyst decides there is a need !or a new data !low into o! o-t o! the whole process, b-t !orgets to add a corresponding new data !low in the parent diagram. $o chec the consistency o! child3diagrams, choose !rom the men-s &ile # Check  or clic on the shortc-t tic b-tton. $he res-lt o! r-nning the consistency checer is an error log as !ollows

$he !-ll contents o! the error log !or the level 1 and level & DFDs is Project: C:\TEMP\DFD02\ Title : DFDs Date: 14-Feb-00 Time: 18:44 Checkin P2!"E#2$D%T Error 8412 &' imbalance$ ret(rne) item )etails *Data +lo, to stock +ile *Data store

)oes not a..ear on .arent )iaram$ Error 8412 &' imbalance$ o/er)(eitem *Data +lo, +rom stock +ile *Data store )oes not a..ear on .arent )iaram$ E's DETECTED3 o 5arnins i/en$ ---- En) o+ re.ort ----

%s can be seen, both errors have been identi!ied. $he way to correct these & errors is di!!erent •

We can add a new "ret-rned item details# data !low on the parent level 1 DFD to correct the !irst error 



We wish to replace the data !low "overd-eitem# with one labelled "overd-e items# !or the second error 

% problem occ-rs i! yo- attempt to change the name o! a data !low to the name o! some other data !low. 2diting the "overd-eitem# data!low and simply changing its name to "overd-e items# res-lts in an error

$o get aro-nd this problem, we need to delete the incorrectly spelt data !low "overd-eitem#, and to create a new data !low "overd-e items# on this diagram. $he corrected DFDs are as !ollows. $he level 1 DFD

$he level & DFD !or process "& loan o! video#

I! we now r-n the consistency checer again, we get a report showing that no errors have been identi!ied Project: C:\TEMP\DFD02\ Title : DFDs Date: 14-Feb-00 Time: 18:67 Checkin P2!"E#2$D%T

o Errors )etecte)3 o 5arnins i/en$ ---- En) o+ re.ort ----

o- sho-ld always r-n the consistency checer !or every diagram when yo- believe the diagram is completed, and !or all parent and child diagrams whenever changes are made to diagrams. Review Questions and Discussion +o&ics &eview uestion *

Why -se models> ist the reasons why systems analysts -se models. What are some o! the speci!ic bene!its o! Data Flow 4odels> % disc-ssion on this review A-estion can be !o-nd at the end o! this chapter . &eview uestion +

Describe each o! the main elements o! Data Flow Diagrams. % disc-ssion on this review A-estion can be !o-nd at the end o! this chapter . &eview uestion ,

Describe & o! the points at which Data Flow Diagrams are -sed d-ring systems analysis % disc-ssion on this review A-estion can be !o-nd at the end o! this chapter . Discussion 'opic 

$he details o! any level & or lower DFD co-ld be displayed in a level 1 DFD, so really there is no reason not to model the entire system in a single level 1 DFD and avoid all the problems o! balancing and hierarchical process n-mbering and so on. :-ggested contrib-tion !or this disc-ssion can be !o-nd at the end o! this chapter . Discussion 'opic 2

$here is no !acility in the Data Flow 4odelling techniA-e to model the order in which  processes occ-r and data !lows. When creating an in!ormation system s-ch time3based aspects o! a system are -st as important as the processes and data themselves. Why do yo- thin that s-ch a !eat-re not been created as part o! Data Flow Diagrams, and how can system designers get aro-nd this omission> :-ggested contrib-tion !or this disc-ssion can be !o-nd at the end o! this chapter .

"nswers and Discussions Discussion o) Exercise 1

*ecomposition  which divides complex in!ormation into manageable ch-ns -sing a hierarchical tree str-ct-re. %n overview o! the problem is presented at the top level o ! the str-ct-re, while lower levels provide increasing depth o! detail !or narrower areas o! the problem (bstraction  enables analysts to concentrate on only one aspect o! the system at a time. Di!!erent models are -sed to model di!!erent perspective o! the system. Data Flow Diagrams concentrate on in!ormation !lows and the activities which process this in!ormation. Discussion o) Exercise 2

Current -ystem !hysical model   the physical processes and data !lows and data stores o! the c-rrent system may be modelled with DFDs (e.g. !orms, pieces o! paper,  physical !iles and !iling systems etc.) Current -ystem Logical model  the logical processes and data !lows and data stores o! the c-rrent system may be modelled with DFDs (e.g. logical actions, logical collections o! data, logical pacages o! in!ormation !lowing etc.) /equired -ystem Logical model   the logical processes and data !lows and data stores o! the reA-ired system may be modelled with DFDs as part o! the speci!ication o! the reA-ired system /equired -ystem !hysical model   the physical processes and data !lows and data stores o! the reA-ired system may be modelled with DFDs as part o! the design !or the reA-ired system Discussion o) Exercise 3

$here are & external entities shown in the above diagram (as ovals) •

C-stomer  a c-stomer who can borrow videos



:-pplier  the local s-pplier 

Discussion o) Exercise 4

$here are ; data !lows shown in the above diagram (as named arrows) •

%vailable titles  !rom :-pplier to ?ideo36ental $D



rder  !rom ?ideo36ental $D to :-pplier 



?ideos  !rom :-pplier to ?ideo36ental $D



:-pplier  the local s-pplier 

Discussion o) Exercise 

$here is -st one process in the above diagram (a rectangle with three parts) 3 ?ideo3 6ental $D Discussion o) Exercise 

$here are no data stores in the above diagram (rectangles with two parts) Discussion o) Exercise 5

$he top le!t part o! a process rectangle is the process n-mber. For context diagrams, i! any n-mber at all is -sed, it is -s-ally Hero. $he Hero indicates that this is the whole system, whereas in lower level DFDs n-mbers lie 1 and ; indicate s-b3processes o! the whole system. $his will become more clear when yo- have progressed to -nderstanding and creating hierarchical, leveled diagrams. Discussion o) Exercise 6

% Context diagram is the !irst DFD to be created !or a system. It represents a model o!  the system as a whole (i.e. as a single process) and this systems interactions with external entities that are o-tside the bo-ndaries o! the system, b-t which provide inp-ts to, and receive the o-tp-ts o! the system being modeled. Context diagrams have the !ollowing !eat-res •

only one process, representing the whole system



they show no data stores



they show all external entities with which the system exchanges data !lows.

Discussion o) Exercise 7

F-nctional decomposition is the breaing down o! higher level processes into their component s-b3processes, data !lows and data stores as lower level DFDs. $he condition to decide to decompose a process is any time where there is some detailed aspect o! the system that is not modeled by the process description alone 

i.e. when a lower level DFD provides something more to the systems analyst, s-ch as s-b processes, additional data stores, and data !lows that are -sed only !or the process and which have not been modeled at the higher level DFD. Discussion o) Exercise 18

Identi!y data !lows by listing the maor doc-ments and in!ormation !lows associated with the system. o- may !ind the -se o! the !ollowing ind o! table is -se!-l Data fow

Sender

Receiver

From the case st-dy we can -nderline all potential data !lows I+$ %+D 7$ F $2 ::$24. %t this point loo !or any possible data !lows, we can change o-r minds at any time in the process o! creating a context diagram. We are not worried abo-t data !lows that seem to be within the system at present, so the sender and receiver sho-ld always be either an external entity, or the system itsel!. ?ideo36ental $D is a small video rental store. $he store lends videos to c-stomers !or a !ee, and p-rchases its videos !rom a local s-pplier. % c-stomer wishing to borrow a video provides the empty box o! the video they desire, their membership card, and payment  payment is always with the credit card -sed to open the c-stomer acco-nt. $he c-stomer then ret-rns the video to the store a!ter watching it. I! a loaned video is overd-e by a day the c-stomer#s credit card is charged, and a reminder letter is sent to them. 2ach day a!ter that a !-rther chard is made, and each wee a reminder letter is sent. $his contin-es -ntil either the c-stomer ret-rns the video, or the charges are eA-al to the cost o! replacing the video.  +ew c-stomers !ill o-t a !orm with their personal details and credit card details, and the co-nter sta!! give the new c-stomer a membership card. 2ach new c-stomer#s !orm is added to the c-stomer !ile. $he local video s-pplier sends a list o! available titles to ?ideo36ental $D, who decide whether to send them an order and payment. I! an order is sent then the

s-pplier sends the reA-ested videos to the store. For each new video a new stoc !orm is completed and placed in the stoc !ile. Data fow

Sender

Receiver

video

s!stem

customer

customer detail

customer

s!stem

mem%ership card

customer

s!stem

mem%ership card

s!stem

customer

empt! video %ox

customer

s!stem

pa!ment

customer

s!stem

return o$ video

customer

s!stem

credit card charge

s!stem

customer (or credit card .rm)

overdue reminder letter

s!stem

customer

availa%le titles

supplier

s!stem

order

s!stem

supplier

pa!ment

s!stem

supplier

re/uested videos

supplier

s!stem

stock $orm

s!stem

s!stem

et -s consider each data !low in t-rn •

video by customer when "oining the store   this is a strong candidate data !low, tho-gh we might name it Qvideo loanQ or Qdetails o! loaned videoQ



customer details by customer when "oining the store  this is a strong candidate data !low



membership card issued to customer   this is a strong candidate data !low



membership card presented by customer when renting a video   this is a strong candidate data !low



empty video box presented by customer when renting a video   this is a strong candidate data !low, b-t perhaps sho-ld be call QreA-est !or videoQ or something similar 



payment by customer when renting a video   this is a strong candidate data !low



return of video by customer   this is a strong candidate data !low, altho-gh the data might be Qret-rned videoQ or Qret-rned video detailsQ



credit card charge by system   this is a strong candidate data !low, b-t in !act we have already identi!ied a payment by the c-stomer (when renting a video) and we co-ld -st consider this to be anther example o! c-stomer  payment (!or simplicity, altho-gh alternatively we co-ld consider this a separate data !low, the decision co-ld be in!l-enced on the sophistication o! the systems processing o! payments, and might be delayed -ntil more detailed DFDs are prod-ced later in the analysis proced-re)



overdue reminder letter from system  this is a strong candidate data !low



payment by system for order   this is a strong candidate data !low



list of available titles from supplier   this is a strong candidate data !low



the requested videos from supplier  this is a strong candidate data !low, altho-gh might be called something lie Qvideos p-rchasedQ



stock form  this last data !low is within the system, so this will not be -sed in the context diagram b-t will probably appear in a more detailed DFD later 

o- might have noticed •

Identify external entities  by identi!ying so-rces and recipients o! the data !lows, which lie o-tside o! the system -nder investigation.

$his step is easy i! we have created a table lie the above, since we can -st create a list o! all the di!!erent entities

o c-stomer  o s-pplier (a candidate might be the credit card company, b-t we shall choose to consider the c-stomer to be charged in this case !or simplicity) Draw and label a process box representing the entire system.



*raw and label the external entities  aro-nd the o-tside o! the process box.

We -st need to add external entity symbols !or Qc-stomerQ and Qs-pplierQ.



(dd the data flows between the external entities and the system box

we now need to add those data !lows earlier Data fow

Sender

Receiver

video loan

s!stem

customer

customer details

customer

s!stem

mem%ership card

customer

s!stem

mem%ership card

s!stem

customer

re/uest $or video

customer

s!stem

pa!ment

customer

s!stem

return o$ video

customer

s!stem

overdue reminder

s!stem

customer

availa%le titles

supplier

s!stem

Data fow

Sender

Receiver

order

s!stem

supplier

pa!ment

s!stem

supplier

re/uested video

supplier

s!stem

We can do a A-ic chec when we have created the diagram by co-nting the n-mber o! !lows o-t o!, and into each entity. From col-mn QsenderQ we can see there sho-ld be

o = data !lows o-t o! the system o = data !lows o-t o! c-stomer  o & data !lows o-t o! s-pplier  From col-mn QreceiverQ we can see there sho-ld be

o K data !lows into the system. o ; data !lows into c-stomer  o & data !lows o-t o! s-pplier  -r context diagram loos as !ollows

Discussion o) Exercise 11

$here are ; data !lows shown in the above diagram (as named arrows) •

Create new c-stomer 



oan o! video



:toc control

Discussion o) Exercise 12

$here are & data stores •

:toc !ile



:toc !ile

Discussion o) Exercise 13

First we start with the context diagram, since all external entities and data !lows on this diagram m-st appear on o-r evel 1 DFD

We can now create an QemptyQ evel 1 DFD with these entities and data !lows



Identify processes. 2ach data !low into the system m-st be received by a  process. 2ach process m-st have at least one o-tp-t data !low. 2ach o-tp-t data !low o! the system m-st have been sent by a process.

 +ow we need to identi!y the recipient and sending processes o! the system !or each data !low. We need to replace with a system process each occ-rrence o! QsystemQ as the sender or recipient in the table o! data !lows created previo-sly. 8ossible processes have been inserted in the !ollowing table Data Flow

Sender

Customer

video loan

s!stem - loan o$ video

customer

customer details

customer

s!stem - create new customer

mem%ership card

customer

s!stem - loan o$ video

mem%ership card

s!stem - create new customer

customer

re/uest $or video

customer

s!stem - loan o$ video

pa!ment

customer

s!stem - loan o$ video

return o$ video

customer

s!stem - loan o$ video

Data Flow

Sender

Customer

overdue reminder

s!stem - loan o$ video

customer

availa%le titles

supplier

s!stem - stock control

order

s!stem - stock control

supplier

pa!ment

s!stem - stock control

supplier

re/uested videos

supplier

s!stem - stock control



*raw the data flows between the external entities and processes . %!ter creating process boxes and drawing the data !lows the diagram loos as !ollows



Identify data stores  by establishing where doc-ments 5 data needs to be held within the system. %dd the data stores to the diagram, labeling them with their local name or description.

$here seem to be & main data stores reA-ired a store o! c-stomer details Qc-stomer !ileQ and a store o! which videos are in stoc Qstoc !ileQ. %!ter adding these to the diagram loos as !ollows



(dd data flows flowing between processes and data stores  within the system. 2ach data store m-st have at least one inp-t data !low and one o-tp-t data !low.

We can create a table to indicate which processes send and receive data !rom each data store

Data store

Data fow IN FROM

data fow OUT TO

customer .le

customer details F&0 create new customer

customer details '0 loan o$ video

stock .le

new video details F&0 stock control

overdue items '0 loan o$ video

%!ter adding these data !lows the diagram loos as !ollows



check diagram +o record seems to be made o! when a video is lent to a c-stomer  there o-ght to be a data !low !rom Qloan o! videoQ to Qstoc !ileQ called something lie Qitem on loanQ. iewise when an item is ret-rned the details sho-ld be recorded in a data !low called something lie Qitem ret-rnedQ.

%part !rom these extra two data !lows the diagram appears to be correct. :o o-r evel 1 DFD !or the ?ideo 6ental case st-dy is now

Discussion o) Exercise 14

4ae the process box on the evel 1 diagram the system bo-ndary on the evel & diagram that decomposes it. $his gives -s the !ollowing, "empty# evel & DFD

Identi!y the processes inside the evel & system bo-ndary and draw these processes and their data !lows. For each data !low into and o-t o! the process !or which this evel & diagram is being created we need to identi!y an appropriate s-b3process to receive and send the data !lows. $he !ollowing table lists each data !low and s-ggests a s-itable s-b3process to receive5send the data !low

Data fow

video loan

Sender

loan o$ video - process loan

Receiver

customer

mem%ership card customer

loan o$ video - validate customer

re/uest $or video customer

loan o$ video - validate customer

pa!ment

customer

loan o$ video - issue video

return o$ video

customer

loan o$ video - restock video

customer details customer-.le

loan o$ video - validate customer

overdue items

stock-.le

loan o$ video - process late return

item returned

loan o$ video - restock video

stock-.le

item on loan

loan o$ video - issue video

stock-.le

overdue reminder

loan o$ video - process late return

customer

%dding these processes and data !lows to the diagram we get the !ollowing

Identi!y any data stores that exist entirely within the evel & bo-ndary, and draw these data stores For this example there don#t appear to be any "local# data stores Identi!y data !lows between the processes and data stores that are entirely within the evel & system bo-ndary :ince there are no local data stores, there are no data !lows  between processes and data stores to be added. Chec the diagram 7pon checing the diagram, we !ind that the process "validate c-stomer# has no o-tp-t data !lows. ooing more closely we see that a p la-sible data !low o-t o! "validate c-stomer# wo-ld be something lie "loan permission#. 7pon adding this new data !low the diagram loos as !ollows

Discussion o) Review Question 1 •

Identify data flows by listing the maor doc-ments and in!ormation !lows associated with the system.

o- may !ind the -se o! the !ollowing ind o! table is -se!-l Data fow

Sender

Receiver

From the case st-dy we can -nderline all potential data !lows I+$ and 7$ F $2 ::$24. %t this point loo !or any possible data !lows, we can change o-r minds at any time in the process o! creating a context diagram. We are not worried abo-t data !lows that seem to be within the system at present, so the sender and receiver sho-ld always be either an external entity, or the system itsel!. Clients wishing to p-t their property on the maret visit the estate agent, who will tae details o! their ho-se, !lat or b-ngalow and enter them on a card which is !iled according to the area, price range and type o! property . 1ote

8otential b-yers complete a similar type o! card which is !iled by b-yer name in an %9 binder. Weely, the estate agent matches the potential b-yer# reA-irements with the available properties and sends them the details o! selected properties. When a sale is completed, the b-yer con!irms that the contracts have been exchanged, client details are removed !rom the property !ile, and an invoice is sent to the client. $he client receives the top copy o! a three part set, with the other two copies being !iled. n receipt o! the payment the invoice copies are stamped and archived. Invoices are checed on a monthly basis and !or those acco-nts not settled within two months a reminder (the third copy o! the invoice) is sent to the client.

We can b-ild a table o! these data !lows, and the senders and receivers o! these !lows. Data fow

Sender

Receiver

house details

client

s!stem

%u!er details

%u!er

s!stem

selected properties

s!stem

%u!er

contract

%u!er

client

invoice

s!stem

client

pa!ment

client

s!stem

reminder

s!stem

client

6eected candidates !or data !lows incl-de

o the internal copies o! the invoice 3 these data !lows do not go o-tside the system bo-ndary so will not be part o! this context diagram (b-t may !eat-re on a more detailed DFD later) o the client details card is !iled I+ the system, so this internal data !low will not !eat-re on the context diagram It is worth noting that the exchange o! contracts between client and b-yer is not a data !low into or o-t o! the system, b-t this data !low between external entities is relevant so o-ght to be notated on the context diagram. •

Identify external entities  by identi!ying so-rces and recipients o! the data !lows, which lie o-tside o! the system -nder investigation.

$his step is easy i! we have created a table lie the above, since we can -st create a list o! all the di!!erent entities client, b-yer. •

*raw and label a process box  representing the entire system



*raw and label the external entities  aro-nd the o-tside o! the process box. We -st need to add external entity symbols !or QclientQ and Qb-yerQ



(dd the data flows between the external entities and the system box. We now need to add those data !lows earlier. -r context diagram loos as !ollows

We can chec the diagram A-icly looing at the table Data fow

Sender

Receiver

house details

client

s!stem

%u!er details

%u!er

s!stem

selected properties

s!stem

%u!er

contract

%u!er

client

invoice

s!stem

client

pa!ment

client

s!stem

reminder

s!stem

client

Client sho-ld send & data !lows, and receive ;. G-yer sho-ld send & data !lows and receive 1. :ystem sho-ld send ; data !lows and receive ;. Discussion o) Review Question 2

We sho-ld start with the context diagram, and create an QemptyQ evel 1 DFD with all the same external entities and data !lows



Identify processes 3 2ach data !low into and o-t o! the system m-st be received by 5send by a process. +ow yo- need to identi!y the recipient and sending processes o! the system !or each data !low. We need to replace with a system process each occ-rrence o! QsystemQ as the sender or recipient in the table o! data !lows created previo-sly. 8ossible processes have been inserted in the !ollowing table Data fow

Sender

Receiver

house detail

client

s!stem - record new client

%u!er details

%u!er

s!stem - record new %u!er

selected properties

s!stem - match properties

%u!er

contract

%u!er

client

invoice

s!stem - invoice client

client

pa!ment

client

s!stem - archive sale

reminder

s!stem - invoice client

client



*raw the data flows between the external entities and processes%  We can now add these processes to the diagram, and connect the appropriate data !lows



Identify data stores  by establishing where doc-ments 5 data needs to be held within the system. %dd the data stores to the diagram, labelling them with their local name or description. $here are two QcardQ stores (clients and b-yers) so these sho-ld be data stores Qproperty !ileQ and Qb-yer detailsQ. % !ile need to be ept !or the invoice copies QinvoicesQ. We can add these data stores to the diagram



(dd data flows  !lowing between processes and data stores within the system. 2ach data store m-st have at least one inp-t data !low and one o-tp-t data !low

(otherwise data may be stored, and never -sed, or a store o! data m-st have come !rom nowhere). 2ns-re every data store has inp-t and o-tp-t data !lows to system processes. 4ost processes are normally associated with at least one data store. We can create a table to indicate which processes send and receive data !rom each data store Data store

data fow IN FROM

data fow OUT TO

propert! .le

propert! details F&0 record new client

properties '0 match properties

%u!er details

%u!er details F&0 record new %u!er

desired propert! '0 match properties

invoices

invoice F&0 invoice client

reminder '0 invoice client

$hese data !lows can be added to the diagram



Check diagram. We now can chec the diagram !or correctness, and !ind a  process that has no o-tp-t data !low Qarchive saleQ. %n appropriate data !low, into data store QinvoicesQ wo-ld be something lie Qrecord o! paymentQ. $he consistent and balanced evel 1 DFD now loos as !ollows

owever, there is another problem with the diagram  what ca-ses the process Qinvoice clientQ to send an invoice or reminder to the client> $he only inp-t to the process Qinvoice clientQ is a QreminderQ !rom the QinvoicesQ data store. $he answer is that there are two things that trigger this process to send a data !low to the client

o nowledge that sale has been completed o nowledge that a payment on an iss-ed invoice is overd-e

$he second is a time3based event, and not modelled explicitly in Data Flow Diagrams. owever, the !irst indicates there sho-ld be a data !low !rom an external entity to the system indicating that contracts have been exchanged. I! we loo care!-lly at the case st-dy again, we !ind that 1ote

When a sale is completed, the b-yer con!irms that the contracts have been exchanged, client details are removed !rom the property !ile, and an invoice is sent to the client. $his m-st mean that the b-yer in!orms the system that the sale is complete, so we m-st create a new data !low !rom Qb-yerQ to Qinvoice clientQ called something lie Qcon!irmation o! saleQ. (+$2 :ince we are adding a new data !low  between the system and the external entities, we shall have to -pdate the parent diagram  i! we !orget we will be reminded by any C%:2 tool consistency checer). We also notice there sho-ld be a data !low o! Qclient to deleteQ !rom process Qinvoice clientQ to the data store Qproperty !ileQ. $he o-r evel 1 DFD now loos as !ollows

Discussion o) Review Question 3 •

Make the process box on the Level 1 diagram the system boundary on the Level 2 diagram that decomposes it%

We sho-ld start with the evel 1 DFD, and create an QemptyQ evel & DFD with all the same external entities and data !lows as the "invoice client# process. $his gives -s the !ollowing, "empty# evel & DFD



Identify the processes inside the evel & system bo-ndary and draw these  processes and their data !lows.

For each data !low into and o-t o! the process !or which this evel & diagram is  being created we need to identi!y an appropriate s-b3process to receive and send the data !lows. $he !ollowing table lists each data !low and s-ggests a s-itable s-b3process to receive5send the data !low Data fow

sender

receiver

invoice

invoice client - raise invoice

client

pa!ment reminder

invoice client - process late pa!ment

client

reminder

invoice client - process late pa!ment

invoice client - process late pa!ment

invoice

invoice client - raise invoice

invoices

con.rmation o$ sale

%u!er

invoice client - raise invoice

client to delete

invoice client - 

propert! .le

$he last row in the table above is interesting  there doesn#t appear to be a s-b3process inside the "invoice client# process that creates the data !low "client to delete#. ooing care!-lly at the evel 1 DFD we can see that the "archive sale# process is probably most appropriate to be sending the property !ile the details o! which client to delete, since it is this process that receives the  payment !rom the client. $here!ore we need to delete this "client to delete# data !low !rom the evel & DFD, and change the evel 1 DFD to have this data !low !rom "achieve sale# to the "property !ile#. %dding these processes and data !lows to the diagram we get the !ollowing



Identify any data stores that exist entirely within the evel & bo-ndary, and draw these data stores. For this example there don#t appear to be any "local# data stores

View more...

Comments

Copyright © 2017 EDOC Inc.