When to define SDD(System Sequence Diagram) operations System->Actor?

Question

I am having some trouble understanding how to make System Sequence Diagrams, as I don't fully grasp why in some cases one should define operations for System -> Actor and in others don't. Here is an example:

Let's assume the System is a Cinema Ticket Store and the Actor is a client that wants to buy a ticket.

1) The User tells the System that wants to buy some tickets, stating his client number.
2) The System confirms that the given client number is valid.
3) The User tells the System the movie that wants to see.
4) The System shows the set of available sessions and seats for that movie.
5) The System asks the user which session/seat he wants.
6) The User tells the System the chosen session/seat.

This would be converted to:

a) -----> tellClientNumber(clientNumber)
b) <----- validClientNumber
c) -----> tellMovieToSee(movie)
d) <----- showsAvailableSeatsHours
e) -----> tellSystemChosenSessionSeat(session, seat)

I know that when we are dealing with SDD's we are still far away from coding. But I can't help trying to imagine how it how it would have been had I to convert it right away to code:

I can understand 1) and 2). It's like if it was a C#/Java method with the following signature:

boolean tellClientNumber(clientNumber)

so I put both on the SDD.

Then, we have the pair 3) 4). I can imagine that as something as:

SomeDataStructureThatHoldsAvailableSessionsSeats tellSystemMovieToSee(movie)

Now, the problem:

From what I've come to understand, my lecturer says that we shouldn't make an operation on the SDD for 5) as we should only show operations from the Actor to the System and when the System is either presenting us data (as in c)) or validating sent data (such as in b)).

I find this odd, as if I try to imagine this like a DOS app where you have to put your input sequencially, it makes sense to make an arrow even for 5). Why is this wrong? How should I try to visualize this?

Thanks

Answer 1

You haven't defined what your system is, and you're not being clear what stage of design you are in, so it's a little hard to answer.

If you instead imagine something like the systems for booking trains on the web, the screen which shows the times just has checkboxes next to them for the user to select which one they want, rather than the system prompting the user - the user initiates the next step on receipt of the data. So it is perfectly possible for a user interface to allow the user to select from just the data without an extra prompting.

If you are doing preliminary design of a system, try and avoid making assumptions about user interfaces, and only include essential use cases. You'd only need the 'print a prompt for the user' use case if you were designing the DOS UI component; it wouldn't be a use case in a web based system.

So the problem isn't that you have some use cases with interactions between the user and system and some with none. The problem is that some of your use cases are assuming a particular UI implementation detail which is not essential for the system to function, and should not be in the top-level design.