Community
Participate
Working Groups
Created attachment 223829 [details] Additional analysis info. The PapyrusTutorial_CollaborativeWork_v1.0_d20110727.pdf describes how you can split models into parts, and why a user would like to do so, for some listed reasons. One reason _not_ mentioned in your .pdf analysis is reuse. (and safe reuse) Example: You decide to try out the Papyrus tool, your start building a model which grows into a larger model, other units close to you get interested in it, and like to try it out too. They would, of course, like to reuse as much as thy can from your work. Obvious things to reuse are global datatypes and interface declarations. So what do you do: You re-factor out reusable stuff from your model into separate "parts" so that they can be imported=reused by others. As you have seen in earlier bug reports from me you _can_ import such system parts into your own model/product, and reuse these model parts. (which have some problems, of course, as listed in earlier bug reports) The thing here is this "unsplitting" of a model, as described on slide 16 in the PapyrusTutorial_CollaborativeWork_v1.0_d20110727.pdf There is no explanation why "unsplitting" a model would be useful. There is a piece of analysis info missing here... The real problem with this is that if someone deliberately or accidently happens to "unsplit" a model part that have been reused by others, this model part get "sucked into" the originating model, you decide (in the menu for it) to delete the "unsplitted part" and right after that all other models reusing your "part" will crash fatally. You may also decide to _not_ delete the "unsplitted part", but then you will suddenly get duplicated copies (= different versions) of this "part" across your modelled product structure. So... When you decide o refactor out a cross-product reusable "part" of your model there should be an option to auto-convert this "part" into into an inported "part" in the model it was exported from, to prevent accidental "unsplitting" of the originating model. This would then mean that users could safely refactor out reusable stuff from a model into a separate project, for _safe_ reuse somewhere else. Attached is some additional analysis info on this.
I understand your point and agree that it woud be helpfull to support the reuse scenario you ar suggesting. COnsequently, I rennamed the task in this sense. However, I disagree with the proposal to enable to use the control to achieve that purpose. If you uncontrol a resource (i.e., unsplit) it is under your responssability and parts of model that are under control (splitt) is for the purpose as denoted in the document you are referring and this mechanism was not designed to enable reuse as you suggested. Airbus wanted this mechanism for enabling different teams to work concurrently on different parts of a ame model.
The rephrased title of this Bugzilla report indicates that its main message has been misunderstood. I'm rephrasing it in accordance with what actually is requested. It's not a request for export but to refactor out for reuse, initially similar to "control" in its mehanics, but complemented with additional mechanisms to ensure a safe reuse and for supporting very-large-scale development of multiple products. I understand the simple mechanics of the control/uncontrol functions. I have used it to "recactor" for "reuse" of parts between projects in my Papyrus tests, because it currently is the only way to split a model in Papyrus, so this is the function I was forced to use. I have also studied the more finer-grained control in EMF tools. I also understand why any/all users of Papyrus would need to split models using "control", since storage in one file prevents real collaboration and will not scale above smaller experiment projects. What I do not understand is why anyone ever would like to uncontrol/unsplit a part of the model which may be reused somewhere else, hence the proposal here to automatically convert it into an imported model part right after it has been controlled. ...and if someone uncontrols a part without deleting the original files then he/she would end up with two copies of the same thing, which is exactly what must be avoided here. ...just like we need to avoid more crashing models in future use. I didn't say that "control as designed" should be used to achieve what is requested. There should be a separate button/menu for this, obviously implemented by a separate piece of software. ...which is the same for the "export" you refer to, which not is supported today either and would need a separate meny/software too. But... Export is not is what is needed here, since it, as the name suggests, only would create a separate copy of what is exported. This is no good, since what we need here is to ensure "one fact in one place", since creating copies all over the place does not scale. What is needed is refactoring out a part of the model into a new and standalone model, to be stored in a separately config managed project, available for a safe and system-wide reuse in larger scale, where the originating model then imports! this refactored-out package. Model artefacts typically necessary to refactor out are common interface/signal declations and datatype declarations. The "control" function in Papyrus actually supports the initial part of such type of "refactoring out", that is, it is possible in Papyrus today to split out an individual package as a separate model in a separate project, where the model is stored in its separate file/-s. This Bugzilla report is about what is needed to happen after! "control", that is, which additional fuctionality that must kick in right after the refactored-out package has been physically moved into separate files. The solution in software, most likely, requires very little effort. When using the "control" function in Papyrus today it only splits one model into separate files, where the controlled part still is part of the originating model as a "packagedElement". What is needed is to "refactor out" a package into a standalone model and then turn it into an "importedPackage" in the originating model. So... What the additional functionality that kicks in after the functionality that-only-does-what-control-does-today is to re-associate the refactored-out package (wrt the metamodel associations) in the originating model. In a real Papyrus example I have, in the .uml file, it's about replacing this: <packagedElement xmi:type="uml:Package" href="../Papyrus_PIM_Model_QVTO_split3_exportedDatatypes/Datatypes.uml#_Y1ocEBIREeKNTdhDAd5_4Q"/> with this: <packageImport xmi:id="_JYcMICNmEeKwd6rqcG9hEA"> <importedPackage href="../Papyrus_PIM_Model_QVTO_split3_exportedDatatypes/Datatypes.uml#_Y1ocEBIREeKNTdhDAd5_4Q"/> </packageImport> Very simple indeed. :)
See also additional information on refactor & reuse in Bug 394883.
