Messages

1

Automation Interface, Add-Ins and Tools / Re: EA and ChatGPT 5 - the death of the forum?

« on: October 08, 2025, 06:38:53 pm »

OpenAi have clearly scanned all of the posts in this forum, to the extent that it will even, occasionally, say WHO provided an answer, which is the proof of the source.
Scanning material like this may not be a Good Thing from an Intellectual Property point of view, but it's definitely a thing, and it seems sensible to use it.
Which is where the issue lies: if we all use an LLM to find out about EA, then where does that leave this forum? Why ask the forum, when ChatGPT has all the answers?

AI is sort-of an improved search engine.
It avoids me having to answer the same question here over and over again.
For new questions, I'm guessing we still need something like the forum.

...LLMs only know the information that has already been posted. There are and will be many unpublished questions and tips. We (human) understand the situation, requests and constraints, and we offer the best solution for every user.

For me, this sums it up well. The LLMs are not (yet) modelling tools, and whilst they will/should learn from their own experiences, they cannot be 'creative' in the human sense of bringing meaning to the UML/SysML/EA/etc semantics in a way that can be interpreted by a large number of users, or in a very specific scenario.

As you suggested, yes maybe this makes forum replies simply feeders into the LLM... but I don't think it necessarily cuts off the source.

Of course, as a systems engineer and architect I have a vested interest in ensuring I still have a relevant career and am not replaced by AI in the next 12 months. So I'm always going to argue strongly FOR humans as modellers and supportive communities!

2

Bugs and Issues / Re: Parts, Properties,… do not allow to “Select Composite Diagrams” on Sysml IBD’s.

« on: September 30, 2025, 05:17:55 pm »

Hi, I am not talking about SysML spec. bugs ,I am talking about EA inconsistency bugs, or at least what I think EA consistency is.

The concept of linking from on element to its details by double click, is nothing defined in the SysML spec. at all. It exists in EA since many years and it is a real good EA feature, which work well in many scenarios. But in some scenarios currently either not or it depends unnecessary on the work sequency performed.

In an IDB e.g. parts are classified by blocks and if those blocks have own IDBs it would be very helpful just be a double click to move the that diagram as it is possible form many other stuff.

Yeah I'm on board with you, I agree it would be useful to be able to navigate quickly ('like' a double-click) from a Part to its Classifier's IBD. I just meant that semantically (according to the OMG spec) I don't think that is how Parts are supposed to behave, so I would guess - and it's only a guess really - that in this instance Sparx have implemented the OMG spec kind of rigidly and therefore there is no EA feature to do that particular navigation.

Looks like Takeshi has a nice elegant solution though

3

Bugs and Issues / Re: Parts, Properties,… do not allow to “Select Composite Diagrams” on Sysml IBD’s.

« on: September 26, 2025, 05:33:48 pm »

I may be wrong but I'm not 100% sure this is a bug.
I can't find a specific reference in the SysML spec to back me up but I think Composition is defined at the level of the Classifier (Block), not at the level of a Part, which itself is an instantiation of a Classifier (Block). If we are looking at an IBD and want to know the constituent Parts of a Part, this really means we are asking "What is it's Classifier composed of?". This is the case because the Part only represents one instantiation of the Classifier, and we should intend that any change to the Classifier is applied to all Part instances of that Classifier, wherever it is used in the model.

As I said, I can't back myself up here in terms of explaining the semantics, and I'm happy to be proved wrong and learn!

4

Uml Process / Re: Multiple versions of a Component

« on: September 26, 2025, 05:25:16 pm »

The problem I have with all of your approaches, is that it results in multiple elements all representing a single component.
Now if I want to get a complete view of the impact of this component, I somehow have to merge all versions of this component together.

I see your point - but from a PLE perspective, if we assume that 'standard 1' of the Component is for CustomerX/ProductX, 'standard 2' of the Component is for CustomerY/ProductY (etc...) then it is almost 'useful' to have different Elements representing them - it *could* make overall PLE integration easier if we are only using the native EA features and no specific PLE plugins etc. For one thing it keeps Customer requirements/IPR more neatly confined with less risk of one customer's dirty laundry to bleed into another customer's product (to use a mixed metaphor ).

Wat we do, is use a single element for a component. If needed, we mark the relations to future or past states.

This would be a good approach. I'm glad you have faith in your Config Management team

Try "the simplest thing that could possibly work" first, and only if you really encounter a problem start thinking about solutions.

100% best mindset for all of MBSE, especially where there is an element of business evolution (switch from paper to MBSE) and/or no requirement to implement a particular approach/framework etc.

5

Uml Process / Re: Multiple versions of a Component

« on: September 25, 2025, 05:24:21 pm »

I assume the Features are not mutually-exclusive, and there is no 'integration' feature in between them (i.e. they share a common interface and are basically plug-and-play into the Component). So you are essentially managing a PLE problem with multiple possible variations.
When I have done this kind of thing in the past with EA (and not saying this is the best, simplest or only way to do it) we would define each Feature in its own Package. Then each 'Product' (for you, 'Component') would be defined as a separate Block in its own Package, and would be comprised of each Feature as required. I'm sure there will be other ways to do it (e.g. I haven't used any dedicated PLE plugins for EA...), just sharing one way that we tackled this with EA.

6

Uml Process / Re: How do you keep big UML projects from turning into a mess?

« on: September 10, 2025, 05:19:32 pm »

