The Object Model

1
Lesson 2

• The Object Model

2
Evolution of Programming Languages

• General trend is from imperative languages to
  declarative languages.
• Imperative language tells the computer what to
  do using the vocabulary of the machine (i.e. its
  instructions).
• Declarative language describes key abstractions
  in the problem space using the vocabulary of the
  problem domain.

3
Evolution (continued)

• First-Generation Languages (1954-58)
• Used for scientific and engineering applications,
  so vocabulary of the problem domain is
  mathematics.
• Some languages include
• FORTRAN I Mathematical expressions
• ALGOL 58 Mathematical expressions
• Flowmatic Mathematical expressions
• IPL V Mathematical expressions

4
Evolution (continued)

• Second-Generation Languages (1959-61)
• Emphasis is on algorithmic abstractions.
• Some languages include
• FORTRAN II Subroutines, separate compilation
• ALGOL 60 Block structure, data types
• COBOL Data description, file handling
• Lisp List processing, pointers, garbage
  collection

5
Evolution (continued)

• Third-Generation Languages (1962-70)
• Increased support for data abstraction.
• Some languages include
• PL/1 FORTRAN ALGOL COBOL
• ALGOL 68 rigorous successor to ALGOL 60
• Pascal Simple successor to ALGOL 60
• Simula Classes, data abstraction

6
Evolution (continued)

• The Generation Gap (1970-80)
• Much language research occurred, and many new
  languages were developed.
• Few endured, but innovative concepts were
  introduced to new versions of established
  languages.
• Object-oriented concepts introduced in Simula
  were refined in Smalltalk.

7
(c) 1994 Booch
8
Evolution (continued)

• Topology of first- and early second- generation
  languages
• The subprogram (subroutine) is the basic physical
  building block (supports algorithmic
  decomposition).
• Flat physical structure global data plus
  subprograms operating on that data.
• Global data means that subprograms are highly
  coupled makes modifications difficult.

9
(c) 1994 Booch
10
Evolution (continued)

• Topology of late second- and early
  third-generation languages
• Greater support for algorithmic abstractions
• parameter passing for subprograms
• nesting of subprograms
• control structures (loops, if-else blocks, etc.)
• scope and visibility of declarations

11
(c) 1994 Booch
12
Evolution (continued)

• Topology of late third-generation languages
• Better support for team development of large
  programs, using separately compiled modules.

13
(c) 1994 Booch
14
Evolution (continued)

• Topology of object-oriented and object-based
  languages
• Data and operations are united using classes and
  objects as fundamental building blocks (supports
  object-oriented decomposition).
• Methods of data abstraction are explicitly
  supported.
• Little or no global data (abstractions are
  decoupled).

15
(c) 1994 Booch
16
Definitions

• Object
• A tangible entity that exhibits well-defined
  behavior.
• A crisply-defined entity that combines data and
  procedures operating on that data (i.e. performs
  computations and saves local state).
• Unifies algorithmic and data abstractions.

17
Definitions (continued)

• Object-Oriented Programming (OOP)
• a method of implementation in which programs are
  organized as cooperative collections of objects,
  each of which represents an instance of some
  class, and whose classes are all members of a
  hierarchy of classes united via inheritance
  relationships.

18
Definitions (continued)

• A language is object-oriented only if
• It supports objects that are data abstractions
  with an interface of named operations and a
  hidden local state.
• Objects have an associated type (i.e. its class).
• Types (classes) may inherit attributes from
  supertypes (superclasses).
• Object-based languages are like object-oriented
  languages, except they dont directly support
  inheritance (e.g. Ada).

19
Definitions (continued)

• Object-Oriented Design
• is a method of design encompassing the process
  of object-oriented decomposition and a notation
  for depicting both logical and physical as well
  as static and dynamic models of the system under
  design.
• Uses class and object abstractions to logically
  structure systems.
• Structured design, in contrast, uses algorithmic
  abstractions.

20
Definitions (continued)

• Object-Oriented Analysis
• is a method of analysis that examines
  requirements from the perspective of the classes
  and objects found in the vocabulary of the
  problem domain.

21
Elements of the Object Model

• We need to establish the conceptual framework for
  object-oriented analysis, design and programming.
• The seven elements are
• Abstraction
• Encapsulation
• Modularity
• Hierarchy

22
Elements (continued)

• Typing
• Concurrency
• Persistence

23
Abstraction

• Definition a simplified representation of an
  object that emphasizes significant details while
  suppressing unimportant or diversionary details.

24
(c) 1994 Booch
25
Abstraction (continued)

• An abstraction focuses on the outside view of an
  object.
• Separates the objects essential behavior from
  its implementation.
• The interface of an object specifies its
  essential behavior.
• Defines a contract upon which other objects
  depend.

26
Abstraction (continued)

• Specifies the responsibilities of the object, the
  behavior for which it is held accountable.
• The implementation focuses on the inside view of
  the object.
• Consists of mechanisms that achieve the desired
  behavior, plus the internal representation of the
  abstraction.
• Should be secret and hidden from other objects.

27
Abstraction (continued)

• We can change details of the implementation if we
  dont break the contractual interface.
• Deciding upon the right set of abstractions for
  a given domain is the central problem in
  object-oriented design.

28
Encapsulation

• Definition the process of compartmentalizing an
  objects internal mechanisms and structure, so
  that the objects interface is separated from its
  implementation.

29
Encapsulation (continued)

• Encapsulation is achieved through information
  hiding
• The structure of the object is hidden.
• The implementation of the objects methods is
  hidden.
