As an ArgoUML contributor I'm going to blog my activities here, so that they may draw interest by other developers or help other developers when doing tasks similar to what I've done. AND(!) the grand vision that makes an Argonaut what he is, TO THRIVE IN THE BIG DANGEROUS WORLD, TAKING THE Argo TO A GOOD SHORE ;-))

Saturday, June 28, 2008

Google Summer of Code 2008

I'm a Google Summer of Code 2008 mentor for ArgoUML. It is fun and, as stated over and over, one learns a lot by teaching and in my case mentoring.

The student I'm mentoring is Bogdan Szanto and he is working in fixing diagram usability issues. This includes fixing some existing problems and adding new features, that hopefully will make ArgoUML users happier.

Bogdan already helped fix some problems found in the new sequence diagrams implementation – argouml-core-diagrams-sequence2. I was a bit late in this game, because he started working in this during the community bonding period and we both wanted him to “bond” with other developers than me. But, now it is long finished and I started supporting his work directly by reviewing patches and testing code and learning about the specifics of the implementation. So, while I was debugging I found the following issues that must go into the DB:

  • Summary: Broom causes ClassCastException when used in a seq2 diagram that contains a Note “connected” to a ClassifierRole

    ModeBroomMessages thinks that all edges in the diagram are messages, but, there can be connections between Notes and ClassifierRoles. The following exception happens when the Broom is used in a seq2 diagram that contains a Note “connected” to a classifier role:

     java.lang.ClassCastException: org.argouml.uml.diagram.static_structure.ui.FigEdgeNote
     at org.argouml.uml.diagram.sequence2.ui.ModeBroomMessages.getAllFigMessages(
     at org.argouml.uml.diagram.sequence2.ui.ModeBroomMessages.getAllFigMessagesDownward(
  • Summary: destroy action cleans the lifeline of the caller

    When a destroy action is created between two classifier roles, the lifeline of the caller becomes fully dashed. I think that the opposite shouldn't also occur, but, that the lifeline of the callee either should become dashed from the point where the message arrives onward or that it should finish there (preferable).

    See the attached figure “destroy-action-clears-lifeline-of-caller.png”.

  • Summary: selected create Action + “Alt” key cause repositioning of created CR

    When you draw a create Action between two classifier roles, leaving it selected, and, afterwards press the “Alt” key, the created CR is repositioned in the top position. If the create Action isn't selected this problem doesn't occur.

No comments:

Reader Shared items