An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task.

Use cases are used in almost every project. The are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible

Below example shows use case for a credit card process

When to use the "uses arrow" in UCD?

The uses arrow (or uses edge as it would be called in traditional graph thoery) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in UCDs of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it it can be read X uses Y means that "X has a Y" as part of it's behavior.

Consider an airline reservation system. First step is to create a separate diagram for the top-level services, and then add new use cases that make up the top-level ones. There is a uses edge from "Check in Passenger" to "Weigh Luggage" and from "Check in Passenger" to "Assign Seat"; this indicates that in order to Check in a Passenger, Luggage must be Weighed and a Seat must be Assigned. Similarly, the diagram indicates that in order to add a reservation to the system, the available space must be checked and the passenger's information must be recorded. You could imagine breaking these use cases down further to show more detail.

When to use the "extends arrow" in UCD?

The extends arrow (or extends edge) is drawn from a use case X to a use case Y to indicate that the process X is a special case behavior of the same type as the more general process Y. In this situations system has a number of use cases (processes) that all have some subtasks in common, but each one has something different about it that makes it impossible to just lump them all together into the same use case.

In airline reservation system sometimes passengers will express a preference aisle seat or window seat. But of course, they cannot just be given their preference right away, because the seat they want might not be available. Therefore, the process of assigning a window seat involves checking for the availability of window seats, whereas the process of assigning an aisle seat involves checking for the availability of aisle seats. But even though these processes are different, they are quite similar in a number of other ways, so it doesn't make sense to ignore their similarities. Fortunately, UML lets us have both: we write that assigning these two types of seats are different processes, but they are similar in that both processes extend a common, more general process (assigning seats.)