SysML - How to model an Ethernet switch - as full port(s) - which part(s)?

[avi10000]

Hi all,

Excuse me for asking a non-EA-specific question here, but I wasn't getting answers anyway else.

SysML: I want to model an Ethernet switch that is part of a computer board (comprising a CPU and additional HW components).

Is the most appropriate approach, to model the Ethernet switch itself as a full port (on a side of the board) ?

Or alternatively should the Ethernet switch be a regular block, and its physical ports / interfaces should be full ports?

Other ... ?

Thanks
Avi

[PDC]

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.

[avi10000]

Thanks for the response, PDC.
 
> it might depend on whether or not you are bothered about the internal structure and behavoiur of the ethernet switch itself.

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.

That's good?

Note:
*1 - I just made up the term.

Edit: I added the note.
 

[avi10000]

Btw, should I have posted this question under the UML Processes board?
If so, how can it be moved?

[PDC]

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(!).

[avi10000]

Thanks for the response, PDC.

Btw, I forgot to point out (the obvious) that the sketch I received is of the HW aspect only of the system.

i. use full ports, but simply ignore (or neglect to specify) the internal structure & behaviour of the port

Also, the sketch I have (so far ...) is just a structure (static) diagram. No behaviors to model yet (relevant to activity diagrams or sequence diagrams).

Looks like I will be going with the full port approach. A full port and also nesting will be a new experience for me.

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.
 

[PDC]

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!