[Year 12 SofDev] DFDs

Kevork KROZIAN kkrozian at ringwoodsc.vic.edu.au
Tue Feb 26 09:27:14 EST 2013


Hi Mark,

I agree. This is for our discussion only. I thought the analogy was useful for the restaurant example we have all grown to love :)

Take Care

Kevork Krozian
IT Pathways Manager
Ringwood Trade Training Facility
Tel: 0419 356 034

From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Mark
Sent: Tuesday, 26 February 2013 8:40 AM
To: Year 12 Software Development Teachers' Mailing List
Subject: Re: [Year 12 SofDev] DFDs

Thanks, Kevork. One learns something new every day!
I wouldn't introduce this complexity to our kids' DFDs and UCDs, however.

Cheers
Mark

On 25 February 2013 13:24, Kevork KROZIAN <kkrozian at ringwoodsc.vic.edu.au<mailto:kkrozian at ringwoodsc.vic.edu.au>> wrote:
Hi James,

I just opened Use Cases Requirements in Context by Daryl Kulak and Eamonn Guiney and p 39 states:
" It is often hard to decide which actors to show on a use case diagram. For example,, when a supplier provides an invoice to a company clerk and the clerk enters the invoice into the system, should the supplier be included in the diagram ? If the supplier is shown it is called a secondary actor. Our rule is that the supplier should be shown in the diagram if the supplier's behaviour impacts the system in any way. For example, if a supplier sends a shipment late and that changes how the system reacts, then the supplier should be in the diagram."

In a restaurant a waiter can't interact with the ordering system until the customer places the order. A delay does not change the response from the system.  The waiter would appear in the UCD but not the DFD which would show the customer - the supplier or source of the data or the order. I wouldn't place the waiter in the DFD as they are not the source of the data.

Perhaps you can offer details of your textbook if anyone wants to get a hold of it .

Just my take on the discussion

Kind Regards

Kevork Krozian
IT Pathways Manager
Ringwood Trade Training Facility
Tel: 0419 356 034

From: sofdev-bounces at edulists.com.au<mailto:sofdev-bounces at edulists.com.au> [mailto:sofdev-bounces at edulists.com.au<mailto:sofdev-bounces at edulists.com.au>] On Behalf Of Vella, James
Sent: Monday, 25 February 2013 10:56 AM
To: sofdev at edulists.com.au<mailto:sofdev at edulists.com.au>
Subject: Re: [Year 12 SofDev] DFDs


Strictly speaking as someone who did DFDs at uni...



As Mark has said, we sometimes think in a human sense however DFDs don't allow us to see the interactions between two EEs.



As Selina has said, the waiter is just the input method - so we can leave it out. I think our students sometimes find it hard at this stage where they have to decide what should and shouldn't be included in our DFDs.



In terms of the DFD, you could argue either way for one or the other....but NOT BOTH! :)



That being said, in the UCD you can list both as actors because they both have roles in the system.



I have a whole text book on this stuff from my 2nd year at LaTrobe which I'm using with my kids at the moment...DFDs, UCDs, UML the whole kit and caboodle!



Regards



Mr James Vella

MacKillop College



 <snip>

Mark Kelly
mark at vceit.com<mailto:mark at vceit.com>

________________________________

Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of Ringwood Secondary College.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20130225/eacd5217/attachment.html 


More information about the sofdev mailing list