Object Oriented System Design

1
COS50-3 OOSD
INTRODUCTION TO OOSD (Week 1)
2
AIMS AND OBJECTIVES

• To understand the software development process,
  including requirement specification, analysis,
  design, implementation and testing.
• To acquire various methodologies in software
  development,
• To understand the process of modelling real world
  problems and systems using UML,
• To develop skills on object oriented software
  development.

3
EXPECTION AND EXAM

• Design solutions to complex problems
• Evaluate the significance of the object oriented
  paradigm in the production of complex software
• Appraise current and future technologies in their
  industrial context.
• Assignments and Exam
• -- Assignments 50
• -- Final exam (QuestionMark) 50

4
TEACHING SCHEDULE

• Introduction outline OOSD, including the
  general process of software development, basic
  methodologies, preliminary on UML and Rational
  Rose.
• Use cases a useful tool for capturing
  requirements basic concepts of a use case,
  reasons for using use cases and how to apply it
  to capture user requirements.
• Analysis modelling management of a software
  process, analysis models, sequence diagram and
  CRC card.
• OO designing function oriented design, object
  oriented design and comparison, class diagram and
  statechart diagram
• Software patterns

5
GOOD BOOKS

• Object-Oriented Software Engineering -- a use
  case driven approach (revised edition) by Ivar
  Jacobson
• UML Distilled (2nd Edition) by Martin Fowler
• Software Engineering (4th Edition) by Ian
  Sommerville
• Developing Applications with Java and UML by Paul
  R and Reed Jr
• An Introduction of Object Oriented Programming
  with Java (2nd Edition) by C Thomas Wu

6
SOFTWARE PROCESS

• A software Process not just coding
• London Ambulance Service (LAS) -- a true disaster
  of software engineering.

• -- Time from early 1980s to 1992,
• -- Total cost 7.5 million,
• -- Result abandoned

7
SOFTWARE PROCESS (Contd)

• LAS manual system

?
? ?
??
8
SOFTWARE PROCESS (Contd)
LAS required system
? ?
? ?
Auto Call Distributor
? ?
9
SOFTWARE PROCESS (Contd)

• Things went wrong from very beginning
• -- End-user hostility -- lack of consultation,
• -- Official project issue report process was not
  followed,
• -- Problems were left in later stages, ignored
  and programmed,
• -- Hidden and newly introduced bugs,
• -- Test team had no knowledge about changes.
• Lessons was taught
• -- Software development is like other
  engineering processes,
• -- The process must be strictly followed.

10
METHODOLOGIES

• Waterfall approach -- requirement, design, coding
  and test stages, one after another,
• Exploratory programming -- working system plus
  improvement,
• Prototyping -- establishing system requirements
  plus re-implementation,
• Formal transformation -- transforming
  specifications into program,
• System assembly from reusable components .

11
WHATERFALL MODEL
12
WHATERFALL MODEL (Contd)

• Requirement specification -- collecting and
  understanding clients requirements.
• Analysis -- establishing systems services,
  constraints and goals by consultation with
  systems users.
• Design -- establishing an overall system
  architecture, including program units and
  interface between those units,
• Implementation -- realising programs or program
  units and verifying that each unit meets its
  specification,

13
WHATERFALL MODEL (Contd)

• integration -- integrating the individual program
  units are testing as a complete system to ensure
  the the system satisfy users requirements.
• Testing -- verification (Does the system work
  right?) and validation (Do we build up a right
  system?).

14
WHATERFALL MODEL (Contd)
15
CRISIS ARE STILL WITH US

• 31 of project will get cancelled before they
  ever get complete
• 88 of all projects are over schedule, over
  budget or both
• for every 100 projects started, there are 94
  restarts
• Average cost overun is 189 of original estimate
• Average time overun is 222 of original estimate

16
CRISIS ARE STILL WITH US

• Causes
• -- Incomplete requirements -- 13
• -- Lack of user involvement -- 12.4
• -- Lack of resources -- 10.6
• -- Unreasonable expectations -- 9.9
• -- No management support -- 9.3
• -- Specification changes -- 8.7
• -- Lack of planning -- 8.1
• -- No longer needed -- 7.5
• Reason and solution
• -- Methodologies are difficult to follow
• -- Modelling language for implement the methods

17
INTRODUCTION TO UML

• UML -- Unified Modelling Language
• It would help us (software engineers) to
  modelling real world problems and systems, e.g.
• -- Use Cases to capture requirements
• -- Analysis modelling to establish system
  specifications
• -- Design modelling to design a system
• -- Package large systems management

18
INTRODUCTION TO UML

• It allows implementation-independent
  specification of
• -- user/system interactions (required behaviors)
• -- partitioning of responsibility (OO)
• -- integration with larger or existing systems
• -- data flow and dependency
• -- operation orderings (algorithms)
• -- concurrent operations

19
CONTENTS OF UML

• Use cases,
• Interaction diagrams (Sequence Diagram, CRC,
  Collaboration Diagram)
