Last updated November 19, 2011 17:30, by javydreamercsw

Eidos UML Wiki

Reasons for a re-write for next version

We believe this code is in need of a complete rewrite, as opposed to some manner of staged improvement.

Stuff to think about

Questions/Issues for a rewrite. It is important that we spend some time thinking about issues that might effect a re-write. Please follow these links and contribute to the discussions taking place on these pages. If there are other issues that you think are important - add them! If you don't have access to edit or discuss these pages, please send your thoughts to "".

UML Coverage and Compliance

Is complete support for the entire UML (1.0, 2.0 or whatever) standard a primary objective of this module?
Our current aim is to provide 2.x support for the first release. Other details can be found on the UML Coverage and Compliance page, including a link to our discussion forum.

Engineering Workflow

Should the module presume that you design first, and then export to code. Should UML diagrams and code be updated synchronously? How important is reverse-engineering?

Suggestions for a testing regime?

Anyone? What do other Netbeans projects use?

Language Independence

Is it important that the we take into consideration the use of multiple languages when designing the module. Is Java only okay? Should multiple languages within one project be supported? Do we need to make it easy for a PHP project to integrate with the UML module?

Java-UML compatibility and how it might be dealt with

Annotations?, Javadoc?. Java is a subset of UML - hmmm.... :)

GUI Frameworks

The Netbeans Visual Library is the most obvious choice... any other suggestions?

Is UML a project type of its own?, or just a part of other Projects?

Should your standard Netbeans Java/php project have an option for creating UML diagrams within it? Should it be necessary to have stand-alone UML Projects or can we presume that coding will also, eventually take place after UML design?

Import Export

Which formats are necessary to be imported from, and exported to? XMI? JPEG? HTML?

Who can help?

Whilst there are at least a few of us dedicated to making this happen, this is NOT a small job. We can probably make use of 10-20% of the current code and algorithms. Please start by making suggestions and giving opinions on this wiki. If your not a member of the wiki and would like to have your say, or you can help with the development effort, say something on the mailing list (

Proposed Features

Keep in mind that this list is just an initial one pending discussion with the UML team.

UML as a feature of a project not a project on its own

Having the UML portion as part of the actual project instead of its own project and conversion between projects approach is part of the issue. You should be able to start an UML project on its own but turn it later into another type of project with UML support.

API for Languages

Providing some type of API from the UML core for the roundtrip engineering and then have modules for each language. Is better than current approach of one UML plugin per language.

Implementation of an in-memory model of the code

Its integration/synchronisation with the Netbeans IDE, and the interface between this, and the presentation model - Netbeans Visual Library is a great start, but its certainly not synchronous and there are other (gui) issues in here that will cause some 'interesting' problems.

Export Import

Ability to import/export from XMI and UML formats. This gets the plugin away of working on those formats internally complicating implementation.

Road Map

Phase I: Specification

  1. Collect feedback in forum topics from module developers (1 week : Finished)
  2. Finalise design goals (specification) based on group opinion in the forums and publish on wiki (Finished : see wiki)
  3. Feedback about final design goals from module developers, and perhaps make some alterations (Finished)

Phase II: Design

  1. Finalise design of APIs/interfaces that separate the repository and GUI sides of the module (Deadline: 27 February 2007)
  2. GUI and Repository internal design commences, lead by Javier and David respectively.

Phase III: Planning

Divide the implementation into smaller specific roles and spread them out amongst the team.

Phase IV: Implement

Some code already implemented. See here for up to date status.

Phase V: Branching in NetBeans Repository