[comp.software-eng] visual languages

goettler@immd2.informatik.uni-erlangen.de (H. Goettler) (02/20/90)

I am gathering material on any kind of diagram technique being 
used in the software engineering process. I already have lots 
of information on: 
Nassi-Shneiderman
HIPO
SDL
JDT
ESTELLE
LOTOS
SD
I'd appreciate very much if you could provide me with information 
on other visualization techniques, which you think are good and 
should deserve more attention. These visualization techniques 
need not integrate the whole software life cycle. They might 
be useful, say, just for requirement analysis, performance 
analysis, debugging, etc.

Herbert Goettler

munck@chance.uucp (Robert Munck) (02/22/90)

In article <2446@medusa.informatik.uni-erlangen.de> goettler@immd2.informatik.uni-erlangen.de (H. Goettler) writes:
>...I'd appreciate very much if you could provide me with information 
>on other visualization techniques, which you think are good and 
>should deserve more attention. ...
>Herbert Goettler

SADT is far and away the best visual language for requirements analysis
and similar forms of modeling.  It is also known as Structured Analysis
and Design Technique, IDEF-0, and "State, Activity, Data, Transition".
The best published description is "SADT" by Marca and McGowan,
McGraw-Hill, 1988.

The graphic language is a "constraint diagram," basically a
generalization of data flow, flowchart, state-transition, etc.  It is,
essentially, a more powerful structuring mechanism for natural language,
a kind of structured hypertext.  Quite powerful CASE tools are available
for it.  The methodology was developed in the early 70's by Doug Ross
and others at SofTech and has been used in many major commercial and
military projects; it is a corporate standard for IBM, DEC, Toshiba,
Phillips, ITT, and others.

SADT is, in my opinion, unique in putting major emphasis on how groups
of people work together well.  For example, the two-week course spends
the better part of a day on "courtesy,"  an idea rarely mentioned in
other methodologies.  Other topics include how to get the enthusastic
cooperation of overworked experts, dealing with computer-phobes,
organizing personal and group files, keeping accurate, complete, and
highly-detailed project histories, and resolving controversy.  Another
example: the peer review procedures put as much emphasis on the
understandability of the document as on the correctness of its content. 
An incorrect document that is understandable can be corrected; a correct
document that is not understandable is useless.

Questions cheerfully answered.

Bob Munck
Internet: munck@mitre.org
UUCP:     ...[backbone]!linus!munck
Work:     The MITRE Corporation, MS Z-666
          7525 Colshire Drive
          McLean, VA    22102-3481
          703/883-6688
          703/883-5519 (fax)
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688

jkenton@pinocchio.encore.com (Jeff Kenton) (02/22/90)

From article <98229@linus.UUCP>, by munck@chance.uucp (Robert Munck):
> 
> SADT is far and away the best visual language for requirements analysis
> and similar forms of modeling.  It is also known as Structured Analysis
> and Design Technique, IDEF-0, and "State, Activity, Data, Transition".
> The best published description is "SADT" by Marca and McGowan,
> McGraw-Hill, 1988.
> 
> The graphic language is a "constraint diagram," basically a
> generalization of data flow, flowchart, state-transition, etc.  It is,
> essentially, a more powerful structuring mechanism for natural language,
> a kind of structured hypertext. . . .  
> 
> SADT is, in my opinion, unique in putting major emphasis on how groups
> of people work together well.

Does anyone else have any experience with this? About 8 years ago I was
part of a startup which had a person who had been at Softech.  He tried
to promote SADT, but wound up creating friction and blocking progress in
many imaginative ways.  He left after 9 months without having written a
single line of code, and a demo scheduled for the board of directors in
two weeks.

Was it him, or us, or SADT?


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com	 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

sdl@lyra.mitre.org (Steven D. Litvinchouk) (02/24/90)

In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes:

> About 8 years ago I was
> part of a startup which had a person who had been at Softech.  He tried
> to promote SADT, but wound up creating friction and blocking progress in
> many imaginative ways.  He left after 9 months without having written a
> single line of code, and a demo scheduled for the board of directors in
> two weeks.
> 
> Was it him, or us, or SADT?

There's an obvious question.  How well did things go on the project
*after* this person left?  Did the non-use of SADT afterwards produce
demonstrable progress?


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730
(617)271-7753

