Article View: comp.specification.z
Article #65Please Review & Comment
From: Stephen Hufnagel
Date: Thu, 27 Aug 1992 20:20
Date: Thu, 27 Aug 1992 20:20
145 lines
8382 bytes
8382 bytes
FROM: Steve Hufnagel, The University of Texas at Arlington
hufnagel@cse.uta.edu
and Bud Hammons, The University of Dallas
hammons@phys.udallas.edu
TO: EmTex and Z Specification users
DATE: 26 Aug 92
SUBJ: Please review and comment
We plan to construct a LaTex/Z development environment. Attached
is a brief set of requirements. Your comments, suggestions,
and/or participation would be appreciated. Also, If you know of
existing similar components or capabilities, please let us know.
Term Project: "LaTex Turbo-Development(LTD) Environment"
SOFTWARE ENGINEERING, Part 1
Last Revised: 26 Aug 92
PROBLEM STATEMENT: LaTex is a wonderful medium for multi-person
development of large document sets. In particular, LaTex is good
to represent mathematics --i.e., Z formal specifications of
software systems. The problem is that LaTex documents can be
cumbersome to develop and "debug", compared to using MS-Word or
WordPerfect. Sometimes, a nicely formatted ASCII document from
LaTex is needed --i.e., for E-Mail. LaTex document preparation
is similar to PASCAL programming, before Borland's Turbo-Pascal
There similarly is a need for a *** SIMPLE and PORTABLE *** LaTex
"Turbo" Development (LTD) environment.
GOAL: We will construct an environment for the rapid development
of LaTex documents. This task is intended to provide ease-of-use
design-by-documentation improvements analogous to the software
development productivity improvement "Turbo PASCAL" brought to
the batch style of software program development in the late
1980s. We must duplicate the keys to Turbo-PASCAL's productivity
improvements which were context-sensitive editing,
context-sensitive debugging, context-sensitive help and rapid
detection of errors.
SCOPE: We will make use of Hufnagel's 90/10 principle: 90% of the
gain can be obtained from 10% of the work, if our goal is rapid
development by optimized-reuse-with-improvement rather than
build-it-better-ourselves. We will use existing LaTex
formatters, fonts, and final viewers.
APPROACH: The LTD editor will be optimized for the syntax and
semantics of LaTex and LaTex style files --i.e., ZED.STY and/or
OZ.STY. Its key function is to provide LaTex sensitive editing
and very easy linkage to a LaTex syntax error detector. The
error detector will provide rapid feedback when basic LaTex or
LaTex style syntactic errors (in particular scoping rule
violations --i.e., unclosed fields) are introduced into a
document. We will do a step-wise development of an ASCII-level
WYSIWYG (what you see is what you get) LaTex document development
environment. Our design goal is simplicity and optimization for
local (in particular primitive terminals and PCs) hardware
--i.e., we will check the simpler scoping rules first and later
more complicated LaTex (style) rules. The LTD environment must
be intuitive, easy-to-use, easy-to-change, and we will follow a
design-by-documentation approach. "Step-wise refinement" means
that increasing sophistication and complexity will be introduced
as time goes by ... a form of incremental delivery.
- First, we will do scenario based domain analysis.
- Next, we will do requirements analysis and rapid prototyping
of sample screens.
- NOW THE FUN PART; the LTD system will be designed and
implemented utilizing Z formal specifications, and the system
itself will support the development of Z formal
specifications.
* Oh by the way, we will make this a case study and do both
functional and object-oriented design representation,
before implementation.
- Along the way, we cannot forget the interface design
specifications and test fixtures, preparing for system
integration.
- The easy part will be Ada implementation, because Ada is
intended to provide multi-platform capability and the
pragmatics that Ada must be taught. It should be easy because
we will have a well designed and well specified system (famous
well repeated words!).
- Finally, verification & validation testing will be done by
making the LTD publically available (FTP site).
- Throughout, this will be a team project which must have
multi-developer multi-version configuration management.
The LTD environment will contain:
1. Main User Interface (Shell)
2. Setup Task: Ease-of-change, using an ASCII control file
(*.INI) for all tasks:
- standard LaTex syntax
- ZED.STY syntax
- local display mapping of non-printable fonts.
- edit to local keyboard mapping
- OTHER???
3. Simple (half) Screen LaTex-Sensitive Editor (Can EMACS be
adapted to this task?)
4. On-Line LaTex-sensitive help
5. CheckTex: LaTex basic block structure and syntax checker,
linked to context-sensitive editor and half screen viewer.
6. PrettyTex: Raw LaTex pretty printer (indentation based on
scoping)
7. DrafTex: simple LaTex ASCII formatter. It does not implement
complex LaTex features --i.e., multi-column, varying fonts.
But, it will ASCII justify, itemize, enumerate, number
chapters and section, etc. (similar to the draft mode of
SCRIBE!)
8. (half screen) LaTex draft (ASCII) previewer, with following
versions
- VT-100 terminal
- IBM-PC
- X-Windows
- MS-Windows
- Mac ???
- OS2 ??? (this may be done)
9. once all detectable errors are removed, link to:
- Z cross reference mapper from Summer 92 software
engineering class.
- Z type checker --i.e, FUZZ
- full blown LaTex formatter --i.e., EmTex.
- a full LaTex viewer, if an appropriate display is
available.
10. OTHER: We must have overlooked something?
BACKGROUND: (for those in the dark about what is going on here)
Tex and LaTex are document preparation systems that were
developed by David Knuth and Leslie Lamport respectively for the
American Mathematical Society. Publication quality documents can
be produced, using any editor on any terminal or computer. Tex
is like assembly language. It provides a powerful but "low level
of control", while LaTex is built on Tex and provides high level
abstract command environments, such as chapter, section, or
paragraph. The goal of LaTex is to be easy-to-use so as to let
you focus on the technical writing rather than the formatting.
Z is a formal specification notation. Z, based on set theory and
first order predicate logic, has been developed at the
Programming Research Group (PRG) at the Oxford University
Computing Laboratory and elsewhere for well over a decade. It is
now used by industry as part of the software (and hardware)
development process in both the UK and the US. It is currently
undergoing BSI standardization in the UK.
Technical Details
Message-ID:
<9208272020.AA03944@cse.uta.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!uknet!comlab.ox.ac.uk!cse.uta.eduShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!uknet!comlab.ox.ac.uk!cse.uta.edu From: hufnagel@cse.uta.edu (Stephen Hufnagel) Newsgroups: comp.specification.z Subject: Please Review & Comment Message-ID: <9208272020.AA03944@cse.uta.edu> Date: 27 Aug 92 20:20:37 GMT Sender: hufnagel@cse.uta.edu Lines: 145 X-Mailer: mail-news 2.0.3