Unit 3 - From domain modelling to requirements

Question 1

What is the function of business rules?

Answer 1

They constrain how a business is run

Question 2

From a typical business description, what should we be able to identify?

Answer 2

Business processes in the domain and business rules (constraints)

Question 3

Verification is?

Answer 3

The set of activities that ensure that a solution is being

correctly developed, i.e. that it is taking into account the business rules.

Question 4

Validation ensures?

Answer 4

That what is being built satisfies the business, i.e. that

the business rules implemented are the ones that the business wants

Question 5

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

Answer 5

The important properties are as follows:

◦ Business rules that apply to the whole business should be represented separately from project specific models.

◦ They should be easy to verify (possibly automatically) and validate.

◦ They should be represented in a readable language that is easy to verify.

Question 6

Business processes define?

Answer 6

What is done in a business, by whom, in what

order, needing which resources, and with what consequences

Question 7

How do you represent business processes?

Answer 7

With UML activity diagrams.

An activity diagram shows a process as a set of activities and describes how they must be coordinated – which ones depend on others having been completed first and where activities can be carried out in parallel

Question 8

For a process of making a hot drink, we need to boil water in a kettle. What are the two steps involved in this task?

Answer 8

1. Fill Kettle

2. Boil Water

Question 9

What are the basic elements of an activity diagram?

Answer 9

Activities and Transitions.

Activities are shown as rounded boxes and Transitions are shown as lines with arrows.

There are two predefined activities, start and stop, which are represented as filled circles

Question 10

UML decision nodes allow what?

Answer 10

To represent alternative mutually exclusive, ways out of an activity. A decision node is drawn as a diamond.

Question 11

The flow out of decision nodes are constrained with Boolean tests, known as?

Answer 11

The Boolean tests are known as Guards, written inside square brackets.

Each of the transitions leaving the first decision diamond has a guard to determine which path should be taken under a given condition

Question 12

A diamond shape in an Activity diagram can also be used as a?

Answer 12

Merge node, which brings together alternative mutually exclusive flows.

A merge node will be reached only by one of the alternative flows and has a single outgoing flow.

Question 13

What causes a transition in an activity diagram?

Answer 13

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

Question 14

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

Answer 14

A synchronisation bar is used to mark the point when two or more activities can take place concurrently (a fork) or when a number of concurrent tasks must finish before continuing to the next activity (a join).

Question 15

An activity diagram can be used to represent what?

Answer 15

The workflow of an existing process.

It represents the sequence of activities and helps identify the stages at which each role requires some interaction with the process.

This is of particular benefit when we want to investigate the steps that people – and any existing systems – take in order to do their jobs.

When modelling a workflow that involves more than one role, it is possible to identify which role is responsible for a particular activity. To do this in UML, we partition an activity diagram into swimlanes – one swimlane for each role

Question 16

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

Answer 16

Swimlanes group activities associated with different roles. The swimlanes show the role that is responsible for each activity.

Question 17

Give one reason for modelling a workflow in an activity diagram?

Answer 17

Activity diagrams represent the sequence of activities. 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. An activity diagram can help identify the stages at which each role
requires some interaction with the process.

Question 18

What are the main elements in a Use Case diagram?

Answer 18

The main elements in a diagram are:

. the actors, represented by stick figures

. the use cases, represented by ovals

. the relationships between actors and use cases – their associations – represented by lines.

Question 19

Name two aspects of software development where use case modelling can help

Answer 19

Eliciting requirements - representing requirements.

Planning iterations of development and validating software systems.

Question 20

Suggest a reason why use case diagrams are an aid to

communication between user and developer

Answer 20

Use cases offer users an opportunity to understand the system since the use case notation is relatively simple and doesn’t require an understanding of UML.

This provides a mechanism that enables developer and client to share a common understanding of the system,
as long as the developer provides some text to demonstrate their understanding of the problem.

Question 21

How do you represent a system boundary in a use case diagram?

Answer 21

By drawing a solid box around the use cases with actors located outside it, represents the system boundary and all we are interested in.

Question 22

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

Answer 22

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 23

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

