Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: adelante от 12 Сентября 2012, 23:50:57
-
Привет коллеги.
Хочу посоветоваться с вами по практике использования UC.
Суть проблемы:
Часто возникает ситуация, что несколько экторов взаимодействуют с системой для достижения одной и той же цели, но по разному.
При этом, в зависимости от эктора, сильно отличаются как шаги сценариев UC, так и предусловие. Хуже того, в зависимости от эктора, у UC могут быть разные расширяющие UC.
Например, представим себе UC "Редактировать заказ". Пусть эктор "исполнитель" редактирует заказ, при этом он может редактировать определенный набор атрибутов, и заказы в определенном состоянии. Эктор "заказчик" -- совершенно другие атрибуты и заказы определенных состояний. Эктор администратор вообще на этапе редактирования имеет возможность попутно создать, скажем, новый "Проект", т.е. запустится расширяющий UC "создать проект". Кроме того, эктор "заказчик", скажем не может редактировать заказ после определенного числа.
Это еще не сложный пример, бывает поведение UC еще больше разнится, в зависимости от того, кто является инициатором.
Тут, естественно, есть два пути:
- Обобщить экторов в нового эктора и соединить его с нашим UC. Далее навесить бизнес правила/доп. требвоания/права доступа к UC, где уточнить кто, что и когда может. Но это все ровно не решает проблемы extend и include других UC. В зависимости от экторов у нашего UC может быть разный набор таких взаимосвязей. Кроме того бывает, что сами шаги UC сильно зависят от эктора. Далее -- в большой системе придется достаточно много вводить таких виртуальных группирующих экторов, ровно столько, сколько будет сочетаний экторов между собой. Модель станет перегруженной и громоздкой
- Выделять UC а ля "Редактировать заказ исполнителем". Т.е для каждого эктора -- свой UC. Минусы очевидны, дублирование описания поведения системы
Другие варианты?
Спасибо!
-
Добрый день!
Я где-то вычитал, что "хороший UC - это простой UC".
При рассмотрении Вашего примера мне показалось, что Вы в плену слова "редактирование". На самом деле, экторы в вашем примере имеют разные цели: "создать заказ", "детализировать информацию заказа", "назначить заказ исполнителю", "создать проект выполнения заказа", "закрыть заказ" и т.п. Различные цели - различные (достаточно простые) UC.
Конечно, эти UC имеют одинаковые фрагменты, например, "выбор заказа". Выделите его в UCI, и никакого дублирования не будет!
Дополнительно:
Название "Редактировать заказ исполнителем", мне кажется, неудачное:
1) Вы указываете эктора в названии UC (дублируете информацию диаграммы, на которой, наверное, Вы нарисуете этого эктора).
2) Слово "Редактировать" в названии UC какое-то аморфное; оно мало что говорит о действительной цели.
-
Здравствуйте.
Насколько я помню (читал в одной из статей блога Александра Шамрай, потом сделал краткую выжимку: http://it-analysis.blogspot.com/2011/03/blog-post_24.html), операции с данными (СЧОУ -- создание, чтение, обновление, удаление -- сюда можно и отнести редактирование) не рекомендуется выносить в виде отдельных UC.
Я бы порекомендовал выделять в виде UC только действительно важные цели пользователя, которые принесут ему ощутимую пользу. Все остальное опишите в виде текстовых требований, привязанных к конкретному варианту использования.
-
Ну да, в большинстве случаев, необходимо создать CRUD UC, где описать все действия по созданию редактированию, удалению, и просмотру некоторых сущностей.
Но в данном случае вопрос был не совсем об этом. UC "Редактировать заказ" это лишь пример.
-
Добрый день!
Я где-то вычитал, что "хороший UC - это простой UC".
При рассмотрении Вашего примера мне показалось, что Вы в плену слова "редактирование". На самом деле, экторы в вашем примере имеют разные цели: "создать заказ", "детализировать информацию заказа", "назначить заказ исполнителю", "создать проект выполнения заказа", "закрыть заказ" и т.п. Различные цели - различные (достаточно простые) UC.
Конечно, эти UC имеют одинаковые фрагменты, например, "выбор заказа". Выделите его в UCI, и никакого дублирования не будет!
Дополнительно:
Название "Редактировать заказ исполнителем", мне кажется, неудачное:
1) Вы указываете эктора в названии UC (дублируете информацию диаграммы, на которой, наверное, Вы нарисуете этого эктора).
2) Слово "Редактировать" в названии UC какое-то аморфное; оно мало что говорит о действительной цели.
1. Все перечисленные вами UC есть в системе. Создать, назначить, закрыть...тут вопросов нет.
2. Я могу привести другой пример, раз "Редактировать заказ" вам кажется аморфным. Например "Просмотреть детальную информацию о заказе". Это могут сделать все пользователи, но, скажем, только заказчик, может на этапе просмотра заказа "Добавить задачу для заказа", т.е. запустить расширяющий UC.
-
2. Я могу привести другой пример, раз "Редактировать заказ" вам кажется аморфным. Например "Просмотреть детальную информацию о заказе". Это могут сделать все пользователи, но, скажем, только заказчик, может на этапе просмотра заказа "Добавить задачу для заказа", т.е. запустить расширяющий UC.
Тогда добавляйте БПр в сценарии ВИ и там это описывайте, даете ссылку в шаге раширения на это БПр.
-
Здравствуйте.
Насколько я помню (читал в одной из статей блога Александра Шамрай, потом сделал краткую выжимку: http://it-analysis.blogspot.com/2011/03/blog-post_24.html), операции с данными (СЧОУ -- создание, чтение, обновление, удаление -- сюда можно и отнести редактирование) не рекомендуется выносить в виде отдельных UC.
Я бы порекомендовал выделять в виде UC только действительно важные цели пользователя, которые принесут ему ощутимую пользу. Все остальное опишите в виде текстовых требований, привязанных к конкретному варианту использования.
Насколько я понял из примера (уточнения adelante не изменили моего мнения), речь идет не о типовой ситуации СЧОУ. Фактически, каждый эктор имеет свою цель (и свои права!).
Но спор здесь не продуктивен. adelante просит варианты. Все предложенные варианты правильные. Я предложил тот, которым пользуюсь (как правило, но не всегда).
-
Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..
В общем случае получается что приходиться создавать столько виртуальных обобщенных экторов сколько есть сочетаний между конкретными экторами.
Это выглядит на диаграмме очень грустно и печально (
-
Может быть тогда на ДВИ таких пользователей объеденить в одного - Пользователь, а в БПр указать кто может выполнять?
Нет единственного правильного решения, делайте как Вам будет удобнее исходя из ваших запросов потребителей ДВИ и спек.
-
Великий Коберн и некоторые другие считают, что UC может иметь только одного первичного эктора.
Если не нравятся "виртуальные" экторы, назначьте этора "Пользователь" (обычно, предок всех остальных) и права доступа опишите в предусловиях.
-
Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..
Но, по крайней мере, здесь все равно пять UC!
-
Великий Коберн и некоторые другие считают, что UC может иметь только одного первичного эктора.
Если не нравятся "виртуальные" экторы, назначьте этора "Пользователь" (обычно, предок всех остальных) и права доступа опишите в предусловиях.
Именно это мне и приходиться делать(
БП + предусловия.
Минус: диаграмма "не говорящая"
-
Но, по крайней мере, здесь все равно пять UC!
Да, редактировать заказ -- это тоже отдельный UC. Точнее "Редактировать параметры заказа"
-
На диаграммах полезно делать примечания.
-
Из моего опыта, заказ имеет состояния, например, "зарегистрирован", "принят", "назначен" и т.д.
Номенклатура параметров, которые можно редактировать, зависит не только от эктора, но и от состояния.
Я стараюсь делать более простые UC, чтобы я мог указать все предусловия, а не рассыпать условия в тексте или на диаграмме деятельности!
-
Тогда добавляйте БПр в сценарии ВИ и там это описывайте, даете ссылку в шаге раширения на это БПр.
Кстати, да. О том, как можно это делать, можно почитать тут (http://it-analysis.blogspot.com/2012/08/use-cases-and-business-rules-can-they.html) (некоторое время назад я занимался переводом англоязычной статьи).
-
Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..
В общем случае получается что приходиться создавать столько виртуальных обобщенных экторов сколько есть сочетаний между конкретными экторами.
Это выглядит на диаграмме очень грустно и печально (
Моё мнение. Я бы в таком случае классифицировал диаграммы по типам пользователей. Для каждого пользователя создал бы отдельную ДВИ -- было бы проще.
Но вариант с общей ДВИ и бизнес-правилами, связанными с конкретной ролью, мне тоже нравится.
-
Моё мнение. Я бы в таком случае классифицировал диаграммы по типам пользователей. Для каждого пользователя создал бы отдельную ДВИ -- было бы проще.
Тогда вы создаете одинаковые UC для каждого из пользователей. Дублируется описание. Если будут изменения -- придется править везде.
Если же вы имеете ввиду на разных диаграммах показывать одни и те же UC, но с разными экторами -- то у UC будет несколько праймари экторов, что недопустимо.
-
Кстати, да. О том, как можно это делать, можно почитать тут (http://it-analysis.blogspot.com/2012/08/use-cases-and-business-rules-can-they.html) (некоторое время назад я занимался переводом англоязычной статьи).
Хорошая ссылка!
Некоторые из приемов я как раз и применяю на практике.
БП формулируются в виде Supplementary Requirements, на которые ссылается UC.
Создать задание
1. Менеджер выбирает создать задание.
2. Менеджер вводит атрибуты задания в соответствии с SUP-2.1 "Правила заполнения/ отображения/ валидации атрибутов при создании нового задания".
3. Система определяет возможность размещения необходимого количества рекламных макетов (в соответствии с SUP-2.8 "Алгоритм проверки возможности выполнения заявки")
4. Система создает задание и переводит его в состояние "Открыто".
5. Система изменяет количество свободных и зарезервированных тележек в гипермаркете соответствии с SUP-2.9 "Алгоритм выбора тележек для задания".