Блог

В отличие от диаграмм классов, кажется, что можно моделировать множество аспектов системы на блок-схемах, таких как программное обеспечение, аппаратные средства, объекты и т.д.

Возможно ли, что один блок может представлять как программное, так и аппаратное обеспечение? Или они всегда будут разделены на два отдельных блока? Например. При моделировании некоторого оборудования, допустим, у оборудования есть физическая кнопка, и программное обеспечение оборудования также имеет программный класс «Button». Будут ли они смоделированы как отдельные блоки или как отдельный блок?

Тот же вопрос можно задать объекту базы данных, который сопоставлен объектно-ориентированному языку как класс, и указанный объект также представляет реального физического субъекта (например, класс программного обеспечения «User» и реального физического пользователя).).

В случае, если один блок может представлять несколько аспектов, существует ли какая-либо форма обозначения, указывающая «этот блок представляет как аппаратное, так и программное обеспечение» — или это просто подразумевается на основе блока, имеющего множественные и отличающиеся аннотированные отношения с другими блоками?

Системный инженер обычно хотел бы разделить физические компоненты и программные компоненты. «Цифровой двойник» в программном обеспечении не всегда точно представляет свой физический объект. Например, плохое распознавание может привести к тому, что цифровой двойник будет неточным представлением компонента в реальности. Представьте положение автономного транспортного средства в пробке или «зависающий» 737 MAX.

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

Отвечая на ваш вопрос, ничто не мешает вам моделировать все как один блок, но, если вы объединяете вещи в модели, вы не можете рассуждать о них по отдельности. Почему вы хотите смоделировать физическую вещь и ее цифрового двойника или класс Java и таблицу базы данных как один и тот же блок SysML?

Все зависит от того, что вы пытаетесь передать. Всегда моделируйте и создавайте представления с учетом конкретного использования модели и представлений.

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

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

Если у вас нет конкретного представления о том, что вы пытаетесь сообщить, но пытаетесь понять, где заканчивается одна концепция и начинается следующая и как вообще думать обо всем этом беспорядке, попробуйте несколько способов, и вы, вероятно, получите лучшее представление о проблеме и приведете в порядок свое мышление. Если объединенный блок не показывает того, что вы пытаетесь «сказать», попробуйте разные комбинации блоков и взаимосвязей. Когда вы найдете что-то полезное, что решит проблему, остановитесь.

Не увязайте в языке