Block V

Software Development:
Modelling a System
 Chapter 31
An overview of software
development
Software Development Activities
 Requirements Analysis

 Design

 Implementation

 Testing
OO Software Development
Activities
 Producing a negotiated statement of
requirements.

 Developing a structural model.

 Developing a dynamic model.

 Communicating with the user

 Detailed design and implementation.

Structural and Dynamic Models
 A structural model describes the static
aspects of a system, required in order to
enable the behaviour of the system to be
carried out.

 The purpose of a dynamic model is to

represent some part of the behaviour of a
system over time. In M206, dynamic
models are presented in the form of walk-
throughs and sequence diagrams.
Defining the problem
Problem Description
A Computer system is required for a small video lending
library. At any time the system should be able to list what
videos any member currently has on loan and to be able
to indicate how many copies of any film are not on loan.

This is called Statement of Requirements.

Requirements Analysis
 The process of analysing the initial
statement of requirements in consultation
with the client is known as requirements
analysis.

 The aim of the requirements analysis is to

reach an agreed and unambiguous
specification called the negotiated
statement of requirements (NSR).
Requirements Analysis
 NSR often forms the basis of a contract
between the client and the developer so it
is important to get it right.

 Partial systems that are used to test and

confirm ideas about what the system is
required to do are known as prototype
systems
NSR for the Video Library System
Problem Description
A Computer system is required for a small video lending
library. At any time the system should be able to list what
videos any member currently has on loan and to be able
to indicate how many copies of any film are not on loan.

Try to analyse this statement of

requirements.
NSR for the Video Library System
An NSR can be as follows:
 The library holds video copies of a number
of films. It may have one or more copies
of each film. The system should, for each
film, hold the film’s title; no two films
have the same title.

 A library member can borrow any video

copy of a film that is not currently on loan.
However, no member can have more than
two copies on loan at a time.
NSR for the Video Library System
 Each copy has a unique identifying
number.

 Each member of the library has a unique

membership number; the system also
holds each member’s name.
NSR for the Video Library System
 The system that has to be designed must
be able to do the following:

 for any film, give the number of copies

of that film that are currently available
for loan;
 for any member, list all the films that
the member currently has copies of on
loan;
 update the system whenever a copy is
borrowed or returned.
Constructing an Initial Structural
Model
 When developing a structural model we
are concerned with the static aspects of
the system.

 This stage deals with how we can make a

sensible choice of classes and attributes to
help solve our problem.
Constructing an Initial Structural
Model
 In this stage, NSR is used to try to identify
and categorize what real-world entities
may need to be modeled in the system.

 The NSR and our understanding of the

real-world context can be used to identify
what properties can be used to identify
what properties we might expect these
entities to have.
Constructing an Initial Structural
Model
 For the video lending library, there are
three distinct types of ‘knowledge’
involved in the specification:

 films, copies, members;

 film titles, copy numbers, member
names, member numbers;
 which members have which copies on
loan, which film a copy is a copy of
(i.e. the possible links between the
entities)
Class Diagram

h a s On Lo a n i s Co py Of
Me mb e r Co p y Fi l m

Classes and associations

h a s On Lo a n i s Co py Of
Me mb e r Co p y Fi l m
0. . 1 0. . 2 1. . * 1

Multiplicities
Object Diagram
c opy3 :
Copy
me mbe r 1 :
Me mbe r f i l m1 : Fi l m
c opy1 :
Copy
me mbe r 2 :
Me mbe r
c opy2 :
Copy
me mbe r 3 :
Me mbe r f i l m2 : Fi l m
c opy4 :
Copy

 Objects and links

Initial Structural Model
 Initial structural model consists of class
diagram + class description

 Initial structural model should be easy to

understand for both client and potential
system users.
Initial Structural Model
h a s On Lo a n i s Co py Of
Me mb e r Co p y Fi l m
0. . 1 0. . 2 1. . * 1

Class: Member
Attributes:
name "The name of the member"
memberNo "The unique membership number of the member"
Class: Copy
Attributes:
copyNo "The unique identifying number of the copy"
Class: Film
Attributes:
title "The unique title of the film"
Constructing Dynamic Models
 This stage is about analysing the
