Recent Posts

1

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« Last post by Paolo F Cantoni on November 15, 2025, 08:14:51 pm »

You could also say it’s a prototype model.
You are making prototypes of the concepts to illustrate their usage.

Geert

Good thought!  Maybe a Metatype diagram, since that’s what’s going to be on it!


Paolo

2

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« Last post by Geert Bellekens on November 15, 2025, 07:54:33 pm »

You could also say it's a prototype model.
You are making prototypes of the concepts to illustrate their usage.

Geert

3

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« Last post by Paolo F Cantoni on November 15, 2025, 01:28:45 pm »

Thanks, guys, for your input.  Most valuable!

I think, using (mainly) Geert’s reply, that what I am building is a profile diagram.  Its intent is similar to the poster, but drawn from an individual node’s perspective (like my Neighbourhood diagrams).

The next problem is that, unlike the paper or PDF poster, I’m creating a model.  So I think I need to distinguish my Concept Node item from the Concept item.  Perhaps I could name the Concept node “«Concept»”, since it embodies the metatype?  Thoughts, other suggestions?

Paolo

4

Automation Interface, Add-Ins and Tools / Re: ArchiMate Grouping and Alternatives

« Last post by Paolo F Cantoni on November 15, 2025, 12:36:02 pm »

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

I know, and was aware I could get in trouble by using a less rigorous approach to nomenclature.  But I will blame the forum’s poor search engine for not allowing me to quickly find one of the posts where we discussed this in the past.  Perfectly happy with “nesting” meaning physical nesting, and using “visual embedding” to describe the ability to move an item in or out of another item on a diagram.  Having said this, Sparx EA doesn’t do “visual embedding” very gracefully at times. 

It wasn’t trouble, merely a gentle correction.   I agree with your point about the searching capability.  Why is searching SO hard (as a functionality)?  It’s not just here that one can criticise the searching as being less than optimal.  Anyway, another gentle correction (to myself, not the least), Nesting doesn’t actually apply to physical nesting; it applies to referential or access nesting - as I have indicated in the past, nesting defines the namespace of the meronym - in other words, you have to access the higher level items to get to the lower level item  (x.y.z).  The physical nesting in the browser is just a manifestation of that concept.

Also, “nesting” is really a form (de-)composition, but AFIK, there is no relationship for it in any modelling language I am familiar with.  Is this not the same as representing “car” as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements?

Yes, you are correct, it is a form of composition, but from the point of view of accessing the item via its FQN.  We use the Nestign Connector as described in the User Guide:
Index > Modeling Languages > Unified Modeling Language (UML) > UML Connectors > Nesting
extensively so that if the meronym and the holonym are on the same diagram, there will be a visual indication that there is a referential nesting, even if the name doesn’t show that (we use use-friendly Aliases a LOT).  The UG places it under UML Connectors (as you can see above), but I couldn't find any reference to it in the Superstructure. 

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Just to clarify my point, I know you and Guillaume have proven you can do this with an MDG.  Actually, I have done it myself.  My point is two-fold:
1 - From previous interactions with Sparx Systems through the support desk, and with Eve and other people in this forum, I got the impression that changing the way the Grouping element works is considered a very significant change, not very high up in their plans.I, too, have observed this.

2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visually embedded.  If the browser could be hidden for certain users, this view could serve as the main entry point for work by some of the users we typically collaborate with.  After all, some relationships are a natural visual embedding: specialisation, aggregation, and composition.

Since we gave away the notion of the browser indicating any form of holonymy, we basically haven’t had that problem.  Only items that require referential nesting are nested.  All other items are in a "flat" structure (by type).  The diagrams are in a separate branch of the repository and can be structured however you like.  Consequently, we don't have as much of a problem as you do.

Paolo

5

General Board / reporting SysML property vallues

« Last post by MMK on November 15, 2025, 01:13:18 am »

Dear all,
We have made a model in SysML to describe a machine. We have used properties to describe the parts of the machine. For reporting we use this fragment to show these properties and their stereotype.

package >
element >
embedded elements >

STRUCTURAL PART OF {EmbeddedElement.Owner}
  {EmbeddedElement.Name} : {EmbeddedElement.Type} {EmbeddedElement.Stereotype}
{EmbeddedElement.Notes}
< embedded elements
child elements >
< child elements
< element
< package

That works perfectly, by regretfully we have not been able to find a way to get the value/ranges of these properties.  Any suggestions?

BR
Marc
 

6

General Board / Context Specific Values

« Last post by free44mind on November 15, 2025, 12:20:01 am »

I’m modelling a simple SysML structure in Enterprise Architect (EA) and I’ve hit a problem with part instances and value propagation.

I have a BDD and IBD, illustrated in the images.

IBD:
https://i.sstatic.net/FyApNoaV.png
BDD:
https://i.sstatic.net/3KzAhaYl.png

I have these blocks:

    Smartphone
    Camera
    Sensor

Relationships:

Smartphone has two parts:

    frontCamera : Camera
    backCamera : Camera

Camera has one part:

    sensor : Sensor

Sensor has a value property power

When I change the power value of one sensor (e.g. set frontCamera.sensor.power = 76), the value automatically changes in the other sensor (backCamera.sensor.power also becomes 76).

