eUML is the name of the Model Subsystem implementation based on the Eclipse UML2 plugin which currently implements support for UML 2.1.1. Although it is a prerequesite for UML 2.x support, there are many individual features of UML 2.x which require support in the GUI or other areas.
The bug tracking systems contain the most up-to-date information on the status of UML 2.x support. This page is only updated on an ad hoc basis. Please see the following:
Top level ArgoUML UML 2.x issue which has all other UML 2.x issues attached to it
(This currently just contains fragments from the dev mailing list and Bogdan's great status reports. This page needs rework, please help to organize and complete the raw material.)
Unsorted stuff from the dev mailing list
NOTE: Many different, unidentified, authors! Tom Morris has identified a few of the pieces that he recognizes, but there are no other authors, dates, or links back to the original threads. Please see http://argouml.markmail.org for the original discussions in context.
eUML does not depend on RCP. eUML uses Eclipse UML2 and Eclipse EMF which consists of a few jars that are self contained, there are no other references, in fact ArgoUML uses the eUML subsystem as is without any additional dependencies. More info about the eUML dependencies here.
I'm wondering if there are any way of retrieving from EUML an element by an Id. In ModelEventPumpMDRImpl there is a method with the following signature:
Object getByMofId(String mofId)
I need a similar method in ModelEventPumpEUMFImpl, but I don't know how to do it. Any hints?
You can use org.eclipse.emf.ecore.resource.Resource.getURIFragment(EObject) and org.eclipse.emf.ecore.resource.Resource.getEObject(java.lang.String uriFragment). An UML element in UML2 Eclipse implementation is an EObject. It can be uniquely identified by a uriFragment.
More details in the javadoc of Resource
(MarkMail link) Tom Morris Nov. 2007 - "All existing eUML work is fully integrated with the trunk in the source pool. There are both an Eclipse run configuration and an Ant target that can be used to start ArgoUML with the eUML subsystem instead of the MDR subsystem. To take it for a test drive, just select Run->"ArgoUML UML2-EUML debug" in Eclipse.
Bogdan did a bunch of work over the summer, but there's still lots and LOTS left to do to get ArgoUML to a complete UML 2.x implementation. You can get an idea of the state of completion of the eUML model subsystem itself by counting the number of occurrences of "TODO Auto-generated method stub" and comparing it to the total number of methods.
The model subsystem itself is just one part of the story though. One of the reasons OMG was so late with UML 2 (and took until UML 2.1.1 to actually get a usable implementation) is because they changed SO MUCH. About the only thing that looks anything like it used to is Use Cases (which were pretty simple to start with). Now, a lot of the changes are good, but the volume of them will make for a huge amount of work in adapting ArgoUML. All of these changes bubble up through the software layers from the Model API (which is loosely based on UML 1.4) to the application logic to the user interface (where we tend to use UML terminology to make it easy for the user to map things back to the UML spec). Supporting both UML 1.4 and UML 2.1.1, whether for a transition period or for the longer term, will introduce an extra level of complexity.
Upgrading UML 1.4 models from earlier versions of ArgoUML to UML 2.1.1 models is another facility which will be needed. Nothing has been done on that yet.
The UML 1.3 to UML 1.4 transition was a huge chunk of work and we STILL don't have some of the "new" UML 1.4 features fully implemented (e.g. Tagged Value types other than String), but that transition will look absolutely trivial next to what needs to be done to implement the changes for UML 2.x. The good news is that because the last transition was done relatively recently, the organizational knowledge about how to go about this is still fresh in people's minds.
In addition to determining the relative importance (and timing) of the UML 2.x migration, we also need to decide whether this is a one-way migration or whether there's a long term need for UML 1.4 support.
By the way, you mention "EMF & UML2" a couple of times, so just to head off any potential misconceptions, the implementation target is OMG's UML 2.1.1, not Eclipse's EMF or Eclipse's UML2 plugin. Those are just implementation details to get us where we need to go and won't be exposed to the end user.
(MarkMail link) Bogdan Pistol March 2008 - "Instead of estimating how much of the org.argouml.model interfaces are implemented by eUML, a better estimation is the current functionality of eUML in ArgoUML: what one can currently do with eUML in ArgoUML.
I suggest you to take a look at the source code (if you haven't done already) and run ArgoUML with the eUML implementation. Details about ArgoUML infrastructure and general architecture are in the cookbook (Moved to the wiki. See ArgoUML Design, The Big Picture). You should read the it (or the relevant parts of it). If you have any problems don't hesitate to ask for help.
A summary of the current functionality of eUML in ArgoUML is:
- in the Class diagram you can't create an operation for a Classifier, you can't create an enumeration, a stereotype, a signal or an exception - in the Use Case diagram you can't create includes or excludes
in the class diagram and the use case diagram: - you can create the elements not listed in the things you can't do above (so, you can create classes, interfaces, use cases, actors, etc) - create attributes, associations (bidirectional or unidirectional) but these can behave a little different from the MDR implementation - save & load the project (XMI + diagrams) - undo & redo - this is not complete, it needs to hook with ArgoUML's undo/redo mechanism.
The eUML model will send event notifications of the model changes.
-> Where are all the Modeling constructs defined by UML ( packages, components, dependency, class, Interface, etc )
The UML model constructs should be defined by the modelling subsystem of ArgoUML. Every model subsystem should define it's own modelling constructs. MDR defines its owns and eUML likewise. For example in org.argouml.model.CoreFactory interface there is a createClass( ) method that should create the Class modelling construct. The MDR model subsystem implements the createClass( ) method and the implementation creates a org.omg.uml.foundation.core.UmlClass that is used as a UML Class modelling construct for the MDR implementation while the eUML model subsystem creates a org.eclipse.uml2.uml.Class (implementing the same createClass( ) method) that is used as a UML Class modelling construct for the eUML implementation.
As you can see, the eUML subsystem uses under the hood the Eclipse UML2 project to create modelling constructs.
Look at the Factory interface and you can observe all its subinterfaces that are responsible for creating UML modelling constructs. It's the job of the model subsystem to implement these interfaces and actually create some modelling constructs to be used further in the same model subsystem.
-> is it like upgrading from UML 1.4 -> UML 2.x ???
Yep, because eUML uses Eclipse UML2 that makes it UML2.x compatible. The current usable model subsystem (that implements the org.argouml.model interface most completely) is the MDR model subsystem that is UML 1.4 compatible. So completing the eUML implementation would upgrade ArgoUML from UML 1.4 to UML 2.x
-> What main role a student has to play in this project ? ie. implement Model Subsystem as much as its possible or what ?
The student should implement the model subsystem's interfaces, but this should be done incrementally. Incrementally means that you will implement what is needed in the model subsystem for a specific functionality (eg. You want to extend eUML so that in the use case diagram should be possible to create a "use case" and an "actor" and an "association" between them, this requires that the eUML model subsystem should be able to create use cases, actors and associations and glue them together)
In conclusion eUML will use standard mementos, and all other functionality should be added in ArgoUML.
History: Bogdans GSoC Status reports
eUML Weekly Report - Week 12
From: Bogdan Ciprian Pistol; Date: Aug 20, 2007 11:07:03 am
Planned
- finish the tests
- finish Classes diagram and Use case diagram
create the Demo of the eUML Subsystem
Achieved
removed the plugin dependencies from EMF&UML2 Eclipse plugins and selected some jars from the plugins to be part of eUML's classpath. Now it's possible to use ArgoUML with eUML without any additional dependencies.
defined a general command stack that was overlapping with ModelMementos and UndoManager, and at Tom's and Bob's suggestions I use ModelMemento notifications but I need to extend the UndoManager with additional functionality.
- general review of eUML with minor changes where there was needed (use the editing domain, repair bugs, etc)
- fix the XMI ids retrieval functions
- fix loading files: now loading a file works with XMI and diagrams (zargo)
- workaround for association end to visually show the navigability correctly because the isNavigable property is not properly use by ArgoUML (I appears that only in UML2.x)
- fix some elements and functionality from Class Diagram: comments, attributes, contextual menu (right click menu), deletion of elements from the model, using generalizations
- fix some elements and functionality from Use Case Diagram: includes, excludes (but not quite functional yet).
- created a demo ArgoUML with eUML model subsystem (I did this to demonstrate the full capabilities of undo/redo of eUML, and because GSoC deadline is today I don't do it the right way -- mementos, etc -- instead I use a modified ArgoUML environment)
- wrote a presentation of the ArgoUML demo (the email on the dev list about the demo)
JUnit statistics (rHEAD = r13416)
- Tests: 631 Errors: 20 Failures: 250
Some of these tests fail because are using stereotypes (creates tests), use operations not yet implemented or use reflection on a list of UML1.x elements (so they fail on some element not available in UML2.x, or with its functionality changed)
To do
Extend the UndoManager and fully use the capabilities of eUML's command stack
write & tweak unit tests
- implement Cut, Paste, Copy
- implement the correct deletion of elements (deletion is possible, but the elements that ArgoUML expects to be deleted at the same time an element is deleted is not implemented)
eUML Weekly Report - Week 11
From: Bogdan Ciprian Pistol; Date: Aug 13, 2007 11:56:28 am
Planned
- test units
finish Facade & CoreHelper
- the demo with the current features of eUML
Achieved
I tweaked the existing unit tests and added new methods to test additional functionality (these new tests are general, not eUML specific - except for a test in ModelEventPump wich uses "ownedAttribute")
- Fixed some bugs that I caught during testing and implemented a few methods that I needed.
JUnit statistics (rHEAD = r13311)
- Tests: 631 Errors: 21 Failures: 259
To do
- finish the tests
- finish Classes diagram and Use case diagram
- create the eUML demo
eUML Weekly Report - Week 9 and 10
From: Bogdan Ciprian Pistol; Date: Aug 7, 2007 7:51:42 am
Sorry for the combined reports, I tried to implement all the features planned for week 9 last week, but it took a lot longer and I tried to finish as quickly as I can and then do the report.
Planned
The relatively easy task (IMO) to complete Facade, CoreFactory, ( :) it wasn't that easy, lots of methods)
- junit tests: I'll use the already existing tests to have a statistics of how much of eUML passes the tests (As Tom suggested I'll use the junit tests to have a quantifiable amount of functionality reported)
Achieved
Completed CoreFactory
Completed a good part of CoreHelper
Created a new ChangeCommand that updates its label based on some objects, so undo now has a descriptive string about every command that changes the repository
Enhanced ModelEventPump to pump CommandStack events and label updates events for ChangeCommand
a few minor methods in Facade and ModelManagementHelper
To do
- I want to make a demo with the current features of eUML
finish CoreHelper
- Implement Facade
- test units
eUML Weekly Report - Week 8
From: Bogdan Ciprian Pistol; Date: Jul 25, 2007 3:26:31 am
Achieved
- synchronized the event pump (thread safe)
- fixed some bugs that got in the event pump
- fixed the undo/redo notifications
added DeleteInstanceEvent and AttributeChangeEvent for model event pump
- documented myself (debugging, comparing UML2.1.1 with UML 1.4) about the changes of attribute (property) names of UML elements. There are changes, but roughly there are lots of names unchanged. IMO changes in ArgoUML where the property names are used would be the best solution, this could be configurable based on UML 1.4 or 2.1.1.
To do
The relatively easy task (IMO) to complete Facade, CoreFactory
- junit tests: I'll use the already existing tests to have a statistics of how much of eUML passes the tests (As Tom suggested I'll use the junit tests to have a quantifiable amount of functionality reported)
eUML Weekly Report - Week 7
From: Bogdan Ciprian Pistol; Date: Jul 16, 2007 2:01:41 am
Planned
Implement the ModelEventPump
- Solve the property names problems
Test the undo/redo features with the ModelEventPump
Continue the adaptation of all other UML elements to use a ChangeCommand
Achieved
- I debugged the ArgoUML application quite a lot to find out how are used the property names
I tried several methods to deliver events from the eUML model: an Adapter for every UML element, a global adapter for all the UML elements, and (the actual method used now) a ContentAdapter that adapts itself to listen all the new UML elements added to the model. So, if a UML element is created it will not be listened, but when it will be atached to the model element the ContentAdapter will adapt itself to listen the newly added UML element.
I implemented the ModelEventPump to use this ContentAdapter (named RootContainerAdapter in eUML) and committed this final implementation.
I tweaked the ModelEventPump to listen efficiently a class of types and subtypes of model elements. It uses a Class.isAssignableFrom(Class) method to determine if the UML model (the notifier) if compatible with the class of objects listened by the PropertyChangeListener.
- I've done some changes to XMIReader/Writer to use the editing domain and added undo()/redo(), canUndo()/canRedo() methods to EUMLModelImplementation
Problems
I have a big problem with undo/redo notifications in the ModelEventPump. If the eUML model changes, then some notifications are fired, if I undo/redo a command no notifications are fired (the eUML model is changed
- I verified by serializing the model and the XMI confirms the undo/redo works). I already asked for help on the Eclipse UML2 news forum.
- Figure out if I can somehow map automatically the property names of UML 1.4 to UML 2.1.1, I should search a little bit more before I decide to hard code the mappings. Or it would be a better solution to change the code in ArgoUML to use the new property names. I don't know yet.
- The org.argouml.model interfaces should be extended to support additional features like undo()/redo(), canUndo()/canRedo()
- The serialization of a model is throwing an error. I will investigate further.
To do
Solve the undo/redo notifications in the ModelEventPump
- Investigate more the property names problems
Continue the adaptation of all other UML elements to use a ChangeCommand (I always defer this because I do not consider it a priority, when all the infrastructure will be ready this part will be quite straightforward.)
eUML Weekly Report - Week 6
From: Bogdan Ciprian Pistol; Date: Jul 11, 2007 12:40:23 pm
Planned:
Commit the work based on ItemProviders:
that sort of implementation uses some EMF.edit commands like SetCommand, AddCommand or CreateChildCommand etc for manipulating the features of modelling elements with support for undo/redo
also, ItemProvider is an observer of the UML items (the notifiers), and provides for Eclipse framework a label, a property descriptor, etc and are supposed to be easy to use in a possible future version of an Eclipse GEF editor
study & search a method to implement the ModelEventPump
Achieved
I found a generic ChangeCommand that can be used without all the ItemProvider hassle, so this would allow the implementation not be to Eclipse specific. I asked for support on the Eclipse UML 2 news forum and I got a confirmation that it's an alternative to use the ChangeCommand directly on the UML elements rather then ItemProviders with their commands (Set, Add, etc). This command stores the history of all changes to the model, and can undo and redo in it's history.
I implemented and committed a working implementation of the Association UML element using the ChangeCommand.
I started studying the ModelEventPump mechanism from ArgoUML and I sketched an implementation (this is needed to test the actual consequences of undo/redo of model changes to ArgoUML)
Problems
I have trouble with the property names of the events which should be fired by the ModelEventPump (I'll send a separate message about these problems)
Plan for the next week
- Solve the property names problems
Implement the ModelEventPumpEumlImpl
Test the undo/redo features with the ModelEventPump
Continue the adaptation of all other UML elements to use a ChangeCommand
eUML Weekly Report - Week 4 and 5
From: Bogdan Ciprian Pistol; Date: Jul 3, 2007 10:53:29 pm
Sorry for the late reports. In week 5 didn't worked much because I left Iasi (university town) to go in Mangalia (my home town) where i'll stay for the summer.
Achieved
I spent quite a lot of time figuring out the way in which the model subsystem implementation should use an EditingDomain (which tracks changes to the model, and so it can support undo and redo).
I presumed the UML model subsystem could have multiple instances (one for each editor - in the future would be desirable to have multiple editors in the same application). So it will be a 1-1 relationship between an eUML instance and an editing domain. Multiple instances of eUML will have their own EditingDomain, so every eUML could have an independent undo/redo stack.
There is a problem with the current Model.initialise(String) initialization and Model.setImplementation(ModelImplementation). In the current form it only allows one implementation of Model to be used as the Model. IMHO one should have the possibility to create multiple instances (how many it needs) of the implementation of the Model (maybe to support multiple editors in the same application).
- I debugged the ArgoUML application to see how a model element is created and used. I saw that when the user clicks, on mouse press event the element is created (without an owner), and then on mouse released event the owner is set. Why isn't the owner set also when the element is created?
The eUML should be able to find out if it's inside an Eclipse plugin or in a stand alone application. In the case of a standalone application eUML should somehow know the location in the filesystem of the "org.eclipse.uml2.uml.resource" jar plugin. So I thought that a system property (System.getProperty(String key)) would be appropriate to define the path of the jar. So if this property is defined then it's the case of a standalone application, else it's an Eclipse plugin.
To do next
continue the current implementation of the EditingDomain and submit the code ASAP
- figure out the singleton pieces of the eUML implementation in the case of multiple eUML instances
Problems
I had some trouble understanding the relations between some classes in org.eclipse.uml2.common.edit.command and EMF commands and how actually they are used in conjunction with a model through implementation of EditingDomain (AdapterFactoryEditingDomain), and some other few classes. All the trouble had the cause that the classes have no javadoc.
eUML Weekly Report - Week 3
From: Bogdan Ciprian Pistol; Date: Jun 19, 2007 3:23:43 pm
Objectives
- implement the basic Factory.createXXX methods
adjust my plan to be more productive & to better identify my objectives
- implement identification methods "isAXXX()" for UML elements
figure out an undo & redo mechanism
- figure out the event notification mechanism
Achieved
- I realised that the UMLAdapterFactory.createXXX() methods shouldn't be used, instead an undo/redo mechanism should be at the model implementation level and the creation of model elements should be done with this mechanism
I analysed the EMF.Edit mechanism for: Command, CommandStack and Notify mechanisms; I believe that instead of pure UML superstructure elements we should use Item providers that will adapt the model elements supporting also undo/redo and centralized notification.
- I tested the EMF.Edit implementation from Eclipse UML2, I need more tests, but I had achieved to actually undo my command applied to the model.
I wrote some documentation about the eUML model subsystem and the Eclipse UML2 plugin: http://euml.wikispaces.com/ This is a wiki, anyone has write access, if you want to add something feel free to do so. I am notified every time someone makes a change so I can review it.
Objectives for the next week
- implement the basic EMF.Edit mechanisms
implement some model element creation commands that will support undo/redo & notification
eUML Weekly Report - Week 2
From: Bogdan Ciprian Pistol; Date: Jun 12, 2007 7:11:46 am
Objectives
- read Superstructure (Classes chapter)
- identify changes from UML 1.x
- implement the basic Factory.createXXX methods
adjust my plan to be more productive & to better identify my objectives
Achieved
- read the Classes chapter from Superstructure - it contains a lot of Infrastructure::Core
I identified a few changes from UML 1.x in the "Changes from previous UML" (Only for AssociationEnd, Feature, StructuralFeature are specified changes) - this is only in the Classes chapter
fixed some minor settings for the configuration launch (the b001 branch)
Objectives for the next week
- implement the basic Factory.createXXX methods
adjust my plan to be more productive & to better identify my objectives
- implement identification methods "isAXXX()" for UML elements
eUML Weekly Report - Week 1
From: Bogdan Ciprian Pistol; Date: Jun 3, 2007 4:37:39 pm
Objectives
- Set-up the environment
- adapt the my current plan to the current time line, identify and plan the next milestone
- Start implementing the first basic UML elements so that eUML works
Achieved
I started my branch on branches/gsoc2007/b001/ and created the initial project with the the help from Tom Morris that started the eUML model.
- Read the Infrastructure spec.
Problems
- I realized that my understanding of UML concepts has some lacking. So I printed UML2.1.1 Infrastructure and read. This delayed all other objectives.
- There are problems with model-mdr in Eclipse 3.3, (compiler errors that don't show up in Eclipse 3.2). This does not affect eUML.
Objectives for the next week
- adapt the my current plan to the current time line, identify and plan the next milestone
- Start implementing the first basic UML elements so that eUML works
- identify changes from UML 1.4 to 2.1.1 in the API