[kepler-dev] Ptolemy Kore Dependencies

Christopher Brooks cxh at eecs.berkeley.edu
Sun May 25 20:03:27 PDT 2008


Attached is a pdf of the Ptolemy Kore package dependencies
that I created with
http://www.umlet.com/
My notes about uml tools are at
http://embedded.eecs.berkeley.edu/dopcenter/faq/115.html

I've checked the original .uxf file in to ptIIdoc/doc/uml.

I started trying to show the imports for the subpackages, but it
was a mess.


_Christopher

Edward A. Lee wrote:
> Great!  An updated UML package diagram would be welcome...
> 
> Edward
> 
> At 09:38 AM 5/23/2008, Christopher Brooks wrote:
>> Ok, I've refactored Ptolemy Kore so that the dependencies are better.
>>
>> Below, as we go down the list of packages, packages at the top don't
>> depend on packages at the bottom.
>>
>> However, within a top level package, we still may have dependencies
>> between the top level package and its subpackages.  I think this
>> is ok, since the subpackages are often syntactic sugar used to
>> break down large packages into smaller packages.
>>
>> Also, not all packages within a top level package are part of Kore.
>>
>>
>> ptolemy.math  - does not depend on other Ptolemy packages.
>> ptolemy.util  - does not depend on other Ptolemy packages.
>> ptolemy.graph - uses Exceptions from ptolemy.kernel.util
>>              - uses NamedObj for better error message
>>
>> ptolemy.kernel, ptolemy.kernel.{attributes,util,undo}
>>              - Depends on ptolemy.util
>>              - Circular dependency: CompositeEntity depends on
>>                kernel.attributes.VersionAttribute
>>
>> ptolemy.data, ptolemy.data.{expr,type,unit}
>>              - Depends on kernel, kernel.util, math, util
>>              - Circular dependencies: Classes in data depend on
>>                ptolemy.data.{expr,type,unit} and the reverse
>>
>> ptolemy.actor - Depends on actor.parameters,
>>                data, data.expr, data.type
>>                graph
>>                kernel, kernel.util
>>                math, util
>>
>> Things starts to break down here.  In particular, the moml/actor split
>> is tricky.
>>
>> ptolemy.actor.gui depends on many packages, including moml.
>>
>> moml depends on many packages, especially actor.
>>
>> However, I _think_ I've removed the circular dependencies between
>> moml and the actor packages.  
>>
>> Kore Actor packages that require moml:
>>      actor.gui, actor.gui.style
>>      actor.lib.hoc
>>
>> Note that other non-Kore actor packages like actor.gt, actor.gui.run,
>> actor.lib.jxta also require moml, but these are not a concern.
>>
>> I also removed dependencies in various actor packages on vergil.
>> The data.unit package got split up and part moved to moml.unit.
>>
>> Future work:
>> - Fix any broken tests or builds.
>> - Refactor ptolemy.actor.lib.gui so that it is easier to substitute
>>   in non-graphical classes for headless runs
>> - Once we choose a new version control system, create modules for 
>>   Kore
>>
>> _Christopher
>>
>>
>>
>> ------
>>
>>    I'm using the term "Ptolemy Kore" to refer to the core packages
>>    of Ptolemy that are needed by Kepler or other developers that want
>>    to mix and match Ptolemy packages.
>>    
>>    http://en.wikipedia.org/wiki/Persephone says:
>>    "for the Greeks knew another face of Persephone as well. She was also
>>    the terrible [Queen of the Dead], whose name was not safe to speak
>>    aloud, who was euphemistically named, simply as, Kore, "The Maiden", a
>>    vestige of her archaic role as the deity ruling the underworld."
>>    
>>    The K in Kore also refers to Kepler.  
>>    
>>    I've started a list of package dependencies at
>>    http://www.kepler-project.org/Wiki.jsp?page=PtolemyPackageDependencies
>>    
>>    Basically, there is a certain amount of cleanup that should happen.
>>    
>>    Thomas Feng is working on pulling fsm out of data.
>>    
>>    actor.gui has references to vergil.  I'll work on that.
>>    
>>    The data.unit package is rather well entwined in the code.  I'm open
>>    to suggestions on how we can make it optional.
>>    
>>    A larger issue is:  What do we do with code that is not in the Kore
>>    modules?  For example, ptolemy.data.properties is not in a Kore
>>    module.  I'd rather leave it where it was and use some sort of build
>>    system to determine what packages go into Kore.
>>    
>>    _Christopher
>>    _______________________________________________
>>    Kepler-dev mailing list
>>    Kepler-dev at ecoinformatics.org
>>    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> --------
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> 
> ------------ 
> Edward A. Lee
> Chair of EECS and Robert S. Pepper Distinguished Professor
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html  
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptolemyKorePackageDependencies.pdf
Type: application/pdf
Size: 104516 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20080525/2d1dc61a/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptolemyKorePackageDependencies.uxf
Type: text/xml
Size: 7352 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20080525/2d1dc61a/attachment-0002.xml>


More information about the Kepler-dev mailing list