Tutorial 6 DFDs vs. Use Case Diagrams (Textbook Chapter 7 & Appendix)

Learning Objectives Practice more DFDs Practice more Use Case Diagrams Understand commonalities and differences between the two types of diagrams

Part 1 Ch. 7 Ex. 12 and Ch. 7 App, Ex. 1 Consider the following narrative: Maximum Software is a developer and supplier of software products to individuals and businesses. As part of their operations, Maximum provides a help desk line for software purchased form Maximum. An operator enquires about the nature of incoming calls. Calls that do not require help desk functions are directed to other company units. Help desk consultants are organised by product. The operator directs the call to a consultant skilled on the software that the caller needs help with. Some calls need to be put on a queue. Once a consultant answers the call, the consultant determines if this is the first call from this customer. If so, the consultant creates a new call report to keep track of all information about the problem. If it is not the first call about a problem, the consultant asks the customer about the call report number and retrieves the open call report to determine the status of the enquiry.

Ch. 7 Ex. 14 and Ch. 7 App, Ex. 1 (cont.) If the caller does not know the call report number, the consultant collects other identifying information such as caller’s name, the software involved etc in order to conduct a search for the appropriate call report. If a resolution of the customer’s problem has been found, the consultant informs the client as to what the resolution is, indicates on the report that the customer has been notified, and closes out the report. If resolution has not been discovered, the consultant finds out if the consultant handling this problem is on duty and if so, the call is transferred to that consultant, who records any new information from the client. For new and continuing problems, the consultant tries to find the solution by using the relevant software and looking up information in reference manuals. If the consultant knows how to solve the problem, he / she tells the customer how to deal with the problem and closes the report. Else the consultant files the report for continued research and tells the customer that someone at Maximum software will get back to him / her and if the customer discovers new information he / she should call quoting the report number.

Ch. 7 Ex. 12 and Ch. 7 App, Ex. 1 (cont.) Decisions to make What is to be represented, i.e. what level of detail to show? Keep Level-0 DFD uncluttered, 7-9 processes (max). DFD can be subsequently further decomposed. Unless further information becomes available, assumptions may be necessary to further decompose.

Ch. 7 Ex. 12 and Ch. 7 App, Ex. 1 (cont.) Decisions to make (cont.) What is part of the system and what is an external entity / agent? One option is to consider the processes performed by the consultants and operators as sub-systems within the system rather than as external entities (sources/sinks). This adds detail; however, it allows bottlenecks in these processes to be corrected. So, it depends on the scope of the problem (and what the client wants to pay for)

Help Desk System Context Data Flow Diagram Ch. 7 Ex. 12 and Ch. 7 App, Ex. 1 (cont.) Help Desk System Context Data Flow Diagram

Ch. 7 Ex. 12 and Ch. 7 App, Ex. 1 (cont.) Decisions to make (cont.) Decision logic is not shown on the DFDs. How do we cope with that? a) show the data flows in / out of processes that correspond to all possible decisions b) simulate some rudimentary decision logic on the DFDs

Hospital Pharmacy Partial Level-0 Diagram Option a) Information necessary to make the decision If the Order is not filled, then the doctor is contacted. The doctor responds …etc etc Hospital Pharmacy Partial Level-0 Diagram

Option b) E.g.: “…the consultant determines if this is the first call from this customer. If so, the consultant creates a new call report […]. If it is not the first call about a problem, the consultant […] retrieves the open call report to determine the status of the enquiry. 5.0 3.0 Determine if first call Previous Call Information Determine problem status First Call Information Call Report 4.0 Create Call Report Call Report Information D1 Call Report File

Help Desk System Level-0 Data Flow Diagram Call New Problem Data 1 Enquiry on Nature of Call Inquiry on Nature of Call Client Call Report # or Other Data Receive 9 Call Nature of Call Final Call Resolution Close Call Report D1 Call Queue Call Closed Call Problem Information Resolution New Help Desk Information Call Information Closed Call on Problem 2 5 Indication Determine 8 3 Previous Determine Direction H elp Desk Research Call Problem of Call Call Information Determine Problem Information if First Status Call Call Non - Help Report Desk Call Information First Call Open Call Problem Information Information Data D2 Call Report File 4 New Other Create Call Report Problem Unit D1 Call Queue Call Information Data Report 6 7 Transfer Open Call Information Record Problem Call New Information Information Interim Problem Status Help Desk System Level-0 Data Flow Diagram

Help Desk System Use Case Diagram Place Call Direct the Call Operator Answer Call Customer <<includes>> <<includes>> Knowledge base lookup Retrieve problem report Consultant Refer to original consultant Update call report <<extends>> Close call report Help Desk System Use Case Diagram

Can this system be improved? A customer may have to explain their problem and/or question over and over to multiple people: an operator and possibly several consultants. Has this happened to you? Why not let the initial operator have access to the customer problem database so that the caller is handed off to a consultant and the customer’s already opened problem file goes along with him. Does this happen in the GU system ?

Can this system be improved? (cont.) The operator could have sufficient information and the option to direct the call to the proper consultant. Clients could call the assigned consultant directly on follow-up calls to an initial call for help. Why should clients not be called back by consultants with updates on the problem or the resolution, rather than the client having to call back to check?

Can this system be improved? (cont.) General areas of improvement for DFDs are: processes that simply collect and pass on information rather than transforming data collecting the same information into several processes placing untransformed data into data stores thus causing unknown delays in processing this data cycles or loops that have no apparent termination.

Same Observations as in previous tutorial: There is substantially less detail on the use case diagram than in the narrative The missing detail will be completed when writing the use cases at intermediate and detailed levels. Decision logic is not shown on the Use Case diagrams. It is described in the written Use Cases and/or Activity Diagrams and/or Sequence Diagrams (the latter can also show timing)

Part 2 Case Study: Pine Valley Furniture (PVF) Review the Case Study DFD and the ‘corresponding’ Use Case Diagram described in Tutorial Wk 5

Level-0 data flow diagram for the PVF WebStore

Case Study: PVF (cont.): Model the functionality of Pine Valley Furniture Webstore Application with a use case diagram. Six high-level functions identified to be included in the use case diagram. The functions represent the “work” or “action” parts of the Website.

Case Study: PVF (cont.): Check Order Fill Order Place Order Login Maintain Account Browse Catalog Shipping Clerk Customer WebStore use case diagram

Place Order Brief Description Case Study: PVF (cont.): The functionality should now be further detailed using written use cases as shown in the lecture. E.g. for the Place Order use case: Place Order Brief Description Customer connects to PVF WebStore and links to Order page. System checks customer information and creates a new order. Customer searches catalog, adds items / makes changes to the order, checks out assisted by the system. Customer requests payment screen, makes payment assisted by system. System sends e-mail confirmation and finalizes order.

Case Study: PVF (cont.): Possible Intermediate level description: PVF Source: (Satzinger et al., 2008)

Case Study: PVF (cont.): Possible fully developed description – adds triggering event, actors, related use cases, stakeholders and pre- and post-conditions: PVF Source: (Satzinger et al., 2008)

Case Study: PVF (cont.): Possible fully developed description (cont.): PVF Source: (Satzinger et al., 2008)

Summary In this tutorial you learned how to: Practice DFDs Practice Use case Diagrams Understand commonalities and differences between the two types of diagrams