Reporting - Dynamic Diagram Creation

[MichaelJ]

Hi everyone,

We would like to use scripting to dynamically create and populate diagrams when generating reports. We could manually create diagrams containing elements of interest, however, our aim is to generate a single diagram that shows multiple boundary elements that contain a given element. The "containment" of the element is dynamic, and we want our report to highlight that; so instead of increasing manual labour and manually updating diagrams, we'd like to "Work Smarter, Not Harder".

Sparx EA does not permit > 1 instance of the same element on a diagram (why?) - however, one CAN add the same element to a diagram if you manually add the object's Object_ID and a unique DUID ["diagram object ID"]  into the t_diagramobjects table. Try it. :-)

The potential (document) script would flow like so:

• Iterate elements of reporting package
• For each element, locate its containing boundary
• Create an "in-memory" diagram and populate the boundary and contained element
• Repeat step [1]-[3] until completed
• Create another "in-memory" diagram and populate (and position) the diagrams snippets generated in step [3]
• Use the diagram from step [5] in the report

[Uffe]

Hello Michael,

Not sure what your question is here, but

Sparx EA does not permit > 1 instance of the same element on a diagram (why?) - however, one CAN add the same element to a diagram if you manually add the object's Object_ID and a unique DUID ["diagram object ID"]  into the t_diagramobjects table. Try it. :-)

is dangerous. It sounds like you're trying to create a structured way of working, and if you base those on hacks you're building your house on the sand.

You can add the same element multiple times using virtual connector ends. Whether that results in the same t_diagramobjects content as your approach I can't say.


/Uffe

[MichaelJ]

Hi Uffe,

Thank you for your reply.

... Not sure what your question is here, but...

We have multiple boundary elements that COMPOSE an element. On a single diagram we wish to show all boundary elements with a visual instance of element X inside.


|---------------------|          |---------------------|
|     Context A       |          |     Context B       |
|                     |          |                     |
|    Element X        |          |     Element X       |
|                     |          |                     |
|---------------------|          |---------------------|

Note: all connectors are hidden; clicking on either representation of "Element X" will always point the modeller to the same element;

...You can add the same element multiple times using virtual connector ends...

If we drag an element more than once from the Browser window onto a diagram canvas, Sparx EA complains "The diagram already contains an instance of the element you are trying to paste...". This is the same for boundary elements (in our case, ArchiMate "Grouping")

...You can add the same element multiple times using virtual connector ends...

