Object Oriented System Software Engineering

1
Object Oriented System Software Engineering

• Dave Gillibrand K222 D.Gillibrand_at_staffs.ac.uk
• Kelvin Hilton K213 K.C.Hilton_at_staffs.ac.uk
• Peter Hoornaert K242 P.Hoornaert_at_staffs.ac.uk
• www.soc.staffs.ac.uk/cmtph

2
Object Oriented Analysis Design - 1

• Everything is a class
• class is a blueprint, abstract
• object has identity, exists
• Real world models
• OO attempts to model real world

3
Class diagrams

• Note - class name is singular
• Class
• identifier
• attributes
• methods

4
Class diagrams

• Classes change
• iterative process
• expect change

5
Classes

• Relationships between classes
• Three relationships
• association
• aggregation
• generalization/specialization (or inheritance)

6
Association

• loosest relationship
• some communication between the classes
• e.g. Student to Module

7
Aggregation

• one class is part of another class
• tighter than an association
• one class is part of another class
• if you can answer yes - probably aggregation
• e.g. Course to Module

8
Inheritance (Generalization/Specialization)

• is a kind of e.g. house is a kind of
  building
• one class is the child of another parent class
• the child class inherits all the attributes and
  methods of the parent
• e.g bank account

9
Inheritance

• may be several classes inheriting from one parent
  class
• Ancestor classes are also referred to as base
  classes

10
Inheritance

• Ancestor Classes
• real power and impact of inheritance becomes
  clearer when we start to add attributes and
  methods
• first add some attributes and
• methods to the class BUILDING
• must remember that they
• must apply to all BUILDINGs

11
Inheritance

• HOUSE now inherits all the generalized attributes
  and methods from BUILDING
• then we can add the specialized attributes that
  make it special
• becomes more interesting when there is more than
  one class inheriting from the parent class

12
Inheritance

• class HOUSE has the attributes
• Front door
• Back door
• Kitchen
• Roof
• Garden
• PLUS
• Walls
• Number of rooms

13
Ancestral trees

• class will inherit all
• attributes
• methods
• from all its ancestors

STAFF Payroll number Employed Works
STUDENT
ACADEMIC Subject Department Teaches Sets
exams Marks work
Administrative
14
UML and case tools

• notation used to draw the class diagrams
• the Unified Modeling Language or UML
• released in January 1997, quickly established
  itself as an industry standard
• Several case tools
• Rational Rose
• Select Enterprise Modeler

15
Multiplicity

• can show how many of one class we can expect to
  find with another
• called multiplicity
• e.g. car - wheel

16
Multiplicity

• character actually
• means 0 or more
• a STUDENT will be
• associated with zero,
• one or many modules,
• and a module will be
• associated with zero,
• one or many STUDENTs

17
Multiplicities

• blank not determined
• 0 zero
• 1 one
• zero, one or many
• 1 .. one or many
• 1 .. 5 one to five
• other combinations as required
• 2 .. 6 two to six
• 3 .. three to many

18
Relationship labels
or
19
Objects

• A class can be thought of as a recipe, a
  description or declaration of something which we
  will create
• We can create
• an individual student
• an instance or instantiation of the class
• give it identity, and this is an object

20
Objects

• class STUDENT may be
• This is a declaration of what we expect every
  student to have and do

21
Objects

• An object created from this class might be
• an object has
• identity
• values
• and is unique

22
Constructors

• We can also say that we have constructed each
  object. This is an important concept when we come
  to implement the design in a programming
  language.
• When we constructed the objects above we gave the
  attributes values which make each object
  different from the next, even though they are all
  instances of the same class

23
Destructors

• Eventually the objects will no longer be
  required. (Hopefully all students will eventually
  complete their course and will cease being
  students.)
• When producing class diagrams this may not seem
  important, but when the system is implemented
  this will need to be considered.
• When we have finished with an object it should be
  destroyed using a destructor. Some languages do
  this for you, others expect you to do it.

24
Encapsulation

• also referred to as data hiding
• need to ensure that the values of the object are
  protected, so that they cannot be interfered
  with, and cannot be inadvertently changed
• object is encapsulated, attributes and methods
  should be carefully controlled so that access to
  them is only allowed in a controlled way

25
Message Passing

• classs data or attribute values should only be
  accessible through message passing
• if you want the value of an attribute then ask
  for it and you will be given it, but you
  shouldnt have direct access to it

26
Encapsulation/message passing

• e.g. class student
• doesnt matter how
• the date is stored,
• providing a recognizable date
• is returned when
• a message is passed asking for it

27
Hidden methods

• Method not accessible outside class
• e.g. getDoB in numeric format
• getDoB in string format
• dont know how DoB is stored
• dont care providing we get DoB in requested
  format
• method to produce it is not visible/accessible

28
Cohesion

• consequence of encapsulation is that classes that
  are self contained
• attributes are not readily accessible to anything
  outside the class unless a method to give access
  is provided
• cannot make changes to anything inside the class
  unless we give permission
• cohesion is HIGH

29
Coupling

• one class has a high dependency on another class
• a change in one requires a change in the other
• this is high coupling
• OO wants LOW coupling

30
Polymorphism

• Inheritance gives all attributes and methods of
  parents
• Inheritance also allows polymorphism
• poly many
• morph form
• many forms

31
Polymorphism
32
Polymorphism

• Circle Rectangle
• Attributes Attributes
• Colour Colour (from Shape)
• Number of angles Number of angles (from Shape)
• Radius Height
• Length
• Methods Methods
• Draw Draw (from Shape)
• Draw Draw

33
Static and Dynamic Binding

• Notice each has two Draw methods
• generalized Draw - shape
• specialized Draw - their own specific outline
• necessary to redefine the Draw method as they
  will need to do something different from the
  ancestor class

34
Static and Dynamic Binding

• Which method will be used?
• At the time of writing and compiling the program
  we may not know
• Procedural programming - static binding (compile
  time)
• OO languages - dynamic binding (run-time)