Subject: Questions about scenarios

> I am trying to get a good handle on the difference between a scenario and a 
> use case as a means for choosing a set of use case. I was hoping you
> could help us along with some insight. 
> 
> In the student registration example you were using in class, 
> we discussed the "registers" for class use case. One could think of this
> as an "Add Course" use case, which immediately brings to mind the
> "Drop Course" possibility. I am confused as to whether these are
> two scenarios, or two use cases that <<"include">> some other more
> general use case. I can convince myself that these are two 
> scenarios,  the drop or add being a detail (parameter) of the interaction.

It could be two scenarios, details within one scenario or even two use cases.
The requirements are very different in each case.  If the system will have a
completely different user interface for the two cases, then they should be two
use cases.  If part of the flow of control is the same in the two cases, then
an <<include>> may be used.  If it is just a parameter within the interaction
(say, a checkbox in the user interface), then they should be a single scenario.
If the user interfaces are basically the same, but there is a branch at one
point in the interaction, then it would be more appropriate to have a single
use case with two scenarios.

> In our project, I see a case of an actor (say the TCS on some node) 
> requesting information, or asking that some information be stored locally. 
> Again, if I consider that "request" and "store" are simply details of one
> kind of interaction between the TCS and our system, I would be tempted to
> say that they are part of the same case. The place where this seems to
> be less clear is a "request" for information that is not stored at the
> node. This may involve other actors (different roles), possibly one of 
> them a "broker" who might be able to tell the first node which third node
> has the information. Does this also fit into one general "request" use
> case? 

I can't give you specific advice about this situation because it is part of the
assignment.  All I can say is that you should keep in mind that the audience
for use cases will typically include many nontechnical people.  Clarity of
presentation is important.  Avoid any kind of logic (i.e., conditionals) in the
use case and focus on the normal flow of events.

> Another point. The project description alluded to at least two different
> types of nodes --- the vehicles and the streets/buildings. Could we assume,
> since buildings are relatively static structures, that they could
> function in  a broker role for vehicles requesting information ?

> I found an analogy on a newsgroup somewhere that a scenario is to a 
> use case what an instance is to a class. I also read (Martin Fowler's 
> UML Distilled) that sometimes it helps to think of actors in terms of 
> the roles they play in an interaction rather than as entities. Would you
> agree with these statements?

Absolutely.  I repeated them several times during my lectures (in various
ways).  It is good to emphasize them.  A scenario is an instance of a use case.
An actor will also have instances, and these instances are defined by their
role in the use case.

> FYI: I heard that a person on our team is
> no longer enrolled in 3205.

There is not much I can do about this.  Fortunately, new groups will be
assigned in the next assignment, so it shouldn't affect you.

> XMI: I was planing to use ArgoUML to do the models for the assignments. It 
> claims to produce XMI output (and it does), but does not have support for 
> attaching scenarios to use cases. They claim to be using the latest
> metadefinitions (uml13.dtd). Would you know how I would go about
> ascertaining whether this is a standard dtd? Finally, would it be ok to
> submit the scenarios as separate html files?

You should be able to state the scenario in the documentation attached to the
use case.  This is only free text, of course.  One can also include links in
your repository.  These links can be to html files.  However, such links are
not attached to other objects.