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
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
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
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
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?
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
Environments in academia, CASE in industry
CASE in information systems & information technology
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
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
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
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
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
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."
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
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
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
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
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