Если создание модели вызывает такие сложности, то насколько просто будет даваться её чтение потребителем?

Практичность «вопроса» в чём?

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

Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].

Если создание модели вызывает такие сложности, то насколько просто будет даваться её чтение потребителем?
Практичность «вопроса» в чём?

Разработка ведется для нужд нашей компании, "потребитель" в UML вообще ни ухом, ни рылом. Функциональные требования описываются в UML скорее для нужд разработчика, для более ясного понимания системы и упрощения дальнейшего анализа, разработки и сопровождения. К тому же я попутно хотел бы с ним освоиться: вещь нужная, а знаю его только по книжкам. Попрактиковаться, освоить CASE-средства, в таком вот акцепте.

А вот теперь, господа эксперты, я действительно запутался...    Такое впечатление, что начал расспршивать об Истинной Вере^TM на сходке христиан и мусульман 

Я бы все-таки избегал обощения модератором свойств автора. Это суть реализации, разделение полномочий на исполняемые действия, а не суть задач. Автор  - это не модератор, это однозначно. Потому не надо нарушать логику предметной области в угоду изобразительного искусства.

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

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

Я сам уже склоняюсь к такому варианту, но в силу неопытности до конца не уверен...

Потому спрашивается, если есть модератор, наверное, есть и администратор? Почему бы его не изобразить?

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

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

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

Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].

Эвон как... а это точно? Потому что, возможно, такая генерализация была бы и полезна. У меня как раз есть актер Пользователь, который обозначает любого человека, шарящегося по сайту системы. Ну и соответственно, реализует все общие для актеров - "посетителей сайта" (модераторы, авторы, зрители и т.д.) ВИ.

Так, еще (хотя предыдущих вопросов это не снимает...) для приличия уточнить хочу (нуб я или когда? ). Генерализация ведь является аналогом механизма наследования в ООП? Данная диаграмма верна?



И не будет ли лучше так:



По идее, и то, и то верно... Но какой вариант, так сказать, более "православен"?

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

Но если подходить с точки зрения ролей... тогда получается, что просто один и тот же человек выступает одновременно и в роли Участника Конференции, и в роли Автора конференции. Но роли-то сами по себе разные, функционал и поведение у них разное абсолютно. А в ДВИ нас интересуют именно актеры и их поведение. Тогда выходит, что первый рисунок более правильный...

Что скажете? Сам я склоняюсь варианту на первом рисунке.

Модератор трансляции и Модератор конференции -- разные роли (акторы). Если вдруг выявятся их общие цели, можно описать их как ВИ для обобщающего их действующего лица Модератор.

И все-таки... И Модератор Трансляции, и Модератор конференции выполняют по сути одну и ту же функцию: могу изменить настройки, могу удалить нафиг. Просто по отношению к разным объектам внутри системы. Не лучше ли оставить одного актера с разными ВИ:



 

Без описаний действующих лиц уточнить, какая из двух диаграмм верна, затруднительно. Могут ли автор Трансляции и Модератор Трансляции делать с трансляцией то, что делает Зритель? Вероятно, да. В таком случае, [взяв за основу вторую диаграмму] можно удалить роль Пользователь, а на её место поставить Зритель. Кто такой Пользователь? Чем он отличается от Зрителя?
Что касается модераторов, то предложенное Вами решение имеет право на жизнь. При этом полномочия модераторов по управлению трансляциями, конференциями и правами доступа не разделимы.

Без описаний действующих лиц уточнить, какая из двух диаграмм верна, затруднительно. Могут ли автор Трансляции и Модератор Трансляции делать с трансляцией то, что делает Зритель? Вероятно, да.

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

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

Имеет ли право на жизнь такое мнение, такая трактовка при моделировании на UML?

Кто такой Пользователь? Чем он отличается от Зрителя?

Посетитель - любой посетитель сайта.
Пользователь - авторизованный посетитель сайта.
Зритель - тот, кто просматривает трансляцию.

Разработка ведется для нужд нашей компании, "потребитель" в UML вообще ни ухом, ни рылом.

Я и имел в виду под потребителем того, кто будет читать ваши диаграммы. А вы кого имели в виду?

Функциональные требования описываются в UML скорее для нужд разработчика, для более ясного понимания системы и упрощения дальнейшего анализа, разработки и сопровождения. К тому же я попутно хотел бы с ним освоиться: вещь нужная, а знаю его только по книжкам. Попрактиковаться, освоить CASE-средства, в таком вот акцепте.

А вы кто в процессе? Вы же и разработчик?

А вы кто в процессе? Вы же и разработчик?

Да. Буду непосредственное участие в разработке принимать. Так что во многом формулирую требования "для себя", чтобы разобраться, какой именно должна быть система в конечном итоге. У нас команда маленькая, несколько человек.

