soft-eng@MITRE.MITRE.ORG (Alok Nigam) (04/18/89)
Software Engineering Digest Monday, 17 Apr 1989
Volume 6 : Issue 15
Today's Topics:
On knowing what you are talking about
Software Engineering Curriculum Survey (resend)
Lines of code
Re: VMS vs. UNIX s/w development tools - query (U)
Any interest in starting a CASE project? (U)
Re: Any interest in starting a CASE project? (U)
midway summary: the vote for comp.realtime (U)
object-oriented reference (U)
COCOMO parameters based on UNIX/C development environment (U)
- ------------------------------------------------------------
Date: Tue, 11 Apr 89 21:21 EDT
From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)"
Subject: On knowing what you are talking about
In Software Engineering Digest v6n13, G.M. Harding writes:
The Unix convention on process-termination values [0=success, anything
else is an error of some kind] makes a lot of sense. Think about it:
There are many flavors of failure, but there's only one variety of
success, namely, the complete kind. So, the Unix shell correlates the
process-termination value with the question: Were there errors? If the
termination value is logically TRUE, the answer is "yes"; otherwise,
"no."
If we are going to talk about "engineering" or "science", it would really help
to try to understand the facts. Let's what they really are:
- Unix doesn't give you quite the variety of return values you
think. For one thing, must Shells silently discard all
but the bottom byte of a returned value. (You have to
search a while to find this in the documentation.) In
practice, few Unix programs terminate with any value other
than 0, 1 or 2; returning anything else is likely to break
someone's Shell script.
- VMS does NOT consider zero/non-zero as a significant indicator
of success. Instead, a VMS condition value - there is a
standardized format used all over the place in VMS - uses
the bottom bit to indicate success or failure. Further,
the bottom three bits indicate severity of failure. This
allows you to encode such things as "failed but still may
have produced useful results", "failed but produced no
results", "succeeded", "succeeded with warnings", "succeeded
with informational messages", and so on.
The rest of a condition value specifies who issued it and,
for values from a given entity, the particular error.
As I noted, condition values are used EVERYWHERE in VMS.
There is a facility, analogous to the Unix perror, which
prints the error message associated with a condition value.
Unlike perror, it is extendable - you can define your own
messages and have them displayed by the built-in mechanisms.
Also, unlike the error values returned in errno, condition
values can reasonably be returned to DCL (analogue of the
Shell), which will then invoke the standard routines to
produce an error message.
- The comment about it being "natural" to use "logically TRUE" to
indicate that a program failed, may be fine, though perhaps
a bit bizarre - I usually think of TRUE as meaning "OK, go
ahead. But that's a minor point. What's interesting is the
leap from that to the "obvious" conclusion that non-zero
should mean TRUE. Your C biases are showing, Mr. Harding!
This happens to be the way C defines its pseudo-Boolean
values, but it's certainly not universal. The VMS standard,
which makes every bit as much sense, is to say in effect
that a Boolean is a one-bit field, set to 1 for TRUE and to
0 for FALSE. This one-bit field can be inserted to a larger
datatype in the same way that, say, an (unsigned) byte is
inserted into a long: As the least significant bit(s). So
VMS defines a value as TRUE if the bottom bit is set, FALSE
otherwise. Again, this is a universal throughout VMS-
specified interfaces. It carries over to VMS implementa-
tions of languages which don't specify the representation of
Booleans, which, it turns out, is most of them. In most
VMS languages, the success of a call to a system routine can
be tested as a simple Boolean value by an if statement. (In
C, this doesn't work; you have to mask off the bottom bit.)
> File types are a problem in VMS. There are a lot of them. The
> default type for a C program is different than the default type
> for FORTRAN.
[These are not Mr. Harding's, but he supports them.] So? Any program can read
ANY of the various types. For operations that are in the common (as in
"shared", not "usual") semantics - like "get next record (line)" - programs in
any language treat all the types identically. C programs have trouble because
they want something which is beyond the common semantics: They want to move
around byte by byte. There are file types which support such operations, and
there are file types that don't.
This underscores the point I was making in my original reply to the
fellow who asked for an OS comparison. The system has no business
knowing (or thinking it knows) what's in my files.
This is OPINION. It's also opinion based on a very limited background.
Unlike Unix, VMS was designed to naturally support languages other than C.
Some - COBOL, BASIC - have built-in constructs for access to things like
indexed files. Allowing "the OS" to maintain such files ensures that they
can be accessed uniformally. Example: In VMS, it is possible to use the
SEARCH command on an indexed file. What this will do is completely ignore
all the overhead and index information, and read sequentially through the
actual data, a record at a time. What does SEARCH have to accomplish this?
Absolutely nothing! It simply opens the file and begins sequential access
to it. "The OS" provides the access necessary. (If you think this is
trivial, consider that VMS supports key compression. The records being
searched may be represented within the file in a very different form from
what SEARCH actually sees.)
Consider what grep does with a dbm file on Unix....
An example of how useful OS knowledge of the encoding used for a file is can
be seen in one case where VMS DOESN'T provide it. FORTRAN has a notion of
"segmented" records. Segmented records can be longer than the records in
any VMS-defined record type, so they are implemented as linked lists of OS
records. This causes incredible pain: Only FORTRAN programs can access files
of segmented records (unless you hack together the appropriate code yourself).
Even FORTRAN programs cannot determine for themselves that an existing file
contains segmented records: You have to include this information in the OPEN
statement.
Now, all this may not seem like a big deal to Unix programmers, since in Unix
the code which accesses a file is always assumed to know how that file is
organized. In VMS (and, BTW, some other OS's - most other than Unix, in fact)
the operating system gets this right by itself much of the time.
I think of VMS file types as implementing a dynamic type system, similar to
that in many programming languages (like LISP or Smalltalk). I have some
major objections to the particular types (== programming abstractions) VMS has
chosen to provide (no Unix-like stream organization, for example); more
generally, I'd prefer the ability to extend the system. VMS doesn't let you
do that. I know of only one system that does: Apollo's Aegis. (Unfortu-
nately, this and many other good ideas in Aegis are likely to be buried in
the rush to Unix compatibility.)
When OS writers try
to do cute things like that, they throw device independence out the
window. (Notice that nobody has ever accused VMS of being based on the
spirit of device independence. Ever try to mount a tape on VMS?)
This statement is so vague, and so incorrect, that it's impossible to respond
to.
-- Jerry
- ------------------------------
Date: Wed, 12 Apr 89 12:53:53 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Subject: Software Engineering Curriculum Survey (resend)
During the last 10 years or so the "Computer Science" curriculum has
become cast in concrete. It includes - Structured Programming (Pascal),
Data Structures(using Pascal), Comaprison of Languages(Pascal<Ada),
Turing Machines, Calculus, Physics, SCience, GE, Operating systems, etc.
This curriculum is now enforced by the Computer Science Accreditation Board.
An accreditable CS BS degree does not give credit
for "language courses".
ACM/IEE recently published reports (the Denning Report) defining
"Computing as a Discipline".
There is a joint ACM/IEEE taskforce taht has listed all the
"knowledge units" that anyone taking a computer xyz degree would know
something about!
"Computer Engineering" and "Computer Information Systems" are
similarly defined and controled:
- the first includes much Electronic Engineering,
and the second includes Accounting and Business and probably COBOL.
I want to know what a Software Engineering BS degree would look like - a
qualification for people who don't want for a PhD in parallel computing, but
will be producing large scale software products.
I would like to here about plausible goals and objectives for a 4 yr
Software Engineering Degree - from those who are in the field.
Suppose it is 5 years in the future - 1995.
You have been promoted.
You are recruiting someone to join your team of "Software Engineers".
The applicants all have a BS in
"Software Engineering".
- what skills and knowledge do they ALL have?
- what skills and knowledge do some of them have?
- what skills and knowledge do NONE of them have?
Here is a random sample of skills that you might find:
Coding programs in:
ADA/ALGOL/BASIC/C/C++/COBOL/csh/DBASE.n/Eiffel/Euler/FORTRAN/GAMMA/HAL/
ICON/JAVELIN/ksh/LISP/MODULA/Natural/OBERON/PASCAL/PL1/PROLOG/POP/Qnial
Language R /Smalltalk/SNOBOL/SQL/Turing/UFO/ Visual/Windows/ Xwindows/
yacc/Z/...
/All of the above
/None of the above
Designing programs using SP/OOPS/Top-down/Bottom-Up/HOS/JSP/JSD/...
Analyse Systems/requirements using SADT/SSSA/DeMarco/JSD/SSADM/....
Rapid Prototyping
Handling EMail - efficiently, politely and skillfully
Soldering
Designing data bases
Designing Networks
Specifying/selecting/purchasing hardware/software/ADTs/Tools
Administrating a multiuser system
Systems Integration
Proving programs
Drawing DFDs/Action Diagrams/Bachman Diagrams/Flowcharts/....
Interveiwing
Using MSDOS/UNIX/OS2/PICK/VMS/JCL/MVS/MacOS/MACH/....
Handling surveys and statistics
Using shell scripts and UNIX tools (awk,sed,greps,...)
Predicting the performance of a computer system
Writing compilers
Differentiating and integrating functions of n variables
Functional Decomposition
Structured Analysis and Design
Leading a Walkthru
Debugging a program
Doing Linear Algebra
Doing simple algebra and arithmetic
Drawing graphs of functions
Being able to define and calculate -
Entropy of data/MTBF/standard deviation/RMS/mean/median/...
Writing good English
Drawing correct circuit diagrams
Handling complex numbers
Solving ODEs
Modifying an operating system
Using a wordprocessor/spreadsheet/outliner/Database/Paint/Draw/...
Using a CASE system: Excelerator/Visible Analysts/SilverRun/....
Using a PC/PS2/Mac/Sun/DEC/CYBER/...
etc
How many "Software Engineers" should be able to do these things?
Which should NO Software Engineer waste time learning?
What have I missed?
Please send me copies of responses and I will sumarise to the net
when the flow slows down...
Dr. Richard J. Botting,
Chair, Dept of Comp Sci., Cal State U, San Bernardino, CA 92407
In Calstate: PAAAAAR@CCS.CSUSCC.CALSTATE
On Bitnet: paaaaar@calstate.bitnet
From Arpanet: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
- ------------------------------
Date: 16 Apr 89 10:22:00 CST
From: "DAVE ERSTAD" <derstad@cim-vax.honeywell.com>
Subject: Lines of code
Can anyone point me to public domain (or cheap) utilities which
count lines of code (NCSS) in some meaningful fashion? I'm
interested in C, Pascal, and Ada counting. Our primary platform
is Apollo, but if I can get a VAX or Sun widget could use that.
- ------------------------------
Date: 11 Apr 89 20:14:56 GMT
From: Bob Dalgleish <att!alberta!dvinci!zaphod!bobd@bloom-beacon.mit.edu>
Organization: Develcon Electronics, Saskatoon SK Canada
Subject: Re: VMS vs. UNIX s/w development tools - query (U)
The major difference between Un*x and V*S is that it is EASY to write
your own tools in Un*x. The use of pipes means that homomorphic
transformations can be applied one after the other until you get the
desired result: read this as functional decomposition. When pipes are
expensive, inconvenient, or awkward to use, the software developers
spend less time writing simple tools to help them in their work and
more time doing things by hand or using the supplied tools.
There is no argument that the programs available on V*S are better or
worse than those on Un*x. The argument is whether it is easy to put
several tools together to make one that does the job that *I* want done
right now. Remember, Man is the tool-MAKING animal. Many other
animals use tools (birds, monkeys, otters, etc.). Spending a small
time to put tools into one's bag of tricks makes one much more
effective as a software developer.
The shells that run on V*S cannot hide all of the differences. The
architecture of V*S assumes monolithic applications with well-defined
interfaces that start up, run for a (relatively) long time, and get
ready for the next request; Un*x assumes small applications that come
and go as they please, creating and destroying files readily.
Consequently, Un*x shells run slowly and awkwardly, destroying any
advantage that might have been gained by making your own tools. Any
argument that writing a C program to more efficiently do the job is
absurd; the expensive part of the process is the programmer time, not
the machine time. It takes me 5 minutes to design, implement and test a
simple three stage shell script to do some straight-forward analysis; it
takes me one day to design, write, and test the same code in C. With
that trade-off, which do you think I would prefer? How about you?
- ------------------------------
Date: 12 Apr 89 13:11:46 GMT
From: storm development account <reign!storm@uunet.uu.net>
Organization: Softa, Washington D.C.
Subject: Any interest in starting a CASE project? (U)
After having looked over all the low-cost CASE packages that I
could find, I haven't found one I really like. Same with the people
that I asked.
So...Is it time to build one and make it freely distributable
over Usenet?
If anyone is interested, please email me. I will be willing
to handle the co-ordination and admin side of the project.
- ------------------------------
Date: 14 Apr 89 16:44:23 GMT
From: David Kuder <apple!vsi1!daver!indetech!david@bloom-beacon.mit.edu>
Organization: Independence Technologies, Inc. Fremont, CA
Subject: Re: Any interest in starting a CASE project? (U)
> If anyone is interested, please email me. I will be willing
>to handle the co-ordination and admin side of the project.
How do you plan to handle the co-ordination and admin without a
CASE package?
- ------------------------------
Date: 12 Apr 89 12:54:11 GMT
From: karl lehenbauer <texbell!sugar!ficc!karl@bellcore.bellcore.com>
Organization: Ferranti International Controls
Subject: midway summary: the vote for comp.realtime (U)
This is the midvote summary for comp.realtime. Voting will end April
26th.
To not "bias" the "vote", I present the names of those who have voted but not
which way they voted:
Alliant.COM!cantrell (Paul Cantrell)
Atherton.COM!hpda!ericb (Eric Black)
Atherton.COM!hpda!ky (Kuang-Yi Tan)
CORNELLC.cit.cornell.edu!850181p%ACADIA.BITNET
DINO.BBN.COM!delatizk (Jonathan Delatizky)
FAS.RI.CMU.EDU!Donald.Schmitz
K.GP.CS.CMU.EDU!David.Maynard
MATHS.LTH.Se!bengt_l (Bengt Larsson)
Portia.stanford.edu!jdj (John Johnson)
SEI.CMU.EDU!mrb (Mario Barbacci)
a.cs.uiuc.edu!kenny%f.cs.uiuc.edu (Kevin Kenny)
abvax!ejp (Ed Prochak)
amdcad!neptune.AMD.COM!tom (Tom Lynch)
ames!elroy!gryphon.COM!richard (Richard Sexton)
ames!eos.arc.nasa.gov!eugene (Eugene Miya)
ames!mailrus!uflorida!novavax!weiner (Bob Weiner)
arizona!midian!ejm (E.J. McKernan)
array!rob (Rob Marchand)
atanasoff.cs.iastate.edu!kelvin (Kelvin Nilsen)
ateng!chip (Chip Salzenberg)
athens.ARPA!iex!cramer (Bill Cramer)
att.att.com!rgh%mtunf
auspex!sun!wrs!fraser!geoff (Geoff Espin)
auspex!sun!wrs!yuba!jerry (Jerry Fiddler)
bernsten@phoenix.Princeton.EDU (Dan Bernstein)
bevsun.bev.lbl.gov!lewis (Steve Lewis)
biar!trebor
bnr-fos!bnr-public!schow (Stanley Chow)
brr@marlowe.hf.intel.com (Brad Rullman)
ccird1!rlgvax!djt (Don Totten)
cfj:cfj Charles Johnson
chinet.chi.il.us!magik (Ben Liberman)
chip@vector.UUCP (Chip Rosenthal)
cmcl2.NYU.EDU!liuys (Yue-Sheng Liu)
cpswh.cps.msu.edu!enbody
cs.duke.edu!rea (Rana Ejaz Ahmed)
cs.rochester.edu!marsh
cs.utexas.edu!mok (Al Mok)
cssun.tamu.edu!venu
cup.portal.com!Orion
daisy!david (David Schachter)
ecf.toronto.edu!apollo (Vince Pugliese)
elxsi.dfrf.nasa.gov!nesel
emx.utexas.edu!nather (R. E. Nather)
eutrc3!wsinkees (Kees Huizing)
farber@dsl.cis.upenn.edu (David J. Farber)
fed!mqws2!m1swd00 (Sean Doyle)
ficc!morrison (Brad Morrison)
frog!john (John Woods)
grasp.cis.upenn.edu!king (Robert King)
hector!dsr (David S. Rosenblum)
helviti.cs.umd.edu!ogud (Olafur Gudmundsson)
hodgkin.med.upenn.edu!blackman (David Blackman)
home.csc.ti.com!jensen (John Jensen)
honda.fdi.tek.com!kyleb ("Kyle B.")
hpcsqa!johnm (John Mauzey)
hub.ucsb.edu!grosen%amadeus (Mark D. Grosen)
idacom!andrew (Andrew Scott)
jarsun1!jensen (peter jensen)
jeffd@ficc.uu.net (Jeff Daiell)
jimst@honda.fdi.tek.com (Jim Stanley)
john@jetson.UPMA.MD.US (John Owens)
juicy-juice.lcs.mit.edu!altman (Arthur Altman)
karl@ficc.uu.net (Karl Lehenbauer)
killer!mizarvme!linimon (Mark Linimon)
lexicon.com!rk
m.cs.uiuc.edu!gillies (Don Gillies)
m.cs.uiuc.edu!swami (Swaminathan Natarajan)
m2.csc.ti.com!gateley (John Gateley)
m2.csc.ti.com!mmeyer (Mark Meyer)
majestix.ida.liu.se!cajsv (Caj E Svensson)
markz@ssc.uucp (Mark Zenier)
mcc.com!rfg (Ron Guilmette)
mcvax!ibmpcug.co.uk!ronald (Ronald Khoo)
me.utoronto.ca!yap (Davin Yap)
microsoft!kevinbe (Kevin S. Berg)
microsoft!stephena (Steve Arrants)
mips.csc.ti.com!mmeyer (Mark Meyer)
n3dmc!johnl (John Limpert)
ncifcrf.gov!elsie!ado (Arthur David Olson)
nexus!dennis (Dennis Rockwell)
nluug.nl!nh20!albert (A.M.J.Hartveld)
nvpna1.prl.philips.nl!huisken (Jos Huisken)
oresoft!m2xenix!news
pcrat!rick (Rick Richardson)
phi@computer-science.strathclyde.ac.uk (Per Henning Isaksen)
philabs.Philips.Com!sxm (Sandeep Mehta)
pixelpump.osc.edu!stein (Rick 'Transputer' Stein)
pprg.unm.edu!swilson (Scott Wilson [CHTM])
proton!muon!baumann (Michael Baumann)
ptolemy.arc.nasa.gov!raymond (Eric A. Raymond)
rayssd.RAY.COM!trr (Terry R. Raymond)
resrch.MoliEnergy.BC.CA!Robbin.W.Johnson (Robbin W. Johnson)
rickc@pogo.wv.tek.com (Rick Clements)
rja@edison.CHO.GE.COM
roope!arl (Ari Lemmke)
rose.waterloo.edu!wacfeick (Wayne Feick)
rutgers!cs.rochester.edu!moscom!adp (Alan Percy)
rutgers!ecsvax.uncecs.edu!uccjcm (John McLendon)
rutgers!eecs.nwu.edu!laidbak!katzung (Brian Katzung)
rutgers!ucf-cs.ucf.edu!tarpit!rd (Bob Thrush)
seahcx!kenh (Ken Hughes)
seismo.css.gov!raybed2!plh (Paul Hilcoff)
shakti!shri (shri)
sparrms!paul (Paul Ng)
src.honeywell.com!kan (Ling Kan)
src.honeywell.com!vestal (Steve Vestal)
strindberg.ericsson.se!howard (Howard Gayle TX/UMG)
sugar!uhnix1!moray!siswat!buck (Lester Buck)
sun!cohesive!kla!serendip!pat (Pat Lashley)
sun!elxsi!len (Len Mills)
sun!wrs!bob (Bob Cohen)
sun!wrs!kymijoki!eric (Eric Stromberg)
swan.ulowell.edu!sky!mirkin
ti-csl.csc.ti.com!gjordan (George Jordan)
topaz.rutgers.edu!msmith (Mark Robert Smith)
tymix!grimoire.Tymnet.com!mooring (Ed Mooring)
ubc-bdcvax!holm (Terrence W. Holm)
umn-cs.cs.umn.edu!haque (Samudra E. Haque)
uncecs.edu!khj (Kenneth H. Jacker)
unet!stout.UCAR.EDU!thor (Rich Neitzel)
unix.cis.pittsburgh.edu!tjw (Terry J Wood)
unmvax.cs.unm.edu!intvax!bryan
ursa-major.SPDCC.COM!eli (Steve Elias)
uvacs.cs.virginia.edu!mac (Alex Colvin)
uwmcsd4!ulowell!masscomp!twn (Thomas W. Nelson)
venera.isi.edu!cew (Craig E. Ward)
victor@concour.cs.concordia.ca (Victor Krawczuk)
walker@ficc.uu.net (Walker Mangum)
watmath.waterloo.edu!dgharriss (Dermot G. Harriss)
watmsg.waterloo.edu!dgharriss (Dermot G. Harriss)
wtwolfe@hubcap.clemson.edu (Bill Wolfe)
xenna.encore.com!pinocchio!cook (Dale C. Cook)
zaphod!bobd (Bob Dalgleish)
zip.eecs.umich.edu!dlk (Daniel L. Kiskis)
- ------------------------------
Date: 12 Apr 89 16:10:19 GMT
From: ken magel <cunyvm!ndsuvm1!ndsuvax!ncmagel%psuvm.BITNET@CUNYVM.CUNY.EDU>
Organization: North Dakota State University Fargo, ND
Subject: object-oriented reference (U)
Although it is somewhat biased, a very good presentation of the basics
of object oriented use is Object-Oriented Software Construction by Bertrand
Meyer from the Prentice Hall International Series in Computer Science. Mr.
Meyer is the developer of Eiffel and the book does discuss object-oriented
development in terms of Eiffel, but the discussions are almost always applicable
to all other systems. The book does seem to cover nearly all of the basic
considerations and does provide some examples. It also discusses the
documentation problem.
- ------------------------------
Date: 13 Apr 89 20:34:07 GMT
From: ssc-vax!shuksan!tahoma!lrm5110@beaver.cs.washington.edu (Larry R. Masden)
Organization: The Boeing Co., BCA FSL, Seattle, WA
Subject: COCOMO parameters based on UNIX/C development environment (U)
I appreciate all the information I recieved regarding COCOMO. I
got a copy of the book "Software Engineering Economics" by
Barry W. Boehm and have read about the BASIC and INTERMEDIATE
modeling methods. Now I have more questions.
My basic concern is the numeric accuracy of the parameters for use
in the UNIX / C environment. The parameters for the formulas in
the book were developed based on information from 63 software
development projects, most of which used FORTRAN or Assembly.
Concievably, the differences between older environments and
the newer environments could be factored into the "Modern
Programming Practices" (MODP) parameter and "Use of Software
Tools" (TOOL) parameter in the INTERMEDIATE model. However,
I was wondering if any parameter sets exist that have been
developed from UNIX / C projects. These might provide a
better place for me to start.
- ------------------------------
End of Software Engineering Digest
**********************************