Each external entity must be involved with at least one data flow.Each data store must be involved with at least one data flow.All processes should modify the incoming data, producing new forms of outgoing data.All processes must have at least one data flow in and one data flow out.There are several common modeling rules that I follow when creating DFDs: Physical data stores are typically self explanatory. Electronic data stores can be modeled via data models, particularly if they represent a relational database. DFDs can be used to model processes that are purely physical, purely electronic, or more commonly a mix of both. The Collect Fees process is interesting because it interacts with an electronic data store, Financial DB, as well as a physical one, Cash Drawer. AM recommends that you follow the practice Update Models Only When it Hurts and in this case this issue doesn’t hurt enough to invest the two or three minutes it would take to fix the diagram. Yes, I could use a drawing program to update the arrowhead but its more important to make the point that agile models don’t need to be perfect, they just need to be good enough. Unfortunately I’ve erased this diagram from my whiteboard so it isn’t easy to address this minor problem. Now that I look closer at the diagram the arrow between the Input Student Information process and the Student DB data store should be two-way because this process searches the database for existing student records. Also notice that the names of the data change to reflect how it’s been processed. Notice how each data flow on the diagram has been labeled. The second process encapsulates the logic for creating a student record, including the act of checking to see it the person is eligible to enroll as well as if they’re already in the database. I then continued to follow the logic of the use case, concentrating on how the data is processed by each step. You can see how the improperly filled out forms are returned to the applicant if required. This information is optional although very useful in my experience. I also indicated who/what does the work in the bottom section of the process bubble, in this case the registrar. I wouldn’t bother to expand this process to more detailed DFD as it is fairly clear what is happening in it and therefore the new diagram wouldn’t add any value. Subprocesses of 1.1 would be numbered 1.1.1, 1.1.2, and so on. Were I to do this for this process I would number the subprocesses 1.1, 1.2, and so on. A common technique with DFDs is to create detailed diagrams for each process to depict more granular levels of processing. I assigned this process identifier 1.0, indicating that it’s the first process one the top level diagram. I introduced the Inspect Forms process to encapsulate the initial validation steps. In this case I started with the applicant, the external entity in the top left corner, and simply followed the flow of data throughout the system. On actual projects it’s far more common just to stand at a whiteboard with one or more stakeholders and simply sketch as we talk through a problem. To create the diagram I simply worked through a usage scenario, in this case the use case logic described in the Enroll in University system use case. Open-ended rectangles representing data stores, including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper.Arrows representing the data flows, which can either be electronic data or physical items.Rounded rectangles representing processes, which take data as input, do something to it, and output it.Squares representing external entities, which are sources or destinations of data.Figure 1 presents an example of a DFD using the Gane and Sarson notation. DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. In the late 1970s data-flow diagrams (DFDs) were introduced and popularized for structured analysis and design (Gane and Sarson 1979).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |