So, as we did for the previous cases, now let's look
at an example. Let's consider a specific use case, maintain curriculum, in
which we have the registrar that interacts with the system to do
operations for maintaining the curriculum. And, let's define the flow of events
for this use case. To do this, we're going to go back, as
usual, to the description of our system. So this is the one
that you already saw several times, but I would like for you
to do something. I would like for you to stop the video,
look back at the spec, the one that is shown here.
And write on your own, what you think is the informal flow
of events that categorizes the interaction of the registration manager with
the system. And it is very important that you keep in mind
something as you're doing that. You should keep in mind that,
as it always happens, when extracting
requirements from an initial specification, in
particular an informal one like this one, a high-level one, you
will have to be able to read between the lines and fill
in the blanks. That is, you have to provide the information
for the missing parts using your domain knowledge. So try to
do that exercise. Read the description, and see how you will
define the steps, the flow of events for the maintain curriculum use
case. If you're done with that, now let's see the possible
informal paragraph that describes that flow of events. And the one
I'm providing now is just one possibility, based on my experience
and based on the way I see this possible flow of events.
So yours might look different, of course. In my case, because
the description was measuring the fact that every user has got
a log-in and a password. I decided that the first step
should be that the registrar logs onto the system and enters his
or her password. As it normally happens with password protected systems,
if the password is valid, the registrar will get into the
system. And the system at this point should ask to specify
a semester for which the maintain curriculum activity has to be performed.
The registrar will therefor enter the desired semester. The interface
I envisioned is one in which the system will prompt
the registrar to select the desired activity. Add, delete, review,
or quit. And if the registrar selects add, the system
will allow the registrar to add a course to the
course list for the selected semester. Similarly, if the registrar
selects delete, the system will let the registrar delete a
course from the course list for the selected semester. And again
similarly, if the registrar selects review, the system will
simply display the course information in the course list for
the selected semester. And finally, if the registrar selects quit,
the system will simply exit and our use case will
end. So, again, there's the main knowledge that goes into
this. But this is a good example of how you
can refine the initial description to identify these scenarios that
then you will use to specify and implement your system.
And as we discussed a few minutes ago, we provided the information
that is requested for the use case, how the use case starts,
by logging into the system. And how it ends, by selecting quit.
We described the normal flow of events. And, of course, these flow
of events could be improved, because right now even though we described
how the use case starts and ends, we just described one possible
flow of events. But there's many alternative ways we could provide and
we do not describe any exception of flow of events. So this could
be the starting point for multiple use cases, or
for use cases just richer and contains more information, more
steps to a richer flow. But you should have
gotten the idea of what a use case should be.