Моделирование этих ролей с использованием действующих лиц в анализе вариантов использования

Question

Я моделирую систему, которая имеет (среди прочих) следующие типы ролей:

1. Индивидуальный игрок
2. Групповой игрок

Вотнекоторые дополнительные факты:

• Существует ряд функциональных требований для отдельного игрока
• Существует несколько типов групповых игроков (например, стрелок, штурман, инженер и т. д.)
• Выбор (то есть тип) группового игрока влияет на то, какие функциональные возможности доступны игроку
• Функциональность группового игрока представляет собой объединение: (a) подмножества вещей, которые отдельный игрок можетdo (b) (опционально), некоторые дополнительные требования, основанные на роли (например, рукопашный бой и т. д.).

Я могу абстрагировать актеров, как специализацию обычного игрока - но яне совсем уверен, как «собрать все это вместе» как часть «формального анализа» системы.

Может кто-нибудь помочь?.

Answer 1

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

Из вашего описания звучит так, что индивидуальный игрок является актером, а групповой игрок - ролью.Роли касаются администрирования, и вам могут потребоваться варианты использования, связанные с администрированием.

Таким образом, ваши актеры Marksman, Navigator и Engineer будут относиться к типу Player.Ваши роли стрелков, навигаторов и инженеров будут вашими групповыми ролями.Варианты использования, определяющие функциональность, с которой взаимодействуют актеры Marksman, Navigator и Engineer, не будут иметь дело с ролями, потому что роли - это то, «как» их реализуют.актер в суб-акторы, вы можете начать фактически моделировать актеров - или изображать их в иерархии - на отдельной диаграмме.Это поможет вам избавиться от любых противоречий и взаимосвязей.

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

Answer 2

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

Answer 3

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

Чтобы обобщить причину обобщения актера, нужно не иметь возможность моделировать роли, а повторно использовать связанные варианты использования.