The Eidos UML project is a side project of the Netbeans UML plugin. It aims to redesign the UML plugin from scratch, to make better use of modern software engineering practices, and the powerful Netbeans platform. Some code from the current plugin will be reused, but the underlying structure of the module will be greatly simplified and improved.
Note: There is now a discussion on why the UML plugin was removed, as well as when UML support is likely to be re-instated. See here: http://wiki.netbeans.org/Talk:EidosUML. Removal occurred prior to 18 Apr 2011, causing a level of confusion in the community as to both the reasons, and the 'replacement' of the open source plugin with the Community Edition of a commercial product that did not include round tripping.
Reasons to Rewrite
The Eidos team believe that the UML plugin is in need of a complete rewrite, as opposed to some manner of staged improvement. Some of the problems we see with the original design include:
- Use of XMI pervades the code Whilst the module should DEFINITELY support XMI export/import and perhaps use it for persistence, the current modules use of XMI throughout the codebase makes a good separation of persistence from 'business logic' very hard to achieve.
- Use of an un-typed signalling mechanism And use of Strings and integers 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.
- 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. The code makes little or no use of Netbeans Lookups - one of its most powerful features.
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.
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 15-30% of the current code and algorithms. If you would like to help with development, or just give us your thoughts the Eidos team can be contacted, c/o email@example.com
Phase I: Specification
- Collect feedback in forum topics from module developers (1 week : Finished)
- Finalise design goals (specification) based on group opinion in the forums and publish on wiki (Finished : see wiki)
- Feedback about final design goals from module developers, and perhaps make some alterations (Finishes Monday 24th January)
Phase II: Design
- Finalise design of APIs/interfaces that separate the repository and GUI sides of the module (1 week)
- 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
WRITE SOME CODE ;)
Phase V: Branching in NetBeans Repository