На диаграмме вариантов использования актор «Менеджер» должен участвовать во всех сценариях актора «Сотрудник» и ещё в нескольких дополнительных, но аналитик продублировал все связи вручную. Какой механизм UML устранит это дублирование?
Используйте обобщение акторов: «Менеджер» должен быть специализированным актором, а «Сотрудник» — обобщённым. Тогда «Менеджер» наследует связи с вариантами использования «Сотрудника» и может иметь собственные дополнительные связи.
Это не означает, что менеджер автоматически получает любые права системы. Обобщение корректно только тогда, когда участие менеджера во всех сценариях сотрудника действительно является частью модели требований.
UML развивался как унифицированный способ описывать структуру и поведение системы до начала реализации. В моделях вариантов использования потребовался механизм представления ролей, между которыми есть отношение специализации, чтобы не повторять одинаковые связи на диаграмме.
Обобщение решает проблему избыточности и одновременно фиксирует смысловое утверждение: специализированный актор может выполнять поведение, доступное обобщённому актору. Это отличается от простой связи актор—вариант использования, которая показывает только конкретное взаимодействие.
Ручное дублирование связей делает модель громоздкой и создаёт риск рассинхронизации. Если для «Сотрудника» добавят новый сценарий, аналитик может забыть добавить такую же связь для «Менеджера».
Однако механическое применение обобщения тоже опасно. Оно утверждает, что менеджер обладает ролью сотрудника в контексте рассматриваемой системы; если менеджер лишь иногда взаимодействует с теми же функциями, наследование будет искажать права и границы ролей.
На диаграмме создают связь generalization от актора «Менеджер» к актору «Сотрудник»: специализированный элемент направлен к более общему. Связи «Сотрудника» с вариантами использования считаются доступными и «Менеджеру», а его дополнительные возможности показываются отдельными ассоциациями.
Важно отличать это от ассоциации. Ассоциация означает факт взаимодействия конкретного актора с вариантом использования и не выражает наследование поведения. Если вместо обобщения оставить только отдельные ассоциации, модель сохранит факт взаимодействия, но потеряет иерархию ролей и будет требовать ручного дублирования.
Обобщение следует применять, когда выполняются оба условия: специализированная роль действительно включает поведение общей роли, а это отношение важно для целей модели. Если различие между ролями зависит от конкретного подразделения, временного назначения или внешней политики доступа, его лучше описать ограничениями, правилами авторизации или отдельными требованиями, а не UML-иерархией.
Следует также проверить направление отношения и границы системы. Обобщение акторов не заменяет матрицу полномочий: диаграмма вариантов использования показывает доступное взаимодействие на уровне целей, но не обязана описывать все условия разрешения каждой операции.
В корпоративном портале «Сотрудник» может подать заявку на отпуск и просмотреть свои заявки. «Менеджер» выполняет эти действия, а также согласует заявки подчинённых.
Рассматривались три варианта. При полном дублировании ассоциаций диаграмма была бы понятной локально, но любое изменение потребовало бы правок в нескольких местах. При отказе от связи между ролями можно было избежать спорной иерархии, но потерять явное утверждение о совместном поведении. Обобщение компактно выразило общую роль, однако потребовало отдельно проверить, что все менеджеры действительно сохраняют права обычного сотрудника.
Выбрано обобщение «Менеджер» к «Сотруднику» и отдельная ассоциация менеджера с вариантом использования «Согласовать заявку подчинённого». В матрице доступа дополнительно зафиксировали условия видимости заявок. В результате диаграмма стала устойчивее к изменениям, а спорные ограничения не были ошибочно спрятаны в структуре UML.
1. Означает ли обобщение акторов, что специализированный актор обязан участвовать во всех сценариях общего актора?
Нет, оно означает наследование возможностей и связей на уровне модели, но конкретная применимость может зависеть от ограничений. Если участие «Менеджера» в каком-либо сценарии запрещено при определённых условиях, это нужно явно описать правилом или ограничением; простая иерархия такую условность не выражает.
2. Когда вместо обобщения нужно использовать две независимые роли?
Когда роли не образуют устойчивого отношения специализации. Например, один пользователь может временно получить функции менеджера, но это не делает его отдельным типом пользователя во всех сценариях. В таком случае независимые акторы или модель ролей и полномочий точнее отражают предметную область.
3. Можно ли считать обобщение акторов доказательством фактических прав доступа в системе?
Нет. Это элемент требованийной модели, показывающий отношение ролей и наследование участия в вариантах использования. Реальные права могут зависеть от подразделения, объекта, статуса заявки или других условий, поэтому их необходимо дополнительно фиксировать в требованиях, правилах доступа и критериях приёмки.