Skip to main content
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.

  • Problems with original design
    • Use of XMI as its canonical source Whilst the module should DEFINITELY support export/import to/from XMI - within the UML project there are many better alternatives for persistence. The XMI implementation pervades the current code and makes a good separation of persistence from 'business logic' very hard to achieve.
    • Use of an un-typed signalling mechanism And use of Strings instead of making use of Java's strong type enforcement. This seems to be a lay-over from the code's previous C++ implementation, but to be honest I don't think its an acceptable approach in a modern program.
    • Too many interfaces and probably too many classes as well Its possible that the use of one interface per class was due to previously used test code (I know this has been done historically). I also believe this is considered "good practice" by some, but personally I strongly disagree. Again, happy to elaborate if anyone wants to know more.
    • The general disconnect between the 'original' design vs one that could have been purposely built to run within the Netbeans Platform Whilst its theoretically possible to port any code to Netbeans, there are some fundamental implementation differences that are quite obvious here.
    • As a group we cast no aspersions on the original designers But it is clear that software engineering practise has changed since the original design of this code. It is also clear that the current implementation suffers from the unavoidable legacy of its C++ past. Unfortunately, the result is something that cannot simply be improved - its time to move on.

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


Please Confirm