Нет, их функции доступны без этого.

Вам виднее. Система как-то различает авторов конференции между собой? Обычно для этого служит авторизация.

Но тут на сайт зашел модератор Злой Петух ... Он зашел на страницу трансляции, полюбовался на Ваню...

Выше указано, что для того чтобы не описывать дважды, как система демонстрирует трансляцию зрителю в рамках его UC и как она это делает для модератора в рамках UC Модерировать трансляцию, можно применить обобщение действующих лиц. Конечно, можно и не применять, я не настаиваю.

То есть, если какой-то актер (например, Модератор) может осуществлять поведение, являющееся основным для другого актера (например, Зрителя)... то это должно отражаться в МВИ?

Это может быть отображено обобщением действующих лиц. Или может отображаться в описаниях их UC.

А разве не может пользователь информировать систему: "А теперь я и Модератор, и Зритель!"?

Может. В ходе соответствующего UC.

Или в UML отдельный реальный человек может в один момент времени  быть только одним актером?

Нет. Я этого не утверждал. Система может воспринимать его под разными ролями.

Тогда возьмем ситуацию: описываем при помощи модели какой-нибудь бизнес-процесс в какой-нибудь фирме. Допустим, там будут упоминаться актеры Директор и Бухгалтер. Два разных актера с разным поведением. А теперь допустим, что в этой фирме в данный момент один и то же человек работает одновременно на должностях директора и бухгалтера. Вуаля! Один человек в роли двух разных актеров. Или что, скажете что в таком случае нужно в модель вводить актера Директоробухгалетр с двумя стрелками к Директору и Бухгалтеру (типа, множественное наследование)? Или удалять Директора и Бухгалтера, а все их поведение присваивать Директоробухгалтеру?

Мне интересно, какое из моих сообщений можно было так истолковать? В этом Вашем примере необходимость в акторе Директоробухгалтер диктуется не тем, есть ли пользователь, совмещающий эти должности, а тем, должна ли система предоставлять этой роли специфические для неё функции + функции, доступные директору, + функции, доступные бухгалтеру. Если должна, завести такого актора имеет смысл. Если не должна -- нет смысла.

А если роль человека в системе меняется со временем. Например, сперва зашел на сайт. Поглазел на трансляции как обычный Зритель. Потом авторизовался, оказалось, что он Модератор, то это все тоже надо отражать? Как? В диаграммах деятельности?

Отразить можно в описании UC Авторизоваться.

В новой версии диаграммы предлагаю UC Создать трансляцию передать Автору.

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

Учту. Меня в данном случае не столько оформление, сколько правильность построения связей интересовала.

Пользователя = Зарегистрированный пользователь (посетитель), т.е. усилить факт самой регистрации. Поскольку посетитель он тоже пользователь "большого и вечного"

ВИ "Управлять трансляцией" безлично. Имхо лучше  "Изменить настройки своей трансляции или удалить свою трансляцию". Либо вообще два отдельных ВИ - объединить можно потом, когда будет ясно, что объединять.

Меня немного смущает массивность имени ВИ. В последнем - это уже прям не имя, а краткое описание...  Это ничего?

ВИ "Изменить права доступа посетителя" - что тут имеется в виду?

В текущем контексте это пока не так важно. Здесь он взят больше до кучи. На этой диаграмме изображено всего несколько актеров и ВИ из реального их числа. Если вкратце, то Модератор может ограничивать и восстанавливать Посетителей и Пользователей в правах (например - просмотра трансляций).

По поводу зрителя - руководствуйтесь принципом Оккамы

Это такой академический вариант совета "будь попроще"?    Т.е. лучше отказаться от этого актера, а в случае чего добавить новое поведение прямо Посетителю? В-общем, я не уверен, что правильно Вас понял...

Вам виднее. Система как-то различает авторов конференции между собой? Обычно для этого служит авторизация.

Различает, но в данном случае это не авторизация, а другой механизм, который на данной диаграмме не отражен.

Выше указано, что для того чтобы не описывать дважды, как система демонстрирует трансляцию зрителю в рамках его UC и как она это делает для модератора в рамках UC Модерировать трансляцию, можно применить обобщение действующих лиц. Конечно, можно и не применять, я не настаиваю.

Теперь дошло, спасибо. Но небольшое уточнение. А если Модератор/Автор и Зритель видят трансляцию немного по-разному (например, у Модератора и Автора отображается панель с настройками трансляции, а у Зрителя - нет). Не следует ли из этого, что должны быть разные ВИ для просмотра каждым из актеров? Или сделать один ВИ, но оговаривать эти различия в спецификации?

Мне интересно, какое из моих сообщений можно было так истолковать? В этом Вашем примере необходимость в акторе Директоробухгалтер диктуется не тем, есть ли пользователь, совмещающий эти должности, а тем, должна ли система предоставлять этой роли специфические для неё функции + функции, доступные директору, + функции, доступные бухгалтеру. Если должна, завести такого актора имеет смысл. Если не должна -- нет смысла.
Отразить можно в описании UC Авторизоваться.

