soft-eng@MITRE.ARPA (Alok Nigam) (12/26/88)
Software Engineering Digest Saturday, 24 Dec 1988
Volume 5 : Issue 50
Today's Topics:
Pseudo-Code description...
Re: software complexity measures
IEEE NEWS GROUP CREATED
Looking for Software Publishers
Makefile Generators (3)
ALGORITHM DESIGN BIBLIOGRAPHY - RESULTS (245 lines)
Re: Software Maintenance for the UNIX Operating System
The High Cost Of Software Practice & Experience (3)
What's the Best OOP Text? (2)
Human Factors and Software Engineering
Re: Professional Programmers (was: Seeing the future)
Vendors of Ada ADTs
------------------------------------------------------------
Date: 13 Dec 88 04:41:41 GMT
From: munnari!basser!natmlab!ipso!metro!pta!teti!nswitgould!ausonics!hanifl@uunet.uu.net (Hanif LADHA)
Organization: Ausonics Pty Ltd, Sydney, Australia
Subject: Pseudo-Code description...
Would like a ``standard'' way in which I can represent pseudo-code in a
design specification. Such specifications are reviewed by hardware
engineers who aren't neccessarily fluent with a programming langauge (eg
C). Appreciate any info. Thanks in advance.
Ps: Oh yes and Merry Christmas to everybody!
------------------------------
Date: 17 Dec 88 07:05:38 GMT
From: tektronix!reed!psu-cs!warren@bloom-beacon.mit.edu (Warren Harrison)
Organization: Dept. of Computer Science, Portland State University; Portland OR
Subject: Re: software complexity measures
Numerous software complexity metrics are currently available. The most
popular (at least as far as commercial software metric analyzers go) are
the Cyclomatic Complexity and Software Science. To the best of my know-
ledge, there are currently around half-dozen commercial software metric
packages on the market, and they all include these two families of metrics.
The October '89 issue of Computer Language Magazine will feature a 'focus
on' section for software metric tools ... I don't yet know which one's
they'll be looking at, but will post it when I find out if there is any
interest.
Two more recent trends tend to be towards "interconnection complexity" and
data structure/flow complexity. The interconnection metrics are best
exemplified by Sallie Henry's metric, though a number of others are also
available. No commercial tools do the interconnection metrics (that I
know of), but a couple do some version of data flow (eg, span of reference).
I mention the metrics used by the commercial tools mainly because (1) these
are being used 'in the trenches' and not on student projects, (2) the
companies that make them are still in business which means at least some
customers are happy with the metrics. If anyone wants to learn more, send
me e-mail, write me or call me.
------------------------------
Date: 20 Dec 88 15:01:42 GMT
From: att!whuts!homxb!hou2d!krsm@bloom-beacon.mit.edu (S.MURTHY)
Organization: AT&T Bell Laboratories, Holmdel
Subject: IEEE NEWS GROUP CREATED
IEEE NEWS GROUPS
(comp.org.ieee and att.society.ieee)
Friends,
The IEEE NEWS GROUPS, one for circulation within AT&T only
called att.society.ieee and another called comp.org.ieee
for world-wide circulation and use have been created.
I sincerely thank all of you who have supported in this
effort. I will try to get an article or some type of
coverage in IEEE INSTITUTE (a news suppliment to IEEE Spectrum)
to help publicize about this group and also increase
awareness about the groups' usefulness.
I encourage all of you to post any news information,
call for papers, conferences, special lectures and also
any professional discussions. To post anything
Type postnews (Return)
and then you get user friendly messages.
I will be posting some background info on the news groups.
Thanks to all of you, again.
------------------------------
Date: 18 Dec 88 20:33:49 GMT
From: kong!emory!stiatl!todd@gatech.edu (Todd Merriman)
Organization: Sales Technologies Inc., Atlanta, GA
Subject: Looking for Software Publishers
I am putting together a list of software publishers who are interested
in evaluating software from independent developers. It will be catagorized
by:
o/s: msdos, unix, vms, etc.
function: tools, office automation, languages, communications
Please e-mail
Todd Merriman ...!gatech!stiatl!todd
------------------------------
Date: 19 Dec 88 14:38:08 GMT
From: ispi!tfli!cpmain!mergvax!rkxyv@uunet.uu.net (Rob Kedoin)
Organization: Linotype Co., Hauppauge NY
Subject: Makefile Generators
I requested this information from comp.sources.wanted without any
success. Can anyone from this newsgroup help ?
- ---
Does anyone know of any Public Domain makefile generators for UNIX ?
My problem is that programmers(myself included) occasionally forget to
add dependencies into their Makefiles. I am looking for a tool that
will somehow create/verify a Makefile so I can be confident that no
dependencies have been forgotten.
I would like information on non-public domain, UNIX, programs if anyone has
it.
------------------------------
Date: 22 Dec 88 00:14:00 GMT
From: hpda!hpcuhb!hpindda!collin@bloom-beacon.mit.edu (Collin Park)
Organization: HP Information Networks, Cupertino, CA
Subject: Re: Makefile Generators
'mkmf' (according to my manpages, was written by UC Berkeley) is non
public domain i guess. the manpage i have also refers to an article
called 'automated generation of make dependencies' in software practice
and experience 14:6 pp 575-585 (June 1984).
i don't know of any public domain ones.
------------------------------
Date: 22 Dec 88 16:39:46 GMT
From: jerbil@csvax.caltech.edu (Joe Beckenbach)
Organization: California Institute of Technology
Subject: Re: Makefile Generators
The X windows system has a 'makedepend' command which parses like a
C preprocessor to find dependencies which might be hidden by #defines,
other #includes, and #if/#ifdef/#ifndef sequences. There are tradeoffs
involved of course:
1- In building 'makedepend' in X windows, apparently a section of
the cpp source code is needed to ensure proper decoding and handling of #if's.
2- Each file is processed once. If included multiple times, it simply
reuses what information it has. This causes problems in the unfortunate case
where a #if/#else clause selects one of two #includes in one file, and the
other in another: the first time through will set the choice of dependencies
in stone.
The man page says that the algorithm assumes that all the source files
for a given makefile use the roughly the same set of -I and -D flags. The
mechanism is based at bottom on cobbling together a useful framework from a
Berkeley kernel-building makefile which modifies itself to add appropriate
dependencies. [Sorry, can't remember where it is. I think it's in a GENERIC
directory somewhere. (And I call myself a system manager. :-) ]
------------------------------
Date: 21 Dec 88 17:49:51 GMT
From: rochester!kodak!ektools!thomas@rutgers.edu (Thomas B. Kinsman)
Organization: Eastman Kodak, Dept. 47, Rochester NY
Subject: ALGORITHM DESIGN BIBLIOGRAPHY - RESULTS (245 lines)
The following is a bibliography generated by a recent request to
the net for reference books on algorithms in general. No names
will be mentioned, but replies came from many countries around
the world. Several people that I consider influential in our
field responded. Thanks are expressed for all who responded.
I found it amusing that there were several different combinations
of titles and authors given for "THE Dragon Book". The rumors
are not clear as to whether the authors (Aho, Hopcroft, Sethi,
and Ullman) are married to each other, or are simply joined at
the waist from birth. :-) You can all speculate about that among
yourselves. Certainly they have made an important contribution
to our field.
People generally mentioned Knuth. However, Knuth was frequently
mentioned as a lower priority choice when priorities were men-
tioned. Many expressed difficulty with the way algorithms were
given in Knuth. Others suggested that Knuth's method of
presentation leads to a better understanding of the method of
implementation.
Sedgewich was a popular first choice. However, no one mentioned
that there is now a second edition of this book.
Note: This was not a scientific survey. Votes were cast for a
reference by mentioning it in a positive way. In the case where
prioritized lists were received, no weights were assigned. Ti-
tles, Authors, etc... were taken on good faith. The existence of
references was NOT CHECKED.
Some people just responded by mentioning authors. Referring to a
book as "Smith, and Jones" is not always helpful, especially if
Smith and Jones ARE really married to each other and have jointly
written several books. I did my best to figure out which book was
intended, without killing myself in the process.
Some respondents just mentioned titles. Some books are so
closely related, i.e. the "Numerical Recipies in..." series,
that they were grouped together. At any rate, this is just
an information source for your consideration. Neither I, nor my
company, recommend any of them. The following sources of inform-
ation are some you may wish to know about: A more verbose list
is posted to the news group "comp.misc".
~~~~~~~~
~~~~~~~~
~~~~~~~~
General Quotes: "...you judge the utility of a reference handbook by the condi-
tion (the more battered the copy, the more it's been used)..."
"...It's really difficult to pick a first, because this is
nearly always context-dependent..."
"...I hunt around other peoples desks or wander through the
load of sources we have on our system..."
Source: "Algorithms", by Robert Sedgewick
Votes: 19
quotes: "...general purpose..."
Source: "The Art of Computer Programming", by Donald E. Knuth
Volume 1/ Fundamental Algorithms
Volume 2/ Seminumerical Algorithms
Volume 3/ Sorting & Searching
Votes: 39
quotes: "...the last place I go..."
"...No question. Knuth..."
Source: "Intro to Data Structures & Algorithms", (or perhaps),
"Data Structures & Algorithms", by Aho, Hopcroft & Ullman
Votes: 9
quotes: "It's a great little book of basic algorithms & data
structures. Nothing too outrageous, though. My copy is
almost worn out."
Source: Data Structures + Algorithms = Programs, by Wirth
Votes: 6
quotes: "...slightly easier to read, & includes quite a bit of
Modula-2 code..."
"...A notorious book...Disgusting..."
Source: Design & Analysis of Computer Algorithms,
by Aho, Hopcroft & Ullman
Votes: 6
Source: The Theory of Parsing, Translation & Compiling, by Aho & Ullman
Votes: 2
Source: Compiler Design, by Hopcroft, Ulmman & Sethi
quotes: These are the "dragon" books. <DRAGON>
Source: Principles of Compiler Design, by Aho, Hopcroft & Ullman
Votes: 4
quotes: The "dragon" book. <DRAGON>
Source: Compiler Design, by Aho, Hopcroft & Ullman
Votes: 3
quotes: This is the second Dragon book. <DRAGON>
Source: Intro to Formal Languages, Automa Theory & Computation
by: Hopcroft & Ullman
Source: Handbook of Algorithms & Data Structures, by G.H. Gonnet
Pub: Addison-Wesley, 1984
Votes: 4
quotes: "I often look at [this book]. It is useful in itself (with
code in Pascal and/or C) but also full of references--
to 23 textbooks & 683 papers to be exact."
Source: Writing Efficient Programs, by Bentley
Source: Programming Pearls, by Bentley
Source: Numerical Recipes in C, the art of scientific computing
Numerical Recipes in FORTRAN, the art of scientific computing.
Numerical Recipes, the art of scientific computing.
by: W.T. Vetterling, S.A. Teukolsky, W.H. Press, B.P. Flannery
Pub: Cambridge, Cambridge University Press, 1988. ISBN 0-521-35465-X
Votes: 8
quotes: "...It doesn't matter which language, really..."
"...for numerical stuff..."
Source: Structure & Interpretation of Computer Programs,
by Abelson & Sussman
Votes: 3
quotes: "...for numerical stuff..."
by: Bender & Orszag
quotes: "...for numerical stuff..."
Source: Artificial Intelligence Programming
by: Charniac, Reisbeck, Mcdermott & Meehan
quotes: "...It's not the most fundamental book, but I've found [it] to
be the book that establishes the leap from 'Let's Learn Lisp!'
to Lisp in the Real World - filled with all sorts of ideas,
& permanently beside my terminal."
Source: Recursive Techniques in Programming, by D.W. Barron,
quotes: New York, 1968: American
Source: Fundamentals of Data Structures
Fundamentals of Data Structures in Pascal
by: Horowitz & Sahni
Votes: 5
quotes: "...my personal favorite..."
Source: Principles of Data Structures & Algorithms
by: Horowitz & Sahni
Votes: 2
quotes: "...for general data structures..."
Source: Fundamentals of Computer Algorithms, by Horowitz & Sahni
Source: Computers & Intractability: A Guide to the Theory of
NP-Completeness, by Michael R. Garey & David S. Johnson.
Votes: 2
quotes: "...Perhaps not an algorithm catalog in the strict
sense, but I find it useful in problem solving..."
Source: Heuristics, by Pearl
quotes: "...if the problem is NP complete..."
Source: How to Solve It by Computer, by Dromey R.G
pub: Prentice/Hall International Series in Comp. Sci.
Source: Combinatorial Optimization: Algorithms & Complexity
by: Christos H. Papadimitriou & Kenneth Steiglitz
quotes: "fairly new but looks like its full of interesting stuff.
I looked at several similar ones & bought this."
Source: Computer & Job-Shop Scheduling Theory
by: E. G. Coffman, Jr. (Ed.)
quotes: "A collection written by several recognizable people."
Source: "Factorization Methods For Discrete Sequential Estimation"
quotes: "useful for estimation algorithms."
Source: Data Structures & Network Algorithms, by Tarjan
quotes: "...for network problems..."
Source: Graphs & Network Algorithms, by Tarjan
quotes: "...for combinatorial algorithms & recursive structures..."
Source: Priciples of Database & KnowledgeBase Systems, by Ullman
Votes: 2
Author: Teorey & Fry
quotes: "...for data base work..."
Source: Implementations of PROLOG, by Campbell
Source: The Computer Modelling of Mathematical Reasoning, by Bundy
Source: Anatomy of LISP, by Allen
Source: Natural Language Understanding, by Allen
Source: Data Structures, by Reingold & Hansen
Source: Data Structures, by Standish
Votes: 2
quotes: "...understandable level with good Knuth style specifications.
Quite complete also..."
Source: The Unix Programming Environment, by Kernighan & Pike
Source: Software Tools, by Kernighan
Source: Matrix Computations, by Holub & Van Loan
quotes: "...for numerical analysis..."
Source: Artificial Intelligence, by Winston
quotes: "...for AI work, either of the books by Winston..."
Source: LispCraft, by Wilensky
Source: Computer Algorithms, by Sara Baase
Source: Lisp, by Winston
Source: The Art of Prolog
Source: Prolog programming for AI, by Bratko
Source: Fundamentals of Interactive Computer Graphics
by: Foley & Van Dam
Votes: 2
quotes: "...for graphics stuff..."
Author: Chris Date
quotes: "...Relational Databases..."
Author: Ullman, Liskov, Guttag & Sowa
quotes: "...Data structures/abstraction..."
Source: Any number of articles in CACM
Collected Algorithms of the ACM (CALGO).
Comm. of ACM
TODS (Transactions on Database Systems)
Votes: 5
Source: Recent journal article(s) I've read on that problem
Source: Algorithms in SNOBOL4, by Gimpel
Source: "...the SIGARCH world..."
------------------------------
Date: 14 Dec 88 18:51:18 GMT
From: mcvax!unido!tub!coma!axel@uunet.uu.net (Axel Mahler)
Organization: Technical University of Berlin, Germany (West)
Subject: Re: Software Maintenance for the UNIX Operating System
>I'm looking for final solution in maintaining UNIX source code...
We won't claim that this is the 'final solution', but what you're
looking for sounds pretty much like "shape", a toolkit that we've just
implemented. The toolkit consists of a set of version control
commands and "shape", a significantly enhanced Make-oid. "shape" and
the version control commands are integrated on top of AFS ("Attributed
File System"), a dedicated version object base. The system features
RCS-style version control and a configuration identification and
- -build process that has full access to all revisions in the object
base (other than make which only knows about plain files). AFS also
supports derived object management, i.e. it maintains a cache of
multiple versions of compiled object-files (e.g. compiled c-files with
different compile switches).
The "shape" program itself is upward compatible to Make in that it can
properly handle conventional Makefiles. The *Shapefile* however, uses
Makefile-style dependencies as (versionless) 'abstract system model'
and employs 'configuration selection rules' to dynamically bind
particular version objects in the object base to the names listed in
the system model. The version selection mechanism exploits AFS'
ability to maintain any number of arbitrary attributes for objects in
the object base. This yields a configuration identification mechanism
similar to (but more flexible than) DSEE's 'configuration threads'.
On special request, shape records an identified configuration in a
'configuration identification document' (CID) which has the form of
a completely bound Shapefile (all object-instances are explicit). This
makes it particularly easy to rebuild recorded configurations. As
CID's are themselves documents, they can be placed under version control,
making it easy to maintain histories of entire software systems.
One of the most useful features of shape is its support of various
variant administration techniques. Shape makes no assumptions about
the semantics of the 'variant' notion other than having "alternative
(conceptually equivalent) instances of the same concept" (e.g.
'module'). Despite the particular semantics of a certain
variant-concept, there is a small number of techniques to physically
handle variants. These techniques are what shape supports. Most
commonly used techniques are:
- equally named files in different directories
- one source file representing multiple variants that are
extracted by a preprocessor using different preprocessor switches
(e.g. conditional compilation)
- one source file processed by different tools or different
tool versions/variants (e.g. cross compilation, different
coders)
- combinations of the above.
Shape includes a variant definition facility that allows very flexible
and convenient handling of all of the above variant administration
techniques.
The object base abstraction presented by AFS provides uniform access to
immutable revisions of data entities ('files') stored in special
archives, and mutable regular UNIX files. Consequently, the AFS based
toolkit lives peacefully (and meaningfully!) together with standard
filesystem applications (editors, compilers, formatters etc.).
Cooperative work within projects is supported by a build-in status
model, controlling visibility of version objects, and locking, a
primitive form of 'long transactions'. The general concept of object
attributes provides for passing information between indiviual tools
that would otherwise be lost. This mechanism is useful for building
integrated environments from a set of unrelated tools.
The toolkit character of the system allows to use it via shell-commands,
or to build a customized environment on top of it. As an example, we
used GNU-Emacs as an alternate user interface to the system which lead
to a much more comprehensive, integrated user interface. For more
sophisticated requirements, there is a complete C-language interface to AFS,
on top of which all the toolkit programs are built.
There are - of course - some drawbacks that appear worth mentioning.
First of all, the shape toolkit implementation has prototype
character. Although all of the described functionality is
operational, we don't have any experience with larger scale software
development projects. The system may still contain serious bugs.
Second, shape is not exactly blindingly fast. It kind of hurts to use
it on a MicroVAX II (our development system), especially when an
average of 10 people are logged in. People who have a 68020 class
workstation on their desk will probably have fun with shape. Some
important aspects, such as distributed builds (as addressed by DSEE),
are not present in shape.
A word concerning the status of the system.
The shape toolkit is in beta test at a number of companies right now.
It is, however, not clear to what degree shape is used on large scale
software development efforts (version control and configuration management
are long term critical issues for a software company, so there is
understandable reluctance to commit oneself to an unproven tool system).
Shape is not a 'product'. You can't buy it, and if you have it, there
is no guaranteed support.
The good news is: shape is free. We consider posting the whole matter
to comp.sources.unix, or donating it to the GNU project (if they want
it). The software is UNIX portable, i.e. it runs under 4.[23]BSD,
SunOS 4.0, Ultrix 2.0+, and will run under System V.3 very soon.
In case you find shape interesting, you may want to read "An
Integrated Toolkit for Engineering Software Configurations", in
"Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium
on Practical Software Development Environments", Nov. 1988, Boston
Mass., or write to shape@coma.uucp which is the same as
shape@db0tui62.bitnet.
------------------------------
Date: 20 Dec 88 16:02:50 GMT
From: mirror!rayssd!raybed2!linus!munck@bu-cs.bu.edu (Robert Munck)
Organization: The MITRE Corporation, Bedford MA
Subject: The High Cost Of Software Practice & Experience
I just received an advertising flyer from John Wiley & Sons for
the journal "Software Practice & Experience." Anyone who has had
any contact with it knows about the quality of this journal;
the articles are timely, well written/refereed, and extremely
interesting, the Editors and Editorial Board are top-notch
people, and the breadth of coverage is great. Somehow just the
sight of that distinctive red cover says "this is good."
Until, that is, you come to the subscription price. This flyer
offers a mark-down from $315/year to $236.25/year for "personal
subscriptions mailed to a home address." (Twelve issues.)
I honestly don't understand that price. Given the cost of all those
good people, production, (overseas) mailing, etc. etc., how can they
possibly charge $20 an issue? I can't believe that greed is the
motivation, except possibly for the publisher.
I put a lot of time and effort into keeping up with the state of the
art; about 40 journals, newspapers, etc. This one magazine would
cost about 1/3 of what I'm spending now. Consider that it could be
sent out in Postscript form by E-mail, saving all post-editing production
costs. What would they have to charge then?
(That $78.75 difference in cost bothers me, too. Suppose I read my copy
and then donate it to a library. Do I have to send Wiley $78.75?)
-- Bob <Munck@MITRE.org>
------------------------------
Date: 22 Dec 88 06:06:34 GMT
From: bsu-cs!dhesi@iuvax.cs.indiana.edu (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Subject: Re: The High Cost Of Software Practice & Experience
>I honestly don't understand that price [of $236 per year].
Lower-circulation periodicals cost more.
But more importantly, for-profit publishers (as opposed to non-profit
organizations such as ACM) charge what the market will bear. Because
of its quality, "Software--Practice and Experience" is a "must have"
for any library and for many individuals.
------------------------------
Date: 22 Dec 88 23:52:41 GMT
From: naucse!rrw@arizona.edu (Robert Wier)
Organization: Northern Arizona University, Flagstaff, AZ
Subject: Re: The High Cost Of Software Practice & Experience
The first time I ran into this journal was several years ago
when there was a big announcement in the general computer press
that a sort had been developed that was faster than quicksort, and
the details were to be published in SP&E. I'm hazy on exactly
what happened, but it seems like the sort was only faster on
certain data arrangements.
At any rate, does anyone know if these are "paid" articles, in
the sense of substantial money going to the authors, or is it
a "scholar" type pub, where it's just for glory (and tenure)?
------------------------------
Date: 22 Dec 88 05:15:33 GMT
From: portal!cup.portal.com!Christopher_Charles_Lapp@uunet.uu.net
Organization: The Portal System (TM)
Subject: What's the Best OOP Text?
I need references for the best description of
object-oriented systems analysis. Can anybody
steer me to the classic articles, texts, etc?
------------------------------
Date: 23 Dec 88 00:29:05 GMT
From: elkins@topaz.rutgers.edu (George Elkins)
Organization: Rutgers Univ., New Brunswick, N.J.
Subject: Re: What's the Best OOP Text?
I have recently gone from complete ignorance of OOP to a decent level of
knowledge through reading "Object-Oriented Software Construction" by
Bertrand Meyer. I didn't thoroughly understand it until after some
experience with the Eiffel language, though. It may be useful even to
those not having access to an Eiffel compiler, but I wouldn't
vigorously recommend it to those without one.
(Since then I've easily transferred my OOP knowledge to Smalltalk,
which I quickly learned with only the most superficial reading
of a book pertaining to Smalltalk. But I actually prefer Eiffel over
Smalltalk due to my previous experience with block-structured
procedural languages.)
------------------------------
Date: Thu, 22 Dec 88 08:58:12 EST
From: Rajshree Bhatt <RBHATT%WAYNEST1.BITNET@cunyvm.cuny.edu>
Subject: Human Factors and Software Engineering
I am extremely interested in issues on and related to Human Factors in
software engineering. At present, I work as a Systems Analyst, but have
every intention on returning to school to complete my doctrate. Any
ideas, topics, discussions relate to that subject will be greatly appreciated.
I am enrolled in a joint Ergonomics and Software Engineering Program at the
University of Michigan, and at present gathering practical experience in the
field. Please send all mail directly to me -- RBHATT@WAYNEST1. Comments on any
developments in the field and the future of such a field would also be
appreciated. THANK_YOU.
------------------------------
Date: 23 Dec 88 23:58:41 GMT
From: sun.soe.clarkson.edu!rpi!rpics!adamsf@tcgould.tn.cornell.edu (Frank Adams)
Organization: RPI CS Dept.
Subject: Re: Professional Programmers (was: Seeing the future)
(I am directing follow-ups to comp.software-eng; this has nothing to do with
architecture any more.)
In article <1992@ndsuvax.UUCP> ncsmith@ndsuvax.UUCP (Timothy Smith) writes:
> I have to disagree with your last sentence. If you extend this to
>every area in which a programmer may be doing work, ... then the programmer
>has to know about every trick in that area ... I think that the
>programmer should examine what the specialist wants done, find areas that
>look like canidates for optimization, and then ask the specialist ...
I disagree strongly. A professional writing programs in any subject area
has a responsibility to be become, if not expert, at least reasonably well
informed about that subject. This is what employers should be looking
for when hiring programmers, not familiarity with language X. (Although
the latter can sometimes substitute for the former -- it is a safe bet
that someone who knows MUMPS will know something about medical practice.)
------------------------------
Date: 24 Dec 88 21:11:37 GMT
From: hubcap!wtwolfe@gatech.edu (Bill Wolfe)
Organization: Clemson University, Clemson, SC
Subject: Vendors of Ada ADTs
In response to e-mailed queries regarding the addresses of vendors
for Ada ADTs and other reuseable software components, here is a summary:
1) Wizard Software
835 S. Moore Street
Lakewood, CO 80226 USA
Wizard sells the collection of ADTs described by Grady Booch
in his book, "Software Components with Ada" (or words to that
effect). A wide spectrum of implementations is provided,
covering variations such as whether the ADT is of finite
or infinite capacity, whether the ADT has been hardened
such that it can cope with the shared-variable environment
(in which a single instance of the ADT is subject to simultaneous
demands for service from an arbitrary number of tasks), etc.
Booch's book also describes ADT construction techniques in
sufficient detail to enable any reasonably intelligent
programmer to construct his/her own toolbox of ADTs,
and that approach is not without its advantages.
2) Lib Systems, Inc.
P.O. Box 18173
Anaheim, CA 92817 USA
Lib Systems provides software in the following categories:
Mathematical Algorithms, Real-Time Control Systems, Graph
Algorithms, Board Support Packages, Business Packages, String
Processing, Sorting Algorithms, Searching Algorithms, Geometric
Algorithms, and Miscellaneous. Appropriate ADTs are provided
for use with these packages, where appropriate; for example,
both sparse and dense representations of a graph ADT are
provided. However, they do not appear to provide the depth
of coverage available in the Booch components; judging from
the Lib Systems catalog, I would doubt that their graph ADTs
would survive long in a multitasking environment.
As I mentioned in comp.lang.ada earlier, I prefer to construct my own
ADTs, and I therefore have absolutely no experience with, and in no
way do I endorse, the products of either vendor. I have summarized
the knowledge available to anyone who reads the vendor catalogs and
the "Software Components with Ada" book. It is recommended that anyone
who is considering purchasing products from either vendor become familiar
with objective reviews of those products; perhaps someone who knows of
the existence of such reviews could summarize the results.
Other reuseable software sources which I have heard of but have no
specific information on include the GRACE library from EVB, and the
RAPID library of MIS software. Anyone having knowledge of these or
other sources should feel free to contribute a followup article.
------------------------------
End of Software Engineering Digest
**********************************