Satish,
I think the extends arrow was misused in the diagram. Please see the information given below for more clarity.
When do I use the extends arrow?
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. You
would use this in situations where your 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 for you to
just lump them all together into the same use case.
Example: Suppose you wanted to add detail to the
diagram shown below, representing an airline reservation system.
Specifically, what you would like to show is that not all of the seats
aboard the airplane are exactly alike (some window and some aisle
seats), and sometimes passengers will express a preference for one of
these types of seats but not the other. 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.)
When do I use the uses arrow?
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.
Example: Suppose you wanted to add detail to the
diagram shown below, representing an airline reservation system.
First, you would create a separate diagram for the top-level services,
and then you would 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.
What is the difference between uses and extends?
Probably the best way to think about these diagram elements is as follows:
- "X
uses Y" indicates that the task "X"
has a
subtask "Y"; that is, in the process of completing task "X", task "Y"
will be completed at least once.
- "X
extends Y" indecates that "X"
is a task fo
the same type as "Y", but "X" is a special, more specific case of
doing "Y". That is, doing X is a lot like doing Y, but X has a few
extra processes to it that go above and beyond the things that must be
done in order to complete Y.
Regards,
Karthic Madanagopal