Как смоделировать в диаграмме вариантов использования UML другую внешнюю систему на основе роли основного действующего лица?
Я моделирую программное обеспечение, которое требует взаимодействия с оптическим датчиком слежения, чтобы измерять положение некоторых объектов с помощью оптических маркеров. Обычный пользователь взаимодействует с этим датчиком (скажем, с внешней системой 1) в двух разных случаях использования (скажем, UC1 и UC2). Я хотел бы также смоделировать возможность того, что пользователь-администратор взаимодействует с программным обеспечением через те же варианты использования UC1 и UC2, но он может быть связан с программным симулятором (скажем, внешней системой 2), который имитирует реальный оптический датчик.
Я пытаюсь смоделировать этот сценарий на диаграмме вариантов использования, но я не уверен в правильном моделировании наличия симулятора и роли администратора. Я бы не стал создавать вторую пару вариантов использования, потому что они должны быть точно такими же, принятыми обычным пользователем. Ссылаясь на рисунок, я подумал добавить некоторые стрелки зависимостей (штриховые) от UC к внешней системе 2, но это будет звучать так, как и обычный пользователь может взаимодействовать с симулятором, в то время как это не должно быть разрешено.
Я извиняюсь, если этот вопрос может показаться довольно тривиальным, но это мой первый опыт моделирования программного UML.
Спасибо заранее за вашу помощь.
Симулятор в основном предназначен для обучения или тестирования, когда настоящий оптический датчик недоступен. Я мог бы подумать о моделировании дополнительных функций, специфичных для симулятора, но сейчас я их не учитываю. Мои сомнения становятся более очевидными, когда я углубляюсь в конкретизацию дизайна. Например, рисуя диаграмму конкурса, я подумал, что мне понадобится один прокси-сервис для реального датчика (который использует API-интерфейсы устройства) и один прокси-сервис для симулятора (который использует API-интерфейсы симулятора). Есть ли концептуальная ошибка в моих рассуждениях?
Это, безусловно, помогло бы правильно назвать UC. UC посвящены вещам реального мира, и перенос их на пронумерованные элементы отключит содержательные обсуждения.
Ответы 1
Начните с просмотра вашей базовой системы, как это
Таким образом, ваша система измеряет что-то с помощью датчика. Это Sensor может быть как настоящим датчиком, так и симулятором. User должно быть все равно (хотя он знает, что прилагается). Но Измерительная система действительно не будет (!) заботиться. Таким образом, симулятор должен имитировать все, что необходимо, чтобы система думала, что это обычный датчик.
Теперь этот симулятор представляет собой другую систему:
С точки зрения этой системы вы смотрите на Измерительная система как на внешнего субъекта. Кроме того, он предлагает администратору возможность устанавливать параметры цикла тестирования.
Возможно, я не смог уточнить одно из своих требований: я хотел бы, чтобы доступ к симулятору был предоставлен только пользователю с правами администратора, а обычному пользователю - нет. Кроме того, это решение предполагало бы, что Измерительная система будет содержать независимый от типа датчика код (реальный или смоделированный), в то время как по моей задумке она должна содержать соответствующие API. Это неправильный взгляд на дизайн?
Вы, вероятно, не совсем понимаете дизайн своей системы. Именно поэтому я предложил начать с ясной и простой точки. Вы можете просто применить ограничение к актеру User, который сообщает { if the simulator is used only an admin can run the measurement} или что-то в этом роде.
Вы имеете в виду, что хотите иметь реальный физический датчик или симулятор и не знаете, как это смоделировать? Используется ли симулятор по определенной причине (например, для калибровки)? Обратите внимание, что актер — это роль, поэтому, если у вас может быть реальное оборудование (настоящий оптический датчик) или манекен (программа, притворяющаяся им), вступая в роль, это не имеет значения, и вы просто моделируете ее один раз.