In the ArgoUML project we are hoping that we will be able to take part in Google Summer of Code 2010. In 2006, 2007, and 2008 we had a lot of students that improved ArgoUML and vitalised the project.
Contents
1. Project ideas
1.1. ArgoUML towards UML 2.0
ArgoUML needs to be changed to support UML 2.0.
ArgoUML is still based on an UML 1.* model while some work has been done to support the euml backend. Moving all the way to euml will make ArgoUML compatible with the whole range of euml-based tools i.e. all Eclipse-based UML tools.
There are several challenges in this area such as:
- Build property panels for UML2 elements.
- Update of existing diagrams with new UML 2.0 constructs.
- Addition of new UML 2.0 diagrams.
- Tool for converting UML 1.4 models.
- Add UML 2.0 features to code generators.
- Store diagrams using the UML 2 Diagrams format.
A couple of these challenges could be chosen combined into a project or made into projects for themselves.
1.2. Moving ArgoUML to Eclipse - RCP
A lot of work has gone into moving ArgoUML to and Eclipse-based platform (see the ArgoEclipse project). Also GSoC projects from previous years have been successful in improving this. What is still missing is the integration with the software update mechanism in the RCP version of ArgoEclipse.
This work includes:
Getting the auto-update function from Eclipse to work in the RCP version of ArgoEclipse.
Fixing all available ArgoUML modules to work with ArgoEclipse.
- If possible getting the module discovery, installation, and update mechanism to work with the non RCP version of ArgoUML.
1.3. Redesign of Notation Subsystem
The Notation Subsystems purpose is to generate text to display within diagram figures. The notation has knowledge of what model elements in the UML model are required to build the description of any particular textual element in a diagram figure.
This differs in complexity for different types of model element. e.g. The class name notation only requires to know of a specific class element. However an operation notation needs to know of an operation and all the parameters of that operation. If any of those model elements change then the display will have to be rebuilt.
Moreover the visual component using a notation can change notation type from one to another (e.g. UML to Java) so entire suits of notations are available for different language types.
An early design decision was to build notations as a Flyweight pattern. Each notation item has knowledge of what model elements the GUI should be listening to so that the GUI display can change when the model change (e.g. the operation display will change when the operation changes in the model but also when any parameter changes). The GUI requests that information and then the GUI takes charge of actually performing the listening.
That decision in hindsight was not the best choice. Its resulted in an overcomplicated architecture which often results in the GUI listening to too many different events and redrawing itself too frequently.
This work includes:
- Begin a new notation subsystem as a plugin module
- Adapting the flyweight pattern into a standard factory pattern
- Move responsibility of listing to the model from the GUI to the notation subsystem (done)
- Introduce an event mechanism from the notation subsystem to the GUI (done)
- Replace reflection by factory classes
- When complete this work will allow further improvements to the GUI to reduce redrawing and rebuilding of diagram figures. Should time allow work can continue into improving the GUI.
1.4. Missing Diagram Figures
ArgoUML was developed initially with Java code generation and reverse engineering only and therefore became very Java-centric (this has been resolved with C#/C++ modules etc included). ArgoUML was also developed way before way before generics were introduced to Java.
The result is that in the early days there was little attention given to Templates in UML.
As well as this there are other missing diagrammatic features that would bring ArgoUML closer to the UML specification
This work includes:
- Completing template and template binding
- Qualified associations
- Lollipop (ball and socket) notation for interfaces
1.5. Improve GUI Interaction
ArgoUML has always strived to make the users experience as pleasurable one. Interacting with the tool should be intuitive and as effortless as possible.
We are open to new ideas from students about how to improve user interaction with the diagrams and the rest of the GUI to make the UML designers work as easy as possible.
Some current ideas include includes:
- Simplify drawing of self associations
- Laser tool for edges (instead of dragging an edge with the mouse all the way to where it needs to be dropped the edge will automatically look past the mouse to the next figure it finds to connect to).
How else could you make the diagrams easier to interact with?
1.6. Update to Graphics2D
ArgoUML was originally developed before Java2D introduced the Graphics2D class. Much of the core libraries still cater for the possibility of the far simple Graphics class.
Updating the code to use Graphics2D should bring further features.
This would include but not be limited by
- Completion of SVGWriter2D - a Graphics2D replacement of our SVGWriter class that is currently the only class that ties us to the old Graphics implementation.
- Gradient fill.
- Line width settings.
2. The Students we are looking for
We are looking for enthusiastic students with a solid knowledge of Java, who are interested in software development tools and modeling, particularly the UML modeling language. Most, although not all, tasks will be easier for those who already have an working knowledge of the OMG's UML.
3. The projects we are looking for
This page include a list of suggested projects that the development team has thought of, but we are happy to consider projects which are not listed here.
If you'd like to suggest a different project, please discuss it previously with the team on the developers' mailing list so that you can develop the strongest possible proposal for evaluation. Our bug database (Issuezilla) could be used as inspiration.
4. Quick intro of general information in the project
This wiki contains a lot of information on the design of ArgoUML and how we work in the project. The Cookbook was used before this wiki and is entirely migrated into the wiki so it is presumably less updated.
All discussions about the ArgoUML project, the ideas above, and other ideas, are kept at the developers' mailing list dev@argouml.tigris.org that also is available as a discussion forum on this site (at http://argouml.tigris.org/ds/viewForumSummary.do?dsForumId=450). Join the list on the web site and start your discussions there. Your first posting will have to be manually approved so be patient.