Object%20Oriented%20System%20Design

1
COS50-3 OOSD
REQUIREMENT MODEL USE CASE DIAGRAM (Week 2)
2
MODELLING
System development is model building

• Complexity -- hard to handle many requirements at
  the same time
• Modelling -- an organised way to handle
  requirements
• Models -- standard representations so that
  everyone can follow
• Various types of models -- for different purposes
  and stages in software development

3
MODELLING (Contd)
Various types of models

• Requirement model
• capture functional/users requirements
• Analysis model
• give the system a robust and changeable structure
• Design model
• adopt and refine the structure to the current
  implementation environment
• Implementation model
• implement the system
• Test model
• verify the system

4
MODELLING (Contd)
Architecture of a modelling language
Model architecture -- a set of modelling
language, notation or modelling technique. It
contains

• Syntax -- how it looks
• Semantics -- what it means
• Pragmatics -- heuristics and rules of thumb for
  using it

5
REQUIREMENT MODEL
What are requirements?

• Statements of a customer/end-users needs and
  expectations
• Descriptions of essential characteristics of the
  customer/end-user,s goal
• Requirements should be problem based and not
  describe the solution

6
USE CASE DIAGRAM
Syntax

• Actor --
• Use case --
• Relationship --
• System border --

7
Rational Rose Use case diagrams
No system border in Rational Rose!
8
USE CASE DIAGRAM (Contd)
Semantics

• An actor represents anything that is outside of
  the system and that needs to exchange information
  with the system.
• -- An individual person (end-user)
• -- A group of people
• -- An individual can play different roles
• -- A machine
• -- ..

9
USE CASE DIAGRAM (Contd)

• A use case represents a special sequence of
  events triggered by an actor.
• Example making an initialisation process
  user-friendly.

10
USE CASE DIAGRAM (Contd)

• Relationship represents information exchange
  between an actor and a use case and between two
  use cases.
• We have different types of relationship existing
  between an actor and a use case and between two
  use cases.
• Ordinary relationship showing that there is a
  relationship between an actor and a use case or
  between two use cases.
• We use symbol to represent this type of
  relationship.

11
USE CASE DIAGRAM (Contd)

• Extend relationship exists between two similar
  use cases where the second one has some extra
  activities, that is the activities of the first
  use case are extended in the second one.
• The first use case sends information to the
  second use case to invoke the extra activities.
• Terms
• -- the first use case base use case,
• -- the second use case extending use case
• -- the information extension point.

12
USE CASE DIAGRAM (Contd)

• Example -- think about an Internet search engine.
  You type in key words and press submit. This
  will trigger a sequence of activities happening
  in a search engine.
• -- If there is no spelling mistake in the key
  words, the search engine will go ahead to search
  for items.
• --If there is a spelling mistake, the search
  engine will ask you to confirm the key word.

13
USE CASE DIAGRAM (Contd)

• Generalisation relationship exists between two
  similar use cases. The base use case includes
  basic activities and the second use case contains
  the alternative activities. Both use cases handle
  the same thing but the base use case deals with
  the general situation and the second one deals
  with special cases.
• Generalisation relationship says that
  alternatives exist.

14
USE CASE DIAGRAM (Contd)

• Example
• -- Suppose in an Internet search engine, we have
  designed two sequences of searching activities
  one sequence of activities is the normal search
  and the other one is intelligent search which is
  for academy.
• -- So we have two use cases corresponding to
  these two sequences of activities one contains
  the normal search activities (called base use
  case) and the other contains the intelligent
  search activities.
• -- Both handle the request of search, but the
  second one deal with special request -- academic
  request.

15
USE CASE DIAGRAM (Contd)

• If two or more use cases have a chunk of same
  activities, we can create a new use case that
  contains this chunk of activities. The relation
  from the original use cases to the new one is the
  Include relationship, which means that the
  original use cases involve the activities of the
  new use case. They share the activities of the
  new use case.
• By having the new use case and the include
  relationship, we can avoid the repeating of the
  same activities in different use cases.

