Abstraction

Tools for Programming

Complex Software

Fundamentally, people use only a few simple tools

to create, understand, or manage
complex systems
One of the most important techniques is termed
abstraction.

Roadmap

In this chapter we will consider abstraction,

which is the most important tool used in

the control of complexity
We will examine various

abstraction mechanisms
We will present a short

history of the development of

abstraction tools

Abstraction
Abstraction is the purposeful suppression, or hiding,
of some details of a process or artifact,
In order to bring out more clearly other aspects,
details, or structure

Information Hiding
Purposeful omission of details in the

development of an abstract representation

Information hiding is what allows

abstraction to control complexity

Abstraction in an Atlas

Think of an atlas, and the various different levels of maps:

A map of the world, contains mountain ranges, large political boundaries
A map of a continent, contains all political boundaries, large cities

A map of a country, contains more cities, major roads

A map of a large city, roads, major structures

A map of a portion of a city, buildings, occupants

Levels of Abstraction in
Object Oriented Programs
At the highest level of abstraction we view a
program as a community of interacting objects
(and interacting programmers).

Important characteristics here are the lines of

communication between the various agents.

Abstraction in OO Programs -Packages and Name spaces

The next level of abstraction is found in some (but not all)

object oriented languages

A package, Unit or Name Space allows a programmer to

surround a collection of objects (a small community in itself)

with a layer,
And control visibility from outside the module
Package Data
Structures

Abstraction in OO Languages -Clients and Servers

The next two levels of abstraction considers the

relationship between two individual objects

Typically one is providing a service, and the other

is using the service

Client

Server

Two layers of abstraction:

view from the client side / view from the server side

10

Abstraction in OO languages -Description of Services

In a good object-oriented design we can describe the services

that the server provides without reference to actions that the

client may perform in using those services
We define the nature of the services that are offered, but not

how those services are realized.

Joes Data Structure Warehouse

Services offered:
void push(Object val);
Object top();
void pop();

$2.00
$1.00
$0.75

Levels of Abstraction in OO -Interfaces

11

Interfaces are one way to describe services at

this level of abstraction:

interface Stack {
public void push (Object val);
public Object top () throws EmptyStackException;
public void pop () throws EmptyStackException;
}

Levels of Abstraction
An Implementation

12

Next we look at the same boundary, but from the

server side:
public class LinkedList implements Stack ... {
public void pop () throws EmptyStackException {
...
}
...
}

Concern here is with the high level approach to

providing the designated service

13

Levels of Abstraction -- A Method

