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

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

On 18 Nov 1996, Piercarlo Grandi wrote:

> >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:
> 
> menio> On 11 Nov 1996 > 
> 
> piercarl> Yes, but what's the relevance of this to the question of
> piercarl> whether "OO programs are systems of interacting **objects**"
> piercarl> rather than systems of modules (either classes or prototypes
> piercarl> or actors) that ``contain'' procedures that invoke each other?
> 
> piercarl> Do OO programs by and large describe static relationships
> piercarl> between modules (or parts thereof like interfaces)? Or do they
> piercarl> describe collections of instances/clones of those modules (or
> piercarl> their types) and how they interact?
> 
> menio> I think the answer to this can be found in the analysis model.
> menio> The analysis model descibes the objects that will be existance
> menio> during the systems existance. In this model and thus the
> menio> functioning system your interested in definate articals ie actual
> menio> entities not classes of entities(ie currentProcess, ActiveWindow,
> menio> nextTransaction, rather than definitions of the types which these
> menio> are instances of) . The relationships expressed are dynamic ones
> menio> as the effects of the messaging between these objects will be
> menio> related to thier state.
> 
> According to your argument, which has already been seen in slightly
> different guises, if a bank has a customer list application, then the
> analysis model will describe N million objects if the bank has N million
> customers. If the bank acquires a new customer, or loses a customer,
> then the analysis model will have to be revised, for the "objects that
> will be in existance during the system existance" will have changed.
> 
> "think before you leap"...
> 
> 

A system in which a 1:N object relationship exists and often
undergoes large changes in the n side of this relationship
requires a structure capable of handling these 
changes. An analysis model which describes the system as
dynamic interactions and relations  between objects 
is fundamental in creating such a structure. The example
you mention can only be though of in terms of
varying numbers of instances of a customer class, thus
in terms of objects. The behavior being  modeled is in terms
of messages between some subset of the N customers and the
list object. The very concept of sending messages to multiple
copies of the same class  by definition requires you to think
in terms of objects.  Even in class definition  your thinking  is
in terms of a typical instance of the class being created. Implementation
of behavior is defined in terms of state, state is a characteristic
of objects. Example

 
customer_list::add_client(customer *new_client)
{

client_vector.add(new_client);


}

customer::customer(char *social_security, dollars opening_deposit)
{
this->identity = social_security;
this->current_balance = opening deposit;


}

the very idea of the assignment of a runtime determined parameter(an
argument)  to an instance variable can only be though of terms of
objects. The same holds true for the idea of increasing the current 
client list by the new client in the above customer_list::add_client()

In a pure OO environment the very act of running an application is
a create message to the application from the user via the O.S.
Application execution begins with instantation of a class, object
creation and messaging. Thus an application as a whole is a dynamic
entity with equally dynamic relationships with other such
entities in other words a a subsystem of a system of interacting
objects. The very idea of persistance mechanisms revolves around
allowing these objects to exist in a dormant state, construction
and destruction can only be thought of in terms of objects, these
activities are essential to OOP execution. Thus OOP programs
are interacting systems of objects.


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

	Your power is your ideas, your ideas are products of
	perception, your perception is the product of your
	architecture, architecture is everything - me