Re: Controlled natural language for program debugging
Any comments on the approach to software taken at <http://www.care-t.com>?
Are they trying to achieve the same objective?
Z
On Wed, 4 Aug 2004, Schiffel, Jeffrey A wrote:
> 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
>