Where did "instance" go?

[Rhys Lewis 2]

What is matter anyhow? Do we exist at all? Did(/will) all philosophers die in vain?

I think what Paolo is saying is that there is the real you (probably only known to yourself) and then there is the mythic you - the story you tell the rest of the world.

This is really getting back to Theseus' Ship.  The original ship was an instance of the Platonic ideal of Theseus' Ship, and then at every point where another plank was swapped out it created a new instance of the ship that shared some substance with prior and subsequent instances.  The instances themselves were not the ship itself, which was a technology node rather than a device.

If you were to take the gradual degradation that caused the planks to need to be replaced, then there is an almost infinite series of instances of the ship, so the instances recorded at the swapping of the planks could be determined by a swinging door algorithm on a time series of the decay.

Hope that's helpful.

[Rhys Lewis 2]

In a rather dramatic development it appears that the Open Group has published a new version of the Archimate standard and has included the new Directed Association relationship https://blog.opengroup.org/2019/11/05/archimate-3-1-specification-the-new-version-of-the-standard/amp/.

If I read this correctly, they have enhanced the "it means anything you like" relationship to allow an arrow and a stereotype, with the ominous warning,

Now you do need to exercise some caution in using this feature. It would not be very helpful, for example, to define your own relationship if something very close is already offered natively by the standard.

  We wouldn't want that to happen now, would we?

I can also picture a scenario where EA including the derived relationships by default would save a lot of "hide this connector in other diagrams" admin.

[Glassboy]

In a rather dramatic development it appears that the Open Group has published a new version of the Archimate standard and has included the new Directed Association relationship https://blog.opengroup.org/2019/11/05/archimate-3-1-specification-the-new-version-of-the-standard/amp/.

Marc Lankhorst was asking on LinkedIn what changes the working group should be looking at next.  I haven't bothered to comment as I've gained the view that a lot of the people discussing ArchiMate on LinkedIn don't really use it.

[Paolo F Cantoni]

Depth, an agreed definition and good humour. What else can you ask for on this forum? 

Hopefully, we have not gone “Full Circle”, as a Cisco SGE2000P 24-Port Gigabit Switch - PoE with serial number 123456789-0986 is only persisted on something like the ServiceNow database, and the physical item on a comms room is not an instance of a Node or Device.

P.S.: Glassboy - As I may have before nothing wrong with floppy disks.

(my emphasis)  We aim to please!  Yesterday, I must have got up on the right side of the bed as I was feeling quite playful...

No, we haven't gone full circle!  At least, we have travelled along what I call the "rising spiral".  In 2D we may appear to be over the same 2D point, but in 3D we have moved along the z-axis.

More on your switch later (especially after I check out the ArchiMate "thang").

Paolo

[Rhys Lewis 2]

... as a Cisco SGE2000P 24-Port Gigabit Switch - PoE with serial number 123456789-0986 is only persisted on something like the ServiceNow database ...

Not necessarily.  At a large site it is important to plan these things ahead of time so that when the deployment team goes out they put the right thing in the right place.  The first round of planning is "what do we need?", which is the yellow and blue diagrams.  Then there is the "what technical solution are we going to roll out to solve that need?", which is the technology layer (1st green diagrams).  And finally there is the "what is the field technician going to deploy at site #3?" plan which is the equipment/device layer (2nd green diagrams).

Then in the subsequent months or years when people ask, "what ended up at site #3?" you pull out the diagram to show what is there.

Speaking of full circle, it's the 1st to 2nd layer green diagrams where the instance functionality was useful.  I have started using the Child Generalisation option in EA, which may not be canonical Archimate but produces readable diagrams.

[Modesto Vega]

... as a Cisco SGE2000P 24-Port Gigabit Switch - PoE with serial number 123456789-0986 is only persisted on something like the ServiceNow database ...

