soft-eng@MITRE.ARPA (Alok Nigam) (10/23/88)
Soft-Eng Digest Sat, 22 Oct 88 V: Issue 38
Today's Topics:
Application generators
bar code systems for inventory and retail applications
Cynic's Guide to SE #6: Forthcoming Revolt
Development on a micro
ever hear of FULCRUM? Help...
JSP/JSD/Jackson(not the singer)
OOPs and JSP/JSD/Jackson(not the singer)
PDL Processor Wanted
PRICE SZ
Project Sizing and Estimating
----------------------------------------------------------------------
Date: 12 Oct 88 15:28:58 GMT
From: ssc-vax!shuksan!scott@beaver.cs.washington.edu (Scott Moody)
Subject: Application generators
I have just recently heard about the term 'application generators'.
I would like to know if these can also be construed as 'Supercompilers'
as described in an article by Turchin in TOPLS (July 86) on
'The Concept of a Supercompiler'. Basically a program transformer.
I could see such a tool as just a higher abstraction for a programmer
to use, in much the same way a high level programming language is
a higher abstraction to the low level machine level. Why not provide
a tool (language,set of tools) that will allow programming of an application.
In my case, we have a set of graphic prototyping tools that are very useful to
develope specific applications (something like visual programming).
Unfortunately the tools are so generic that the end result is a great
MODEL of the applications, but the execution performance isn't as good
as a taylored end product. Why not provide a application generator
or metasystem transformer, that will take the prototype and generate
a streamlined end product. This way changes can be made to the generic
high level prototype, without having to diddle in the low level
end produce. (Have we heard this before?)
Does this even come close to your concept of an application generator?
Could you post any references that are explicitly on the application
generators.
(Actually after posting this I found an article in July 1988 issue of
Computer on application generators, and am now editing the batched
news message:
Do feel that the application generators you want are actual formal
definitions of the end system? Or do you think that a running
prototype would also fit? )
------------------------------
Date: 15 Oct 88 14:21:45 GMT
From: mds@bu-cs.bu.edu (Michael Siegel)
Subject: bar code systems for inventory and retail applications
Does anyone have any information on software systems that combine
bar code recognition with inventory and retail operations. I
would be interested in software by name and/or articles in journals
or magazines describing these types of systems.
------------------------------
Date: Fri, 14 Oct 88 18:08:08 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Subject: Cynic's Guide to SE #6: Forthcoming Revolt
Please have pity on your proffessors!
They may have just been told that they have to replace
an aging mini with Alseimer's and a complete hardware labe
witha $2000 (Two Thousand dollars) budget....
It just takes a small miscalculation by the state that supports
or at least attempts to control a university system and
suddenly there is ZERO cash....
But you don't want to hear any more bitterness...
Recently I started a C programming class and as is my habit
invited each student to use there own machine if they so wished
and took responsibillity for it - while providing on a mini
running BSD as a central fallback system and communications tool...
The class split 40:40:20 into IBM PC:Macintosh:None (with one
Atari!). I'm not sure what this means but it is clear that
there are a lot of undergraduates with their own software development
system these days...say about 80% of all students...
------------------------------
Date: Fri, 14 Oct 88 23:09:02 PDT
From: Mike (I'll think of something yet) Meyer <mwm@violet.Berkeley.EDU>
Subject: Development on a micro
>> Also, it is quite easy for one person to develop a project that won't fit
>> within the memory constraints of a PC (which could be solved by a large
>> virtual address space).
True. On the other hand, it's a lot cheaper to stuff a micro with
memory than to buy a mini or mainframe and stuff it with disk.
Especially if you can't control the maximum virtual a process can get
on the development system, as those tend to default to small numbers
(2-8 meg).
>> My current project is 20k lines and 200+
>> source files and I think that without the simple facility of a core dump to
>> save the state of the program when a fatal runtime error occurs, I would be
>> still focusing on debugging instead of on future enhancements.
My current project is comparable in size - 25K in 30 or so files.
If I were restricted to post-mortems for debugging, the project
wouldn't be nearing completion. Much nicer to have the debugger halt
the program on a fatal error, and hand you the offending code in a
window.
>> Also, the
>> project is big enough that each module has its own directory. I don't
>> have much respect for PC make facilities especially since a PC has limited
>> concurrent execution powers to allow for the nested makes needed for
>> the nested directory structure.
My project is split across multiple directories. I didn't go with
nested makes, mostly because things are organized for supporting four
different different hardware/software combinations. The objects,
executables & Makefile for each are in their own directory, and the
makefile does what is correct for that particular hardware/software
combination.
I could have done makes that dropped into each directory and did a
make. After all that should only double the number of process needed
to compile each file. But that would have been a nightmare to
coordinate with needing different commands for each combination I was
working with.
After pointing out the value of using a micro networked to a
mainframe, I suppose I ought to explain why I'm working on a micro.
It's because I'm in the last phases of putting a user interaface for
that micro into the program. I'm working on a frozen version of the
machine indepent part of the project, and others are developing the
next version of that. The code I'm working on _has_ to run on the
target machine (or I have to develop a simulator for the windowing
system it's running). That leaves local development, or
cross-compiling and downloading. The choice was mine, and I prefer
local development.
------------------------------
Date: Fri, 14 Oct 88 19:30:08 PDT
From: palmer%hbvb.span@VLSI.JPL.NASA.GOV (Gary Palmer)
Subject: ever hear of FULCRUM? Help...
Hello everyone, I need some help.
This may not be the correct BB but I'm doing a massive
cross-posting...
I am looking for some (any) information on a
system/package/who-knows-what that does automated mapping. What I
have heard is that one called FULCRUM exists but I have been unable to
gather any other information. That's all I know, any other help would
be greatly appreciated... Any leads about other automated mapping
(from you cartographers out there) products would also be appreciated.
If there are any requests to do so, I will post my findings.
Please respond to me directly as I do not subscribe to these BB's
that I am posting to.
Many Thanks,
Gary Palmer
Science Applications International Corp.
(213) 781-8644
SPAN: hbva::palmer
INTERNET: palmer%hbva.span@vlsi.jpl.nasa.gov
------------------------------
Date: Fri, 14 Oct 88 18:58:57 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Subject: JSP/JSD/Jackson(not the singer)
There have been some questions about Michael Jackson, the founder of
MJSL, on this digest recently.
I was trained by the UK Civil Service and MJSL in JSP and the early
forms of JSD - this was in 1979 thru 1982. In what follows I am
expressing my own conclusions and not those of either these
organisations (who'd probably want me to shut up anyway...).
Someone asked for an address - as of 1987 the full address was
Michael Jackson Systems Limited
22 Little Portland Street
LONDON
W1N 5AF
UK
(the W1N 5AF is the Brit zipcode and identifies the address to within a "block")
In the USA (at that time) a company was licensed by MJSL to sell training,
products and susch - but I don't have the address (HELP!)
Bailey and Benson, Decision Systems Inc.
I have a list of licensees in MJSL's brochure (1987).
--------------------------------
Jonathan Mitchener<jmitchener@axion.bt.co.uk> in Vol 5 Iss34
Asked about
> a) Jackson Structured Design YES/NO
This may be difficult to answer:-)
since there is
JSP - Jackson Structured Programming
and
JSD - Jackson Systems Development
(at least from 1982 thru 1987).
A note on names - Jackson uses English VERY precisely. If I recall correctly
he once claimed that the SP in JSP was forced on him by his Scandinavian
customers...and JSD is about System Development because it decomposes
the Software Life Cycle in an unusual way, moving from a description
of the problem to the exact code for the solution without either stepwise
which brings the tasks of analysis, design and programming under
a single person's job (I think).
--------------------------------
In Vol 5 Issue 37 ( 7 Oct 88 16:54:26 GMT )
ai.etl.army.mil!mike@ames.arpa (Mike McDonnell)
Asked about
> ?Relationship of OOP and JSD?
This message may get too long for our mailer so there's more to follow...
Watch this space...
------------------------------
Date: Fri, 14 Oct 88 20:03:19 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Subject: OOPs and JSP/JSD/Jackson(not the singer)
In Vol 5 Issue 37 ( 7 Oct 88 16:54:26 GMT )
ai.etl.army.mil!mike@ames.arpa (Mike McDonnell)
Asked about
> ?Relationship of OOP and JSD?
>We here at ETL are embarking on a medium-sized software development
>project. We want to use "structured techniques", but we need help. I
>like JSP and JSD because of Jackson's "entities", which seem to be
>something like the "objects" in C++, Flavor systems, and the Common Lisp
>Object System (CLOS).
They are.
>It seems to me that what Jackson was after was a sort of object-oriented
>programming [OOP] method that he developed using the tools of his day
>(early 70's I think).
Yes - he got the basis of JSP while at Hoskins in and before the seventies,
worked with a consultancy/publishing/training company that is now defunct
published "The Principles of Programming" in 1975
and formed MJSL.
>His idea of modeling objects rather than
>procedures is attractive, but the implementation seems complicated.
Absolutely
- when done in a sequential language like COBOL, FORTRAN
PL/1, BASIC, or (yech) Assembler concurrency in any form is either
a pain(eg BASIC) or hopelessly innefficient(eg PL/1).
C seems (as always) to have almost exactly the right primitive features
('return', static storage, branchess into and out of structures)
without the right syntactic sugar to make them less rude to those
who have been programmed to avoid 'g*t*s'.
JSP and JSD appear cleaner in languages and systems that allow
concurrency/tasking/pipes/rendezvouses(sp?)/parallelism/objects/messages.
>Would it be possible to do a more simple and natural implementation of
>Jackson's ideas using a more modern programming language?
Certainly - as long as you can
(1) Backtrack out of a sequence that turns out to be a dead end
& (2) Set up a set of communicating sequential processes simply.
The ICON Language has the right stuff (generators,backtracking etc).
>Also, the
>languages available to me (C, C++, Common Lisp and CLOS) don't have
>coroutine linkages. I'm not sure how to simulate them.
I have some simple examples I use in various courses and
I can share a 20 line 'm4' macro package for C that hides all the
g*t*s and labels used in "inversion"
> I also don't
>understand what he means by "inverting a program", but it seems
>unnatural.
Yes - "inversion" does seem unnatural. The name is misleading
and seems to be from Warnier's idea of turning a tree upside down.
The key point is to not understand everything but to hand compile
the individual entries and exits to and from the 'semi-co-routine'
It is no more or less than a way of faking co-routines
in languages that don't have them. The code is ugly (all g*t*s) if
you have to read it. But so is any "structure" when it is compiled.
"Restartable subroutines"/ "Semi-co-routines"/"inversion" is
just a hand compiled very efficient structure for cooperating
sequential processes. It is not a coincidence that Hoare developed CSP
after several long sessions with Jackson, in my humble opinion.
>I need to know more before I can commit to a design method. Are my
>conclusions about the relationship between JSD and OOP justified?
Yes - there may even be a report on doing this in a recent IEEE Tutorial.
>If there is a separate discipline of program and system design that has
>evolved to the maturity of JSP and JSD and is based on modern concepts
>of OOP, what is it?
In the early 80s the following might have developed a mature method for OOPS
Warnier and Orr (who did not evolve in that direction)
a relative (Cohen I think), who was sued...
Keith Robinson and/or John Hall in the UK( who I've lost track of)
but had worked with the UK Civil Service on integrating the
Jackson Entities/Event approach with Bachman's and Codd's
techniques for determining entities.
More recently there is Grady Booch's work which focusses on the User's
Vocabulary to determine the Objects but relies on ADA
but this has not developed the same rigorous/religious flavor of JSD.
JSD via Hoare's CSP has also influenced on Pamela Zave's PAISLEY(sp?)
and some other Formal Methods...
I will admit that JSP/JSD underlies 80% of my research and 100% of my
programming...
However - JSD is probably the most mature technique for the detailed
analysis of dynamics and the design of strictured objects.
On the other hand - I have seen designs go wrong when the designers
have not done a conceptual data base design as well as JSD.
May the Source be with you...
------------------------------
Date: 12 Oct 88 16:00:19 GMT
From: martin@umn-cs.arpa (Johnny Martin)
Subject: PDL Processor Wanted
Xinotech Research of Minneapolis sells a language independent structure
editor which supports multiple views of program/documentation/pseudo-code.
It is called the "Composer", and it supports a variety of programming and
a few specification languages (Ada, Cobol, Pascal, Modula-2, MSG, etc.)
The composer is loaded with nifty editing features, automatic indentation,
summary views, customized indentation schemes, full syntax checking, and
provides some fancy conversions (like Pascal --> Ada). The composer also
runs on IBM-PC (and compatibles), Sun's, Apollo's, VAXes (VMS and Unix),
and some other machines which I can't remember.
If you're interrested, their address is,
Xinotech Research, Inc.
Technology Center, Suite 213
1313 Fifth Street SE
Minneapolis, MN 55414
(612) 379 - 3844
------------------------------
Date: 13 Oct 88 11:30:00 CST
From: "HSDP1::LONGRA" <longra%hsdp1.decnet@bafb-ddnvax.arpa>
Subject: PRICE SZ
Where can I find info on using the PRICE SZ model?
May send directly to:
LONGRA@BAFB-DDNVAX.ARPA
------------------------------
Date: Thu, 13 Oct 88 14:01:23 CDT
From: marco@ncsc.ARPA (Barbarisi)
Subject: Project Sizing and Estimating
>...interest in effort estimating and project sizing techniqes.
(comments about estimate accuracy in early phases of software development
and allusions to the difficulties of dealing with managers who
think software is something you get in the linen department...)
>Some of the methods I've read about, but not used are:
> COCOMO Barry Boehm
>A model that shows the trade-offs between
>schedule/effort/quality/complexity would really be nice.
According to Boehm, the detailed COCOMO offers estimates are
within 20 percent of actual cost 80 perecent of the time.
My personal experience has found this to be an accurate claim. COCOMO allows
the user to study trade-offs between schedule, effort, quality, complexity,
and et cetera. We use a version developed at Wang Institue, called WICOMO.
Since the Institute has been captured by Boston University, you might want
to check with BU before Wang. It runs on Unix and MS-DOS, and is written in
Pascal, should you wish to modify it.
In my experience, an *HONEST* COCOMO estimate is a good a your guess of how
many lines of code will be delivered. In every case where I've been told
that COCOMO (and other estimating tools) is useless and inaccurate, I've
found that the user whittled down the number of lines of code until the
estimate fit the available budget. This usually occurs under management
pressure. This problem is exacerabated by dishonest adjustment of parameters
for schedule, complexity, etc.; with the goal of making the estimate
fit what management wants to hear.
Also, people around here are notorious for underestimating the number of
lines of code a project requires.
The basic rule of thumb is to provide a range of estimates from optimistic
to pessimistic. Create your assumptions carefully and be prepared to justify
them to management. Break the software down into as much detail as possible
and size the software carefully (better to use what
appears to be an overestimate).
If the big-wigs aren't happy with a range of estimates,
give them the pessimistic version and don't back down!
------------------------------
End of Soft-Eng Digest
******************************