It seems both cameras are sharing the same sensor instance, even though I expected each camera to have its own sensor.

But i want to make use of the "context specific values".

I know that SysML has this concept and I dont know why this should not be possible in EA. How can I correctly model this so that frontCamera.sensor and backCamera.sensor are independent instances (each with its own Sensor.power value) in EA’s SysML IBD?

7

Automation Interface, Add-Ins and Tools / Re: ArchiMate Grouping and Alternatives

« Last post by Modesto Vega on November 14, 2025, 10:33:08 pm »

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

I know, and was aware I could get in trouble by using a less rigorous approach to nomenclature. But I will blame the forum poor search engine for not allowing me to quickly find one of the posts where we discussed this is the past. Perfectly happy with "nesting" meaning physical nesting, and using "visual embedding" to describe the ability to move an item in or out of another item on a diagram. Having said this, Sparx EA, at times, doesn't do "visual embedding" very graciously.

Also "nesting" is really a form (de-)composition but, AFIK, there is no relationship for it in any modelling language I am familiar with. It this not the same to represent "car" as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements.

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Just to clarify my point, I know you and Guillaume have proven you can do this with an MDG. Actually I have done it myself. My point is two fold:
1 - From previous interactions with Sparx Systems through the support desk, and with Eve and other people in this forum, I got the impression that changing the way the Grouping element works is considered a very significant change not very high up in their plans.
2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visual embedded. If the browser could be hidden for certain users, this view could be the main entry point for any work done by some of the users we typically collaborate with. After all, some relationships are a natural visual embedment: specialisation, aggregation, and composition.

8

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« Last post by Modesto Vega on November 14, 2025, 09:21:33 pm »

I now follow a similar approach to Geert, with possibly one exception I am still thinking about.

I typically have the following:

1) A conceptual model, using UML class diagrams, without attributes. Depending on the size of the MDG, I will use multiple diagrams.
2) A Logical model, again using UML class diagrams, with attributes. I use as many diagram as I used in the conceptual model.
3) The EA profile used to generate the profile.
4) And, often but not always, a poster leveraging the conceptual model, typically breaking down the model into, for example, aspects or layers.

I always keep all the above in the same repository or branch of the repository.

The exception I have not worked out yet, is how well the above works for an MDG based on, for example, Sparx EA implementation of ArchiMate. The main reason is that is that I don't want to get caught in reverse translation exercise.

9

Automation Interface, Add-Ins and Tools / Re: When is a Metamodel not a metamodel?

« Last post by Geert Bellekens on November 14, 2025, 08:17:45 pm »

Hi Paolo,

I generally have three different models (with their corresponding diagrams)

1. A conceptual metamodel. This is where we start. The metamodel is basically a class diagram. Each element is a class, each property is an attribute. Each relation an association (sometimes with aggregationkind=composite). We also do taxonomy using generaralizations. These are the requirements for the MDG developers.

2. The EA UML profile model, used to generate the MDG. This is sort-of the platform (Sparx EA) specific implementation of our conceptual metamodel. Here we decide which elements will be stereotypes, and how to implement properties and relationship constraints.

3. The metamodel poster. This is a visually pleasing representation of the metamodel that can be printed and hung on the wall as a poster. It uses the visual representations as the users see them in the model and diagrams. Usually this is not complete, but more of a summary showing the most important elements and relations.
My experience is that this works best to communicate the metamodel to the average modeller.

Next to these models/diagrams we also have guidelines documents, detailing usage and rules of each of the metamodel elements. Here we include things like naming conventions, location in the model, etc...

Geert

10

Automation Interface, Add-Ins and Tools / When is a Metamodel not a metamodel?

« Last post by Paolo F Cantoni on November 14, 2025, 07:52:01 pm »

We are familiar with creating an MDG, particularly in this section of the website.  The MDG defines the nodes that the technology allows you to create and the edges that can connect them.  It also allows you to define how the various nodes and edges will be rendered, along with any constraints that may apply.  It further allows you to define the nature and properties of the items.  This sounds suspiciously like a metamodel, but is it?  If it’s not a metamodel, what is it then?

I’m asking for your thoughts.

We currently create our MDGs in a separate repository that contains the MDG definitions.  We then generate the MDG and apply it to the repository that holds the actual models we are developing.  As the MDG developer, I can review the diagrams (in the MDG repository) for the items and visualise how they will appear in the model repository.  But this is too difficult for the user who just wants to model and understand the rules.  “The thigh bone’s connected to the knee bone, the knee bone’s connected to the leg bone... etc.”.  So I thought we’d create the equivalent diagram to the one in the MDG, but with the «stereotype» item replaced by the generated item and the «stereotyped relationship» replaced by the generated edge and so on.  This would provide a visual view of what the MDG can do.

What kind of diagram would this be?  Could I call it a metamodel diagram?  What about the items, both nodes and edges, on the diagram?  Are they the generated items or something else?
For example,  I have «stereotype» in the MDG whose _metatype is Concept.  Concepts are represented as nodes in the model (in fact, they look suspiciously like ArchiMate Meaning items).  Do I place a Concept on the diagram, or do I place a Concept Node on the diagram?  Similarly, do I place a Composition or a Composition Edge on the diagram?

Thoughts and suggestions would be much appreciated.

Paolo