Unit 3

Question 1

What are the important properties that a representation of business rules should have?

Answer 1

The important properties are as follows:
Business rules should be represented separately from other models;
They should be easy to verify (possibly automatically) and validate;
They should be represented in a readable but structured language.

Question 2

Consider whether business rules can be modelled in UML; discuss the consequences in the light of the properties in your answer to (a).

Answer 2

UML does not provide an explicit notation for business rules. As a consequence, it
does not:
Facilitate separate recording of the rules;
Facilitate their analysis, validation and change;
Facilitate their traceability from the business needs to the software solution.

Question 3

What causes a transition in an activity diagram?

Answer 3

A transition in an activity diagram is caused by the completion of an activity.

Question 4

What is a synchronisation bar, and when is one used in an activity diagram?

Answer 4

A synchronisation bar is used to mark the point when two or more activities can take place independently (a ‘fork’), or when a number of tasks must finish before continuing (a ‘join’).

Question 5

Figure 1 represents a particular way of making a cup of coffee. Suggest a reason
why the activity add coffee has been placed before the joining synchronisation bar
rather than immediately after the bar.

Answer 5

When the kettle is full and you are waiting for the water to boil, there is some ‘free’ time that you can use to add coffee to the cup. Placing the activity add coffee after the joining synchronisation bar rather than before it would mean that you would
have to wait to carry out the activity until the water had boiled, and the overall time taken for the task would be longer than that shown in Figure 1.

Question 6

How does the partitioning of activities into swimlanes help us understand a set of activities?

Answer 6

Swimlanes group activities associated with different roles. Each swimlane shows who is responsible for which set of related activities.

Question 7

Indicate one reason for modelling a workflow in an activity diagram.

Answer 7

Activity diagrams help to identify which role is responsible for which activities in a business process. An activity diagram can help identify the stages at which each role requires some interaction with the process. When you are modelling a workflow that involves more than one role, it is possible to identify which role is responsible for a particular activity.

Question 8

Name three aspects of software development where use case modelling can help.

Answer 8

Any three of the following: capturing and eliciting requirements; representing requirements; planning iterations of development; validating software systems.

Question 9

Suggest a reason why use case diagrams are an aid to communication between user and developer.

Answer 9

Use cases offer users an opportunity to understand the system without the need to
understand all of UML since the use case notation is relatively simple. This provides a mechanism that enables both developer and client to share a common understanding of the system, as long as the developer provides some text to demonstrate his or her understanding of the problem.

Question 10

What is the purpose of a system boundary? Is it always necessary to draw one in a use
case diagram?

Answer 10

The purpose of a system boundary is to identify a single system, distinguishing between the internal and external components. Typically, the external components are the actors, and the internal components are the use cases. UML says that the system boundary is optional.

Question 11

Explain why the actors in a use case diagram do not represent actual individuals.

Answer 11

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 (see Figure 9). 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.

Question 12

Suggest a guideline that will help you decide whether or not to include an interaction with an external system on your use case diagram.

Answer 12

Show interaction with an external system if the use case needs to communicate with the actors that represents the external system.

Question 13

What is the relationship between a use case and a scenario? Give examples to illustrate your answer.

Answer 13

For each use case there is a set of possible scenarios. A scenario is an instance of a use case. A scenario describes a sequence of interactions between the system and some actors.
Here are two examples of scenarios. A member of a lending library wishes to borrow a book, and is allowed to do that as long as she has no outstanding loans. Another member wishes to borrow a book, but has exceeded his quota of the
number of books he is allowed to borrow. In each scenario, the member wishes to borrow a book, but both the circumstances and outcomes of events are different in each instance. So a use case includes a complex set of requirements that the system must meet in order to cope with every eventuality.

Question 14

What is meant by a main success scenario?

Answer 14

The main success scenario shows the steps normally followed to achieve the stated goal of the use case. But there can be other scenarios for the same use case, each one having different outcomes depending upon circumstances.

