Messages

1

General Board / Re: Extending SysML Requirement

« on: June 12, 2025, 05:18:08 pm »

You may have to explicitly specify a Derive Relationship between your new Stereotype and the thing you want to Derive it from in your Profile/MDG

2

General Board / Re: Apply custom stereotype to Class and Connector with different Tagged Values

« on: June 09, 2025, 05:20:07 pm »

Even if it would work, it's sometimes kind of annoying.
ArchiMate does that for a few stereotypes (ArchiMate_Path, and ArchiMate_CommunicationNetwork). They are applied on both Class and Connector
...
I had to completely redefine ArchiMate_Path in our MDG so it would only apply to a Class

Interesting... have to admit I've barely scratched the surface of ArchiMate, is this a case where EA treats the ArchiMate profile differently to others like the SysML profile? Or just something fundamentally different about the 2 altogether?

3

General Board / Re: Apply custom stereotype to Class and Connector with different Tagged Values

« on: June 06, 2025, 05:20:49 pm »

Might be messy (and I'm sure you thought of this) but you could always include the TV on your Connectors too but set it to something like 'N/A'. At least means you can use the stereotypes in the way you want to.

4

Uml Process / Re: SysML Action (accept event)

« on: May 27, 2025, 05:24:24 pm »

If it's just AcceptEventAction that you are looking at, then I don't think you need multiple instances of it anyway.
According to UML 2.5.1 section 16.10.3.1, I see no reason (but happy to be proved wrong!) why the AcceptEventAction cannot be triggered multiple times, and at ANY point during the execution of other Actions within the Activity.
If there are different reasons for triggering it (or if it can be triggered by different incoming signals) then you might need a Decision immediately after the AcceptEventAction to test why it was triggered, what was received and decide what to do about it. But it would seem messy/cluttered to me to have multiple AcceptEventActions within the same Activity which are all receiving basically the same incoming trigger/signal.

As always, I know I don't have the full context and I'm happy to be proved wrong about semantics too - it's how I learn!

5

General Board / Re: Applying custom stereotypes

« on: May 27, 2025, 05:15:57 pm »

Glad you figured it out
(and thanks for sharing the diagnosis/fix!)

6

General Board / Re: Applying custom stereotypes

« on: May 21, 2025, 06:05:49 pm »

Works for me in 1625, sadly don't have a 17.1 installation on this laptop but I'm sure I've had it work before in 17.1.
I created a test stereotype as you described, then when I select a Class Element on a diagram and use the Ellipsis (...) on it's Stereotype property the test stereotype is right there under Perspective='All Perspectives' and Profile='None'.

Are you using custom profiles/MDGs at all? Maybe the stereotype is hidden in a different profile/perspective somehow.

7

General Board / Re: SQL Queries, Connectors, and 'Find in Diagram'

« on: May 21, 2025, 05:54:18 pm »

Such a sad image
In dutch we have a saying feels applicable: "Iemand blij maken met een dooie mus", which translates to "To make someone happy with a dead sparrow"

That's absolutely brilliant! (and slightly monty python ) I'll definitely be using that from now on!

8

General Board / Re: SQL Queries, Connectors, and 'Find in Diagram'

« on: May 20, 2025, 10:11:17 pm »

I wouldn't get too excited just yet. AS CLASSTABLE was introduced a couple of years ago, and I haven't seen much change yet in the treatment of connectors.

I'll put the party balloons back in the bag...

9

Uml Process / Re: Best UML Diagrams for Requirements Gathering?

« on: May 20, 2025, 05:31:42 pm »

The sequence diagram is by far the best way to capture who is using what information, what attribute, how they use it and why.
...
Activity diagrams don't add much value beyond maybe user interface design as they just show procedural steps without capturing what information is used, where it comes from, where it goes to.  Personally I avoid them.

Interesting take. Have you played around with using Activity Parameters, ObjectFlows supported by a rigorous data model etc?


To answer the original question, Use Case diagrams are a good way to organise requirements. It depends entirely on what format your requirements take though, of course. If your requirements are modelled as UML Requirement Elements in EA then UC diagram works, or a Class diagram if you want to show different requirement types and how they relate to / inherit from each other (and many other ways to manage the requirments structure).
If your requirements are modelled as Activities then naturally a set of Activity Diagrams is what you need (similar for requirements modelled as Sequences, Class structures etc...).
For me, in summary, there are few 'rights and wrongs' because it depends on what you're trying to achieve, and that will be different depending on the design, the system, the requirements management philosophy, the customer....

I wrote an eBook about all this (Rquirement Diagram, Use Case Diagram and Activity Diagram; you can find it at https://leanpub.com/uml-erpworkshop

I'd be interested to read this!

10

General Board / Re: SQL Queries, Connectors, and 'Find in Diagram'

« on: May 16, 2025, 05:50:09 pm »

Ah, I see. I didn't even know that EA did the "find in diagrams" for connectors.
It didn't used to, but that was before the "AS CLASSTABLE" was available.

This potentially marks a step change in the way Connectors/Relationships are treated in EA... are you aware of anything else different like this? There's been plenty of bellyaching in this forum in the past about how Connectors/Relationships are treated as lesser than Elements but this could be the start of something potentially really useful and exciting (to sad lonely people like me )

11

General Board / Re: SysML V2

« on: May 16, 2025, 05:46:33 pm »

Last time I was aware of anyone asking in this forum, the response was that Sparx were waiting for a stable version of the spec.

[Dec-2023]
https://sparxsystems.com/forums/smf/index.php/topic,47808.msg278320.html#msg278320
"SysML 2 support is not included in EA 17. The specification itself isn't finalized, which is at least part of the reason why v17 doesn't include it."

The spec is currently at beta 2 so I guess still no reason for Sparx to commit.

12

General Board / Re: {bag} what's that?

« on: February 25, 2025, 07:18:00 pm »

I never knew this was possible. Really useful little feature though. Thanks for asking and answering!

(Table 7.1 in UML spec 2.5.1, for anyone interested)

13

General Board / Re: Linking Connectors to Diagrams

« on: January 15, 2025, 07:42:31 pm »

We have the same (and related issues).  We solved it by using the fact that EA now allows relationships between relationships.
We assert that a relationship can be derived from other relationships via a Derivation relationship.  We have various forms of derivation (by traversal, by union, by specialization etc.).  This will allow you to model the concepts you want.  By creating a diagram with the vertices involved in the derivations; the canonical and derived relationships, and derivation relationships, you effectively get the composite diagram for the high-level connector!  In your case, a simple composition relation between the high-level and lower-level relationships may "do the trick".

This sounds like a simpler (and better-explained) version of my vague thoughts

14

General Board / Re: Linking Connectors to Diagrams

« on: January 14, 2025, 07:47:14 pm »

Could you achieve something similar using custom Connector stereotypes in an MDG?
ElementA is linked to ElementB using your custom-stereotyped Connector, let's call the stereotype 'RelationshipType'.
Then in the MDG (or in your 'main model'?) you give RelationshipType an IBD or other diagram(s) (if this is permitted?) that describes its nature as you wish. Then in your main model when you find a Connector stereotyped as RelationshipType, you can look up its Stereotype and insect the properties of the Stereotype.
Or it might be simpler to just define RelationshipType within your 'main model' in a similar way to how you would normally do ICD-style interface definitions.


I *think* this kind of works, but it admittedly doesn't give you much flexibility in defining the innards of ReltionshipType - it would basically be described by metamodelling in your MDG rather than any of your 'main model' Elements etc.
Either way, as has been pointed out, you can't really have Composite Connectors in EA in the same way that you can for Elements.
I also don't have EA open at the moment and haven't tried to do this myself.

15

General Board / Re: How are people integrating EA into confluence?

« on: December 13, 2024, 08:53:44 pm »

You could also install WebEA and publish the links to the diagrams in Confluence.

This simplistic 'pointer' option is a decent solution in many cases, although I agree it isn't technically integration.
If the Engineering team consider the model to be the true single source of truth for the design (which is sort of the point of MBSE), then putting links in Confluence encourages people to actually use the model rather than treating Confluence as a design tool*.
It's a bit more overhead to maintain than a true 'integration' solution like Prolaborate, but for small-scale projects (and to save the cost of buying Prolaborate) it might be workable in some cases.

* Overall, as an industry, we will benefit from people becoming more comfortable with using MBSE tools like EA rather than always defaulting to Confluence, text editors etc