• Class Diagram (aggregations, composites,
  interfaces and realisations)
• Package
• Activity Diagram
• State Diagram, State Chart, and Data Flow Diagram

20
RATIONAL ROSE

• Rose is one of products from Rational Software.
• It is an expensive CASE (Computer-Aided Software
  Engineering) tool for object-oriented modeling.
• Based on UML (more or less).
• It provides semantics (a compiler) for UML.
• It has a reasonably intuitive GUI similar to
  standard drawing programs, like Illustrator, and
  is available for Windows and other platforms.
• It makes creating and maintaining your UML
  diagrams easier (or at least more consistent).
• Has many bizarre features, including generation
  of C (and other) code from your diagrams.

21
RATIONAL ROSE (Contd)

• You can visit their website http//www.rational.c
  om/
• Getting the Evaluation copy (limited to 15 days)
• http//www.rational.com/tryit/rose/index.jsp
• Rational Rose is also Installed in our CIS Lab
  (Room 015)
• Our practicals will be based on the software.

22
RATIONAL ROSE (Contd)

• Why do we need the Rational Rose? -- We use it to
  create a series of models for all the steps of
  OOSD
• -- Each model contains views, diagrams, and
  specifications to visualise and manipulate the
  elements in the model
• -- There are many views of each underlying
  element
• -- Every object in the design is represented
  once in the Rose model
• -- Rose maintains a consistent semantic
  representation in the model

23
RATIONAL ROSE (Contd)

• What does Rational Rose look like?
• -- Standard toolbar
• -- Diagram toolbar
• -- Browser a drop-down list of things in your
  model
• -- Documentation window where you can add notes
  to a thing in your model
• -- Diagram windows where you draw your pictures
• -- Specifications
• -- Status bar

24
(No Transcript)
25
SUMMARY

• Credit Scheme
• Software process
• Introduction of UML
• Introduction to Rational Rose

26
COS50-3 OOSD
REQUIREMENT MODEL USE CASE DIAGRAM (Week 2)
27
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

28
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

29
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

30
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

31
USE CASE DIAGRAM
Syntax

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

32
Rational Rose Use case diagrams
No system border in Rational Rose!
33
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
• -- ..

34
USE CASE DIAGRAM (Contd)

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

35
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.

36
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.

37
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.

38
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.

39
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.

40
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.

41
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.

42
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.

43
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.

44
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.
45
CASE STUDY (Contd)

• Identify actors

46
CASE STUDY (Contd)

• Identify use cases

47
CASE STUDY (Contd)
Entire use case model
48
DOCUMENTATION

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

49
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.

50
ACTIVITY DIAGRAM (Contd)
Syntax
Activity
Fork
Branch
Join
Merge
51
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

52
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
53
(No Transcript)
54
Rational Rose activity diagram
55
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.
56
CASE STUDY (Contd)
Step 1 System border
Wessex Fox
57
CASE STUDY (Contd)
Step 2 Actors -- Drivers, -- Time Table
Makers, -- Manager.
58
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.

59
CASE STUDY (Contd)
Time table maker
Driver
Manager
60
Case Study in Rational Rose
61
SUMMARY

• Various models
• Use case diagram
• Activity diagram

62
COS50-3 OOSD
Object Oriented Analysis (Week 3)
63
OBJECT

• An object is an entity which consists of a number
  of operations and a state which remembers the
  effect of the operations.
• State is regarded as information which is saved
  in a set of variables.
• Operations read and/or affect the information.
• The only part that can be seen by an outsider is
  the operations. For this reason, operations are
  also known as behaviours.
• Information is hidden to the outsider.

64
OBJECT (Contd)
Example a person as an object
65
CLASS and INSTANCE

• Class is a template or abstract description of
  the same type of objects. It defines the common
  features of the objects, that is the operations
  and information structure.
• Instance is an object created from a class.
• An instances behaviour and information structure
  is defined in the class.
• Its current state (values of instance variables)
  is determined by operations performed on it.

66
INHERITANCE

• Inheritance takes place when a subclass of a
  superclass is created.
• A subclass inherits behaviours and information
  structure (class members) from its parent class.
• It can refine the operations and can even add
  some extra operations and information.
• Note not all operations and information a
  subclass can inherit. Pay attention to the the
  specifiers of class members of a superclass.
• Access private members is not easy.

67
POLYMORPHISM

• Very original meaning -- Microorganism propagates
  itself and no two individuals are exactly the
  same. So we obtain a variety of individuals.
• Original meaning -- the sender of a stimulus
  doesnt need to know the receivers class.
• Extension -- different receivers can interpret
  the message in their own way.
• Consequence -- different receivers can response
  to the same stimulus based on their
  interpretation. So we can have a variety of
  objects who process the same piece of data in
  different ways.
• Method overloading and overwriting.

68
ENCAPSULATION

• Encapsulation is the process of hiding the
  implementation details of an object.
• The only access to manipulate the object data is
  through its interface.
