Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Brumbel от 09 Апреля 2012, 08:08:10
-
Здравствуйте! У меня маловато опыта в использовании UML при проектировании, и сейчас вылезла одна неясность.
Пытаюсь создать более-менее адекватную модель прецедентов использования, вот ее кусочек.
Есть актеры:
1) Создатель трансляции - может создать трансляцию, удалить или изменить ее настройки;
2) Модератор - модерирует, т.е. также может удалять трансляцию или изменять ее настройки. Но не создавать, поскольку в этом случае он будет выступать в качестве "Создателя трансляции", т.е. в другой роли;
3) Зритель трансляции - соответственно, любуется на все это безобразие;
Т.е. в данном контексте модератор и создатель выполняют практически одни и те же функции, только у создателя на одну больше. (если брать систему в целом, то у модератора задач гораздо больше, чем надзор за одними только трансляциями).
Как быть при создании вариантов использования? Множить сущности (модератор того, модератор сего, модератор десятого...) мне кажется не кошерным. По существу у него простые надзорные функции в разных разделах проекта: может править, может удалять.
Напрашиваются 2 варианта использования:
а) Транслирование - создание, удаление, изменение настроек;
б) Модерирование трансляции - удаление, изменение настроек;
Наблюдается дублирование функционала... Вроде как, при этом следует использовать связь "включение". После модификации прецедентов получаем:
Транслирование <- Управление трансляцией
(http://imglink.ru/thumbnails/09-04-12/3bf16115d4788951cbf8b29fd884491d.jpg) (http://imglink.ru/show-image.php?id=b1d6bc692c43526706e78901bafe4112)
Правильно ли в данном случае диаграмма отражает суть концепции? Т.е. что актер "Модератор" применяет вариант использования "Управление трансляцией", который сам является включением в вариант использования "Транслирование", который, в свою очередь используется актером "Создатель трансляции". Вообще, правомерна ли такая загогулина в UML?
Может быть все это следовало бы реализовать как-то иначе?
И еще пара отвлеченных вопросов. Существуют ли какие-либо общепринятые правила именования вариантов использования. Обратил внимание, что в RSA применяется конструкция ${use.case}. Т.е. именование с прописных букв и вместо пробелов точки? Возбраняется ли в Rational Software Architect применять русский язык, в частности - для именования элементов (актеры, варианты и т.п.)?
Большое спасибо.
-
Я отвечу по существу вопроса. Реально тут можно серьезно подискутировать, однако.
Включение тут явно не катит никак.
1. Налицо - предусловие. Ясно, чтобы что-то сделать с трансляцией, ее нужно создать - опубликовать.
2. Включение моделирует ситуацию, когда ВИ Трансляция не моежт быть НИКОГДА звершен, пока не будет ВКЛЮЧЕН и ЗАВЕРШЕН ВИ Управление трансляцией
3. Названия ВИ неудачные. ВИ - это цель использования системы. ВИ всегда имеет ОДНУ роль характеризующую ВИ, по сути и отражающую самую цель использования. У нас их типа две: создатель (я бы назвал его автором) и модератор. И так автор - ПУБЛИКУЕТ трансляцию (размещает, добавляет и т.п.), далее автор как я понимаю может редактировать и удалять свою трансляцию? (Создание трансялции - акт творческий и видимо осуществляется вне рамок рассматриваемой системы). Кстати а что за система? Модератор - модерирует трансляцию. Т.е. получаем группу Автор - Разместить/изменить трансляцию и Модератор - Модерировать трансляцию. Очевидно, автор может что-то делать только со СВОЕЙ трансляцией, модератор может делать РАЗРЕШЕНИЯ по любой из трансляций. Ясно, что никакого обощения уточнения тут нет, т.е. мы не можем сделать генерализацию, т.к. ни при каких обстоятельствах нельзя сказать:
модератор - это автор, но частично можно было бы сказать - автор - это модератор (но только своих трансляций), однако это все-таки не полное наследование (а выброчное), тоже нельзя применить явно.
Можно было бы попытатсья осуществить обобщение вариантов использования Обобщение вариантов использования (http://www.uml2.ru/index.php?option=com_content&task=view&id=421&Itemid=51). Но здесь оно тоже не подходит.
Резюме. Ваша модель использования небольшая, начните не с обощения всего в 1-2 варианта использования, а напишите столько сколько типичных вариантов использования обнаруживается, их у вас ну не много, потом уже и соедините, коли потребуется.
-
Коллеги,
Я бы сделал следующее:
1. "Создатель трансляции" -> "Опубликовать трансляцию"
2. "Модератор" -> "Модерировать (изменить или удалить) трансляцию"
3. Между "Модератором" и "Создателем трансляции" поставил бы связь обобщение, и в бизнес-правилах ВИ "Модерировать трансляцию" написал бы, что Модер может изменять/удалять любые трансляции, а Создатель может это делать только со своими.
-
Очевидно, автор может что-то делать только со СВОЕЙ трансляцией, модератор может делать РАЗРЕШЕНИЯ по любой из трансляций. Ясно, что никакого обощения уточнения тут нет, т.е. мы не можем сделать генерализацию, т.к. ни при каких обстоятельствах нельзя сказать:
модератор - это автор, но частично можно было бы сказать - автор - это модератор (но только своих трансляций), однако это все-таки не полное наследование (а выброчное), тоже нельзя применить явно.
Вот-вот, это самое мне покоя и не давало, потому и прибежал советоваться.
Кстати а что за система?
Если кратко - то что-то вроде видеотрансляций на сайте. Автор создает трансляцию, зрители к ней подключаются и зыркают. У трансляции есть несколько настроек (например: защита паролем, только для взрослых и др.). Плюс текстовый чат.
Автор может создать новую трансляцию, закрыть (удалить) свою текущую, изменить настройки своей текущей трансляции.
Модератор может удалить любую трансляцию или изменить настройки любой трансляции. Если модератор трансляцию создает, то он становится ее Автором... т.е. это функционал уже другого актера.
Но все, что касается именно трансляций - это скорее ПОДсистема, т.к. в проекте еще предусмотрена возможность видеоконференций и прочего. Т.е. утверждение:
Ваша модель использования небольшая
не совсем верно. Я просто привел кусочек контекста, в котором у меня возникли проблемы. Я потому и начал сомневаться по поводу такого варианта, что ВИ становится многовато...
Как я понял, особого выхода нет и нужно делать ВИ:
Создать трансляцию (хотя он получится смехотворно малым) - его будет осуществлять Автор.
Модерировать трансляцию (или Управлять трансляцией) - подразумевается удаление трансляции и изменение ее настроек. Этот ВИ может осуществляться и Автором, и Модератором.
Что-то вроде этого?
(http://imglink.ru/thumbnails/09-04-12/52e7794be709191d0fd0a04074b399b5.jpg) (http://imglink.ru/show-image.php?id=e61355dedadfe297a7fc5de8c27605ca)
(со стрелочкой в сторону модератора - косяк, еще не разобрался как следует с инструментарием 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) Забить болт на все хитрости и просто выделить столько ВИ, сколько нужно.
(http://imglink.ru/pictures/09-04-12/1230ded6f413c4399e2331e979a89c46.jpg)
2) Таки использовать обобщение, указав все тонкости (по разграничению прав и неполном наследовании) в спецификации.
(http://imglink.ru/pictures/09-04-12/3efa7fb13bf37a06805766db92568330.jpg)
3) Использовать CRUD-паттерн (как я понял, там используется несколько основных потоков в ВИ). С этим колдунством пока не разобрался. Уже скачал книжку "Современные методы описания функциональных требований" (Алистер Коберн) - там по этой теме целая глава, а еще вот эту темку (http://www.uml2.ru/forum/index.php?topic=628.0;nowap). Но у меня уже поздний вечер, так что вникать буду завтра...
Не буду здесь грузить. Будет интересно - пишите в личку.
Очень интересно, грузите пожалуйста (если конечно это не то, что в вышеуказанной книге расписано - ей я завтра займусь). И зачем в личку, почему бы не здесь, ведь в тему же?
Еще рекомендация: не используйте термин "прецедент". Это просто неверный перевод термина USE CASE. И уже очень давно не используется.
Это я Вендрова начитался :) Буду иметь в виду.
Большое спасибо всем откликнувшимся. Уж завтра-то я эту гаденькую диаграммку дорисую... ;D
P.S. сорри за портянку, не нашел у вас тега MORE.
P.S.S. Кстати, по ссылке с гугла Варианты использования CRUD (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=289.0) PHP выдает сообщение об ошибке и херит сессию (Боже, храни гуглкэш (http://webcache.googleusercontent.com/search?q=cache:snM3lxAmyhIJ:www.uml2.ru/index.php%3Foption%3Dcom_smf%26Itemid%3D45%26topic%3D289.0+&cd=4&hl=ru&ct=clnk&gl=ru)!).
-
Я бы все-таки избегал обощения модератором свойств автора. Это суть реализации, разделение полномочий на исполняемые действия, а не суть задач. Автор - это не модератор, это однозначно. Потому не надо нарушать логику предметной области в угоду изобразительного искусства. Если уж нужно, тогда следует выделять промежуточное обощение от которого наследуются и автор и модератор.
Кроме того модератор хотя и активный пользователь системы, но он все-таки ближе к понятию системного персонала. Потому спрашивается, если есть модератор, наверное, есть и администратор? Почему бы его не изобразить?
Потому ориентируемся на самое главное и основное в первую очередь:
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. В противном случае у вас получится, что Модератор может создавать и править трансляции от имени других пользвателей, что вряд ли приведет их в восторг.)
Полностью согласен.
Если надо показать, что любой пользователь может получить обе эти роли независимо, то нарисуйте слева от человечков Автор и Модератор еще человечка Пользователь, и проведите к Пользователю от двух других стрелочки Генерализация.
Да именно об этом я и пытался сказать ниже
Если уж нужно, тогда следует выделять промежуточное обобщение от которого наследуются и автор и модератор.
-
Если создание модели вызывает такие сложности, то насколько просто будет даваться её чтение потребителем?
Практичность «вопроса» в чём?
-
Если надо показать, что любой пользователь может получить обе эти роли независимо, то нарисуйте слева от человечков Автор и Модератор еще человечка Пользователь, и проведите к Пользователю от двух других стрелочки Генерализация.
Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].
-
Если создание модели вызывает такие сложности, то насколько просто будет даваться её чтение потребителем?
Практичность «вопроса» в чём?
Разработка ведется для нужд нашей компании, "потребитель" в UML вообще ни ухом, ни рылом. Функциональные требования описываются в UML скорее для нужд разработчика, для более ясного понимания системы и упрощения дальнейшего анализа, разработки и сопровождения. К тому же я попутно хотел бы с ним освоиться: вещь нужная, а знаю его только по книжкам. Попрактиковаться, освоить CASE-средства, в таком вот акцепте.
А вот теперь, господа эксперты, я действительно запутался... :o ??? Такое впечатление, что начал расспршивать об Истинной ВереTM на сходке христиан и мусульман ;D
Я бы все-таки избегал обощения модератором свойств автора. Это суть реализации, разделение полномочий на исполняемые действия, а не суть задач. Автор - это не модератор, это однозначно. Потому не надо нарушать логику предметной области в угоду изобразительного искусства.
Вот об этом я тоже думал. Понятно, что т.к. функционал актеров почти одинаковый, реализовать его будет похожий код. И тут, чтобы избежать повторного кода, будет использоваться одни и те же (ну или родственные) классы. А если в будущем что-то изменится, всегда можно будет провести рефакторинг.
Но в МВИ мы ведь описываем функциональность, а не архитектуру. Что будет делаться, а не как. А с точки зрения функционала транслирование (в это определение включаю все: от публикации до управления своей трансляцией) и модерирование - действительно разные вещи. Может быть, действительно идеологически более верно пока что плюнуть на схожесть функций этих актеров, сделать:
Автор трансляции -> CRUD Трансляции
Модератор трансляции -> Модерировать трансляцию
А уже на фазе анализа и проектирования внести ясность: что такой-то и такой-то функционал будет реализован одним и тем же классом, т.к. по сути это одно и то же?
Я сам уже склоняюсь к такому варианту, но в силу неопытности до конца не уверен...
Потому спрашивается, если есть модератор, наверное, есть и администратор? Почему бы его не изобразить?
Ну, сами требования еще на стадии формирования. По идее, конечно нужен юзер с более высокими чем у модера привелегиями. Просто об это еще подумать не успели :)
3. там Вы говорили что-то по комментирование - а кто коментит, ну уж явно не автор а кто-то другой, этот другой кто он? явно пропущен ВИ Оставить комментарий к трансляции
Как я уже говорил, во-первых, система еще продумана не до конца. Во-вторых, я привел здесь только небольшой кусочек модели, с которым возникли затруднения. Если брать систему в целом, одних актеров уже сейчас около 15, и думаю, число еще вырастет. В проекте есть явно выраженные подсистемы, которые при моделировании я предполагаю распределить по отдельным пакетам.
Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].
Эвон как... а это точно? Потому что, возможно, такая генерализация была бы и полезна. У меня как раз есть актер Пользователь, который обозначает любого человека, шарящегося по сайту системы. Ну и соответственно, реализует все общие для актеров - "посетителей сайта" (модераторы, авторы, зрители и т.д.) ВИ.
-
Так, еще (хотя предыдущих вопросов это не снимает...) для приличия уточнить хочу (нуб я или когда? :) ). Генерализация ведь является аналогом механизма наследования в ООП? Данная диаграмма верна?
(http://imglink.ru/pictures/10-04-12/641442fc27b3839a01a90eebcc1cb87a.jpg)
И не будет ли лучше так:
(http://imglink.ru/pictures/10-04-12/3c37732fad21f87e9f83016d5de7d11a.jpg)
По идее, и то, и то верно... Но какой вариант, так сказать, более "православен"?
С одной стороны, если рассматривать автора конференции, как отдельно взятого реального человека, то он должен просто наследовать функции участника конференции (чтобы не только управлять ей, но и с другим народом общаться). Т.е. на диаграмме надо генерализовать их связь.
Но если подходить с точки зрения ролей... тогда получается, что просто один и тот же человек выступает одновременно и в роли Участника Конференции, и в роли Автора конференции. Но роли-то сами по себе разные, функционал и поведение у них разное абсолютно. А в ДВИ нас интересуют именно актеры и их поведение. Тогда выходит, что первый рисунок более правильный...
Что скажете? Сам я склоняюсь варианту на первом рисунке.
Модератор трансляции и Модератор конференции -- разные роли (акторы). Если вдруг выявятся их общие цели, можно описать их как ВИ для обобщающего их действующего лица Модератор.
И все-таки... И Модератор Трансляции, и Модератор конференции выполняют по сути одну и ту же функцию: могу изменить настройки, могу удалить нафиг. Просто по отношению к разным объектам внутри системы. Не лучше ли оставить одного актера с разными ВИ:
(http://imglink.ru/pictures/10-04-12/597a4b2712e399725966324bd02f6907.jpg)
???
-
Без описаний действующих лиц уточнить, какая из двух диаграмм верна, затруднительно. Могут ли автор Трансляции и Модератор Трансляции делать с трансляцией то, что делает Зритель? Вероятно, да. В таком случае, [взяв за основу вторую диаграмму] можно удалить роль Пользователь, а на её место поставить Зритель. Кто такой Пользователь? Чем он отличается от Зрителя?
Что касается модераторов, то предложенное Вами решение имеет право на жизнь. При этом полномочия модераторов по управлению трансляциями, конференциями и правами доступа не разделимы.
-
Без описаний действующих лиц уточнить, какая из двух диаграмм верна, затруднительно. Могут ли автор Трансляции и Модератор Трансляции делать с трансляцией то, что делает Зритель? Вероятно, да.
Ммм... я смотрю на это немного по-другому. Т.е. что (актеры!) Модератор Трансляции и Автор не могут делать с трансляцией то, что делает Зритель (т.е. смотреть трансляцию они не могут априорно). У них четко очерченые функции. Автор может только трансляцию создать (опубликовать), удалить, изменить ее настройки. Модератор может только изменить ее настройки или удалить. Все, больше никаких функций у этих актеров нет.
Актер Модератор и человек, которому дали модераторские полномочия - на мой взгляд, совершенно разные понятия. И человек - модератор проекта заходит на страницу трансляции и видит ее только потому, что в этот момент он отыгрывает роль Зрителя. Роль актера-Модератора он исполняет только тогда, когда изменяет настройки трансляции или удаляет ее. Поэтому мне кажется, что ставить связть в ДВИ между Модератором и Зрителем только потому, что сидящий за компьютером человек может выступить в любой из этих ролей, не совсем верно. Это совершенно разные актеры с совершенно разными функциями и поведением.
Имеет ли право на жизнь такое мнение, такая трактовка при моделировании на UML?
Кто такой Пользователь? Чем он отличается от Зрителя?
Посетитель - любой посетитель сайта.
Пользователь - авторизованный посетитель сайта.
Зритель - тот, кто просматривает трансляцию.
-
Разработка ведется для нужд нашей компании, "потребитель" в UML вообще ни ухом, ни рылом.
Я и имел в виду под потребителем того, кто будет читать ваши диаграммы. А вы кого имели в виду?
Функциональные требования описываются в UML скорее для нужд разработчика, для более ясного понимания системы и упрощения дальнейшего анализа, разработки и сопровождения. К тому же я попутно хотел бы с ним освоиться: вещь нужная, а знаю его только по книжкам. Попрактиковаться, освоить CASE-средства, в таком вот акцепте.
А вы кто в процессе? Вы же и разработчик?
-
А вы кто в процессе? Вы же и разработчик?
Да. Буду непосредственное участие в разработке принимать. Так что во многом формулирую требования "для себя", чтобы разобраться, какой именно должна быть система в конечном итоге. У нас команда маленькая, несколько человек.
-
Автор может только трансляцию создать (опубликовать), удалить, изменить ее настройки. Модератор может только изменить ее настройки или удалить. Все, больше никаких функций у этих актеров нет.
Если они это делают, не глядя, (т. е. не имея доступа к функциям для Зрителя), то Вы правы.
Актер Модератор и человек, которому дали модераторские полномочия - на мой взгляд, совершенно разные понятия.
Так точно. На обратном никто не настаивает. Другое дело, что роли -- это не маски, которые произвольно меняет пользователь, не информируя об этом систему, а точки зрения системы на части своего окружения. В Вашей модели либо придётся дублировать описание показа трансляции в UC зрителя и в UC модератора, либо придётся человеку, играющему роль Модератора, информировать систему, что он перестаёт исполнять эту роль (вылогинивается) и начинает исполнять роль Зрителя. Признаюсь, что написав это, я исхожу из скорее всего неверного понимания того, что такое модерирование трансляции.
Связь обобщения позволяет единожды описать общие UC разных акторов как UC обобщающего действующего лица. Она никак не связана с тем, может ли человек за компьютером выступать в обоих ролях или не сможет.
Посетитель - любой посетитель сайта.
Пользователь - авторизованный посетитель сайта.
Зритель - тот, кто просматривает трансляцию.
Допустим так. Проходят ли авторы и участники конференции авторизацию?
-
Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].
Ну да, а в чем тут противоречие? Обощенный Пользователь, например, имеет общий юзкейз - ему доступна страница авторизации с рекламой спонсора (кейз в интересах спонсора).
Какой то другой актор, например, Взаимодействующая Автоматическая Система, может не иметь возможности ходить на эту страницу авторизации, используя другой механизм входа. Тогда актор Взаимодействующая Автоматическая Система не будет Пользователем, и не будет иметь счастье смотреть рекламу, а Модератор и Автор - будут Пользователями, и будут смотреть.
-
придётся человеку, играющему роль Модератора, информировать систему, что он перестаёт исполнять эту роль (вылогинивается) и начинает исполнять роль Зрителя.
Нормально сделанная система безопасности позволяет назначить несколько ролей одному пользователю (одному логину), поэтому роли Зрителя и Модератора могут быть доступны без перелогинивания -- если и то и другое полномочие человеку даны.
-
Ох... :o Ниче не понял... ??? Щас как понапишууу... :-X
Допустим так. Проходят ли авторы и участники конференции авторизацию?
Нет, их функции доступны без этого.
Признаюсь, что написав это, я исхожу из скорее всего неверного понимания того, что такое модерирование трансляции.
"Иван решил показать всем, какой он умный и красивый через веб-камеру и рассказать об этом через микрофон. Для этого он зашел на сайт системы, авторизовался и нажал "создать новую трансляцию". Ввел ее название: "Красивый Ваня", настроил, указав некоторые опции, и опубликовал. Он оказался на странице трансляции, видел себя на ней в специальном окошке, а также видел сколько людей его сейчас смотрит. Ссылка на его трансляцию появилось в списке трансляций на сайте вместе со скриншотом. Зрители заходили к Ване по ссылке, любовались на то, какой же он все-таки красивый, оценивали величину ума и радовались. А Ваня радовался количеству зрителей и тому, что в любой момент может изменить настройки своей трансляции или закрыть ее через специальную панельку на странице (Зрителям недоступную).
Но тут на сайт зашел модератор Злой Петух. На скриншоте в списке трансляций он увидел, какие непотребства совершает Ваня перед камерой. Он зашел на страницу трансляции, полюбовался на Ваню и в панельке настроек (которую он видел, как и Ваня) поставил галочку "Только для взрослых". Заметив эти изменения, Ваня очень расстроился: ведь теперь возможности зреть его красоту и величие лишилась самая добрая и светлая категория зрителей - дети. Да и скриншоты в списке трансляций больше не показывались. Ваня хотел убрать галочку обратно, но не смог - ее поставил модератор, а модератор, как известно, всегда больше и красивее рядового юзера.
Ваня обиделся на Злого Петуха и назвал его злым петухом. Модератор оскорбился и усмотрел в этом нарушение правил проекта. Нажал на панельке крестик и удалил ванину трансляцию. Больше никто не видел, какой Ваня красивый и умный."
Если они это делают, не глядя, (т. е. не имея доступа к функциям для Зрителя), то Вы правы.
...
Другое дело, что роли -- это не маски, которые произвольно меняет пользователь, не информируя об этом систему, а точки зрения системы на части своего окружения.
То есть, если какой-то актер (например, Модератор) может осуществлять поведение, являющееся основным для другого актера (например, Зрителя)... то это должно отражаться в МВИ? А разве не может пользователь информировать систему: "А теперь я и Модератор, и Зритель!"? 8) Смотрю на трансляцию как актер Зритель и могу ее править как актер Модератор. Т.е. двуедин в двух лицах... Ну почти как Святой Дух ;D Или в UML отдельный реальный человек может в один момент времени быть только одним актером? И пока реальный человек выполняет роль какого-то актера он целиком и полностью ограничен поведением этого актера? Т.е. то, чего в МВИ актеру не приписано, того этот человек сделать не сможет, пока не пе6рестанет быть прежним актером и не сделается другим?
Тогда возьмем ситуацию: описываем при помощи модели какой-нибудь бизнес-процесс в какой-нибудь фирме. Допустим, там будут упоминаться актеры Директор и Бухгалтер. Два разных актера с разным поведением. А теперь допустим, что в этой фирме в данный момент один и то же человек работает одновременно на должностях директора и бухгалтера. Вуаля! Один человек в роли двух разных актеров. Или что, скажете что в таком случае нужно в модель вводить актера Директоробухгалетр с двумя стрелками к Директору и Бухгалтеру (типа, множественное наследование)? Или удалять Директора и Бухгалтера, а все их поведение присваивать Директоробухгалтеру?
Вот я чего понять не могу... ???
А если роль человека в системе меняется со временем. Например, сперва зашел на сайт. Поглазел на трансляции как обычный Зритель. Потом авторизовался, оказалось, что он Модератор, то это все тоже надо отражать? Как? В диаграммах деятельности?
-
(http://imglink.ru/pictures/11-04-12/60d5cf44dda4d3ee39f2044e666c50a2.jpg)
Эта диаграмма составлена на основе душещипательной истории Вани (выше). Верна ли она?
Кстати, мое представление о модели в процессе создания диаграммы изменилось...
ВИ "Управлять трансляцией" в данном случае означает - изменить ее настройки или удалить.
ВИ "Модерировать трансляции" - изменить настройки или удалить любую трансляцию.
Создает трансляцию теперь Пользователь и при этом становится Автором трансляции.
Вышло, что актер Зритель оказался не нужен (ведь просмотр доступен и Посетителям, и Пользователям)... Но если я хочу выделить эту роль? Что, если у Зрителя в дальнейшем появится какое-то особое поведение, недоступное Посетителю? Например, проголосовать за трансляцию? Как мне быть? Рисовать человечка Зритель. От него стрелка генерализации к Посетителю. От Пользователя стрелка генерализации к Зрителю? ??? мешанина какая-то получается...
Из диаграммы получается, что создав трансляцию, Пользователь становится Автором трансляции... По задумке, Автор трансляции может владеть только одной трансляцией. Т.е. пока он не удалит трансляцию и не станет обратно Пользователем, создавать трансляции он не может... а по диаграмме получается, что этот функционал им унаследован. Как здесь быть? Указывать вес связи: Пользователь * --- 1 Создать трансляцию?
-
Неплохо, только изобразить все-таки следует иначе - ВИ внутри прямоугольника системы, который собственно имеет название и определяет контекст рассмотрения.
Пользователя = Зарегистрированный пользователь (посетитель), т.е. усилить факт самой регистрации. Поскольку посетитель он тоже пользователь "большого и вечного"
ВИ "Управлять трансляцией" безлично. Имхо лучше "Изменить настройки своей трансляции или удалить свою трансляцию". Либо вообще два отдельных ВИ - объединить можно потом, когда будет ясно, что объединять.
ВИ "Изменить права доступа посетителя" - что тут имеется в виду?
По поводу зрителя - руководствуйтесь принципом Оккамы
-
Ну да, а в чем тут противоречие?
В своём сообщении я процитировал то, с чем не согласен. Обобщение Пользователем Автора и Модератора не является указанием на то, "что любой пользователь может получить обе эти роли независимо".
Нормально сделанная система безопасности позволяет назначить несколько ролей одному пользователю
В каком виде в модели вариантов использования будут представлены функциональные требования к указанной Вами подсистеме безопасности?
-
Нет, их функции доступны без этого.
Вам виднее. Система как-то различает авторов конференции между собой? Обычно для этого служит авторизация.
Но тут на сайт зашел модератор Злой Петух ... Он зашел на страницу трансляции, полюбовался на Ваню...
Выше указано, что для того чтобы не описывать дважды, как система демонстрирует трансляцию зрителю в рамках его 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че они с этим соглашаются.
Какой, однако, умный дядька... И объясняет доступно. Может, я и правда чересчур уперся лбом в диаграммки? Что, кстати, уже упоминалось местными эрудитами. :D Хотя, с другой стороны, нужно ведь было разобраться с непонятным, да и новые знания почерпнул... Одним словом, еще раз спасибо! )
Надеюсь, если я снова прибегу с проблемами, это не будет воспринято как чрезмерное нахальство? :)
-
Мне понравилась книга Use Case Modeling by Bittner K., Spence I. (http://www.amazon.com/Use-Case-Modeling-Kurt-Bittner/dp/0201709139/ref=sr_1_1?s=books&ie=UTF8&qid=1316877644&sr=1-1)
-
Спасибо за наводочку. Жаль не переведена на русский. Англицкую читать все же тяжеловато.
-
Спасибо за наводочку. Жаль не переведена на русский. Англицкую читать все же тяжеловато.
Читается как песня, хотя и на английском, читаю почти не перевожу в уме.
-
А как кстати будет выглядеть ДБО? Правильно ли я её нарисовал, если не считать что там нету направлений у связей и кратности.
Предлагаю такие ВИ: “Создать трансляцию”, “Изменить настройки трансляции”, “Удалить трансляцию”.
Alfia, вот у вас красивая диаграмма получилась, но я хотел бы её нарисовать со своей точки зрения. Не согласен с тем, что там есть включение ВИ Удалить трансляцию. Так как можно транслировать не удаляя трансляцию. Мне кажется, что зритель и автор, это всё таки как бы один АРМ(хоть и АРМах тут речи не идёт), поэтому можно просто пользователь. Даже вот это обобщение которое я нарисовал от пользователя к администратору мне тоже не очень нравится, так как практической пользы от него мало. 2 пользователя 3 ВИ всё просто и понятно, а уж то что в системе можно по разному настраивать права доступа от уровня администратора к уровню пользователю, это и так будет ясно из функциональных требований в текстовом виде.
Alfia эти 3 ВИ означают то же самое, что и у вас, просто немного по своему их назвал.