2.

The Use Case Diagram In many design processes, the use case diagram is the first that designers will work with when starting a project. This diagram allows for the specification of high level user goals that the system must carry out. These goals are not necessarily tasks or actions, but can be more general required functionality of the system. Use Case More formally, a use case is made up of a set of scenarios. Each scenario is a sequence of steps that encompass an interaction between a user and a system. The use case brings scenarios together that accomplish a specific goal of the user. A use case can be specified by textually describing the steps required and any alternative actions at each step. For example, the use case for searching a web for a keyword might be shown as: 1. Customer enters the keyword 2. Customer clicks the search button 3. The search is executed 4. The results are shown Alternative: Search Failed If the search fails at 3, then the user is redirected back to the search screen at step 1 In Visual Case, you can specify the steps of a use case in its description field. Simply right-click on a use case and select properties. You can then run a report and print or export the results to html or ascii text. Together, the report and the diagrams will include all of the details of the use case - their specific scenarios and the actors that carry them out. Actor The use case diagram allows a designer to graphically show these use cases and the actors that use them. An actor is a role that a user plays in the system. It is important to distinguish between a user and an actor (better thought of as a role). A user of the system may play several different roles through the course of his, her or its job (since an actor may be another system). Examples of actors are salesperson, manager, support person, and web store system. It is possible that the same person may be a sales person and also provide support. When creating a use case model, we are not concerned with the individuals, only the roles that they play. Associations

On a use case diagram, associations are drawn between actors and use cases to show that an actor carries out a use case. A use case can be carried out by many actors and an actor may carry out many use cases.

In the above diagram, the actors are shown as the green stick figure shapes on the left, the use cases are the blue ellipses, and the associations between them are represented by the connecting lines. The developer and the stakeholder both are responsible for specifying the system roles, but only the developer creates the model. Includes Use cases can also be related to each other with three different links. The diagram below shows the use of the includes link. Both invoice purchase and online purchaseinclude the scenarios defined by purchase valuation. In general, the includes link is to avoid repetition of scenarios in multiple use cases.

Generalization When a use case describes a variation on another use case, use a generalization link. In the example below, the use case limit exceeded describes a situation in which the usual scenario of online purchase is not performed. Use cases that generalize

another use case should only specify an alternative, even exceptional, scenario to the use case being generalized. The overall goal of the use cases should be the same.

Extends In some instances you want to describe a variation on behaviour in a more controlled form. In such instances you can define extension points in the extended use case. In the example below, search by name is said to extend search at the name extension point. The extends link is more controlled than the generalization link in that functionality can only be added at the extension points.

Putting it all Together When starting a use case model, it is very important to keep it simple. Often it is easiest to first determine the actors of the system, and then flush out the use cases that they perform. Your use case diagrams can be as simple or complex as you wish, however simpler, less cluttered diagrams are easier to understand, and are often more powerful in capturing the tasks of the system. In Visual Case, you can explode a use case into a new use case diagram. For example, the use case online purchase may require further specification as you move into the design. You can create a sub-diagram within any use case to help clarify and understand the tasks involved.

Remember that a use case represents a goal of a user, not an atomic programming operation. Your use case design should be simple and help to clarify the user's goals and expectations for the system.