UML 2 For Dummies

Some business analysts go use-case crazy. Before they know it, they have an unruly plethora of use cases. This happens when the business analyst creates—CRUD. Yep, CRUD. For example, the user needs to Create addresses, Read addresses, Update addresses, and Delete addresses. So the analyst creates four use cases to handle the Address class. Then, with a flourish, the Read Address use case is included by putting «includes» in the Create, Update and Delete Address use cases. (By the way, this analyst is just getting started. Every class known to the user must be created, read, updated, and eventually deleted—which means dealing with thousands of use cases.)

 Tip   When you see lots of use cases, check to see if they are CRUD. Check the following to identify CRUD:

• One class: Several use cases all center around just one class.

• Not a major class: The use cases deal with a relatively minor class in your application.

• CRUD: The use-case names are similar to Create X, Read X, Update X, and Delete X, where X is the minor class.

• Simple interaction: Each use-case description is short and simple to describe.

• Include Read use case: Several of the use-case descriptions include the Read X use case. In other words several use cases have an «include» relationship to a use case named Read X.

If you recognize CRUD use cases, combine them into one use case and call it Maintain X. However, if the CRUD use cases really represent different goals to the users, then they should be separate.

 Warning   You should be careful not to fall into the opposite trap of creating a diagram with one use case that seems to do everything. You can recognize this situation by looking at the use-case description. If it has sprouted many complicated alternative paths, replace that overburdened use case with several simpler ones.