[comp.software-eng] Software Engineering Digest v5n43

soft-eng@MITRE.ARPA (Alok Nigam) (11/11/88)

Soft-Eng Digest             Thu, 10 Nov 88       V: Issue  43

Today's Topics:
                    CASE and the Nov '88 Dr. Dobbs
                       Document Editing System
                             Objective-C
              References on Function Point metric sought
                  Structured Editor vs. Text Editor
         Structured Editor vs. Text Editor -- Summary (Long)
                             Trellis/Owl
              What's a PC? (What's the best environment)
----------------------------------------------------------------------

Date: 8 Nov 88 07:22:54 GMT
From: dewey.soe.berkeley.edu!oster@ucbvax.berkeley.edu  (David Phillip Oster)
Subject: CASE and the Nov '88 Dr. Dobbs

The inside back cover of the Nov. '88 issue of "Dr. Dobbs magazine of
Software Tools" has a funny article about CASE. Basically, the editor
tried to get an article on CASE for his magazine. Applying CASE tools to
the writing process, in this case, slowed the process down by a factor of
five.

------------------------------

Date: 8 Nov 88 18:24:25 GMT
From: panda!teddy!jpn@husc6.harvard.edu  (John P. Nelson)
Subject: Document Editing System

I am looking for information on software engineering-oriented
documentation systems.

We are currently using "troff" for all of our documents, occasionally
using "pic" to imbed pictures and diagrams (we have an internally written
tool that generates "pic" output).  While this fills our needs for the
short term, I'm sure that there must be better solutions.  We have over 50
diskless SUN workstations, and we would like to take advantage of the
CPU power at our disposal.

Most of the WYSIWYG documentation programs seem heavily oriented
towards producing end-user documentation.  As engineers, we like to use
the information in our documents in various ways:  not just as a
end-product hard-copy.  Ideally, we would like to use some kind of CASE
system, but most of these seem like vaporware at the moment.  Barring
that, we would like to use a document system with an open interface:
that lets us get information in and out of the system easily, (perhaps
storing the documents in some kind of database?)  We would like to be
able to imbed pictures into our documents, but our needs are simple:
we mostly generate block diagrams, flow-charts, that sort of thing.

I would like to hear from anyone who is actually USING such a system,
along with it's pluses and minuses.  If you did a comparison investigation
of several such systems, I'd really like to hear your conclusions.  What
I don't need is to be swamped with more vaporware.

Thanks in advance.  I'll summarize any results that I get (unless you
specificly ask me not to include your response).

------------------------------

Date: 10 Nov 88 07:32:37 GMT
From: seanjiam@umn-cs.arpa  (Sean Jiam)
Subject: Objective-C

        I am interested in getting any materials related to Objective-C.
Objective-C is an object oriented language developed by Brad Cox at PPI.
Could anyone please send me references about the language?  Or send me
any typeset documents about the language by E-mail ?  My E-mail address
is seanjiam@umn-cs.cs.umn.edu.arpa.

------------------------------

Date: Tue, 08 Nov 88 08:38:35 PST
From: jon@june.cs.washington.edu
Subject: References on Function Point metric sought

I keep seeing mention of a technique for estimating effort, cost, or errors
in software projects based on something called "function point analysis".
I don't know much about it, but it is apparently based on assessing the
functionality described in the specification, which seems obviously more
useful than measures based on the size or other measurers of the code (which
you don't really know until you're almost done with the project).

Although I've seen it mentioned in trade papers like COMPUTERWORLD, and a
recent posting in SOFT-ENG DIGEST says it is the basis for a software cost
estimating product, I have never seen a paper in a journal that describes
how the metric is calculated, and presents data showing how its predictions
match with actual experience.   COMPUTERWORLD says it was introduced in 1979
by A.J. Albrecht, and IBM researcher, but I find no articles by that author
in THE IBM SYSTEMS JOURNAL since 1979 (actually there is one, but it has
nothing to do with function points or any other metrics).

------------------------------

Date: 4 Nov 88 20:40:00 GMT
From: <Bill Smith> wsmith@cs.uiuc.edu
Subject: Structured Editor vs. Text Editor

I will try to briefly respond to the points raised by Johnny Martin.

