Какой тип элемента мне следует использовать для моделирования сообщения и его элементов данных в SysML?

Question

В SysML при моделировании сообщения у меня возникают проблемы с пониманием того, какой тип элемента должен использоваться для его определения, его элементов и порта, через который он проходит.

Я предполагаю, что это либо:

• необработанный блок
• более специализированный InterfaceBlock

Оба могут вводить прокси-порт (ранее порт потока , если я правильно понимаю), или введите большинство других свойств в других блоках, когда создается полный интерфейс сообщений или система портов (прямые порты или вложенные порты).Если базовое определение сообщения является обычным блоком , то когда вы создаете свойство потока , которое будет напечатано этим block , чтобы что-то могло фактически перетекать из одной задачи в другую через порт?

Интерфейсный блок должен происходить где-тотам, чтобы набрать порт, верно?Означает ли это, что я использую его для непосредственного определения сообщения, или это зависит от моей схемы портов (т. Е. Вкладываю ли я порты и на какой уровень)?

Полагаю, это сводится к путанице, когда вы определяетевещь (т. е. класс / блок), и когда вы определяете, что эта вещь является количеством, которое течет в вашей модели (какой-то поток - сообщение переходит от одной задачи или части оборудования к другой).

PS Я использую MagicDraw в качестве инструмента SysML, но не думаю, что это должно повлиять на основной ответ.

Answer 1

Ответ, разработанный моей командой:

1. Использовать полный порт для необработанного сетевого интерфейса физического уровня.
2. Используйте block для ввода сетевого интерфейса, включая:
   • Свойства потока, которые представляют физические элементы, вытекающие из порта, такие как общий электрический ток (power).
   • Вложенные полный порт элементы для физических вложенных портов, такие как контакты, которые составляют физический порт Ethernet.Введите с другим block .
   • Вложенные <> элементы для логических / абстрактных потоков данных через сетевой интерфейс, таких как сокеты / соединения
3. Используйте интерфейсный блок для ввода каждого логического соединения (вложенный прокси-порт ) с Интерфейсный блок , содержащий следующее:
   • Свойства потока, представляющие блоки данных, например сообщения, которые отправляются в виде группы по соединению
   • Свойства значения, определяющиехарактеристики этого соединения, такие как IP-адреса источника и назначения, номера портов, потеря связи и информация о повторных попытках и т. д. Обратите внимание, что некоторые из них могут быть лучше представлены в виде метаданных в тегах как часть отдельного стереотипа.
4. Введите свойства потока данных для соединений с ValueType , атрибуты которого являются отдельными элементами данных этого блока данных (то есть элементами сообщения).
5. Создайте новый стереотип с настраиваемым именем, например, «Элемент данных», и добавьте теги для любых метаданных, необходимых для каждого элемента данных, например длины (в битах или байтах), базового типа в сообщении, любой единицы измерения.или коэффициенты масштабирования, положение в сообщении и т. д.

В этой точке можно даже создать общую таблицу, в которой будут перечислены все элементы данных в данном сообщении или во всех сообщениях, а также добавлены всерелевантные элемент данных помечают как столбцы и используют его в качестве текущей спецификации для каждого сообщения и элемента данных каждого сообщения, а также значительно упрощают редактирование всей информации непосредственно в этой таблице.

Зачем использовать ValueTypes для блоков данных, которые проходят через Прокси-порты ?Потому что тогда они будут отображаться как Информационный поток элементов вместо Элемент потока элементов через соединитель между двумя Порты прокси на Внутренняя блок-схема (IBD) .То есть, когда я отправляю физический элемент, набранный Блоком , он отправляется как Поток элементов , но когда я отправляюЛогический элемент, такой как данные, набирается как ValueType и отправляется как Информационный поток .

Это отправная точка - мы обнаружили проблемы с вложением определений типа значений изначально, поэтому выбрали более плоское определение сообщения, содержащее все аспекты сообщения в одном ValueType ,а не вложение их.Я уверен, что есть способы обойти это, но насколько сложным ты хочешь стать?