Добрый день, друзья!

Возникла задача документирования существующей системы. Решил начать с выявления реализованных use cases и столкнулся с некоторым моментом, который замечал и раньше, но не уделял этому должного внимания, чтобы разобраться.

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

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

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

Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.

А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.

Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?

Эдуард, добрый день. По-моему, возможны оба варианта. Ответ - как договоритесь. Но, по-моему, красивее будет описать один общий вариант использования с общими шагами сценария (можно совсем верхнеуровнево) и к нему прицепить реализацию сценария использования (два варианта реализации) с детальным описанием.

Эдуард, добрый день. По-моему, возможны оба варианта. Ответ - как договоритесь. Но, по-моему, красивее будет описать один общий вариант использования с общими шагами сценария (можно совсем верхнеуровнево) и к нему прицепить реализацию сценария использования (два варианта реализации) с детальным описанием.

Привет, Дмитрий. Не совсем уловил твою мысль насчет прикрепления реализации сценария с детальным описанием.

Ты имеешь в виду обобщение? Или реализацию сценариев в виде диаграмм последовательностей?

Жизненный цикл заявки - это внутреннее устройство системы. А вариант использования обычно описывает взаимодействие с системой снаружи.
Можно, конечно, вспомнить про разные уровни ВИ, но в данном случае уровень понятен - это взаимодействие двух разных пользователей с системой. Поэтому imho это два разных варианта использования, которые, возможно, даже не пересекаются.

Ты имеешь в виду обобщение? Или реализацию сценариев в виде диаграмм последовательностей?

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

Добрый день, друзья!

Возникла задача документирования существующей системы. Решил начать с выявления реализованных use cases и столкнулся с некоторым моментом, который замечал и раньше, но не уделял этому должного внимания, чтобы разобраться.

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

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

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

Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.

А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.

Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?

Эдуард, добрый день!

А вы не рассматривали вариант двух разных юзкейсов с включением общего поведения (include) в третий юзкейс?

Эдуард, добрый день!

А вы не рассматривали вариант двух разных юзкейсов с включением общего поведения (include) в третий юзкейс?

Сергей, добрый день. Нет, не рассматривал. Но чуточку подумав, решил, что тут не прокатит.

Гриша, да ты прав. Я рассматриваю то, что уже имеется. Вижу, что даже внешне имеются различия.

Пользователь - работает с фронт эндом
Менеджер с бэкендом

Пользователю подгружается просто заявка
Менеджеру погружается заявка с внедренным объектом дополнительный параметров

Естественно предусловия, постусловия, проверки и альтернативные потоки сильно разные

Общее, что создается заявка - одинаковый объект.

А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.

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

А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.

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

Сергей, добрый день. Нет, не рассматривал. Но чуточку подумав, решил, что тут не прокатит

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

А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.

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

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

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

Может Вы попробуете проиллюстрировать то, что Вам кажется возможным?

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

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

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

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

Примерно так ))

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

Да нет никакой новой реализации )) Документирование системы нужно для сохранения знания, типа.

Да нет никакой новой реализации )) Документирование системы нужно для сохранения знания, типа.

Ещё такой вариант... Как уже писали выше сделать два юзкейса + include третьего с общим поведением. А далее если текущие реализации общего поведения сделаны по разному, тогда для общего юзкейса не нужно делать use case realization. А сделать разные use case realization для двух других юзкейсов.

Возможно, я не совсем точно понял суть проблемы. Я вижу в приведенной постановке отдельные процессы, выполнение которых можно рассматривать как параллельно, так и последовательно (в зависимости от точки зрения и поставленных задач). Но описывать надо раздельно. Поясню.

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

Процесс первый: "Регистрация зародыша заявки при помощи инструментов самообслуживания". Который начинается с манипуляций пользователя с фронтэндом и заканчивается регистрацией в системе заявки установленной формы. Всё.

А вот совсем другой процесс "оформление заявки оператором", никак не связанный с первым:

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

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

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

Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.

А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.

То, что в процессе пребывания в каком-то из состояний с этими заявками кто-то что-то делает, картины не портит и может быть описано отдельными процессами. 

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