Unit 3 - Domain modelling to requirements analysis Flashcards
(a) What are the important properties that a representation of business rules should have?
(b) Consider whether business rules can be modelled in UML; discuss the consequences in the light of the properties in your answer to (a).
(a) 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.
(b) 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.
(a) What causes a transition in an activity diagram?
(b) What is a synchronisation bar, and when is one used in an activity diagram?
(c) 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.
(a) A transition in an activity diagram is caused by the completion of an activity.
(b) 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’).
(c) 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.
(a) How does the partitioning of activities into swim lanes help us understand a set of activities?
(b) Indicate one reason for modelling a workflow in an activity diagram.
(a) Swimlanes group activities associated with different roles. Each swimlane shows who is responsible for which set of related activities.
(b) 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.
(a) Name three aspects of software development where use case modelling can help.
(b) Suggest a reason why use case diagrams are an aid to communication between user and developer.
(a) Any three of the following: capturing and eliciting requirements; representing requirements; planning iterations of development; validating software systems.
(b) 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.
What is the purpose of a system boundary? Is it always necessary to draw one in a use case diagram?
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.
(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 diagram.
(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 (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.
(b) Show interaction with an external system if the use case needs to communicate with the actors that represents the external system.
(a) What is the relationship between a use case and a scenario? Give examples to illustrate your answer.
(b) What is meant by a main success scenario?
(a) 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.
(b) 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.
(a) How do use cases help with requirements capture?
(b) How do use cases help with the elicitation of detailed software requirements?
(c) How do use cases help with development?
(d) How is system validation performed using a use case?
(a) 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.
(b) Detailed software requirements can be associated with each step in a use case scenario.
(c) 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.
(d) 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.
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.)
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 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 reserving books. 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.
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.)
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.
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.
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.
unit3 page33
Table 2 A textual description of the check in guest use case
Identifier and name
UC2 check in guest
Initiator
Receptionist
Goal
A guest takes up a reservation and occupies a room at the desired hotel.
Precondition
There is a reservation for the guest for an available room of the desired type, and the guest can pay for the room.
Postcondition
The guest will have been allocated to a room for the period identified in the reservation, and a bill will have been opened for the duration of the stay.
Assumptions
The guest is already known to the hotel’s software system. The hotel is confident that the guest can pay. For example, the guest has a valid credit card.
Main success scenario
1
The guest provides a reservation number to the receptionist.
2
The receptionist enters the reservation number to find the reservation.
3
The hotel system provides the details of the requested reservation.
4
The receptionist confirms the details of the room type and duration of stay
with the guest.
5
The hotel system allocates a room to the guest.
6
The hotel system opens a bill for the guest. (It could be that there is a
separate billing package, which must be notified upon check in.)
7
The receptionist issues a key to the guest.
What is the purpose of identifying relationships between actors?
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.
(a) What is a stereotype in 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?
(a) A stereotype is a way of attaching extra classifications to a model. Stereotypes can be user-defined; this is a way of extending UML.
(b) 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.
(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 to specify when the variant behaviour will be included. This could be done with either a note or an extension point.
(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 they will not be understood by everyone.
(e) 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.
(a) 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?
(b) What problems may arise when developing a software system from a set of use cases?
(a) 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.
(b) 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.
What are the tasks involved in preparing a use case diagram for a moderately large system, intended for the development team?
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.
