Begin forwarded message:

From: "Carla F. Griggio" <carla.griggio@gmail.com> Date: December 30, 2010 7:42:50 AM GMT+01:00 To: Stéphane Ducasse <stephane.ducasse@inria.fr>, stephane ducasse <stephane.ducasse@free.fr> Subject: Fwd: what is the status of SmallUml?

---------- Forwarded message ---------- From: Carla F. Griggio <carla.griggio@gmail.com> Date: Mon, Dec 13, 2010 at 6:15 PM Subject: Re: what is the status of SmallUml? To: Stéphane Ducasse <stephane.ducasse@inria.fr>

Hi Stef!

I made several refactors from the GSoC version, so it can be more extensible on the future when adding new diagrams or new kind of nodes. That doesn't bring "new features" by itself, but it makes possible to add new features in the future :P

Actually, I've been using smallUML to make object diagrams for another project. It works, but... as I don't have a nice automatic positioning algorithms, it's still a little caotic.

The same problem came up when Mariano asked me to add automatic inheritance diagrams. Building the model of the diagram was very very easy, but showing it not so much, because I needed a minimal positioning algorithm. I made one, it's not the best but it works :P

So, the new stuff would be:

A better design overall, although I still have to make some refactors (now I know morphic a little more, so I can clean up some messy changed/update code) Object diagrams (still messy, but there they are) Automatic inheritance diagrams Before diving into positioning algorithms, I want to add some menues to add relationships in a more 'graphic' way. Once I do that, I can actually get rid of the "workspace" panel in the Diagram Browser and build the diagrams entirely in a graphic way.

Then I have to start digging into positioning algorithms. At Smalltalks 2010 many people asked me for some features that really need that, and while using it I also notice that it's neccesary to help building diagrams more rapidly and in a more confortable way. Of course that would only be to "suggest" an initial position of every diagram node that it's introduced to the diagram from the existing code (i.e: inheritance trees), and then the user can modify that position, I don't want to lose that :)

Another thing that people suggested (in Smalltalks and also ESUG) was some way of letting the programmer know when a diagram needs to be updated, because as the diagrams are not "liked" to the code, documentation can be easyly forgotten, and consulting an unupdated diagram could be confusing. I think that's another whole chapter, what do you think?

Cheers! Carla

On Sat, Dec 11, 2010 at 10:40 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: