[comp.software-eng] Soft-Eng Digest V4 #17

MDAY@xx.lcs.mit.EDU ("Mark S. Day") (03/13/88)

Soft-Eng Digest             Sat, 12 Mar 88       Volume 4 : Issue  17 

Today's Topics:
             Functional Approaches to Concurrent Systems
                       HICSS-22 Call for Papers
                     Metrics on Specs, 4GL, 5GL
                     Name Space Problem (2 msgs)
                     "Efficient" Implementation
                    Requirements for a New Kernel

----------------------------------------------------------------------

Date: Sat, 27 Feb 88 15:18:16 PST
From: Eugene Miya <eugene@ames-nas.arpa>
Subject: Functional Approaches to Concurrent Systems

>I'm very interested in building concurrent/parallel systems, such as
>operating systems, in the framework of functional programming.
>
>Recent nonprocedural approaches to concurrent systems are based on
>mathematical-flavour concepts such as logic, functional, or
>message-based (Ex: Actor) programming. Of the three, it is seemed that
>logic and message-based approaches are more studied than functional in
>the field of concurrent systems.
>
>Why functional approaches have been less studied?
>
>If you know other researches or papers related to functional
>approaches, please let me know.

As a follow up to Mark Day:

There is a pretty good machine readable biography composed to Andy B. Cheese
at Nottingham.  I just converted it all to refer format.  Lauren Smith
(lls@mimsy.umd.edu) maintains the US copy, but I suspect that Andy
uses it for his personal collection.  A good number of papers are Alvey
papers which the English will not distribute out of their country (I spoke to
Andy about some of this), and I suspect that American and Japanese requests
are looked at with especially competitive perspectives.  Lauren's ultimate
employer might also have something to say about giving you a copy.

