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

[Paul_Gover@uk.ibm.com]

I think there's a general thread appearing here over the boundary between
design and coding, and over what constitutes a program.  What happens to
the discussion if we introduce another boundary between applications and
programs?

I can see that an application's design might be expressed as
a network of interacting objects, and without such objects there's no
application.  I can also see that it's possible to design class hierarchies
to solve application development problems (for example a matrix class to
help develop a linear programming application) which clearly contain
executable program code despite having neither objects nor their interactions
defined as part of the program.

To clarify, we write such a class definition in terms of the indefinite article -
"A matrix inverse" - whereas in the application definition we'd write in terms of
the definite article - "THE costs matrix.  (My apologies to readers whose native
language is Russian, which I think has neither definite nor indefinite articles!)

If we restrict a development method to applications, I think it's perfectly
possible to consider a design which specifies no implementation details.
But if we consider a development method for programs, I suggest it should
address implementation details such as capacity, performance, reliability,
generality.

If that's so, can we separate development methods into two groups along this line,
(and if so, are the groups non-empty :-)?  Does the term "OO" mean the same thing when
applied to the different groups?  I suggest not: application designs seem to be
independant of implementation, so if we use the term to mean inheritance,
encapsulation and polymorphism, it's irrelevant; in the application context it's
more a synonym for "entity -relationship" (which I'd justify by pointing to Alan's
interacting object instances).  Conversely in "component" design, the traditional
OO attributes are very relevant to the implementation.  Perhaps the
entity-relationship details now come more as constraints on the design, ie, an input,
than a design product.

Paul Gover
IBM Warwick Development Group
Mumbling for myself, not IBM.