Hello Bob!
If the modules and subsystems match, should we redefine the subsystems to
improve on the understanding of the system?
/Linus
2008/12/12 Bob Tarling <[email protected]>
> Hi Linus
>
> To my mind a module is not a system. It is a component that contains
> extensions of our subsystems. I'm trying to highlight what those
> subsystems are by separating the packages and also use that to enforce
> we don't get cycles back in (I've never used jdepend, I may need some
> help).
>
> I saw this when the sequence diagram came out as it was clear that it
> was not just the diagram itself that needs to be pluggable but as that
> module is registered or not we want to plug in/out the property panel
> for the diagram and any critics for the diagram etc. The module became
> more than just the sequence diagram subsystem.
>
> I think that you're suggesting that I could put everything inside one
> package in the module. This mixes up property panels classes and
> diagram classes in the same package. Critics will later be added and
> maybe some support for reverse engineering.
>
> Maybe I'm trying to be too purist in this separation. I'm interested
> in further views. Please take a look at the current layout of the seq2
> module and my previous proposal on refactoring package layout.
>
> You are correct on how I'm trying to get the subsystems apart.
> Separating individual diagrams first should make it clear what those
> diagrams require as a common interface.
>
> The last to come out would be some common-diagram subsystem containing
> things like FigClass that can be used in many diagram types and
> FigNodeModelElement etc.
>
> Details pane is similar. We have just the properties panel in
> Christians last GSOC project but others will come out into other
> modules in time or may actually belong to some other module.
>
> For example it could be that the style panel is something that is
> sensibly a part of the common-diagram module. If we have argouml with
> no diagrams but just being used by someone as a model explorer the
> style panel makes no sense.
>
> Regards
>
> Bob.
>
>
> 2008/12/12 Linus Tolke <[email protected]>:
> > 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=983285
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=984050
To unsubscribe from this discussion, e-mail:
[[email protected]].
