Cloning Instances or Classes?

Post Reply
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

A couple of people have asked recently about creating new instances or classes by copying existing ones or by 'cloning' classes instances. I thought it would be useful to share this as there are some important things to understand about cloning / creating copies of things in the Essential Modelling environment in Protege.

First, let's consider making extensions to the meta model - creating new Classes in the class hierarchy. There is not currently a facility in Protege to clone a class - although there is a sub-class creating Wizard in the Tools menu. However, in practice, you will find that you are not creating new Classes very often and remember that Slots (the attributes of the Classes) are defined and managed separately from the Classes and can be re-used and across Classes. So, if you want to create a new Class from an existing one, you can simply create a new one and add (rather than create new) the same Slots to your new class.

Most of the time in Essential Architecture Manager will be spent working with Instances and there are some clone/create a copy capabilities for Instances.

If you go to the Instances Tab and select the meta class that you wish to work with (e.g. Technology_Product) in the Classes panel, then you will see all of the Instances of that Class that are in the model listed in the middle panel, called the Instance Browser. At the top of this Instance Browser panel are 6 buttons in a row. If you select the one that has 2 overlapping diamonds (one light purple, the other dark), this will create a copy of the selected Instance.

NOTE: This should be used with care, due to the highly-interconnected meta model. There are 2 options in the 'Create a Copy' capability:
  • By default perform a shallow copy. This means that all simple attributes such as strings, integers etc. are copied but importantly, any references to other instances in the model (relationships) are copied such that the new copy points to the same referenced instances. This is known as a shallow copy
  • Deep Copy. By selecting the 'deep copy' option, all the simple attributes are copied BUT for all attributes that are relationships to other instances, a copy is made of each referenced Instance. With the amount of interdependency between elements in an EA meta model (such as the Essential Meta Model) this can cause significant problems in your repository. Many of those referenced instances should not be copied however, there are certain types that should be (e.g. usages). In general, we strongly recommend that you do not use the Deep Copy.

In practice, what you find yourself needing is a bit of both - shallow copy for most things, but for things like usages, a deep copy. Therefore, if I find that I want to clone an instance, I always take a shallow copy and then resolve the things that should be deep-copied afterwards by hand. Think of it as you make a template copy and then complete the template to finish your instance.

So, in my example, I can use the 'Create a copy' button to create a copy of Oracle 9i and then change the name of the new Instance to Oracle 10g. However, make sure that you update the copy, not the original, as there could be many other Instances making reference to the Oracle 9i instance. Normally, the copy is placed AFTER the original in the Instance Browser list but you can use the View references to Instance button to check. The panel that pops up will include the internal repository ID for the instance that you've created and it should have a higher number than the instance ID for the original instance.

In many ways, the complexities of managing the results of performing a copy can make it simpler just to create a new instance and copy and paste / replicate the attributes as required in the new one. Note that you can use the magnifying glass button to open the definition of an instance in a separate window that you can place on the screen for easy reference when doing this. Nearly all the time, this is the approach that I take.

By the way, in my example of Technology_Products, when I create my Oracle 10g instance, I mustn't forget to create a Technology Product Role Instance for this (the Implements Technology Components attribute) that tells the model what Oracle 10g can be used for - and you can have more than one of these Roles!

This example demonstrates the potential issues raised by performing a copy.

I'll probably find that the Technology Product Role for Oracle 9i has been copied into the 'Implements Technology Components' attribute of the new Oracle 10g instance. This isn't right. That Technology Product Role is a role for Oracle 9i. However, I can't open that and update it because then I will damage the relationship that has been defined for Oracle 9i. Rather I have to REMOVE (not delete) it from that slot and then create a NEW Technology Product Role for Oracle 10g.

To summarise about cloning instances, if you do use the Copy Instance capability in Protege, make sure to perform a shallow copy (the default) and NOT a deep copy. Then 'fix up' the new instance to make good any relationships or attributes that shouldn't really have been copied. Attributes that contain Relationship Classes, e.g. Technology Product Role, Actor to Role Relation, always need removing and re-defining with a new instance of the relationship class.

You can see that cloning instances can be tricky and unless you really need to is often not worth the effort.

Jonathan
Essential Project Team
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

This has been exactly our experience. Though the notion of simply copying instances is superficially attractive, it's almost always more trouble than it's worth. Deep copies are especially trouble prone; you'll end up with copies of many of the associative classes, all named identically to the source instances, and drive yourself crosseyed trying to sort them out.
Post Reply