Messages

31

Automation Interface, Add-Ins and Tools / MDG profile: Port typed by InterfaceBlock

« on: May 16, 2024, 12:58:40 am »

I am defining a SysML profile using the metamodel tools.
I've defined a bespoke Stereotype that extends the metaclass 'Port' (let's call it 'PortNew').
I've defined a bespoke Stereotype of the metaclass InterfaceBlock using a Generalization (let's call it 'IFNew').
I've added 'PortNew' to a new toolbox and can add it to Blocks on a BDD. However, I want to be able to set up the profile so that any time I add a 'PortNew' to a Block it uses IFNew as the Port's interface definition - i.e. as 'Type' under the Port Element Attributes.

Is this possible? I can't figure out how to set it up in the metamodel.
tia

32

General Board / Re: Do you model separate blocks when creating interfaces in SysML?

« on: May 14, 2024, 06:40:15 pm »

I am afraid my understanding is not correct, so please tell me if my post is wrong.

No I totally agree with everything you said there (I wrote a long response explaining that I agree, and then my network went down as I pressed 'Post' so it was lost. But you are correct!)

After posting my previous post I continued playing around and found that EA was behaving inconsistently. Actions like restarting EA or opening/closing different Element properties was affecting the display of the labels on the diagram. I do agree that it is strange that it lets me set the InterfaceBlock FlowProperty as the itemProperty on the ItemFlow... maybe that's where I had managed to confuse EA into showing something that it shouldn't.

33

General Board / Re: Inheriting Signal attributes

« on: May 14, 2024, 12:55:30 am »

Right-click on s2, choose 'Compartment Visibility' and select 'Inherited Attributes'. The inherited Attribute will then be displayed.

Do you need to be able to manipulate that variable from s2?

34

General Board / Re: Do you model separate blocks when creating interfaces in SysML?

« on: May 13, 2024, 07:57:23 pm »

Excellent summary, thanks. And that is how it worked out in my case as well.

No problem... although I have to admit that now I go back into my sandbox area it is rendered as "Water {Water}", not "Water: Water". I think this is purely a graphical thing though and the underlying semantics are equivalent. Water/water... Potato/Tomato...

I just have this one last theoretical question regarding the InterfaceBlock. If in my case I have different messages all of the same type, then I think the flow properties need to be on the owning block, and not in the InterfaceBlock. Suppose you had two messages of type CAN: speed, torque. Then I would have two ports typed by an InterfaceBlock called CAN. If I have the flow properties on the InterfaceBlock, then anytime I type a port with a CAN InterfaceBlock, it will have both properties and I want to avoid that, which makes me think perhaps the block has to own the flow properties. The InterfaceBlock would have just the common information.

Personally I wouldn't worry about this. For one thing, I don't think Blocks *can* own FlowProperties - they have to belong to the InterfaceBlocks.
At the same time, the InterfaceBlock defines what is permissible to flow across that interface, as a static representation of the interface agreement between 2 entities. You then use the rest of the model to describe what actually does pass over that connection in different circumstances. So you might know that it is an RJ45 connector, and there is an almost infinite number of different information items that 'could' be sent over that interface, but you use the IBDs to give context for a particular scenario, and use logical modelling to describe how the InterfaceBlock decides what is sent (e.g. an Activity Diagram that illustrates a choice, like "if a data packet of type packetA is received from the internal Block, then send out a packet of type 'packetB' on the external connection").
I guess it all depends on what your model is trying to communicate though

35

General Board / Re: Do you model separate blocks when creating interfaces in SysML?

« on: May 13, 2024, 07:22:06 pm »

Think I understand the question a bit better now.
I think the following steps give a semantically-similar result.
This includes all steps to build an ICD.

1. create the data definitions (e.g. define 'Liquid' and 'Water' as Blocks, with 'Water' as a Generlization of 'Liquid')
2. create an InterfaceBlock with a FlowProperty that represents the data items permitted to pass over that interface (e.g. a FlowProperty called 'Water' that is typed by the 'Liquid' Block, or another FlowProperty called 'gasoline' that is typed by the 'Liquid' Block)
3. add Ports to your Structural Blocks and classify them using the InterfaceBlock (helps give your ICD meaning)
4. draw the ItemFlow between the Ports and add an InformationItem typed by the 'Water' Block and 'itemProperty' tagged value set to be the flowProperty defined within your InterfaceBlock definition
5. draw a Connector between the Ports and link it to the ItemFlows relevant to a particular context*

