developer.com
Search EarthWeb
CodeGuru | Gamelan | Jars | Wireless | Discussions
Navigate developer.com
Architecture & Design  
Database  
Java
Languages & Tools
Microsoft & .NET
Open Source  
Project Management  
Security  
Techniques  
Voice  
Web Services  
Wireless/Mobile
XML  
New
 
Technology Jobs  

   Developer.com Webcasts:
  The Impact of Coding Standards and Code Reviews

  Project Management for the Developer

  Defining Your Own Software Development Methodology

  more Webcasts...




Return in early January to see which technologies and products won.




Developer Jobs

Be a Commerce Partner














 


Developer News -
Linux Subscriptions Paying Off for Red Hat    December 23, 2008
OpenVAS Charts Its Own Forked Course    December 22, 2008
A Linux Year in Review: Sun's Very Big Buy    December 18, 2008
Adobe Floats AIR 1.5 Into Linux    December 19, 2008
Free Tech Newsletter -

Creating Use Case Diagrams
By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

Go to page: Prev  1  2  3  4  Next  

Creating the Use Case Diagram

For drawing use case diagrams, you need to use any tool that supports use case diagrams. We will be using the Poseidon Community Edition tool for drawing the use case diagram, as shown in Figure 3.7. You can use any tool that you are comfortable with. A use case modeling tool provides a palette of options to draw actors and use cases and to define relationships between the use cases.



Click here for a larger image.

Figure 3.7: a screen shot of the Poseidon tool

Take a look at the screen shot of the Poseidon tool. You can see the different options it provides to draw the use case diagram elements. In addition to drawing the use case diagram elements such as actors and use cases, you also can define relationships between use cases. Apart from this, the tool also provides capability to document the different elements that we draw. This documentation can be viewed as a consolidated report for future reference.

An additional feature that you can check in your modeling tool is support for generating test scripts from the use case diagram. A comprehensive use case diagram provides a good foundation for basing test cases for the system that you model.

Writing a Use Case Specification

A use case diagram, as we have seen, is a visual depiction of the different scenarios of interaction between an actor and a use case. The usefulness of use case diagrams is more as a tool of communication between the requirements capture team and the user group. The next step after finalizing of use case diagrams is to document the business functionality into clear-cut and detailed use case specifications. Because use cases are used as an input to the other project phases such as design, development, and testing, we need to ensure that the visual depiction of the business requirements is translated into clear and well-defined requirements in the form of use case specifications. Elaborate use case specifications are used as an input for design and development and for writing test cases (unit, system, and regression tests, as the case may be).

A use case specification document should enable us to easily document the business flow. Information that you document in a use case specification includes what actors are involved, the steps that the use case performs, business rules, and so forth. A use case specification document should cover the following areas:

  • Actors: List the actors that interact and participate in this use case.

  • Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform.

  • Post-conditions: Define the different states in which you expect the system to be in, after the use case executes.

  • Basic Flow: List the basic events that will occur when this use case is executed. Include all the primary activities that the use case will perform. Be fairly descriptive when defining the actions performed by the actor and the response of the use case to those actions. This description of actions and responses are your functional requirements. These will form the basis for writing the test case scenarios for the system.

  • Alternative flows: Any subsidiary events that can occur in the use case should be listed separately. Each such event should be completed in itself to be listed as an alternative flow. A use case can have as many alternative flows as required. But remember, if there are too many alternative flows, you need to revisit your use case design to make it simpler and, if required, break the use case into smaller discrete units.

  • Special Requirements: Business rules for the basic and alternative flows should be listed as special requirements in the use case narration. These business rules will also be used for writing test cases. Both success and failure scenarios should be described here.

  • Use case relationships: For complex systems, it is recommended that you document the relationships between use cases. If this use case extends from other use cases or includes the functionality of other use cases, these relationships should be listed here. Listing the relationships between use cases also provides a mechanism for traceability.

You can download a template for a use case specification document and customize it for your use here.

Go to page: Prev  1  2  3  4  Next  

Previous article: UML Tools
Next article: The UML Class Diagram: Part 1


Tools:
Add www.developer.com to your favorites
Add www.developer.com to your browser search box
IE 7 | Firefox 2.0 | Firefox 1.5.x
Receive news via our XML/RSS feed


Architecture & Design Archives






internet.comearthweb.comDevx.commediabistro.comGraphics.com

Search:

Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia

Jupitermedia Corporate Info

Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers