Data Flow Diagram - DFD Levels, Symbols, Case Study, Tutorial, Example,

  Difference between Uses and Extends Probably the best way to think about these diagram elements is as follows:- "X uses Y" indicates that the task "X" has a subtask "Y"; that is, in the process of completing task "X", task "Y" will be completed at least once. "X extends Y" indicates that "X" is a task for the same type as "Y", but "X" is a special, more specific case of doing "Y". That is, doing X is a lot like doing Y, but X has a few extra processes to it that go above and beyond the things that must be done in order to complete Y.

Uses Arrow: The uses arrow (or uses edge as it would be called in traditional graph theory) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in Use Case Diagrams of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it can be read X uses Y means that "X has a Y" as part of it's behaviour.   Extends Arrow: The extends arrow (or extends...

 How to Find Actors for Use Case Diagram? When working from an Action/Response table, identifying the actors is easy: entities whose behaviour appears in the "Actor's Actions" column are the actors, and entities whose behaviour appears in the "System's Response" column are components in the system. If you are working from an informal narrative, a sequence diagram, or a scenario description, the actors are typically those entities whose behaviour cannot control or change (i.e., agents that are not part of the system that you are building or describing.) The most obvious candidates for actors are the humans in the system. Except in rare cases when the system you are describing is actually a human process, such as a specific method of dealing with customers that employees should follow, the humans that you must interact with will all be actors. If your system interacts with other systems (databases, servers maintained by other people, legacy sy...

Introduction to Use Case Diagram UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, Use Case Diagrams can be used to show all of its available functionality. It is important to note, though, that Use Case Diagrams are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarise yourself with the look of them. Use Case Diagrams have only 4 major elements: ·          the actors that the system you are describing interacts with ·          the system itself ·          the use case...