CSE503: Software Engineering
Lecture 19  (February 22, 1999)

David Notkin

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