ARPA:  sdl@mbunix.mitre.org
UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

	"Where does he get those wonderful toys?"
				-- J. Nicholson

--
Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730
(617)271-7753

ARPA:  sdl@mbunix.mitre.org
UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

	"Where does he get those wonderful toys?"
				-- J. Nicholson

cs86eew@cc.brunel.ac.uk (Eoin Woods) (02/28/90)

In article <SDL.90Feb23164916@lyra.lyra.mitre.org> sdl@lyra.mitre.org (Steven D. Litvinchouk) writes:
>
>In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes:
>
>> About 8 years ago I was
>> part of a startup which had a person who had been at Softech.  He tried
>> to promote SADT, but wound up creating friction and blocking progress in
>> many imaginative ways.  He left after 9 months without having written a
>> single line of code, and a demo scheduled for the board of directors in
>> two weeks.
>> 
>> Was it him, or us, or SADT?
>
>There's an obvious question.  How well did things go on the project
>*after* this person left?  Did the non-use of SADT afterwards produce
>demonstrable progress?
>
Even if there was progress, it does not really refect positively or negatively
on the SADT method. Promoting a tool is one thing, blocking a project and
making it run late is surely unprofessional in the extreme. It sounds as if
the Ex-Softech-ie was getting mixed up between the use of SADT specifically and
using good software development method. Presumably you were using a method but
they thought it could be done better with SADT.

I could have been you, it probably was him but it can;t have been SADT - It
can't produce friction - only the human's using it can!!

Besides, I think SADT is really quite good !

Eoin.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| FROM  : Eoin Woods  Computer Science Department, Brunel University,        |
|                     Uxbridge, Middlesex UB8 3PH                            |
| JANET : cs86eew@mercury.cct.brunel.ac.uk                                   |
| UUCP  : ...ukc!cct.brunel!cs86eew                                          |
| ARPA  : cs86eew%cct.brunel.ac.uk@cs.ucl                                    |

wdr@wang.com (William Ricker) (03/02/90)

cs86eew@cc.brunel.ac.uk (Eoin Woods) writes:
>>In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes:
>>
>>> About 8 years ago I was
>>> part of a startup which had a person who had been at Softech.  He tried
>>> to promote SADT, but wound up creating friction and blocking progress in
>>> many imaginative ways.  He left after 9 months without having written a
>>> single line of code, and a demo scheduled for the board of directors in
>>> two weeks.
>>> 
>>> Was it him, or us, or SADT?
>I could have been you, it probably was him but it can;t have been SADT - It
>can't produce friction - only the human's using it can!!

As an ex-SofTechie who was annoyed that SofTech never trained him in SADT,
but has worked elsewhere with ex-SofTechies even more arrogant than
myself, including one SADT co-developer, I suspect the friction was
produced (a) by the ex-SofTechie, a lot of us have awfully good opinions of
our own opinions, consulting houses breed that; and (b) aggressively
ramming his favorite methodology down peoples throat as *the one true way*.

If the original poster would like to mail me the name of the suspect 
*privately*, I might be able to reply more conclusively as to his reputation
and likely guilt or innocence.  If I don't know him, one of my even-more
arrogant ex-colleagues can tell me...

Note that a good designer *can* be an asset to a project even if s/he never
writes a line of code.  But a good analyst/designer by definition is a 
builder of consensus, not friction.  The JAD methodology from PRI is the 
"hot"  new replacement for SADT in this area.

>Besides, I think SADT is really quite good !
  
I rather like it myself.  I do note that both L.J.Peters and C.F.Martin
comment that it, like abstract DFD octupi-charts, are difficult to explain
to the sponsor-clients of large systems (executives, not programming 
managers); and that SADT reviews with less experienced or less trusting
reviewers drop into gnit-picking about "why is this flow/arc a control not
data?" when what should be discussed is three-boxes or four-boxes to 
decompose this node.

We have stolen the "kit" and "author-reader cycle" concepts from SADT,
whereby people provide 12-48hour turnaround on small pieces of spec,
with context and feedback, in a structured interaction, without benefit
of conference room.  And we use whatever diagram style fits, or just memos
(usually from an outliner) for the body of the "kit".

Bill Ricker