[Binah-devel] initial attempt at class diagram

[Dexter A. <ve...@ia...>]

here's a first, *way* tentative cut at a class diagram:

http://www.luminousbeings.com/binah/class_0.1.gif

here's the argoUML file:

http://www.luminousbeings.com/binah/binah_0.1.zargo

I thought this might kick off some thoughts or discussion...

a couple things to note,
- i'm *really* unsure about the RuntimeEntity stuff.  how much state 
should we try to preserve, versus just re-querying the JDI/eclipse data? 
  it's sorta an optimization question, plus i figured it could be 
delayed till we settled the JDI vs Eclipse Debug issue.  For the purpose 
of discussion here, I'm imagining instances of RuntimeEntity being the 
various Methods, Threads, Object Instances, etc in the running code.

- The EntityState stuff is a simple instance of the State pattern.  The 
idea is that the user will interact with the system in some way to 
change how different Entities get drawn.  So, two instances of the same 
class (ie, two instances of RuntimeEntity), one might be the "focus of 
attention" and one might be merely "visible" or even "shawdowed" to get 
it out of the way.

- The AttributeValue pattern (Attribute, AttributeValue and their 
subclasses) is there to allow GraphicDescriptions to change on the fly, 
that is, if there's a twiddle in the interface that says "hide all 
objects but the watched ones", then the Descriptions of all the Object's 
States (except for (RuntimeEntity Instance) "Instance"'s WatchedState 
Description) would get the new AttributeValue "False" that pointed to 
Attribute "Visibility".

- The "TemporalAttributeValue" is a first-thought attempt at trying to 
add the notion of time-travel to the system.  The idea would be that 
either you passed the current time in with every request for an 
AttributeValue's value.  I'm imagining that AttributeValue is 
responsible for knowing what it's values in the past have been-- I'm 
really fuzzy whether that is best or not, other ideas?  (I don't believe 
we'll ever be able to "roll-back" execution of Java code, so we'll have 
to store what we need.  It's possible that this could be dowe closer to 
the API level, but that's still an open question.)


Anyway, aside from the intial design, there's a couple of remaining 
issues that are gonna haunt us if we don't resolve them quickly:

- what debug API?  Eclipse's debug stuff vs JDI-direct are the two on 
the table.  We may want to make a list of the things we want from the 
debug API and do a checklist approach-- that'd focus the evaluation effort.

- despite the "iterative programming" concept, i think adding the 
temporal stuff in after-the-fact will be a total bitch, so if we want to 
have "time travel" aka, TiVo slider-bar, I think we should make the call 
in this here elaboration iteration one.

- 3D API.  I'm falling down pretty strongly in favor of Java3d rather 
than a native OGL wrapper.  Aron-- have you had a chance to look at 
either of these much?


-- 
Brian "Dexter" Allen   "Being nationalistic in the sense in which it is
www.luminousbeings.com  now demanded by public opinion would, it seems
ve...@ia...      to me, be for us who are more spiritual not mere
ve...@ac...          insipidity but dishonesty, a deliberate
                         deadening of our better will and conscience."
				               Friedrich Nietzche (1884)