Unit 3

Question 1

What are Business Rules?

Answer 1

Business rules constrain how a business is run. Understanding the business rules is key to modelling the business and to specifying how any system to be developed can support the correct functioning of the business processes. There is a clear distinction between the business processes and the constraints imposed on them.

For example, in a car rental company, renting a car is one of the processes of the business; one business rule that may apply to this process is that the car allocated is the lowestmileage car that is available in the chosen group.

Question 2

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

Answer 2

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 3

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

• 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.

Answer 3

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 4

What causes a transition in an activity diagram?

Answer 4

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

Question 5

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

Answer 5

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 6

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 6

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 thejoining 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 7

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

Answer 7

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

Question 8

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

Answer 8

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 9

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

Answer 9

Any three of the following:

• capturing and eliciting requirements;
• representing requirements;
• planning iterations of development;
• validating software systems.

Question 10

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

Answer 10

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 11

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

Answer 11

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 12

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

Answer 12

An actor in a use case diagram represents a particular role that an individualmight 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 13

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 13

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

Question 14

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

Answer 14

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 15

What is meant by a main success scenario?

Answer 15

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 16

How do use cases help with requirements capture?

Answer 16

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 17

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

Answer 17

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

Question 18

How do use cases help with development?

Answer 18

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 cases should 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 19

How is system validation performed using a use case?

Answer 19

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 bythe 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 20

What is the purpose of identifying relationships between actors?

Answer 20

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 21

What is a stereotype in UML?

Answer 21

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 22

What is the function of the «include» stereotype?

Answer 22

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 23

What is the function of the «extend» stereotype?

Answer 23

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 24

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

Answer 24

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 25

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 25

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 26

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

Answer 26

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 27

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

Answer 27

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 28

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

Answer 28

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 29

Who initiates the prototyping process?

Answer 29

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 30

Who should test a prototype?

Answer 30

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 31

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

Answer 31

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.

Question 32

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 32

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 33

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 33

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.