Selecting, Copying, Duplicating and Merging

This page is some thoughts about how copying and pasting elements in Archi currently works, how I think it could be improved, and how this could be implemented. This page is meant to be temporary, but may eventually become the basis of the documentation for these processes in Archi, if Phil agrees that the changes are desirable.

The focus is on supporting the user, both such that the actions are not surprising, and such that one gets a few more possibilities when copy-paste than is currently supported. (However, this page is not meant to be read by users, but only by developers).

Relevant issues currently are https://github.com/Phillipus/archi/issues/60 and https://github.com/Phillipus/archi/issues/26. More may be relevant.

Overview of the Archi model

For the sake of the discussion, it is probably beneficial to consider how Archi works, with respect to the Archimate model and the views. The following is my understanding, which is surely simplific, but hopefully close enough to be usable.

The Archimate standard uses "Concepts" and "Relations". In this text, Concept will be called objects, relations will be either relations or connections, and "Elements" will be used to cover both types (concepts and relations).

Manipulating elements as seen from the users perspective

The user have two main ways to manipulate elements: The tree view, or a given view on the model. If the tree and the view is linked, a click on an element in the view will highlight an element in the tree. A click on an element in the tree, will highligth an element, if it is visible in the current active view.

From the users point of view, elements can be part of several views, but the element can have e.g. different appearence properties in different views. Elements can even be present several times in the same view, and all instances will highlight when the element is selected in the treeview (in the linked case).

Archimate elements and Diagram elements

Although it appears to the user that the elements in the tree and in the views are "the same", to Archi, there is (and must) be a difference.

Archi internally differs between Archimate elements, and Diagram elements. Archimate elements are elements (objects and relations) that are part of the Archimate model that the user works on. These elements are part of the model tree in the Archi GUI. Diagram elements are the representation of these elements in different views. They, obviously, appears in the views, but have no direct representation in the model tree.

Every Diagram element have an associated Archimate element, but Archimate elements can exist without any associated Diagram elements.

When the user manipulates elements in views, he is manipulating Diagram elements. For some operations, such as naming, the associated Archimate element will be manipulated too, for others, such as the color, only the Diagram element is affected. When the user manipulates elements in the view, he is manipulating Archimate elements, and for many operations, the associated elements will not be affected. For others, such as a delete, the associated elements will absolutely be affected.

Notation for elements, objects and relation

In the following, assume the following notation:

• An Archimate Element is shorthanded to AE, this can be either an
  • Archimate Object = AO or
  • Archimate Relation = AR
• A Diagram Element is shorthanded to DE, this can be either a
  • Diagram Object = DO or
  • Diagram Element = DE
• S notes a selection, which can be one of or a combination of
  • SM notes a selection of Archimate Elements from the model tree
  • SD notes a selection of Diagram Elements from a diagram (view)

Selecting elements

When selecting in the model tree, the archimate elements from the model are selected, and worked upon. A selection therefore contains a set (possibly with duplicates?) of archimate elements, which we can write like this S = SM = {AE0, AE1, ...} = {AO0, AO1, ..., AR0, AR1, ...}, where AE are archimate elements, divided into AO (archimate objects) and AR, (archimate relations).

When selecting in the views (diagrams), the diagram elements are selected. In this case, we can write S = SD = {DE0, DE1, ...} = {DO0, DO1, ..., DR0, DR1, ...}, where DE are diagram elements, divided into DO (diagram objects) and DR (archimate relations). (Again, duplicates may be a possibility?)

In some cases, when selecting a DE, the visual feedback is different from the actual selection that archimate gives. This is true when the DE is a container, where other DE's are nested inside. Assume that DO0 is an object that have an aggregation relation DR0 to DO1. If DO1 is nested inside DO0, a selection of DO0, followed by a delete (from view) operation, will mean that the SD' = {DO0, DO1}. (Note, that DR0 is not part of the selection, because it is actually not present in the diagram model when nesting. Might need some clarification here). If, however, DO1 is not nested in DO1, then SD' becomes {DO0, DR0}. Note, that in both cases, the delete operation works on something different from the users visual feedback.

Also, for some operations, the set of associated archimate elements may be relevant to the selection. For e.g. delete on the model tree, if SM = {AO0}, the delete operation actually have to work on the set SM', that contains {AO0, AR0, AR1, ...} where AR0, AR1, ... are the relations in the archimate model that have AO0 as a source or taget. And, because all diagram elements DE that refers to a given AE must also be deleted, the delete operation needs to work on both SM' and SD', where SD' is the set of associated DE that matches the set of AE in SM'. Hence, the total set S to work on, becomes the combination of these sets of different elements.

Copying elements

There are two places to support copying elements. One is in diagrams, the other in the tree. (I don't think there is a wasy to copy between these to representations, at least not currently).

For both, a special consideration must be given to the case where the elements to copy gets deleted either during the copy (cut) operation, or between the copy and paste operations.

Copying elements in the diagram

Copying elements in the diagram is probably done by the user to either get a copy of the elements in the same diagram, or a copy in another diagram. However, because of the association between AE and DE, the semantics of the operation can be discussed: Is a copy a copy of the DE's with new AE's, or is it a copy of the DE's while maintaining the association to the existing AE's? In the following this is discussed with a starting point in the current Archi behaviour, then a few suggestions for additional operations.

Current behaviour

The current behavour has some "quirks", that give some interessting/suprising results.

Overview

When the user have made a selection SD in the diagram, and chooses the Copy action, Archi first filters SD to SD' where only the DO's of SD is kept. DR's are not kept. Then a CopySnapshot is made from SD', but only from the toplevel elements in SD'. Then a number of connections are added, based not on the selection, but on the associated AE's.

When pasting, the DE's from SD is pasted, but also recursed, so any elements they contain, gets pasted too. Then the connections are pasted.

To complicate matters a bit: when pasting, if an associated AE has been deleted, OR, the target diagram contains a DE that is associated with an AE, the paste operation creates new AE's for the entire selection and associate them with the DE's, before pasting them (each gets marked "(copy)").

Quirks

• If a container DO_p contains two elements DO_c_0 and DO_c_1 (nested) and the user makes a selection S = {DO_p, DO_c_1} and pastes it to an empty view, all of {DO_p, DO_c_1, DO_c_1} is pasted.
• Likewise, if two elements DO_0, DO_1 are connected by two different DR's: DR_0, DR_1, and the user selects both DO's, but only one of the DR's, all are copied anyway.

Details of the operation

This CopySnapshot builds a representation of SD based on SD' (lets call this new representation SD'').

The building of SD'' is quite complicated. First, only the toplevel objects from SD' is used. Because there (intentionally) are no relations in S', the CopySnapshot builds the relations by looking at the associated elements (AE's) from the DO's in SD' to build the representation. A relation DR is created in SD'', if and only if there exists DO_t and DO_s, where the associated AE's, AO_t and AO_s have a relation AR.

Example

An example:

Suggested behaviour of copy and paste

Merge feature