16
USE CASE DIAGRAM (Contd)

• Example
• -- Both the normal and the intelligent search
  engines need to read the key words you typed in.
• -- The activity of reading key words can then be
  picked up from the two use cases and placed into
  a new use case.

17
USE CASE DIAGRAM (Contd)
Pragmatics

• Identify system border -- Which action should be
  taken by actors and which by system? This is
  vital important.
• Identify actor(s) -- What are objects outside
  of the system which want to exchange information
  with the system? Can we classify them?
• Identify use case(s) -- What are the main tasks
  of each actor? An use case should link to a main
  task and contain a complete course of events
  related to the task.
• Add relationship -- We need to pay extra
  attention on those between use cases.

18
CASE STUDY
A recycling machine

• System description The system controls a
  recycling machine for returnable bottles, cans
  and crates. The machine can be used by several
  customers at the same time and each customer can
  return all three types of item on the same
  occasion.

19
CASE STUDY (Contd)
The system has to check, for each item, what type
has been returned. The system will register how
many items each customer returns and when the
customer asks for a receipt, the system will
print out what was deposited , the value of the
returned items and the total return sum that will
be paid to the customer. An operator also uses
the system. He asks for a printout of the total
number of items that have been deposited at the
end of each day. He has right to change the
deposit values of the items through a console.
When anything wrong with the machine, the
operator will be called by a special alarm
signal.
20
CASE STUDY (Contd)

• Identify actors

21
CASE STUDY (Contd)

• Identify use cases

22
CASE STUDY (Contd)
Entire use case model
23
DOCUMENTATION

• Events/activities of each use case must be
  documented.

24
ACTIVITY DIAGRAM

• Activity diagram -- showing the sequence of
  events triggered by an actor and the relationship
  among the events contained in an use case
• Events -- being represented as activity states
  (of an use case) or activity for short.

25
ACTIVITY DIAGRAM (Contd)
Syntax
Activity
Fork
Branch
Join
Merge
26
ACTIVITY DIAGRAM (Contd)
Semantics

• Activity -- event which is the response to a
  stimulus from an actor
• Branch -- conditional selection, only one
  outgoing transition can be taken
• Merge -- the end of conditional behaviour started
  by a branch
• Fork -- the start of parallel operations
• Join -- the end of parallel operations

27
ACTIVITY DIAGRAM (Contd)
Example Recycling machine -- customers return
items
When a customer returns an item to the machine,
the following activities should happen in the
system -- Register the item -- Classify (crate
can bottle) -- Increment item quantity --
Increment item value
28
(No Transcript)
29
Rational Rose activity diagram
30
CASE STUDY
Wessex Fox is a small bus company operating a
number of different routes. Each route has a
unique route number and is divided into a number
of stages. The same stage may occur in several
different routes. For example, both the route
from Southampton to Fawley and the route from
Southampton to Lyndhurst include the stage
Millbrook - Totton. Fares are allocated on the
basis of how many stages a passenger's journey
incorporates. Each route is associated with a
number of scheduled departure times for
particular days of the week and estimated arrival
times. For reasons of safety, no two buses can
depart at exactly the same time. Once a week, a
particular bus and bus driver are allocated to
each departure scheduled for the following week.
This information is only kept during that current
week. The company uses this information to
produce a bus timetable for the use of the
drivers.
31
CASE STUDY (Contd)
Step 1 System border
Wessex Fox
32
CASE STUDY (Contd)
Step 2 Actors -- Drivers, -- Time Table
Makers, -- Manager.
33
CASE STUDY (Contd)

• Step 3 Use case
• Driver request time tables, drive buses, collect
  fares
• Time table maker collect departure times,
  arrival times and information about the
  allocation of bus drivers, generate new time
  tables, delete out of date time tables.
• Manager Allocates buses and drivers.

34
CASE STUDY (Contd)
Time table maker
Driver
Manager
35
Case Study in Rational Rose
36
SUMMARY

• Various models
• Use case diagram
• Activity diagram