|Tom Morris||May 28, 2009 9:37 am|
|Linus Tolke||May 28, 2009 10:16 pm|
|Luis Sergio Oliveira||May 28, 2009 10:44 pm|
|Luis Sergio Oliveira||May 28, 2009 10:52 pm|
|Bob Tarling||May 29, 2009 12:31 am|
|Bob Tarling||May 29, 2009 12:47 am|
|Tom Morris||May 29, 2009 7:43 am|
|Tom Morris||May 29, 2009 8:24 am|
|Tom Morris||May 29, 2009 8:29 am|
|Linus Tolke||May 29, 2009 8:45 am|
|Subject:||[argouml-dev] Model API (was Tom's UmlFactory vs Eclipse UMLFactory)|
|From:||Tom Morris (tfmo...@gmail.com)|
|Date:||May 28, 2009 9:37:37 am|
Perhaps the use of my name was only to catch my eye so I'd be tempted to respond (in which case it worked!), but just to set the historical record straight, the Model API was defined long before I joined the project.
As I understand it, it was created as a first step to isolate direct access to the Novosoft UML 1.3 library (NSUML) which was scattered throughout the code, in preparation for the move to UML 1.4.
My major contributions were the UML 1.4 MDR implementation with Ludovic, eliminating duplicate methods, extending the API to support UML 1.4 functionality, beginning to extend it to UML 2.x, deprecating obsolete methods, etc. In other words, maintenance and cleanup of what was, for the most part, already defined.
Because stability of the API is key, I did *not* change a lot of things which arguably need fixing. If anyone is going to seriously consider major compatibility breaking changes, I'd recommend starting fresh with a clean sheet of paper, probably with an API largely machine generated from the UML metamodel (which would, of course, lose all your UML version isolation/compatibility).
Some other things that need changing (but aren't worth the cost):
- make the API more object oriented. The current "every element handle is just an Object" style is a hack - make the API more granular. Having huge interfaces like Facade is crazy. - make the API definition interface only with no required concrete classes
Something that I would like to see fixed to help with the migration to UML 2.x by allowing both UML 1.4 and UML 2.x models to be open is:
- support multiple loaded Model subsystems which can be selected at runtime on a per-project/model basis
Although all my major contributions are EPL licensed now, I'd be willing to help collaborate on a BSD licensed version of the API which supports this last goal (as well as needed UML 2.x extensions, of course). That would allow Model subsystems which are written for ArgoUML and those written for ArgoEclipse to continue to remain compatible.