behaviour.

 What behaviour is the system supposed to

have; what is it supposed to do?
Constructing Dynamic Models
 From the previous NSR we can identify
four distinct behaviours, or use cases :

 Give the number of available copies of a

film.
 Give a list of the films that a member
has copies of on loan.
 Record that a member borrows a copy.
 Record that a copy is returned.
The Use Cases
 Get Number Available: give the number of
available copies of a film.

 List Films: give a list of the films that a

member has copies of on loan.

 Borrow: record that a member borrows a

copy.

 Return: record that a copy is returned

Constructing Dynamic Models
 A user interface is the means by which the
domain model communicates with the real
world.
 However, the domain model cannot be
completely independent from the user
interface since the two will need to
communicate.
 We have to introduce an extra object to
the domain model called the
orchestrating instance.
Communication with the user interface
 Orchestrating instance is used to represent
the user interface. In our example we
consider the LibAdmin.
 The developer has to find the associations
between the user interface and the classes of
the system. For our example, possible
associations are:
 Use titles to keep track of instances of Film linked
via films. Result: the number of copies available
 Use membership numbers to keep track of
instances of Member linked via members. Result:
the relevant film titles
Communication with the user interface
Walk-through
 A walk-through takes a single piece of
coherent behaviour (a use case or part of
a use case) and describes what this
involves in terms of the domain model by
splitting it into simpler steps.
Final Structural Model
Sequence Diagrams
 Sequence diagrams are used to explore
and show the sequences of messages that
are passed between objects in the domain
model in order to carry out a use case or
part of a use case.
Sequence Diagrams
a d mi n a Fi l m

nu mb e r Av a i l a b l e ( a Ti t l e )
1
g e t Numb e r Ava i l a b l e

a Nu mbe r

This sequence diagram is for the GetNumaber walk-

through
Communicating with the User
 The benefit of using the orchestrating
instance is that the rest of the domain
model will not be affected by changes
made to the user interface and vice versa.

 The actual development of user interfaces

requires consultation with the client.
Detailed Design and Implementation
 Which existing classes could be used in
our solution?

 Could we make use of inheritance and

introduce extra classes to give a more
logical structure?

 What programming constructs can be used

to implement the various responsibilities
that we have identified for each class?
 Chapter 33
Constructing an Initial
Structural Model
Identifying classes and attributes
 To identify the classes using the NSR do
the following:

Identify the things that play a significant

part in the application area

 one aid to identifying classes is to identify

nouns or noun phrases in the NSR.
The Video Library System
Negotiated statement of requirements
The libra ry holds vide o copie s of a numbe r of films . It
ma y ha ve one or more copie s of e a ch film. The s ys te m
s hould, for e a ch film, hold the film’s title ; no two films
ha ve the s a me title .
A libra ry me mbe r ca n borrow a ny vide o copy of a film
tha t is not curre ntly on loa n. Howe ve r, no me mbe r ca n
ha ve more tha n two copie s on loa n a t a time . Whe n a
libra ry me mbe r re turns a copy it imme dia te ly be come s
a va ila ble for loa n.
Ea ch copy ha s a unique ide ntifying numbe r.
Ea ch me mbe r of the libra ry has a unique me mbe rs hip
numbe r; the s ys te m a ls o holds e a ch me mbe r’s na me .
The Video Library System
Negotiated statement of requirements
The s ys te m tha t ha s to be de signe d mus t be a ble to do
the following:
> for a ny film, give the numbe r of copie s of tha t film tha t
a re curre ntly a va ila ble for loa n;
> for a ny me mbe r, lis t a ll the films tha t tha t me mbe r
curre ntly ha s copie s of on loa n;
> upda te the s ys te m whe ne ve r a copy is borrowe d or
re turned.
The Video Library System
Negotiated statement of requirements
The libra ry holds vide o copie s of a numbe r of films . It
ma y ha ve one or more copie s of e a ch film. The s ys te m
s hould, for e a ch film, hold the film’s title ; no two films
ha ve the s a me title .
A libra ry me mbe r ca n borrow a ny vide o copy of a film
tha t is not curre ntly on loa n. Howe ve r, no me mbe r ca n
ha ve more tha n two copie s on loa n a t a time . Whe n a
libra ry me mbe r re turns a copy it imme dia te ly be come s
a va ila ble for loa n.
Ea ch copy ha s a unique ide ntifying numbe r.
Ea ch me mbe r of the libra ry has a unique me mbe rs hip
numbe r; the s ys te m a ls o holds e a ch me mbe r’s na me .
The Video Library System
Negotiated statement of requirements
The s ys te m tha t ha s to be de signe d mus t be a ble to do
the following:
> for a ny film, give the numbe r of copie s of tha t film tha t
a re curre ntly a va ila ble for loa n;
> for a ny me mbe r, lis t a ll the films tha t tha t me mbe r
curre ntly ha s copie s of on loa n;
> upda te the s ys te m whe ne ve r a copy is borrowe d or
re turned.
Guidelines for rejection
 Things that are attributes.

 Things that refer to a behaviour of the

