Use-Case Diagram


To understand your system’s requirements from the users’ perspective, build a use-case diagram. A quick way to create one is to start with the context diagram. If you remove the data input and output from the context diagram and simply add a use case for each of your actors, you have a use-case diagram.

The use-case diagram helps you understand the major functionality that your system must provide for each type of user. That’s vital information when you want to organize the requirements imposed on each group of users (that is, on each actor). Each use case tells the requirements story from the user’s perspective.

 Warning   Don’t try to complete your use-case diagram with all the use-case descriptions (textual description of the details of the user’s use of the system) at once; instead, follow these steps:

  1. Develop a basic use-case diagram and just supply the name, summary, and actor in each use-case description.

  2. Model the user’s domain in a domain class diagram for your use cases.

    For more information, read the section “Domain Class Diagram” later in this chapter.

  3. Return to your use-case descriptions and fill in the pre- and postconditions.

    You might also want to provide a (simple) example of a user interaction.

  4. Add details that you found while discussing user interaction (in Step 3) to your domain class diagram (in Step 2).

  5. Consider adding alternative and error scenarios to your use-case descriptions.

Creating careful, thorough use-case diagrams, and use-case descriptions can help you achieve the following goals:

  • Easier communication: Use cases are written in the language of the user. Your users and project stakeholders understand what you’re talking about because you use their words. You understand what the users are saying because you focus on their needs.

  • Better-educated users: Users often don’t know exactly what they want in a new software application. You will educate your users because you understand their goals, develop use cases to meet those goals, and describe back to the users (in a language that they understand) what the use cases does to help them. As you help users to focus on their job goals, they in turn tell you what they need from your system to meet those goals.

  • Closer focus on requirements: Developers find it hard to focus on requirements. All too often they think about how to make a program work. Developers focus on technology and implementation details because that is their training. Use cases help you stay focused on users’ needs (requirements).

  • Natural stages for incremental development: Each use of the system is geared toward one group of users. You don’t have to build an entire application; all you need is one that does just a few use cases. Then, incrementally, design and build a few more use cases—and deliver them in the next increment to your system. You can get away with this incremental approach because use cases don’t depend on each other. What one group of users may need is different from what another group needs. In our experience, each use case has its own classes. If the user requirements (for example) change for one particular use case, they don’t cause changes in other use cases.

 Tip   Use interview notes and use-case descriptions to help you build a domain class diagram. User interactions (part of your use-case documentation) can help illustrate the dynamics of your system or software. You capture the dynamics of text descriptions in sequence diagrams.




UML 2 for Dummies
UML 2 For Dummies
ISBN: 0764526146
EAN: 2147483647
Year: 2006
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net