Object Oriented Software

Development2009-2010

Modelling information systemsOOSAD Booklet Chapter 3

Lecture: Week 2Brian Farrimond

2

Objectives At the end of this session you should be

able to: Explain some difficulties in requirements

analysis Describe in outline some strategies for

obtaining requirements Explain the purpose of the following UML

models in the process: Use Case Class Association Diagram Sequence Diagram

3

System RequirementsThe Requirements specification must provide sufficient information to enable the system to

be constructed “successfully.”

• Functional requirements• What the system must do (tasks)

• Non-Functional Requirements• Eg constraints, such as hardware to be

used,• Eg interface, documentation, training,

management standards to be used.

4

The Difficulty with Requirements System Requirements are normally

written in English According to the Oxford English

Dictionary, the 500 words used most in the English language each have an average of 23 different meanings.

5

Examples:

Anti-nuclear protestors released live cockroaches inside the White House

Friday, and these were arrested when they left and blocked a security gate.

The Duchess handled the launching beautifully, confidently smashing the champagne against the prow. The crowd cheered as she majestically slid down the greasy runway into the sea.

6

What’s wrong with these? “The system shall list all the details of the

members”. Instructions to make tea

Fill kettle with water Put tea bag in cup Pour water from kettle into cup Add milk Drink

7

From a British Airways Memorandum, quoted in Pilot Magazine, December 1996:

The Landing Pilot is the Non-Handling Pilot until the decision altitude call, when the Handling Non-Landing Pilot hands the handling to the Non-Handling Landing Pilot, unless the latter "calls go around," in which case the Handling Non-Landing Pilot continues handling and the Non-Handling Landing Pilot continues non-handling until the next call of "land" or "go around" as appropriate.

In view of recent confusions over these rules, it was deemed necessary to restate them clearly.

8

Requirements should be .. Complete Unambiguous Correct ( does what the user

wants) …. Whatever that is.

9

A checklist for fuzzy requirements

1. Incomplete lists ending with "etc.," "and/or," and "TBD.“

2. Vague words and phrases such as "generally," "normally," "to the greatest extent," and "where practicable.“

3. Imprecise verbs such as "supported," "handled," "processed," or "rejected.“

1988, the MITRE Corporation, prepared a checklist for the U.S. Air Force:

10

A checklist for fuzzy requirements

4. Implied certainty, flagged by words such as "always," "never," "all," or "every.“

5. Passive voice, such as "the counter is set." (By whom or what?)

6. Every pronoun, particularly "it" or "its." Each should have an explicit and unmistakable reference.

7. Comparatives, such as "earliest," "latest," "highest." Words ending in "or" or "est" should be suspect.

1988, the MITRE Corporation, prepared a checklist for the U.S. Air Force:

11

A checklist for fuzzy requirements

8. Words and phrases whose meaning can be disputed between developer and customer, such as instantaneous, simultaneous, achievable, minimum,

9. Contractually troublesome phrases: a. "Design goal." The developer will spend money and

other resources with no guarantee of goal accomplishment.

b. "To the extent practicable." A decision in the eyes of the developer.

c. "Where applicable." There are no criteria for judgment.

d. "Shall be considered." The developer will think about.

e. "A minimum of X." The developer will provide exactly X.

1988, the MITRE Corporation, prepared a checklist for the U.S. Air Force:

12

Gathering requirements – How?

Background Reading

Interviewing

Observation

Document Sampling

Questionnaires

13

Your Coursework You will eventually need to Think

about how this applies to your feasibility study (Coursework 3)

14

Modelling for Clarity Models represent the key features

An abstraction of reality The meaning of the model elements and

rules for combining must be understood and clear Unambiguous syntax and semantics

Used to communicate with Developers, Clients, (and any passing aliens)

15

Example – Mountain bike hire companyExtract from Statement of Requirements

“ Only members can hire bikes. A member can reserve bikes in advance (the system records details of the bike, member, date and time reserved).”

“Leaders (who must be members) take groups of members on particular rides. A leader has to hold a leadership certificate. ”

“Members can ride by themselves or can book specific rides”

16

Use Case Modelling This shows the tasks and what or

who will initiate them. What tasks can you identify?

17

Use Case

Member

Leader

Lead Ride

Reserve Bike

Book Ride

Static Model

18

Class Modelling The system is composed of objects that

communicate to perform the system’s tasks.

Objects represent real-world things, events or roles (e.g. a particular member or bike)

Objects have Attributes and Behaviour A Class is a template for objects of the

same type (eg Bike is a Class)

19

Class Association Model A Class-

Association Diagram shows the structure of the system: eg

Member

Leader Ride

1 *

leads

Reservation

Bike

1

4

makes

*

1

for

* *

books

20

Member

Leader Ride

1 *

leads

Reservation

Bike

1

4

makes

*

1

for

* *

books

ClassAssociatio

n

Generalisation

21

Generalisation A Leader is-a-kind-of Member Therefore

The Leader Inherits all the characteristics of a Member and adds extra (specialised) behaviour or attributes

Member is a generalisation of leader

Leader is a specialisation (or Sub-class) of Member

Member

Leader

22

Association

Leader Ride

1 *

leads

A Ride is led by 1 Leader

A Leader Leads many Rides

23

How many reservations can a member make?

Member

Leader Ride

1 *

leads

Reservation

Bike

1

4

makes

*

1

for

* *

books

24

Dynamic Models Use Case and Class diagrams do not show

how a system behaves over Time Dynamic models can show this UML has several Dynamic models, you

will only meet Sequence Diagrams on this course.

These show details of how a Use Case is implemented, corresponding to program code.

25

A Possible Book Bike Ride Use Case

aRide: : RideaMember : MemberaUser

Book(aRide)()

books()

()

()

Tim

e

Object

Message

26

Summary Systems are complex, Models help to

represent key features clearly and reduce ambiguity.

Requirements should be Unambiguous Complete Correct

Use Case models show tasks Class Diagram models show structure Sequence Diagram models show

behaviour of a single use case over time.