Messages

1

Uml Process / Re: SysML > IBD > connectors: Is there a customary & agreed notation for data rate ?

« on: July 22, 2024, 05:57:54 pm »

Well, it depends on what you expect.
For me expressing the things is more important, than “super standard” compliance.

100% agree. I've not yet worked in an organisation where there was any kind of auditing against the SysML spec (and I'd be interested to know how many organisations actually go that far).

Interesting feedback on the diagram frame behaviour in EA17. I can see why they would do that but as you say there may be times when it is desirable to intentionally bend the rules of the SysML spec to do things like that. Would be nice if features like that had an 'off' switch a bit like the 'strict connector syntax' option.

2

Uml Process / Re: SysML > IBD > connectors: Is there a customary & agreed notation for data rate ?

« on: July 19, 2024, 07:25:32 pm »

Not a bad idea - it certainly gives you the power to query the model and work out the associations between the structural and behavioural views, and if that's what you're after then it's a valid solution Tthe ability to 'freestyle' stuff like that is both EA's greatest power and its biggest potential weakness.

3

Uml Process / Re: SysML > IBD > connectors: Is there a customary & agreed notation for data rate ?

« on: July 19, 2024, 01:48:18 am »

Well linking structural and behavioural stuff, is poorly supported in SysML anyway.

I guess that's deliberate - structure and behaviour are 2 different views of the same design, so there will be some mapping (e.g. use of SysML 'Allocate') but they are intended to represent different concepts. My suggestion was a bit cheeky really... there isn't (and shouldn't be) any direct equivalence between an IBD ItemFlow/Connector and an ActivityDiagram ObjectFlow (because they represent 2 separate concepts) but I guess I wondered if EA would allow us to 'cut the corner' and show some relationship (either formal or informal) between the 2. Naughty me!

Edit: apologies for thread-jacking...

4

Uml Process / Re: SysML > IBD > connectors: Is there a customary & agreed notation for data rate ?

« on: July 18, 2024, 08:54:53 pm »

In such a case I just add this information as a "contraint" to the connector,, just because it is a "cheep" solution.

I've had a bit of a play around and I agree this is a nice neat solution.
I can't remember if there is a way to tell EA that an ItemFlow/Connector pairing on an IBD represents an existing ObjectFlow on a related Activity Diagram, but maybe that could be one way to link the structural and behavioural views... (the same Constraint could be applied on the IBD and the AD)?

5

Uml Process / Re: SysML > IBD > connectors: Is there a customary & agreed notation for data rate ?

« on: July 18, 2024, 05:51:19 pm »

Maybe different for different people, but I think an IBD is generally used for 'static' structural modelling - i.e. defining the data items that 'can' be passed between structural entities. Once you start talking about rate, you are talking more in the behavioural domain than the structural domain, so maybe an Activity Diagram would be better suited to modelling rate.
Section 11.1.2 of the SysML spec introduces Continuous Systems, where flows can have rates. Maybe that's a good place to start?

Alternatively, and especially if you aren't bothered about simulating your model and other exciting things like that, then annotating the rates as simple labels (which I think is what you're suggested) or including it as a tagged value of the ItemFlow in your IBD would certainly work fine and I don't think there is any international standard notation to worry about!

6

General Board / Re: SysML - How to model an Ethernet switch - as full port(s) - which part(s)?

« on: July 17, 2024, 05:57:27 pm »

But please don't go the direction that I've seen one customer go with by demanding one Port per signal in the interface(!).

Wow...

Assuming a signal is an app output, in my case that would be dozens; if it's an information item, that would be 1000s. So it would not have occurred to me to make a separate port for each signal.

...yep!

7

General Board / Re: SysML - How to model an Ethernet switch - as full port(s) - which part(s)?

« on: July 16, 2024, 08:37:57 pm »