Question 15

How do use cases help with requirements capture?

Answer 15

Use cases help with requirements capture by assisting with the identification of actors and tasks in the system. For each actor, the set of use cases establishes what that actor requires from the software system. The association between an
actor and a use case is about communication. Therefore you should also establish what the software system derives from the actors.

Question 16

How do use cases help with the elicitation of detailed software requirements?

Answer 16

Detailed software requirements can be associated with each step in a use case
scenario.

Question 17

How do use cases help with development?

Answer 17

One of the difficulties that developers face is planning delivery times. Often a customer can place pressure on the developer to meet a particular deadline. However, it is the developer’s job to indicate which criteria in the software system can be met under such constraints, and to elicit from the users those use cases that have
the highest priority. The use case diagram helps by: providing an understanding of the complexity of each use case; determining which actors interact with each use case and to what degree; discovering which use cases carry the most risk; and estimating how long each use case is likely to take to implement. Understanding these aspects of the system can help developers plan the order in which the use casesshould be developed, and provide an appropriate time frame. Several criteria such as risk, coverage and criticality can be used to help establish priorities of use cases.

Question 18

How is system validation performed using a use case?

Answer 18

One way to validate a system is to use the walk-through technique. This is where each
use case is examined in turn to assess whether the system actually supports the functionality required by the users a process known as validation. The walk-through technique can also be used to elicit system tests where each use case is required to deal with a number of scenarios a process known as verification. For each software
requirement generated from a step of a scenario, the fit criterion helps to devise the test.

Question 19

A typical lending library keeps a stock of books for the use of its members. Each
member can take out a number of books, up to a certain limit. After a given period, the
library expects members to return the books that they have on loan. When borrowing books, members are expected to hand their chosen books to the librarian, who records each new loan before issuing the books to the member. When a book is on loan to a member, it is associated with that member: possession of the book passes from the library to the member for a defined period. The normal loan period for each book is two weeks. If the member fails to bring the book back on or before the due date, the library imposes a fine.
In the proposed new software system, anyone should be able to browse the stock of books held in the library, but only a member will be able to reserve a book. The ability to browse and make reservations will be provided through a web-browser interface. The system should also deal with the enrolment of new members for the library.Draw a simple use case diagram for the proposed software system, and identify the
constraints or assumptions that you make. (Ignore the issue of fines, because there is
not enough information.)

Answer 19

A good first step is to establish the context for the proposed system by identifying the
actors that surround it. When you have identified the actors, you can investigate the behaviour that each one will expect from the proposed system, which will eventually give rise to the use cases for your model. Your task is to determine the roles that people will adopt in order to use the proposed
software system. In general, the customer (the person who is buying the software) will have some say in who is a legitimate user. In this problem domain, the library owns the books. One of its employees, a librarian, is responsible for issuing books to a member. Typically, a librarian will also act on the member’s behalf when recording a new loan. Hence we expect the librarian to be a key user of the new system. Browsing through the library’s catalogue is a common activity performed by both members and librarians. As a catalogue is only a kind of list that shows what the library
offers for loan, it can be read by anyone: non-members are also to be allowed to
browse the catalogue. There appear to be two scenarios related to the activity of reservation. In the first, a member might want to borrow a specific book, but finds that all the available copies
are out on loan. In the second, a member might want to make sure that at least one copy is available in order to avoid a wasted trip to the library.We conclude that there are three basic actors:
Member
Librarian
Browser
What is missing from the given description of the system is any indication of how people join the library and become members. We have been told that there is a possible fine for overdue books, but is there a fee to join the library? Do prospective
members have to prove their identity? How do members prove their membership? So
this is a potential use case that requires later elaboration In addition, someone – a librarian, we presume will be expected to make sure that the catalogue reflects the actual stock held at the library, and a corresponding use case is needed for this.Our solution includes six basic use cases for the library software system:
Issue copy of book
Return copy of book
Reserve book
Browse catalogue
Update catalogue
Enrol new member
Figure 10 (p.32) shows a possible use case diagram for the proposed system. You may have used different names on your diagram, and you may have identified more or fewer than six use cases. There is no one correct solution: there are many possibilities. You may have defined use cases that combine two or more of our use cases, but in doing this it is likely that you would have assumed knowledge of the internal structure of the proposed system. In a use case diagram, you should identify only the behaviour that will bring some discernible value to at least one actor. In reaching your solution, you might have gone through several iterations. This is to be expected. Your first guess could have been done in your notebook, as opposed to using a CASE tool. In practice, you might alternate between pencil and paper and a CASE tool. Whatever your chosen means of recording, focus on getting a useful result. A rough diagram that is useful is better than a pretty one that is not! Finally, you should have included some notes with both the diagram and the elements in it. For example, in Figure 10, the issue copy of book use case has a note associated with it indicating the loan period. Notes are an excellent way to record constraints on
the behavioural requirements. Another use of a note is to indicate something that needs further attention or revision.Figure 10 shows that both members and librarians are associated with reservingbooks. A note records the fact that librarians can reserve books on behalf of members.
At some future point, once you have learnt more about the library, you would revise the
use case diagram.