• We can reimplement anything inside the objects
  capsule without affecting other objects that
  interact with it.

30
(c) 1994 Booch
31
Modularity

• Definition The decomposition of a system into a
  set of highly cohesive and loosely coupled
  modules.
• Modules are physical containers in which classes
  and objects (the logical design) are placed.
• In C, modules are separately compiled files,
  each having one or more class definitions.
• In Java, modularity is achieved with packages.

32
(c) 1994 Booch
33
Modularity (continued)

• A module has an interface and a body
  (implementation).
• Changing the body requires recompiling just that
  module.
• Changing the interface requires recompiling the
  module, plus all other modules that depend on the
  interface.

34
Modularity (continued)

• Deciding how to group classes into modules is a
  difficult physical design decision
• Every class could be put into one module useful
  only for trivial systems.
• Could have one class per module difficult to
  manage for large systems.
• Could group logically related classes into the
  same module probably best, but the best
  grouping to use may not be clear.

35
Modularity (continued)

• The principles of abstraction, encapsulation and
  modularity work together
• An object provides a sharp boundary around a
  single abstraction.
• Both encapsulation and modularity prevent
  unauthorized access to the secrets of the
  abstraction.

36
Hierarchy

• is a ranking or ordering of abstractions.
• Allows us to organize a large number of
  abstractions.
• The class (is a) and object (part of)
  hierarchies are fundamental to an object
  architecture.

37
(c) 1994 Booch
38
Class Hierarchy

• Classes are related by inheritance
• A subclass inherits behavior and structure from
  its superclass.
• A subclass also augments or redefines the
  behavior and structure of its superclass.
• Also known as generalization/specialization
  hierarchy.

39
Class Hierarchy (continued)

• Helps create compact code
• General functionality is put into superclasses.
• Specialized functionality is added to the general
  case by creating the appropriate subclass.
• The subclass reuses the code from the superclass
  for non-specialized functionality.

40
Class Hierarchy (continued)

• Single inheritance
• Where subclasses can have only one immediate
  superclass.
• E.g.

41
Class Hierarchy (continued)

• Multiple inheritance
• Where subclasses may have more than one immediate
  superclass.
• C is a very strong language that can support
  very easily multiple inheritance.
• Some languages (e.g. Java) dont support multiple
  inheritance.

42
Object Hierarchy

• Objects are grouped into logical collections
  (i.e. an aggregation).
• E.g.

43
Typing

• is the enforcement of the class of an object,
  such that objects of different types may not be
  interchanged.
• Strong typing
• Where you cannot send a message to an object
  unless its class or superclasses have been
  defined to accept the message.
• In a strongly-typed language, a violation of type
  conformance is detected at compile time.

44
Typing (continued)

• Example
• fido.eat(food) is legal, since fido is of the
  class Dog, which has the eat() method defined.
• myCar.eat(food) is not legal, since the eat()
  method is not defined in myCars class Volvo, nor
  any its superclasses.
• With strong typing, all expressions are
  guaranteed to be type-consistent.

45
(c) 1994 Booch
46
Typing (continued)

• Untyped languages, like Smalltalk, allow you to
  send a message to an object of any class.
• If the object cannot respond to the message (i.e.
  its class and superclasses dont implement the
  method), this violation of type conformance is
  not detected until run time (i.e. is an execution
  error).

47
Typing (continued)

• Weak typing where type conformance is not
  always strictly enforced.
• Binding the association of a name (a declared
  variable) with a class (a type).
• Static binding (early binding) the class of a
  variable is established at compile time, and
  cannot be changed during execution.

48
Typing (continued)

• Dynamic binding (late binding) the name/class
  association is not made until the object
  designated by the name is created at execution
  time.
• E.g. Animal a new Animal()
• Allows dynamic loading of code while a program
  is running, you can add objects to it that were
  created in some other code.
• C uses static as well as dynamic binding.
• Java uses dynamic binding.

49
Typing (continued)

• Polymorphism where the same message can be sent
  to different objects, and each responds in an
  appropriate way.
• This works because these objects inherit from
  some common superclass (i.e. they respond to a
  common set of operations).

50
Typing (continued)

• E.g.

Mammal fido, fluffy fido new
Dog() fido.eat(food) fluffy new
Cat() fluffy.eat(food)
51
Concurrency

• Where two or more objects are active at the same
  time.
• On a multiprocessor system, there is a thread of
  control on each CPU.
• On a single CPU, the illusion of concurrency is
  achieved by scheduling time slices for each
  thread.

52
(c) 1994 Booch
53
Concurrency (continued)

• Heavyweight process (task)
• Has its own address space, and is managed by the
  OS.
• Interprocess (intertask) communication is
  expensive.
• Lightweight process (thread)
• Shares the address space with other threads in
  the task.

54
Concurrency (continued)

• Communication among threads is inexpensive since
  shared data is usually used.
• Concurrent objects must be synchronized to deal
  with issues like
• deadlock
• livelock
• starvation
• mutual exclusion
• race conditions

55
Concurrency (continued)

• In OOP, concurrency is usually achieved by
  placing an object in its own thread of control.
• Java has built in support for threads and
  synchronization.

56
Persistence

• Where an object continues to exist after its
  creator dies, or is moved to a different address
  space from where it was created.
• OO databases are available for permanent storage
  of objects.
• Object Request Brokers (ORBs) and distributed
  objects allow movement of objects from machine to
  machine.

57
(c) 1994 Booch
58
This presentation is based on the following book
Object Oriented Analysis and Design by G.Booch
and partially compiled by Leonard Manzara.