v Tools and analysis will be the focus of the
next six lectures
Ø In some ways, at least the analysis part
might be close to the specification topics covered last week
Ø But the focus will be much, much closer to
the source code
v Today
Ø Quick overview
§
Environments
vs. tools
§
A bit of
history (on environments --- we'll focus on tools after this)
§
Static vs.
dynamic tools
Ø The rest of the time, we'll focus on a set
of interesting tools and underlying techniques including
§
Lackwit/type
inference
§
LCLint/lightweight
checking of C code
§
Purify/dynamic
bounds & memory checking
§
Slicing/PDGs
§
Dynamic
invariant checking
§
Reverse
engineering tools/Rigi
§
Software
summarization tools/reflexion model tools
v What's a tool?
Ø Merriam-Webster
§
a handheld
device that aids in accomplishing a task; the cutting or shaping part in a
machine or machine tool; a machine for shaping metal
Ø From Jargon File (4.0.0/24 July 1996)
§
A program
used primarily to create, manipulate, modify, or analyze other programs, such
as a compiler or an editor of a cross-referencing program
Ø For these lectures, I will omit
“intellectual” tools, focusing instead on this kind of tool
v What’s analysis?
Ø Merriam-Webster
§
an
examination of a complex, its elements, and their relations
Ø What do I mean (for these lectures)?
§
Computer-supported
“reasoning” that is intended to aid a programmer in understanding and improving
a software system
v Tools you probably use
Ø Compilers
Ø Editors
Ø Debuggers
§
How often?
Ø Profilers
§
How often?
Ø Configuration management and version
control tools
Ø GUI builders?
§
What kinds,
how frequently?
Ø Testing tools?
§
What kinds,
how frequently?
Ø What else?
v Environments and CASE
Ø CASE, Computer Aided Software Engineering
§
Using
computers to help people engineer software
Ø Environments vs. tools
§
Environments:
Integrated, user interacts with a single environment, environment is
responsible for managing consistency, sharing of representation
§
Tools:
Standalone, user interacts with each tool separately, user must apply tools
appropriate to ensure consistency, independent representations
Ø Why environments?
§
“During the
past decade there has been a growing realization [that software tools] have by
and large failed to reduce cost and improve quality. … [T]he essence of an environment
is that it attempts to redress the failures of individual software tools
through synergistic integration.” Osterweil, 1981
§
“Current
software development environments often help programmers solve their
programming problems by supplying tools such as editors, compilers, and
linkers, but rarely do these environments help projects solve their system
composition or management problems.”
Notkin & Habermann, 1979
Ø What are environments?
§
“A software
development environment consists of a set of techniques to assist the
developers of software systems, supported by some (possibly automated) tools,
along with an organizational structure to manage the process of software
development. Historically, these
facilities have been poorly integrated.”
Wasserman, 1981
Ø Where can the computer help?
§
Interaction
and rich user interfaces
§
Translation
of high-level descriptions
§
Maintaining
consistency among large and complex representations
§
Encoding
knowledge about an activity, organization or process
§
Broader
availability of pertinent information
§
Communication
medium
Ø The “promise” of CASE
§
“The CASE
technology is a combination of software tools and methodologies. … Spanning all
phases of the software lifecycle, not just on implementation, CASE is the most
complete software technology yet.” McClure, 1989
Ø “To be truly successful, a CASE product
must literally support application development from womb to tomb, from the
initial conception of an application through its long-term maintenance.” Towner, 1989
Ø “CASE provides the rigorous automated
support required to build flexible, high-quality information systems
quickly.” Mylls, 1994
v Environments in academia, CASE in industry
v CASE in information systems &
information technology
Ø The MIS world of CIOs
Ø Application Development (AD)
Ø Information Engineering (IE)
Ø Methodology plays a key role
Ø Upper CASE vs. lower CASE
v (A few) classic environments
Ø Interlisp (Xerox PARC), Teitelman &
Masinter, 1981
§
Language-centered
environment
§
Very fast
turnaround for code changes
§
Monolithic
address space
§
Environment,
tools, application code commingled
§
Code and data
share common representation
Ø Smalltalk-80 (Xerox PARC), Goldberg, 1984
§
Language-centered
environment (OO)
§
Classes as
first-class objects, inheritance, etc.
§
Environment
structured around language features (class browsers, protocols, etc.)
§
Rich
libraries (data structures, UI, etc.)
Ø Unix (Bell Labs)
§
Toolkit-based
environment
§
Simple
integration mechanism
§
Convenient
user-level syntax for composition
§
Standard
shared representation
§
Language-independent
(although biased)
§
Efficient for
systems’ programming
Ø Cedar (Xerox PARC), Teitelman, 1984
§
Intended to
mix best features of Interlisp, Smalltalk-80, and Mesa
§
Primarily was
an improvement on Mesa
§
Language-centered
environment
§
Abstract data
type language
§
Strong language
and environment support for interfaces
§
Key addition:
garbage collection
v Commercialization of CASE
Ø Not wildly successful at all
§
“Despite the
many grand predictions of the trade press over the past decade,
computer-assisted software engineering (CASE) tools failed to emerge as the
promised `silver bullet.’” Guinan, Cooprider, Sawyer; IBM Systems Journal, 1997
§
“CASE tools
are sometimes excessively rigid in forcing the user to input too much
information before giving usable results back. CASE tools also typically don't
adapt to multiple or in-house methodologies…” www.confluent.com; 1997
v Myth #1 of CASE, Integration is job #1
Ø Integrating tools helps, but only if the
tools are the “right” tools
§
That is,
integration is a second order effect, not a first order effect
v Myth #2 of CASE, Graphics inherently
dominate text
Ø “A picture is worth a thousand words”
Ø This is a complicated issue
§
Screen real
estate
§
Sharing with
other tools
§
Sharing with
other people
v Myth #3 of CASE, Software tools are more
important than intellectual tools
Ø False
Ø Software tools are important but are
generally a second order effect
§
Sometimes
software tools can qualitatively change the world, although usually indirectly
v Myth #4 of CASE, Tool adoption is a
consumer problem not a producer problem
Ø False
Ø Organizational issues (Orlikowski)
§
“[To] account
for the experiences and outcomes associated with CASE tools, researchers should
consider the social context of systems development, the intentions and actions
of key players, and the implementation process following by the organization.”
v Myth #5 of CASE, Goal should be to change
how software engineering is done
Ø No, it should be to enhance how people are
doing software engineering
v Myth #6 of CASE, The tools can handle
creative aspects of software engineering
Ø Tools frequently fail to be useful because
they make poor judgments about what the human does well and what the computer
does well
v Tools
Ø Assuming you could/would build most
commercial products with languages like Scheme, ML, Haskel, CLP(R), Prolog, etc.,
which tools would you give up?
§
Probably none
Ø However, the underlying premises and
implementation structures for many tools and language implementations are
closely related
§
The program
dependence graph representation is heavily used in program optimization and
parallelization, as well as in software engineering tools
§
Type
inference is being used increasingly broadly as the basis for some software
engineering tools
v Static vs. dynamic
Ø Tools are all-but cleanly divided into two
categories: static and dynamic
Ø Static tools
§
Analyze the
program text
§
Are usually
sound
Ø Dynamic tools
§
Analysis
based on execution of the program
§
Are
inherently unsound
v Types
Ø Type systems fit into the definition of
analysis we’re using
Ø These systems are intended to eliminate
some classes of errors in programs
Ø Programs in a language are analyzed and
ones that don’t pass type checking are considered illegal programs (static
typing)
Ø During execution checks are made to ensure
that bit representations are never misinterpreted (dynamic typing)
Ø Type inferencing
§
A downside of
type systems is that the programmer has to write more “stuff”
§
Type
inferencing has the compiler compute what the types of the expressions should
be
§
The
programmer writes less down
§
The
programmer has less to change when the program is modified
§
The
programmer gets almost all the benefits of static typing