I've just come across another subsystem that diagram modules will want to plug in to. Toms recent commit to RESequenceDiagramDialog reminded me.
When class diagrams are extracted they will also need to plugin to the reverse engineering subsystem. We'll need some common way for diagram modules to extend and allow themselves to built as part of the reverse engineering process. I was planning on leaving class diagrams till last anyway so we have some time to think about that. Again, using sequence2 as an example we currently require org.argouml.core.diagrams.sequence2.module - The module class to register with framework org.argouml.core.diagrams.sequence2.diagram - The sequence2 extension of the diagrams subsystem org.argouml.core.diagrams.sequence2.proppanel - The sequence2 proppanel org.argouml.core.diagrams.sequence2.cognitive - Critics for sequence2 org.argouml.core.diagrams.sequence2.reveng - Reverse engineering code for sequence diagrams Bob. 2008/5/2 Bob Tarling <[EMAIL PROTECTED]>: > I'll rename the sequence2 package soons so let me know if anyone > disagrees with my suggestion. > > I've just realised that some diagram modules will want to register > critics so we will in theory also need > org.argouml.core.diagrams.sequence2.cognitive > > Are we happy that this pattern is used for packages as other diagrams > are extracted? > > Bob. > > > > 2008/5/1 Bob Tarling <[EMAIL PROTECTED]>: > > > > The new sequence diagram implementation proves how easy it is to keep > > a particular diagram type within its own clear subsystem as a separate > > eclipse project loaded at runtime as a plugin. > > > > I'd like to go ahead and do this with the other diagram types. I think > > the more we begin to move stuff out of argouml-app the clearer it will > > be how to move the rest. > > > > Initially I'd just like to move the packages in their current > > structure but eventually I'd like to refactor into a flatter package > > structure. > > > > The sequence diagrams I should be able to refactor sooner rather than > > later though. I'll use that as an example of what I'd like to see > > > > First of all I'd like the base package structure to echo our new > > naming convention > > > > So we will have > > > > org.argouml.core.diagrams.sequence2 > > > > In that base package I would expect no classes > > > > The subpackages would contain the implementations > > > > org.argouml.core.diagrams.sequence2.plugin - The module class > > org.argouml.core.diagrams.sequence2.diagram - The sequence2 extension > > of the diagrams subsystem > > org.argouml.core.diagrams.sequence2.proppanel - The sequence2 > > extension of the proppanels subsystem > > > > > > We seem to use the term module and plugin interchangeably. Could we > > settle on one. I would suggest plugin as it tends to fit eclipse > > terminology better. > > > > Bob. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
