[comp.software-eng] Pictorial Case Tools

hammondr@sunroof.crd.ge.com (Richard A Hammond) (05/24/91)

In article <1991May22.223228.5483@netcom.COM>
jls@netcom.COM (Jim Showalter) writes:
>I'm not a big fan of any of the pictorial CASE tools. ... For pictorial
>design work, the all-time greatest tool is a whiteboard in a well-lit
>room. ...

In article <1991May23.185623.24457@agate.berkeley.edu>
bks@alfa.berkeley.edu (Brad Sherman) writes:
>   I heartily concur with Mr. Showalter's advocacy of whiteboards over
>pictorial CASE tools.  I would also like to recommend the use of large
>calendars, with the last few months and the next 6 months all simultaneously
>visible on a wall, as superior to any scheduling software available.

This sounds to me a bit like the old Ada vs C debates -	:-)
Ada - more structured, C - less confining

For me the main purpose of the pictorial case tools is to capture the design
at as early a stage as possible so that we can begin testing for consistency
and omissions with automated tools.  The same is true of the scheduling
software.  It should provide automatic checking of the deadlines vs progress.
One can do these tests manually on white-boards, but it is tedious, time
consuming and error prone on a large project, just like software engineering
in C.:-)

Now, I'm neglecting the issue of whether the current crop of tools actually
do the checking or not.  Also, as Jim Showalter pointed out, the tools seem
to have problems handling large projects, which is precisely where one needs
them the most.  I'm confident the tools will improve, just like Ada compilers
have.

I don't object to using white boards as scratch pads and transferring the
results to a tool, that's the way I work.

My main concern is that the tools, unlike Ada, don't seem to be mandated,
and thus the vendors might go out of business before they manage to
produce production quality tools.

Rich Hammond

jls@netcom.COM (Jim Showalter) (05/25/91)

>For me the main purpose of the pictorial case tools is to capture the design
>at as early a stage as possible so that we can begin testing for consistency
>and omissions with automated tools.

I guess the issue I have with this is not so much the checking--I agree
that tools automate checking--as it is the notion that there is anything to
BE checked that is an indicator of good design. Yes, a tool can automatically
check that all my bubbles and arcs line up properly, but the fundamental
issue I have with this is: what proof, if any, is there that those bubbles
and arcs have anything to do with a good design? It gets back to the same
issue in the metrics thread in this same group: for metrics to be of value,
one has to have confidence that the metrics are measuring something that
has a correlation to project success; for design tools to be of value, one
has to have confidence that the tools are enforcing things that have a
correlation to good design. I think what designers do is largely ephemeral:
it takes place in the space between their ears. Good designers do something
that produces a good design. Most people are not good designers. I doubt
that good designers arrive at good designs by manipulating bubbles and arcs
in their brains (I could be wrong here--anybody who is a good designer care
to describe how they do what they do?).
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

orville@weyrich.UUCP (Orville R. Weyrich) (05/25/91)

In article <1991May24.202600.14452@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>>For me the main purpose of the pictorial case tools is to capture the design
>>at as early a stage as possible so that we can begin testing for consistency
>>and omissions with automated tools.
>
>I guess the issue I have with this is not so much the checking--I agree
>that tools automate checking--as it is the notion that there is anything to
>BE checked that is an indicator of good design. Yes, a tool can automatically
>check that all my bubbles and arcs line up properly, but the fundamental
>issue I have with this is: what proof, if any, is there that those bubbles
>and arcs have anything to do with a good design? It gets back to the same

A person's ability to think about a problem depends on their ability to 
express the relevant aspects of the problem in some sort of precise
language which is easy to use. The language may be verbal or visual. 

The question becomes, "Do bubbles and arcs express some relevant aspect
of the system being designed in a convenient and precise language?"

See my comments below regarding this question.

>issue in the metrics thread in this same group: for metrics to be of value,
>one has to have confidence that the metrics are measuring something that
>has a correlation to project success; for design tools to be of value, one
>has to have confidence that the tools are enforcing things that have a
>correlation to good design. I think what designers do is largely ephemeral:
>it takes place in the space between their ears. Good designers do something
>that produces a good design. Most people are not good designers. I doubt
>that good designers arrive at good designs by manipulating bubbles and arcs
>in their brains (I could be wrong here--anybody who is a good designer care
>to describe how they do what they do?).

Several things occur to me:

1) A software tool's usefullness depends on how well it facilitates
   mapping between the problem and solution domains.

2) CASE tools are largely visually oriented. 

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

4) Sensory-mode mismatch tends to lead to loss of communication effectiveness.

5) The degree to which CASE tools facilitate good design therefore depends
   on the degree to which the designers are visually oriented. 

6) This then raises the question: what percentage of the designers are
   comfortable in visual mode? An interesting topic for a human-factors
   study.

7) I like to think that I am a good designer :-). I am comfortable in visual
   mode, but prefer to manipulate bubbles and arcs on paper [or blackboards:
   I do not care for the solvents in dry-erase markers]. It is not the only
   thought mode that I use [for some aspects of a problem, for example, I
   prefer decision tables -- more verbally oriented, but still with a
   visual (spatial) component].

8) Good "Form" seems to be necessary but not sufficient requirement for a
   good design.

9) CASE tools that can do consistency checks help ensure good Form, and hence
   good design.

--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

tsarver@andersen.uucp (Tom Sarver) (05/28/91)