Thanks for the reference to "Virtual Connector Ends". We tried it and felt happy this might work. Stockholm Syndrome kicked down the door and we cowered, but only because we love Sparx EA. "Sparx! Why you do dis!?" we beg it to answer. "Why you no work proper?". Spex-amatron (that's our "fond" name we chistened it) looks down upon us and lifts its mighty arms. We gaze upon its muscles, rippling, fed fat with the pain and anguish of countless modellers, and we shame ourselves for our words. Spex-amatron shouts out thunderously for all to hear, "Because-We-Say-So!". Driven by Stockholm Syndrome, who are we to argue?

Virutal connectors are an utter ball-ache, we found the following issues with using them in this scenario:

• moving the boundary element ("Context A") wreaks havoc with diagram location of virtualized instance inside "Context B";
• virtualised instances cannot be embedded into boundary instances;
• hiding connectors that show between the virtual instance represenation and the boundary that composes it, also hides the virtual instance representation (which is correct); accepting this means the diagram gets messy when additional virtual connectors are "contained" by a boundary

[Paolo F Cantoni]

Hi Uffe,

Thank you for your reply.

[SNIP]

If we drag an element more than once from the Browser window onto a diagram canvas, Sparx EA complains "The diagram already contains an instance of the element you are trying to paste...". This is the same for boundary elements (in our case, ArchiMate "Grouping")

Hi Michael, This is a common fallacy.  A Grouping Element is NOT a boundary (Object Type="Boundary").  In ArchiMate ANY element can become a "boundary" by using visual embedding (I use the term advisedly).   It is a true (first class) element - consequently can't be in a diagram more then once (without automation) but can be used in multiple diagrams as the same element.  An EA Boundary element is by Sparx design (and in my view - and probably others) spuriously) designated as "owned" by the diagram so when you copy and paste a boundary, you get a new instance.

...You can add the same element multiple times using virtual connector ends...

Thanks for the reference to "Virtual Connector Ends". We tried it and felt happy this might work. Stockholm Syndrome kicked down the door and we cowered, but only because we love Sparx EA. "Sparx! Why you do dis!?" we beg it to answer. "Why you no work proper?". Spex-amatron (that's our "fond" name we chistened it) looks down upon us and lifts its mighty arms. We gaze upon its muscles, rippling, fed fat with the pain and anguish of countless modellers, and we shame ourselves for our words. Spex-amatron shouts out thunderously for all to hear, "Because-We-Say-So!". Driven by Stockholm Syndrome, who are we to argue?

Virutal connectors are an utter ball-ache, we found the following issues with using them in this scenario:

• moving the boundary element ("Context A") wreaks havoc with diagram location of virtualized instance inside "Context B";
• virtualised instances cannot be embedded into boundary instances;
• hiding connectors that show between the virtual instance represenation and the boundary that composes it, also hides the virtual instance representation (which is correct); accepting this means the diagram gets messy when additional virtual connectors are "contained" by a boundary

Virtual connectors are (in my view (and definitely that of others)) conceptually the correct way to handle this problem.  However - as you observe - the impl;ementation "sucks".  The basic issue, in my view is that the "VCE" is NOT implemented as a special type of t_diagramobject, but some sort of zombie diagram object with very few useful characteristics.

Put it a formal feature request (links below) to get them to fix it.

Paolo

[MichaelJ]

Hi Paolo,

...Virtual connectors are (in my view (and definitely that of others)) conceptually the correct way to handle this problem.  However - as you observe - the implementation "sucks"...

Yes agreed, conceptually correct, realistically not feasible.

Given the *visual*/*model* coupling present in the product, the implementation sucks and create odd beahvior when using virtual connectors, making this feature unusable. However, if we duplicate the SAME element in the t_diagramobjects table, viola! Two of the SAME instances appear. And diagram manipulation works... mostly.  However, manual replication is not recommended. Though doing this "works", the Sparx team decided to not make it available? Why? Instead we gotta settle for poorly implemented virtual connectors.

...The basic issue, in my view is that the "VCE" is NOT implemented as a special type of t_diagramobject, but some sort of zombie diagram object with very few useful characteristics....

Absolutely. A host of issues are present because the Sparx team has not achieved separation of VISUAL and MODEL concerns. The product is a UML modelling tool. The *visual* IS the *model*. Due to this limitation, it seems the dev. team is forced to hack and add onto what already exists in their C++ codebase rather than unravel the potential complexities in their aging codebase. If "VCE" were implemented as ordinary diagram objects (with a link to the "originator" element), then bingo! Modellers are free to replicate the same element over and over and over and Sparx EA would treat the replications are pure diagram elements complete with all the features we need like embedding within a container.

...Put it a formal feature request (links below) to get them to fix it.

I have logged numerous detailed feature requests, and experience shows:

• logging feature requests is a dead-end
• no feedback/acknowledgement from the Sparx team
• the request form does not support uploading mock-ups (images or video)
• too much time is wasted describing the various aspects of a feature request, such as [Pros], [Cons], [Reason for this Feature], [Benefits of this Feature], [Implementation] etc. just to end up in Ether

The conclusion is: notify Sparx about improving this process. Until then, I'll log bugs.

[Paolo F Cantoni]

Hi Paolo,

...Virtual connectors are (in my view (and definitely that of others)) conceptually the correct way to handle this problem.  However - as you observe - the implementation "sucks"...

Yes agreed, conceptually correct, realistically not feasible.

Given the *visual*/*model* coupling present in the product, the implementation sucks and create odd behaviour when using virtual connectors, making this feature unusable. However, if we duplicate the SAME element in the t_diagramobjects table, viola! Two of the SAME instances appear. And diagram manipulation works... mostly.  However, manual replication is not recommended. Though doing this "works", the Sparx team decided to not make it available? Why? Instead we gotta settle for poorly implemented virtual connectors.

It's not that simple, Michael.  Just placing multiple copies of an item on the diagram "willy nilly" can be done with automation, but that presents its own problems.  If there are relationships to other items on the diagram and the relationships are needed to be visible, which instance of the item is to be connected to?   t_digramlinks (correctly) contains only the object id, not the diagram object id.  So EA can't know which diagram object to connect to.   The use of the VCE is the correct way to handle this as, by definition, each relationship connector now has its own virtual end to be managed.

...The basic issue, in my view is that the "VCE" is NOT implemented as a special type of t_diagramobject, but some sort of zombie diagram object with very few useful characteristics....

Absolutely. A host of issues are present because the Sparx team has not achieved separation of VISUAL and MODEL concerns. The product is a UML modelling tool. The *visual* IS the *model*. Due to this limitation, it seems the dev. team is forced to hack and add onto what already exists in their C++ codebase rather than unravel the potential complexities in their aging codebase. If "VCE" were implemented as ordinary diagram objects (with a link to the "originator" element), then bingo! Modellers are free to replicate the same element over and over and over and Sparx EA would treat the replications are pure diagram elements complete with all the features we need like embedding within a container.


[SNIP]

I don't agree here.  The visual is a View of the model.  It is also a data entry and output mechanism.  There is only one item in the model.
Having multiple instances of the same item on the same diagram is antithetical to the modelling process.  That's why the concept of a "virtual connector end" is valid.  We are not creating new instances of the item, we are allowing each end of the relationship to be rendered as we desire, but we aren't creating new instances.  As I said earlier, the implementation sucks because the rendered VCE is just another rendering of the original item and deserves it's own t_diagramobject to allow that (with an indication that it is a VCE, and not a "real" instance).  We should then be able to hide the connector (since that also is a rendering, not a modelling issue) and voila, we have a correctly modelled multiple rendering of the same item.

Paolo

[MichaelJ]

Hi Paolo,

Thank you for your feedback.

...It's not that simple....  If there are relationships to other items on the diagram and the relationships are needed to be visible, which instance of the item is to be connected to?   t_digramlinks (correctly) contains only the object id, not the diagram object id. 

t_diagramlinks indeed does contain the diagram object ID to connect. Please see the ObjectStyle column in t_diagramobjects table. Each diagram object is assigned a unique ID and this ID is stored like so: "DUID=xxxxxx;". The DUID (Diagram ID) is then referenced in the Style column of t_diagramlinks table. Each connector instance has basic geometry and style definitions, and the Style column contains the diagram objects to be connected. The start and end diagram objects are referenced as either "EOID=xxxxxx;..." (End Object ID) or "SOID=xxxxxx;...." (Start Object ID).

...So EA can't know which diagram object to connect to....

When adding or connecting other elements to/from a manually replicated element, onto a diagram, EA will connect based on the HIGHEST Instance_ID of the replicated element (this highlights a coding bug in their codebase). At this point, the diagram will not show connectors from other instances of the replicated element. It's only when a user closes and reopens the diagram, that EA correctly generates "missing" connectors. All relations are then shown as expected between the replicated element and its linked model elements.

The good thing too is that it's possible to move the replicated element into a boundary. The user can also show/hide specific connectors to that diagram object instance. And since each connector in the t_diagramlinks table is a separate instance, hiding/showing connectors linked to the replicated element is the same as if it were a normal diagram object.

...The visual is a View of the model.... There is only one item in the model....

Yes, this statement "... The *visual* IS the *model*..." is made because, in EA, there is a strong 1:1 relationship between the *view* and the *model*. This is seen by how difficult it is to replicate model elements in a given view (whether or not this is "correct", is not being questioned).

Beside other view elements like "notes", "boundaries" or "graphs", anything we put onto an EA diagram must come from the "model" (whatever our "model" may be). Yes, a model only ever has ONE item of a given meaning.

... Having multiple instances of the same item on the same diagram is antithetical to the modelling process....

There is a distinction between presenting architecture models to stakeholders who understand modelling terminology, and stakeholders who do not. As life shows, simplest is always best. Our reports/diagrams/communications to stakeholders should therefore always be targeted to their understanding of their problem domain. Throwing complex UML diagrams at stakeholders, focing them to focus on how "pure" the "view" is (no duplicated elements whatsoever!) is counter-productive and unhelpful. Our job is to enable stakeholders to understand complexities of their systems by abstracting/minimising those complexities in the  "view".

So, having multiple instances of the same item on a diagram is NOT, as you propose, "antithecal" to creating easy-to-understand views, targeted to a given audience.

Please note :

• EA supports "Convert Linked Element to Local Copy". A modeller can use this feature ad naseum to "replicate" the same element onto a diagram multiple times. (But please! Don't do this because it also replicates connectors and that becomes a world of hurt)
• EA supports "Create Instance" when dragging an element onto a diagram. This is correct behavior according to UML definitions of "instance" and "type"; not supported when modelling ArchiMate because well... ArchiMate is not UML
• The manual replication process described (editing t_diagramobjects using Microsoft Access or SQL Server) seems to work too

We differ in opinion and that's OK. I want to replicate an element on a diagram for presentation (and not modelling purposes). Using Virtual Connector ends is out of the question because they don't achieve what's required.

The original post asked whether it's possible to generate diagrams at runtime and then merge them into a single diagram presented in a report. It seems this is not quite possible, so we investigated how to generate a diagram that achieves the end goal. The investigation lead us discover concening manual replication using the t_diagramobjects table and also use of Virtual Connector Ends and other "local copy" approaches.

[Paolo F Cantoni]

Hi Michael,

Thanks for the considered response!  I DO enjoy a good, and thought-provoking, discussion!  As you suggest, we might have different points of view on this, but actually, I suspect we might be more aligned than you propose.

Firstly, the concept of "instance" is problematic for me.  If you search the forum, you'll see I've pontificated on this a bit (one of my nicknames in the past was "Pope Paul"  ).  Also, if you look at my other postings, you'll see I'm quite pedantic ("pedantry is your friend -when modelling" (in my experience)).

For me, the concepts of having multiple "instances" on the diagram implies multiple "instances" in the model, otherwise you have broken the one-to-one relationship you assert.

As I tried to show, I'm NOT against multiple renderings of the same item on a single diagram.  I'm merely saying that the (correctly implemented) VCE is the mechanism to consistently achieve this.  So that the diagram and model are still "in synch".

We already know that visual embedding is a form of rendering of relationships between items.  EA will (somewhat) correctly suppress the relationship arc when visually embedding.  However it will NOT materialize the relationship if none exists when you visually embed.  This is unfortunate.  We have written scripts to materialize such relationships into the repository.

Similarly, if we have multiple rederings of the same item on a diagram we are expressing that the item is related to other items on the diagram in some way; else why place it thereon?  If there is a relationship, then we can create a VCE.  I assert, without any mathematical proof, that every item on a diagram has to be in a (conceptual) relationship with at least one other item on the diagram (which may or may not be materialized in the repository) and consequently can be rendered multiply according to the number of potential VCEs that exist for that item on that diagram.

As you observe, connecting to the highest Instance_ID is not a modelling consequence, it is a defect.

We agree that we need to create diagrams suitable for the audience.  I've thought long about this and we came up with the notion of "presentation mode" where the item shape scripts can respond to the diagram type and become visually simplified automagically.  My point is that if we break the modelling paradigm (which the VCE - in my view - doesn't) then we aren't modelling any more, just drawing pictures.  To me the whole point of this effort is that when we change the model, the diagram chances accordingly (and, if possible, automatically) according to the rendering transformation rules we have previously defined for each diagram.

How far apart are we now?

Paolo

[MichaelJ]

Hi Paolo,

Thanks for the considered response!  I DO enjoy a good, and thought-provoking, discussion!...

You're always welcome! Thought-provoking discussions are a joy to enage because we're always bound to learn something from each other.

...Firstly, the concept of "instance" is problematic for me...

The "instance" concept was on my mind for a few days during our discussions, as I challenged what is meant by "instance".

...the concepts of having multiple "instances" on the diagram implies multiple "instances" in the model, otherwise you have broken the one-to-one relationship you assert....

Yes, i realised the term "instance" was not clearly defined, since we both interpreted the word in a different context: my context was in reference to "diagram", your context was in reference to "model".
Isn't it amazing that this discussion demonstrates a real-world example of how often definitions mean different things to different people based on different contexts? How important then is the use of a common business vacabulary between "techies" (say as ourselves) and the "get-paid-a-lot-to-know-nothing" management of a business? This example, to me, shows the importance of context.

How many times do we use words or terms that are not the same as what our target audience think? Because of this difference we end up teaching business people to speak our tech language. It's as if we proclaim,

      "We say PO-TAY-TOOOOAH; thou shalt speak after our manner; and after our manner shalt thou speak. For thus say ye: POTAYTOW"
     And after this declaration, did many days pass. For the passing of many days did occur.
     And upon the third day of the passing of many days, did the Architects descend. And the people came with hearts glad.
     For the people inquired of them concerning the potatoes, grown high on Architect Mountain. And thus spake the people, "Oh Architects! We beseech thee, tell us! How doth thine 'pudding-toes' fare upon thine mopuntain?"

     (insert here dramatic scenes where the Architects once more school the people on the correct pronounciation of their glorious 'potty fate toes')



I believe no argument exists for the statements that (1) a model must only EVER contain a single "instance" of an element, and (2) a diagram contains multiple visual "instances"

...the (correctly implemented) VCE is the mechanism to consistently achieve this.  So that the diagram and model are still "in synch"....

Absolutely. Problem is that this is difficult to achieve right now.

..However it will NOT materialize the relationship if none exists when you visually embed.  This is unfortunate.  We have written scripts to materialize such relationships into the repository....

Interesting... initial reaction is that this is "as-is". Since elements on a diagram should be related to something, then surely this beahvior is correct? I'm intrigued to know more about why you wrote scripts to materialize these relationships... because... I'm thinking... "ArchiMate". (things like, when we embed elements, technically we are 'composing'/'aggregating' those elements, but Sparx won't create the relationships automatically because it's a UML modelling tool, not an ArchiMate tool. And that's why we'd have to script this logic)

...Similarly, if we have multiple rederings of the same item on a diagram we are expressing that the item is related to other items on the diagram in some way; else why place it thereon?  If there is a relationship, then we can create a VCE....

..I assert, without any mathematical proof, that every item on a diagram has to be in a (conceptual) relationship with at least one other item on the diagram (which may or may not be materialized in the repository) and consequently can be rendered multiply according to the number of potential VCEs that exist for that item on that diagram....

Say hello to ArchiMate and derived relations. Derived relations are exactly what you describe in that they don't "exist" but are inferred based on rules of precendence and type of connector. The derivation is based on mathematics.

Here's a contrived example: (please don't model like this, it's just an example)


|---------------|                   |--------------------|
|  SQL Server   |----<<serves>>---->| Business Service A |
|---------------|                   |--------------------|
(technology layer)                     (business layer)

Technically this is not a good model because we should not model physical software instances in a business model. BUT conceptually it's OK because ArchiMate permits hiding away of complex relations between components of a model. This is what "derived relations" address.  As you mentioned, I believe they're the same as your thinking of "conceptual relationship even if it does not materialize in a repository".

So given the (incorrect) ArchiMate model above, the "<<serves>>" relationship is actually a "derived" relationship. If we analysed the connector further, and asked "why is SQL Server USED by Business Service A?" we would then uncover an entire possible set of nodes, devices, application components, interfaces, collaborations and business processes etc. used to reach the business service.

...we came up with the notion of "presentation mode" where the item shape scripts can respond to the diagram type and become visually simplified automagically... 

I wish you well if you ever decide to log this as a "feature" with the Sparx team.

...My point is that if we break the modelling paradigm (which the VCE - in my view - doesn't) then we aren't modelling any more, just drawing pictures....

Ah! Good question. When you present your pictures to stakeholders, which of the following do they tend to see

• Pretty pictures of boxes and line "thingies"?
  They look at The Pretty and think "it looks pretty. Colour scheme is good. Wow there's a box that states "CRM" and another that states "SQL". OK. Got it! Let's build this thang!
• A well-thought out conceptual model?
  They heap praise on us for our chastity and purity in the UML presented before them but haven't got a clue what's going on. So, we have to declare what is a PO-TAY-TOOAH (see historical account above)
  

I think based on the question and your statement, that modelling and drawing pictures go hand-in-hand. The pictures must look good and be easily digested, while the model must enable us to maintain governance.

[Paolo F Cantoni]

Hi Paolo,
[SNIP]

…Firstly, the concept of "instance" is problematic for me...

The "instance" concept was on my mind for a few days during our discussions, as I challenged what is meant by "instance".

You may care to investigate some views I have on the matter of instances (earlier in the Forum).  Your thoughts would be appreciated.

…the concepts of having multiple "instances" on the diagram implies multiple "instances" in the model, otherwise, you have broken the one-to-one relationship you assert...

Yes, I realised the term "instance" was not clearly defined, since we both interpreted the word in a different context: my context was in reference to "diagram", your context was in reference to "model".
Isn't it amazing that this discussion demonstrates a real-world example of how often definitions mean different things to different people based on different contexts? How important then is the use of a common business vocabulary between "techies" (say as ourselves) and the "get-paid-a-lot-to-know-nothing" management of a business? This example, to me, shows the importance of context.

How many times do we use words or terms that are not the same as what our target audience think? Because of this difference, we end up teaching business people to speak our tech language.

That's what ontological models are for.  Our repositories use them to create "Controlled Languages".  You get 5 business people you get 7 languages.  The controlled language (not tech language) is the only way out.  As my tag line says...  "There is no such thing as an inconsistently correct system".

I believe no argument exists for the statements that (1) a model must only EVER contain a single "instance" of an element, and (2) a diagram contains multiple visual "instances"

Now, Michael, I'm afraid you're insisting on calling "a Spade a blo*dy Shovel" (as the colloquial saying goes).  By continuing to use "instance" for "rendering" you "muddy the water".  In my view, it is clearer (and more semantically valid) to say "this diagram contains 3 renderings of item X".  It can become unclear as to which instance you are discussing if you don't consistently qualify "instance" with "model instance" or "visual instance", as appropriate.

…the (correctly implemented) VCE is the mechanism to consistently achieve this.  So that the diagram and model are still "in synch"...

Absolutely. Problem is that this is difficult to achieve right now.

I believe that ALL options we currently have will yield invalid diagrams and models.  The current (defective - in our joint view) VCE implementation is merely "the best of a bad lot".  I believe we should put our efforts in getting Sparx to fix the VCE,  heaven forbid they should actually ask us what we think might be the desired result.

...However, it will NOT materialize the relationship if none exists when you visually embed.  This is unfortunate.  We have written scripts to materialize such relationships into the repository...

Interesting... initial reaction is that this is "as-is". Since elements on a diagram should be related to something, then surely this behaviour is correct? I'm intrigued to know more about why you wrote scripts to materialize these relationships... because... I'm thinking... "ArchiMate". (things like, when we embed elements, technically we are 'composing'/'aggregating' those elements, but Sparx won't create the relationships automatically because it's a UML modelling tool, not an ArchiMate tool. And that's why we'd have to script this logic)

In my view, the reason EA doesn't do this has nothing to do with the UML vs ArchiMate tooling.  It's just nobody understood this was necessary to materialize these relationships to create "fully fleshed" models.  Now it may be too late.

EA has a number of relationships between vertices what are NOT found by following arcs between the vertices.  We took the view that if a relationship exists in the model, it should be expressible as an arc.  Incidentally, this is an example of my "same semantics, different syntax" pattern.  Consequently, we materialize many of these relationships as arcs where required.

[SNIP]
Say hello to ArchiMate and derived relations. Derived relations are exactly what you describe in that they don't "exist" but are inferred based on rules of precedence and type of connector. The derivation is based on mathematics.

Indeed!   I am very familiar with derived relationships and I like the ArchiMate mechanism.  The problem that is faced is that sometimes you want to "render" these derived relationships^[1].  They assist in making model diagrams simpler without losing the underlying consistency (as per your example - excised).   However, they represent, potentially, a "combinatorial explosion" of arcs!  We materialize these derived relationships only as required.  They are clearly distinguished from the canonical relationships.

…My point is that if we break the modelling paradigm (which the VCE - in my view - doesn't) then we aren't modelling any more, just drawing pictures....

Ah! Good question. When you present your pictures to stakeholders, which of the following do they tend to see

• Pretty pictures of boxes and line "thingies"?
  They look at The Pretty and think "it looks pretty. Colour scheme is good. Wow there's a box that states "CRM" and another that states "SQL". OK. Got it! Let's build this thang!
• A well-thought out conceptual model?
  They heap praise on us for our chastity and purity in the UML presented before them but haven't got a clue what's going on. So, we have to declare what is a PO-TAY-TOOAH (see historical account above)
  

I think based on the question and your statement, that modelling and drawing pictures go hand-in-hand. The pictures must look good and be easily digested, while the model must enable us to maintain governance.

We don't present UML.  We have gone beyond UML and ArchiMate.  We are working on a "Digital Twin" form of modelling so they can see shapes that represent REAL items in the real world.  Where we need to display an abstracted placeholder (such as "ERP System" for "SAP R3") we use placeholder items which are distinguishable from the real items that might "fit the bill".

Just as the concept of "Instance" is problematic for me, I've (almost) done away with the concept of "Classifier" for real world (as opposed to Code Generation) modelling.  We have  replaced it with a placeholder with query specification so that we can automagically maintain the set of instances that can "fit the bill".  (Placeholder Actor) "Data Architect" has a specification for which (actual Actor) "Paolo Cantoni" ^[2] can be "substituted" at query/runtime (analogously to the Liskov substitution principle (LSP)).

Paolo

^[1]  Another time (and probably off-line) I can recount an interesting encounter with Jim Rumbaugh (before the three became "amigoes") and derived relationships.
^[2]  But hopefully, (actual actor) Julius Caesar won't be substituble!