Question 20

Suggest a precondition and a postcondition for the check out guest use case given in Table 1. (You may also find the scenario of Table 1 useful.)

Answer 20

Precondition: the guest must be currently allocated to a room.
Postcondition: the room will have been designated as free to be reserved by another guest, and the guest will have paid his or her bill.

Question 21

Prepare a textual description of the check in guest use case that appears in Figure 9. Follow the example of Table 1, which shows the main success scenario and other criteria for the make reservation use case. As part of your working, identify any exceptions to the main success scenario. You will need to make some reasonable
assumptions and should record them.

Answer 21

The actor for the check in guest use case is the Receptionist, as shown in Figure 9. You need to consider the exchanges that take place between each guest and the hotel’s receptionist. The main success scenario describes the simplest path for checking a guest into a room in a hotel. There can and will be exceptions to the main success scenario. Our solution is shown in Table 2.

Question 22

What is the purpose of identifying relationships between actors?

Answer 22

The purpose of identifying relationships between actors is to indicate generalisations. Figure 11 illustrates a Guest being a special type of Reserver.A Guest can do the same things that a Reserver can, but may be able to do something else that a Reserver cannot.

Question 23

What is a stereotype in UML?

Answer 23

A stereotype is a way of attaching extra classifications to a model. Stereotypes can be user-defined; this is a way of extending UML.

Question 24

What is the function of the «include» stereotype?

Answer 24

The «include» stereotype indicates a situation where a use case is reused. In Figure 12, the diagram illustrates the check reservation use case, which is used by two 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 base, use case.

Question 25

What is the function of the «extend» stereotype?

Answer 25

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 to specify when the variant behaviour will be included. This could be done with either a note or an extension point.

Question 26

Is it necessary to place the «include» and «extend» stereotypes on all diagrams?

Answer 26

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 they will not be understood by everyone.

Question 27

How would you modify a use case model to show that you intend to employ a component that already exists?

Answer 27

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.

Question 28

What is the main source of confusion for a developer who has been asked to produce a use case diagram for a potential software system?

Answer 28

The main source of confusion for the developer is the separation of the problem from its potential solution. In asking ‘What tasks should the software system perform?’, for example, the developer should be aiming to draw a clear boundary between the problem domain and the intended software system.

Question 29

What problems may arise when developing a software system from a set of use cases?

Answer 29

