soft-eng@MITRE.MITRE.ORG (Alok Nigam) (05/12/89)
Software Engineering Digest Thursday, 11 May 1989
Volume 6 : Issue 20
Today's Topics:
Re: Computer langauges and software lifecycle - references request (U)
COBOL as a Programming Language (U) (2)
SoftEng or CS Graduate Program Search (U)
Software Analysis for Design Decisions : Static & Dynamic (U)
Re: software engineers (U) (8)
Exception handling models
CASE project update (?) (U)
Surface area for software (U)
Re: grep vs. SEARCH (Was Re: Software Development Tools) (U)
------------------------------------------------------------
Date: 2 May 89 00:08:24 GMT
From: Stanley Chow <mailrus!jarvis.csri.toronto.edu!utgpu!bnr-vpa!bnr-fos!bnr-public!schow@cu-arpa.cs.cornell.edu>
Organization: Bell-Northern Research, Ottawa, Canada
Subject: Re: Computer langauges and software lifecycle - references request (U)
I don't want to start a war about C, please forgive any remarks I made/make.
>In article <432@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes:
>> Amazingly, it is possible to write good modular code in COBOL. It takes some
>> discipline but is certainly an order of magniture easier than doing so in C.
>
>Excuse me? C has global variables, variables that can be local to a
>module (source file), and both temporary and long-lived variables local
>to functions (subroutines). Cobol has global variables, and very
>limited subroutines (PERFORM).
>
I meant to say:
it is easier to write modular code that is easily maintainable by people
with minimal familiarity with the language.
In the commercial shops (for which COBOL is intended), getting good people is
very difficult.
>> If I may preempt some objections to COBOL:
> [...]
>> - Not-block structured, no variable scoping.
>> Again, true but irrelevent. Most shops have set up variable naming rules
>> so that scoping is not needed.
>
>Rules the compiler can't check for you. The lack of true local
>variables precludes recursion, unless you build your own stack.
>
Recursion, I don't consider to be a problem for COBOL. The problems usualy
don't need recursion. The odd time that recursion is needed, you can fake it.
Most COBOL programs that I have seen do not require many local variables. Anyway,
after your tenth clone of the print program, you are not likly to have much
trouble with the eleventh clone.
>> - Poor choice of control structures.
>> True, but in the right domain, the COBOL paradigm is very effective.
>
>I'd say the same thing for good 4GL's. The intersection of their
>domains is pretty large, and the 4GL's are more concise.
>
I have not used any 4GL, so I can't say. But I imagine you are right on this.
------------------------------
Date: 3 May 89 03:08:42 GMT
From: Warren Harrison <tektronix!psueea!jove.cs.pdx.edu!warren@bloom-beacon.mit.edu>
Organization: Dept. of Computer Science, Portland State University; Portland OR
Subject: COBOL as a Programming Language (U)
The discussion regarding COBOL has been quite interesting. It seems
quite obvious however that the majority of people flaming COBOL don't
have much experience with it.
If written correctly, COBOL is perhaps the most modular language
in use. This is not at first obvious because few people ever use
subprograms in their college COBOL courses, and this appears to be
limit of most of the posters' exposure to COBOL. In fact, COBOL
has NO global variables. The only way in or out of a COBOL
subprogram is via the parameter list, which by default is passed
by address, but it can be forced to pass by value if desired.
I have successfully developed and taught a course on data abstraction
This can be inefficient, but it gives a great motivation for
students to address memory allocation issues [no new(xyz) ...
you're responsible for the free list or garbage collection yourself].
Data abstraction was much easier in COBOL than in Pascal since you
really could ensure the internals of the operation abstractions were
unavailable to the user. Because of this, you didn't have any
"global linked lists" floating around that the programmer is tempted
to access outside the "pop" and "push" routines.
Unfortunately, the potential is usually not realized since most
CS COBOL courses are taught by either (1) people who know COBOL,
but have no formal CS training - eg, the adjunct instructor from
the local dog food plant or (2) CS faculty who know barely more
about COBOL than what is in the first 10 chapters of a sophomore
lvele text book.
Here are some of the good points of COBOL, that few other languages
have ... as far as I know, no other language has them all:
packed decimal number representation, built-in report writer,
built in (via the OS access methods that is) indexed sequential
file system, built in binary search and sorting commands, exception
flagging and handling, built-in string handling (eg, STRING/UNSTRING),
(REPLACE USING), pseudocode-like syntax (?).
Bad points:
Wordiness, poor control stuctures (fixed in COBOL 8x), no dynamic
RAM memory.
I may have missed some of each. Note that my fondness for built-in
operations such as indexed files, string/unstring, etc. is because
I don't like surprises, and everytime I use someone's super duper
B-tree library, they seem to want to change the calling conventions.
If you want to flame COBOL, please spend some time looking over the
language first. It's potential is great. It's too bad no one
is making use of it.
------------------------------
Date: 3 May 89 19:38:15 GMT
From: Len Lattanzi <apple!vsi1!wyse!mips!synthesis!len@bbn.com>
Organization: Synthesis Software Solutions Inc, Sunnyvale, CA
Subject: Re: COBOL as a Programming Language (U)
>If written correctly, COBOL is perhaps the most modular language
>in use....
This is true of subprograms but the bread and butter of cobol is the
perform statement which allows 0 parameters. The call statement is
more expensive than the perform and that alone would hamper any crusade
to write 'correct' COBOL programs. For those unfamiliar with cobol
ponder how many C programmers could be convinced to program using only
static globals and every procedure in a separate file?
>I have successfully developed and taught a course on data abstraction...
It's very hard to concentrate on data abstraction issues if you're busy
chopping up global memory for heap usage. COBOL is not a systems programming
language.
>Here are some of the good points of COBOL, that few other languages
>have ... as far as I know, no other language has them all:
Very large installed base. Cobol and RPG have the lion's share in
terms of amount of code written.
>Bad points:
No bit operations.
No Standard floating point types.
Packed decimal is limited to 36 digits
Paragraphs use of decimal point as implied end-if or end-perform can
lead to obscure bugs after code is modified. This is almost as bad
as Fortran's ability to compile "DO 10 I=1.10"
Except for my last point none of these Bad points prevent Cobol from
being an ideal 'COmmon Business Oriented Language' but neither does
Cobol's good points make it an ideal general purpose language.
------------------------------
Date: 1 May 89 23:13:20 GMT
From: "Stanislaw L. Olejniczak" <mailrus!ncar!umigw!umiami!slores@ohio-state.arpa>
Organization: University of Miami (IR)
Subject: SoftEng or CS Graduate Program Search (U)
I would very much appreciate, on my and many other prospective
graduate students' behalf, your comments on graduate software
engineering programs. I have been reading brochures from various
schools, collected various rankings and read a couple books about
graduate programs in software engineering or computer science.
What I am asking for in this message are personal opinions,
observations and comments.
Which school and department do you think is a good place to study
Software Engineering or Computer Science with Software
Engineering emphasis? Why do you think a particular department
is a good place to spend a couple years getting a Master's, and
later, a Ph.D.? What are its strength? What are its weaknesses?
Where do the graduates go? What kind of research is being
conducted? Who (if not yourself) is a good person to contact
there? What are other comments you would like to make that I
have not asked about? All comments you will send will be
appreciated.
Let me apologize for posting this message again, and for posting
it this time to numerous newsgroups. When I have initially
posted this request, I have offered to send summaries to any
interested person. I have received several dozens of requests
for the summaries. I have received a small handful of replies on
the subject. After waiting now a considerable, for Newsnet,
time, I have decided I did not post it to the right groups; or
all the right people did not get to see this. Thus, this second,
and final, attempt.
To those who had previously replied, my many thanks. For those
who had requested or will request summaries, I will post them to
you after I feel reasonably certain I have received all replies
to this second posting. To those who will reply, many, many
thanks, from me and from the numerous prospective graduate
students who will embark on more successful graduate studies
thanks to the time you take off your busy schedules to advise.
P.S. If you are so kind as to send your comments but would NOT
want be identified in the summary, please let me know.
- ----
Stan Olejniczak Internet: slores@umiami.miami.edu
University of Miami UUCP: {uunet!gould}!umbio!solejni
Miami, Florida, USA BITNET: SLORES@UMIAMI
Voice: (305)-547-6571 FAX:305-547-6412
------------------------------
Date: 2 May 89 15:40:46 GMT
From: Zongcheol Zhoo <osu-20.ircc.ohio-state.edu!zhoo-z@ohio-state.arpa>
Organization: The Ohio State University, Columbus, Ohio
Subject: Software Analysis for Design Decisions : Static & Dynamic (U)
General question is,
How to cope with tedious and frequent analyses of large and complex software ?
So far
analytic, empirical and simulation approches for the performance analysis have been known to answer the question.
1. How could we capture the static and dynamic features of the software and how to cooperate the static and dynamic behavior of the
2. What is the requirements for providing in-depth, and performance information to the design decision making ? Some of them are
- - Modeling techniques for capturing the system's behavior
- - Trasient behavior of a software system
- - Timing data, control flow and program variables
- - Dynamic monitoring, measurement for run-time information
- - Evaluation techniques with the static and dynamic information
What else ?
Is "the execution time" still important for the design decisions ?
3. Any proposals for the computation structure model or references ?
4. How would the Expert-Systems work for the design decision making with the static and dynamic infomation of software in oder to he
Any advise and comment on the above questions would be appreciated.
------------------------------
Date: 2 May 89 15:42:00 GMT
From: Jim Perry <apollo!perry@eddie.mit.edu>
Organization: Apollo Computer, Chelmsford, MA
Subject: Re: software engineers (U)
>Real programmers spend 90% of their time debugging. Computer science
>curricula ignore debugging, perhaps because it can never be reduced
>to a theory. But debugging skills are what I would look for *first.*
Unfortunately I believe real debugging skills can only acquired with
experience. You can teach techniques for writing relatively bug-free
code, the hard part is when you have to debug someone else's code (or
spec/interface, whatever). I generally have confidence that my code
will do what I intend, but can still have a good time tracking down a
subtle bug in the compiler or OS. There's a leap of faith in believing
that compilers *have* bugs, the sad realization that most "compiler bugs"
aren't, and finally the ability to track down the real ones.
>Other skills I would look for:
>
>2. The ability to "port" software. This is an acid test for distinguishing
> able programmers from mere C.S. grads.
A lot of this could and should be taught, in the hypothetical S.E. curriculum.
>3. The ability to maintain somebody else's code. Most C.S. students have
> no experience in this.
And the flip side, the ability to write code that can be maintained by
somebody else with a minimum of difficulty. There's a trade-off here, in
that a programmer in an environment where high standards of maintainability
are followed can be at a loss when presented with a more real-world poorly
documented program, while a programmer very adept at maintaining bare-
bones code may not appreciate the value of the additional work involved
in (structuring, documenting, modularizing) code.
>4. The ability to work from specifications. This includes getting them
> changed when they need it, and filling gaps by making inquiries or
> using your own judgment.
>
>5. The ability to write software with clean, convenient user interfaces.
> A good programmer can "see" his software from the user's viewpoint
> and write for the user's benefit.
>
>6. The ability to write adequate user documentation. See 4.
Where "user" under 5 and 6 refers not just to an end user of an application
but also clients of libraries, etc.
>7. Experience with a variety of languages, environments, and methods.
> Not that this experience will necessarily prove useful, but it shows
> that the programmer is versatile, and probably understands some of
> the underlying principles of software environments. By the same token,
> beware of dogmatism; a programmer with an antipathy to Pascal, COBOL,
> or VAX/VMS may have a stiff neck. A programmer who stops learning
> is technologically obsolete.
AMEN.
(I have more follow-up material on this but it's getting long so I'll
post it separately).
------------------------------
Date: 2 May 89 10:17:21 GMT
From: Periklis Tsahageas <mcvax!unido!ecrcvax!periklis@uunet.uu.net>
Organization: European Computer-Industry Research Centre, Munich 81,West Germany
Subject: Re: software engineers (U)
Flame on !
>Real programmers spend 90% of their time debugging.
Real software engineers spend 100% of their time trying to reduce the time
programmers spend on debugging.
>curricula ignore debugging, perhaps because it can never be reduced
>to a theory. But debugging skills are what I would look for *first.*
>(By the way, I am using "software engineer" as synonymous with "programmer."
Great mistake, sounds like a voice from the past.
>Separating design from implementation is usually a mistake; ask the DoD.)
Seperating design from implementation is one of the greatest advances in the
field of software engineering (borrowed/stolen from other engineering
disciplines). Have you heard of something called data abstraction ? ADT's ?
>Other skills I would look for:
>
> list of skills deleted
>
I, absolutely, agree. They are all necessary for a programmer.
I think software engineering degrees are an attempt by the academia, supported
by the software engineering industry, to evolve the craft of current software
manufacture into an enginneering discipline. Of course, this is a third year
student of Software Engineering (M.Eng.) at Imperial College, London, speaking.
------------------------------
Date: 2 May 89 17:50:00 GMT
From: m.cs.uiuc.edu!render@uxc.cso.uiuc.edu (Hal Render)
Subject: Re: software engineers (U)
The Colonel gives a good list of skill requirements for software engineers,
but I'll be damned if I know how you can judge someone's ability on this kind
of stuff unless you've watched them do it. Debugging is something they all
should have done on programming assignments, but how do you rate debugging
skill? Most undergrads won't have done any porting unless they had some
system programming job. Maintenance covers porting and upgrades, but this
is also something you don't get anywhere except on a job. Working from
specs they should be able to handle; a programming assignment is nothing if
not a spec, albeit a poorly worded one. Designing a good user interface
is a science in itself, and should be taught as a separate class (or a big
part of some other class). Ditto for writing docs. I think that a good
CS program will give them some variety of languages and systems (I'd tried
6 or 7 languages by the time I got out of ugrad), and it's easily checked.
As I said, a good list, but hard to check.
I know the ACM has been working on a core curriculum for undergraduate
CS education. Does anyone know how much software engineering is included?
------------------------------
Date: 2 May 89 19:49:18 GMT
From: "g.l.sicherman" <att!homxb!genesis!odyssey!gls@bloom-beacon.mit.edu>
Organization: AT&T Bell Laboratories, West Long Branch, NJ
Subject: Re: software engineers (U)
Dr Hubert Matthews at CERNvax has privately sent me the following note.
Since there's nothing here that calls for privacy (is there ever?), I'm
restoring the discussion to the public.
> From uunet.UU.NET!mcvax!cernvax!hjm Tue May 2 18:43:36 +0200 1989
>
> 90%? What sort of programmers do you know? Perhaps the first thing
> they should do is learn to write better code in the first place and
> reduce that to 50%, or preferably a lot less. Try a course in formal
> methods and specifications and see if that doesn't improve things.
> Also, try teaching programmers about program testing; if you know the
> most common ways that programs fail, then you can avoid those pitfalls
> from the start.
>
> I'm not a CS type. I happen to know about such things as formal
> methods, pre- and post-conditions and loop invariants &c., formal
> specifications and the like. I also know how to write the most
> gawd-awful twisted assembler and get the last drop of performance out
> of the machine. I'm an engineer by trade and by training - that's why
> I carry the title of Doctor with pride.
>
> So, get some better programmers, or train your existing ones.
Thanks for your note. Indeed, the programmers on my project probably
don't spend more than 50% of their time testing and debugging. It
depends on where we stand in the development cycle.
I do not share your faith in formal methods or methodologies. To me,
the work of programming consists of weaving order with chaos. The amount
of work to be done is a constant. No amount of external organization
or systematic analysis will reduce the need for application and holistic
attention, because chaos is unsystematic. The act of programming is a
metaphor for the act of living.
Col. G. L. Sicherman
gls@odyssey.att.COM
------------------------------
Date: 3 May 89 12:50:34 GMT
From: Larry Campbell <redsox!campbell@think.com>
Organization: The Boston Software Works, Inc.
Subject: Re: software engineers (U)
>(By the way, I am using "software engineer" as synonymous with "programmer."
Nonsense. "Software engineer" is not synonymous with "programmer". One of
the differences between a software engineer and a programmer is that, while
a programmer probably does spend 90% of his time debugging, a software
engineer spends, maybe, 25% of his time debugging. Furthermore, a programmer
thinks that spending 90% of his time debugging is perfectly natural, while a
software engineer knows that nearly all bugs are fundamentally preventable,
and that each bug in his code represents a personal failing, to be learned
from and avoided next time around.
------------------------------
Date: 3 May 89 22:51:26 GMT
From: Jason <castor.ucdavis.edu!ccs013@ucdavis.ucdavis.edu>
Organization: University of California, Davis
Subject: Re: software engineers (U)
In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes:
>Real programmers spend 90% of their time debugging. Computer science
>curricula ignore debugging, perhaps because it can never be reduced
>to a theory.
>2. The ability to "port" software. This is an acid test for distinguishing
> able programmers from mere C.S. grads.
>3. The ability to maintain somebody else's code. Most C.S. students have
> no experience in this.
and other atributes supposedly lacked by *>mere<* CS grads....
I do not mean to flame the writer of the inserted article, but.....
I do not know what school you went to for your degree (or the schools
of the people you hire) ....but it is
unfortunate that, at that school, the CS students were taught SO
poorly! Where I attend here at the University of California,
Davis.... CS students FROM THE VERY START are taught the things that
YOU say CS people just can't hack (no pun intended). I think that your
statements were very close minded...and arrogant.....
I apologize if I have offended you...but I believe an apology to
those who ARE competent CS grads is due...
------------------------------
Date: 3 May 89 13:58:33 GMT
From: Montgomery <att!ihlpf!warren@bloom-beacon.mit.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Re: "software engineers" -- case study (long) (U)
I read this group only occasionally but was fortunate enough to
stumble across Jim's posting on software engineering as practiced by
DTSS. I worked at Dartmouth before him (when everything was done in
assembly) and have much the same feelings about the quality and
productivity of the work done there. In addition to his reasons,
I'd offer the following observations:
The student programmers were chosen very carefully based on
the non-credit course and placed very carefully in
assignments according to what skills they showed.
They were also there because they enjoyed the job, since it
was not (during my era at least) seen as the route to fame
in fortune it became in the early 1980's
New people worked as apprentices to experienced developers in small
teams. This allowed a lot better transfer of style and
problem solving approaches than happens with typical job
training programs. It also meant that designs and code got
reviewed by at least one other person who was an expert at
the system being modified and could effectively critique the
strategy and style issues instead of focussing on
superficial issues as is more typical of such reviews in
large efforts.
The primitive nature of the tools available (110 baud ttys and lots
of batch compilation) forced people to be careful. People
read and hand interpreted programs before compiling, and
built in lots of trace information that was useful in
diagnosing problems when something did fail.
There were strong feelings of ownership and responsibility for the
software. Ownership went out of fashion with "egoless
programming", but I think it worked well in this environment
at least. Programmers owned modules and when your module
crashed, you got an octal dump in your inbox. The culture
dictated that you figure out what caused each dump and fix
it. Nobody liked being dumped on and everyone worked hard
to keep their stack of unsolved dumps to a minimum.
As to why you don't hear from more DTSS people, lots of them went on
in other fields, and others are hacking away in various niches
without access to anything like netnews and no particular interest
in publishing.
------------------------------
Date: 4 May 89 02:12:05 GMT
From: Garrett Fitzgerald <brunix!cs132046@uunet.uu.net>
Organization: Brown University Department of Computer Science
Subject: Re: software engineers (U)
>3. The ability to maintain somebody else's code. Most C.S. students have
> no experience in this.
The second assignment in CS132 this year was to rewrite UNIX's file
command so that it recognized Pascal. (I would advise against trying
to read file.c--it could be hazardous to your health!)
>[The ability to work from specs]
That was another of our assignments--we had to write our own specs for a
"Breakout" program, but then we had to code the specs they gave us.
>6. The ability to write adequate user documentation. See 4.
Writing the ExDoc was a major part of our final project.
>7. Experience with a variety of languages, environments, and methods.
One of the few failings of the department here. We do almost all of our
programming assignments on Suns, with various different interfaces for
the different courses. CS132 (Intro to S.E.) uses X, CS4 uses an
environment called Passe`, CS12 uses yet another...If we ever have to
deal with MS-DOS and PC-XT's, we could be in trouble...
------------------------------
Date: Tue, 2 May 89 15:27:19 EDT
From: howell@starbase (Chuck Howell)
Subject: Exception handling models
I'm interested in alternative exception handling models (e.g., Bertrand
Myer's arguments on "disciplined exceptions" in _Object-oriented
Software Construction_) and various idioms & conventions for use with
existing Ada exception handling facilities. Other language models are
of real interest, too.
Any comments (e.g., "If I don't get parameterized exceptions in Ada9X,
I'll hold my breath 'till I turn blue!"), references, or summaries of
related work will be appreciated; I'll post a summary to the Net.
thanks,
Chuck Howell
MITRE, Mail Stop W418
7525 Colshire Drive
McLean, VA 22102-3481
howell@starbase.mitre.org
------------------------------
Date: 3 May 89 18:35:17 GMT
From: storm development account <reign!storm@uunet.uu.net>
Organization: Softa, Washington D.C.
Subject: CASE project update (?) (U)
I recently posted an article about starting a CASE tool design
effort. The most common response was 'What do you want it to do?'.
The answer to that is 'I don't know!'.
When I am designing a project, I use:
. A data dictionary (rudimentary)
. Data flow diagrams showing system i/o and some processes
. Structure charts showing the hierarchy, data and
control couples, and sometimes some high
level control flow
However, this is me. By looking at the above, you can also see that none
of it is 'pure' with regard to common methodologies. They reflect my
needs and how I work.
As far features of the package, it should be:
. Project oriented
. Useable by multiple designers (implying levels of
control to prevent unauthorized changes)
. Flexible (you want a symbol that not part of the
"official" symbol set, add it)
. Graphic output to plotter, postscript, printers, etc.
. Strong checking as far as arguments, variables in
the data dictionary, function types
. Being able to specifically override the strong checking
. Integrated - if you are (for example) working with
the structure chart and need to check the
data dictionary, a data dictionary window
should appear
. Though it has graphic output, the positioning of
all the graphic elements should be determined
by the computer so that manual fitting is
not required
. Be useful across a range of applications such as
database projects and system engineering
projects
Okay, folks, this is what I think it should do. Rather than
implement something that fits only my needs, I'd like something of more
general use that could help bring CASE tools into greater use. The
project certainly won't lead to fame and fortune, but might help nudge
the industry towards methods or tools.
If you have a CASE 'wish list' let me know. Even if we can't
get a project started, I will be developing something and what you want
might get added in.
------------------------------
Date: 3 May 89 22:06:42 GMT
From: Yen-Ping Shan <thorin!unc!shan@mcnc.org>
Subject: Surface area for software (U)
Sorry about the confusion raised by my previous posting. English is not my
native language. I didn't realize that "surface area" has a more common
meaning. Let me try to get it straight this time.
Cox in his book, "Object Oriented Programming" p. 16, defines the "surface
area" as "the number of things that must be understood and properly dealt
with for one programmer's code to function correctly in combination with
another's."
What I am interested in is:
1. Who invented the term "surface area?" Under what context?
2. Is there a more precise definition?
3. Is there a systematic way to compute surface area? (So that we can
say, for example, the surface area between module A and B is 10 and
the surface area between module B and C is 100, therefore B and C
are more closely coupled than A and B.)
------------------------------
Date: 2 May 89 21:52:21 GMT
From: Jeff Aguilera <hpda!hpcuhb!hp-ses!hpcea!hpnmdla!hpmwtd!jeffa@bloom-beacon.mit.edu>
Organization: HP Microwave Tech. - Santa Rosa, Ca.
Subject: Re: grep vs. SEARCH (Was Re: Software Development Tools) (U)
>>Knuth made a wrong assumption: That the use of an otherwise clause in
>>the case statement was portable.
"(Of course, if no default mechanism is available, the case statements
of TeX will have to be laboriously extended by listing all remaining
cases. People who are stuck with such Pascals have, in fact, done this,
successfully but not happily!)"
--- Donald Knuth
"TeX: The Program"
------------------------------
End of Software Engineering Digest
**********************************