Not bothered at all about internal struct & behav of the switch itself. So modeling the switch as a full port is good (- better than I expected).
Just that the switch connects with several external devices. So is that still ok to make the switch a full port?
I think yes, coz I can make the switch a 'nesting port' (*1), as well as full port, where it contains the right number of nested ports.

I think in your case having the switch (by which I understand you to mean the physical ethernet connector, not a network switch) as full port does make sense, but there will just be very minimal (or no) specification within that full port.

The SysML spec (section 9.1.3) says "[full] ports specify separate elements of the system", implying that you want to treat the port as something physically separate from the rest of the system/components (which makes sense in your case I think). However, section 9.3.2.9 states "[full ports] might have their own internal parts and behaviors to support interaction with the owning block, its internal parts, or external blocks. They cannot be behavioral ports, or linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts".

So to clarify my responses, maybe you have 2 options:
i. use full ports, but simply ignore (or neglect to specify) the internal structure & behaviour of the port
ii. use proxy ports but then make sure that you actually specify the behaviours in your other structural Blocks, and expose that via the proxy port, per the SysML spec

As I said, I'd personally be tempted to go with option (i), based on my previous experience elsewhere. And it probably wouldn't matter much anyway unless there was a particular requirement or contraint e.g. from a customer or auditor.


In terms of the nested Ports, I think what you're saying does make perfect sense; one Port per connection can help separate out logical or physical links within an interface. But please don't go the direction that I've seen one customer go with by demanding one Port per signal in the interface(!).

8

General Board / Re: SysML - How to model an Ethernet switch - as full port(s) - which part(s)?

« on: July 16, 2024, 06:12:05 pm »

The answer might be 'it depends' - e.g. it might depend on whether or not you are bothered about the internal structure and behavoiur of the ethernet switch itself.
In my experience (maybe not the same for everyone else) I would be less bothered about the ethernet switch and more bothered about what I do with the data once it's in my system - i.e. I would want to spend my time modelling my own system's structure & behaviour, and possibly pull the design of the ethernet switch as COTS. So I would probably use a full port for the ethernet connector and only characterise its flowproperties using an InterfaceBlock (to help me define an ICD for the system).
If you use a regular Block for the ethernet switch/connector, the implication is that you want to specify its internal structure and behaviours. Maybe your company does that, in which case it would be appropriate.

9

General Board / Re: Duration for Activity Diagrams

« on: July 10, 2024, 06:00:45 pm »

I think the 'textbook' answer is to make sure you're using the right tool for the job. i.e. if the SysML spec (or EA) can't constrain Actions by time then maybe you could look into using Interactions (i.e. Sequence Diagrams or UML Timing Diagrams) - see section 11.1.5 of the SysML spec.
Alternatively, if you don't actually need to simulate the Activity using EA's built-in Simulation feature, then you could just add a Tagged Value called 'Time' to each Action and then you'lll be able to aggregate them quite easily using a script or something similar.

Honestly though I've never really tried to do what you're doing, and there may be some clever stuff you can do achieve your goal with the Activity features of EA. I'd also be interested to know if it's possible.

10

General Board / Re: Diagram frames in UML ?

« on: July 04, 2024, 06:01:12 pm »

One minor but interesting difference is that this means that EA can render Relationships (Connectors) between Elements and diagram frames on composite diagrams, but does not do so on UML composite structure diagrams (I guess because the frame of a SysML diagram effectively represents a Classifier). This isn't mentioned in the SysML spec (Appendix A) although it also isn't explicitly forbidden.

11

General Board / Re: Relationship directionality and verbs

« on: July 03, 2024, 05:48:06 pm »

The implication of the subject|verb|object metaphor is:
1. The subject is the source,
2. The verb/verbs is the connector, and
3. The object is the target.

To construct the sentence A car (subject) consists of (verb) wheels (object). We need to put “car” as the source and “wheel” as the target of an aggregation relationship, with, if I am not mistaken, the diamonds on the car side. This is counter intuitive and I am not sure Sparx EA works this way.

