The Object Model Nazim H. Madhavji UWO 1(c) N.H. Madhavji, 14 August, 2014

(c) N.H. Madhavji, 14 August, 2014 1

The Object Model

Nazim H. MadhavjiUWO


Key sources of material

• Chapter 2, OO Analysis and Design with Applications, 3rd Ed., Grady Booch, et al., Addison Wesley, 2011.

• Personal thoughts.


Key topics covered

• The Evolution of the Object Model• Foundations of the Object Model• Elements of the Object Model


The Evolution of the Object Model

• Please read the text book for complementary details; here we shall cover: Algorithmic/Structured languages vs. OO languages


Algorithmic/Structured languages vs. OO languages

• Algorithmic languages were so called because “algorithms” (actions, instructions, etc.) were the primary basis underlying the design and code of programs in these languages.

• OO languages have “objects” and “classes” of objects as the primary basis.


Algorithmic/Structured languages• Programs in algorithmic (a.k.a “structured”) languages (such as Algol 60,

Pascal, etc.) were basically tree-structured.• Relatively small(er) programs (“programming-in-the-small”).• Independent development of parts of the same program manually

managed.

PROGRAM X (I/O parameters);<mainline data structures><Sequence of (possibly) nested PROCEDURES and FUNCTIONs>

BEGIN<mainline statements: ASSIGNMENT; SELECTION; LOOPs; CALL; JUMP; etc.>

END.


Modular languages

• More sophisticated (a.k.a “modular”) languages (such as Modula, Modula-2, Ada, C) facilitated development of a large “system” as a set of “modules”.

• This suited “programming-in-the-large” – for development by teams. Say, programmer 1 develops module M1, and programmer 2 develops module M2, etc.

• Modules could be developed independently and concurrently.– Separately compiled– Loaded (integrated) to form a whole system


Modular languages

• A module had two parts: interface part and implementation part. The implementation part was hidden from the users of a given module; they could only read/use the interface part.

• The modules M1 and M2, etc., interacted with each other through their interfaces.

• A module interface had “exports” and “imports”. • Exported items from module M1 need to be declared in the

interface part of M1. – Data structures exported showed their internal structure in the

interface part. – Procedures/functions exported showed the parameters so that the

user of module M1 can make proper calls.


Modular languages

• Items imported in module M1 (from module M2, etc.) need to be specified in the interface part of module M1 and must be exported from the exporting module’s interface (M2, etc.).

• Each module was essentially like a tree-structured Pascal program.


Interface and Implementation Modules

INTERFACE MODULE M1.EXPORT A, B, X;FROM M2 IMPORT P, Q; (*P and Q need to be made visible through the

interface of Module M2 *)<visible declarations: A: int; B: real; PROCEDURE X (....);

END M1. IMPLEMENTATION MODULE M1.

<hidden data declarations>; Procedure X (....); BEGIN .... END; (*hidden from the user*)

BEGIN .... END M1.


Modular languages and scaling up

• While modular languages enabled programmers to do independent development (of large-scale systems) and collaborate through module interaction, the increasing domain complexity was still a challenge. – Modules could not be nested so scaling up to very large-scale

development was a problem. – Fundamentally, viewing a real-world problem in an

algorithmic way was getting more and more difficult as system complexity increased.

– There was a need to represent the application domain more directly in the system design in order to handle system complexity.


From Modular to OO languages

• Object-oriented languages (e.g., Java, C++) turned this around (to the extent it has been able to) by structuring systems based on classes (as representation of real-world things) and objects as instances of classes. See OO history (Chapter 2)– Algorithms are encapsulated in classes as “operations” (a.k.a

methods) on the objects. – Objects in different classes interact with each other through calls

(messages) from methods in one class to methods in other classes.

– Specialisation (reuse) of a parent class is done through inheritance; this did not exist in modular/structured languages.


From Modular to OO languages

• The OO paradigm builds upon the structured paradigm, does not abandon it. – The basic elements of structured languages are all there:

declarations, procedures and functions, calls, execution statements, assignment, etc.

– However, be warned that different OO language designers have tended to call the same thing differently in different OO languages (Smalltalk, C++, Eiffel, Object Pascal, CLU, Java, etc.).

– As programmers in OO languages, you need to know the different terminology used by different OO languages. (For an overview of various OO languages see Appendix A of the book by Booch et al, 3rd. Ed.).


Small to moderate-sized OO programs


Large-sized OO systems

Note encapsulation ofSmall objects (classes)into large objects(packages). Enablesscaling up to designingand developing largeSystems.


Foundations of the Object Model