First, one should not make generalizations about an editor based on such a
short description.  Leif is a complex program that is more than a "background
syntax checker."  It contains an incremental parser that efficiently
maintains a parse tree that may be consulted to visualize the syntactic
structure of the program as well as locate errors.  Leif is definitely not
slow.

Secondly, there are other ways of categorizing language oriented
editors.  Martin's categorization begs the question by implying that "True
SDE's have great power" and thus must abandon text editing commands to provide
this power.  Leif does not yet provide all of the transformational
power of the ideal philosopher's stone SDE but it provides enough power to
be worthwhile.

While emphasizing that a nice user interface is "a godsend," he assumes that
text editing does not fit in such a user interface.  Consider Richard Waters
article "Program Editors Should not Abandon Text Commands."  Syntax directed
editing is possible within a framework of textual editing and Leif proves
that.  The transformation and holophrasting capabilities espoused by Martin
are possible within the Leif framework although they have not been
implemented yet.  I believe researchers at Berkeley are also independently
developing an editor with similar capabilities to Leif.

Transformational commands are valuable, but is it possible to proved a complete
set of such commands?  Many transformations should be based on semantic
information which may be unavailable because of undecidability of understanding
some aspects of programs.

Martin implies that a programmer only wants to use a language oriented editor
on a fixed, standardized language.  In my research, Leif demonstrates that there
is a demand for easily constructed language oriented editors. In Leif, it
takes only a few hours to create an useful editor once a lexical analyzer and
LALR grammar have been written.  The problem of creating a useful set of
transformations is difficult and time consuming.  Similarly, writing emacs
lisp code to edit in a new language-sensitive mode is non-trivial.

By quickly developing an editor for a special purpose language, the quality
of the language may be improved through an iterative design process.  This
same design process may be used to teach compiler design techniques.
Leif allows many different languages to be edited with no modifications to
the user interface.

The original question that started this discussion demonstrates that the
design of language oriented editors still pose several research questions.
The foremost research issue is the user interface.  Leif provides a user
interface that is radically different that that provided by Xinotech's
Program Composer that Martin champions.

Finally, evidence that language oriented editors (or syntax directed editors)
are not a solved problem is that they are not widespread and they have only
a limited user community.  Research should continue to improve the tools
available to programmers beyond the limited editing techniques available now.

------------------------------

Date: 8 Nov 88 22:35:18 GMT
From: gandalf.cs.cmu.edu!ntanaka@pt.cs.cmu.edu  (Nobuyoshi Tanaka)
Subject: Structured Editor vs. Text Editor -- Summary (Long)

Thank you for your responses.  I must summarize the result but it is hard
job for me to summarize them without spoiling them.  So,  I will COLLECT
(not summarize) all the responses.  I apologize...
Some responses were posted not e-mailed, so I will not include them.
Thanks again.
--Nobu

______________________________________________________________________
From: uwslh!lishka@spool.cs.wisc.edu (Fish-Guts)

     Although "Structured" and "Text" editors are two different
conceptual models, in the real world there are many editors that are
not simply "Structured" and not simply "Text-Oriented."  For instance,
I use Gnu-Emacs at work, which has different "major-modes" for
enterring text or code.  One mode (called "text-mode") word-wraps and
justifies all the text that I type in so that I can concentrate on
writing, and forget exactly how I am formatting a particular line.
This is sort of a "structured-English" mode.  Another mode allows one
to enter text, but formats it in a style suitable for C-code...this
mode aids greatly in writing programs, because the editor formats the
text correctly.  If one wants more structure, Gnu-Emacs can be
programmed (using a built-in Lisp language) to rigidly control the
structure of a language (although noone has done this for anything but
Lisp to date).

     Other editors I have used are *mush* more structured.  One of the
editors on the Xerox 1108 Lisp-Workstations *only* allowed legal Lisp
code to be enterred; everything was rejected before even inserting the
text.  This editor was *highly* structured towards Lisp, and was sort
of a pain to use.  One of my favorite editors came with a
C-environment that was sold for the Commodore 64.  The basic editor
was completely unstructured; i.e. you could enter anything you wanted.
However, it had a command that allowed one to run a C-syntax-checker
over the current edit-buffer to make sure the code that you had just
written conformed to the Kernighan-Ritchie standard.

     If the above sounds too technical, don't worry.  I am just trying
