MDAY@XX.LCS.MIT.EDU ("Mark S. Day") (03/16/88)
Soft-Eng Digest Tue, 15 Mar 88 Volume 4 : Issue 22
Today's Topics:
Adding Object Oriented Facilities to a Language
Looking for Ideas on Writing Maintainable Code
Incompetence and Whistleblowing
Licensing Software Engineers
Reusable Software Libraries
Shared Libraries (2 msgs)
Speed of Higher-Level Languages
What is CASE?
CASE Tools and DFDs/Bubble Charts
CASE Tools and JSD
----------------------------------------------------------------------
Date: Mon, 14 Mar 88 16:31 GMT
From: "Donal O'Mahony - omahony@tcdcs.uucp" <mcvax!cs.tcd.ie!OMAHONY@uunet.UU.NET>
Subject: Adding Object Oriented Facilities to a Language
I am in the process of preparing a proposal to add-on Object Oriented
facilities to a special purpose language for real-time applications. The
problem is that I have no access to compiler source code.
I am thinking of implementing the concepts of class,instance,inheritance
etc. as a pre-processor to the language, as I know of C++ implementations
that are done this way.
Can anybody point me to references describing similar work?
The general idea, is to develop a class hierarchy of reusable software
that is accessable to the programmer - If anybody has any comments on this,
they would be welcome.
Donal O'Mahony omahony@cs.tcd.ie or (older mailers) omahony@tcdcs.uucp
Computer Science Dept.,
Trinity College,
Dublin,
Ireland
------------------------------
Date: Mon, 14 Mar 88 13:52 EST
From: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>
Subject: Looking for Ideas on Writing Maintainable Code
Hello,
I'm gathering information on "Writing Maintainable Code." I'm interested in
any tips/pointers people have on how to teach someone to write maintainable
code.
What \is/ maintainable code? How do I recognize it when I see it? How do
I know it when I'm writing it?
There seem to be both language-specific principles (e.g. use DEFVAR in Common
LISP to declare special variables), and language-nonspecific principles (e.g.
keep firm abstraction barriers).
If you have any ideas, however large or small, on writing maintainable code,
I'd enjoy hearing them. And please feel forward to forward this message
to anyone you think would have ideas.
Thank you,
Stephen Robbins
(STEVER@OZ.AI.MIT.EDU,
STEVER@SCRC-RIVERSIDE.ARPA)
------------------------------
Date: Tue, 15 Mar 88 07:21:59 PST
From: bowles@lll-crg.llnl.gov (Jeff Bowles)
Subject: Incompetence and Whistleblowing
Re: Incompetence
I've always defined incompetence as "not doing your job and standing in
the way of anyone else getting it done," which means that the
incompetent is not necessarily ignorant of "how to get it done" but
refuses to.
Ignorance is forgivable, and can be taken care of with
education/training/ experience. Incompetence isn't. I quit a job after
being badly brutalized by an incompetent supervisor --- I could've just
transferred within the company, but "enough was enough." (He's still
there, by the way, and I expect he'll be there forever.)
Re: Whistleblowing
It's hard to walk the line between loyalty (whatever that means, these
days) to your employer and loyalty to those who end up with your
product. If you're told "it needs to be shipped Tuesday" and you know
damn well that it can't be ready by then, what do you do? Steadfastly
refuse to start, or what?
Too many projects have been taken out of developers hands before
complete, and too many projects have been delayed by developers trying
to make it utterly perfect when 98% is enough. What should you desire
in a product when it's deployed? [Speaking as one who's done software
support, I'd say you want to: a) know what the product does, and
document that well; b) know what it doesn't do reliably, and if
possible, excise that code or make it unreachable; c) test well enough
to know what it doesn't do, and document that.
A consultant working at Bell Labs a few years back was pretty good about
overcoming "group-think." If you were sitting in a room with a bunch of
people on a project trying to avoid thinking about how to FIX a problem
(we've all seen this) he'd be the first to say "look, if it's broken here,
let's fix it now - it'll be better than shipping it broken." My supervisor
at the time would say "you can fix it now, or you can fix it later. It'll
be more expensive later."
The CYA (cover your ass) part of this is to make sure that if it's not fixed
"now", you have told the business-types enough that they'll listen to you
NEXT TIME.
Jeff Bowles
------------------------------
Date: 11 Mar 88 14:37:18 GMT
From: bsu-cs!dhesi@iuvax.cs.indiana.edu (Rahul Dhesi)
Subject: Licensing Software Engineers
>Is there any reason why software engineers
>should be exempt from the sort of licensing requirements found in other fields?
Yes indeed. Licensing prevents employers from hiring the people *they*
believe are the best, instead of being forced to hire people that
*somebody else* considers competent.
If an employer would really rather let somebody else make his hiring
decisions, he can always specify that job applicants be certified
(e.g. CDP, CCP). Clearly most employers don't feel this way, because
most don't require certification. I see no reason to believe that a
certificate or license is a more reliable indicator of competence than
evidence of education or achievement at work.
I would be happy to see a licensing agency put its money where its
mouth is, by accepting all liability for the failures of those that it
licenses as competent. Until that happens, and the ABA accepts
liability for all legal malpractice by its licensees, and the AMA
accepts liability for all medical malpractice, and so on, I will refuse
to believe that licensing is anything other than an attempt to simply
keep wages artificially high.
Political follow-ups should probably be emailed or sent to
talk.politics.misc (where I won't see them).
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
------------------------------
Date: 14 Mar 88 14:27 EST
From: EVERHART%ARISIA.decnet@ge-crd.arpa
Subject: Reusable Software Libraries
Re: The Cynic's Guide to software engineering:
Software engineering in most places does NOT use its
resources over and over again as hardware engineering does.
A few reasons:
1. Resources not available or not known.
Discussion:
The engineer who wants to re-use code needs to know where to
look for candidate code. Frequently this can be done only within
his own disk area, or perhaps within his small circle of close
associates. Small disk allocations can be a positive hindrance
to this, and not much is likely to be meaningful to carry from
one project to the next. The result is that code gets written
over and over, costs for software reflect this, and general
waste and lossage prevail.
Cure:
Clearly, common software repositories can address this. Those
who use the Internet know of several such, and micro users have
BBSs. At the corporate level, however, these tend to be rare.
Excuses given often have to do with security and licensing issues
but the most important reason may be that a software library cannot
be effectively handled by non-technical librarians, and the
engineering resources to manage one are not committed either due
to unavailability, or because nobody can figure out how to pay
them.
Such repositories need to be well publicized, a job which is
difficult to do from a central site. They also need to be fairly
well catalogued, and they should have a way to accept and
even solicit software contributions from the company. Finally,
they must be accessible easily and without prior arrangement,
so that looking for tools can become a routine activity.
2. "There's nothing useful in the library"
Discussion:
A software library which contains the software equivalent of
SSI parts (e.g. math libraries, string handling packages, and
a few other specialized items) can be set up, but if it remains
small, an engineer will often fail to find code that will save
him a significant chunk of time. This discourages further looking
at the library and will vitiate its success even if the library
later grows. The SSI parts are certainly needed and vital, but
MSI and LSI parts are needed too. The engineer who discovers a
fullscreen editor for his text buffer, for example, and can use
it in his system without a lot of messing with it, will come back,
and will pick up the SSI programs too.
Cure:
My experience is that a software library containing several
hundred megabytes MINIMUM is about the threshold needed. A
gigabyte or two would be preferable. The software made available
needs to be sources and documents, and indices in some form
that can be perused without too much effort. There should not be
too much concern that the software will have to be changed a bit
to be re-used. What's important in reusable software is that it
take (significantly) less effort to turn a piece of old code into
what you need than it would take to write new code from scratch.
This is generally the case with whatever source code programmers
are willing to let anyone else see.
Building such a library from internal resources is a significant
barrier. Fortunately, there's a cure in the form of public domain
libraries. Several organizations maintain large collections of
PD code; the most prolific of these is the DECUS library, which
can by itself be used to seed a multi-gigabyte library. Among
MSDOS machines, the PC-SIG has a collection of some hundreds of
megabytes, but relatively little of that code is sources. Finally,
the collections on the SIMTEL20 repository can be obtained, as
can those in the mod.sources newsgroups on Internet.
This software is adequately indexed for browsing, at least in that
indices to it can be maintained online on even a modest sized
machine. Even a search tool like VMS SEARCH or VMS or Unix GREP
searching for keywords is fairly effective at finding code that
will do what's desired.
Publicizing and soliciting contributions are problems which generally
need management support. Corporate users are likely to find
significant resistance to a group letting "its" code out for
a system it does not control, even where the code so released is
likely to make contributions to the company generally. Also,
work done even partly for contracts is likely to have major
legal entanglements. Some support for the concept needs to be
forthcoming from contracting customers, where one deals with
governmental customers.
The bottom line is that reusable software libraries CAN be had, and
they tend to generate their own publicity and use. The one I maintain
is indexed only in fairly crude ways, with considerable browsing and
rooting around necessary to find things. Still, software is found and
used (across the internal corporate DECnet) a lot (typically 2 or 3
file transfers going on most of the day during work hours; a bit more
sporadic off hours.) By limiting the collection to items which can be
passed freely around within my company (and mostly to public domain
offerings which can go ANYWHERE), security issues have been reduced.
There's little at my site which couldn't be duplicated at other
companies, though, provided only that resources were to be provided
to support it.
Comments? Suggestions? Anyone know of good sets of tools to
help take large collections of data, usually with some English
language descriptions, and generate good cross references? (Yes, I know
somewhere in GE makes GESCAN, which is well suited to this. My budget
unfortunately can't hack one...)
Glenn Everhart
Everhart%Arisia.decnet@crd.GE.com
------------------------------
Date: 10 Mar 88 13:06:31 GMT
From: pacbell!att-ih!alberta!mnetor!utzoo!yunexus!geac!daveb@AMES.ARC.NASA.GOV (David Collier-Brown)
Subject: Shared Libraries
> Replacing shared libraries with new versions could make
> lots of working programs crash. Because those libraries are
> instantaneously used in almost ALL running programs, one
> error in such a library can be fatal for the complete system.
I remember being told how to do shared library installations to avoid
this problem, but I forget how it worked.
Can some Multician on the net comment?
--dave
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers International Inc., |
350 Steelcase Road,Markham, Ontario, |
CANADA, L3R 1B3 (416) 475-0525 x3279 |
14-Mar-88 08:04:38-EST,2202;000000000001
------------------------------
Date: 9 Mar 88 16:58:20 GMT
From: uh2@psuvm.bitnet (Lee Sailer)
Subject: Shared Libraries
>The day things went wrong, they had a new version of the VMS
>C compiler installed, including of course the (shared) libraries.
>The errors in the unchanged working program emerged from an
>error in the new libraries.
Shared library systems should have some mechanism for avoiding this type
of problem. How about this:
When object files are created, the startup code includes a check of the
version of the library used. Then, if the library changes, the startup
code sends urgent mail to the person responsible for supporting the code,
such as the local system administrator, the vendors (via email?), and the
user (this is optional).
Another approach would be to keep the old libraries around, and have
the using object file specify a library version number.
------------------------------
Date: 13 Mar 88 17:22:44 GMT
From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs)
Subject: Speed of Higher-Level Languages
> Now I see lots of software being put together with minimum
> implementation time as its sole goal. Yes, we have lots
> of uncommented Lisp. The benchmarks show it runs about
> 3 times slower than C, which is about 3 times slower than
> machine language.
I've said it before in other newsgroups - there's no technical reason for
Lisp programs to be any slower than machine language. Near-optimal compiler
output has been demonstrated many times, but only on small benchmarks, and
the results on larger programs can be as bad as you say. Nevertheless,
efficient compilation of realistic programs seems to have been decreed to
be "non-research" therefore unfundable, and Lisp companies have been trying
to get better compilers, while losing sales because their stopgap releases
have shabby performance. It's pretty frustrating to see higher-level
languages losing out to C++, not because of inherent defects, but because
available systems fail to deliver adequate speed and space performance.
> All that runs over an operating system,
> Unix, which switches contexts an order of magnitude slower
> than some other systems.
>
> ... and one of us (not me) wonders why his "high-tech"
> workstation has worse response time than his PC at home.
This is the first I've heard of Unix being accused of slowing workstations
to sub-PC levels! Certainly doesn't correspond to my experience, where I've
given up on PCs completely because they're just too excruciatingly slow to use,
compared to the HP 350 on my desk...
stan shebs
shebs@cs.utah.edu
------------------------------
Date: 14 Mar 88 16:25:10 GMT
From: pacbell!att-ih!alberta!calgary!lomow@AMES.ARC.NASA.GOV (Greg Lomow)
Subject: What is CASE?
I have started hearing a lot about CASE. What is it?
My understanding is that a CASE system should support all
aspects of the software development life cycle. What does CASE
offer that we don't already have? Or does CASE require more
things to be described in a form that can be processed and
maintained by a computer? What CASE tools support which portions
of the development cycle?
What is the difference between CASE and CAPM (Computer Aided
Project Management :-))? By this I mean what benefits could I
expect from using a CASE system that I would not get from using
a set of computer based tools for requirements analysis,
interface typing, test case generators, configuration
management, etc.
Finally, are there any commercial CASE systems? Alternatively,
what set of existing computer tools would you suggest a
small/medium sized project (20,000 to 100,000 lines of code)
needs to manage product development.
--
Greg Lomow
lomow@cpsc.calgary.cdn
or
....![ubc-vision,ihnp4]!alberta!calgary!lomow
------------------------------
Date: Mon, 14 Mar 88 18:21:04 PST
From: PAAAAAR%CALSTATE.BITNET@MITVMA.MIT.EDU
Subject: CASE Tools and DFDs/Bubble Charts
jon@june.cs.washington.edu (Jon Jacky) writes:
>I concluded that this class of CASE tools doesn't address
>the problems we find most difficult, namely specifying the behavior of the
>system, and designing a good set of tests. Moreover, the bubbles-and-arrows
>diagrams don't really express anything that doesn't appear in a program
>outline consisting only of data declarations, procedure and function
>declarations, and a program skeleton consisting only of procedure and function
>calls, written in a strongly-typed language with nested scope, such as Pascal.
Ada-PDL was the language of choice in some European projects
- Pascal does not express exceptions, concurrency, information hiding,
objects, libraries, etc very well (if at all)
>The bubble-and-arrow diagrams simply provide an alternate, graphic
>representation of such a text.
An alternative view is exactly what is sometimes needed.
Examples
- when wanting to avoid details while working topdown.
(DFDs tend to encourage designs that follow Parnas's
Principle of Information Hiding, and Object Oriented Designs
more often than PDL based notation)
- verifying that all parts fit together as a whole.
- communicating with someone with a visual mind rather than a textual one.
- Finding unexpected interfaces between things.
The problem is that it takes much non-productive work to get a readable
DFD/bubble chart. Also DFDs are not easily expressed in ASCII. I have spent
years looking for alternatives. Ideally automatic as PSA/PSL with
modern bitmapped graphics as an interface.
I have found two forms of DFD where the layout work is useful.
(1) DT Ross's SADT Notation (Softech Inc)
(See April Issue of the IEEEE Computer Society Magazine p25-34)
(2) R. J. Lano's "N-squared" Chart
(TRW-SS-77-04 November 1977, One Space Pk, Redondo Beach CA 90278)
Both of these have explicit rules that help determine the layout
in terms of what is being drawn.
Both place the "bubbles" on the diagonal.
The N-squared (N^2) chart is
* Simple to learn, easy to read
* Makes missing connections obvious
* Makes feedback loops obvious
* Can even be "ASCII-fied" or done on a grid/spreadsheet.
In an n^2 chart arrows come out of the sides of bubbles, turn a corner,
and enter into either the top or bottom of another bubble.
Bubble 1 ------>Arrow 1 to 2
^ :
: :
: V
Arrow 2 to 1 <-----Bubble 2
A column indicates the inputs to a bubble and a row it's outputs.
On the other hand SADT has rules that still seem incomprehensible after
10 years study of published papers.
BTW There exist at least other types of chart that CASE tools support
- Bachman/Entity-Relation-Attribute Charts for conceptual modelling
of data structures.
- Hierarchicy charts for programs ( and sometimes data as well).
- State Transition Diagrams
Dick Botting
PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick)
paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}.ARPA
Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
Disclaimer: I have no financial or other link to the above companies.
I am not responsible - and neither is CSUSB.
------------------------------
Date: Mon, 14 Mar 88 18:11:09 PST
From: PAAAAAR%CALSTATE.BITNET@MITVMA.MIT.EDU
Subject: CASE Tools and JSD
sdcc6!loral!shawn@ucsd.edu (Shawn McFarr) writes:
>I am looking for CASE tools that would use either JSD[...]
As far as I know a number of Diagramming type tools allow you to
use Jackson's structure notation as an alternative for other program
hierarchy notations (eg Myers...). These would (perhaps) support the
production of JSP diagrams, but not the automatic production of code
from the design documentation. I have seen two systems in the UK
that to some extent did this back in the 70's - THe MAJIC[sic]
system at Manchester University had some fundamental misunderstandings
about JSP imbedded in it. On the other hand Keith Robinson
had an impressive program running on his personal machine which
went well beyond editting diagrams - it showed that the system could
help the programmer to combine data descriptions to give program structures,
and to allocate operations to these structures.
Jackson's Company in London may produce a similar package some day.
No one has proceeded from JSP to JSD, yet - as far as I know.
------------------------------
End of Soft-Eng Digest
******************************
-------