Answer 23

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.

Actors can also represent other systems, rather than people/roles.

Question 24

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 24

One possible guideline would be to show interaction with an external system if the use case needs to communicate with the actors that represent the external system.

Question 25

Are roles in business process models the same as actors in use cases?

Answer 25

Roles in business process models may not correspond directly to actors in use cases as although they interact with a business process they may not interact with a proposed system.

Question 26

What is a precondition?

Answer 26

A condition that must hold true before a specific task is called to action.

Question 27

What is a postcondition?

Answer 27

A condition that will hold true after a specific task has completed.

Question 28

What is a scenario?

Answer 28

A scenario illustrates one particular way a use case can unfold, by the sequence of interactions the actors have with the system.

For each use case, we normally start by considering a main scenario in which the goal of the use case is successfully achieved.

Question 29

What is the relationship between a use case and a scenario?

Answer 29

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 they have no outstanding loans.

Another member wishes to borrow a book, but
has exceeded the quota for the number of books that can be borrowed. 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 30

What is meant by a main success scenario?

Answer 30

The main success scenario shows the steps normally followed to achieve the stated goal of the use case

Question 31

How do use cases help with:

(a) requirements capture
(b) the elicitation of detailed software requirements
(c) development
(d) the system’s architecture
(e) system validation (checking that the system actually supports the functionality required by the users)?

Answer 31

(a) Use cases help with requirements capture through 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.

(b) Detailed software requirements can be associated with each step in a use case scenario. There may be more than one requirement for each step.

(c) One of the difficulties that developers face is planning delivery times. Often a customer can put pressure on the developer to meet a particular deadline. It is part of the developer’s job to elicit from the users the use cases that have the highest priority and to indicate what functionality in the software system can be met under such constraints. The use case descriptions help the developer to:
◦ understand the complexity of each use case
◦ determine which actors interact with each use case and to what extent
◦ establish which use cases carry the most risk
◦ estimate 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) Use cases, as standalone chunks of system specification, dictate the sorts of functionality that need to be provided by the system and constitute an aid for identifying interfaces in an architecture. Use cases can also be grouped in terms of similar functionality, therefore influencing the architecture of the system. Scenarios can be used to check how an architecture meets non-functional requirements, in particular those that can be affected by the architecture, such as security and safety requirements.
(e) One way to validate a system is to use the walk-through technique, checking the functionality related to each use case in turn. The walkthrough 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 32

What is the purpose of identifying relationships between actors?

Answer 32

The purpose of identifying relationships between actors is to indicate generalisations and establish which use cases can be performed by which actors.

For example, a Receptionist can do the same things that a Reserver can, but may be able to do something else that a Reserver cannot, in this case check in guest and check out guest.

Question 33

What is a stereotype in UML?

Answer 33

A stereotype is a way of attaching extra classifications to a model adding to its basic language. Stereotypes can be user defined – this is a way of extending UML.

Question 34

What is the meaning of the «include» stereotype?

Answer 34

The «include» stereotype indicates a situation where a use case is reused. An example would be a ‘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 (base) use case.

Question 35

What is the meaning of the «extend» stereotype?

Answer 35

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

Question 36

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

Answer 36

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 37

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

Answer 37

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 38

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

Answer 38

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 use cases may cause the developer 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 the developer 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.

Question 39

What are the tasks involved in preparing a use case model intended for the development team?

Answer 39

The tasks comprise:

. defining the context for the model by identifying the actors involved in the aspect of the system in question

. analysing the behaviour that each actor expects from the proposed system, and identifying the use cases (as units of functionality within the overall requirements)

. identifying the common behaviour that may be reused by other actors, and the variations on common behaviour (the stereotypes «include» and «extend»)

. drawing a model that shows the use cases, the actors and the relationships between them

. annotating the use cases as you learn more about the requirements.

Question 40

Who initiates the prototyping process?

Answer 40

The developers would normally start the prototyping process because they have detected or identified a particular problem in their requirements analysis.

Question 41

Who should test a prototype?

Answer 41

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 library members would be the testers

Question 42

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

Answer 42

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 developer produces in response.