• For a historical exposé on the various influencing and concurrent factors in the development of OO languages and paradigm, see Section 2.2 (Foundations of the Object Model), pg. 37-40 in Booch et al., 3rd ed.

• We will focus on the meanings of: OO Programming (OOP), OO Design (OOD) and OO Analysis (OOA)


OOP -- Object-oriented programming

• OOP is a way of writing programs 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.– Object-oriented programming uses objects, not algorithms, as its

fundamental logical building blocks (”part of’ hierarchy ).– Each object is an instance of some class.– Classes may be related to one another via inheritance

relationships (the “is a” hierarchy). • A language that supports the above three elements is an

OO language. •


OOD -- Object-oriented design

• While OOP emphasises proper and effective use of particular OO *language* mechanisms, OOD emphasises proper and effective *structuring* of a complex system. In this course (cs3307) we are concerned with this latter, design issue.

• OOD 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.


OOD -- Object-oriented design

• The difference between OOD and structured design is that OOD uses class and object abstractions to logically structure systems; whereas, structured design uses algorithmic abstractions.


OOA -- Object-oriented analysis

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

• Helps identify what should be part of the system and what should not be included, and what interactions system should have with things outside the system. This is also called “boundary analysis”.


OO Programming (OOP), OO Design (OOD) and OO Analysis (OOA)

RequirementsEngineering

SoftwareDesign Programming

OOA OOD OOP

• These three notions are all important and complementary in software/systems engineering.

• OOA produces models used to start OOD the models of which can then be used to implement a system using OOP.


Elements of the Object Model

• There are four fundamental elements of this model:– Abstraction– Encapsulation– Modularity– Hierarchy

• Without any of these four elements, it is unthinkable to be able to build large OO systems.


Elements of the Object Model

• Three relatively minor elements of this model are:– Typing– Concurrency– Persistence

• These elements are useful but not essential in all the systems at the design level.


Abstraction

• An abstraction focuses on the outside view of an object and so serves to separate an object’s essential behavior from its implementation.


Encapsulation

• Abstraction and encapsulation are complementary: – Abstraction focuses on the observable behavior of

an object – Encapsulation focuses on the implementation that

gives rise to this behavior


Encapsulation

• The abstraction of an object should precede the decisions about its implementation.

• Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients.


Encapsulation

• Encapsulation is achieved through information hiding (not just data hiding): – hides all the secrets of an object that do not

necessary for the clients to know:• structure of an object is hidden, • Implementation of its methods.

• No part of a complex system should depend on the internal details of any other part”.


Modularity

• Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.– High cohesion within a module. – Low coupling across modules.

• Modularity and encapsulation go hand in hand.


Hierarchy

• Abstraction, encapsulation and modularity are all useful for dealing with complexity; yet they are not adequate.

• In complex systems, we end up making a set of abstractions, e.g.:– Person (Male doctor | Female doctor)– Male doctor Male & (GP |specialist)


Hierarchy

• A set of abstractions often forms a hierarchy• Identifying these hierarchies in our design can

help deal with problem complexity.• Hierarchy is thus a ranking or ordering of

abstractions.


Hierarchy

• Two important hierarchies to note:– class structure (the “is a” hierarchy) – object structure (the “part of’ hierarchy).

• Single inheritance and Multiple inheritance– “is a” relationship among classes in the hierarchy


Typing

– Type is a precise characterization of structural or behavioral properties which a collection of entities all share. E.g.: the Integer type (1,2,3 ....)

– Typing is used to enforce constraints on operations. • Objects of different types may not be interchanged, or• interchanged in very restricted ways.

– E.g.: operations on variables of mixed types in an expression

– NHM: Data types are important (of course) but they tend to be at the programming (a.o.t. Design) level.


Concurrency

• An automated system may have to handle many different events simultaneously.

• Other problems may involve computation that exceeds the capacity of any single processor.

• May need to: – distribute the solution across a set of computers . – Or do multitasking (time-sharing) on a signle

computer.• May need to model this at design time.


Persistence

• An object takes up space and time during its life.• Persistence encompasses the following:– Transient results in expression evaluation– Local variables in procedure activations– Global variables that outlive a procedure’s life – Data that exists between executions of a program– Data that exists between various versions of a program– Data that outlives the program

• Important to think of these issues in system design.


Summary

• OOA, OOD and OOP address the issues of programming-in-the-large.

• There are several different programming paradigms: procedure-oriented, object-oriented, logic-oriented, rule-oriented, and constraint-oriented.

• Key OO system design properties:– Abstraction; Encapsulation; Modularity; Hierarchy

• Other properties include: Typing, Concurrency and Persistence.

Documents

The Object Model Nazim H. Madhavji UWO 1(c) N.H. Madhavji, 14 August, 2014