Модель потока данных от (потока) порта к диаграмме активности UML

Question

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

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

• Подключите порт к свойству (или части) и используйте ReadStructuralFeatureAction чтобы получить значение
• Подключите порт к свойству (или части) и добавьте операцию в класс, который вызывается с CallOperation
• Создайте атрибут с тем же именем, что и порт, и предоставьте операцию, которая вызывается с CallOperation действие

Первый вариант был бы в порядке, но наш инструмент моделирования Rhapsody 8.1, похоже, не поддерживает ReadStructuralFeatureActions. Недостатком двух других подходов является отсутствие прямого соединителя между портом и активностью в модели, и он не является визуально очевидным, поэтому я хотел бы найти лучшую альтернативу.

Мне интересно, есть ли кто-нибудь знает о лучших подходах для достижения этой цели, например, используя SysML (1.3).

Answer 1

Связи между статическим и динамическим представлениями в UML и SysML "скрыты" в менее видимой части модели. Я думаю, причина в том, что дизайнеры UML хотели отделить их. Таким образом, нет никаких графических или иным образом очень явных связей.

Вместо этого связи вполне естественны, так что вы можете просто использовать их. Примерами являются охранники, триггеры или действия при переходах в диаграммах состояний или диаграммах активности. Эта операция ReadStructuralFeatureAction реализована неявным образом с использованием статического элемента напрямую. Вы можете смоделировать их прямо там. Таким образом, они происходят рядом с ребром, которое представляет переход состояния или поток управления. Дальнейшим способом является использование действий приема и установка свойства приема для события или запускаемой операции. С помощью Send Actions вы можете инициировать события в том же структурном элементе или других. При этом в Rhapsody необходимо указать целевой порт и целевую часть.

Ни в UML/SysML, ни в Rhapsody не предусмотрено, что вы хотите знать, через какой порт поступил вызов или атрибут был изменен, когда вы предлагаете интерфейс класса / блока. Но вы можете реализовать это, используя полные порты и реализуя намеченное поведение (которое может быть отличительным - иначе не нужно было бы знать источник). Таким образом, каждый полный порт имеет диаграмму состояния или действия и передает внутренние сигналы или события объекту вашего класса. Для вызова операций из действий существует два способа: более скрытый, просто вызываемый из действий (или состояния при входе или выходе), и более видимый, использующий операции вызова.

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