object oriented software development 2009-2010 modelling information systems oosad booklet chapter 3...
Post on 20-Dec-2015
216 views
TRANSCRIPT
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?
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
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