|
| Re: State of Papyrus compare in 2022 [message #1853297 is a reply to message #1853268] |
Mon, 27 June 2022 07:00   |
|
I know what Papyrus Compare does. But what is Papyrus Compare good for?
The same question for LieberLieber LemonTree or other similar add-ons.
I am using Papyrus since version 0.7 and used Topcased since version 2 point something before. I use both with models shared among several modelers being altered concurrently. More than 15 years by now. Never had a need for a graphical model compare.
What is Papyrus Compare good for?
Is it a work-around for inadequate model structure or for lacking governance.
/Carsten
|
|
|
|
| Re: State of Papyrus compare in 2022 [message #1853307 is a reply to message #1853302] |
Mon, 27 June 2022 12:49 |
|
Hi John,
you can split the model at each package/model into sub-models via context menu -> Model refactor -> Create Submodel within the Model Explorer. The model I am currently working on consists of some 300 sub-models. I expect a figure between 2000 and 3000 if it is finished.
Second factor is to introduce a model breakdown that facilitates modelers after having created sub-models to work without interfering each other. Another factor of it is planning the tasks to build the model.
So it is about structure, planning and governance.
/Carsten
|
|
|
| Re: State of Papyrus compare in 2022 [message #1853309 is a reply to message #1853268] |
Mon, 27 June 2022 13:29 |
|
Hi John,
on CDO in my experience
+ real concurrent modelling -- no task planning required to not interfere
+ no merge conflicts -- transactions based
- really bad baseline support -- technically merely a database snapshot
- no support for releasing model parts -- one big pile or how to prove a part of the model has not been altered after release?
- no commit messages -- how to bind changes to review reports/tickets/tasks?
- performance issues
All in all I personally prefer GIT on models split into a sufficient number of sub-models or even separate linked models.
/Carsten
[Updated on: Mon, 27 June 2022 13:51] Report message to a moderator |
|
|
| Re: State of Papyrus compare in 2022 [message #1853314 is a reply to message #1853309] |
Mon, 27 June 2022 16:32 |
 Oliver Gardiner
Messages: 50
Registered: May 2014
Location: Oxford, UK |
Member |
|
|
FWIW, I'm in exactly the same position as John - we have a number of data architects working on a reasonably large class model. Initially, we subdivided the model into domains but we really want to be in a position where different architects can work in the same domains without tripping over each other. We looked at CDO but a) as Carsten observes, that doesn't really provide the features needed for true collaborative development, and b) requires an install of a CDO server in a network accessible location - and that's not always easy on a corporate network. Git does support collaborative workflows really well and secure cloud repositories are widely available, and the platform is also very familiar to developers.
But... a collaborative Git-based workflow does require a tool that can compare and merge branches, with regard to both the model and the diagrams. Papyrus Compare clearly is intended to support this. I would in no way want to criticise the community for developing Papyrus Compare and it is a tool that shows real promise. However, in practice, we found it just too hard to use, partly because it is very unclear how to identify and resolve "real" conflicts (I think quite a lot of the work requires filtering the copious output from EMF Compare into something that makes sense to a developer), and partly because we found it very difficult to create a repeatable merge process that didn't end up with the model being in an unusable state. It may well be that our difficulties were down to our mistakes but I'm not convinced they were and, in any case, that would point to some significant usability issues that would probably seriously limit its application.
Currently, we get our Data Architects to work in separate branches and then copy/transcribe their works in progress into the master branch when it makes sense - not ideal but has proved to be the most workable approach for us, but we may go back to splitting the model as well. Personally, I think Papyrus is an amazing tool that is invaluable to us, but making the Compare feature work simply and reliably would be a game changer for us.
Regards,
Oliver
|
|
|
| Re: State of Papyrus compare in 2022 [message #1853319 is a reply to message #1853314] |
Mon, 27 June 2022 17:49 |
|
Hi Oliver,
if you have to work on a single, flat, atomic class model you either go CDO or sequentialize access.
BTW, with 'flat' in this context I classify class models without hierarchies, implying without locality. These kind of class models are hard to create, review and maintain anyway. That is why a strongly advise to avoid such class models.
SAP R/3 maintenance suffers hard from a historically grown flat data model. SAP learned its lessons and avoided it with S4/HANA
With SASPF mainly SAP as contractor restructured a historically grown flat data model used by some 1800 applications used by the German Armed Forces containing some 30K tables restructured. Cost point was above EUR 2 billion.
/Carsten
|
|
|
|
| Re: State of Papyrus compare in 2022 [message #1853326 is a reply to message #1853322] |
Mon, 27 June 2022 21:29 |
Oliver Gardiner
Messages: 50
Registered: May 2014
Location: Oxford, UK |
Member |
|
|
Many thanks - that is all eminently sensible and, yes, our modelling is very structured so lends itself to being managed as sub-models. Indeed, when we set it up that way initially we had hoped to combine that approach with Papyrus Compare but quickly came unstuck. We then moved to a single file containing the whole Package hierarchy in the hope that this would work better with Compare but are now considering going back to the sub-model approach. Rest assured that I am no fan of monolithic models, though!
I have tried a few tools in my time and I certainly agree that they are tricky things, so I have always been impressed at how the Eclipse projects have demonstrated the viability and benefits of a ground-up MOF based approach. I also appreciate that Compare/Merge is probably one of the hardest things to make work given the nature of the underlying XMI. Personally, I have not come across another tool that gets even remotely as close as Papyrus Compare in this regard - Atlova's UModel was, I think, the best commercial Compare/Merges I found but it was still pretty poor. I guess that thing that feels a slight shame is that, despite the intrinsic difficulties, Papyrus Compare seems so close to being great.
All that said, we still find Papyrus to be a great tool and certainly the approaches discussed here are entirely workable.
Regards,
Oliver
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03521 seconds
] 
Search
Help
Register
Login
Home
