Parallel Editing of RSA models managed by DM (4.0)?
Hi!
It is quite easy to find documents on how DM can be used for reviewing/commenting an RSA model uploaded to DM. As we understand it DM 4.0 will have extended support for also editing/managing the model on the DM server, but we have not really found any documentation specifying what DM 4.0 will support. We tried to test DM 4.0 RC2 but experienced some defects preventing us from testing the capabilities. This concerns mostly models managed by DM, ie not the case where you just import a model but rather the case where you upload a model from RSA to DM and from that point uses the version stored on DM as the master. Typical questions we have: 1. If designer A uploads a model with diagrams, can then designer B connect to DM with RSA and start editing the model, for example change a diagram? 2. How is then conflicts handled - what happen for example if both try to change name of a class or rearranges symbols on a diagram? Are there any significant differences compared to how conflicts are handled compared to when using for example RSA with RTC. 3. When working with a model managed by DM how will then changes done by others be loaded? Will it be handled by "Design Changes" similar to "Pending Changes" for RTC, ie that the user can control when to accept the new changes? On what level will the changes be reported, for example one change for each UML class changed? Support for merge with local changes? 4. Which parts of the model will be editable in a DM web client? Will it for example be possible to add classes, edit attributes, change tagged values in stereotypes and similar tasks? 5. Loading a large model in RSA can take quite long time. What will happen when you start RSA with a workspace containing a model managed by DM? Will you then automatically get the latest version, or can you control that with the "Design Changes" view? If someone has good answers to the questions above, or can provide with references to a good article/webpage it would be highly appreciated. Please also tell us if we have totally miss understood what DM 4.0 will provide. |
4 answers
These are all good questions and they do align well with the 4.0 vision. The answers to most of them are captured in public work items on jazz.net but going through all of them can be quite time-consuming task. I'll try to summarize this information.
1. If designer A uploads a model with diagrams, can then designer B connect to DM with RSA and start editing the model, for example change a diagram? Yes. 2. How is then conflicts handled - what happen for example if both try to change name of a class or rearranges symbols on a diagram? Are there any significant differences compared to how conflicts are handled compared to when using for example RSA with RTC. RSA DM 4.0 uses exclusive locking mechanism within workspace so only one of them is going to be allowed to proceed on a resource with contention. If they are working on separate workspaces then they will both be able to proceed but merge will be required when/if the changes are propagated from one workspace to another. That merge mechanism is currently basic. 3. When working with a model managed by DM how will then changes done by others be loaded? Will it be handled by "Design Changes" similar to "Pending Changes" for RTC, ie that the user can control when to accept the new changes? On what level will the changes be reported, for example one change for each UML class changed? Support for merge with local changes? There is no control for incoming changes - you are always dealing with the latest in the workspace. However, when you are working on separate workspaces you control when to merge the content. 4. Which parts of the model will be editable in a DM web client? Will it for example be possible to add classes, edit attributes, change tagged values in stereotypes and similar tasks? Currently you can edit model element's properties through form UI. You cannot edit diagrams (the graphical part, you can edit properties). 5. Loading a large model in RSA can take quite long time. What will happen when you start RSA with a workspace containing a model managed by DM? Will you then automatically get the latest version, or can you control that with the "Design Changes" view? Model is not in the workspace - it is in RSA DM repository. When dealing with DM managed model the elements are loaded as they are needed. |
|
Thank you very much for your information, everything is much more clearer now. We experienced some errors when testing RC2 (for example 27456) so we will continue our tests when a new version is available on jazz.net
What is the planned release schedule for posting DM on jazz.net? Looking at RTC one can see that for example RC3 ended May 4th but has not yet been published on jazz.net. On the other hand there are some outstanding defects so I fully understand if you decide to wait with publishing new versions until it has been stabilized. Are there any current plans on when the final DM 4.0 should be released - could not really find that out by looking at the timelines in RTC. One other concern I have concerns performance for DM managed models. I know it takes quite long time to import a model, but what about working with a model stored in DM. I am mostly concerned with the issue when someone is located far from the server with long response times and/or a slow connection. |
|
Started to think more of the locking mechanism. How will the other user detect the locking (because someone else is editing the model or has saved it)?, I could imagine some different solutions
1. Can't load - the other user can't load the model at all if someone else currently has loaded it (and possibly have some unsaved changes) 2. Can't write - the model becomes read only only if someone else saves changes or have unsaved changes 3. Can't save - you notice it first when you try to save that it is locked, and then you need to reload the model and discard your changes As I understand it the locking will concern the whole workspace/model, and not on a lower level (element/diagram/package). br Erik
|
|
Actually, the locking is done on lower level - class, package, diagram, etc.
It is detected on attempted locking or editing action. The user is simply prevented to obtain the lock and notified who has the lock at the time. So it is essentially your bullet #2: cannot write to documents locked by someone else, except that it is not the entire model that is read only but rather just affected elements. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.