| |
 |
|
|
MARCH 20, 2006
(COMPUTERWORLD)
-
Twenty years ago, software engineer Fred Brooks famously observed that
there was no silver bullet that could slay "the monster of missed
schedules, blown budgets and flawed products." Today, the creation of
software might seem as expensive, trouble-prone and difficult as ever.
And yet progress is being made. While there is still no silver bullet
in sight, an array of new techniques promises to further boost
programmer productivity, at least in some application domains.
The techniques span a broad spectrum of methods and results, but all
are aimed at generating software automatically. Typically, they
generate code from high- level, machine-readable designs or from
domain-specific languages—assisted by advanced compilers—that sometimes
can be used by nonprogrammers.
 |
 |
| Gordon Novak, a computer science professor at the University of Texas at Austin |
|
Gordon Novak, a computer science professor at the University of Texas
at Austin and a member of the school's Laboratory for Artificial
Intelligence, is working on "automatic programming"—using libraries of
generic versions of programs, such as algorithms—to sort or find items
in a list. But unlike traditional subroutines, which have simple but
rigid interfaces and are invoked by other lines of program code, his
technique works at a higher level and is therefore more flexible and
easier to use.
Novak's users construct "views" that describe application data and
principles and then connect the views by arrows in diagrams that show
the relationships among the data. The diagrams are, in essence, very
high-level flowcharts of the desired program. They get compiled in a
way that customizes the stored generic algorithms for the user's
specific problem, and the result is ordinary source code such as C, C++
or Java.
Novak says he was able to generate 250 lines of source code for an
indexing program in 90 seconds with his system. That's equivalent to a
week of productivity for an average programmer using a traditional
language, he says. "You are describing your program at a higher level,"
he says. "And what my program is saying is, 'I can tailor the algorithm
for your application for free.'"
Novak says he intends to expand the system to allow construction of
larger programs and eventually to turn it into a commercial product. "I
hope to move programming up a level, from the writing of code to
programming in terms of abstractions, such as physical models,
financial models and so on," he says.
 |
|
| Douglas Smith, principal scientist at Kestrel Institute |
|
Douglas Smith, principal scientist at Kestrel Institute, a nonprofit
computer science research firm in Palo Alto, Calif., is developing
tools to "automate knowledge and get it into the computer." Kestrel's
development system works with two kinds of knowledge: the skills and
techniques that programmers have—about data structures and algorithms,
for example—and the application knowledge that an end user has.
Specware Features
A programmer starts with Kestrel's Specware, which is a
general-purpose, fifth-generation language that specifies a program's
functions without regard to the ultimate programming language, system
architecture, algorithms, data structures and so on. Specware draws on
a library of components, but the components aren't code. They are at a
higher level and include design knowledge and principles about
algorithms, data structures and so on. Smith calls them "abstract
templates."
In addition, Specware can produce proofs that the working code is
"correct"—that is, that it conforms to the requirements put in by the
user (which, of course, may contain errors). "Some customers want that
for very-high-assurance applications, with no security flaws," Smith
says. Kestrel does work for NASA and U.S. military and security
agencies.
Specware is essentially a productivity tool for programmers, producing
several times as many lines of code as is actually written by the
programmer. But Kestrel has something at an even higher level—a
language called Planware that's specifically for creating scheduling
applications. Smith says users at the U.S. Air Force, who know about
airplanes, runways and air bases but not software, used it to create an
aircraft scheduling system.
"It's a language for writing down problem requirements, a high-level
statement of what a solution should be, without saying how to solve the
problem," Smith says. "We think it's the ultimate frontier in software
engineering. It's what systems analysts do."
In the future, Kestrel will enhance its techniques by incorporating
some of the concepts of aspect-oriented programming that deal with
issues that cut across programs, such as activity logging and
authentication. When users make a policy change related to such
cross-cutting issues, it can entail expensive code changes at many
places in a system. "I want to allow programmers to write policies at a
very high level and then have them automatically enforced," Smith says.
"How to put cross-cutting issues into designs is one of the most important things going on in software engineering right now."
| CODE EXPLOSION |
The whole history of
computer science has been toward increasingly high-level languages —
machine language, assembler, macros, Fortran, Java and so on — and we
are working at the extreme end of that,” says Douglas Smith, principal
scientist at Kestrel Institute.
The higher the programmer goes,
the less code he needs to write and the less he needs to know about
algorithms, data structures and hardware.
When Kestrel and the
U.S. Air Force developed a mission-scheduling application, analysts
using Kestrel’s Planware language were able to produce 17 lines of
Specware code, 74 lines of Lisp code and 189 lines of assembler for
each line written in Planware.
— Gary Anthes
| LINES OF CODE |
LANGUAGE |
LANGUAGE DESCRIPTION |
| 2,500 |
Kestrel Planware |
6GL domain-specific requirements-modeling language, partly graphical, partly textual |
| 43,000 |
Kestrel Specware |
5GL general-purpose functional programming language |
| 186,000 |
Common Lisp |
3GL programming language |
| 472,000 |
Assembler |
Obtained by disassembling the compiled Common Lisp code. Code can be proved to be correct per requirements. |
|
|
|
|
|