• It protects an objects internal state from being
  corrupted by other objects.
• Also, other objects are protected from changes in
  the object implementation.
• Encapsulation allows objects to be viewed as
  black boxes.
• Communication is achieved through an interface.

69
ANALYSIS

• In software engineering, analysis is the process
  of converting the user requirements to system
  specification (system means the software to be
  developed).
• System specification, also known as the logic
  structure, is the developers view of the system.
  
• Function-oriented analysis -- concentrating to
  the decomposition a complex function to simply
  ones.
• Object-oriented analysis -- identifying objects
  and the relationship between objects. (An
  object-oriented model of a system consists of a
  number of objects which are the parts of the
  system.)

70
OO ANALYSIS

• OO analysis contains the following activities
• -- identifying objects objects must be
  essential, i.e. always exist, so the system is
  stable,
• -- organising the objects classifying the
  objects identified, so similar objects can later
  be defined in the same class,
• -- identifying relationships between objects
  this helps to determine inputs and outputs of an
  object,
• -- defining operations of the objects the way
  of processing data within an object,
• -- defining objects internally information held
  be the objects.

71
OO ANALYSIS MODEL

• A model is required to represent the system
  specification.
• The model must be robust and stable. To achieve
  these, the model must be implementation
  environment independent, so that any change in
  the implementation environment will not affect
  the logic structure of the system.
• The model must be able to capture information,
  behaviour (operations) and presentation (inputs
  and outputs).

72
OO ANALYSIS MODEL

• The model is defined in information -- behaviour
  -- presentation space.

73
OO ANALYSIS MODEL (Contd)

• Syntax
• Within an use case, we employ three types of
  objects (in Rational Rose, they are known as
  three types of entities or stereotypes)

74
OO ANALYSIS MODEL (Contd)

• Semantics
• An entity object models information that shows
  the state of a system. This information is often
  used to record the effects of operations and
  therefore is related to the behaviours of the
  system.
• A boundary/interface object models inputs and
  outputs and operations that process them.
• A Control object models functionality/operations
  regarding to validate and decide whether to
  process and pass information from interface
  object to entity object, or the way around.

75
OO ANALYSIS MODEL (Contd)

• Pragmatics
• Identifying interface objects -- functions
  directly related to actors.
• Identifying entity objects -- information used in
  an use case and functions of processing the
  information.
• Identifying control object -- functions that link
  interface objects and entity objects

76
OO ANALYSIS MODEL (Contd)
Example Recycling machine

• Three tasks are often tangled together
• We normally start from the refinement of the use
  case diagram.
• Then we identify objects.
• At the same time, we organise and identify
  relationships.

77
OO ANALYSIS MODEL (Contd)

• Refinement of the use case diagram
• -- Refine use cases by considering include,
  extend and generalisation.

78
OO ANALYSIS MODEL (Contd)
-- Refine actors by considering
superclass/subclass and inheritance.
79
OO ANALYSIS MODEL (Contd)
-- Refinement also includes adding use cases
which are forgotten at the previous stage.
80
OO ANALYSIS MODEL (Contd)

• Identify boundary/interface objects

81
OO ANALYSIS MODEL (Contd)

• Identify relationship (also know as association)
  between the identified objects.

82
OO ANALYSIS MODEL (Contd)
When a customer returns a deposit item, it is
measured by the system. The measurements are used
to determine what kind of can, bottle or crate
has been returned. If acceptable, the total
number of items of this type returned by the
customer increments. If not, the light for Not
Valid is highlighted on customer panel. When the
customer presses the receipt button, the printer
prints the date. The total number of items he
returned and the lump sum is calculated. The
following is printed out customer number,
number returned, deposit value, total of this
type and lump sum
83
OO ANALYSIS MODEL (Contd)

• Identify entity objects. (Let us focus on return
  item use case.)
• -- long term information (for all customer)
  deposit values of bottle, can and crate,
• -- short term information (for a customer) the
  total number of items of each type returned by
  the customer, the total number of items he
  returned and the lump sum should be paid to him.

84
OO ANALYSIS MODEL (Contd)
85
OO ANALYSIS MODEL (Contd)
When a customer returns a deposit item, it is
measured by the system. The measurements are used
to determine what kind of can, bottle or crate
has been returned. If acceptable, the total
number of items of this type returned by the
customer increments. If not, the light for Not
Valid is highlighted on customer panel. When the
customer presses the receipt button, the printer
prints the date. The total number of items he
returned and the lump sum is calculated. The
following is printed out customer number,
number returned, deposit value, total of this
type and lump sum
86
OO ANALYSIS MODEL (Contd)

• Identify control objects. (We still focus on
  return item use case.)
• -- There are entity and boundary objects in this
  use case.
• -- Items coming from customer panel need to be
  measured and decision on whether passing the
  information needs to be made according the
  measurement.
• -- decision on whether print out information
  also needs to be made.

87
OO ANALYSIS MODEL (Contd)
88
OO ANALYSIS MODEL (Contd)