1

Procedural Abstraction
Dr. Roger T. Alexander
University Services Building, Room 240
Voice: 491-7026, Fax: 491-2466
[email protected]
http://www.cs.colostate.edu/~rta/courses/cs414
2
Topics
Abstraction
Defining procedural abstractions
Implementing procedural abstractions
Abstraction
Achieving economy of scale
4
What is Abstraction?
Way to do decomposition productively by
changing level of detail to be considered
When we abstract
We agree to ignore certain details in an effort
to convert original problem into simpler one
An abstraction is
A many-to-one mapping from many detailed
views to a single less-detailed view
2
5
What is Abstraction (continued)
Allows us to treat different things as if they
were the same
Separation of relevant from irrelevant.
Relevancy depends on context of problem.
One mans abstraction is anothers detail!
6
What is Abstraction (continued)
Separation of procedure definition from
invocation
Makes two important methods of
abstraction possible in programming:
Abstraction by Parameterization
Abstraction by Specification
7
Abstraction by Parameterization
Allows single program text to represent as
single abstraction a potentially infinite set
of computations.
Abstracts away the identify of the data
being used
Defined with formal parameters
Used with actual parameters
8
Abstraction by Parameterization
(continued)
Irrelevant
Identity of actual data.
Relevant:
Presence, number, and types of arguments
Generalizes modules
Makes them useful in more situations.
Important for achieving generality in
programs
3
9
Abstraction by Parameterization
(continued)
Example:
int squares(int x, int y)
{
return x * x + y * y;
}
squares(2,3)
The values 2 and 3 are actual parameters of
function squares
x and y are its formal parameters.
10
Abstraction by Specification
Allows us to abstract from the computation
described by a procedure body to its end
result.
We introduce a specification of a procedures
internal effect
We consider the meaning of a call to be
based on this specification.
Focuses on behavior that user can count
on (but not how).
11
Abstraction by Specification
(continued)
Abstracts from details that implement
behavior.
What is done is relevant
How it is done is irrelevant
Key Advantage: Because implementation
is irrelevant, it can vary independent of the
abstraction
12
Abstraction by Specification
(continued)
Abstraction
a
I1 In
Implementations
4
13
Properties of
Abstraction by Specification
Locality
Implementation can be read or written without
needing to refer to implementation of any
other abstraction
Modifiability
Effects of program modification and
maintenance bounded (ideally).
14
Benefits of
Abstraction by Specification
Users of a procedure do not have to look
at the body in order to use it.
Users can ignore the detail of procedures
computation.
Procedural Abstraction
Creating Virtual Machines
16
Procedures
Combine methods of abstraction by
parameterization and abstraction by
specification
Formal mapping from a set of inputs
(domain) to set of outputs (co-
domain/range)
Allow us to implement operations not
found in underlying machine architecture
5
17
Defining procedural abstractions
The parts of a procedural abstraction
Total vs. partial procedures
Side effects
Implementing procedural abstractions
Defensive vs. non-defensive programming
Optimization
Procedural abstraction applies to any language,
no matter what the units are called:
Procedures (e.g. Ada, Modula,...)
Functions (e.g. C, ML,...)
Methods (e.g. java,...)
18
Procedural Abstractions
A procedure maps from input arguments to outputs:
May modify its arguments.
May have side effects.
May return a result.
Aim for Referential Transparency
Procedure does the same thing, no matter where it
is used.
A procedural abstraction ("specification"):
Describes what a procedure does, ignores how it
does it.
Different implementations of the abstraction can
differ over details.
One implementation can be substituted for another.
19
Procedural Abstractions
Advantages
Achieves locality
Programmers don't need to know implementation
details
Achieves modifiability
Replacing an implementation does not affect the rest
of the system
Achieves language Independence
Implementation could be any programming language.
20
Defining Abstractions
Abstractions need to be precisely defined.
Formally (mathematically): very precise; can be automatically checked.
Informally (e.g. natural language description): less precise, easier to
read and write.
Need to define five things:
Way in which the procedure communicates (input/output parameters).
Conditions under which the procedure will work.
What the procedure achieves.
Any side effects (changes to global variables or system state).
Any exceptions raised.
6
21
Total versus Partial Procedures
A total procedure:
Works for any input.
Has no requires clause (equates to true).
A partial procedure:
Works for some of the possible inputs.
Requires clause places restrictions on the behavior of the
procedure.
The procedure is only guaranteed to work if the requires clause
is met.
22
Side-effects
If a procedure modifies its environment in any way, this
is a side effect.
E.g. modifying global variables.
E.g. allocating or de-allocating memory.
E.g. Writing to the output stream.
E.g. reading characters from the input stream.
A pure function has no side effects
All communication is through parameters and return result.
All programming languages allow procedures/functions
to have side effects.
input/output is impossible otherwise(!)
However, side effects make a program harder to understand and
more error prone.
23
Specifying Side-effects
Use of modifies clause.
24
Different Implementations
There are many possible implementations:
Linear search - slow but easy to implement.
Binary search - fast for large lists.
Etc.
These satisfy the abstraction, but:
What if x occurs in list more than once?
What if a is not sorted?
If we care about any of these details, they should be described in
the abstraction.
7
25
Procedure Design
Procedural Abstractions:
Have both clients and implementor.
The abstraction defines the service offered to the clients.
The implementor is free to provide the service in whatever way
seems best (As long as it meets the specification).
The abstractions should:
Constrain things that matter to the client.
E.g. Whether sort creates a new list or modifies the old one.
Not constrain things that don't matter to the client.
E.g. speed, efficiency, algorithm used.
Under-determination
Some aspects of behavior are not defined.
E.g. search was underdetermined as we didn't say what to do if the
element occurs more than once in the list.
An under-determined specification may have implementations that
behave differently.
26
Desirable Properties of Procedures
Minimally specified
Only constrained to the extent required by the clients.
General
Able to work on a range of inputs (or input types).
E.g. search could be generalized to work on any array types (might
need to pass it a comparison function).
However, generalizing a procedure is only worthwhile if it becomes
more useful.
Simple
A well-defined and easily explained purpose.
If you can't think of a simple name for your procedure, it's probably
overly complex (i.e. not cohesive).
Non-trivial
Should achieve something significant.
Don't decompose a program down into too many tiny pieces.
27
Defensive Programming
Murphy's law
Anything that can go wrong will go wrong.
E.g. If you rely on precedence order for expressions, you'll make
a mistake, so put parentheses everywhere.
E.g. Clients will call your procedure with the wrong inputs, will
forget to initialize data, etc, so always check (not necessarily)!
Partial Procedures are Problematic
Sooner or later someone will violate the precondition
(requires clause).
Solution:
Try to make them total, or
Add code at the beginning that checks that requires clause is
met.
28
Further Advantages of Abstraction
Encapsulation
All the important information about the procedure is stated explicitly in one
place.
The detail is hidden.
Testing
Without an abstraction defined, how will you know if your procedure is
correct?
The abstraction will suggest unusual ("off nominal") test cases
Optimization
Follow Michael Jacksons advice on optimization:
Dont do it.
If you must, postpone until later.
It is often (extremely) hard to predict where bottlenecks will occur.
Dont try, youre not that good (focus on the behavior instead!).
Use abstractions to implement the whole program, then just optimize those that
need optimizing.
Error tracing
Abstractions help you build firewalls that stop errors from propagating
We want to catch errors (failures) as close to the point of origin as possible.
8
29
Elements of Program Style
Program code is an expression of a design
that will change.
Write clearly, avoid cleverness.
Use library functions.
Clarity is more important than efficiency.
Parenthesize to avoid ambiguity.
Avoid confusing variable names.
Don't patch bad code - rewrite it!
Don't over-comment.
Don't comment bad code - rewrite it!
Format the code for readability.
As a design, program code should convey
intellectual clarity.
Clarity is better than small gains in
Efficiency.
Make it right before you make it faster.
Make it robust before you make it faster.
Make it clear before you make it faster.
Choose a data representation that makes
the program simple.
Assumptions are dangerous.
State your design and implementation
assumptions clearly.
Test inputs for validity and plausibility.
identify bad input, recover if possible.
Use self-identifying input.
Make input easy to prepare.
Make output self-explanatory.
Make sure the code "does nothing
gracefully.
Program code represents the result of
problem solving.
Write first in a simple pseudo-code, then
refine.
Modularize.
Write and test a big program in small pieces.
Instrument your programs.
Measure for bottlenecks before you
optimize.
Watch for "off-by-one" errors.
Test the "boundary conditions.
Check some answers by hand
Adapted from Blum, 1992, p278-9 12
30
Summary
Procedural abstractions are useful.
They express the contract between client and implementor.
They are helpful for testing.
They facilitate modification.
Procedural abstractions must be defined precisely.
Abstract does not mean the same as vague!
Strive for referential transparency.
This process works at all levels.
The principles shown here for procedures apply to all design levels:
Specify the abstraction precisely.
The specification should tell you everything you need to know to use the
component.
The specification should not include unnecessary design information.
Try it for:
Systems, Modules, Packages, Procedures, Loops, ...
31
References
van Vliet, H. "Software Engineering: Principles and
Practice (2nd Edition), Wiley, 1999.
Liskov, B. and Guttag, J., "Program Development in
Java: Abstraction, Specification and Object-Oriented
Design", 2000, Addison-Wesley.
Blum, B. "Software Engineering: A Holistic View". Oxford
University Press, 1992
Questions?