Hi All
I'd appreciate some feed back on this. Renaming the package structure
again will be painful so I'd hope to get this right on first release.
My intention is to define a common package structure not only for the
new sequence diagrams but also something for other diagram types to
adhere to as they split out of ArgoUML into their own plug-in module.
The package structure of a module is designed to match with our subsystems.
org
argouml
core
diagrams
sequence2 -- top level package for seq2 module
module -- contains class that registers module
diagram -- contains the actual diagram implementation
proppanel -- contains the property panel implementation
for sequence diagram
critics -- nothing yet - reserved for critics
regarding sequence diagram layout
reveng -- nothing yet - reserved for generating
sequence diagrams from code
The hierarchy of packages I took to match with the current eclipse
project name argouml-core-diagrams-sequence2
However, what do we mean by core here? This is a module but it is
argouml owned. Should this be module or core?
If we have a namespace of org.argouml then is core/module useful?
Do we need the first level of diagrams separation? The seq2 module
primarily exists to provide diagrams but it also extends other
subsystems such as proppanels.
Is this better or something else inbetween?
org
argouml
sequence2 -- top level package for seq2 module contains class
to register
module -- contains class that registers module
diagram -- contains the actual diagram implementation
proppanel -- contains the property panel implementation for
sequence diagram
critics -- nothing yet - reserved for critics
regarding sequence diagram layout
reveng -- nothing yet - reserved for generating
sequence diagrams from code
Regards
Bob.
2008/12/4 Bob Tarling <[EMAIL PROTECTED]>:
> Just a reminder before I go ahead and do this before the seq2 module
> goes live I intend to rearchitect the packages as such
>
> 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
>
> The intention is that at a later date there is likely to be
> org.argouml.core.diagrams.sequence2.cognitive - Critics for sequence2
> org.argouml.core.diagrams.sequence2.reveng - Reverse engineering code
> for sequence diagrams
>
> This keeps our subsystems clearly separated within the seq2 module.
>
> Regards
>
> Bob.
>
> 2008/5/2 Bob Tarling <[EMAIL PROTECTED]>:
>> 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.
>>> >
>>>
>>
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=981309
To unsubscribe from this discussion, e-mail: [EMAIL PROTECTED]
