Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Tim Ottinger <tottinge@csci.csc.com>]

Bill Gooch wrote:

> Well, I'm sorry that I apparently misinterpreted what you wrote.
> I do believe that you know these things, and perhaps what we are
> dealing with is a reflection of the fact that "design" is a very
> broad term.  I think of software designs in layers, from the most
> abstract (related directly to the domain model) to concrete (the
> closest to the implementation, and most language-specific).  This
> covers such a broad range that the relationship between layers at
> each end is often lost, simply because there are so many refining
> transformations in between, and methods don't support specifying
> those refinements very clearly or completely.  (This can change.)

> In any case, I didn't say that the specification I referred to
> was necessarily executable, nor usable to generate a program.
> 
[Alan Lovejoy wrote]
> > My thesis is that a design **methodology** should be able to handle designing
> > a program regardless of language, although it will certainly need to take the
> > differences between langauges into account.  If I have to use a completely
> > different methodology for each part of the system that is implemented in a
> > different language, something is wrong.
> 
> More or less, I agree.  But in a practical sense, it isn't so
> much the *methods* that are limited (with some exceptions), it
> is the *notations* which don't span languages very well.  The
> need to be able to specify language-dependent aspects of design
> when appropriate argues for multi-lingual, rather than language
> independent, notation.  IOW, perhaps you flip a language switch
> when you're ready to deal with the more concrete design layers.
> 
> Mapping designs between languages is even more problematic.

If there's one thing that we should learn from Mr. Booch and the many
others who've been with OO through the good, the bad, and the ugly
projects, it's that we have to watch out for "the big project".

The Big Project is the "clean-break from the past", "do it all", "no
limits", type of project which typically fails.  Typically, people
believe that they can build a complex system, which works, from 
scratch.

An end-all notation is a great idea, and if you can make a notation
or method which is independent of all technologies but which uses
every technology well, then I would love to see it.

We have to face the "fact" that a design notation has to map cleanly
into the engineering realm. If I could borrow the flimsy and much-
touted "other fields" analogy, what good would a circuit diagramming
notation do if it didn't map cleanly into manufacturing?  In fact, 
if we don't consider manufacturing in our notation, we're probably 
making a big mistake.

For instance, it's sometimes a mistake to use OO notation for a SA/SD
software project, likewise it's frequently troublesome to use SA/SD
design, and expect to manufacture an OO system easily from it.

[ SOAP BOX WARNING: BEGINS NOW ]

As much as we like to glorify our jobs, we analyse in order to design
well, and design well so that we can build well, and we build well so
that the software will run well.  If my design is "independent of tech"
that might be nice unto itself, but it pushes problems downstream.

A lot of the analysis/design/code/test/release/revisit talks I hear are
legitimate.  You clearly should know what you want before you start, 
etc.  Ad-hoc hacking can lead to some pretty ill-conceived systems,
which
act ill-conceived.  Nobody wants that.

On the other hand, a lot of talk seems to be trying to maintain a status
quo for the "SE" career path
(tester->coder->designer->analyst->manager).
Let's face it, our separation of concerns is often separation of
careers,
and it exists to give us a promotion path with requisite pay raises and
status.

We're in an incremental world now.  We iterate (okay, not all of us,
SM).
If we can't maintain our business organization and separation of roles
and pay ranges in this world, is that a problem with the methods or the
status quo?

It's a hard call.  It's bigger than this list, and can't be corrected
by developers (though we can push for this).  When we change our 
manufacturing methods, we must change the front-line skills, the tools
(notation/language) and the organization of labor.

We can surf, or we can get washed away.  

[SOAPBOX WARNING OVER]

But the "ultimate" methodology should match the way we generate
software.
It should not be independent of it.  It should not limit our abilities,
and some tradeoff must be made from time to time.  But our early
analysis
must eventually map onto hardware, or it wasn't a very useful part of
the
software development process (though it can be good for professional 
development ;-) )

-- 
Tim
+------------------------------------------------------------------+
|     Tell me again, *why* must we publish estimates before we     |
|     gather requirements?                                         |
+------------------------------------------------------------------+
| Tim Ottinger, Sr Tech			     tottinge@csci.csc.com |
| CSC Communications Industry Services		 217-351-8508x2420 |
| TRIS Division -- Cellular Billing and Support	  Fax 217-351-2640 |
+------------------------------------------------------------------+