Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!apple!portal!fernwood!dumbcat!hal
From: hal@dumbcat.sf.ca.us (Hal Wine)
Newsgroups: comp.object
Subject: Re: How would you model this situation?
Summary: Model the connections as objects, too.
Message-ID: <219@dumbcat.sf.ca.us>
Date: 24 Oct 90 16:14:04 GMT
References: <16734@rouge.usl.edu>
Organization: MH Software, Hayward, Ca.
Lines: 85

In article <16734@rouge.usl.edu> pcb@cacs.usl.edu (Peter C. Bahrs) writes:
> The Domain: Object-oriented with concurrency if needed, objects have
>      local state, behaviors
> 
> The Problem:
>   Model an application where two things(people) ara each applying a 
> force(pulling) on another thing (ends of a rope).  The acted upon
> thing (the rope) breaks.
> 

I haven't actually done an OO system like this, either, but I have a few
observations (i.e. opinions) based on the OO systems I have done.  (Another
caveat -- it's been *years* since I did any classical mechanics.):

-	It seems that there are actually two issues here: how to model the
	interaction between the objects; and how to propigate changes in a
	model during simulation.  I'll only address the first.

-	I see more than the three objects in the system, as there are also the
	connections between these objects.  I'll refer to the original objects
	as simulation objects, and the connections as simulation connections.  

	The simulation connections have knowledge of how the change (e.g. force
	vector) propigates across that connection, as well as the simulation
	objects to which it is connected (I think there are only two, but I
	couldn't prove it).

	Similarly, the simulation objects know about all of their connections,
	as well as how a change affects it (e.g. for force: deformation,
	acceleration, etc.), and all the proporties of the object (location,
	motion, color, etc.).

	(Note that a collection of such objects is a simulation system, and that
	they could exist recursively.  I.e., the rope could be modeled by a
	system consisting of the two end points as simulation objects joined
	by a simulation connection that would have knowledge of the breaking
	point.  The rope ends might know about stretch, etc..)

(The rest of this discussion assumes that we're only dealing with a classical
mechanics aspect of the tug of war, and will ignore physiological changes
and psychological connections <grin>.)

-	When a change in force is imposed on a simulation object, it responds
	with the force vector comprising the "equal and oposite reaction" that
	comes back across the connection.  Any unbalanced force contributes to
	motion of the system.  I.e. the net force is the (vector) sum of the
	input force and the results of propegating the input force across the
	object and all other connections.  (Note that this results in an order
	'n' squared algorithm.)

-	Putting it together (and ignoring simulation timing), when person 1 (p1)
	pulls away, the change in force vector is sent to the p1-rope connection
	which in turn propegates the vector to the rope.  The rope deals with
	stretch, and propigates the remaining vector to the rope-p2 connection,
	which passes it on to the person 2 (p2) object.  The p2 object calculates
	the net force acting on it, notes any changes to its position, and returns
	its opposing force.  The rope integrates that force into its state, and
	returns the total opposing force to p1.  P1 can then update its position,
	based on its net force.

-	If the rope breaks, the rope (or the rope end to rope end connection)
	know this and simply no longer propigates a force.  This preserves the
	integrity of the system, and requires no special handling by any other
	simulation object or simulation connection.

Physics aside, what this means from an OO design standpoint is that each
object knows about its neighbors only via connections, and propigates *all*
changes to those connections.  It is up to the connections to decide what
(if anything) to do about the change.  The knowledge of the connections is
limited to their existance, however; i.e. each simulation object has a
connection list over which it iterates the sending of the change message.
Furthermore, the connection list is local to each object.  Only those parts
of the model which receive some sort of outside input need to be visible to
other parts of the application.

(For what its worth, I've successfully used similar designs for updating
multiple views of a model and protocol stacks.)

This reply got overlong, thanks for presenting such an interesting problem.
I may have to try implementing some of this...

--Hal
-- 
-- hal@dumbcat.sf.ca.us
-- {ames,decwrl,sun}!pacbell!dumbcat!hal