Здравствуйте! У меня маловато опыта в использовании UML при проектировании, и сейчас вылезла одна неясность.

Пытаюсь создать более-менее адекватную модель прецедентов использования, вот ее кусочек.
Есть актеры:
1) Создатель трансляции - может создать трансляцию, удалить или изменить ее настройки;
2) Модератор - модерирует, т.е. также может удалять трансляцию или изменять ее настройки. Но не создавать, поскольку в этом случае он будет выступать в качестве "Создателя трансляции", т.е. в другой роли;
3) Зритель трансляции - соответственно, любуется на все это безобразие;

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

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

Напрашиваются 2 варианта использования:
а) Транслирование - создание, удаление, изменение настроек;
б) Модерирование трансляции - удаление, изменение настроек;

Наблюдается дублирование функционала... Вроде как, при этом следует использовать связь "включение". После модификации прецедентов получаем:
Транслирование <- Управление трансляцией



Правильно ли в данном случае диаграмма отражает суть концепции? Т.е. что актер "Модератор" применяет вариант использования "Управление трансляцией", который сам является включением в вариант использования "Транслирование", который, в свою очередь используется актером "Создатель трансляции". Вообще, правомерна ли такая загогулина в UML?

Может быть все это следовало бы реализовать как-то иначе?

И еще пара отвлеченных вопросов. Существуют ли какие-либо общепринятые правила именования вариантов использования. Обратил внимание, что в RSA применяется конструкция ${use.case}. Т.е. именование с прописных букв и вместо пробелов точки? Возбраняется ли в Rational Software Architect применять русский язык, в частности - для именования элементов (актеры, варианты и т.п.)?

Большое спасибо.

Я отвечу по существу вопроса. Реально тут можно серьезно подискутировать, однако.

Включение тут явно не катит никак.
1. Налицо - предусловие. Ясно, чтобы что-то сделать с трансляцией, ее нужно создать - опубликовать.
2. Включение моделирует ситуацию, когда ВИ Трансляция не моежт быть НИКОГДА звершен, пока не будет ВКЛЮЧЕН и ЗАВЕРШЕН ВИ Управление трансляцией
3. Названия ВИ неудачные. ВИ  - это цель использования системы. ВИ всегда имеет ОДНУ роль характеризующую ВИ, по сути и отражающую самую цель использования. У нас их типа две: создатель (я бы назвал его автором) и модератор. И так автор - ПУБЛИКУЕТ трансляцию (размещает, добавляет и т.п.), далее автор как я понимаю может редактировать и удалять свою трансляцию? (Создание трансялции - акт творческий и видимо осуществляется вне рамок рассматриваемой системы). Кстати а что за система? Модератор - модерирует трансляцию. Т.е. получаем группу Автор - Разместить/изменить трансляцию и Модератор - Модерировать трансляцию. Очевидно, автор может что-то делать только со СВОЕЙ трансляцией, модератор может делать РАЗРЕШЕНИЯ по любой из трансляций. Ясно, что никакого обощения уточнения тут нет, т.е. мы не можем сделать генерализацию, т.к. ни при каких обстоятельствах нельзя сказать:
модератор - это автор, но частично можно было бы сказать - автор - это модератор (но только своих трансляций), однако это все-таки не полное наследование (а выброчное), тоже нельзя применить явно.

Можно было бы попытатсья осуществить обобщение вариантов использования  Обобщение вариантов использования. Но здесь оно тоже не подходит.

Резюме. Ваша модель использования небольшая, начните не с обощения всего в 1-2 варианта использования, а напишите столько сколько типичных вариантов использования обнаруживается, их у вас ну не много, потом уже и соедините, коли потребуется.

Коллеги,

Я бы сделал следующее:
1. "Создатель трансляции" -> "Опубликовать трансляцию"
2. "Модератор" -> "Модерировать (изменить или удалить) трансляцию"
3. Между "Модератором" и "Создателем трансляции" поставил бы связь обобщение, и в бизнес-правилах ВИ "Модерировать трансляцию" написал бы, что Модер может изменять/удалять любые трансляции, а Создатель может это делать только со своими.

