Hello Bob!
This question is partly about how to organize ArgoUML into subsystems. You
seem to have done this in the other way. This is mostly in your list of
subpackages. Let me explain.
The current plan is to have subsystems grouped by where things are showing
on the screen:
- diagrams
- property panels
- todo
- explorer
- code generation / reverse engineering
Your suggestion seems to first split on the type of diagram:
- use case
- sequence
- ...
and then split on diagrams, property panels, critics, etc.
Leaving that my question is about how many classes are we talking about? Is
it really necessary to split in more than two packages? Like this:
org.argouml.sequence2 (for main classes and module stuff)
org.argouml.sequence2.diagram (for classes that are internal to the sequence
diagrams implementation).
If any of these would contain more than 40 classes then I understand that
you would want to split it further but with my limited knowledge, it looks
like that is not the case.
/Linus
2008/12/8 Bob Tarling <[email protected]>
> 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]].
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=983222
To unsubscribe from this discussion, e-mail:
[[email protected]].
