6.12 Self-assessment questions
SAQ 1 Actors
(a) Explain why the actors in a use case diagram do not represent actual individuals.
(b) Suggest a guideline that will help you decide whether or not to include an interaction with an external system on your use case model.
(a) An actor in a use case diagram represents a particular role that an individual might play when interacting with a software system. For example, a receptionist checks guests into and out of a hotel. But it could be that the person who works as a receptionist at one hotel becomes a guest at another hotel in the chain and hence takes on another role.
(b) Show external systems as actors only if they need the use case. In other words, show the external interaction if the use case needs to communicate with the actor – the subsystem.
SAQ 2 describing use cases
(a) From your own experience, write down a description of the use case check out guest shown in Figure 3.
(b) Suggest a pre-condition and a post-condition for the use case check out guest.
(c) If you were determining the requirements for a real hotel chain, what would you do next with your answers to parts (a) and (b)?
(a) When a guest wishes to check out, he or she vacates the room and hands over the key to the receptionist. The receptionist finalises the bill and presents it to the guest. The guest pays the bill and leaves.
(b) Pre-condition: the guest must be currently allocated to a room and have a key.
Post-condition: the guest will have handed over the key, paid the bill and the room will have been designated as free to be reserved by another guest.
(c) Check them with real receptionist(s) to ensure that they are correct and capture the real requirements.
SAQ 3 Scenarios
What is the relationship between a use case and a scenario?
A use case is a related set of scenarios. Scenarios are instances of a use case in the UML. A scenario describes a sequence of interactions between the system and some specific actors. Here are two examples of scenarios. A member of a lending library may wish to borrow a book and is allowed to do that as long as she has no outstanding loans. However, another member may wish to borrow a book but has exceeded his quota of the number of books he is allowed to borrow. In either case they both want to borrow a book, but both the circumstances and outcomes of events are different for each instance. So, a use case includes a complex set of requirements that the system must meet in order to cope with every eventuality. There should be one main success scenario that helps an actor achieve the stated goal of the use case. In addition, there can be other scenarios for the same use case, each one having different outcomes depending upon circumstances.
SAQ 4 To extend or include?
(a) What are the two stereotypes that are used to define relationships between use cases in the UML?
(b) What is the function of the «include» stereotype?
(c) What is the function of the «extend» stereotype?
(d) Is it necessary to place the «include» and «extend» stereotypes on all diagrams?
(e) How would you modify a use case model to show that you intend to employ a component that already exists? Would you show this change to a user?
(a) The two stereotypes are «include» and «extend». A stereotype is a way of attaching extra classifications to a model. Stereotypes can be user-defined, which is a way of extending the UML.
(b) The «include» stereotype indicates a situation where a use case is reused. In Figure 7, the diagram illustrates a use case log-on which is used by three other use cases. The purpose is to demonstrate commonality between tasks so that reuse can be achieved. The additional use case is included unconditionally in the original or main use case.
(c) The «extend» stereotype indicates a conditional extension to the original use case, known as alternative behaviour. This is used to illustrate a case where there are two or more significantly different scenarios so that the main case and the additional, subsidiary cases are clearly differentiated. The main purpose of this classification is to separate out a special case. You should add a condition to each extension point to specify when the variant behaviour will be included.
(d) No, it is not necessary to place the «include» stereotype and the «extend» stereotype on all diagrams. In fact, in some situations they can cause confusion since their use is not at all ‘obvious’ and requires understanding that most users are unlikely to have. Their purpose is to illustrate reuse in the «include» stereotype and, in special cases, in the «extend» stereotype.
(e) The existing component must perform some useful task for the user, which adds some value to one or more use cases that you have already modelled. Each use case that benefits from the component must have a relationship to that component shown on the diagram. This relationship should have the «include» stereotype attached to it. If the use of that component would bring some benefit to the user, this should be shown in the new model. (Each change you make as a developer should make the proposed software more useful, usable, affordable, available or reliable.)