I agree with your logic here, and also agree that this makes it look A Bit Weird - i.e. the diamond ends up at the source end of the Aggregation connector, which doesn't immediately seem logical with a directed Relationship.
Maybe I spent too long in the past thinking about UML Interfaces, but somehow I approach each directed Relationship as "a directed Relationship consists of one thing that needs something (the 'required' interface / the target) to another thing that provides that needed thing (the 'provided' interface / the source)". In that case, you could argue that our sentence reads "A wheel belongs to a car" (i.e. the car is providing context for the wheel to be a meaningful part of something bigger). It's maybe a bit of a stretch, and certainly doesn't read so well in English as your original sentence "A car consists of wheels".

12

Automation Interface, Add-Ins and Tools / Re: Redefining an ArchiMate element does not work as expected?

« on: July 03, 2024, 05:38:32 pm »

Could it depend on where the MDG is located?
If the MDG is saved within the same model's Resources then maybe relaunching EA is not necessary, but with an MDG saved to the local disk I guess the relaunch is needed so that EA goes to the disk (/server) and brings in the MDG definition from the xml again.
Just a guess based on some thing I've been doing recently.
In any case, I'm with the rest of you - "Troubleshooting step 1 is to turn it off and on".

13

General Board / Re: Relationship directionality and verbs

« on: June 26, 2024, 07:20:00 pm »

Composite Aggregation a part can only belong to one whole at a certain moment in time. (and will be destroyed with the whole if not detached)
Shared Aggregation a part can belong to many wholes at the same time. When a whole is destroyed all parts remain.

This bit seems critical and is certainly very useful to me in understanding the difference.
Thankyou for these clarifications!

14

General Board / Re: Relationship directionality and verbs

« on: June 25, 2024, 09:03:56 pm »

Have slept on this and I think I'm overthinking it. I think.
The reason I'm having a hard time coming to a clear conclusion is because the problem I'm tackling at work has multiple viewpoints, from which Aggregation or Composition could variably make sense.
It relates heavily to my thread in a different sub-forum so I'll stop hijacking this one and I'll take the discussion over there to keep it all in once place.

https://sparxsystems.com/forums/smf/index.php/topic,48546.msg281535.html#new

15

General Board / Re: Relationship directionality and verbs

« on: June 25, 2024, 01:11:33 am »

With respect, I believe the composition relationship is not as you describe it.  You may be confusing the classifier with the instance.  You are correct in asserting that destroying (not deleting - more later) the Car classifier doesn't destroy the Wheel classifier.  However, at the instance level, if the wheel is attached to the car, it must be destroyed with the car (think "nuked")!  However, the wheel may be detached from the car (and therefore no longer participates in the composition) then it survives.

This is the essential difference between composite aggregation (aka "Composition") and shared aggregation (aka "Aggregation").  Aggregation is like Team membership, you can destroy the team without destroying the players.  Also, a player can be in more than one team at the same time whereas the wheel can only be on one car at a time.  The other distinguishing mechanism for which type of "holonymy is in play".

As I said, I treat every day as a school day. Looks like I need to go back to class, or at least wake up properly before posting.
I'd love to understand the philosophical aspects of all this a whole lot better. For one thing, the subtle difference between 'delete' and 'destroy' which I had never really understood properly.

*Could* you say that the 'car/wheel' Relationship can be described as both Aggregation AND Composition when considering either classifiers or instances? i.e.
> Aggregation in that there is not really any such thing as a 'car', that's just what you end up with by collecting (aggregating) enough bits and pieces (including, but not limited to, Wheels) together and attaching them in the right order. But any one of those pieces (e.g. 'Wheel' or 'Chassis') can exist perfectly well on its own without having to be 'Part of a Car'
> Composition in that once you destroy an instance of a Car, all of its constituent Parts (e.g. its 'wheel' instances) are also considered destroyed

At one point I thought I understood these concepts but now I'm not so sure...



Also major apologies for hijacking the thread, happy to continue this privately unless it is useful to other people too?!