system.

 Things that are outside the scope of the

system.

 Things that refer to an aspect of the user

interface.
Guidelines for rejection
 word or phrase that is used in talking
about the system that is to be developed
rather than a reference to something in
the application area

 Things that refer to links between other

objects in the system
Kinds of classes
 tangible objects

 roles

 events

 organizational units
Hospital Admission and Treatment System
The statement of requirements
This part of the system is concerned with the admission,
treatment and discharge of patients. When a patient is
admitted to the hospital, he or she is placed in the care of a
team of doctors. Each team is headed by a consultant doctor
who is responsible for the patients assigned to that team. A
record has to be kept of the doctors in a team who have
actually treated the patient while in hospital.
Hospital Admission and Treatment System
The statement of requirements
The system should be able to:
 record the admission of a patient to the hospital;

 give a list of the doctors who have treated a patient;

 give a list of the patients that a team cares for together

with the ward that each patient is in;

 process the discharge of a patient from the hospital.
Hospital Admission and Treatment System
The statement of requirements
This part of the system is concerned with the admission,
treatment and discharge of patients. When a patient is
admitted to the hospital, he or she is placed in the care of a
team of doctors. Each team is headed by a consultant doctor
who is responsible for the patients assigned to that team. A
record has to be kept of the doctors in a team who have
actually treated the patient while in hospital.
Hospital Admission and Treatment System
The statement of requirements
The system should be able to:
 record the admission of a patient to the hospital;

 give a list of the doctors who have treated a patient;

 give a list of the patients that a team cares for together

with the ward that each patient is in;

 process the discharge of a patient from the hospital.
Classes
 Ward
 Patient
 ConsultantDoctor
 JuniorDoctor
 Doctor
 Team
Class description
Class: Ward
Attributes:
name "The unique name of the ward"
Class: Patient
Attributes:
name "The name of the patient"
address "The address of the patient"
dob "The date of birth of the patient"
Class: ConsultantDoctor
Attributes:
name "The name of the consultant doctor"
address "The address of the consultant doctor"
Class description
Class: JuniorDoctor
Attributes:
name "The name of the junior doctor"
address "The address of the junior doctor"
grade "The grade (1,2 or 3) of the junior doctor"
Class: Doctor
Attributes:
name "The name of the doctor"
address "The address of the doctor"
Class: Team
Attributes:
code "The unique code of the team"
Generalisation relationships
 A generalization relationship can be used
to represent both the similarity and
difference between related classes
Abstract classes
The Candidate Classes
Associations
 An association between classes represents
the existence of a significant category of
links between some of their respective
instances.
 The association relationship is represented
in a class diagram using a link with a label
that indicates the relationship between the
connected classes. To show the direction
of the association we use solid arrowhead
Associations
Identifying associations
 The grammatical structures that connect
the nouns and noun phrases (used in
finding the classes) in the text of an NSR
can suggest likely associations.

 You should identify verbs, verb phrases or

