Consider an object on a background canvas
within a browser such as this.
The graphical object represents a chunk
of Java, that is, an instance of a Java object.
| If the object had subobjects: | If the object were a pre-existing hunk of java: |
I want to edit the subobjects interactively:
![]() |
I would be taken to the code where I
could
make changes:
public void Graph(double xDrawBuf[], Color fore,
// draw x axis and
y axis
// set line color
|
For example if I wanted to do a simulation of an automobile engine, I might choose to break that down as a single cylinder engine running autonomously. I might choose to break a single cylinder engine into a combustion chamber, a piston, a connecting rod and a crankshaft object. Each piece would have a visual component consisting of geometry and rendering specifications. Each piece would have an analytic model possibly consisting of a different geometry with a material specification. These could be used to compute mass. Input messages would be the external forces applied to the object. Output messages could be the new position, velocity and acceleration applied to interface models which would handle the connection between objects.
A key aspect of all this is to develop a one to one correspondence between visual models and Java objects. Let's develop this for a set of simple structural problems.
Consider the table of object below.
By combining instances from the table a large number of common engineering
problems can be expressed, even though the vocabulary is incomplete.
We would like to freely choose among the constraints, links, springs and
forces to connect some kind of a structural abstraction together.
We would then like to click a "Run" button and find out what happened to
the structure. Did it move? Did it bend? Does it reach
equilibrium, does it keep accelerating, does it oscillate?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
How would we organize such a tinker toy engineering system along an object oriented paradigm? What unifying algorithm could be used that would cause the solutions that we see from statics and dynamics to simply appear? How would we distinguish solution steps that iterate towards static equilibrium from those that march in time? Can we model the three problems on the bottom row of the table as an automatic conversation among cooperating objects?
Consider the leftmost problem in the bottom row of the table, the statics problem. The "conversation" might go something like:
Force object:
Who am I connected to?
Let me check my table.
I am connected to node
B of link A.
Tell [Link A: Node B] that [Force: F = ai+ bj].
End Force
Link object:
Who am I connected to?
Let me check my table.
For each subobject:
Node A:
I
am connected to a fixed constraint.
I
cannot move in x, in y or theta.
i = Case[3,1] // from green class table above
Node
B:
I
am connected to a Force object.
I
will ask Force what their* message is.
Ask[Force
object]**
Force tells me I have an applied force of [Force: F = ai+
bj].
j
= Case[3,4]
End For
run Solver[i, j] to compute new link state [ pos, vel, acc, rot, bending, shear, elongation, etc.]
update my free
body diagram
End Link
Floor object:
Who am I connected to?
Let me check my table.
I am connected to node
A of link A.
Tell [node A of link A] that [Floor: dx = 0, dy = 0, dtheta=0].
ask Solver for reaction so I can
update my free body diagram
End Floor
Remarks
Note that the force and floor objects do not run the solver. Only the link has the power to run the solver, since it is the only object that has the possibility of a change of state. However the floor object needs to consult the solver to find out what the reaction was so that the free body diagram of the floor reaction can be drawn.
One should be able to go through an
elementary statics and dynamics text, specify the problems in JIVE and
click run. Easy as pie.
My question, and reason for creating this
document was this, "Can this be done?", "Is Java the right implementation
language", "are their better solutions already in existence that
will allow me to worry about the problem instead of the solution methodology?".
I have always wanted to pose engineering
problems on a unified visual platform. Until Java appeared there
was no widely available object oriented programming language that wasn't
riddled with the frailties of pointers. If Java holds to its promise
of "write once, run everywhere", it could be a significant advance.
The appearance of the Microsoft Java Application Foundation Classes (AFC)
solves many of the user interface problems that plagued earlier versions
of Java. It is not clear at this writing how the AFC integrates with
the existing development environments such as Visual J++. We'll have
to wait a couple of days for that epoch to pass.
**"Ask" causes an evaluation of an object if the objects output queue is empty. If the object has been evaluated then the message in the output queue of the object is sent.