``` One problem is that the focus may end up being top-down and function-oriented, resulting in an inflexible and difficult-to-maintain system. Focusing on the use cases may cause the developers to sacrifice the object-oriented nature of the system, thus losing any advantage that UML offers. Another danger lies in mistaking design for requirements, where a design decision is mistaken for a constraint. Focusing on the requirements in a use case may cause developers to view the system too operationally, where a sequence of events is assumed to be the only answer. Developers need to distinguish between requirements and preferred designs. There is also a danger of missing some of the requirements, especially if emphasis is placed on actors and their tasks, because not all the requirements will emerge in this process. A developer should use more than just one model of a proposed system. For example, class modelling (discussed in Unit 5) should be performed alongside use case modelling, since one informs the other. This illustrates that use cases help mainly with requirements capture and testing but not with the design. Use cases need to be used in a way that is understandable to the customer but also useful to the developers. ```

Question 30

What are the tasks involvedin preparing a use case diagram for a moderately large system,intended for the development team?

Answer 30

For each use case diagram: Define the context for the model by identifying the actors involved in the aspect of the system in question; Analyse the behaviour that each actor expects from the proposed system, and identify the use cases (as units of functionality within the overall requirements); Identify the common behaviour that may be reused by other actors, and the variations on common behaviour (the stereotypes «include» and «extend»); Draw a model that shows the use cases, the actors and the relationships between them; Annotate the use cases as you learn more about the requirements. For large projects, you will need to record separately any constraints that affect more than one use case diagram. One way is to produce a use case model at a higher level of abstraction.

Question 31

Recall the hotel example, which was introduced in Section 3 (see Figures 8 and 9). Redraw Figure 8, taking into account theinformation contained in Tables 1, 2 and 3, to show common tasks and any extensions to the main success scenarios. (Do not show the log on use case, described in Figure 15.)

Answer 31

Our solution is given in Figure 17. When a Guest checks in, we can identify two components: identify reservation and check for available rooms. When a Guest checks out, we can identify at least one component: prepare bill. A bill is assumed to exist because the check in guest use case includes open new bill for the guest. This is something for the developer to check, in discussions with the users. We will also assume that the records of payments made by guests are held separately, which is a typical accounting procedure. Hence we have identified a new actor called Accounts System that communicates with open new bill and prepare bill. Since a room must be cleaned after a guest has checked out we have identified a use case named request room cleaning. This is the kind of detail that you are likely to discover as you find out more about the problem domain. Finally, there may be an early design decision to change the way that reservations are created. The difficulty arises because there is a subsidiary goal to create a new guest record if the person identified during reservation is not known to the hotel system. For example, you may decide to have a software component that identifies those who have already been entered into the hotel system (in a use case called identify guest, say). Such a component is very likely to be reused in other use cases. As a consequence, creating a new guest could be seen as an extension of identify guest, whenever a condition such as guest not found is encountered. Undoubtedly, your diagram will differ in some aspects from Figure 17, but you should be able tojustify your choices. You should have used «extend» to show variant behaviour, and «include» to show the potential use of components. We have deliberately added enough new use cases to show how easy it is for use case diagrams to become quite complicated. Such complex use case diagrams are unlikely to be shown to the intended users; they are intended for the development team.

Question 32

A nationwide chain of DVD rental shops wants to take advantage of web technology to change the way that it operates. The main changeis to allow members to use their web browsers tolook through its stock titles, make reservations and rent DVDs for delivery to any location within a certain distance from any one of its shops. Currently, prospective members have to goin person to theirlocal branch of the DVD chain and pay ajoining fee. A member ofstaff at the branchthen issues a membership card, which is used to reserve or rent DVDs. Members can only rent from the stock available at the branch where they joined. The owners want to simplify the membership procedure as follows. People can use a web browser tojoin the scheme by providing credit card details as wellas their postcodes, which allows the company to perform a credit check and locate their home address while the prospective member waits. Once a membership application has been accepted, the member can browse the stock of DVDs and find out when their choice will be available for rental from the branch nearest to the member’s home. The new software system should enable a member to reserve a DVD in advance or request its deliveryifitis available. The local branch would deliver it to the requested address for a small charge. The normal DVD loan periodis 48 hours. The member would either return the DVD to the branch in person or request its collection for an additional charge – a service that must be asked for when the rental request is made. The customer also wants the software system to enable members to request an extension to theloan period (bya further 48 hours) after paying an extra charge, but they must be prevented from doing so if they have any DVDs that are overdue, or if the DVD has been reserved by another member. Draw a use case diagram for the proposed system, and identify the constraints or assumptions that you make.

