Thanks for the summary and the additional detail. That helps
understand the proposal.
I think the crosscutting issue is something that you are going to have
no matter what organization you pick. It's just the nature of the
beast. I don't see a reason that the package structure needs to
mirror the structure of what's being extended.
I think there are too many packages in both the old and the new
structure. I can't really see having a package for 1 or 2 classes.
Here's what I'd suggest - just two packages (actually I think this is
the same or similar to what Linus suggested too):
org.
argouml.
sequence2. // module registration (4), prop panel &
factory(1), notation(2)
diagram // The actual diagram implementation graph
model, diagram Figs etc (3 & 5)
Any reverse engineering stuff is probably only going to be a class or
two, so it can go in the top level package as well. If it looks like
there are going to be a dozen or more critic classes, they can go in
their own package org.argouml.sequence2.critics.
>> 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.
Yes, modules definitely need to extend multiple subsystems, but I
think we need to think in terms of making the modularity more fine
grained in general. There's no reason that seq2 critics need to go
into the seq2 module. They could be in a module of their own or there
could be a set in the seq2 module and then someone else could come
along a provide an "enhanced critics" module which provided additional
seq2 critics as well as additional use case or core critics.
For reference, in Eclipse terms, units of redistributable code are
called "plugins". Plugins map 1:1 with Eclipse projects. Plugins can
be grouped into "features" which are chunks of functionality that make
sense from a user's point of view. Plugins can provide "extension
points" which are well defined interfaces for plugging things
together. Plugins can also provide "extensions" to the extension
points defined in other plugins (thus introducing a dependency). Each
plugin can provide multiple extensions and multiple extension points,
so there's a many to many mapping, but no cycles are allowed in the
dependency graph.
As I've said many times, the OSGi/Eclipse plugin model is the one that
ArgoUML should migrate to.
Tom
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985890
To unsubscribe from this discussion, e-mail:
[[email protected]].
