soft-eng@MITRE.ARPA (05/31/88)
Soft-Eng Digest Mon, 30 Apr 88 V: Issue 6
Today's Topics:
Anybody know about SADT? (2 msgs)
More on gotos
More SCCS usage/Has anybody heard of "SABLE"?
Requirements for SFs and SEEs
State Machines, The Ultimate Go
State Machines, The Ultimate Goto
----------------------------------------------------------------------
Date: 15 May 88 01:49:21 GMT
From: att!alberta!oha!access!edm!ahe3b1!root@bloom-beacon.MIT.EDU (Root)
Subject: Anybody know about SADT?
>From article <660@vsi.UUCP>, by friedl@vsi.UUCP (Stephen J. Friedl):
> SADT: Structured Analysis and Design Technique by David A.
> Marca and Clement L. McGowan ("with a forward by Douglas T.
> Ross").
>
> (A) How is SADT?
> (B) How is this particular book?
> (C) If one wanted to be exposed to a couple of ways
> of doing SA, what is a good second choice?
>
>From my reading of the book, SADT is an extremely powerful system
modeling technique with potential way beyond software engineering.
In fact, it appears to have gotten more use in organizational analysis
and design than anywhere else (E.G. job design and control).
The basic conceptual unit (the SA box) :
|
| CONTROL
V
-----------------
| |
INPUT ------> | (subject) | ---> OUTPUT
| |
-----------------
^
| MECHANISM
can be combined and/or successively decomposed to model virtually
any task. The running example in the book is an analysis of a
Tool Shop. Example subjects: Pick Tools, Setup Machining Place,
Evaluate Job Progress. Example control flows: Blueprints, Job
Completion requests, Job order steps. Example Outputs/Inputs:
Unfinished Parts, Tool Crib, etc.
The book is an extremely detailed 'step-by-step' cookbook which
includes a great deal of information about how to manage
and organize the products (including standards,etc.)
of an SADT analysis (Each set of SA box diagrams is called a KIT, the
construction of a KIT is called an AUTHOR/READER cycle). The latter
half of the book gives example KITS from 4 application areas.
The technique is of course copyrighted and sold by a Mass. company
called SofTech.
The most frustrating aspect of the book to me was the enigmatic
claim in the preface by the technique's inventor:
'There are two main styles of SA modeling: activity models stress
the happenings of the system; data models stress the things of
a system. Both use the same box-and-arrow graphic language, in dual
ways (the roles of boxes and arrows interchange)'.
That unfortunately was the last reference to data modeling; the rest
of the book concentrates exclusively on activity modelling.
I have absolutely no doubt that a properly executed SADT would serve
as a superb basis for a software construction project.
It would take a long time and it would highlight the context within which
the system would be expected to operate, but it might raise very sticky
questions about the functioning of the organizational unit being modeled.
(i.e. make sure that a corporate sponser is prepared to question the
operation of the WHOLE unit, not just the 'computerized' part of it).
As the authors present the method, I have doubts about its utility/cost
ratio. But as a structured technique for requirements analysis or
'getting a feel for the problem' it makes a useful addition to the
armamentorium of the individual system analyst/designer.
------------------------------
Date: 16 May 88 14:30:43 GMT
From: rochester!kodak!mcgrath@cu-arpa.cs.cornell.edu (bill mcgrath)
Subject: Anybody know about SADT?
SADT is a methodology with rules and procedures to analyze and present
high level, abstract definition of enterprises which are supported by
systems. It is used by DOD in its Integrated Computer Aided Manufacturing
(ICAM) process to represent system development capabilities of vendors
and configuration control and management abilities. Yourdon is a systems
development methodology with diferent and more rigororous rules with the
goal of building a system. The goal of SADT is to gain an understanding
of an enterprise and document it. It will break down in doing detail design.
All of this is arguable. Most system design methods are extensions of Yourdon
not SADT. Yourdon rules and procedures constrain thinking around high level
definition of an enterprise. Read 'Diagramming Techniques for Analysts and
Programmers' by Martin and McClure, Prentice-Hall. There are others.
To soft-eng
From: bates%falcon.dnet@fermat.mayo.edu (Cary Bates)
To: soft-eng
Subject: Return status structures
To take advantage of what little type checking is done by our C
compiler, some of our programmers have started writing their functions
so that they return structures rather than integer constants. This
makes it impossible to check for a status that is not returned by the
function without getting a compile time error. For example, the
completion status for the function 'foo' can have three possible
values (SUCCESS,WRONG_VALUE,& BAD_PARAMETER). These are the only three
values that are valid to check for. Using a structure for the
completion status, the function is as follows:
| #include stdio
|
| typedef struct
| {
| unsigned success : 1;
| unsigned wrong_value : 1;
| unsigned bad_parameter : 1;
| } foo_status;
| #define INIT_FOO_STATUS {FALSE,FALSE,FALSE}
|
| /*****************************************************************************\
| * *
| * This is a very simple function that accepts one parameter 'i' by reference. *
| * The function completes SUCCESSfully if a value of 1 is passed in for 'i'. *
| * The function returns WRONG_VALUE if a other than 1 is passed in for 'i'. *
| * The function returns BAD_PARAMETER if no address was passed in for 'i'. *
| * *
| \*****************************************************************************/
| foo_status foo( int *i )
| {
| foo_status return_status = INIT_FOO_STATUS;
| if ( i == 0 )
| {
| return_status.bad_parameter = TRUE;
| return( return_status );
| }
|
| if ( *i != 1 )
| {
| return_status.wrong_value = TRUE;
| return( return_status );
| }
|
| return_status.success = TRUE;
| return( return_status );
| }
|
|
| main()
| {
| foo_status status;
| int i;
|
| i = 2;
| status = foo( &i );
|
| if ( !status.success )
| {
| if ( status.wrong_value )
| printf("Wrong value\n");
| if ( status.bad_parameter )
| printf("Bad parameter\n");
| }
|
| status = foo( 0 );
|
| if ( !status.success )
| {
| if ( status.wrong_value )
| printf("Wrong value\n");
| if ( status.bad_parameter )
| printf("Bad parameter\n");
| }
| }
Such a method may cause more work to delcare and check status
variables. Assuming that coding is only 20% of the development cycle
(40% design and another 40% testing/debug), will such a concept reduce
debugging time enough to make up for the extra coding time? Is this
easy enough to understand so that maintenance is not made more
difficult? Does this violate any C rules or hurt efficiency?
------------------------------
Date: Fri, 20 May 88 16:08:12 cdt
From: bates%falcon.dnet@fermat.mayo.edu (Cary Bates)
Subject: More on gotos
This letter was inspired by Soft-Eng Digest
of Thu, 19 apr 88 V: Issue 3. On goto's and FSM's
( I personally like to implement finite state machines
using a two-dimensional search table. For what it's worth.)
Given my experience, it would be an understatement to say
that goto-less programming is an OVER reaction to a
GENUINE problem.
|
| do {
| ... some code here ...
| if ( *some condition* ) break;
| ... some code here ...
| if ( *some condition* ) break;
| ... some code here ...
| } while( FALSE );
|
| ... some more code here ...
|
I have really seen a programmer write a loop in this way to
avoid using a goto. This loop will never loop. It is just used
as a place holder for a location to jump to. (Using the break
statements as gotos.) This is still goto type logic, this
programmer just avoided using a goto statement and further
perverted the code.
The difference as I see it between using goto's and
structured coding is that the structured code emphasizes the
structure of the code, and gotos make the structure more
distant and obscure. This implies to me that gotos could be used
in a way that would hide structures that are very much so not
central to the algorithm that the program performs. This could
make the program easier to understand. Here is an example of
want I mean:
Some time ago, we decided to add the option to our system
of allowing the user to enter the letter B or the word BACKUP to
make the program go back to the previous prompt. We also
decided that it would be handy for the user to enter E or EXIT
to exit the program at any prompt. Some of our programmers who
went to the "no gotos make good program" school of thought,
tried to implement this using a case statement which held all
the program's prompts and some operations:
| do {
| switch (sw)
| {
| case 1:
| st = get_design_dir(design_dir);
| break;
| case 2:
| st = get_node(design, "Enter design name", design_dir, FALSE);
| break;
| case 3:
| st = get_design_dir(that_lib,
| "Enter Library");
| if(st == SUCCESS)
| {
| /*
| determine if the value input at the last prompt is actually
| a library.
| */
| st = cad_get_dir_type(that_lib, &type);
| if(type != NODE_LIB)
| {
| get_error(MCMS_WRONGDIR, NULL, PRINT, "mcms_create_ref",
| NULL, that_lib,
| "a Library");
| /*
| the following 2 lines allow reprompting for the
| tech spec sys lib.
| */
| --sw;
| st = SUCCESS;
| }
| }
| break;
| case 4:
| st = get_node(fp_node,
| "Enter floorplan node name", that_lib, FALSE);
| break;
| }
| /*
| handle the various status values returned by the functions.
| */
| if(st == SUCCESS) { ++sw; }
| else if(st == BACKUP) { --sw; }
| else if(st == EXIT) { break; }
| else { break; }
| }
| while (sw>=1 && sw<=4);
|
This structure seems to add meaningless complexity to the code.
Also, because it is structured code, it draws the programmer's
attention and thus could distract him from the main function of
the code, making the code seem more complex. This section of
code could well have been written as follows:
| prompt_1:
| st = get_design_dir(design_dir);
| if ( st != SUCCESS || st == EXIT || st == BACKUP ) return( st );
| prompt_2:
| st = get_node(design, "Enter design name", design_dir, FALSE);
| if ( st == EXIT ) return( st );
| if ( st == BACKUP ) goto prompt_1;
| if ( st != SUCCESS ) return( st );
| prompt_3:
| st = get_design_dir(that_lib, "Enter Library");
| if ( st == EXIT ) return( st );
| if ( st == BACKUP ) goto prompt_2;
| if ( st != SUCCESS ) return( st );
| /*
| determine if the value input at the last prompt is actually
| a library.
| */
| st = cad_get_dir_type(that_lib, &type);
| if(type != NODE_LIB)
| {
| get_error(MCMS_WRONGDIR, NULL, PRINT, "mcms_create_ref",
| NULL, that_lib,
| "a Library");
| /*
| the following line allows reprompting for the
| tech spec sys lib.
| */
| goto prompt_2;
| }
| st = get_node(fp_node,
| "Enter floorplan node name", that_lib, FALSE);
| if ( st == EXIT ) return( st );
| if ( st == BACKUP ) goto prompt_2;
| if ( st != SUCCESS ) return( st );
|
This code seems to preserve the sequential nature of
the operation that is being preformed without
drawing undo attention to the structure of the exceptional
condition of the user entering backup or exit. (I would
say that the goto's may even model the condition of the user
entering backup or exit better than the case statement.)
If a goto statement can make the functionallity of a program
clearer, then maybe a goto statement is what should be used. I
am not advocating massive goto usage by any means, but I believe
that they do have their place.
------------------------------
Date: 12 May 88 01:34:22 GMT
From: mcvax!ace!konijn@uunet.uu.net (Erik van Konijnenburg)
Subject: More SCCS usage/Has anybody heard of "SABLE"?
In the recent summary of SCCS experiences, the following note
touches on one of the most important parts of version control:
keeping multiple files consistent.
> Charles Lambert <cl@datlog.co.uk>:
>
> ... Keep a System Description File that
> lists all the version-numbered sources needed for a correct build. This
> is simply a text document that has to be kept up to date. Since nobody
> remembers to keep documents up to date, it is wise to have your shell
> scripts do it automatically: every time someone deltas a file, the new
> version number gets written into the SDF.
And in article <647@vsi.UUCP>:
> Stephen J. Friedl <friedl@vsi.UUCP>:
>
> [ Question about Sable ]
>
> Related to this, I have found that naked SCCS is really not
> suitable for doing even small projects and would like to find
> something more. I have tried to build tools on top of SCCS and
> am getting closer, but "The Right Way" has eluded me. Who knows
> of good configuration management software based on SCCS? Even
> ideas would be helpful.
>
Using System Description Files is definitely the right direction for
version control. If these files have a fixed format, they can become
the basis of tools for practically all your source control.
-- It is possible to create source distributions automatically.
-- It is possible to produce a diff listing between two versions,
not of a single file, but of a complete product, complete
with the SCCS comments for all these changes.
-- Since the version of the snapshot file is a complete
identification of the product, it is sufficient to put the
version of the snapshot file in a product. This means you
no longer have to wade through pages of version strings to
get the one you are interested in.
-- By using SCCS simply as a "backend", much more flexibility is
available. For instance recursion: one single version number
identifies a complete distribution by giving the version
numbers of component parts, which give the version numbers of
component parts, and so on.
-- The version identification of a System Description File is
a great shorthand in communication between developers and
distributors: ``Version 6.25 of the C compiler does loop
invariant code moving, and could you do a trial UNIX
distribution and validation with it?''
Generating the distribution is then a matter of passing that
single version number to an extraction tool.
We built a system based on System Description Files, and find it
indispensable in keeping order in our distribution (several hundred
megabytes of kernels, uitilities, compilers, etc.).
There is a short paper on these version control tools and how they fit
in with validation, distribution generation, and software problem
report management. If you're interested in a copy, send mail to
------------------------------
Date: 11 May 88 11:19:33 GMT
From: dewal@exunido..uucp (Sanjay Dewal)
Subject: Requirements for SFs and SEEs
We are trying to define requirements for Software Factories. In ESF, which is
an EUREKA project,we made an attempt to define the requirements not dependent
on ceratain application domains. During further work we realized that it is
necessary to take the application domain into account in order to get the re-
quirements more clear.
Does anyone know any specific approach strategies which are used to get or de-
fine requirements catalogues for Software Factories or at least SEEs ?
During a literature research I could find only several types of empirical re-
search as an approach. This research depends on asking experts or examining
existing tools.
Both approaches have basic cons that they are not applicable for us and they
postpone the problem, as with these methods the analyst has to define questions
lists to guide the interview or examination.
Besides I found only a few references to this subject.
I wonder why usual methods used for requirements engineering for systems are
not used for the requirements engineering of SF's or SEE's.
Have you got any ideas or references?
------------------------------
Date: 7 May 88 21:49:00 GMT
From: urbsdc!aglew@uxc.cso.uiuc.edu
Subject: State Machines, The Ultimate Go
>>Goto logic says leave and don't come back.
>
>Not true. For example:
>
> FOO: goto FOO;
>
>Goto logic says you can come here anytime you need to and from anywhere you
>want to (within limits, of course).
So, maybe we need a "come from" statement at each label?
eg.
state1(come-from state2, state3):
goto state4;
{-: smileys, because I read the "come from" spoof - but half seriously :-}
------------------------------
Date: 8 May 88 18:04:01 GMT
From: cca!g-rh@husc6.harvard.edu (Richard Harter)
Subject: State Machines, The Ultimate Goto
In article <4627@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>In article <27568@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
>>Goto logic says leave and don't come back.
>Not true. For example:
> FOO: goto FOO;
You misapprehend. This is not an example of 'goto' logic -- it is
an implementation of a simple loop using goto's.
>Goto logic says you can come here anytime you need to and from anywhere you
>want to (within limits, of course).
Well, this is a matter of terminology -- what precisely does one mean
by the phrase 'goto logic', which is actually a neologism. Since I coined
the phrase, I will claim priority and say it is my definitions that should
be used :-). Seriously, however, your definition is not of much use, because
what you say is true of procedure calls also. The difference is:
Procedure logic: Record where you are now, transfer to a labelled block
(called a procedure) and transfer back to the recorded transfer point upon
completion of the block.
Goto logic: Do not record where you are now; simply transfer to a labelled
block (no standard name). Determine within the block the next block to be
executed. The essence of 'goto logic' is that there is no return point to
return to.
In theory, procedure logic is stronger than simple goto logic, i.e.
you can simulate an N statement program which uses gotos but not procedures
with an O(N) statement program using procedures but no gotos, said procedure
using program running in O(the execution time of the original program).
Conversely there are programs using procedures which cannot be replaced by
a program only using gotos without paying a penalty either in space or time.
[The reason for this is that the return is actually a 'computed goto' which
is stronger than the simple goto.]
>>The prescription against goto's really means -- don't mix
>>the two types of structure.
>I think I agree with you (I'll have to ponder this a little while longer).
It is worth mentioning that the reason for the stricture is that
in 'goto logic' all control is at the same level. In truth, most real
examples of goto logic are actually embedded goto logic, where there is
a remembered return point that any 'goto block' can exit to. I.e. you
put a state machine inside a block and exit the state machine by exiting
the block.
I have added comp.lang.misc to the group list and have directed
followups there, because this is no longer particularly a C topic.
------------------------------
End of Soft-Eng Digest
******************************