Object Oriented Systems

1

Object OrientedModelling Rationale and Concepts
University of Ulster at Jordanstown
2
The role of abstraction in problem solving

• Abstraction is generally defined as
• the process of formulating generalised concepts
  by
• extracting common qualities from specific
  examples
• Central to human understanding and reasoning
• Tool for handling complexity in two areas
• in understanding complex issues, and
• in solving complex problems

3
Levels of Abstraction
Requirements
Users Conception
Logical Model
Analysis
Acceptance
Physical Model
Design
Constructed Model
4
A Logical Model

• Describing WHAT a system must do without
• considering HOW the system will do it.
• Difficult to divorce Logical and Physical
  Models
• because humans are naturally prone to
• problem solving.
• Business level abstractions such as Customers,
• Accounts, Managers, Invoices, Parts,
  Suppliers,
• etc...

5
A Physical Model

• Now concentrating on turning the what
• into the solution by considering the how.
• Introducing more detailed abstractions such
• as Collections, Menu Items, Icons, Dialogues,
• Mouse Events, Storage Managers, etc...

We will return to these ideas later when looking
at Object Modelling
6
A mind Map
Principles
P r i n c i p l e s
P r i n c i p l e s
Principles
adapted from Wilkie 1993
7
Fundamental principles of Object oriented
abstraction

• Data abstraction
• Behaviour sharing

Evolution and Reuse
8
Data Abstraction

• The programmer is presented with a higher level
  abstraction over both the data and the algorithms
  required to manipulate the data.
• The user view is of a collection of operations
  that define the behaviour of the abstraction.
• Data abstraction encompasses two separate but
  closely related concepts
• Modularisation
• Information hiding.

Blair et al 1991
9
Behaviour Sharing

• Many entities can share the same signature or
  interface access points.
• through classification, where entities in a group
  share common behaviour
• by one classification including another
• The individual implementations behind these
  access points may differ, reflecting inherent
  differences between the entities.
• by one classification redefining another
• by coincidence, where 2 entities share common
  behaviour without being part of a classification.

Blair et al 1991
10
Evolution Reuse

• System requirements change over time.
• Solutions to problems may be developed in an
  incremental manner.
• The object oriented philosophy is to provide a
  single approach which encompasses both aspects.
  This is facilitated through Data Abstraction and
  Behaviour Sharing.

11
Applications of these Principles
The major areas where object oriented concepts
have been influential are

• Programming languages
• Smalltalk, C, Visual C, Java
• Analysis/Design methods
• Booch, Rumbaugh, Coad/Yourdon, Jacobson, UML,
  etc.
• Databases
• IRIS, Gemstone, ONTOS, ObjectStore, Versant, etc.
• AI
• principally because of the elegance for
  representing complex knowledge
• HCI
• Harmony between OO and metaphors for visual
  representation and interaction
• Distributed Systems
• OMG, WWW

12
Introduction to Coupling and Cohesion

• Qualitative measures of the goodness of a design
• Suggested by Stevens et al (1979)
• Coupling describes the relationship between
  modules.
• Cohesion describes the relationships within a
  module.
• Strive for Low Coupling and High Cohesion

13
Coupling
Decreasing strength

• Internal data coupling (undesirable)
• One module can modify internal local data of
  another. Makes understanding programs difficult
  and changing them very risky (knock-on effects)
• Global data coupling
• Two or more modules bound together by reliance on
  common global data structures. Sometimes
  unavoidable but makes for difficulties in
  understanding.
• Control coupling
• One module must perform operations in a certain
  fixed order, but the order is controlled by
  another module.
• Parameter coupling (most desirable)
• One module invokes services from another.
  Parameters may be supplied and a return value
  defined.

14
Cohesion
Increasing strength

• Coincidental cohesion (weakest)
• Elements of a module are grouped for no apparent
  reason. e.g. arbitrarily chopping a large program
  into segments.
• Logical cohesion
• Logical but no actual connection between elements
  in terms of either data or control e.g. function
  libraries.
• Temporal cohesion
• Elements are bound which execute at approximately
  the same time. e.g. initialisation routines.
• Communication cohesion
• Elements all access the same I/O data or device.

15
Cohesion continued
Increasing strength

• Sequential cohesion
• Elements are activated in a particular order. OK
  provided the sequence is hidden from outside
  view.
• Functional cohesion (desirable)
• Elements are all related to the performance of a
  single function or task.
• Data cohesion
• Module internally defines a set of data values.
  This occurs when a module is used to implement a
  data abstraction.

16
Building on the fundamental principles - the
basic concepts

• Objects (Encapsulation)
• Classes
• Inheritance
• Message Passing
• Polymorphism

17
Objects
Encapsulation
External Interface

• Data - the Attributes of the object
• Code - the functional logic, Methods or behaviour

18
More about Objects

• There are two kinds of Method
• Interface Methods - which can be called from
  external objects
• Private Methods - which are for internal use only
• Data Attributes can assume different forms
• A primitive type such as an integer, string, etc.
• Another Object, - very powerful concept, allows
  for object composition.

