Open ModelDeveloper-AG opened 9 years ago
Phillipus
commented
9 years ago This is a well-presented and detailed feature request. :-)
The longer-term solution is to have a model repository of shared elements and relations, but this proposal could be a stop-gap.
Considerations would be maintaining integrity across the models - deletion of elements in the referenced model, maintaining the undo/redo stack, etc.
jbsarrodie
commented
9 years ago Hi,
If you can wait 1 or 2 months, there should be an even better "low tech" solution. A colleague and I will patch ArchiGITPlugin to slightly change its behaviour.
Today, this plugin does the following:
The main issue is that you can't save on an already existing branch which lead to an (IMHO) unusable git repo.
Our fork will in fact keep only the first part (creat YAML files) and remove (in fact inhibit) the git part.
So the proposed workflow is the following:
This obviously requires some Git knowledge but should be easy to use with the help of a good Git GUI.
Do you this this would solve your issue ?
Regards
JB
ModelDeveloper-AG
commented
9 years ago Thank you Phil, I appreciate your considerations! I'm wondering if there might be some synergies at least in the UI with the long-term solution?
On Wed, Feb 4, 2015 at 7:00 AM, Phil Beauvoir notifications@github.com wrote:
This is a well-presented and detailed feature request. :-)
The longer-term solution is to have a model repository of shared elements and relations, but this proposal could be a stop-gap.
Considerations would be maintaining integrity across the models - deletion of elements in the referenced model, maintaining the undo/redo stack, etc.
— Reply to this email directly or view it on GitHub https://github.com/archimatetool/archi/issues/110#issuecomment-72843252.
ModelDeveloper-AG
commented
9 years ago Hi Jean-Baptiste,
Thank you for your detailed response - the solution you propose certainly looks interesting and capable, and I would very much like to take a closer look at it. I'm also approaching this from an end-user interface perspective, and am wondering how this back-end solution might manifest itself in the Archi UI?
On Wed, Feb 4, 2015 at 9:58 AM, Jean-Baptiste Sarrodie < notifications@github.com> wrote:
Hi,
If you can wait 1 or 2 months, there should be an even better "low tech" solution. A colleague and I will patch ArchiGITPlugin https://github.com/CymaLtd/ArchiGITPlugin to slightly change its behaviour.
Today, this plugin does the following:
- "explode" the archimate model in several (a lot of) YAML http://www.yaml.org files (one per element or view).
- Save them in a new git branch from a choosen git repo.
The main issue is that you can't save on an already existing branch which lead to an (IMHO) unusable git repo.
Our fork will in fact keep only the first part (creat YAML files) and remove (in fact inhibit) the git part.
So the proposed workflow is the following:
- Initialize a new "central" git repo for our main (whole IS/IT landscape) ArchiMate model
- Export our model unsing the plugin and save all the YAML files in the newly created repo, on the "master" branch.
- From this point, only the Lead Architect is authorized to change the "master" branch of the "central" repo.
- People working on the model will clone locally the "central" repo, do their changes and save it back (always in YAML) into their local clone.
- The last step can be repeted a lot of time by several people.
- When someone wants to share its work with the team, it has to commit its changes on the "central" repo in a new branch reflecting the purpose of the edit (e.g. project context)
- When someone wants to see its changes merged in the "master" branch, he just has to submit a pull request.
- The Lead Architect then reviews this pull request and, if ok, does the merge.
This obviously requires some Git knowledge but should be easy to use with the help of a good Git GUI.
Do you this this would solve your issue ?
Regards
JB
— Reply to this email directly or view it on GitHub https://github.com/archimatetool/archi/issues/110#issuecomment-72868697.
Markenson
commented
8 years ago Anybody knows if is there some progress about this issue?
jbsarrodie
commented
8 years ago Hi,
There have been no real progress on this, but this in fact is a feature supported by EMF (the Eclipse Modelling Framework) on which Archi is based. Unfortunately this feature has been disabled when Archi was first developped and this need some (big) changes.
For the moment our focus is on updating Archi to support ArchiMate 3.0, when this will be done (target end of year) and if we succeed in having more funding, we should then be able to work on a major rewrite of Archi that would allow such feature (and many more).
Regards,
JB
Markenson
commented
8 years ago Thank you for your reply, jbsarrodie!
Hello,
This is a possible "low tech" scenario for supporting references to model elements that are mastered in .archimate model files other than the one referencing them. Instead of building on a full multi-user repository, It utilizes Archi's model files that are loaded in memory and provides an extended "shortcut element" that references elements across models.
Shortcut References to Elements in Different Models
Example scenario:
Shared Model Masters the following Motivation model elements:
Project Model Masters the following Motivation mode elements:
Currently in Archi, if “Project Model” would want to use the model elements defined in “Shared Model”, they would need to be copied (by value) to the “Project Model”, resulting in duplicate elements in both models. Any changes to these elements in either model would not be reflected in the other model, since they are separate copies. The proposed enhancements add a new type of “shortcut element”, that references an element in another model. Within the Archi data model, these “shortcut elements” store the id of the model that the element is mastered in, in addition to the element id. When the model that the “shortcut element” references is opened in Archi in addition to the model that contains the “shortcut element”, the properties of the “shortcut element” can be synchronized with their corresponding master definitions. There should be a capability to select the master of the “shortcut element” in the model browser.
Visually, these types of “shortcut elements” could be represented as a standard ArchiMate element, overlaid by a “shortcut” icon (as illustrated). Other possible visual options include showing the text in a different color (e.g. blue), and/or in italics. Relationships would be shown without the icon, but could utilize a different line color, text color and/or font as well.