I would like to say that we should not do this work per package. Instead we
should do it per subsystem.
Looking at the Cookbook chapter 5 the Model, Critics, Diagrams, Notation,
Profile, Other source languages, GUI, and Explorer subsystems already have
diagrams explaining one aspect or the other. I think this is what shall be
improved upon.
/Linus
2008/7/16 Bob Tarling <[EMAIL PROTECTED]>:
> Hi Tony
>
> There are two problems I see
>
> 1) ArgoUML is still being untangled from a big ball of spaghetti code.
> 2) Automated diagrams based on packages don't describe enough.
>
> By just creating a diagrams based on package means that often you will
> not see graphically that a model element in that package extends
> something from another package or has an association across packages.
> For many packages you will see just a bunch of unconnected boxes. This
> stands out in ArgoUML particularly as we seem to have level of
> separation of classes into packages that I think isn't truly needed.
> Our package split is rather heavy and so we are more likely not to see
> these relationships.
>
> So in order to see some sense from the model the user needs to create
> their own diagrams and drag classes from various packages together to
> really visualize the relationships. This takes quite some time and
> effort.
>
> But then somebody changes the code. It's no coincidence that I've just
> created issue 5242 and 5243.
>
> What happens when someone does some mass refactoring to move classes
> between packages?
>
> ArgoUML has no way of knowing that those classes have moved. Where a
> user has gone to a lot of effort to carefully place all those classes
> in the right place he then finds on the next attempt at reverse
> engineering that those diagrams have not been updated and still show
> as if the classes exist in their old location.
>
> With ArgoUML still being picked apart from this tangle of code then
> that kind of refactoring will continue.
>
> The slow separation of ArgoUML into components I think will help. I
> think the Model component and the Model/MDR component are stable
> enough to model and will remain relatively stable.
>
> I imagine Model/EUML should also be stable enough that we are at least
> unlikely to have any mass refactoring going on. We could model those
> components and their relationships.
>
> I don't think the other parts are going to become stable enough to do
> this until they also have been extracted into separate components
> (modules/plugins).
>
> Sequence2 is the first of these but for the moment, before it goes
> live, I am considering some change to the package structure or clearer
> naming. I feel it's important to get that right before other diagrams
> follow suit and become separate components.
>
> As components then have a clearer interface we can model their
> relationships to each other and that is likely to remain quite stable.
>
> With some flatter repackaging going on during the extraction to these
> components we should also have better information in the
> auto-generated diagrams showing the internals of those components.
>
> So, what you say does makes sense. We should be able to eat our own dog
> food.
>
> But I think we have a few more issues to resolve in the RE processing
> and some more separation and stability required in the product as a
> whole.
>
> Bob.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