19
Benefits from Objects

• Strong Cohesion (Can you suggest what form?)
• Weak Coupling (What form?)
• Information Hiding
• Can lead to a reduction in side effects when
  things change
• Conceptual clarity by more closely modelling
  problem domain

20
Classes

• A Class is a template from which Objects are
  created. It defines the Attributes and Methods
• A Class is generally a compile-time concept
• An Object, by comparison, is generally a run-time
  concept
• An Object is an instance of a class. Can have
  many objects of the same class
• The code (methods) associated with an object is
  managed from the Class
• The data (attributes) associated with an Object
  reside in the Object

21
Classes
Lecturer Fred
Emp 1 NameFred Room 16J03 Salary10000
Class Lecturer
Object ID
Attributes
Emp no. Name Room no. Salary
Lecturer Laura
Emp 2 NameLaura Room 16J15 Salary15000
Methods
Lecture() Mark() Publish() ...
Instances of the class Lecturer
22
Benefits from Classes

• Provide a central point for managing and storing
  methods
• Conceptually similar to the notion of a record or
  data structure used in a traditional method
• Provide a framework for Inheritance

23
Inheritance

• Classes are defined from candidate objects by
  means of abstraction
• Abstraction enables generic properties or
  features of objects to be extracted
• An inheritance hierarchy can be created - the
  most generic classes towards the top with
  increasing specialization towards the bottom
• Classes can inherit both attributes and methods
  from superclasses

24
An example of Inheritance
Person
Name Address
Employee
Add_Name Query_Name
Salary
inherits from
Add_Salary Query_Salary
Manager
Car_Allow
inherits from
Add_Allow Query_Allow
25
Forms of Inheritance
When creating a new class from an existing class,
the user is effectively creating a
specialisation which is a step nearer the
requirements of the application domain. There are
various ways that a specialisation can take
place

• Add new behaviour
• Change existing (superclass) behaviour
• Delete behaviour

26
Inheritance - Adding Behaviour

• The most common approach.
• Adds data or methods to the superclass
• New class inherits all data and methods from
  superclass

27
Inheritance - Changing behaviour

• Re-defining the implementation of an existing
  method
• For example, a print method could be added to
  each of Person, Employee and Manager with
  slightly different behaviour for each.
• Sharing signature with slightly modified
  behaviour.

28
Inheritance - Deleting Behaviour

• Less common.
• Sometimes possible to remove data and methods
  from the superclass thus creating a new class
  with less functionality than the superclass.
• Need to question whether a sub-class/super-class
  relationship is appropriate in this case!

29
Inheritance

• Usually a combination of adding and changing
  behaviour is used.
• Most object oriented programming languages and
  methods will support addition and re-definition.
  However, some systems do not allow behaviour to
  be deleted from classes.
• Systems supporting only addition are said to have
  strict inheritance.

30
Benefits and detrimentsfrom Inheritance

• Benefits
• Provides a means of managing classes
• Useful mechanism for promoting re-use
• Creates an extensible framework
• Problems
• Increases coupling between Classes
• Requires careful management in environments with
  a large class library
• Requires tools to increase visibility of
  inherited properties

31
Message Passing

• Objects communicate by send each other messages.
• Messages generally take the form
• Object Name - Message Name - Argument List

32
Message Passing
Review_Dept Message
Increase_Salary Message
Object called "Burt" of class MANAGER
Object called "Joe" of class EMPLOYEE
33
Polymorphism

• Literally Translated it means "Many forms"
• It enables programming languages to use
• objects from different classes in an
  interchangeable
• and consistent way.
• Strong benefits for software extensibility.
• Most relevant at the Programming stage.

34
Inclusion Polymorphism

• Implemented through Inheritance
• An object of class X can be used to represent any
  object inherited from X
• Methods defined in the parent class can be
  redefined in the child

35
Inclusion Polymorphism
Consider the Employee/Manager inheritance
relationship
Employee
Salary
query_sal() print()
Manager
Car_Allow
inherits from
qry_Allow() print()
36
Inclusion Polymorphism
The print() method appears in both classes and
has been redefined in the Manager class. A
reference to an Object of class Employee can
also refer to any decendant class such as Manager
Polymorphic message - EmpRef.print()
37
How the Object oriented concepts support the
principles

• Data Abstraction
• Objects
• modularity
• abstract behaviour
• Behaviour sharing
• Classes
• Inheritance
• Polymorphism
• Evolution Reuse
• Inheritance
• Polymorphism

38
Overall benefits derived from a use of OO Concepts

• Easier management of complexity
• Reliability and ease of change
• More Software Reuse
• Needs good management!!!
• Publicise available components
• Guarantee library integrity
• Scout for new, potentially reusable components

39
A Definition of Object Orientedness

• Goldberg and Rubin 1995 state
• Something is object oriented if it can be
  extended by composition of existing parts or by
  refinement of behaviours. Changes in the original
  parts propagate, so that compositions and
  refinements that reuse these parts change
  appropriately.