Messages

1

Automation Interface, Add-Ins and Tools / Assigning Additional Stereotypes to Archimate elements and connectors

« on: January 18, 2022, 03:55:55 am »

I suspect I am going down a very unsafe road and hope the hive mind can tell me one way or the other (bearing in mind I am NOT an expert - just a modeler).

Im describing flows between archimate components. I'd like to also clarify whether the flow is implemented securely as part of the EA "question" to be answered is which system relationships are insecure.
So I started with tagged values but then found that I cant use diagram filters with these *on connectors* (all I wanted to do was hid ann insecure connectors - seemed reasonable to me but tagged value does not appear as a filterable property - whether in UML or Archimate).

So I switched to assigning stereotypes - with a "workaround" because the Archimate profile wont let me assign additional archimate stereotypes (sensible I suppose ) but I can assign some additional UML profile stereotypes. So eg I have a stereotype "IsEncrypted", "IsNotEncrypted".

Now ignoring for now that regardless I can may those stereotypes visible without adaptations anyway , my question to the collective is - is this "multiprofile" stereotype approach going to lead to pain and tears or is is perfectly legitimate (recognising I'd have preferred to use tagged values but due to the apparent inability to filter on these for connectors I didnt).

I suspect the answer will be to define our own MDG based on Archimate - or based on UML - but to look and behave like archimate but with more flexibility (I find the number of "standard" things that dont work with the Archimate MDG quite frustrating.

But one has to ask 

 

2

General Board / Re: Multiple use of elements in diagram

« on: January 11, 2022, 04:39:45 am »

I know this is an old thread but really - please change the message that pops up rather than maing folks raising it feel stupid.
Im frustrated by virtualizing connector ends as a very clunky work around because it doesnt work in reality - its not the answer to a situation where you want to show that an element is duplicated for convenience on a diagram to help the reader of the diagram know that there a relationship to an item that exists more than once on the diagram. We cant all work in nice small packages sometime we have to show the bigger picture (literally).

Whats wrong with "use virtualised connectors" as an answer?

Ok - heres some stuff that shows its not thought out.

The "ghost" shape that gets created is not able to be changed in appearance - its just a visual adornment on the connector really - in fact when you look at it it is still a connector
You cant find the other end that is virtualised (no jump to...); 
the fact its a "ghost" is not always visible (depends on the elemnt type so in archimate sparx try to show it by tweaking the embedded icon but of course this doesnt work for elements tha dont have this like dataobject;).
If you associate something with the ghost it hasnt associated it with the "real" element - so thats a bear pit - because you have actually associated your element with a connector not another element.

And also in archimate the whole argument about element type and instance fails (I agree with it but it doesnt help the enterprise architect who wants to represent element that it right over the other side of their diagram).

Heck in 1997 we had SSADM tools like Popkin System Architect that simply stuffed an asterisk or diagonal slash in the corner for you so you know it was a visual duplication *for convenience*).

Small rant over but Sparx you do have a habit of making your arguments based on some peculiar logic that might be sensible for certain context (eg class diagram) but doesnt work for archimate - at least remove "currently" from the error dialogue that appears and stop making us think you are doing something to address what is a basic constraint of your underpinning relational data model.