Автор может только трансляцию создать (опубликовать), удалить, изменить ее настройки. Модератор может только изменить ее настройки или удалить. Все, больше никаких функций у этих актеров нет.

Если они это делают, не глядя, (т. е. не имея доступа к функциям для Зрителя), то Вы правы.

Актер Модератор и человек, которому дали модераторские полномочия - на мой взгляд, совершенно разные понятия.

Так точно. На обратном никто не настаивает. Другое дело, что роли -- это не маски, которые произвольно меняет пользователь, не информируя об этом систему, а точки зрения системы на части своего окружения. В Вашей модели либо придётся дублировать описание показа трансляции в UC зрителя и в UC модератора, либо придётся человеку, играющему роль Модератора, информировать систему, что он перестаёт исполнять эту роль (вылогинивается) и начинает исполнять роль Зрителя. Признаюсь, что написав это, я исхожу из скорее всего неверного понимания того, что такое модерирование трансляции.
Связь обобщения позволяет единожды описать общие UC разных акторов как UC обобщающего действующего лица. Она никак не связана с тем, может ли человек за компьютером выступать в обоих ролях или не сможет.

Посетитель - любой посетитель сайта.
Пользователь - авторизованный посетитель сайта.
Зритель - тот, кто просматривает трансляцию.

Допустим так. Проходят ли авторы и участники конференции авторизацию?

Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].

Ну да, а в чем тут противоречие? Обощенный Пользователь, например, имеет общий юзкейз - ему доступна страница авторизации с рекламой спонсора (кейз в интересах спонсора).
Какой то другой актор, например, Взаимодействующая Автоматическая Система, может не иметь возможности ходить на эту страницу авторизации, используя другой механизм входа. Тогда актор Взаимодействующая Автоматическая Система не будет Пользователем, и не будет иметь счастье смотреть рекламу, а Модератор и Автор - будут Пользователями, и будут смотреть.

придётся человеку, играющему роль Модератора, информировать систему, что он перестаёт исполнять эту роль (вылогинивается) и начинает исполнять роль Зрителя. 

Нормально сделанная система безопасности позволяет назначить несколько ролей одному пользователю (одному логину), поэтому роли Зрителя и Модератора могут быть доступны без перелогинивания -- если и то и другое полномочие человеку даны.

Ох...  Ниче не понял...  Щас как понапишууу... 

Допустим так. Проходят ли авторы и участники конференции авторизацию?

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

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

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

Но тут на сайт зашел модератор Злой Петух. На скриншоте в списке трансляций он увидел, какие непотребства совершает Ваня перед камерой. Он зашел на страницу трансляции, полюбовался на Ваню и в панельке настроек (которую он видел, как и Ваня) поставил галочку "Только для взрослых". Заметив эти изменения, Ваня очень расстроился: ведь теперь возможности зреть его красоту и величие лишилась самая добрая и светлая категория зрителей - дети. Да и скриншоты в списке трансляций больше не показывались. Ваня хотел убрать галочку обратно, но не смог - ее поставил модератор, а модератор, как известно, всегда больше и красивее рядового юзера.

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

Если они это делают, не глядя, (т. е. не имея доступа к функциям для Зрителя), то Вы правы.
...
Другое дело, что роли -- это не маски, которые произвольно меняет пользователь, не информируя об этом систему, а точки зрения системы на части своего окружения.

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

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

Вот я чего понять не могу... 

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

Эта диаграмма составлена на основе душещипательной истории Вани (выше). Верна ли она?
Кстати, мое представление о модели в процессе создания диаграммы изменилось...
ВИ "Управлять трансляцией" в данном случае означает - изменить ее настройки или удалить.
ВИ "Модерировать трансляции" - изменить настройки или удалить любую трансляцию.
Создает трансляцию теперь Пользователь и при этом становится Автором трансляции.

Вышло, что актер Зритель оказался не нужен (ведь просмотр доступен и Посетителям, и Пользователям)... Но если я хочу выделить эту роль? Что, если у Зрителя в дальнейшем появится какое-то особое поведение, недоступное Посетителю? Например, проголосовать за трансляцию? Как мне быть? Рисовать человечка Зритель. От него стрелка генерализации к Посетителю. От Пользователя стрелка генерализации к Зрителю?  мешанина какая-то получается...

Из диаграммы получается, что создав трансляцию, Пользователь становится Автором трансляции... По задумке, Автор трансляции может владеть только одной трансляцией. Т.е. пока он не удалит трансляцию и не станет обратно Пользователем, создавать трансляции он не может... а по диаграмме получается, что этот функционал им унаследован. Как здесь быть? Указывать вес связи: Пользователь * --- 1 Создать трансляцию?

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

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

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

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

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

Ну да, а в чем тут противоречие?

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

Нормально сделанная система безопасности позволяет назначить несколько ролей одному пользователю

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