prepositional phrases
The Video Library System
Negotiated statement of requirements
The libra ry holds vide o c o pie s of a numbe r of films . It
ma y ha ve one or more c opie s of e a ch film. The s ys te m
s hould, for e a ch film, hold the film’s title ; no two films
ha ve the s a me title .
A library me mbe r ca n borrow a ny vide o c o py of a film
tha t is not curre ntly on loa n. Howe ve r, no me mbe r ca n
ha ve more tha n two c o pie s on loa n a t a time . Whe n a
library me mbe r re turns a c o py it imme dia te ly be come s
a va ila ble for loa n.
Ea ch c o py ha s a unique ide ntifying numbe r.
Ea ch me mbe r o f the library ha s a unique me mbe rs hip
numbe r; the s ys te m a ls o holds e a ch me mbe r’s na me .
The Video Library System
Negotiated statement of requirements
The s ys te m tha t ha s to be de signe d mus t be a ble to do
the following:
> for a ny film, give the numbe r of c o pie s of tha t film
tha t a re curre ntly a va ila ble for loa n;
> for a ny me mbe r, lis t a ll the films tha t tha t me mbe r
curre ntly ha s c o pie s of on loa n;
> upda te the s ys te m whe ne ve r a c o py is borrowe d or
re turned.
Hospital Admission and Treatment System
 Conduct a textual analysis of the
negotiated statement of requirements for
the hospital admission and treatment
system in order to identify candidate
associations.
Class Diagram
Class Diagram showing
multiplicities
 Chapter 37
Constructing Dynamic Models
Identifying use cases
 We can identify the use cases from the
NSR parts that contain information about
the required behaviour of the system;
what the system is required to do.
Hospital Admission & Treatment
System
 Try to identify the use cases from the
negotiated statement of requirements
(NSR).
Hospital Admission & Treatment
System
 The use cases:

A List Patient’s Treatment

B List Team’s Patients
C Admit Patient
D Treat Patient
E Discharge Patient
Hospital Admission & Treatment
System
 Use case: A List Patient’s Treatment.
 Given: A patient (identified by ward name
and patient name).
 Goal: The following have to be returned:
 the team code of the team that cares for the
patient;
 the name of the consultant doctor responsible
for the patient;
 the names of the doctors who have treated the
patient.
Hospital Admission & Treatment
System
 B List Team’s Patients
 Given: A team (identified by team code).
 Goal: The following have to be returned:
 for each patient that the team cares for, the
name and date of birth of the
 patient and the name of the ward the patient is
on.
Hospital Admission & Treatment
System
 C Admit Patient
 Given: A patient name, address and date
of birth, a ward (identified by ward name)
and a team (identified by team code).
There should not be a patient with the
given patient name already on the ward.
 Goal: The system has to record that there
is a patient with the given name, address
and date of birth on the given ward and
under the care of the given team.
Hospital Admission & Treatment
System
 D Treat Patient
 Given: A patient (identified by patient
name and ward name) and a doctor
(identified by doctor name and team
code). The doctor should be in the team
that cares for the patient.
 Goal: The system has to record that the
doctor has treated the patient.
Hospital Admission & Treatment
System
 E Discharge Patient
 Given: A patient (identified by ward name
and patient name).
 Goal: All information relating to the
patient has to be removed from the
system.
Hospital Admission & Treatment System
Communication with the user interface
 We need an orchestrating class and
instance and we need to consider what is
needed for successful translation between
user interface data and domain model
objects.
Communication with the user interface
 We have two aims:

 To identify the associations (and the

navigation) required to locate the objects
identified by data from the user interface.

 To identify the objects (if any) that the main

part of the use case requires to return so that
the orchestrating instance can extract from
their attributes the data to be returned to the
user interface.
Communication with the user interface
Hospital Admission & Treatment
System
Walk-throughs
We have to construct a walk-through for
each use case in sufficient detail to specify
what has to be done in terms of the
domain model, and to identify all the steps
that require objects to be located.
Walk-throughs
These steps allow us to determine the
navigational usage of the associations,
and to allocate the association
responsibilities to the appropriate classes.

When constructing walk-throughs, care has

to be taken to check that any conditions
on the given objects are satisfied, and that
any relevant invariants still hold at the end
of the use case.
Sequence Diagrams
 A sequence diagram can be used to
represent an appropriate sequence of
messages passed between objects in order
to carry out the steps of a walk-through.
Sequence Diagrams
Sequence Diagrams