Re: Controlled natural language for program debugging
John Sowa recently (July 28) posted a note regarding the use of
controlled natural languages in software. His primary point related to
software debugging, and secondarily to CNL as a desirable future means
of programming. I'd like to comment on the lack of rigor in the use of
natural languages throughout the software development life cycle.
The articulation of firm requirements is the first obstacle in the
requirements phase. There are many means now in use. For example,
Structured English has been used as early as the 1970s. This was first
used as a way to document the end points during structured analysis and
design decomposition. It depends on arbitrarily selecting a subset of
English, and applying programming-like constructs (e.g., C programmers'
SE looks a bit like C code). Deciding the lexicon for SE is not normally
a formal process.
Among many other methods is one where requirements documents are written
with "shall", "must", and "will" verbs. This is common among software
engineers working in large, complex embedded systems like avionics.
While this technique plays a little loose with proper English grammar,
the "shalls" and "musts" are interpreted as firm requirements, and the
"wills" are usually interpreted as enhancements. The programming team
extracts unique requirements based on single sentences containing these
verbs and assigns a unique tag to each. The primary advantage in this is
that individual requirements can be traced through the life cycle.
Testing, especially, can assure the original requirements are met. The
downside is that traceability ends up as just chasing tags around; the
semantics of requirements and their interrelationships may be lost.
Often, with this tagging process, a definition language construct allows
each requirement to be placed into the software source code. Typically
little more than a markup similar to an HTML comment surrounding the
unique tag and its requirements text, this allows a grep-like utility to
extract the comments from the code, thus matching coded requirements to
design documents via the tags. Again, what is lost is the meaning and
consistency in requirements.
It would be much better if a CNL could be used during the writing of
requirements. Even if not used to produce code by programming directly
in CNL, verification of the development process end-to-end through
traceability studies, product validation via qualification testing, and
writing accompanying documents like user guides would be enhanced.
Automated development support tools built around CNL could rely on a
consistent, closed semantics.
-- Jeffrey Schiffel