Fundamentally, people use only a few simple tools
to create, understand, or manage
complex systems
One of the most important techniques is termed
abstraction.
3
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
?
4
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
5
Information Hiding
Purposeful omission of details in the
development of an abstract representation
Information hiding is what allows
abstraction to control complexity
6
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
7
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.
8
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”
9
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
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.
Joe’s 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),
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
We’ll 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