MDAY@xx.lcs.mit.EDU ("Mark S. Day") (03/13/88)
Soft-Eng Digest Sat, 12 Mar 88 Volume 4 : Issue 18
Today's Topics:
Request for Info on New make Packages from Toolchest
Research on Mathematics for Specs. and Definitions?
Reuse of Design
Summary of How to Elicit User Requirements
UNIX: Clarifying Terms
Writing Upgradable Data Structures (2 msgs)
----------------------------------------------------------------------
Date: 4 Mar 88 01:38:19 GMT
From: vsi!friedl@uunet.uu.net (Stephen J. Friedl)
Subject: Request for Info on New make Packages from Toolchest
The AT&T Toolchest has two programs that replace make. They
are:
"mk - A succcessor to make"
and
"nmake - New make program"
Has anybody had any experience with either or both of these?
How about other next-generation make programs? Our systems are
getting larger and makefile administration is rapidly becoming a
drag. Please email, and I'll summarize and post if I hear any-
thing interesting.
Steve
Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA *Hi Mom*
CSNet: friedl%vsi.uucp@kent.edu ARPA: friedl%vsi.uucp@uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl
------------------------------
Date: 2 Mar 88 03:11:03 GMT
From: edwards@cod.nosc.mil (Sheridan H. Edwards)
Subject: Research on Mathematics for Specs. and Definitions?
I am currently interested in what research is currently
being conducted in the areas of:
-using mathematical knowledge in formal software
development
-specifications using formal mathematics
What I have in mind is along the ideas presented by I.J.
Hayes at the first Australian Software Engineering Conference
(Canberra, 1986) or concepts like those in "Using Mathematical
Knowledge in Formal Software Development" by L. A. Wallen (who
is in the AI department at University of Edinburgh).
Specifically, I am trying to come up with a formal and
hopefully somewhat rigorous method of describing Command and
Control systems. I am not interested in stuff like PDLs (yet,
anyway), but a higher level description (suitable for A-specs and
PPSs). E-mail me any/all information. If there is enough
response I will summarize and post.
-Thanks much
-Dan Edwards
edwards@nosc.mil
------------------------------
Date: Thu, 25 Feb 88 14:22:59 -0800
From: Ira Baxter <baxter@madeleine.UCI.EDU>
Subject: Reuse of Design
Neil at U Lancaster was interested in information about reuse of
design plans. Most of the relevant work I know of uses formal
transformations as a basis for capturing the actual design, and
attempts to replay the derivation steps in various fashions. Jack
Mostow notes that we should be designing derivations rather than
programs. David Wile at ISI proposed a system called PADDLE which
replays design plans. I am trying to use captured design plans to
guide installation of changes to implemented programs.
There is a considerable amount of interest in the VLSI design world in
reuse of design plans. I believe this work to be generally applicable
to software design, but (collective) you may have other opinions.
Two interesting examples of work include the REDESIGN project at Rutgers
under Louis Steinberg, and the ARGO tool at MCC (Huhns and Acosta), in
which previously constructed design plans are applied to new specifications
in order to achieve new implementations.
A starter bibliography can be found in my paper "Reusing Design Histories
via Transformational Systems" in the Oct 87 Proceedings of the Workshop
on Software Reuse, Rocky Mountain Institute of Software Engineering,
Boulder Colorado.
IDB
(714) 856-6693 ICS Dept/ UC Irvine, Irvine CA 92717
------------------------------
Date: 25 Feb 88 14:27:02 GMT
From: uflorida!beach.cis.ufl.edu!hbh@gatech.edu (Hillard Holbrook)
Subject: Summary of How to Elicit User Requirements
A while back, I sent out a request for suggestions on eliciting user
requirements. And while the response wasn't overwhelming, many thanks to those
who did send me their ideas.
Interestingly enough, prototyping seems to be the order of the day.
Several people stressed the importance of giving the user something to play
with. As it turns out, prototypes serve as an excellent means of communication
with users which is a critical factor in the whole requirements thing. Another
feature in using prototypes is the learning process that takes place in their
creation and evaluation.
Another response was to examine the knolwedge engineering techniques
associated with artificial intelligence and expert systems.
Some very valuable feedback I received was from the folks at
the University of California at Irvine. In their Advanced Software
Engineering Project, Julio Leite is working in the area of requirements
elicitation, more specifically investigating using production systems to aid
to requirements analysis. Anyway, as part of his work, he has written a very
comprehensive survey of requirements analysis (ASEP Report# RTP-071). They
gladly sent me a copy of the report and I would strongly recommend it to
anyone doing work in the requirements analysis area.
Adios all - Hilliard Holbrook (hbh@beach.cis.ufl.edu)
(904-377-5410)
------------------------------
Date: 25 Feb 88 14:25:54 GMT
From: uh2@psuvm.bitnet (Lee Sailer)
Subject: UNIX: Clarifying Terms
Let's distinguish
UNIX, the Operating System --- kernel, file system, i/o, etc.
UNIX, the environment --- the shell, grep, awk, pipes, sccs, rcs, make, etc.
UNIX, the applications available --- editors, design tools, compilers, etc.
There might not be a clean distinction here between the kernel, the
environment, and the applications, but it is clear that there is a qualitative
difference between things like record locking, the quality of the error
recovery in the compiler, and the command language in the editor.
So, when
in article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) says:
>
>Lets see more discussion on things to be IMPROVED.
> - Better syntax directed editing (>emacs has now)
> - Improved syntactic and semantic compiler recovery
> - Use of object oriented languages (C++ !)
> - object oriented data bases for those object oriented languages.
> - More powerful compiler compilers
> - Better debugging
> - Automation of regression testing
> - Conversion of specification into code.
>
I see a list of things that mostly do not have anything to do with UNIX
the operating system or environment per se, but look mostly like
discussions of what commercial software is available for UNIX. For
that matter, it is probably a comment on what is available on one or
two particular machines.
------------------------------
Date: 21 Feb 88 15:45:44 GMT
From: mnetor!utzoo!yunexus!geac!daveb@uunet.uu.net (David Collier-Brown)
Subject: Writing Upgradable Data Structures
In article <2079@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>Sooner than you can say "UNIX is a Trademark of ...", 47000 AD will be
>here. The greatest mistake a designer can make is to assume that a
>certain date and time will never come. Such short-sightedness has
>caused problems over and over again, yet we see it again and again.
>
>The right way to do it is as follows:
[ example of linked list elided]
The idea of a infinitely-extendable date is one solution, and is
particularly applicable to things like dates, which should be
monotonically increasing. (But a library system would *freak* at
the late starting date).
A more general solution predates Unix, and has therefore been
forgotten by many members of the Unix community: version-numbered
structures.
Let us consider a date structure as follows:
struct date_t {
int v;
unsigned d;
} foo = { 0, 32766};
This describes a range of dates and times, encoded into a single
unsigned value (which should be insufficient for anything but the
execution of a single filter). Let us assume that this is the date
format of our machine.
As soon as 47000 AD comes around (or whatever date breaks the
date/time system), the library containing the date routines is
replaced [note 1] with one which checks the version number, "v". If
it is non-zero, the structure is trashed [note 2] and replaced by
one with the following form:
struct date_t {
int v;
unsigned long d;
} foo = { 1, 32766};
The new code changes the structure to type "1", and then
continues. This can happen over and over again, and allow the data
structure to grow or shrink, as necessary.
The disadvantages are as follows:
1) You have to make version-number checks in your library
routines, and fault to updating code if they fail
2) You can't have "structure constants", because they would
be the wrong size (you have to stick with c initializers)
3) You can't take sizeof(struct time_t) unless you build the
version stuff into the compiler (vstruct time_t, for
example). The size changes on you, so you have to keep a
dope-vector.
4) You CAN'T use a severely type-checked language like
Pascal because it knows that you don't want variable
sized structures. (It's hard in Ada[note 3] too. Source:
Paul Stachour).
This technique is used in the ARPAnet and on Multics. Ritchie and
Thompson didn't include it in Unix and C, probably for the good
reason that it approached overkill. (:-))
Some days, though, you have to kill something repeatedly. Dates
are a good example.
--dave c-b
[note 1] Dynamic linking is needed: I assume we'll have it by then:
I had it in the late '70s.
[note 2] Probably by being realloc'd. Malloc usually has a
dope-vector available for this.
[note 3] Ada is a trademark of the Gods of War (Ada Joint Program
Office).
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers International Inc.,
350 Steelcase Road,Markham, Ontario,
CANADA, L3R 1B3 (416) 475-0525 x3279
------------------------------
Date: 26 Feb 88 10:13:00 GMT
From: mcvax!enea!sommar@uunet.uu.net (Erland Sommarskog)
Subject: Writing Upgradable Data Structures
David Collier-Brown (daveb@geac.UUCP) presents a data structure for date
handling which gets lager and larger as time goes by and then continues
with some disadvantages with the method:
> 4) You CAN'T use a severely type-checked language like
> Pascal because it knows that you don't want variable
> sized structures. (Its hard in Ada[note 3] too. Source:
> Paul Stachour).
Doesn't seem very diffcult doing it in Ada. What about:
Type Date_type is array(integer range <>) of integer;
Type Date_pointer is access Date_type;
To begin with you allocate a date with:
Date_p := new Date_type'(1);
When time is come you get a new date with:
Date_p := new Date_type'(2);
and so on. I have not included a version field here, since I think we
can trust the attribute 'SIZE of Date_p.all.
Note however that this method, as well in C as in Ada, will eventually
break down. Sooner or later theree will not be memory to store the dates.
And if we assume an infinite memory, there is still a limitation of the
number of elements in the array, at least in Ada. Could this be circum-
vented in C?
--
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.UUCP
------------------------------
End of Soft-Eng Digest
******************************
-------