Not necessarily.  At a large site it is important to plan these things ahead of time so that when the deployment team goes out they put the right thing in the right place.  The first round of planning is "what do we need?", which is the yellow and blue diagrams.  Then there is the "what technical solution are we going to roll out to solve that need?", which is the technology layer (1st green diagrams).  And finally there is the "what is the field technician going to deploy at site #3?" plan which is the equipment/device layer (2nd green diagrams).

Speaking of full circle, it's the 1st to 2nd layer green diagrams where the instance functionality was useful.  I have started using the Child Generalisation option in EA, which may not be canonical Archimate but produces readable diagrams.

You are essentially describing an architecting (in blue), engineering (in green) and building approach (the 2nd green diagrams) process. In this case I have no objection if the word engineering is used to describe the work behind producing the 2 green diagrams.

Just to get this clear in my head out of curiosity:
- Do you have a Node element for the Cisco SGE2000P 24-Port Gigabit Switch without a serial number in the blue or 1st green diagram?
- Do you then create (or want to create) green diagrams where the Cisco SGE2000P 24-Port Gigabit Switch without the serial number is replaced by an instance of it and add the serial number to it?
- What object type does Sparx EA use (or would you Like Sparx EA to use) for the instance?

[Rhys Lewis 2]

Just to get this clear in my head out of curiosity:
- Do you have a Node element for the Cisco SGE2000P 24-Port Gigabit Switch without a serial number in the blue or 1st green diagram?
- Do you then create (or want to create) green diagrams where the Cisco SGE2000P 24-Port Gigabit Switch without the serial number is replaced by an instance of it and add the serial number to it?
- What object type does Sparx EA use (or would you Like Sparx EA to use) for the instance?

It varies by how much of the full set of possible documents a project requires.  In the 1st green diagram I used a lot of nodes, but have also started using devices and equipment a lot more lately.

If I am creating a few instances of a thing, then I will make a Node, Device, Equipment or Technology Object in a special folder called "Types".  At the moment I have an Archimate_Node in that folder called "Switch", but if I were doing that again I think it would be a Device.  When I have a diagram with one or more particular switches, then if they are older diagrams they are Instances of that type, and for newer ones they are now Child Generalisations.

Otherwise I often create the instances of the 2nd level green diagram from the objects of the 1st level green diagram.

When it comes to real-world project documentation there are a variety of ways that it will diverge from the idealised set, but they are centred around that ideal even if they are not all carbon copies.

One of the huge advantages of using instances or generalizations rather than raw Archimate objects is that they assume the visual properties of a Class, and you can view or hide the tags.  So for almost every instance I have a tag "IP" that has it's IP address.  Other types of device have other things that are useful to include in tags, such as type (eg. IE-4000-8T4G-E).  That way you can toggle the Tag feature for a diagram to have a clean "just what's there" view, or a more detailed "tell me everything" view that includes details about each box.

[Paolo F Cantoni]

Hi Rhys,

I'll bite.  What's a "Child Generalization"?  In normal modelling usage, that would be an oxymoron.  Generalization is a directed relationship from the origin (so-called child) to the destination (so-called parent).  Specialization is the antonym of Generalization and therefore directed from the more general to the more specific.

Paolo

[Rhys Lewis 2]

I'll bite.  What's a "Child Generalization"?  In normal modelling usage, that would be an oxymoron.  Generalization is a directed relationship from the origin (so-called child) to the destination (so-called parent).  Specialization is the antonym of Generalization and therefore directed from the more general to the more specific.

That really is the life blood of this thread.  On the one hand is the canonical forms suggested by the Archimate standard, and on the other is the things that actually happen when you drag Archimate objects from the project browser onto a diagram.

As it stands, if I drag an Archimate technology object (Node, Device, Equipment etc.) onto a diagram I have two choices: Link (ie. put the existing one onto the diagram) or "Child (Generalization)", which is the only way to create a relationship from the existing object to the new thing that is to be represented on the diagram. 

I suppose that another way around the problem would be drag the first object onto the diagram, create a new object of a suitable type, then connect them with a relationship from Toolbox, then remove the first object from the diagram.  However this won't visually embed the relationship in the new object.