If you want a copy, let me know, it's 368KB with the largest of 24
being 35 KB.  If I get burned for sending it to you, I will let the net know
(assuming they don't take my accounts away).  U.S. requests should be sent
to Lauren and European requests to Andy.

There's numerous applicative language and other approaches.  It's not
like this is a vacuous area of research.  I have several problems
with bibliographic sevices which I won't elaborate one: like great
for librarians, not as great for researchers.

--eugene miya
  NASA Ames

------------------------------

Date: 4 Mar 88 14:59:05 EST
From: Thomas Corbi <GROKLIB@ibm.com>
Subject: HICSS-22 Call for Papers

                     CALL FOR PAPERS AND REFEREES

      HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES - 22

                "SOFTWARE DESIGN TOOLS AND TECHNIQUES"
              Kailua-Kona, Hawaii  --  January 3-6, 1989

The Software Track of HICSS-22 will contain a special set of papers
focusing on a broad selection of topics in the area of SOFTWARE DESIGN
TOOLS and TECHNIQUES.  The presentations will provide a forum to discuss
new advances in theory and applications of software design.

The need for systematic software design has received increasingly
widespread acceptance.  Researchers have been actively working on
various design tools and techniques to improve the software development
process.  These design tools allow for design to be expressed in a
a variety of useful notations including requirement-oriented
representations, mathematical representations, and programming language
oriented representations.  This session will explore development of
new design tools, methods and notations as well as improvement of
existing tools and environments to help promote high levels of software
quality.  Submissions are solicited in various topics of software
design tools, techniques, and environments, including:

      * incremental definition and analysis of programs (syntax directed
          editors)
      * distributed software design
      * architectural design
      * requirement specifications and analysis
      * traceability throughout the system lifecycle
      * reuseability in design and implementation
      * performance engineering analysis
      * program and data structure display
      * software architecture

Papers are invited that may be theoretical, conceptual, tutorial, or
descriptive in nature.  Those papers selected for presentation will
appear in the Conference Proceedings which is published by the Computer
Society of the IEEE.  HICSS-22 is sponsored by the University of Hawaii
in cooperation with the ACM, the Computer Society, and the Pacific
Research Institute for Information Systems and Management (PRIISM).

INSTRUCTIONS FOR SUBMITTING PAPERS

Manuscripts should be be 22-26 typewritten, double-spaced pages in
length.  Do not send submissions that are significantly shorter or
longer than this.  Papers must not have been previously presented or
published, nor currently submitted for journal publication.  Each
manuscript will be put through a rigorous refereeing process.
Manuscripts should have a title page that includes the title of the
paper, full name of its author(s), affiliation(s), complete physical
and electronic address(es), telephone number(s), and a 300-word abstract
of the paper.

DEADLINES

      * A 300-word abstract is due by March 30, 1988
      * Feedback to author concerning abstract by April 15, 1988
      * Six copies of the manuscript are due by June 6, 1988
      * Notification of accepted papers by September 1, 1988
      * Accepted manuscripts, camera-ready, are due by October 3, 1988

SEND SUBMISSIONS AND QUESTIONS TO:

  Prof. Narayan C. Debnath
  HICSS-22 Software Design Tools and Techniques Session Coordinator
  Department of Computer Science
  University of Wisconsin-River Falls
  River Falls, WI  54022
  715-425-3769

------------------------------

Date: Fri, 04 Mar 88 10:37 CET
From: "Ludwig Hausen +49-2241-14-2426"            <HAUSEN%DBNGMD21.BITNET@MITVMA.MIT.EDU>
Subject: Metrics on Specs, 4GL, 5GL

We are working on the foundation of the assessment of software and
trying to develop a generic software quality and productivity
model. Current state of the art shows that there are a huge number
of measures and metrics available, most of them are
applicable only to the assessment
of programs, i.e. programs which are written in procedural
languages (Fortran, Ada, C, etc.). On the other hand there is also
a need to assess results produced in the earlier stages of the
development.  Unfortunately one can't find so many measures or
metrics appropriate for the assessment of requirements, functional
specifications or even DB applications (4GL, DML, DDL, etc.).

Therefore, we would greatly appreciate to receive any comment or
text on the definition or application of measures
and/or metrics on
 O software documentation written in natural language(s),
 O design specifications,
 O requirement specifications,
 O 4GLs, data definition languages, data manipulation languages
   or other linguistic means used in DB design and application,
 O software written in
   object-oriented languages (Smalltalk and the like),
 O software written in
   AI languages (Lisp, Prolog, OPS5, XPS-Languages),
 O test coverage for requirement specs, design specs or
   other non-procedural languages.
 O software written in
   other non-procedural language.

From practitioners I would like especially to learn
 O what aspects of quality are of interest,
 O what aspects of productivity are of interest,
 O which objects should be measured.

A drafted report on the quality model, called YAMOSQUAP
(Yet Another Modelling Of Software Quality And Productivity)
is available. An abstract is to be found below.

                               H A N S - L U D W I G  H A U S E N

GMD Schloss Birlinghoven       Telefax   +49-2241-14-2889
D-5205 Sankt Augustin 1        Teletex   2627-224135=GMD VV
       West  GERMANY           Telex     8 89 469 gmd d
                               E-mail    hausen@dbngmd21.BITNET
                               Telephone +49-2241-14-2440 or 2426
P.S.:GMD (Gesellschaft fuer Mathematik und Datenverarbeitung)
     German National Research Institute of Computer Science
     German Federal Ministry of Research and Technology (BMFT)

....................................................................
YET ANOTHER MODELLING OF SOFTWARE QUALITY AND PRODUCTIVITY
        Hans-Ludwig Hausen,
        GMD, Schloss Birlinghoven, D-5205 St.Augustin 1, FRG
Abstract
  Software engineering comprises construction, validation,
measurement and assessment of software products and software
projects.  Software systems are often subdivided into the levels
application concept, data processing concept and implementation.
Evaluation, measurement and assessment have to take these three
levels into consideration.  Quality models have to consider active
and passive elements of the software as well as dynamic
characteristics on all three levels.  Since software systems and
software projects are unique quality models have to be flexible. The
proposed scheme for quality modelling uses weight functions to
define quality factors in terms of evaluation factors. The scheme
may also be extented to cover productivity.
  A selected set of quality and evaluation factors is used to
demonstrate the quality modelling procedure. With respect to three
levels of software description a number of ratios are defined in
order to describe software quantitatively.  Using functions which
reflect past experience, it becomes possible to generate estimates
over the product extent and the production effort.
  Both the modelling scheme and the assessment scheme are effectively
implementable.  An abstract program defines the computation of the
quality and productivity on a common scheme.

------------------------------

Date: 23 Feb 88 03:22:42 GMT
From: maynard!campbell@think.com  (Larry Campbell)
Subject: Name Space Problem

From article <3490002@otter.hple.hp.com>, by kers@otter.hple.hp.com (Christopher Dollin):
> I'd go for "one-datatype-per-file". Spliting the files up using directories is
> just a hack for controlling a growing namespace; NO existing language that I
> know of has a decent solution for this (and if *you* know of one that does,
> **please** let me know!).

How about packages, as found (at least) in Common LISP and Ada?
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com          120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell         +1 617 367 6846

------------------------------

Date: 23 Feb 88 16:55:28 GMT
From: otter!kers@hplabs.hp.com  (Christopher Dollin)
Subject: Name Space Problem

> How about packages, as found (at least) in Common LISP and Ada?

Well, those were the ones I was thinking of when I said that no existing
language solved the problem! [BTW - I don't think you can compare the Ada and
Lisp notions of packages, except as you can compare thumbscrews and drowning.]

I don't think Ada even attempts to solve the problem. Correct me if I'm wrong,
but isn't there a single flat namespace for modules? So how do I plug together
different subsystems built independantly?

The Common Lisp system has all sorts of problems. It packages symbols (words;
names), not variables. The package namespace is flat. It has no notion of
access control (you can grab the innards of any package without a declared
intention to do do). It does not support transitive export of things. (If it
did, you can bet that it wouldn't support *non*-transitive export). You can't
rename across a import/export boundary to avoid name clashes. Etc.

It's just like filing systems. They give you this way of separating files one
from another, and Lo! make it hard to join them together again. That's why
Unix has hard links. And symbolic links. And a tree structured hierarchy,
or a DAG if you're super-user. And PATH. And CDPATH. And (csh) ~. And .........

PS No, Pop doesn't get it right either.

Regards,
Kers                                    | "Why Lisp if you can talk Poperly?"

------------------------------

Date: 2 Mar 88 12:23:23 GMT
From: mcvax!enea!sommar@uunet.uu.net  (Erland Sommarskog)
Subject: "Efficient" Implementation

>How many novice Pascal programmers use many global vars because it saves
>memory?  On a paging system, though, you may need more pages in real memory
>because of the way the chaining of variables is done in Pascal.

This reminds me of when I did my exam work. My task was to do a
capacity analysis of the file system of a 68000-based machine. Since
this file system was quite buggy I had to check the sources to see
what happened. The langauge used was EriPascal, a Pascal extention
with Modula-2 module concept and real-time primitives.
  Nevin would have loved them. They used a lot of global variables. 
A typical procedure could have some local variables, but mostly they
used the used the global ones, even for typical local purposes. To
make it even more fun, all variables had one-letter prefixes like
cnumber, cix etc. And on top of all, the modules were *huge*. 6000
lines or so.
  Now, was this a fast and speedy file system? Laugh. Reading a 
record from a 100 record-index file with variable-length fields 
could take 3 seconds. With a Winchester. No, no time-sharing. At 
disk-manager level, reading a specified block in a file was randomly 
distributed between 100 and 300 ms. 
  Talk about poor algorithms. You should have seen the code for
finding a particular block. In practice they counted on their
fingers, making complicated a MOD for every decrement. Not takling
of the procedure that allocated disk blocks. 27 Gotos into 150
lines of code. Yes, there was a bug in it.

So moral: You may save some execution time by having your variables
global, but you since you are obscuring your code so fatally,
you will lose the notion of what you are doing and introduce
bugs and inefficiencies instead.

Oh, it should be added that the file system I talked of has since then
been improved. I have no idea of how it works today.

Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP

------------------------------

Date: 26 Feb 88 21:10:24 GMT
From: trwrb!aero!venera.isi.edu!raveling@ucbvax.Berkeley.EDU  (Paul Raveling)
Subject: Requirements for a New Kernel

>Isn't the real power of UNIX in that it
>is an environment that encourages tool building?

	No.  It REQUIRES tool building because the operating system
	itself doesn't offer good solutions to large sets of problems.

>The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!".

	Many of the problems with Unix can't be solved without
	a different kernel.  I favor a substantially different
	kernel with a Unix compatibility layer over it to accommodate
	existing applications.  I'd write new applications for
	the new kernel's native facilities.


	To pick a few examples:

	We need asynchronous i/o.  What we did in EPOS was to issue
	a request as a signal (NOT like a Unix signal) to a device
	driver process; the device driver then issued an answering
	signal at completion.  These signals included event
	data and were queued if the destination process wasn't
	ready for them.  Lurking behind this terse description
	are about half a dozen things the Unix kernel can't do.

	We need GOOD interprocess communication.  The only
	Unix mechanisms that are standard enough to have some
	hope to contribute are pipes and signals.  There's
	nothing which efficiently communicates a small set
	of paramaters, such as those in typical C function calls,
	between processes.  Unix signals don't queue event data,
	and pipes are slow -- our benchmarks show that either
	the setup overhead for pipe i/o or context switching
	is easily an order of magnitude slower than it should be.

	We need to share memory among processes in a multi-process
	application.  There's no way to do this and keep
	application software portable between Unixes with different
	extensions.

	We need a single i/o interface with mutually consistent functions.
	We really don't want to have to check stream status, call
	Xpending, etc. before knowing it's safe to call select.
	In fact, it can never be totally safe to use select with
	streams or X connections without a polling time interval;
	if a context switch and input completion intervene between
	the stream/X connection check and the select, the select
	can leave the calling process blocked.

	We need to spawn processes without creating another copy
	of the entire address space (as in fork) and without having
	to fetch the new process from a disk file (as in vfork).
	The first part is especially important, since much of our
	project's software is Lisp running in a 40-megabyte address
	space, and we don't have enough swap space for another
	copy of it.

	I haven't even mentioned the question of user interfaces,
	but the problems there are equally dismal.


	Give Me Liberty or Give Me Unix!

Paul Raveling
Raveling@vaxa.isi.edu

------------------------------

End of Soft-Eng Digest
******************************
-------