Answer 32

The notion of renting DVDs is very similar to that of lending books, which you saw in Example 1. That is, the two domains are similar, which should help you identify the actors. (We need to take care, of course, that we do not make unjustified assumptions.) A good first step is to establish the context for the proposed system by identifying the actors that surround it. When you have identified the actors, you can investigate the behaviour that each one will expect from the proposed system, which will eventually form the use cases for your model. Working with the analogy to the library case study, the two basic actors are: Member DVDLibrarian The new scheme also suggests that we should identify an actor who delivers and collects DVDs. For the present, we will call this actor a Driver until we can find out more about the requirements. A less obvious actor is the person who wants to become a new member. From the description, we find that potential members must have a credit card, which is a constraint restricting the kind of people who can join. This raises the need for a connection to an external system that can perform credit checks. Thus there are two more actors: CreditCardHolder CreditAgency The library example helps us find a number of appropriate use cases for the DVD chain: Issue copy of DVD Return copy of DVD Reserve DVD Update catalogue Browse stock There is an additional use case that is shared by more than one actor, which we will call join scheme, since it links credit card holders with the CreditAgency authorisation service. We are not well informed about the delivery and collection service of the new scheme, and so that is an area for investigation during analysis. For the moment, we will make the assumption that a driver can carry out two use cases. The two are separated to allow the possibility of making additional charges for the collection of DVDs in the new scheme: Identify DVDs for delivery c identify DVDs for pick-up There are three use cases involved in extending loans: The main use case for members to extend their loan; A variation that refuses loans when a member has items that are overdue; One that checks for existing reservations before allowing a DVD to be rented or reserved. The check reservation appears to be a key component in the proposed software system, since it is associated with four other use cases. You might consider its early implementation within the project. The question only mentioned the refusal of a loan in the case where a member tried to extend a rental. As a developer, it is worth noting that such a requirement may spread to other use cases such as issue copy of DVD and reserve DVD – a point for further analysis. Figure 18 includes such an extension for the issue copy of DVD use case. When each copy is returned to the branch, it is possible that there will be some outstanding charges, especially if members are late in returning their DVDs. The collect charges use case may also have to deal with inconsistent records, which may occur when members keep extending the loan on a particular DVD. The diagram in Figure 18 is one possible use case diagram for the proposed system. You may have used slightly different names on your diagram, and you may have identified alternative use cases to those we have shown. There is no one correct solution; there are many possibilities. You might have tried to share some of the use cases, but this would assume knowledge of the internal structure of the proposed system. You should check that in your use case diagram you have included the behaviour that will bring some discernible value to the actors. For example, as the driver’s job is to ferry DVDs between members’ homes and the local shop, he or she will derive benefit from the computer system by being provided with lists of addresses and the names of DVDs to be fetched or delivered.

Question 33

Who initiates the prototyping process?

Answer 33

The developers would normally start the prototyping process because they have detected or identified a particular problem in their analysis of the requirements for the proposed system. (But note that the project manager would need to get approval from the customer for the additional effort.)

Question 34

Who should test a prototype?

Answer 34

The intended users should test it. For example, if you developed a series of interfaces as part of a prototype for the borrowing and returning of books, the librarians would be the testers.

Question 35

What is the main benefit of identifying the location and availability of user interfaces in your activity diagrams?

Answer 35

