Now if you want to build a use case diagram for
our example, we have to add the use cases for
these different actors. For instance, if we consider the student
and the registrar, they might be both interacting with the maintain
schedule system, the registrar by updating the schedule and the
students by using the schedule that has been updated by the
registrar. As you can see, different roles for the same
use case. Another possible use case is the request course roster.
And on this case, the professor will request the roster
by interacting with the system. We will continue in this way
by further refining and by further adding use cases as we
identify possible interactions of the actors that we identified with our
system. So in summary, what the use case diagram is doing
is to show the actors and their interaction with the system
through a set of use cases. At this point, it should
be pretty clear that sure, this gives us an idea of
the interactions but we don't really know how these interactions occur.
So there is one piece that is missing, which is how
do we document the use cases, how do we describe what
happens and what these interactions actually are. And that's exactly what
we're going to discuss now, how to document use cases. So the
behavior of a use case can be specified by describing its
flow of events. And it is important to note that the
flow of events should be described from an actor's point of view,
so from the point of view of the external entity that
is interacting with my system. So the description should detail what
the system must provide to the actor when the use case
is executed. In particular, it should describe how the use case
starts and ends. It should describe the normal flow of events,
what is the normal interaction. And in addition to the normal
flow of events, it should also describe possibly alternative flows of
events. For example, in the case in which there are multiple
ways of accomplishing one action or performing a task. And finally,
it should also describe exceptional flow of events. For example, assume that
you are describing a use case for withdrawing money from an
ATM. You may want to describe the normal flow of events in which
I insert my card, I provide my pin and so on.
An alternative one in which, in addition to withdrawing cash, maybe I'll
also first ask for some information about how much money is
in my account. And finally, I may want to also describe an exceptional
flow of events in which I get my pin wrong and,
therefore, I'm not able to perform the operation. One more thing I
want to mention, when we talk about documenting use cases, is
the fact that the description of this information can be provided in
two main ways, in an informal way or in a formal
way. In the case of an informal description, we could just have
a textual description of the flow of events in natural language.
In the case of a formal or structured description, we may use,
for example, pre and post conditions, pseudo
code to indicate the steps. We could
also use the sequence diagrams, which is something that we will see in a minute.