Да я просто запутался уже... Понял, спасибо.

В новой версии диаграммы предлагаю UC Создать трансляцию передать Автору.

Т.е. как только Пользователь собрался создавать трансляцию, мы начинаем считать его Автором. И создает трансляцию он уже как актер Автор трансляции? Так?

Т.е. как только Пользователь собрался создавать трансляцию, мы начинаем считать его Автором. И создает трансляцию он уже как актер Автор трансляции? Так?

Кто создает, тот и Автор, по определению, так ведь?

В своём сообщении я процитировал то, с чем не согласен. Обобщение Пользователем Автора и Модератора не является указанием на то, "что любой пользователь может получить обе эти роли независимо".

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

В каком виде в модели вариантов использования будут представлены функциональные требования к указанной Вами подсистеме безопасности?

Я бы написал это в в тексте юзкейза для администратора безопасности.

Предлагаю такие ВИ: “Создать трансляцию”, “Изменить настройки трансляции”, “Удалить трансляцию”. Соответсвенно, актерами у всех трех ВИ будет Автор, а Модератор – актер только для двух последних ВИ. Зритель будет актером для ВИ “Посмотреть трансляцию”.

Другой способ. Можно создать ВИ более высокого уровня "Транслировать" и "Модерировать" для актеров Автор и Модератор соответственно. ВИ более низкого уровня  “Создать трансляцию”, “Изменить настройки трансляции”, “Удалить трансляцию” вызывать из них. Точнее, ВИ "Создать" будет вызываться только из ВИ "Транслировать".

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

И вообще, большое спасибо всем отозвавшимся за советы и науку. 


Как и обещал, основательно взялся за книгу "Современные методы описания функциональных требований" (Коберн А.) и наткнулся там на пару интересных, на мой взгляд, советов. Причем, похоже, как раз про "мой случай":

Действующие лица в сравнении с ролями

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

...

В UML используется незакрашенная стрелка, обозначающая, что одно действующее лицо является специализацией друrоrо (см. рис. А.6).

Такая стрелка позволяет кратко выразить, что менеджер может делать все то, что может делать служащий. Достаточно нарисовать стрелку, направленную от Meнеджера к служащему.

...

Стрелка специализации вовсе не помоrает решить rлавную часть проблемы Действующее лицо/Роль. Для служащеrо отдела продаж и служащеrо отдела аудита наборы вариантов использования перекрываются, но между ними нельзя поставить стрелку специализации, так как никто из них не может делать все, что может друrой. Таким образом, вы возвращаетесь к середнне дискуссии о действующем лице и роли.

Не уделяйте слишком мнoгo времени изучению rрафики и связей. Приложите лучше силы к написанию легкоrо для чтения повествования. В тексте прямо указаны связи между вариантами использования.

...

Те, кто создают хорошие текстовые варианты использования, просто не встречают проблем, с которыми сталкиваются любители фиryрок из палочек, эллипсов и стрелок UML. Связи появляются естественным образом, коrда вы пишете разворачивающуюся историю. Они становятся проблемой, только если вы на них останавливаетесь. Чем больше опыта приобретают консультанты в текстовой и в UМL форме, тем леrче они с этим соглашаются.

Какой, однако, умный дядька... И объясняет доступно. Может, я и правда чересчур уперся лбом в диаграммки? Что, кстати, уже упоминалось местными эрудитами.  Хотя, с другой стороны, нужно ведь было разобраться с непонятным, да и новые знания почерпнул... Одним словом, еще раз спасибо! )

Надеюсь, если я снова прибегу с проблемами, это не будет воспринято как чрезмерное нахальство? 

Мне понравилась книга Use Case Modeling by Bittner K., Spence I.

Спасибо за наводочку. Жаль не переведена на русский. Англицкую читать все же тяжеловато.

Спасибо за наводочку. Жаль не переведена на русский. Англицкую читать все же тяжеловато.

Читается как песня, хотя и на английском, читаю почти не перевожу в уме.

А как кстати будет выглядеть ДБО? Правильно ли я её нарисовал, если не считать что там нету направлений у связей и кратности.

Предлагаю такие ВИ: “Создать трансляцию”, “Изменить настройки трансляции”, “Удалить трансляцию”.

Alfia, вот у вас красивая диаграмма получилась, но я хотел бы её нарисовать со своей точки зрения. Не согласен с тем, что там есть включение ВИ Удалить трансляцию. Так как можно транслировать не удаляя трансляцию. Мне кажется, что зритель и автор, это всё таки как бы один АРМ(хоть и АРМах тут речи не идёт), поэтому можно просто пользователь. Даже вот это обобщение которое я нарисовал от пользователя к администратору мне тоже не очень нравится, так как практической пользы от него мало. 2 пользователя 3 ВИ всё просто и понятно, а уж то что в системе можно по разному настраивать права доступа от уровня администратора к уровню пользователю, это и так будет ясно из функциональных требований в текстовом виде.

Alfia эти 3 ВИ означают то же самое, что и у вас, просто немного по своему их назвал.