soft-eng@MITRE.ARPA (Alok Nigam) (09/20/88)
Soft-Eng Digest Mon, 19 Sep 88 V: Issue 30
Today's Topics:
Anyone using Cadre teamwork IM?
Design assessment report & software metrics
File Compression Utility Wanted
Looking for info on tools & techniques (2 msgs)
Looking for Line of Code Counters
New journal: FORMAL ASPECTS OF COMPUTING
OPEN LOOK (6 msgs)
Test support tools
Validation of Expert Shell Applications
Version control across machines
----------------------------------------------------------------------
Date: 13 Sep 88 21:21:00 GMT
From: mailrus!caen.engin.umich.edu!conliffe@cu-arpa.cs.cornell.edu (Darryl C. Conliffe)
Subject: Anyone using Cadre teamwork IM?
Are there any Cadre teamwork users on the net, specifically
using the IM module? Would like to hear from you for further
discussion of a design issue.
------------------------------
Date: Fri, 9 Sep 88 09:11:34 EDT
From: spratt%lti.com@bu-it.BU.EDU (Lindsey Spratt x24)
Subject: Design assessment report & software metrics
I am responding both to "howell%community-chest.mitre.org@gateway.mitre.org"
(please include real names in e-mail) and Warren Harrison in digest v5n29.
I am the original author of the INSPECTOR product of Language
Technology Inc. Anyone who wants more extensive information than
that provided below (ie marketing literature) should send their US Mail address.
INSPECTOR measures many aspects of COBOL programs, and provides
an extensive facility for creating reports based on these measurements.
These measures include counts of lexical items (e.g. various classes of
tokens), syntactic items (e.g. paragraphs, various categories of
statements), and McCabe's essential and cyclomatic complexity metrics.
The major virtue of the reporting facility is the (fully declarative)
report language in which a user may define her own metrics as
combinations of the ones provided by INSPECTOR's analysis (e.g.
she might define "average statements per paragraph"(ASPP) from the measured
number of statements for each paragraph as:
define-meter(ASPP, divide(total(all-paragraphs, statements),
count(all-paragraphs))).
I find McCabe's essential complexity particularly interesting in
evaluating "maintainability". It is a direct measure of the amount
of unstructured code in a program. Unfortunately, it is relatively
unexplored in the literature on software metrics; perhaps because it
is harder to evaluate than the more heavily researched metrics such as
McCabe's cyclomatic complexity and Halstead's "software science".
US Mail address:
Language Technology Inc
27 Congress St.
Salem, MA 01970
(508) 741-1507
------------------------------
Date: 7 Sep 88 20:13:40 GMT
From: tektronix!teklds!amadeus.LA.TEK.COM!karenc@bloom-beacon.mit.edu (Karen Cate)
Subject: File Compression Utility Wanted
I was wondering if anyone out there has or knows of any good file
compression/de-compression utilities. We are transferring very large
files between a logic analyzer and a host machine. Even over GPIB
or Ethernet, some of these transfers take HOURS, which is annoying to say
the least.
These are the requirements we are looking for:
- Must be portable, or available over a wide range of systems including
but not limited to PC's, Suns, Apollos, Apples, and of course our
LA.
- Must be fast. I.e. compression and transfer must take less time than
transferring the original file. We are looking for speed improvements,
not for disk space optimization.
- We'd prefer this to be a product that is supported by its vendor, but
this is negotiable.
------------------------------
Date: 9 Sep 88 22:36:00 GMT
From: inmet!ishmael!inmet!authorplaceholder@bbn.com <Paul Slonaker>
Subject: Looking for info on tools & techniques
A significant portion of _A_Practical_Handbook_for_Software_Development_,
by N.D. Birrell and M.A. Ould, Cambridge University Press, 1985,
is devoted to overviews of many of these techniques (and others), and
to showing how each could be used in the development of an example system.
The techniques surveyed (grouped roughly by phase) include:
cost estimation techniques (IBM, SLIM, PRICE-S, COCOMO)
requirements definition techniques
PSL/PSA, Structured Analysis (SA),
Structured Analysis and Design Technique (SADT),
Controlled Requirements Expansion (CORE),
Software Requirements Engineering Methodology (SREM),
Finite State Machines (FSM),
Petri Nets,
Jackson System Development (JSD),
RSRE Software Development System (SDS/RSRE)
design techniques
Structured Design (SD),
Jackson Structured Programming (JSP),
System Architect's Apprentice (SARA),
MASCOT,
Formal Development Methodology (FDM),
Hierarchical Development Methodology (HDM),
Higher Order Software (HOS)
------------------------------
Date: 6 Sep 88 15:06:33 GMT
From: mcvax!ukc!stc!stl!phm@uunet.uu.net (Peter Mabey)
Subject: Looking for info on tools & techniques
I'm looking for information about a lot of software/management tools and
techniques, which I've come across by name, but haven't been able to identify
further.
1. ABCL
2. ASTEC
3. ASTRAP
4. DE WOLF
5. DSS - Decision Support System
6. FAN
7. GALPAT
8. HDM - Hierarchical Design Method
9. IRS
10. KEE
11. KNOWLEDGE CRAFT
12. MICROTEXT
13. MIPSE
14. PMS
15. PODEM
16. SAW - Systems Analysis Workbench
17. SDM - Systems Design Methodology
18. SDS - Software Development System
19. SFC - Structured Flow Charts
20. TAGS - Techniques for Automatic Generation of Systems
Things I'd like to know are :
what is it? what does it do? features & facilities?
who developed it? where can I get more information?
what machines? cost?
strengths & weaknesses? competitors?
users' applications? users' opinions?
- but even partial information would be helpful.
------------------------------
Date: Wed, 14 Sep 88 10:36:52 -0700
From: S H Willson <willson@gremlin.nrtc.northrop.com>
Subject: Looking for Line of Code Counters
Anyone have a public domain line of code counter available for
any of these languages?
Jovial
Fortran
C
PL/M
VMS Assembly
1750A Assembly
Also, does anyone know of public domain grammars for those languages?
------------------------------
Date: 9 Sep 88 05:10:24 GMT
From: munnari!otc!uqcspe!banana!ianh@uunet.uu.net (Ian Hayes)
Subject: New journal: FORMAL ASPECTS OF COMPUTING
FORMAL ASPECTS OF COMPUTING
The International Journal of Formal Methods
Editor-in-Chief: C. B. Jones
Associate Editor: D. J. Cooke
Published by Springer International in association
with The British Computer Society.
Announcement and Call for Papers
Computing Science is developing and providing a basis on which complex
systems can be designed and analysed. Theories are evolving in terms
of which a true understanding of difficult computing concepts can be
gained. To employ such theories in discussions requires the use of
formal notation. Although notation can present an initial barrier,
practitioners are now finding that the investment of effort is worthwhile.
The principle aims of ``Formal Aspects of Computing'' are to promote
the growth of computing science, to show its relationship to practice,
and to help in the application of formalisms. In particular,
contributions to the formal aspects of computing are to be published.
The following fall within the scope of formal aspects:
- Well founded notations for system description/specification;
- Verifiable designs;
- Proof methods;
- Theories of objects used in specifications and implementations;
- Transformational design;
- Formal approaches to requirements analysis;
- Results on algorithm and problem complexity;
- Fault-tolerant design;
- Descriptions of relevant ``Project Support Environments'';
- Methods of approaching development.
Applications of known formal methods as well as new results would be
suitable subjects for papers. Comprehensive surveys will also be
published and there is hope that some systematic coverage of major
topics can be achieved over a period of years. Contributions to the
teaching of formal aspects would also be welcome.
To all contributions, normal scientific standards will be applied;
papers must be soundly based, include a proper description of their
context and adequate references to associated work must be given.
People wishing to submit papers should, in the first instance, contact
either Cliff Jones or John Cooke.
Professor C. B. Jones, Dr. John Cooke,
Department of Computer Science, Department of Computer Studies,
The University of Manchester, University of Technology,
Oxford Road, Loughborough,
Manchester M13 9PL, Leicestershire LE11 3TU,
ENGLAND ENGLAND
------------------------------
Date: 14 Sep 88 01:29:55 GMT
From: amdahl!pacbell!well!shf@ames.arpa (Stuart H. Ferguson)
Subject: OPEN LOOK
I recently had the opportunity to listen to Tony Hoeber from Sun
Microsystems speak about OPEN LOOK(tm) (capitalization is correct) and
what it is designed to do.
I don't like it. I don't like it at all.
The goals are good, and some of the problems they address are real, but
OPEN LOOK is not the answer as far as I'm concerned. OPEN LOOK is not a
windowing system, it is not a toolkit, it is not software at all -- it
is a *specification* for the "look and feel" of graphical user
interfaces which fully details the appearance and function of the
elements of the interface. The idea is that if different applications
running on different window platforms on different hardware all have the
same "look and feel," then users will be more comfortable and more
proficient quickly.
While this valid in principle, and OPEN LOOK does provide some good
guidelines to work from, it goes too far in specifying exactly what the
interface must look like.
Scroll bars are a good example. OPEN LOOK specifies exactly what scroll
bars are to look like almost at the bitmap level and how they are to
behave. The only user preference is what side of the scrolling area the
scroll bars normally appear. Now, there are lots of interface toolkits
out there which provide scroll bars, and although they all look and
behave somewhat differently, the basic concept is the same. I have used
many different styles and looks of scroll bars, and while I like some
better than others, I have never had any trouble figuring out how to
operate them. Switching styles has never really slowed me down.
Scroll bars are a little like door handles. There are lots of different
styles of door handles in the world but they all have some basic
similarities. They are typically a hand-sized object set about halfway
up the surface of the door which, when turned, pressed or lifted operate
the door latch. If you encounter a door handle which varies too much
from what you expect, it might slow you down a bit, but for the most
part, variations in door handle style don't pose a significant
impediment to productivity. In fact, doors with different purposes can
require different types of handles. Can you imagine if the door to your
office, your car and your shower were required by law to use the same
standard door handle?
I object most strongly, however, to how OPEN LOOK has already made all
of the aesthetic decisions. Sun hired a graphic designer and he set
forth the look of OPEN LOOK. The appearance of windows, buttons, scroll
bars, even the colors allowed are part of the specification. There is
no room for innovation, no room for creativity. It's like requiring
that everyone wear designer clothes from the same designer -- any other
style of clothes are "non-standard." Like an other artist, I want full
control of my media. OPEN LOOK takes this away.
All of this attention on minor details actually fails to address the
real issues behind user interface standardization -- that of how a
particular application maps into the controls presented to the user.
This very difficult issue is still left up to the programmer. Although
OPEN LOOK provides some guidelines as to how certain common operations
should be handled, at the level of detail at which it's concerned, it
cannot hope to address all of the possible needs that an application may
have of its user interface.
User interface design is a difficult craft often poorly done. OPEN LOOK
attempts to address standardization, but instead imposes dogmatic and
arbitrary limitations on the interface designer. What user interface
designers need is not a standard "look and feel," but rather a careful
look at the art of user interface design, perhaps a definative reference
work on the subject so that programmers can create their own user
interfaces that are clear, simple and attractive.
------------------------------
Date: 14 Sep 88 19:47:19 GMT
From: aramis.rutgers.edu!klaatu.rutgers.edu!josh@rutgers.edu (J Storrs Hall)
Subject: OPEN LOOK
>I object most strongly, however, to how OPEN LOOK has already made all
>of the aesthetic decisions. Sun hired a graphic designer and he set
>...
Personally, I think that traffic lights should be set into the
pavement like catseye reflectors, in the center of the lane. There
should be two lights, a blue one first, and then a red one. The
blue light means "stop" (blue=cold=frozen) and the red one
means "go" (red=hot=blazing speed). To warn of state changes,
the blue light would blink for 3 seconds before turning on and
the red (go) light turning off. All cars would have red and blue
taillights. The red is an acceleration light (redshift = going away)
and the blue are brakelights (blueshift = coming towards). See
how neatly the meanings mesh with the traffic lights? Surely
this is true art!
------------------------------
Date: 14 Sep 88 20:46:30 GMT
From: pterodactyl.cis.ohio-state.edu!zwicky@ohio-state.arpa (Elizabeth D. Zwicky)
Subject: OPEN LOOK
>Switching styles has never really slowed me down.
>Scroll bars are a little like door handles.
If switching styles has never slowed you down, then you've probably never
used SunView. There's this neat "feature" where it's the button you
press, and not the place you press it in that determines which direction
you scroll in. Takes me several seconds to figure out how to scroll up.
Always. X11 scrollbars have similar peculiarities that interfere a
great deal with my ability to use them.
You may just be a person who deals easily with new user interfaces, in
which case you can afford to be into flexibility. I don't, and I
can't. For people like me, who represent at least a significant
minority of the population, a basic, consistent interface is not just
pleasant, but necessary. Horrible things happen to me in SunView and
X. I find my windows magically iconifying, or I scroll off the end of
my mail in one leap and can't get back, or I somehow manage to
accidentally select a menu item while trying to click on something...
I can go back and forth between NeWS and a Mac without killing myself;
I suppose it's good I didn't start by learning SunView, or I might
be permanently crippled on a Mac, and that would be embarrassing.
For that matter, if someone had standardized door handles a little
more, I might be able to lock *both* my front door locks. The one in
the handle just won't lock for me; I know you have to either push
it in or pull it out and turn it one way or the other at the same time,
but I can't remember the right two, so I stick with the deadbolt.
------------------------------
Date: 15 Sep 88 13:25:10 GMT
From: adm!smoke!geoffs@nyu.edu (Geoffrey Sauerborn )
Subject: OPEN LOOK
>Personally, I think that traffic lights should be ...
...(BLUE <stop>, RED <GO>)...
The fact that tail lights are red and headlights are white is
not a random event. There has actually been a lot of thought put into
it.
RED is safer than BLUE for stops since it can be seen more
easily. (But White is even better than RED for that reason - but that is
why it is used for headlights).
Physics will tell you that blue (a higher energy frequency) will
travel further than red. But a fact of human engineering is that red is
more easily noticed by the eye - especially when other light (sun light)
is interfering. This is why many police vehicle use BOTH red and blue.
Red for Day, Blue for Night.
Next time you see a police flashing its lights in the extream
distance, you'll see likely notice just the red at first.
------------------------------
Date: 15 Sep 88 13:25:10 GMT
From: adm!smoke!geoffs@nyu.edu (Geoffrey Sauerborn )
Subject: OPEN LOOK
>Personally, I think that traffic lights should be ...
...(BLUE <stop>, RED <GO>)...
The fact that tail lights are red and headlights are white is
not a random event. There has actually been a lot of thought put into
it.
RED is safer than BLUE for stops since it can be seen more
easily. (But White is even better than RED for that reason - but that is
why it is used for headlights).
Physics will tell you that blue (a higher energy frequency) will
travel further than red. But a fact of human engineering is that red is
more easily noticed by the eye - especially when other light (sun light)
is interfering. This is why many police vehicle use BOTH red and blue.
Red for Day, Blue for Night.
Next time you see a police flashing its lights in the extream
distance, you'll see likely notice just the red at first.
------------------------------
Date: 15 Sep 88 14:19:23 GMT
From: att!whuts!spf@bloom-beacon.mit.edu (Steve Frysinger of Blue Feather Farm)
Subject: OPEN LOOK
> If switching styles has never slowed you down, then you've probably never
> used SunView...
I think that's just the point. While having the "right" human
interface be standard is a good idea (see a previous poster's
extreme example of traffic lights), standardizing the "wrong"
human interface is NOT a good idea. If you can convince me that
OPEN LOOK's interface is "right", fine. But (for example), a slider
with only one adjustable parameter isn't "right" in my book, nor is
the requirement that horizontal scrollbars be on the bottom of a
window. Elizabeth is right about SunView's insane scrollbars - now
imagine if they became a STANDARD!
P.S. I've only begun to look at OPEN LOOK, and it very likely has some
excellent points. The few I've cited are (probably unfairly) chosen
to point out the pitfalls of premature standardization.
------------------------------
Date: 9 September 88 15:51-PAC
From: COSTEST%IDUI1.BITNET <Bill Junk>
Subject: Test support tools
I am currently surveying test support tools which are available
for the UNIX environment. These include test data generators,
test coverage analyzers, capture & playback tools, as wells as
static analysis tools. I would appreciatiate hearing about
tools you are aware of and also am particularly interested in
experience you might have had with tools of this variety.
------------------------------
Date: 9 Sep 88 23:25:09 GMT
From: mailrus!ncar!dinl!noren@husc6.harvard.edu (Charles Noren)
Subject: Validation of Expert Shell Applications
I need a pointer to information on software validation techniques
in general and specifically the validation of software applications
written in an expert shell. I am using G2 by Gensym (which I like
very much) and need to get a handle on formal verification techniques.
------------------------------
Date: 7 Sep 88 12:25:05 GMT
From: tness7!petro!iquery!matt@bellcore.bellcore.com (Matt Reedy)
Subject: Version control across machines
> What I'm asking is, are there any
> references on how to keep version control between machines manageable?
This is really a sticky problem for us. We have a horizontal application (a
report writer/data analysis tool) that runs on PC's, Unix/Xenix, and VAX/VMS.
We've been struggling for a long time trying to manage source code control.
What we currently have isn't the best but it seems to work. Since we like
to do most of our development on PC's, each of the 5 developers has a 286 MS-
DOS machine connected via Starlan to an AT&T 3B2 server. Starlan lets us
access the 3B2 Unix file system as remote DOS drives. This provides for
transparency between Unix & DOS.
We maintain the One True Source on the 3B2 and use a Make file and shell
scripts to keep track of the date/time things were last updated on a
particular machine. Anytime any changes are made in one of the other env-
ironments, we update the One True Source to reflect this (with conditional
compilations, etc.) Then as the need arises, we use the Makefile to update
the other target systems.
------------------------------
End of Soft-Eng Digest
******************************