Login | Register
My pages Projects Community openCollabNet

argouml
Wiki: Diff for "Ideas for GSoC 2011"

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

Differences between revisions 1 and 12 (spanning 12 versions)

Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma section-numbers on In the ArgoUML project we were hoping that we will be able to take part in Google Summer of Code 2011. The ArgoUML project has taken part before with great success. !ArgoEclipse and the Profile handling are essentially student projects.
Line 3: Line 3:
In the ArgoUML project we are hoping that we will be able to take part in Google Summer of Code 2011. In 2006, 2007, and 2008 we had a lot of students that improved ArgoUML and vitalised the project.

This page is based on ["Ideas for GSoC 2010"]

## Instructions to the editors of this page:
## Guessing why we were not selected in 2009 and what we
## could do to improve ourselves for 2010 is not a simple task.
## One thing is the Ideas page. The 2009 page ["Ideas for GSoC 2009"]
## have many many short ideas. Better explanations (10-20 lines on
## each suggestion) would probably have been better. Let's try that for 2010!

[[TableOfContents(3)]]
Unfortunately, ArgoUML was not a chosen organization for 2011.
Line 19: Line 8:
=== ArgoUML towards UML 2.0 ===
ArgoUML needs to be changed to support UML 2.0.
=== Reading an UML 1 model into an UML 2 model ===
ArgoUML is still based on an UML 1.* model while some work has been done to support the euml backend for UML 2. 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 as well as new Diagram types.
Line 22: Line 11:
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. Currently this is implemented using two separate backends for ArgoUML.
Line 24: Line 13:
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.
To allow the ArgoUML Users to move their old models from UML 1 to UML 2 we need a way to read the old UML 1 models from within the UML 2 model backend preserving all the information (element types are changed, texts, relations, Uids, profile connections are preserved...). There is also a need to dig into the differences between UML 1 and UML 2 and decide how incompatible constructs are to be handled.
Line 32: Line 15:
A couple of these challenges could be chosen combined into a project or made into projects for themselves. The diagram shows a possibility for placing the model conversion function and several options for reading the UML 1 model.
Line 34: Line 17:
=== Moving ArgoUML to Eclipse - RCP ===
A lot of work has gone into moving ArgoUML to and Eclipse-based platform (see [http://argoeclipse.tigris.org 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.
attachment:ArgoUML_Model_Conversion.png
Line 37: Line 19:
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.
=== UML 2 Graphics ===
For the drawing of elements in the model, ArgoUML uses GEF (not the one that was a part of Eclipse but the tigris one (http://gef.tigris.org). GEF and ArgoUML stores the graphics in a non-standard way while UML 2 has a standardized ways of storing the graphics.
Line 42: Line 22:
This project is to explore what it would take to make ArgoUML and GEF to store and read graphics using the standardized format.
Line 43: Line 24:
=== 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.


=== 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


=== 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?


=== 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.
Suggested by: [:linus:Linus Tolke]
Line 101: Line 28:
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.  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. A knowledge of UML is not a requirement but a interest and eagerness to learn is.
Line 104: Line 31:
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. 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.  Our bug database (Issuezilla) and previous GSoC projects suggestions could be used as inspiration.
Line 106: Line 33:
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. For inspiration you could also look at the lists of previous projects:
 * [http://argouml.tigris.org/googlessoc2006.html Projects for 2006]
 * [http://argouml.tigris.org/gsoc2007/index.html Projects for 2007]
 * [http://argouml.tigris.org/gsoc2008/index.html Projects for 2008]

Please join the developers' mailing list (dev@argouml) to discuss your project with the team so that you can develop the strongest possible proposal for evaluation.
Line 109: Line 41:
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. This wiki contains a lot of information on the design of ArgoUML and how we work in the project.
Line 111: Line 43:
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. 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 to the mailing list will be manually approved so be patient (usually within 24 hours).

In the ArgoUML project we were hoping that we will be able to take part in Google Summer of Code 2011. The ArgoUML project has taken part before with great success. ArgoEclipse and the Profile handling are essentially student projects.

Unfortunately, ArgoUML was not a chosen organization for 2011.

Project ideas

Reading an UML 1 model into an UML 2 model

ArgoUML is still based on an UML 1.* model while some work has been done to support the euml backend for UML 2. 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 as well as new Diagram types.

Currently this is implemented using two separate backends for ArgoUML.

To allow the ArgoUML Users to move their old models from UML 1 to UML 2 we need a way to read the old UML 1 models from within the UML 2 model backend preserving all the information (element types are changed, texts, relations, Uids, profile connections are preserved...). There is also a need to dig into the differences between UML 1 and UML 2 and decide how incompatible constructs are to be handled.

The diagram shows a possibility for placing the model conversion function and several options for reading the UML 1 model.

UML 2 Graphics

For the drawing of elements in the model, ArgoUML uses GEF (not the one that was a part of Eclipse but the tigris one (http://gef.tigris.org). GEF and ArgoUML stores the graphics in a non-standard way while UML 2 has a standardized ways of storing the graphics.

This project is to explore what it would take to make ArgoUML and GEF to store and read graphics using the standardized format.

Suggested by: Linus Tolke

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. A knowledge of UML is not a requirement but a interest and eagerness to learn is.

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. Our bug database (Issuezilla) and previous GSoC projects suggestions could be used as inspiration.

For inspiration you could also look at the lists of previous projects:

Please join the developers' mailing list (dev@argouml) to discuss your project with the team so that you can develop the strongest possible proposal for evaluation.

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.

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 to the mailing list will be manually approved so be patient (usually within 24 hours).


CategoryFurtherDevelopment

Ideas for GSoC 2011 (last edited 2011-03-18 23:45:01 -0700 by linus)