In article <1991May24.202600.14452@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>>For me the main purpose of the pictorial case tools is to capture the design
>>at as early a stage as possible so that we can begin testing for consistency
>>and omissions with automated tools.
>
>I guess the issue I have with this is not so much the checking--I agree
>that tools automate checking--as it is the notion that there is anything to
>BE checked that is an indicator of good design. Yes, a tool can automatically
>check that all my bubbles and arcs line up properly, but the fundamental
>issue I have with this is: what proof, if any, is there that those bubbles
>and arcs have anything to do with a good design?
>    [Stuff deleted referring to metrics and correlation between good design
>     and good cross-checking facilities.]

The usefullness of cross-checking facilities of a CASE tools depends largely
on the methodology which it supports.  If the tools only recognizes bubbles
and arrows, then automated checking is of dubious value.  However, a more
precise methodology (or design technique) would deliver more value.

My case in point is Structured Analysis Design Technique (SADT).  The
constraints on using this technique are very specific.  For example, an
incoming arrow in the child diagram must be coming into the given box in
the parent diagram.

The value of using an automated SADT (which is available) is immediately
apparent specifically because of its cross checking facility.

Of course when choosing a methodology, you are implicitly saying, "I believe
that following this methodology will help me create better (insert your
criteria for better) software."  Then, choosing a tool which supports
the methodology is a natural extension of using the methodology.

>-- 
>**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
>*Proven solutions to software problems. Consulting and training on all aspects*
>*of software development. Management/process/methodology. Architecture/design/*
>*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

--Tom Sarver
tsarver@andersen.com
Andersen Consulting, 100 S. Wacker, Chicago, IL 60606, (312) 507-4912

haim@taichi.uucp (24122-Haim Kilov(L028)m000) (05/28/91)

With respect to:

"A person's ability to think about a problem depends on their ability to
express the relevant aspects of the problem in some sort of precise
language which is easy to use. The language may be verbal or visual.

The question becomes, "Do bubbles and arcs express some relevant aspect
of the system being designed in a convenient and precise language?" "

-- the most important question seems to be: "do bubbles and arcs represent
a _precise_ language?"


--Haim Kilov
haim@bcr.cc.bellcore.com

itcp@praxis.co.uk (Tom Parke) (05/29/91)

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

seb1@druhi.ATT.COM (Sharon Badian) (05/29/91)

in article <1991May28.165251.4840@porthos.cc.bellcore.com>, haim@taichi.uucp (24122-Haim Kilov(L028)m000) says:

> The question becomes, "Do bubbles and arcs express some relevant aspect
> of the system being designed in a convenient and precise language?" "
> 
> -- the most important question seems to be: "do bubbles and arcs represent
> a _precise_ language?"

How about "Do bubbles and arcs represent a *more precise* language than
what you are using currently?" If you are using plain old English, then
the answer is yes.

Sharon Badian
att!druhi!seb1

jls@netcom.COM (Jim Showalter) (05/30/91)

I agree wholeheartedly with the points made in your post with one exception:
I think it is fairly straightforward to diagram the STATIC structure of
software. By static, I mean what in Ada is called the "with" dependency
closure: the visibility that each unit has to all others. It is even easier
to diagram the export/import interface relationships between software
subsystems at the architectural level. These diagrams, particularly the
latter, are quite useful. Unfortunately, they don't represent the dynamic
behavior of the software at all--and the dynamic behavior is typically
orders of magnitude more complex than the static structure.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

haim@taichi.uucp (24122-Haim Kilov(L028)m000) (05/30/91)

In response to:

> The question becomes, "Do bubbles and arcs express some relevant aspect
> of the system being designed in a convenient and precise language?" "
>
> -- the most important question seems to be: "do bubbles and arcs represent
> a _precise_ language?"

How about "Do bubbles and arcs represent a *more precise* language than
what you are using currently?" If you are using plain old English, then
the answer is yes.

Sharon Badian
att!druhi!seb1


----- I'd like to note that all too often pictures used in, e.g., "ER diagrams"
are incomplete, inconsistent, or both. As a result, important aspects of
the modeled system are relegated to the "data dictionary" where they are
expressed as "comments". Note that I'm not trying to defend plain old English.
There exist other means (e.g., predicate calculus). A picture may help to
understand _some_ aspects of a system, misunderstand some other aspects, 
and may be irrelevant at all for some other aspects.

Design and programming are the same activity done on different levels of
abstraction. Correctness concerns are of utmost importance for both. And, in
the same manner as "flowcharts" are inadequate for program development, 
pictures are inadequate for "system" development.

-Haim Kilov
haim@bcr.cc.bellcore.com

itcp@praxis.co.uk (Tom Parke) (06/04/91)

seb1@druhi.ATT.COM (Sharon Badian) writes:

>in article <1991May28.165251.4840@porthos.cc.bellcore.com>, haim@taichi.uucp (24122-Haim Kilov(L028)m000) says:

>> The question becomes, "Do bubbles and arcs express some relevant aspect
>> of the system being designed in a convenient and precise language?" "
>> 
>> -- the most important question seems to be: "do bubbles and arcs represent
>> a _precise_ language?"

>How about "Do bubbles and arcs represent a *more precise* language than
>what you are using currently?" If you are using plain old English, then
>the answer is yes.

On the contrary, plain old english can, between consenting adults, be
as precise as you like. 

	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