What you should see on the ItemFlow/Connector is "Water: Liquid"

* on another diagram, you might have an ItemFlow carrying the 'Gasoline' data item, which would be rendered "Gasoline: Liquid". This lets you should the same connection with different flows for different scenarios/contexts

36

General Board / Re: Do you model separate blocks when creating interfaces in SysML?

« on: May 13, 2024, 05:40:18 pm »

Suppose I have 10 signals like CAN messages for example, that are sent from one block to another. All are signals of the same type (CAN).
Do I model 1 block of type CAN and then create multiple item flows using that same type?
Or do I create 10 CAN blocks for example, each with a different name and then refer to them in the item flows?

You *can* (no pun intended) do either, but personally I would do the first option. Define 'CAN signal' as a Block and use it as the Classifier to type the data items flowing around your system. That way you can add generic descriptions to the classifier and only have to do it once. And it's applied consistently throughout. YOu can also do this using just one itemflow and attach all 10 CAN data items to that one flow, although this assumes some semantics... e.g. that all of the 10 items generally flow across that link in the same scenario. If there are different scenarios then multiple data flows would help you illustrate the specific data flows in each case.
If you need to create a hierarchy then that could be useful (e.g. if all 10 signals are broadly the same, but then 5 of them have some special characteristic that the other 5 don't).

Hope some of that helps... though it's probably easier to illustrate my points graphically rather than English-ly.

In the book by Friedenthal, Practical SysML there was an example of using flows of electricity (DC). The notation used there I could not get in EA:
azm supply : DC
fm supply : DC
elm supply : DC
I suspect the DC is of course a block, but the names to the left I cannot figure out how to do in EA. The reason I am confused is because a block represents a type, so I have doubts about creating 10 CAN blocks when all are of the same type. In EA however, I can't seem to distinguish them. All 10 connections just show CAN.

Can't be 100% sure without seeing the notation (I don't have the book) but it looks like 'DC' is a single classifier (a Block) and then 'azm supply' et al are the names of instances of that classifier.

37

General Board / Re: Removing a linked document in v16.1.1628

« on: May 09, 2024, 11:59:13 pm »

Here's one way:

1. select the Element that has the Linked Document
2. on the ribbon, go to 'Portals > Windows'
3. select 'Document' under 'Properties'
4. the 'Document' window should now appear (somewhere)
5. use the hamburger icon and select 'Delete Linked Document'

38

General Board / Re: Modeling interfaces in SysML

« on: May 09, 2024, 06:32:16 pm »