Очевидно, автор может что-то делать только со СВОЕЙ трансляцией, модератор может делать РАЗРЕШЕНИЯ по любой из трансляций. Ясно, что никакого обощения уточнения тут нет, т.е. мы не можем сделать генерализацию, т.к. ни при каких обстоятельствах нельзя сказать:
модератор - это автор, но частично можно было бы сказать - автор - это модератор (но только своих трансляций), однако это все-таки не полное наследование (а выброчное), тоже нельзя применить явно.

Вот-вот, это самое мне покоя и не давало, потому и прибежал советоваться.

Кстати а что за система?

Если кратко - то что-то вроде видеотрансляций на сайте. Автор создает трансляцию, зрители к ней подключаются и зыркают. У трансляции есть несколько настроек (например: защита паролем, только для взрослых и др.). Плюс текстовый чат.

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

Но все, что касается именно трансляций - это скорее ПОДсистема, т.к. в проекте еще предусмотрена возможность видеоконференций и прочего. Т.е. утверждение:

Ваша модель использования небольшая

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

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

Что-то вроде этого?

(со стрелочкой в сторону модератора - косяк, еще не разобрался как следует с инструментарием RSA)

3. Между "Модератором" и "Создателем трансляции" поставил бы связь обобщение, и в бизнес-правилах ВИ "Модерировать трансляцию" написал бы, что Модер может изменять/удалять любые трансляции, а Создатель может это делать только со своими.

Кстати да, мысль была, но уверенности в правильности не было... А кого "во главу угла" при этом ставить Создателя (Автора)? Но опять таки, модератор может модерировать не только трансляции, но и конференции... Т.е. все-таки лучше разделить эти роли между актерами "Модератор Трансляции", "Модератор Конференции"?.. Лицо вроде одно, но роли разные...

Спасибо за ответы.

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

Кстати да, мысль была, но уверенности в правильности не было... А кого "во главу угла" при этом ставить Создателя (Автора)?

Ну а логически подумать? Автор наследует действия Модератора по управлению трансляцией.

Предлагаю свой вариант.
1. все описанное вами, т.е. создание, просмотр, редактирование и удаление принято собирать в так называемый CRUD Use Case (Create, Read, Update, Delete);
2. очевидно, что есть несколько актеров, которые используют один и тот же функционал (вопрос полномочий оставляем за рамками UC. Это можно описать в предусловиях, в БП, и т.д. К самим шагам UC это уже не относится - UC уже работает);
3. логично было бы создать один UC, содержащий описание всех основных, описанных выше, операций и ассоциировать этот UC с двумя актерами ("Автор трансляции" и "Модератор"). Это абсолютно нормальная ситуация - назначать одному UC несколько актеров. Это означает лишь то, что в выполнении данной задачи заинтересованы несколько актеров; 
4. поскольку модератор имеет возможность делать все то же самое, что и Автор трансляции, за исключением только одной операции - создания трансляции, то логично создать общий CRUD UC, в котором действия по созданию трансляции будут описаны с необходимой детальностью. Все остальные действия по редактированию и удалению трансляции в данном UC описаны одним шагом и являются по сути ссылкой на второй UC. Второй UC детально описывает шаги по редактированию и удалению трансляции. Данная связь между UC будет <include>;
5. Актером первого наиболее полного UC является Автор трансляции. Актером второго - Модератор.
6. Что касается опасений, что один UС содержит сразу несколько равноправных операций (по созданию, удалению, редактированию...), которые не обязательно будут выполняться все и последовательно, или предположений, что первый (более общий UC) не отработает, пока "обязательно!" не отработает второй, то это вопрос написания самого  UC. Есть несколько общепринятых приемов для решения такой проблемы, в частности написания CRUD UC. Не буду здесь грузить. Будет интересно - пишите в личку.
Картинку прилагать не буду - она простая.
Еще рекомендация: не используйте термин "прецедент". Это просто неверный перевод термина USE CASE. И уже очень давно не используется.
Удачи!

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

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

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

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

Ну а логически подумать? Автор наследует действия Модератора по управлению трансляцией.

