Нюансы разработки модели UC(Прочитано 11403 раз)
Re: Нюансы разработки модели UC Ответ #15 : 13 Сентября 2012, 15:41:51
Тогда добавляйте БПр в сценарии ВИ и там это описывайте, даете ссылку в шаге раширения на это БПр.

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



Re: Нюансы разработки модели UC Ответ #16 : 13 Сентября 2012, 15:45:37
Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..


В общем случае получается что приходиться создавать столько виртуальных обобщенных экторов сколько есть сочетаний между конкретными экторами.
Это выглядит на диаграмме очень грустно и печально (


Моё мнение. Я бы в таком случае классифицировал диаграммы по типам пользователей. Для каждого пользователя создал бы отдельную ДВИ -- было бы проще.

Но вариант с общей ДВИ и бизнес-правилами, связанными с конкретной ролью, мне тоже нравится.



Re: Нюансы разработки модели UC Ответ #17 : 13 Сентября 2012, 19:45:06
Моё мнение. Я бы в таком случае классифицировал диаграммы по типам пользователей. Для каждого пользователя создал бы отдельную ДВИ -- было бы проще.


Тогда вы создаете одинаковые UC для каждого из  пользователей. Дублируется описание. Если будут изменения -- придется править везде.
Если же вы имеете ввиду на разных диаграммах показывать одни и те же UC, но с разными экторами -- то у UC будет несколько праймари экторов, что недопустимо.



Re: Нюансы разработки модели UC Ответ #18 : 13 Сентября 2012, 19:51:02
Кстати, да. О том, как можно это делать, можно почитать тут (некоторое время назад я занимался переводом англоязычной статьи).

Хорошая ссылка!
Некоторые из приемов я как раз и применяю на практике.
БП формулируются в виде Supplementary Requirements, на которые ссылается UC.

Создать задание

1. Менеджер выбирает создать задание.
2. Менеджер вводит атрибуты задания в соответствии с SUP-2.1 "Правила заполнения/ отображения/ валидации атрибутов при создании нового задания".
3. Система определяет возможность размещения необходимого количества рекламных макетов (в соответствии с SUP-2.8 "Алгоритм проверки возможности выполнения заявки")
4. Система создает задание и переводит его в состояние "Открыто".
5. Система изменяет количество свободных и зарезервированных тележек в гипермаркете соответствии с SUP-2.9 "Алгоритм выбора тележек для задания".
« Последнее редактирование: 13 Сентября 2012, 19:53:02 от adelante »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19