Re: Controlled natural language for program debugging
Jeffrey,
I believe that the ability to generate precise
specifications is one of the most important
applications of controlled NLs:
> For example, clear test plans and protocols can be
> difficult to write due to semantically imprecise
> requirements specifications having varying
> interpretations by various team members. This is
> a major problem in those kinds of projects where
> testing is half or more of the time and personnel
> cost, and where both the test results and the entire
> development process are subject to safety-critical
> certification by outside agencies.
I would envision tools that would do something like
the following:
1. Help the systems analyst to analyze and organize
the informal requirements and other documentation,
and aid in the extraction of the basic vocabulary
and the formulation of precise definitions. This
is a task that Skuce's FactGuru is designed to
support, and the language used for the definitions
is a version of Controlled English.
2. Use some internal logic-based tools for the analysis
and debugging of the spec's, and use CNL generators
to echo back to the analyst the current state of the
specifications. During this stage, various languages
could be used: CNLs, graphics such as UML, and whatever
procedural and declarative notations the programmres
and system analysts already know.
3. After the spec's have been analyzed and debugged, a
complete document could be generated automatically
with diagrams and tables in UML and/or other graphic
formats and detailed spec's and explanations in CNL.
This final form would be a computer-generated snapshot
of the exact specifications at that moment. The original
authors of the informal requirements could read it and
compare it to what they wrote and check for errors and
discrepancies. If any problems are found, the programmers
and analysts could go back to step #2 above and continue.
After the spec's are verified against the original
requirements, the programmers could push a button to
have the compilers generate the executable code from
the internal logic specifications.
By the way, I certainly wouldn't rule out the use of
low-level languages such as C for low-level supporting
routines. But the overall structure should be defined in
a declarative, logic-based form that could be translated
automatically to controled English or other NL.
John Sowa