MDAY@XX.LCS.MIT.EDU (Moderator, Mark S. Day) (10/26/87)
Soft-Eng Digest Sun, 25 Nov 87 Volume 3 : Issue 13
Today's Topics:
Fortran Source Code Metrics
Software Technology is NOT Primitive (5 msgs)
Productivity: Progress, Prospects, and Payoff Call for Papers
ICSE-10 Call for Tools
----------------------------------------------------------------------
Date: Fri, 25 Sep 87 09:02:32 EDT
From: johnson@NADC.ARPA (R. Johnson)
Subject: Fortran Source Code Metrics
Thanks to everyone who responded to my request for information on the source
of Halstead/McCabe metrics programs for Fortran source code. For the benefit
of anyone else looking for such programs, here is a summary of what I found out:
"Analyze," a product of Autometric, Inc., calculates metrics for Fortran and C
code on an IBM PC. It is written in Ada and costs $495. The capability to
analyze Ada, Cobol, and Pascal code is available at extra cost. For more
information, contact:
Autometric, Inc.
891 Elkridge Landing Rd. #350
Linthicum, Md 21090
301-859-4111
NASA Goddard Space Flight Center's (GSFC) "Fortran Source Code Analyzer Program"
(SAP) calculates a variety of metrics for Fortran code. It is written in
employees, and employees of other government agencies, it is available free
from:
Goddard Space Flight Center
Computer Program Library
Building 23, Room C-238
Greenbelt, Maryland 20771
301-344-6796
For others, it is available "for a small fee" from NASA's Computer Software
Management and Information Center (COSMIC). Contact:
COSMIC
112 Barrow Hall
Uiversity of Georgia
Athens, Georgia 30602
404-542-3265
------------------------------
Date: 22 Oct 87 01:01:55 GMT
From: crowl@cs.rochester.edu (Lawrence Crowl)
Subject: Software Technology is NOT Primitive
Software technology is not in the primitive state that people so constantly
moan about. First, software has a much more difficult task than hardware. We
have more expectations from software than hardware, so the perceived state of
the technology is less than the actual state.
Consider the "great advance" in memory chip size. Most of the impressiveness
of the advance comes from replication of design effort. Is a software engineer
given accolades when he calls a subroutine a million times instead of a
thousand? Hardly. Much of hardware design is replication, but very little of
software design is replication.
In 1950, a processor had hundreds to thousands of gates and a large program had
a hundred to a thousand lines. Today, a processor has (say) a hundred thousand
to a million gates, while a large program has a hundred thousand to a million
lines of code. The track well don't they? But let's look closer. In 1950, a
processor had a control unit, a few registers and an ALU while a program had a
simple routine to read cards, a simple routine to drive the printer, and a
simple core algorithm. Today, a processor had a control unit, a few registers
and an ALU (note the less than radical change), while a program has a graphics
interface, a file manager, a recovery scheme and a performance monitor in
addition to the core algorithm. There has been quite a deal of change in the
tools and _functional_ capabilities of software systems.
"But hardware systems have improved performance by four orders of magnitude
since 1950!" True, but for many problems, you are better off running today's
algorithms on 1950's hardware than 1950's algorithms on today's hardware. Do
not deny software its contribution to performance. (Although to be fair, we
have already reached the theoretical maximum performance for many algorithms.)
In article <3349@uw-june.UUCP> bnfb@uw-june.UUCP (Bjorn Freeman-Benson) writes:
>However, one must consider that current software technology is at the level of
>individual transistors and resistors, and that we could use the step up to
>"7000 series ICs". After that, custom and semi-custom would be great.
Well, I apply different analogies. I think you will find these better related
to the actual scale of work.
transistors == machine language
7400 series == assembly language
msi == higher level languages
lsi == libraries
vlsi == utility programs (ala Unix)
custom ICs == inheritance and generics (needs more experience to say for sure)
It looks to me like software and hardware technology have tracked fairly well.
The cause for the difference in perception is that hardware has done the same
task cheaper and faster while software has performed an ever more difficult
task. Because hardware has simpler measures, it has more apparent progress.
The actual progress is roughly equivalent.
--
Lawrence Crowl 716-275-9499 University of Rochester
crowl@cs.rochester.edu Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627
------------------------------
Date: 23 Oct 87 01:48:50 GMT
From: ihnp4!ihopa!jdu@ucbvax.Berkeley.EDU (John Unruh)
Subject: Software Technology is NOT Primitive
In article <3471@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
> Software technology is not in the primitive state that people so constantly
> moan about. First, software has a much more difficult task than hardware. We
> have more expectations from software than hardware, so the perceived state of
> the technology is less than the actual state.
>
> transistors == machine language
> 7400 series == assembly language
> msi == higher level languages
> lsi == libraries
> vlsi == utility programs (ala Unix)
> custom ICs == inheritance and generics (needs more experience to say for sure)
>
> It looks to me like software and hardware technology have tracked fairly well.
> The cause for the difference in perception is that hardware has done the same
> task cheaper and faster while software has performed an ever more difficult
> task. Because hardware has simpler measures, it has more apparent progress.
> The actual progress is roughly equivalent.
>
I really like Lawrence's analysis. He has a few vital points.
1. Today's software projects attack extremely difficult tasks. It is
unlikely that these tasks would be attempted in a circuit or in a
mechanical system.
2. Software technology has evolved. I would not have built the same
equivalence that he did, but his way of looking at things is certainly
reasonable.
I have a few observations that I would like to add.
1. I believe many of the problems attributed to
the "software crisis" are a by product of the difficulty of the task
itself, not of the fact that the solution is implemented in software.
Often we run into problems because we do not understand the problem
that we are trying to solve well enough. Therefore, the program that
is built doesn't solve the right problem.
2. Often the people who wish to purchase a software system to inprove the
efficiency of their operation do not understand the true problem that
they want to solve. Introducing automation does not always make a
business run more efficiently, largely because the change introduced
in work methods by the automation changes what should be automated.
I think those who specify what is to be done often don't get this
right. I am not sure it is possible to get it right in many cases.
An example is the stories I have read about the introduction of robots
on assembly lines. Supposedly many of these installations have not
worked out well on an economic basis.
3. I am not entirely convinced by the arguments presented of where money
is spent during the "software life cycle". I have seen varying estimates
up to 80% for maintenance. I always wonder what maintenance means. Does
it include enhancements to the product because customer needs were not
understood? Does it include enhancements to address more markets?
Does it include ports to new operating environments such as porting a PC
program to the MAC environment? These things are very different than
bug fixes. If things are counted this way, the newest IBM 370 series
computers should probably be counted as engineering changes on the
original 360.
4. Program bugs after release are a serious problem. Just read
comp.micro.ibm.pc to see how many postings are related to bugs
in standard packages. I would hate to have to pay to send a free
update diskette set to every registered owner of LOTUS 1-2-3
(This is probably a trademark of LOTUS development). I would still
rather do this than put a white wire change into every IBM PC.
With today's hardware, the answer to hardware problems may be to
document them and program around them. This is equivalent to a
work around solution for software problems. I will not make
apologies for buggy software. We need to make some improvements
here.
5. The theoretical base is better for hardware than for software.
People have been studying the physics of electricity for MANY
years, and many things are well understood. One of the reasons
many new hardware designs work well is because they are extensively
simulated. They can be simulated because the theoretical base allows
software to simulate them. Most of the work in theory supporting
software that I have seen falls into two classes. The first is the
analysis of algorithms. This area has been extremely fruitful. We
have been able to find good algorithms for many computations. We also
have been able to find theoretical upper bounds for performance and
see how close we have come to those bounds. The second area is in the
theoretical basis for computing in general. In my mind, this area
covers many basic problems such as the halting problem and proof of
correctness. The advances in this area have been significant, but they
are very difficult for the working programmer to use. They are more
like Maxwell's equations for electromagnetic fields. I don't know
of any theoretical basis that supports software like circuit analysis
supports circuits (both digitial and analog) or like boolean algebra
supports digital circuits. We have no good way of doing automatic
(or really semi-automatic) checks of software boundary conditions,
or of driving software through many states. Currently, we manually
generate many tests, and then we manually run them. It would be
really nice if we could have some system generate and run tests
and then we could analyze the results.
6. The state of the theory as listed in 5 also makes correctness by
construction difficult. I don't really think circuit designers
do everything like that anyway.
I hope I have managed to shed some light on the matter, and perhaps
to spur some thought.
John Unruh
------------------------------
Date: 23 Oct 87 08:16:20 GMT
From: amdahl!drivax!socha@ames.arpa (Henri J. Socha (7-x6628))
Subject: Software Technology is NOT Primitive
AHH! The wonderful advantages of blinders.
I don't intend to repeat your statements.
They were well written but a little shortsighted I think.
Now I'm a software type as well but with an EE degree.
But my software has ranged from writing micro-code (pretty close to hardware
if you ask me) to application with a big smattering of OS and networks
inbetween.
Any you have greatly simplified the advances made in the hardware area.
Now, I do not want to argue extents because I will agree that software
has changed greatly but so has hardware.
Consider DSP chips, bit blitters, LAN processors, IEEE floating point
in hardware, VM, segmentation, caches, ASICs, just to name a few
of the hardware complexity improvements.
Ever try to build a 68000 with TTL? It can be done but it is not
only large but VERY COMPLEX.
Every tried to understand some code where there are hundreds of thousandsf
of lines and sometimes just putting a line close to another line of code
will cause invalid code to be executed? (Said humourously but with reason.)
So, don't sell those hardware types short
(especially when they may not be reading this newsgroup).
--
UUCP:...!amdahl!drivax!socha WAT Iron'75
"Everything should be made as simple as possible but not simpler." A. Einstein
------------------------------
Date: 23 Oct 87 15:15:50 GMT
From: defun!shebs@cs.utah.edu (Stanley T. Shebs)
Subject: Software Technology is NOT Primitive
I think one of the reasons for the perception of software technology as
primitive is that the languages have not changed very much in 30 years.
C seems to be in the ascendant for research work, yet it is not too far
removed from Fortran (no language fanatic flames please). Of course, the
*use* of the languages now is very different, as are the algorithms they
express, but it is an article of faith in some circles that progress in
software == use of higher-level languages.
stan shebs
shebs@cs.utah.edu
------------------------------
Date: 23 Oct 87 23:33:30 GMT
From: thoth17.berkeley.edu!adamj@jade.Berkeley.EDU
Subject: Software Technology is NOT Primitive
In article <1691@culdev1.UUCP> drw@culdev1.UUCP (Dale Worley) writes:
>Another feature of "software ICs" comes from the fact that they are
>part of an object-oriented system. One can actually write, say, a
>linked list manager that will work on objects of *any* type. In most
>languages, this is impossible to do in a library routine.
"Object oriented?" What you are describing involves
parameteized typing and polymorphic routines. Objected oriented
programming (in my book) involves data hiding and polymorphic routines.
Parameterized typing is an independent concept from data hiding.
Parameterized typing should be a tremendous win because it
then becomes possible to change the lower levels of a hierarchical
type without affecting the routines that only need to know some overall
information about that type.
I'd like to drop the term "software IC" as that an IC is noticibly
deficient in this low-level parameterization. E.g., I can't buy a TTL IC
from Radio Shack, buy a GaAs description module, apply one to the other,
and get my favorite chip design in GaAs. The chip design has to be
reworked by the manufacturer, just like present day software has to be
recompiled and probably edited by an owner of the source code.
>I suspect that I could write considerably less code if I could write
>in one statement all the trivial, but extremely stereotyped, bits of
>code. After all, what fraction of your lines of code are
>loop-and-search, and other completely standard stuff?
>Dale
Right on!
--Adam J. Richter
adamj@widow.berkeley.edu
...!ucbvax!widow!adamj
Adam J. Richter adamj@widow.berkeley.edu
....!ucbvax!widow!adamj
(415)642-7762
------------------------------
Date: Tue, 20 Oct 87 09:26:29 EDT
From: Charles Youman (youman@mitre.arpa) <m14817@mitre.arpa>
Subject: Productivity: Progress, Prospects, and Payoff Call for Papers
Call for Papers
PRODUCTIVITY: PROGRESS, PROSPECTS, AND PAYOFF
27th Annual Technical Symposium
Gaithersburg, Maryland June 9, 1988
Productivity is a key issue in the information industry.
Information technology must provide the means to maintain and
enhance productivity. Productivity: Progress, Prospects, and
Payoff is the theme of the 27th Annual Technical Symposium spon-
sored by the Washington, D.C. Chapter of the Association for Com-
puting Machinery (ACM) and the Institute for Computer Sciences
and Technology, National Bureau of Standards (NBS/ICST). The
symposium will explore the theoretical and practical issues in
developing and applying technology in an information-based
society. How productive are we? How productive can we become?
What are the inhibitors and facilitators? Some of the following
areas are suggested:
Software Hardware
System Considerations Economic Considerations
Environments Labor and the Work Place
The Knowledge Industry Impact of Ada
Capture and Use of Expertise When to Standardize
The Hardware-software Gap Higher Level Languages
Building, Testing, and Main- Artifical Intelligence
taining Systems and Knowledge-based Sys-
tems
The conference program committee has issued a call for
papers covering new concepts, research in progress, and completed
work, as well as reviews or overviews of relevant work in tech-
nology, management, and other pertinent areas. Papers of 10 to
20 double-spaced pages are suggested. Papers must include the
name, mailing address, and telephone number of each author or
other presenter. Five copies of papers should be submitted by
December 17, 1987 to the program chairman at the following
address: John E. Gaffney, Software Productivity Consortium, 1880
Campus Commons Drive North, Reston, VA 22091. Both experienced
and first-time authors are encouraged to present their work. The
papers will be refereed. Authors will be notified of acceptance
by February 1, 1988. Final versions of papers are due April 1,
1988 (no fooling). Authors of accepted papers (excepting papers
that cannot be copyrighted under government regulations) must
transfer copyright to the ACM for material published in the
conference proceedings.
For additional information about the symposium please con-
tact: Symposium General Chairman Charles E. Youman, The MITRE
Corporation, 7525 Colshire Drive, McLean, VA 22102, Telephone:
(703) 883-6349, electronic mail address: youman@mitre.arpa.
------------------------------
Date: Mon 28 Sep 87 06:48:34-PDT
From: Grady Booch <GBOOCH@ADA20.ISI.EDU>
Subject: ICSE-10 Call for Tools
CALL FOR TOOLS FOR THE 10TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING
A Tools Fair will be held from 13 to 15 April, 1988, in parallel with the
technical sessions of the 10th International Conference on Software
Engineering, to provide an opportunity for softare professionals to be
exposed to the latest commercial and research tools. The Tools
Fair consists of two parts: the Tools Exhibition, and the Tools
Presentation Track. The Tools Exhibition offers a forum for vendors and
research organizations to display their tools; the Tools Presentation Track
forms one of the technical tracks of the 10th ICSE, featuring presentation ad
demonstration of tools selected by the tools fair committee.
The 10th ICSC will be held in the Raffles City Convention Center, Singaapore.
The tools fair committee will arrange with Singapore computer companies to make
hardware available for overseas exhibitors to demonstrate their software
tools.
For further information, contact:
American and European exhibitors:
Grady booch
Rational
835 S. Moore St
Lakewood, CO 80226
Phone: 303-986-2405
Arpanet: gbooch@AJPO.SEI.CMU.EDU
Asian, Australasian and other exhibitors:
Wong Sen Hon
National Computer Board
71 Science Park Drive
Singapore 0511
Republic of Singapore
Phone 7720291
Bitnet ncbise1@nusvm
egb
-------
------------------------------
End of Soft-Eng Digest
******************************
-------