Hi Tom
Currently the seq2 packages have the following structure. Some of this
was a reflection of the packaging from the original implementation.
Notation has been added since.
I give a number in brackets to highlight where I suggest a package is moved.
The is the current package structure of seq2 in SVN
org.
argouml.
proppanel.
sequence2. // The property panel factory and
implementation (1)
notation // The UML notations for sequence diagram (2)
uml.
diagram.
sequence2. // The sequence graph model only (3)
module // The class for registering the module (4)
ui // The sequence diagram, Figs etc (5)
Below is the structure I would like to move to and become the common
structure as further diagrams are split out.
Explanation given below.
org.
argouml.
sequence2. // top level package for seq2 module
module // The class for registering the module (4)
diagram // The actual diagram implementation graph
model, diagram Figs etc (3 & 5)
notation // The UML notations for sequence diagram (2)
proppanel // The property panel factory and implementation (1)
critics // Nothing yet - reserved for critics
regarding sequence diagram layout
reveng // Nothing yet - reserved for generating
sequence diagrams from code
Actually everything in the above is to allow sequence diagrams which
is why I suggest sequence2 as the top level package name under
org.argouml. Otherwise we're crosscutting packages in core ArgoUML.
Having notation as a subpackage of proppanel is confusing it suggests
some relationship where there is none.
A package for uml seems fairly redundant to me in a UML tool.
There seems little point to me in having a hierarchy of packages that
contain only the graph model in one and the Figs (sequence2 and
sequence2.ui). Such a hierarchy really means nothing in java but it
does imply some relationship. That hierarchy tends to suggest that the
ui is used by the model rather than the other way around. I have
simply combined these as the graph model an ui together into
(org.argouml.sequence2.diagram)
> If the modules and subsystems match, should we redefine the subsystems to
> improve on the understanding of the system?
I'm not sure what you mean by "If the modules and subsystems match".
There are no new subsystem here so that requires no new change to
subsystem descriptions.
Maybe what needs clarifying is my view of modules as components. I
think in the past it has been assumed that a module would be a
subsystem. However seq2 proves that a module actually needs to extend
and integrate to various subsystems of the main application.
Bob.
2008/12/14 Linus Tolke <[email protected]>:
> 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=984568
To unsubscribe from this discussion, e-mail:
[[email protected]].
