Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!pyrltd!root44!praxis!itcp
From: itcp@praxis.co.uk (Tom Parke)
Newsgroups: comp.software-eng
Subject: Re: Pictorial Case Tools
Message-ID: <1991May29.123727.23393@praxis.co.uk>
Date: 29 May 91 12:37:27 GMT
References: <1991May23.185623.24457@agate.berkeley.edu> <19874@crdgw1.crd.ge.com> <1991May24.202600.14452@netcom.COM> <1991May25.080657.3447@weyrich.UUCP>
Organization: Praxis, Bath, U.K.
Lines: 59

orville@weyrich.UUCP (Orville R. Weyrich) writes:

>2) CASE tools are largely visually oriented. 

>3) So are some [but not all] people. [Some people are verbally oriented, etc.]

This assumes that a visual form can be useful. Fredrick Brooks wrote
in his seminal "No Silver Bullet". [no-one should post to
comp.software-eng who hasn't read it :-)] 

	"The complexity of software is an essential property, not an
	accidental one. Hence descriptions of a software entity that
	abstract away its complexity often abstract away its essence."

and later...

	"The reality of software is not inherently embedded in space.
	Hence it has no ready geometric representation in the way the
	land has maps, silicon chips have diagrams, computers have
	connectivity schematics. As soon as we attempt to diagram
	software structure, we find it to constitute not one, but
	several, general directed graphs, superimposed one upon the
	other. ... These are usually not even planar, much less
	heirarchical. Indeed, one of the ways of establishing
	conceptual control over such a structure is to enforce link
	cutting until one or more of the graphs becomes heirarchical." 

	"In spite of progress in restricting and simplifying the
	structure of software, they remain inherently unvisualizable,
	thus depriving the mind of some of its most powerful
	conceptual tools."

On a more prosaic level I would add, in the context of diagramming
CASE tools, that 

1. Diagramming notations tend to have weak or vague semantics JSP
structure diagrams and ERA diagrams are honourable exceptions.

2. Entering and maintaining diagrams is time consuming. 

3. A diagram is only helpful when it is neatly and clearly laid out.

4. The automatic neat and clear laying out of a diagram is hard.

5. Even the best current workstations bare the same relationship to a
drawing as 25-line 80-column character terminals do to a page of
printed text.

With the exceptions of 1. above I would limit the use of diagrams to
their ad hoc use during design (pencil and paper/whitboard) - ad hoc
in when they are used and in what and how they portray it. And in final
documentation - where computer preparation may be necessary for "finish".

	Tom
-- 

Tom Parke (my opinions and spelling are strictly temporary) 
"Trust me - I'm a banker, and this is a metal detector." - Steve Bell
itcp@praxis.co.uk