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