In Visual Studio flagship edition, you can draw a use case diagram to summarize the users of your application or system and the purpose of the application or system. To create a UML use case diagram, on the Architecture menu, click New Diagram. Use case diagrams help you discuss and communicate the following: Several scenarios in which your system or application interacts with people, organizations, or external systems. It helps participants achieve their goals. The scope of the system. Use case diagrams do not show the details of a use case: it summarizes only certain relationships between use cases, actors, and systems. In particular, the use case diagram does not show the sequence of steps that each use case takes to achieve the goal. You can describe these details in other diagrams and documents that can be linked to each use case. For more information, see the detailed description of use cases in this topic. The description you provide for use cases will use some vocabulary related to the areas used by the system, such as "Sales", "menus", "Customers" and so on. It is important to clearly define these words and their relationships, which you can define using UML class diagrams. For more information, see UML Class Diagrams: Guidelines. Use cases only deal with the functional requirements of the system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately. The architecture and internal details must also be explained separately. For more information about how to define user requirements, see Modeling user requirements. The examples used in this topic relate to websites where customers can order meals from local restaurants. "Contributor" (1) is a class of people, organizations, devices, or external software components that interact with your system. For example, "customer", "Restaurant", "Temperature sensor", "credit card licensor" are participants. A "Use Case" (2) represents an action that one or more actors perform to achieve a particular goal. For example, "Order Meal", "Update Menu", "process payment" are use cases. In use case diagrams, use cases are associated with the participants who execute them (3). "System" (4) is any result of your development. The system can be a small software component, where the participants are just other software components, the system can also be a complete application, and the system can be a large distributed application suite deployed on multiple computers and devices. For example, the "meal site", "Room Service", "website version 2" are subsystems. Use case diagrams can show the use cases supported by the system or its subsystems. Topic content Basic steps for drawing a use case diagram Drawing participants and use cases Describe use cases in detail Structured Use cases Using subsystem boundaries Basic steps for drawing a use case diagram Create a new use case diagram 1. On the Architecture menu, click New Diagram. 2. Under Templates, click UML Use case diagram. 3. Name the diagram. 4. In Add to modeling project, select an existing modeling project from your solution, or select Create a new modeling project, and then click OK. Draw a use case diagram 1. Drag the subsystem boundary from the Toolbox onto the diagram, which can represent the entire system or its main components. If you do not want to describe which use cases the system or its components support, you can not draw system boundaries in the use case diagram. As needed, drag the corners of the system to enlarge them. Rename it appropriately. 2. Drag the contributor from the Toolbox onto the diagram (placing it outside of all system boundaries). Participants represent the various types of users, organizations, and external systems that interact with your system. Rename these participants. For example: "Customer", "Restaurant", "Credit card institution". 3. Drag the "use case" from the toolbox to the appropriate system. Use cases represent activities that participants perform with the help of the system. Rename these use cases with names that the participants themselves can understand. Do not use code-related names. For example: "Order Meal", "Pay meal", "Delivery meal". Start with a major transaction (such as "ordering") until a smaller transaction (such as "à la carte") is followed. Put each use case into the system or primary subsystem that supports it (ignoring any appearance or component patterns that are only relevant to the user). Use cases can be drawn outside the system boundary to indicate that the system (possibly in a particular version) does not support the use case. 4. Click Associations on the Toolbox, click the Use case, and then click the participant for the use case. In this way, each participant is linked to its use case. 5. Use the "include", "extend", and "generalize" relationships to structure the use case. To create each of these links, click Tools, source use cases, and targets. See the structured Use cases section below. 6. Describe the use case in detail. See the section describing use cases in detail below. 7. Draw additional diagrams to target different subsystems or different related use case groups. All the diagrams in one modeling project are multiple views of the same model. Drawing participants and use cases The primary purpose of a use case diagram is to show the users interacting with the system and the main goals that these users are implementing with the system. Create a "contributor" to represent a variety of people, organizations, other systems, software, or devices that interact with your system or subsystem. To learn how to draw participants and other elements, see how to: Edit UML models and diagrams. For each set of different goals, identify the participants by their type or role, even if the specific individual or entity may be the same. For example, "Restaurant" and "customer" are different participants, even though restaurant employees may sometimes be customers. Create "Use cases" for each goal that each participant wants to achieve with the system. Names and describes use cases in terms that the participant can understand, rather than using the terminology used in the implementation. Use the association link contributor and use case. Inheritance between participants You can draw a "generalization" link between participants. Dedicated contributors, such as "club customers" in the example, inherit the use cases of generalization participants, such as "customers". The arrows should point to more general participants, such as "customers." When you create a link, you first point to a more dedicated contributor. Dedicated contributors can have their own additional use cases that are not available to other participants. Warning: You should not create a generalization relationship loop that causes participants to generalize themselves. Loops can produce errors. Optional participant icon You can use a custom icon instead of a standard line chart to represent participants. For example, you can change it to an icon similar to a device, restaurant, bank, and so on. Change the appearance of participants 1. Right-click the participant, and then click Properties. The Properties window appears. 2. Set the "Image Path" property to the location of the image file. You can use any of several image formats, including. gif,. jpg, and. bmp. Use files that are contained in solution or project source control to remain available when you move or copy a solution. 3. To copy this appearance to another use case diagram, copy the participant and paste it into a different diagram. The changes to the image apply only to views in a particular diagram. This is not applied to the underlying model element. If you drag a contributor from UML Model Explorer to another diagram, the participant is displayed as a standard line chart. The number of re-counts between participants and use cases The association between a participant and a use case displays a "weight count" at each end. Note: If the count of the two ends of an association in a use case diagram is "1", then the weight is hidden. By default, each count is "1". In the strict interpretation of the model, take the customer order meal as an example, the weight of 1 means that a meal only one customer booking and one meal per customer. You can change these re-counts. For example: To indicate that a use case can be attended by more than one of the same participants, you can set the number of contributors in the association to "1..*". In the illustration, one or more restaurants can participate in the same order. To indicate that each participant can participate in multiple use cases at the same time, you can set the weight of the use case side of the Association to "*". In the illustration, each restaurant can participate in the implementation of multiple bookings at the same time. Set the number of the associated weight 1. Right-click the association, and then click Properties. 2. Expand "First role" or "second role". "Role" represents the element at the end of the association. 3. Set the Multiplicity property, which can be selected from the following table: 1, indicating that only one instance of this role participates in each link. 1..* that indicates that one or more instances of this role participate in each link. 0..1, indicating that participation is optional. *, indicating that 0 or more instances of this role participate in the link. Note: Many teams do not provide the re-count information in the use case diagram, retain the default value of 1, and provide that information in other descriptions of the use case. In this case, all the re-counts in the use case diagram are hidden. Use one contributor or use case in multiple diagrams You can display the same contributor or use case in multiple diagrams. For example: Different use cases involving the same participant can be described in different diagrams. You can use a diagram to display multiple actors and subsystems associated with a use case, and use another diagram to show how to structure the use case into included use cases and extension cases. Show the same participant or use case in different diagrams 1. Create a contributor or use case in a diagram. 2. Create another use case diagram. 3. Drag the participant or use case from Model Explorer onto the new diagram. Note: If you put the new diagram in the associated actors and use cases, the associations between them will automatically appear in the new diagram. Describe use cases in detail The use case represents: Participants use the goals that the system wants to achieve, such as "buy food and beverage"; One or more scenarios, which are a series of steps to achieve a goal, such as {"Order Meal", "payment", "Meal Delivery"}. In addition to successful scenarios, there may be several exceptions or failure scenarios, such as "credit card rejection." The description of a use case can have a different level of detail. In the early stages of design, it is sufficient to simply label the name on the use case diagram. A more detailed description of the scenario can be written later. In Visual Studio flagship, you can describe use cases in a number of ways that can be used separately or together: Link a use case to another or several diagrams in the project. Activity diagrams help explain the more complex processes that contain loops, branches, and parallel threads. The activity diagram can also show the flow of data between parts of the process. Sequence diagrams help explain the complex sequence of interactions between different participants. Sequence diagrams can also be used to display responses to each use case that occur within the system. Link a use case to a OneNote page, section, or paragraph that describes the use case in detail. Link a use case to a Word document that uses text, screens, and so on to describe the scenario for the use case. For more information, see Modeling user requirements. Linking a use case to a diagram or file in the same solution 1. Plot diagrams (such as sequence diagrams or activity diagrams) to illustrate scenarios for use cases. 2. Return to the use case diagram. 3. Drag the diagram or file from Solution Explorer to a blank part of the use case diagram. 4. Use dependencies to connect to the use case from the project. Link to a solution file such as a Word document or PowerPoint presentation 1. Write a document that uses text, screens, and so on to describe the scenario of the use case. 2. Add the document to the solution. A. Move the Word document into the Windows folder where the solution resides. B. In Solution Explorer, right-click the solution, point to Add, and then click Existing Item. C. Navigate to the Word document, and then click Add. The Word document is displayed in Solution Explorer in the solution folder. 3. Drag the Word document from Solution Explorer to a blank part of the use case diagram. The new item is displayed. 4. Use dependencies to connect to the use case from the project. Linking to a shared document, OneNote element, or Web page 1. Gets the URL of the shared element. For example, this URL can be a network file path starting with "\ \", a Web page, a Sharepoint URL that begins with "http://", or a link to a OneNote section, a page, or a paragraph that begins with "OneNote." 2. In the Toolbox, click Projects, and then click the Use case diagram. 3. When the new item is selected, type or paste the URL into the Hyperlink property. Note: Double-click an item to open the diagram or document to which it is linked. Link a use case to a work item If your project uses Visual Studio Team Foundation Server 2010 and you have Team Explorer, you can link each use case to a work item in Team Foundation. This can be used to: Describes a use case in a linked work item. In particular, if your project uses Visual Studio formal Process Template, you can link to a use case work item. This work item type provides fields that describe the goals and scenarios of the use case. Link test Cases to use cases so that you can get a report of the progress of code development that implements the use case. Link tasks to use cases so that you can track the progress of your development efforts. Structured Use cases You should try to describe the behavior of the system in only a few major use cases. Each large use case defines the primary goal that a participant realizes, such as purchasing a product, or, if it is from a vendor's point of view, a product for sale. Once you have identified these goals, you can refine how to achieve each goal and the variations of the basic goals. You should avoid splitting the use cases into thin-grained. Use cases should be based on the user's experience of the system, not the internal processing of the system. In addition, you will often find that it is more efficient to create an earlier working version of the code than to spend time fine-grained structuring the use case. You can summarize the relationship between the main use case and the refinement use case in the use case diagram. This is described in the following sections: Use include show details of use cases Sharing targets with generalization Separating variant use cases with extensions Use include show details of use cases Using the include relationship can indicate some details of one use case used to describe another use case. In the illustration, "ordering" includes "Payment", "select Menu" and "Order". Each included refinement case is a step that one or more participants may have to perform in order to achieve the overall goal of including the use case. The arrows should point to the included use case for refinement. Warning: The include relationship loop should not cause a use case to include itself. Loops can produce errors. The included use cases can be shared. In the example, the "Order Meal" and "subscribe to comment" Use cases include "payment". The goals and scenarios that are included in the use case should have an independent meaning so that they can be included in later design use cases. It is useful to divide the use case into both partial and included sections to achieve the following goals: Structure The use case description to a different level of detail. Avoid repeating shared scenarios in different use cases. Define the order of detailed steps A use case diagram does not provide the order in which the refinement steps must be followed, nor does it tell you whether each step is always required. To clarify the order of the steps, you can use the project to attach additional documents to the include use cases. In the following example, an activity diagram is attached to the "Order meal" use case. Alternatively, you can use a text document that contains a list of steps or a series of screens. For more information, see describing use cases in detail. Note the following naming conventions when working with activity diagrams: The name of the entire activity is the same as the name that includes the use case. The action in the activity diagram has the same name as the included use case. Sharing targets with generalization The generalization relationship is used to indicate that a specialized use case is a specific way of implementing a target represented by another common use case. The arrows should point to more general use cases. For example, "payment" generalizes "credit card payments" and "cash payments". Warning: You should not create a generalization relationship loop that causes participants to generalize themselves. Loops can produce errors. Specialized use cases help demonstrate different ways in which the system achieves the same goals. A dedicated use case is considered to inherit the goals and actors of the common use case. The generic use case can have no own solution, and its specialization describes the different ways to achieve the goal. Refactoring common goals with two or more use cases 1. Create a new generic use case and give it a name. 2. Create a "generalization" relationship whose arrows point to the new generic use case. A. Click Generalization in the Toolbox. B. Click the private use Case ("credit card payment" in the example). C. Click the general use case ("payment" in the example). 3. If the target of a dedicated use case has been described, you can move the common part into the description of the generic use case. 4. You can move participants that are shared between private use cases to a common use case. Separating variant use cases with extensions
The extension link is used to indicate that a use case can add functionality to another use case under certain circumstances. The arrows should point to the main use case being expanded. Warning, should not cause an extended relationship loop that will cause participants to generalize themselves. Loops can produce errors. For example, a "sign-in" use case for a typical Web site can include "Registering a new user", but only if the user does not yet have an account. Divide use cases into major and extended sections 1. Create a new extension use case and give it a name. 2. Create an "extended" relationship whose arrows point to the extended use case. A. Click Extensions in the Toolbox. B. Click the extension use case ("register new user" in the example). C. Click on the extended use case ("login" in the example). Note: Do not create loops for extended relationships in the diagram. Use cases cannot be extensions of their own. 3. If you have created a scenario for an extended use case, you can move the relevant steps into the extension scenario. 4. The description of the extension ("Registering a new user" in the example) should include details of the location and conditions where the extension appears in the main use case scenario. Treat it as a description to modify the main use case. The extension use case represents a scenario step that should be part of the main use case scenario. The context of the main use case will always be read into the extended scenario and target, so they may not have independent meaning Separating extensions is useful when describing the following scenarios: There are additional participants that participate only in extension cases. For example, an administrator is required to approve a customer's registration on the site. A separate subsystem will handle the extension use case. This extension will only be available in a specific version of the system. You can display each version as a separate subsystem in the use case diagram. Using subsystem boundaries subsystem boundaries are used to indicate which use cases are within the scope of the system. Draw subsystem Boundaries 1. Click Subsystems in the Toolbox, and then click the diagram. The subsystem is displayed in the diagram. 2. Drag the corners of the subsystem to resize it. 3. Drag the existing use case into or out of the subsystem to adjust the subsystem content. Or To create a new use case directly in the subsystem, click Use case in the Toolbox, and then click inside the subsystem. Note: the "subjects" property of the use case indicates the subsystem that contains it. Use cases outside the system scope It is often useful to include a use case that is part of a business component but not a system that you develop to work with in a diagram. This helps developers understand the context of their work. For example, "food delivery" can be displayed as a use case involving the participant "restaurant" and "customer", but outside the scope of responsibility of the "order site". Multiple subsystems You can create multiple subsystem boundaries to show how different use cases are handled by different system components. For example, "Add restaurant reviews" may be processed on a separate forum website. Keep in mind that use case diagrams should handle user-visible content. If you want to describe the work partitioning within your system, you should consider using component diagrams. System version You can use different subsystem boundaries to demonstrate different versions of the system. For example, the payment use case may be included in site version 2, but not in version 1. This means that the system can help the customer to order meals, but the customer must pay directly to the restaurant. Dependency relationships are used to link subsystems that represent different versions or variants. |