in Isolation
Finally, we consider the implementation of each
method in isolation:
public class LinkedList implements Stack ... {
...
public void pop () throws EmptyStackException {
if (isEmpty())
throw new EmptyStackException();
removeFirst(); // delete first element of list
}
...

14

Summary:
Levels of Abstraction
Interface
Implementation
Strategy
Methods

Every level is important, and often

we move quickly back and forth between levels

15

The name of the game:

Finding the right level of abstraction

To determine what details are appropriate at each

level of abstraction,
And, more importantly, what details should be omitted
One does not want to ignore or

throw away important information

But one does not want to

manage too much information,

Or have the amount of information hide critical details

Abstraction

16

Forms of Abstraction
Division into parts

Specialization
Multiple views

17

Is-a and Has-A abstraction

Two of the most important types of abstraction
are the following:
Division into parts -- Has-a abstraction
Division into specialization -- Is-a abstraction

Both is-a and has-a abstractions will reappear in

later chapters and be tied to specific
programming language features

18

Has-A Abstraction
Division into parts takes a complex
system, and divides into component
parts, which can then be considered in isolation.
Characterized by sentences that have the
words has-a:
A car has-an engine, and has-a transmission

A bicycle has-a wheel

A window has-a menu bar

Allows us to drop down a level of complexity when we

consider the component in isolation

19

Is-a Abstraction
Is-a abstraction takes a complex
system, and views it as an instance of
a more general class
Characterized by sentences that have the
words is a:
A car is a wheeled vehicle, which is-a means of

transportation

A bicycle is a wheeled vehicle

A packhorse is a means of transportation

Allows us to categorize artifacts and information and

make it applicable to many different situations

20

Encapsulation and
Interchangeability
An important aspect of division into parts is to

clearly characterize the connection, or

interface, between to components
Allows for considering multiple

different implementations of the same interface

For example, a car can have several different

types of engine and one transmission

21

The Service View

Another way to think of an interface is as a way

of describing the service that an object provides

The interface is a contract for the service
If the interface is upheld, then the service will be

provided as described.
Joes Data Structure Warehouse
Services offered:
void push(Object val);
Object top();
void pop();

$2.00
$1.00
$0.75

23

A measure for dependency:

Coupling
Coupling is the amount of dependency among

modules.
A system with many dependencies has high

coupling.
Good systems have low coupling

Low coupling is a major pattern (advice) in

assigning responsibilities to modules.

24

Degree of Coupling
The degree of coupling between two components can be
qualitatively measured by determining the effects of changing
the contract or interface between two components or systems.
For example:
What would happen if you added or deleted a property from a class?
What would happen if you changed the data type of a column in a table?
What would happen if you added a column to a table?
What would happen if your database server changed from SQL Server to

mySQL or Oracle?

The degree of pain that each of these changes would cause you
is a good qualitative measurement of how tightly coupled your
components are to the components they depend on

25

Other Types of Abstraction -Composition

While is-a and has-a are two important types of
abstraction, there are others
Composition is one example; a form of has-a;
characterized by the following:
Primitive forms
Rules for combining old values to create new values
The idea that new values can also be subject to further

combination

Examples include regular expressions, type systems,

windows, lots of other complex systems

26

Composition in the Creation of

User Interfaces

Example of Composition
Regular Expressions

27

(empty set) denoting the empty set.

(empty string) denoting the set containing only the "empty" string, which has no
characters at all.

(literal character) in denoting the set containing only the character .

(concatenation) denoting the set { | in and in }.

For example {, }{, } = {, , , }.

(alternation) | denoting the set union of and .

For example {, }| , , = {, , , }.

(Kleene star) denoting the smallest superset of that contains and is closed
under string concatenation.
This is the set of all strings that can be made by concatenating any finite number

(including zero) of strings from .

For example, 0,1 is the set of all finite binary strings (including the empty string),

and ,

= {, , , , , , , , , }.

28

Design Patterns
Patterns are another attempt to document and

reuse abstractions

Patterns are description of proven and useful

relationships between objects; which can help

guide the solution of new problems

Example pattern, Proxy:

Client

Proxy

Server

Well have many more patterns in a later chapter

29

A Short History of Abstraction

Mechanisms
Another way to better understand OOP is to put it in
context with the history of abstraction in computer
science:
i.

Assembly languages

ii.

Procedures

iii.

Modules

iv.

ADT

v.

The Service View

vi.

Objects

vii. The future....

30

ENIAC The First Electronic

Computer

31

Assembly Languages
Assembly languages and linkers were perhaps the first
tools used to abstract features of the bare machine.
Addresses could be represented symbolically, not as a

number

Symbolic names for operations

Linking of names and locations performed automatically

Binary

10110000 01100001

Hexa.

B0 61

ASM

MOV AL, 61h ; Load AL with 97 decimal (61 hex)

32

Procedures and Functions

Libraries of procedures and functions (such as

mathematical or input/output libraries) provided

the first hints of information hiding
They permit the programmer to think about

operations in high level terms, concentrating on

what is being done, not how it is being
performed
But they are not an entirely effective mechanism

of information hiding

33

Information Hiding
The Problem of Stacks
int datastack[100];
int datatop = 0;
void init() // initialize the stack
{ datatop = 0; }
void push(int val) // push a value on to the stack
{ if (datatop < 100) datastack [datatop++] = val; }
int top() // get the top of the stack
{ if (datatop > 0) return datastack [datatop - 1]; else return 0; }
int pop() // pop element from the stack
{ if (datatop > 0) return datastack [--datatop]; else return 0; }

Where can you hide the implementation?

34

Modules

Modules basically provided

collections of procedures and data

With import and export statements
Solves the problem of encapsulation

35

Parnas's Principles
David Parnas described two principles for the
proper use of modules:
One must provide the intended user of a module

with all the information needed to use the module

correctly, and with nothing more
One must provide the implementer of a

module with all the information needed to

complete the module, and nothing more

36

What if we need more than one stack?

37

Abstract Data Types

An Abstract Data Type is a programmer-defined data type that

can be manipulated in a manner similar to system-provided data
types
Must have the ability to instantiate

many different copies of the data type

Data type can be manipulated using provided operations,

without knowledge of internal representation

ADTs were important not because they were data structures,

but because they provided an easily characterized service to the
rest of an application

38

Three Eons of History

Looking at this history, we can separate it into
three periods of time:

Functionality of
the application

Data types used in

an application

services provided
by objects in the
application

39

Objects ADT's with Message Passing

Characteristics of Objects:
Encapsulation -- similar to modules
Instantiation -- similar to ADT's
Messages -- dynamic binding of procedure names

to behavior
Classes -- a way of organization that permits

sharing and reuse

Polymorphism -- A new form of software reuse

using dynamic binding

40

OMG one picture MDA

Vertical
Domains
Core
Technologies

Core Target
Platforms

Pervasive
Services

41

What Does the Future Hold

What will be the next evolutionary step in software?
Prediction is hard, particularly about the future
However, once you have accepted the idea of an

application formed from interacting agents:

There is no reason why those components must exist

on the same computer (distributed computing)

Or be written in the same language (components)

So some of the trends we see today in software are

natural results of the OOP mind set