soft-eng@MITRE.MITRE.ORG (Alok Nigam) (05/31/89)
Software Engineering Digest Tuesday, 30 May 1989
Volume 6 : Issue 21
Re: CASE Tools: References (U)
Re: software engineers (U)
Re: Surface Area (U)
Summary of Books on Object Oriented Design (U)
Re: CASE Tools: References (U)
Re: software engineers (U)
Re: software engineers (U)
Floating Point in COBOL (U)
Re: "software engineers" -- case study (long) (U)
Re: Floating Point in COBOL (U)
Error information in various OSes
Re: software engineers (U)
Re: Surface area for software (U)
Correction: Books on Object-oriented Design (U)
Re: software engineers (U)
software engineers (U)
Today's Topics:
------------------------------------------------------------
Date: 2 May 89 21:50:27 GMT
From: Mike Balenger <att!homxb!ho7cad!msb@bloom-beacon.mit.edu>
Organization: AT&T Bell Laboratories
Subject: Re: CASE Tools: References (U)
This book is an intro to CASE, a discussion of a few available tools,
and a list of the major CASE tool vendors.
cn 005.1/F533c
ti CASE : using software development tools / Alan S. Fisher.
au Fisher, Alan S.
pu New York : Wiley, c1988. xv, 287 p. : ill. ; 24 cm.
no Includes index. Bibliography: p. 281-284.
su Computer software--Development.; Software engineering.; Computer
programs--Design.
b-no 452490M isbn 0-471-63747-5 (pbk.) lccn 88-10142 oclc 17807437
------------------------------
Date: 3 May 89 21:43:14 GMT
From: Sean Matthews <mcvax!ukc!etive!lfcs!sean@uunet.uu.net>
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Subject: Re: software engineers (U)
In article <855@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes:
>Dr Hubert Matthews at CERNvax has privately sent me the following note.
[point made in favour of Formal methods by the good Doctor (good on two counts:
he shares a surname with me and he is in favour of formal methods - did you
ever run into Jon by the way?)]
>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
>Col. G. L. Sicherman
>gls@odyssey.att.COM
^^^^^^^
I just what to clear up a point; isn't Odyssey Richard Platek's operation
in Ithaca (sorry about the spelling) which specialises in mathematically
verified software i.e., formal methods?
Or has the good professor gone back to mathematical logic and left the field
to the hackers?
Se\'an
------------------------------
Date: 3 May 89 09:24:50 GMT
From: Keith Richards <mcvax!ukc!axion!krichard@uunet.uu.net>
Subject: Re: Surface Area (U)
>> Can anyone give or point me to a precise definition of "Surface
>> Area?" Is there a system that allows me to compute the value of the
>> surface area?
A more relevant use of the phrase (considering the newsgroup) is that
of Brad Cox in his `Object Oriented Programming' book for Addison
Wesley. I think the term is used loosely and is meant to illustrate
the concept by analogy, but an imprecise definition is given 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"
I haven't seen the expression used elsewhere in this context though.
------------------------------
Date: 3 May 89 18:39:01 GMT
From: Charles Weir <mcvax!ukc!stc!idec!marlow!cweir@uunet.uu.net>
Organization: Reuters Ltd PLC, Marlow, Bucks, England
Subject: Summary of Books on Object Oriented Design (U)
Thank you all out there for a number of replies to my question on
books about object-oriented design. This is really encouraging.
Far and away the most popular book on the subject is:
Bertrand Meyer
Object-Oriented Software Construction
UK Prentice-Hall 1988
This provides a clear descriptions of the principles of
object-oriented design. Don't be put off by the emphasis on the
Eiffel language - the examples are easy to understand, and the whole
is a remarkably good read. It also gives (a somewhat biassed) view
of other OO languages eg. C++, smalltalk etc. Highly recommended.
Another is:-
Brad J. Cox
Object-oriented Programming - An Evolutionary approach
Addison-Wesley, Reading Massachusetts 1986
This provides an introduction to object oriented programming, with
particular emphasis on C++. It also discusses (although in very
little detail) the possibility of incorporating existing non-object
code.
Three papers on the subject are:-
Bertrand Meyer
Reusability: The Case for Object-Oriented Design
IEEE Software April 1987
This gives a very detail analysis between functional approach and
Object-oriented approach.
Roland T. Mittermeir
Object-oriented Software-Design.
Software Engineering Environment - Proceedings of the
international workshop on software engineering environment.
China Academic publishers 1986
This relates OOPs to Software Engineering Design. It compares the
OOP approach to JSD and Yourdon method. It is very useful for people
who are interested both in OOP and SE.
------------------------------
Date: 4 May 89 18:25:27 GMT
From: David Taylor <voder!cullsj!david@bloom-beacon.mit.edu>
Organization: Cullinet Software, San Jose, CA
Subject: Re: CASE Tools: References (U)
> I am looking into different CASE Tools available in the market for PC as
> well as mainframe environment. Does anybody already have a compiled list
> of such tools?
>
> Is there any book/paper which does a comparative study of the existing
> tools?
In the 4/89 issue of IEEE Computer, there is a review of a book called
"CASE: Using Software Development Tools" that the reviewer feels "offers
a highly readable but somewhat shallow overview of the most popular
commercial CASE tools [10] and their methodologies...It targets practicing
software engineers and managers who need a quick overview of the subject
but are not willing to thoroughly investigate it." It's by Alan S. Fisher
(John Wiley, NY, 1988, 287 pp, $24.95).
In that same issue, under "New Literature" is a blurb for "CASE Analyst
Workbenches: A Detailed Product Evaluation". It is said to "provide
guidelines on choosing, implementing, and using analyst workbenches to
maximum advantage. It reviews 66 workbenches and includes tables
highlighting the available features and conventions." It's by
Rosemary Rock-Evans (2 volumes, 780 pp, #550). Contact Ovum Ltd.,
7 Rathbone St., London W1P 1AF, England.
------------------------------
Date: 4 May 89 00:50:51 GMT
From: The Polymath <apple!versatc!mips!prls!philabs!ttidca!hollombe@bloom-beacon.mit.edu>
Organization: The Cat Factory
Subject: Re: software engineers (U)
>Debugging is something they all should have done on programming
>assignments, but how do you rate debugging skill? ...
On one job interview I brought along a sample. I showed them two listings
of a program I'm currently responsible for. The first was the one I got
when I took over maintenance of the (extremely buggy) code. The second is
what the code looks like now (bug free, as far as I know).
Don't know if it helped, but they were on the point of hiring me when the
job got moved from Berkeley to Boston. Oh, well.
------------------------------
Date: 4 May 89 00:57:37 GMT
From: The Polymath <apple!versatc!mips!prls!philabs!ttidca!hollombe@bloom-beacon.mit.edu>
Organization: The Cat Factory
Subject: Re: software engineers (U)
}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.
Perhaps we have a semantic quibble here. The usual figure quoted is a
system will spend ~70% of its life in maintenance mode. Maintenance is
much more than debugging. It includes enhancement and making the program
do what the customer wants it to do, after you've made it do what they
asked for it to do.
Given that, it's not unreasonable to expect most programmers to spend 70%
of their time maintaining existing software, as opposed to creating new
software from scratch.
------------------------------
Date: 5 May 89 01:24:35 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: Floating Point in COBOL (U)
Perhaps this is stretching a point since after checking, I found out this
is an IBM extension to the ANSI-78 standard, but COMP-1 and COMP-2 are
single and double word floating point data types, aligned on fullword and
doubleword boundaries, respectively. Computational is fixed point. True,
COMP-3 (packed decimal) is limited to 36 characters, but I know of no other
language which provides this much accuracy (remember, this stuff is stored
in base 10, so round off errors are significantly reduced) in a data type.
36 decimal places is: 999999999999999999999999999999999999.
Please note that I didn't suggest COBOL was an all purpose programming
language, but that modular programs could be written at least as easy in
it as in most other langauges, and much easier than in many other languages.
The overhead of a COBOL subprogram call is probably less than the overhead
of a Pascal call since local variables do not have to be generated each time
(data items within the subprogram are static), thus you have less of a performance
ding against subprogram calls than in many other "modular" langauges.
I know of many non-commercial applications that have been written in COBOL.
For example I have been told that Micro Focus COBOL/2 is written in COBOL.
I myself have written a COBOL subset compiler in COBOL (and Pascal
compilers in Pascal - I failed to see much difference once you're familiar
with the language). So far, no operating systems or flight control software
though :-)
------------------------------
Date: 5 May 89 02:55:48 GMT
From: Scott_Gulland <hpda!hpdslab!hp-ptp!scottg@bloom-beacon.mit.edu>
Organization: HP Indus. Appl. Center, Sunnyvale, CA
Subject: Re: "software engineers" -- case study (long) (U)
>Real programmers spend 90% of their time debugging. Computer science
>curricula ignore debugging, perhaps because it can never be reduced
I beg your pardon! YOU may spend 90% of your time debugging, but no one
I have known in the last ten years of software development has spent anything
close to 90%. Most engineers might spend at most 10% of thier time debugging.
The vast majority of thier time is spent, developing internal and external
documentation, design, coding, testing, and a wide variety of release related
activities. Besides, if you write high quality code in the first place, you
won't end up spending hardly any time at all debugging. Although a useful
skill, it is definitely not in my top ten list.
> Separating design from implementation is usually a mistake; ask the DoD.)
Don't you mean to ignore implementation during design? I'll conceed that
in some classes of applications that this might be true, but it is definitely
not true in the general case (no blanket statements).
> 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.
The problem is there are just not that many people (compared to the industry
as a whole) performing this kind of work. In the last four years, the
orginizations I have worked for has interviewed well over 500 canidates.
Almost none of these canidates has had any significant porting experience.
> 3. The ability to maintain somebody else's code. Most C.S. students have
> no experience in this.
Almost anyone can maintain someone else's code. The important question is
how long does it take to become fluent in that code. Especially if it is
poorly documented and/or poorly written. The amount of experience in this
area can substantially affect their skills.
> 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.
In some jobs this might be very important, but not in a lot of cases. In
many of the jobs I seen and worked on, the development team itself develops
the specs based on customer requirements or feedback (we spend a lot of time
gathering this). Of course you orgnization may do things quite differently.
> 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.
Excellent point! A very rare comodity indeed!
> 6. The ability to write adequate user documentation. See 4.
I whole-heartedly agree.
> 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! You be amazed at the number of people who claim to be engineers
who are unwilling or afraid of learning a new languages, working on a new
OS, etc. Experience combined with a solid CS background gives an engineer
the confidence to tackle any new language, environment, etc.
------------------------------
Date: 5 May 89 18:20:27 GMT
From: Len Lattanzi <apple!versatc!mips!synthesis!len@bloom-beacon.mit.edu>
Organization: Synthesis Software Solutions Inc, Sunnyvale, CA
Subject: Re: Floating Point in COBOL (U)
>Perhaps this is stretching a point since after checking, I found out this
>is an IBM extension to the ANSI-78 standard, but COMP-1 and COMP-2 are
>single and double word floating point data types, aligned on fullword and
>doubleword boundaries, respectively. Computational is fixed point. True,
>COMP-3 (packed decimal) is limited to 36 characters, but I know of no other
>language which provides this much accuracy (remember, this stuff is stored
>in base 10, so round off errors are significantly reduced) in a data type.
>36 decimal places is: 999999999999999999999999999999999999.
As far as I know the COMP-1/COMP-2 are only supported by IBM and
LPI-COBOL, so portable cobol programmers would probably avoid them.
As for extended precision data types, Common Lisp has unlimited size
bignums. I like the ability to work with >32 bit numbers but limiting me
to 64 bits is similar to telling me I can use recursion but only to 6
instantiations.
>Please note that I didn't suggest COBOL was an all purpose programming
>language, but that modular programs could be written at least as easy in
>it as in most other langauges, and much easier than in many other languages.
>
>The overhead of a COBOL subprogram call is probably less than the overhead
>of a Pascal call since local variables do not have to be generated each time
>(data items within the subprogram are static),
>thus you have less of a performance
>ding against subprogram calls than in many other "modular" langauges.
Many FORTRAN implementations work this way (and many non-standard FORTRAN
programs depend on static locals) but often you find that using local stack
variables is faster because the variables have greater locality [parent &
childs locals are less likely to collide in data caches] and can
be referenced relative to the stack pointer rather than building a static
address.
>I know of many non-commercial applications that have been written in COBOL.
>For example I have been told that Micro Focus COBOL/2 is written in COBOL.
>I myself have written a COBOL subset compiler in COBOL (and Pascal
>compilers in Pascal - I failed to see much difference once you're familiar
>with the language).
Well don't try any recursive descent parsers :-)
------------------------------
Date: Fri, 5 May 89 17:17:33 EDT
From: howell@starbase (Chuck Howell)
Subject: Error information in various OSes
In Unix, there is the errno value of the most recent error encountered,
which can be tested to determine at least some indication of what
went wrong. What are the equivalent facilities on other OSes?
Thanks; I'll forward a summary to the net.
Chuck Howell
MITRE, Mail Stop Z645
7525 Colshire Drive
McLean, VA 22102-3481
howell@.mitre.org
------------------------------
Date: 5 May 89 13:29:29 GMT
From: Dave Berry <mcvax!ukc!etive!lfcs!db@uunet.uu.net>
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Subject: Re: software engineers (U)
>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 read several books and articles on debugging as background for my thesis.
I would recommend "Debugging C", by Robert Ward, published by Que corporation.
ALthough it focuses on C on micros without sophisticated environments,
Ward has enough useful ideas of a general nature to make this worth reading
by people learning to program in most languages and environments.
Ward does some teaching, and does teach people how to debug. He claims
that his best pupils are those who can both design well and debug well.
------------------------------
Date: 5 May 89 04:37:00 GMT
From: m.cs.uiuc.edu!render@uxc.cso.uiuc.edu (Hal Render)
Subject: Re: Surface area for software (U)
>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."
I'm sorry I misunderstood you. I don't think Cox chose the term well (if
indeed he did choose the term) given what he intends for it to mean. I
would've said "object context" or "object interface". His definition is
so vague (possibly intentionally) that any concrete means of calculating
"surface area" is difficult to specify. You might take a look at papers
discussing the quantification of module interfaces for more help. I can
give you a couple of pointers if you want.
------------------------------
Date: 5 May 89 18:43:36 GMT
From: Charles Weir <mcvax!ukc!stl!stc!idec!marlow!cweir@uunet.uu.net>
Organization: Reuters Ltd PLC, Marlow, Bucks, England
Subject: Correction: Books on Object-oriented Design (U)
Brad J. Cox
Object-oriented Programming - An Evolutionary approach
Addison-Wesley, Reading Massachusetts 1986
> This provides an introduction to object oriented programming, with
> particular emphasis on C++.
Brad Cox's book concentrates on Objective-C, not C++. My apologies
for any confusion I've caused.
------------------------------
Date: 6 May 89 20:52:46 GMT
From: Emuleomo <aramis.rutgers.edu!paul.rutgers.edu!yes.rutgers.edu!emuleomo@rutgers.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
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.*
> (By the way, I am using "software engineer" as synonymous with "programmer."
> Separating design from implementation is usually a mistake; ask the DoD.)
I must say that debugging skills, although important, are NOT AS IMPORTANT AS
GOOD **SOFTWARE DESIGN** skills.
In general, the amount of time required to debug a program, is INVERSELY
PROPORTIONAL to the amount of time spent on the drawing board designing the
program properly.
Have you ever seen a civil engineer debugging a bridge after it has been built?
Give me a disciplined designer anyday. Debugging is usually the result of
haphazard work.
------------------------------
Date: 6 May 89 01:33:55 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: software engineers (U)
Sure software engineers spend a great deal of their time debugging,
coding, designing, etc. I think many of us are missing one VERY
important activity (that software engineers COULD be prepared for
in school) --- communicating. I find that many of my students (and
many new programmers/software engineers I have worked with) have a
very difficult time of communicating with others, both orally and
in writing. In most of the projects I have been involved in, this
skill was almost as important as programming since you always end up
describing the system or the code or whatever to others.
I don't necessarily mean you have to be able to write the great
American novel, but when you get up in front of the other 20
people on the project and try and explain your part of the system
(or worse yet, the system as a whole) and can't (or worse yet
describe the *wrong* interface) you're in trouble.
Most posters seem to do a pretty good job of it. Maybe if I require
my students to post 3 messages to the net each term they'll improve???
------------------------------
End of Software Engineering Digest
**********************************