Да, точно, спасибо.


Т.е. есть несколько путей:

1) Забить болт на все хитрости и просто выделить столько ВИ, сколько нужно.



2) Таки использовать обобщение, указав все тонкости (по разграничению прав и неполном наследовании) в спецификации.




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

Не буду здесь грузить. Будет интересно - пишите в личку.

Очень интересно, грузите пожалуйста (если конечно это не то, что в вышеуказанной книге расписано - ей я завтра займусь). И зачем в личку, почему бы не здесь, ведь в тему же?

Еще рекомендация: не используйте термин "прецедент". Это просто неверный перевод термина USE CASE. И уже очень давно не используется.

Это я Вендрова начитался Буду иметь в виду.

Большое спасибо всем откликнувшимся. Уж завтра-то я эту гаденькую диаграммку дорисую... 


P.S. сорри за портянку, не нашел у вас тега MORE.

P.S.S. Кстати, по ссылке с гугла Варианты использования CRUD PHP выдает сообщение об ошибке и херит сессию (Боже, храни гуглкэш!).

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

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

Потому ориентируемся на самое главное и основное в первую очередь:
1. автор - размещает трансялцию в эфире (возможно ждет разрешения модератора) (если хочет удаляет ее)
2. модератор - разрешает трансляцию в эфире (если надо удаляет оную)
3. там Вы говорили что-то по комментирование - а кто коментит, ну уж явно не автор а кто-то другой, этот другой кто он? явно пропущен ВИ Оставить комментарий к трансляции

По поводу CRUD см. книгу usecasespatternsblueprints.chm. Правда мне этот CRUD честно не нравится.

Но

Код: [Выделить]

Use Case: CRUD Task
Brief Description

The use case registers, modifies, or cancels the information about a task to be performed as stated in information received from the Task Definer.

Basic Flow

The use case has four different basic flows:

Register Task

Modify Existing Task

Cancel Task

View Tasks That Failed

REGISTER TASK

The use case starts when the Task Definer chooses to register a new task. The use case presents a list of possible kinds of tasks to the Task Definer, and asks what kind of task is to be registered, what name it is to be assigned, and when it is to be performed.

The Task Definer enters the required information. The use case checks whether the specified time is in the future and whether the name of the task is unique.

The use case registers a new task in the system and marks the task as enabled.

The use case ends.

MODIFY EXISTING TASK

The use case starts when the Task Definer chooses to modify an already registered task. The use case retrieves the names of all the tasks not marked as active and presents them to the Task Definer.

The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.

The Task Definer modifies any of the presented information except the name of the task.

The Task Definer accepts the information. The use case checks whether the specified time is in the future and, if so, stores the modified information.

The use case ends.

CANCEL TASK

The use case starts when the Task Definer chooses to cancel a task. The use case retrieves all the tasks not marked as active.

The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.

If the Task Definer confirms the cancellation, the use case removes the task; otherwise, no modifications are made.

The use case ends.

VIEW TASKS THAT FAILED

The use case starts when the Task Definer chooses to view a list of all the tasks that have failed. The use case collects all the tasks with the status failed and presents their names to the Task Definer.

The use case ends.

Alternative Flows

CANCEL OPERATION

The Task Definer may choose to cancel the operation at any time during the use case, in which case any gathered information is discarded, and the use case ends.

INCORRECT NAME OR TIME

If the name of the task is performed not unique or the time is not in the future, the Task Definer is notified that the information is incorrect and is requested to re-enter the incorrect information.

The Task Definer re-enters the information. The flow resumes where the check of the information is performed.

А я вот с Эдуардом не соглашусь...

Мне больше нравится вариант 2, т.к. если показываются 2 актера участвующих в одном ВИ, то это скорее понимается, как один что-то делает в ВИ, а другой доделывает. Т.е. один - главный актер, а второй - вторичный.
В вашем же случае ИМХО больше подходит вариант 2.

Но как я уже сказал: как нарисовать ВИ - это дело вкуса.

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

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

А я вот с Эдуардом не соглашусь...

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

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

Полностью согласен.

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

Да именно об этом я и пытался сказать ниже

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