The main benefit of recording user (or any other) interfaces in an activity diagram is traceability. To the users, the interface is the software system: an unacceptable interface can lead to failure. The user interface is the link between what the users want and what the developers produce in response. Also, the developer can identify the relative importance of each user interface for the project plan, particularly when resources are needed for a prototype.

Question 36

What does the librarian record in the transaction for the return copy of book use case, which Figure 4 illustrates? Can another member borrow the returned book?

Answer 36

The librarian records that the book has been returned. Although the book is now back it the library, it does not automatically follow that another member can borrow it immediately. The developers will need to explore this detail with the librarians, who understand the business processes of a library in more detail.

Question 37

Suppose the developer built a prototype interface that could deal with all four use cases in the first iteration of the library system. Suggest a criterion that a librarian might use when evaluating the prototype, which goes beyond the completion of the underlying tasks within each use case.

Answer 37

This was the example we thought of, but you may have thought of others. Suppose there is the design constraint that at any given time only a single librarian will be on duty. Then that person will be faced with a queue of library members who may require a range of different services. Librarians will find it essential that in these circumstances the system makes it very easy to switch between different tasks, to meet the varying types of request received. They will expect the prototype to provide evidence that the eventual system will meet this criterion.

Question 38

Draw an activity diagram to show the separate responsibilities of the receptionist and the hotel system for the check in guest use case. Your diagram should contain the main success scenario. You do not need to show any extensions. (See Figure 7 of this unit.)

Answer 38

(see page 55) We can use the textual description of the check in guest use case from Exercise 6 of this unit. Figure 20 shows an activity diagram showing the exchange of information that takes place at the user interface. The receptionist initiates the use case, as shown in the diagram. Some of the activities show the conscious acts that a receptionist needs to undertake in order to make progress in the main success scenario for checking in a guest.

Question 39

Recall the requirements for the nationwide chain of DVD rental shops in Exercise 9. A member can reserve a DVD in advance or request its rental directly,if it is available. In addition, members can extend the period of loan by paying an extra charge, but they must be prevented from doing this if they have any DVDs overdue. (a) Draw an activity diagram for the proposed system to deal with the extension of a loan period. For simplicity, show only the main scenario, and do not use swim lanes for the different actors in your activity diagram. (b) When answering part (a), you will have come across a range of issues that the existing requirements do not cover. These would have to be clarified in discussions with the clients. List some of the issues which you can identify as requiring clarification, and state what points would need to be resolved in each case.

Answer 39

(see page 57) (a) The activity diagram in Figure 21 shows one of the ways of extending the loan period for a DVD. We have shown the basic scenario without adding to the complexity of the activity diagram by looking for the exceptions that can and will arise. Discussions of the extend loan use case with the users should help identify the exceptions and their consequences. (b) From the descriptions in Exercise 9, we are told that members use their credit cards for joining the scheme. As a developer, you would need to clarify the rules for other payments, such as rental charges and the charge for collection by a driver. So a discussion of the extend loan use case with the user might help you understand how the owners of the shops want to collect the charges. For example, is there a request to the Credit Agency actor for each payment, or would you allow certain members to accrue charges in an account? Another point for discussion with the user involves the refuse loan use case, which is associated with the main extend loan use case. It may become a potential component for other use cases since it is a reasonable assumption that new transactions would be refused when a member has outstanding loans. Another question relates to the constraint on the charge for collection. In the original requirements of Exercise 9, this fee had to be paid with the rental. The user could consider whether or not to allow a new collection charge to be included as part of the extend loan use case. Figure 21 shows that the extension to the loan is made on the assumption that fees are paid. The next step should be to consider the relationships between use cases. For example, the initial activity to identify the particular copy of a DVD could also be a component in the browse stock use case. Similarly, the record extension activity shares functionality with the request copy of DVD use case. As part of your analysis, consider which of the activities would be ‘visible’ to the user and which ones would be ‘hidden’. For instance, both the checking activities may be hidden and only become visible when there are any exceptions such as other members waiting for a copy of the DVD.