to give examples of "real-world" editors, which typically are *not*
just "Structured" editors and are *not* just "Text" editors.  Most are
somewhere between the two extremes.

     If you are looking for an excellent (although very large) editor,
I would recommend Gnu-Emacs.  It is essentially free (you need only
pay the shipping charge), but it is only available for Unix.  It is
also monstrous (the executable alone is 1 megabyte, and the support
files needed must consume over 2 megabytes), and has an amazing amount
of functions, which makes it a bit hard to learn initially.  However,
once one knows the basics, there is a lot of power available.

______________________________________________________________________
From: johnm@uts.amdahl.com (John Murray)

The XEDIT component of IBM's VM/SP mainframe opsys is a very
powerful text editor. It has a macro interface to the standard
VM command languages EXEC & REXX. Macros are commonly used to
format the screen displays, set reserved and protected fields,
etc. Thus, you can use the editor to build full-screen interactive
menus, for example.

Since the macro programs take over every time the user hits Enter,
or a function key, the facility can be used to do syntax
checking on the fly, justification, pretty-printing, etc. At Amdahl,
we use XEDIT & REXX extensively to check and format Assembler source
code.

There is an imitation of XEDIT for IBM PCs called KEDIT available
from Mansfield Software, which works with Mansfield's Personal REXX.
But it's not nearly as good as the real thing.

______________________________________________________________________
From: celerity!jjw@ucsd.edu

I suspect I will not be alone in saying this.  Most Emacs editors provide
exactly this capability.  It is possible to define editing packages which
define how to recognize and format various kinds of blocks depending on the
kind of file being editted.  "Standard" packages are often supplied and it
is possible to define your own if you don't like the standard.  It is also
possible to redefine what key strokes cause which editing operations so if
you want you can make your Emacs behave like vi, Wordstar, ...

______________________________________________________________________
From: DORFMAN@ECLA.USC.EDU

        On October 25 you inquired about Structured Editors in the
Software Engineering Digest.  Mr. Gary Pace of my organization (Lockheed
Missiles & Space Co., Sunnyvale, Calif.) suggested that you contact
Xinotech Research about their editor called Program Composer:
                Xinotech Research, Inc.
                Technology Center, Suite 213
                1313 Fifth St. SE
                Minneapolis, Minn. 55414
                        612-379-3844

        Mr. Pace may be contacted at 408-742-7791; or I will forward to
him any messages you send via E-mail.  We would also be interested in
your summary of responses.

                                                Merlin Dorfman
                                                408-756-8204
                                                DORFMAN@ECLA.USC.EDU

------------------------------

Date: 8 Nov 88 05:03:42 GMT
From: kehyoe@umn-cs.arpa  (Ong Keh Yoe)
Subject: Trellis/Owl

        I was wondering if anyone could send me any articles in
nroff / troff or TeX / LaTeX format or even plain text on an
Object Oriented Programming Language, called Trellis / Owl.  I
have a presentation soon, and my material presently is very
sparse.  Trellis / Owl has been developed at DEC.  My main
interests are on it's language features to support OOP.  Please
send me any material by E-Mail to kehyoe@umn-cs.cs.umn.edu.arpa.

------------------------------

Date: 8 Nov 88 00:05:12 GMT
From: texbell!killer!pollux!ti-csl!pf%csc.ti.com@bellcore.bellcore.com  (Paul Fuqua)
Subject: What's a PC? (What's the best environment)

   >N.B., most if not all of the advantages of an integrated LISP
   >environment cited in the above articles are also present in
   >Smalltalk.

That's the point:  it's not the language, per se, it's the integrated
environment.  Lispms just seem to be better-known.  And, gradually,
environments for lesser languages are catching up to those that already
exist for Lisp and Smalltalk (check out Saber-C).

So what got Lisp and Smalltalk there first?  My vote goes to the
object-oriented aspect of both languages, which is also filtering out to
lesser languages (I see C++ as a broader dialect of C).

   >                           It also supplies real structure
   >for your data, instead of forcing everything to look like a list.

Most modern Lisps provide lists, arrays, structures, and "objects" (as
in Flavors or CLOS).

------------------------------

End of Soft-Eng Digest
******************************