Skip to content

Selecting, Copying, Duplicating and Merging

Mads Bondo Dydensborg edited this page Apr 14, 2014 · 13 revisions

This page contains 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

Assume the user have made a selection SD and chooses the Copy action.

Archi first filters SD to SD' where only the DO's of SD is kept. DR's are not passed on to the CopySnapshot created afterwards (com.archimatetool.editor.diagram.actions.CopyAction.run)

Then a CopySnapshot is made from SD', but only from the toplevel elements in SD'.(CopySnapshot.getTopLevelObjectsToCopy(), .createSnapshotObjects()). This is the "snapshot". Lets refer to the snapshot of objects as SS_Obj. Conceptually, it sort of a selection, based on SD' (which again was based on SD). But, SS_Obj does not contain references to the objects in SD', but rather copies. A 1-to-1 mapping between the objects is created, that is, from SS_Obj to objects in SD' (fOriginalToSnapshotObjectsMapping). Lets call the objects that matches SS_Obj in the original model for SS_Obj_Org.

Then a number of relations are added. The relations are found by looking at all the elements in SS_Obj_Org, look at all source connections, and check if the target of the relation is part of SS_Obj_Org. (getConnectionsToCopy()). If it is, it is added to a list of relations (SS_Rel_Org), that are then traversed. For each relation in SS_Rel_org, it is checked if SS_Obj contains both the target and source object (which, I believe, it should, as we got the relations from the 1-to-1 mapping fOriginalToSnapshotObjectsMapping!). If the source and target objects are present, a new relation is created, based on the relation from SS_Rel_Org, and inserted into the set of relations in the snapshot SS_Rel. A 1-to-1 map between SS_Rel_Org and SS_Rel is maintained in the fOriginalToSnapshotConnectionsMapping variable.

(Phew).

When it is time for pasting, it goes somewhat like this:

The main method is getPasteCommand - the purpose of this method is to create a command that does the pasting of the individual DE into the view/diagram in question.

The first thing the method does, is to determine if the AE's that SS_Org and SS_Rel_Org points to, are to be reused for the paste operation, or if new ones are to be created. (needsCopiedArchimateElements()). (This is a global consideration, which I would like to challenge, but for now, I am just describing what it does. The way it does it is slightly complicated, actually).

The paste command creates a new set of objects and relations from the existing sets SS_Obj and SS_Obj_Rel. This is (probably) because you should be able to paste several times, to different views, etc, so the snapshot can't be pasted, it has to be a copy of the set that gets pasted.

The paste command has to do some bookkeeping for mouse coordinates, and for making sure that the new DO's that is created on the basis of SS_Obj, gets new DR's that matches the source and targets, and that if new AE's are needed, these are created and set up correspondingly. But aside from this, it is a pretty straight forward process, where the sets are traversed (recursively for DO's that are containers) and instances of an internal command (PasteDiagramObjectCommand) are created to do the actual inserting of DE's and AE's into the diagram and model respectively. (And support removal during undo, if needed, and so on).

Example

An example might be needed?

Suggested behaviour of copy and paste

TODO: Write this.

Something about that it might be good if there was a greated kind of correspondance between what the users sees as selected, and what gets pasted?

For containers that are nested, it makes sense. But, perhaps not so much for other stuff? The selection tool explicitly does not relations - but they get copied and pasted anyway? I think that is confusing.

Merge feature

TODO: write this.

Merge is really: do not create new AE's when pasting into the same archimate model, but only if absolutely needed.

Duplicate

Duplicate - copy and paste all DE's, but do not create new AE's?

Complications

TODO: Write this

Connections are directional - they are only registered with the source???

If a source of target DE is not pasted - can you create a connection anyway for merge (does this even make sense, I am writing right now?)

Can you create new DR's if pasting two elements with a relation, and you decide to reuse an existing DE?

What to do if several DE's in the diagram already when pasting and you have a connection? Connect to all?

Clone this wiki locally