For me it partly depends on the requirements for your model. i.e. do your stakeholders need you to be able to present the logical view and the physical layers separately? In that case, it is normally going to be easier to model both Ports separately and, as you suggest, draw the traceability between them - e.g. using 'Allocate'. However, if your stakeholders are less bothered about that (or don't understand the question) then maybe you can [cut some corners and] somehow model both layers using a single Port. My personal preference is to keep the functional, logical and physical views separate in the model - so I would have a logical Port and a physical Port in your scenario.

I also sometimes find that 'nested' Ports are useful in this context.

You mention the 'literature' - maybe you have already read this paper but I think it's a good discussion on a related subject: https://www.omgsysml.org/A_modeling_pattern_for_layered_system_interfaces-INCOSE%20IS15_paper-sarrel-shames.pdf

39

General Board / Re: Associating SysML object states with parts lists

« on: May 09, 2024, 06:16:32 pm »

Sounds like a reasonable way of mapping it to me. As long as it works for you then it's not worth getting overly bogged down in SysML semantics.
I did wonder if there might be a way for you to attach your Blocks to the State transitions in the STM - i.e. "in order to get from StateA to StateB, Block1 must be added to the build". But I've not played around with it myself. Probably several ways to do what you're trying to do if you aren't too worried about semantics.

40

Automation Interface, Add-Ins and Tools / Re: [SELF-SOLVED] Redefining Quicklinker captions

« on: May 08, 2024, 12:21:57 am »

If you use the profile helper, you can simply fill in fields like MeaningForwards and MeaningBackwards. The tool will automatically create the attributes with the correct name on the correct item.

Geert

This is how I solved it - had avoided the profile 'helper' based on previous misconceptions but in this instance it actually did prove very helpful! Egg on my face.

Cheers

41

Automation Interface, Add-Ins and Tools / Re: Redefining Quicklinker captions

« on: May 07, 2024, 11:38:47 pm »

Apologies, I fixed this within 10 minutes of posting the question.
For posterity, the answer seemed to be:
1. my new 'validate' Stereotype must extend the 'Trace' EAUML metaclass, not redefine the 'SysML1.4::trace' Stereotype
2.'_MeaningForwards' and '_MeaningBackwards' must be applied to the 'Trace' EAUML metaclass, not my new 'validate' Stereotype or the 'SysML1.4::trace' Stereotype

This does only provide my desired captions in the Quicklinker; the Traceability window still uses the terms 'Needed by' and 'Traced from', which is a bit inconsistent and annoying but I can live with that.

I'll stop talking to myself now...

42

Automation Interface, Add-Ins and Tools / [SELF-SOLVED] Redefining Quicklinker captions

« on: May 07, 2024, 11:20:04 pm »

I'm building an MDG technology using a Profile Metamodel and finding it difficult to redefine the Quicklinker captions. I've looked around online and it seems that this has been a bit of a buggy area over time. I'm in 16.1 (1628).

Specifically, I have a created new Stereotype 'validate' that I want to use to show that a Requirement is <<validated>> by another Element.
My 'validate' Stereotype redefines "SysML1.4::trace", and everything works fine except that the Quicklinker sub-menu caption still says 'Traced To'. I would like the caption to say "Validates" or "Validated by" (depending on the direction in which the Relationship is drawn). Is this possible?

_MeaningForwards and _MeaningBackwards (when applied to my 'validate' Stereotype) do not seem to make any difference in the Quicklinker nor in the Traceability window.

Thanks for any pointers!

43

Bugs and Issues / Re: Sparx claims inactive diagrams have been changed by other user

« on: April 29, 2024, 10:00:05 pm »

My work around is the old microsoft office one, ctrl-s every time I change something.

Agreed! I learned this habit from Eclipse where Ctrl+S also compiles the code

44

Automation Interface, Add-Ins and Tools / Re: Hiding the remaining Generic Links in QuickLinker

« on: April 29, 2024, 07:13:14 pm »

About: Hide Default Quick Linker Settings
https://sparxsystems.com/enterprise_architect_user_guide/15.1/modeling/hiding_default_quick_linker_se.html

Unfortunately, as described at the end of the:
"Note that this technique does not affect the automatic appearance of 'Dependency', 'Trace', 'Information Flow' and 'Help' options on the Quick Linker menu"

When shall we have this fixed? (We have been asking that for years)

I'll ask for it to be updated to reference the help for _HideUmlLinks instead.

Apologies for resurrecting an old thread but this is relevant to me.
It seems that this has been corrected for Dependency, Trace and Help, but I still see 'InformationFlow' in the QL options, alongside my own profile links. The note has been removed from the Help page linked above, so I assume the intention was to remove all of these links, but InformationFlow is still there.
Is this still the case for anyone else? I'm in 16.1 (1628).

45

General Board / Re: Are you model-based without a Pro Cloud Server License?

« on: April 26, 2024, 06:12:21 pm »

Absolutely agree. 'Being MBSE' does not mean 'using one tool'. It's probably the exception where a single tool is used, and that's why there are so many integration tools, plugins etc (and so many threads on these forums with people addresing integration issues).

I'm a big advocate of 'use the right tool for the job'. So for me, EA, Jama, DOORS, Cameo, (Jira...?!)...... they are all legit tools for managing requirements in an MBSE environment. but when people suggest 'adding Sequence diagrams into DOORS' I start to twitch

Sounds to me like you have the right mindset though. Digital thread, traceability, consistency... they are fundamental concepts addressed by MBSE, and your chosen toolset (in your case, maybe Jama + EA) is the mechanism for efficiently managing those concepts.