- Project tools
- Using ArgoUML
- How do I...
|Over 500 more tools...
ArgoUML in Google's Summer Of Code 2008
The ArgoUML organization will take part in
Google Summer of Code 2008.
This page include a list of project suggestions and
some general tips on
what we look for in a student,
what projects we want to see,
how you should fill in your applications,
some quick references on the projects.
Don't let this list limit your choices.
We are happy to consider other projects!
general notes on what projects we are
looking for. For a list of the top vote getting requests in the
Issue database, use
Module Loader Eclipse-style
We would like to integrate the Eclipse module loader in ArgoUML.
We have had a long list of problems with the module loader and
previously reimplemented it once already.
The Eclipse project is, on the other hand, very experienced and successful
with their module loader/plug-in handler.
We assume the following challenges:
- Remaining name resolution problems to be solved
- Identifying APIs
- All modules are built and distributed as Eclipse Plug-ins
- Java Web Start
There are also
some other ideas on requirements on the implementation that could be useful.
Developer Contact: Linus Tolke
eUML model subsystem
eUML is a
model subsystem in ArgoUML, it's the alternative to the MDR model subsystem
(the one used currently by ArgoUML, see the ArgoUML architecture in the
eUML is implemented with the
"Eclipse UML2" project and
in part using the Eclipse Modeling Framework (EMF)
project, and supports
UML 2.x while
the MDR model is implemented with the Metadata Repository (MDR)
Project and supports UML 1.4.
The eUML model and the MDR model are both implementing the ArgoUML interfaces from
The eUML model is not finished:
- It does not implement all the required interfaces from org.argouml.model
- There is new functionality in UML 2 that needs additional interfaces in org.argouml.model
to be usable by ArgoUML's components
- There are places where UML2 elements are changed in behavior and semantics from the previous
Incrementally implement and improve the eUML model using the Eclipse UML2 and EMF projects.
Incrementally means that the implemented stuff from the model subsystem should be done to implement some
high level functionality in ArgoUML, eg: because you want to implement the possibility to create some
state in an activity diagram you'll implement what it requires in the model subsystem, then you could
test what you've done by testing that specific functionality in ArgoUML.
- Java SE
- Basic UML knowledge
- You will need to read the UML specification (the relevant parts of it), specifically the
Developer Contact: Bogdan Pistol
ArgoUML and UML 2 compliance level 0
UML 2 defines several compliance levels for uml-tools.
To fulfill the
compliance level 0, mainly classes and class-diagrams of uml 2.x must be
supported. these will be introduced to argouml by integrating a
amof2 will be used to load uml's metamodel and then act as the model repository
for ArgoUML. it stores the instances of the metamodel the user creates(classes,
to be able to handle any mof-compliant metamodel and make it available to
ArgoUML would raise many possibilities for creating and using
domain-specific languages. also it can be the base
for introducing UML Diagram Interchange to ArgoUML, because it's also a mof-compliant specification.
- 1st step: basic integration
Amof2 has to be integrated into argouml's tool-library and the
- 2nd step: amof2 interface
ArgoUML supports already two model-repositories. this is possible due to
an abstraction layer. the api from amof2 must be wrapped by this layer.
- 3rd step: gui binding
The needed ui-objects for creating, editing and deleting the level 0
objects already exist, as argouml supports their uml 1.4 siblings which
should be mostly the same on this basic level.
- 4th step: persistence
Amof2 understands xmi but can't persist files by itself. argouml's xmi
export and import interface must be connected to the xmi-reader and
-writer from amof2. also the file-format of argouml must be enabled to
save the xmi-data from the amof2-repository
Make the Executable UML profile work in ArgoUML.
There are several different aspects of this.
The most important ones are thought to be:
Improve ArgoUML to allow a profile to add the needed restrictions
to be able to work with the Executable UML profile.
Explore OCL to see if it works well enough as an action language
for Executable UML.
Depending on the result of the OCL evaluation,
integrate another action language geared towards Executable UML.
Integrate a compiler to compile Executable UML from within
ArgoUML with help in pin-pointing errors.
Integrate/implement an interpreter that executes a model and
visualizes states and state transitions.
Developer Contact: Linus Tolke
Improve a subsystem of your choice by solving existing issues
The issues database contains many bugs
and enhancement requests.
Go to the query page at
Issue tracking query,
and select a subsystem from the list below.
The task for the student is to solve
as much of these issues
within one subsystem
as (s)he can.
These are acceptable subsystems:
- Class Diagram
- CodeGeneration and ReverseEngineering
- Collaboration Diagram
- Cpp module
- Csharp module
- Deployment Diagram
- Module loader
- OCL and Constraints
- PHP module
- Property Panels
- Sequence Diagram
- State and Activity Diagram
- Usecase Diagram
Beware: This may seem less interesting than
adding one big new feature to ArgoUML,
but has the big advantage that
the work is broken in many small parts,
each of which are usefull to solve on its own.
No pressure for deadlines,
no disappointment if a project remains unfinished!
Developer contact (at least for most subsystems):
Michiel van der Wulp.
Create "Critics" for all UML well-formedness rules
Critics are ArgoUML's system of warnings,
i.e. when you break a rule of UML, then a warning will be generated,
much like warnings and errors used for source code correctness and style.
The UML contains the so-called "Well-formedness rules" (WFR),
written in OCL,
which specify constraints to the creation of model-elements.
ArgoUML currently contains an outdated set of critics,
from the days we supported UML 1.3.
These need to be updated to the UML 1.4 standard, and completed.
Developer contact: Michiel van der Wulp.
Support of parameterized classes (templates)
In UML, parameterized classes are used to model parameterized types.
This is somewhat similar to Java and C# generics and C++ templates.
ArgoUML doesn't support yet the modeling of parameterized classes and this is
causing it to be less useful for modeling in these languages.
This project would implement the GUI support for modeling parameterized
classes, since these are already supported in the model sub-system.
It will require working in the several presentation elements of the ArgoUML
GUI, such as the explorer pane, the class diagram and the properties panel.
Potentially interesting is the correct display of the parameterized classes
and of the bound elements (classes that are defined by defining actual types
for the parameterized class' parameters).
More details on suggestion:
- This project is
- The model sub-system support for parameterized classes are available
via the interfaces
of the package
- In the context of some work made previously to support the notation
of UML templates - the dashed rectangle in the upper right-hand corner
of the class symbol - it was considered interesting to explore this in the
scope of the GEF project.
#3802 for some reasoning and ideas related to this.
- A big part of this project is Java Swing work on top of GEF and
ArgoUML GUI classes.
- The proposal mentor will work in parallel ensuring that the code
generation modules will also support generics or templates.
Developer Contact: Luís Sérgio
Oliveira (user euluis in tigris)
ArgoEclipse is a project that integrates ArgoUML within the
ArgoUML's main panels (implemented in Swing): the explorer pane (top left), the diagram pane (top right),
the to do list pane (bottom left) and the properties pane (bottom right) are integrated in Eclipse's
Standard Widget Toolkit (SWT) and included in the Eclipse views, editors and dialogs
using the SWT_AWT
bridge (that makes possible Swing integration into SWT).
The Eclipse IDE can host ArgoEclipse as its plugin along with other plugins, but ArgoEclipse can also be used as a standalone
Rich Client Product (RCP) application.
ArgoEclipse uses mainly ArgoUML's Swing code as is and sparsely reimplements some Swing dialogs using SWT.
The suggestions marked with (*) are harder to accomplish.
- Reimplement the Swing dialog windows from ArgoUML using SWT/JFace
- Extend the org.eclipse.ui.PreferencesPages extension point and reimplement ArgoUML's settings
- Headless build for the plugin and the RCP application using PDE tools
- Reimplement the explorer, todo and properties panes of ArgoUML in SWT/JFace or/and redesign their appearence
- Add the ability to parse Eclipse Java projects and generate a UML model in ArgoEclipse
(ArgoUML is able to parse Java files from a filesystem location)
- Hook the editors/views to the standard global actions (print, delete, select all, undo, redo, etc)
- Add action bar contributions when the editor is opened: menu contributions, coolbar contributions with ArgoUML's actions
that should be available in that context
- (*) Add support for the ability to drag UML elements from the explorer pane and drop them on the diagram editor
- (*) Use the Eclipse Graphical Editing Framework (GEF)
to start the reimplementation of the diagram editor
- (*) Implement the support for multiple diagram editors
- Basic UML knowledge
- Java SE
- Eclipse Plugin Development Environment (PDE)
- Standard Widget Toolkit (SWT) / JFace
- Apache Ant scripts (this is required only if you want to include the headless build suggestion)
- Graphical Editing Framework (GEF) (this is required only if you want to include the reimplementation of the diagram editor with GEF suggestion)
Developer Contact: Bogdan Pistol
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.
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
There's also a more general list of development tasks which
have been suggested over time available in our
Job Jar which may offer additional sources of
and our bug database could be another source of inspiration.
How to fill in your application
In the Title, formulate your own title as a summary of what you will
accomplish in the project.
In the Abstract, describe what you plan to achieve in the project.
In the Detailed Description,
we suggest you use more or less the following template:
* General introduction
* Your plans for the summer
* Your experience. State specifically any previous experience with:
* ArgoUML (using or improving)
* Java, Eclipse
* Open Source projects
* Other programming languages or XML
* Details on the project you are suggesting. This includes:
* What the project is about
* Why this is important to ArgoUML
* How this is solved
In your plans for the summer,
mention where you will be working,
at home, in your student dorm, at your institution,
and what kind of computer and internet access you have access to there.
Tips for writting a good application:
- Subscribe to the dev mailing list and talk with us about your idea
- Before submitting your application to Google Summer of Code infrastructure, discuss and review with us your application, we will help you with suggestions and feedback
This page was last updated on
$Date: 2010-01-12 10:21:28 -0800 (Tue, 12 Jan 2010) $.
Back to ArgoUML Home