...- document the metamodel
- build MDG technologies to aid your users to follow the guidelines
...
- training/coaching

Agree - these are hugely important. Having a documented approach, a metamodel, proper training/guidance, style guides etc should all be mandatory in my opinion. I may live in a very idealistic world, but that's the reality of model management, and especially critical when managing transition from document-based design to MBSE. Must be done from day 1!!

7

General Board / Re: Setting Attributes on multiple elements

« on: September 10, 2025, 05:17:41 pm »

You bring up an interesting point...
How does one right an add-in for EA?

My only reservation about writing an add-in is that the next version will have the feature(s) I will want and will write.

A script would be a much simpler and quicker solution.

8

Uml Process / Re: InformationFlow between Actor and UC

« on: September 09, 2025, 05:21:59 pm »

Thanks both, appreciate the input.

It's a bit unconventional, but as long as you have a clear documented purpose for this type of relation, I would not hesitate.

Yes this is increasingly my attitude to a lot of modelling to be honest - as long as something has a documented purpose (like an internal company style guide or set of rules) then it is a lot easier to justify bending rules... depends on the tool a little bit as well I guess.
It's also a challenge I've found when working with companies/programmes that are moving from documented design into a modelling environment. If people/businesses are less experienced in modelling (and I am by no means a veteran) then little 'features' like this one seem to creep in because they make sense to the person who drew the diagram. Sometimes it's easier to document the oddity rather than educate an entire team on every specificity of the UML & SysML specs (as the idiom goes: 'ask for forgiveness rather than permission'). But then again, I'm also naturally quite pedantic about syntax and am more inclined to try to educate myself directly from the specs whilst the business just wants a model that looks "graphically ok" and is "acceptable by a customer".

9

General Board / Re: Not being able to type a FlowProperty with a Signal

« on: August 21, 2025, 05:30:55 pm »

In the properties window of the FlowProperty, under Type.

This worked in older EA Versions. I used it through Version 16. And I am pretty sure it worked in the release version of 17.

I was trying to model the signal flow in an IBD. And while creating the InterfaceBlocks I noticed this bug.
Based on the SysML specification: "A FlowProperty shall be typed by a ValueType, Block, or Signal."
Value Type and Block still works though.

Yeah you're doing everything that should work then I think, sounds like a genuine bug!

10

General Board / Re: Not being able to type a FlowProperty with a Signal

« on: August 20, 2025, 05:26:32 pm »

This is of no help to you but I can confirm it does work in 1625 and there's nothing in the release history to suggest that this functionality has been altered in any way since then.
Sorry I don't have 1710 to hand to help you out further.

Out of interest, how are you trying to apply the signal type to the flowproperty?

11

General Board / Re: Extending SysML Requirement

« on: July 28, 2025, 05:48:45 pm »

Good to hear.
Out of curiosity what was the issue and how will it be addressed?

12

Automation Interface, Add-Ins and Tools / Re: how to change default apperance for MDG stereotypes

« on: July 23, 2025, 05:14:07 pm »

I see a lot of views on this topic, could someone of viewer reply to me with a solution  ?

This is normal for this forum I think - usually means that lots of other people have the same question and nobody has worked out how to solve it. Sadly for you, I am one of them! Hopefully one of the Clever Ones will log in soon and help you.

13

General Board / Re: bulk positioning multiple embedded elements (interfaces) of a component?

« on: July 23, 2025, 05:11:43 pm »

As far as I know this is the expected behaviour in all versions of EA to date. I think everyone would agree it would be desirable to be able to move multiple exposed interfaces at once, but for whatever reason this is how the tool behaves.

14

General Board / Re: Posting UML/SysML Diagrams to this Forum

« on: July 18, 2025, 05:20:35 pm »

There is a *model* behind any diagram.

Clearly we have worked with different colleagues

Primarily, a model would have to be embedded into the post, to make it editable.

I wouldn't suggest making it editable, just a simple way to throw a static diagram on the screen to illustrate a point or a query

There are already alternatives worth considering:
...PlantUML - online tool https://www.plantuml.com/ may be used to quickly build sample diagram, if graphical visualization is desired (but not critical nor EA's specific).

Yes there are tools out there to stick together something using UML/SysML notation - even dia or powerpoint can do that for you! It's just fiddly and time consuming that an image has to be created in another tool, uploaded to an external server and then linked here - if the forum engine could handle drawing and hosting simple images they could be embedded in posts with no need for external hosting.


I'm not expecting anything to happen, just dumping some of my brain contents to make space for something actually useful

15

Uml Process / InformationFlow between Actor and UC

« on: July 15, 2025, 07:34:01 pm »

I seem to remember ages ago seeing Something Somewhere that said it is incorrect to link Actors to UCs with InformationFlows that describe the information flowing in/out of that UC (i.e. the Actor is using a system via that UC and the UC diagram also specifies the data flowing in/out of the system's Behaviours).
However, para 20.2.1.5 "InformationFlow > Constraints" of the UML spec states "The sources and targets of the information flow can only be one of the following kind: Actor... UseCase...", which would seem to imply that it is permitted to attach InformationFlows to the Actor-UC Associations on a UC diagram.

Does anyone have any thoughts on this? Is it permitted/forbidden/unrecommended?

If nothing else I guess that maybe it is 'permitted' but only when it is technically correct to do so (i.e. when the Actor is actually the entity that literally sends that InformationItem into the system or receives from it).