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

[Anthony Menio <menio@pegasus.montclair.edu>]

On 11 Nov Paul Gover
> 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.
> 
> 
	I think the distinction you are speaking od is the one 
between the analysis model and the design model. The analysis
model is one of the objects which will exist in the system and the
interactions between them. These are objects not classes, thus
they are definite articals. This model is assumed to take place in
an ideal environment. Thus the specifics of the development environment
are ignored, ie operating system, language,database system in use etc.
The design model describes the classes and class relations which the
objects in the previous model will be created from. This model
is developed from the previous now in the specific implementation
model for the system. The the processes that create these models
should be seemless thus the implementation model should be
created from and be as consistant as possible with the
analysis model. Thus both described the system and both
do so in terms of same architecture(an OO) just at
different levels of detail. So in essence your talking
about the deliverables of two different stages in an
OO systems development process rather than two
different sets of methods, and the answer is that these
both reflect the OO architecture of the system equally.
Regardless of the size or complexity of any system thier exists
both an analysis model and a design model which will
be equally valid descriptions of it. Thus any component
you wish to create must have the abilites of an instance
of it modeled and then a blue print to create these instances 
of. Consider the development of a set of components
from a physical system lets say a transmission you would
be interested in describing the behavoir and attributes of a
example of this transmission and its sinteraction with everal
instances of types of cars. From this model you would create your
blueprint thus your design the type description.
 

Anthony Menio
I.S. student
menio@pegasus.montclair.edu