Which returns me to my original question, "Where did "instance" go?"

[Paolo F Cantoni]

Ah... My Apologies... As you probably have realised, I'm somewhat of a pedant (many pedants here would say I'm an absolute pedant  ).  But hey, "Let's hear it for pedantry!" 

Child Generalization and Child (Generalization), aren't the same thing and Sparx has helpfully added to the confusion by making the link generate a non-ArchiMate term (Generalization)  The term is used EXACTLY once in the standard and then ONLY to point out that the ArchiMate concept is Specialization (and I suspect to give UML a "Serve" for defining Generalization the wrong way round).

Anyway, now I understand and I agree that (as the Standard says) "a specialization relationship is always allowed between two instances of the same element".

This thread has REALLY got me thinking about the nature of instances and as you said, it's the lifeblood of this thread.

I'm still refining my thoughts (while tryng to get on with my day job).  Hopefully, I'll have some input soon.

Paolo

[Rhys Lewis 2]

many pedants here would say I'm an absolute pedant 

"Absolute" in the sense of undiminished, independent of other things, or a pedant for things that are themselves absolutes?

[Paolo F Cantoni]

many pedants here would say I'm an absolute pedant 

"Absolute" in the sense of undiminished, independent of other things, or a pedant for things that are themselves absolutes?

Would you accept Both? 

And to illustrate that... What do you understand by: "a specialization relationship is always allowed between two instances of the same element".

Is BMW X3 a specialization of BMW X1 - surely not?  Can there be a specialization of BMW X1 with Vin#?  Where is the element?  What is the Element?  Is it a metatype?  Why do Actors "get a guernsey" as an Element, but Motor Vehicles don't?

Thoughts?
Paolo

[Modesto Vega]

Just a number of random comments:

1) "Child (Generalization)" is Sparxian for Specialise, by choosing "Child (Generalization)" you are creating a new element with an specialisation relationship to its parent.

2) According to section "7.3.20 Generalization (from Kernel, PowerTypes)" of OMG Unified Modeling LanguageTM (OMG UML), Superstructure - Version 2.2: "A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of the more general classifier."

I cannot see too much wrong with this. But the use of the word instance (with small 'i') is interesting. It suggests that as Paolo has been suggesting a specialised element is an instance, with small "i", of its classifier/parent element.

3) When "Instance (Object)" is used in Sparx EA, all Sparx EA does is to set the classifier of the new/child element to the parent without creating a relationship. This may be an Sparxian, and perhaps incorrect, interpretation of UML because my understanding, hopefully not incorrect, is that classifiers can be applied to classes, actors, components and so on.

4) ArchiMate is a name only modelling language, the ArchiMate specification does not mention attributes and operations anywhere when describing the metamodel. As a result, no features are inherited when specialising in ArchiMate because there are features to be inherited. The fact that tags can be added is most likely a Sparxian deviation from the standard.

My conclusion is that Generalisation/Specialisation is likely to be the most semantically correct way to achieve what Rhys has in mind.

Interestingly, I cannot find a definition for Instance or Object in OMG Unified Modeling LanguageTM (OMG UML),
Superstructure - Version 2.2. There are plenty of definitions including both words but none for each word on its own with a capital letter.

[Glassboy]

Why do Actors "get a guernsey" as an Element, but Motor Vehicles don't?

I love that you mix pedantry with a colloquialism that even I, as someone who is fluent in 'straln, had to look up :-)

[Paolo F Cantoni]

Why do Actors "get a guernsey" as an Element, but Motor Vehicles don't?

I love that you mix pedantry with a colloquialism that even I, as someone who is fluent in 'straln, had to look up :-)

As I said to Modesto, "We aim to please".   

Of course, being a Kiwi, you'd mispronounce 'Strine.  But you're forgiven... 

Paolo

[In some seriousness, as a person for whom English wasn't, technically, my first language I like to encourage our non-EFL correspondents to explore some of the more esoteric areas of this fascinating language]