Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Galogen от 18 Августа 2015, 11:43:06
-
Добрый день, друзья!
Возникла задача документирования существующей системы. Решил начать с выявления реализованных use cases и столкнулся с некоторым моментом, который замечал и раньше, но не уделял этому должного внимания, чтобы разобраться.
Итак, в чем же проблема.
Пользователь веб- или мобильного приложения может разместить заявку на выполнение определенной услуги. При этом заявка попадает в список не распределенных заявок и ожидает своей очереди.
Однако заявку можно оставить, и придя в офис лично или позвонив по телефону. В этом случае оформляет заявку оператор. Если заявку оформляет оператор, то заявка уже попадает в список заявок этого оператора. При оформлении заявки в таком случае существует возможность указывать больше деталей и особенностей этой заявки, чем у заявки, которую размещает обычный пользователь.
В целом жизненные циклы заявки созданных разными способами одинаковы, за исключением начального состояния и одного правила перехода.
Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.
А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.
Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?
-
Эдуард, добрый день. По-моему, возможны оба варианта. Ответ - как договоритесь. Но, по-моему, красивее будет описать один общий вариант использования с общими шагами сценария (можно совсем верхнеуровнево) и к нему прицепить реализацию сценария использования (два варианта реализации) с детальным описанием.
-
Эдуард, добрый день. По-моему, возможны оба варианта. Ответ - как договоритесь. Но, по-моему, красивее будет описать один общий вариант использования с общими шагами сценария (можно совсем верхнеуровнево) и к нему прицепить реализацию сценария использования (два варианта реализации) с детальным описанием.
Привет, Дмитрий. Не совсем уловил твою мысль насчет прикрепления реализации сценария с детальным описанием.
Ты имеешь в виду обобщение? Или реализацию сценариев в виде диаграмм последовательностей?
-
Жизненный цикл заявки - это внутреннее устройство системы. А вариант использования обычно описывает взаимодействие с системой снаружи.
Можно, конечно, вспомнить про разные уровни ВИ, но в данном случае уровень понятен - это взаимодействие двух разных пользователей с системой. Поэтому imho это два разных варианта использования, которые, возможно, даже не пересекаются.
-
Ты имеешь в виду обобщение? Или реализацию сценариев в виде диаграмм последовательностей?
В данном случае, это может быть либо обобщение, либо, как написал Григорий - два разных варианта использования.
-
Добрый день, друзья!
Возникла задача документирования существующей системы. Решил начать с выявления реализованных use cases и столкнулся с некоторым моментом, который замечал и раньше, но не уделял этому должного внимания, чтобы разобраться.
Итак, в чем же проблема.
Пользователь веб- или мобильного приложения может разместить заявку на выполнение определенной услуги. При этом заявка попадает в список не распределенных заявок и ожидает своей очереди.
Однако заявку можно оставить, и придя в офис лично или позвонив по телефону. В этом случае оформляет заявку оператор. Если заявку оформляет оператор, то заявка уже попадает в список заявок этого оператора. При оформлении заявки в таком случае существует возможность указывать больше деталей и особенностей этой заявки, чем у заявки, которую размещает обычный пользователь.
В целом жизненные циклы заявки созданных разными способами одинаковы, за исключением начального состояния и одного правила перехода.
Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.
А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.
Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?
Эдуард, добрый день!
А вы не рассматривали вариант двух разных юзкейсов с включением общего поведения (include) в третий юзкейс?
-
Эдуард, добрый день!
А вы не рассматривали вариант двух разных юзкейсов с включением общего поведения (include) в третий юзкейс?
Сергей, добрый день. Нет, не рассматривал. Но чуточку подумав, решил, что тут не прокатит.
Гриша, да ты прав. Я рассматриваю то, что уже имеется. Вижу, что даже внешне имеются различия.
Пользователь - работает с фронт эндом
Менеджер с бэкендом
Пользователю подгружается просто заявка
Менеджеру погружается заявка с внедренным объектом дополнительный параметров
Естественно предусловия, постусловия, проверки и альтернативные потоки сильно разные
Общее, что создается заявка - одинаковый объект.
А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.
-
Я подобный случай рассматриваю на тренинге на примере коммунального платежа. Единственное рабочее решение, которое я нашел - это больше двух ВИ, как минимум один из них должен быть обобщающим. И, да, это достаточно сложный случай. Пожалуй, это самое сложное упражнение на тренинге. За один проход такое не делается. Пример с коммунальным платежом я шлифовал несколько лет. А когда в реальной жизни столкнулся с примером такой сложности понадобилось более 10 часов на проработку и потом еще часов 20 на донесение до остальных участников проекта.
-
А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.
Похоже, твои предшественники не смогли справиться со сложностью и были вынужденны создать плохо поддерживаемый код.
-
Сергей, добрый день. Нет, не рассматривал. Но чуточку подумав, решил, что тут не прокатит
Эдуард, не могли бы пояснить почему вы считаете что не прокатит?
-
А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.
Если реализация отличается, но соответствующие требования пересекаются, я бы выделил общую часть двух юзкейсов во включаемый третий. Хотя, с другой стороны, если в новой реализации планируется преднамеренно оставить две разные реализации, то лучше оставить два разных юзкейса.
-
Эдуард, не могли бы пояснить почему вы считаете что не прокатит?
Я не могу делиться реальными деталями проекта. Потому могу только говорить намеками.
Однако у нас есть некая общая часть, в чем она заключается в некотором небольшом наборе заполняемых данных. Я просто не вижу целесообразности в этом.
Может Вы попробуете проиллюстрировать то, что Вам кажется возможным?
Предположим фирма выполняет установку окон. Они используют некий сервис регистрации заявок на установку окон.
Заявка может завершиться заключением договора, но может и нет. Заявка - это элемент управления и организации работы.
Типично заявки делают сами клиенты на сайте или в мобильном приложении. Минимально клиенту достаточно указать: Имя, телефон и когда ему можно звонить для согласования. Если клиент желает, то может указать свой адрес, количество окон на вставку, и указать из предоставляемого списка тип окна и другие дополнительные материалы типа откосы, подокойник и т.п.
Данная заявка попадает в общий пул заявок. Сотрудник компании выбирает из списка очередную заявку и берет ее на себя и начинает по ней работать, т.е. связывается с клиентом и уточняет детали заявки, если клиент не может сейчас говорить, то заявке указывается новое время звонка и так происходит до тех пор, пока либо заявку не закроем, либо по ней не будет сформирован заказ на установку
Поскольку клиенты могут приходить в офис или звонить, то заявку принимает сотрудник компании, в этом случае сотрудник оформляет заявку на себя, при это оформление заявки совмещается с первым звонком клиенту. В этом случае заявка оказывается списке заявок данного сотрудника. При этом при таком оформлении заявки формируются дополнительные разделы, формируется история работы по заявки, появляется возможность перевода состояний и передачи заявки другому сотруднику.
Примерно так ))
-
Если реализация отличается, но соответствующие требования пересекаются, я бы выделил общую часть двух юзкейсов во включаемый третий. Хотя, с другой стороны, если в новой реализации планируется преднамеренно оставить две разные реализации, то лучше оставить два разных юзкейса.
Да нет никакой новой реализации )) Документирование системы нужно для сохранения знания, типа.
-
Да нет никакой новой реализации )) Документирование системы нужно для сохранения знания, типа.
Ещё такой вариант... Как уже писали выше сделать два юзкейса + include третьего с общим поведением. А далее если текущие реализации общего поведения сделаны по разному, тогда для общего юзкейса не нужно делать use case realization. А сделать разные use case realization для двух других юзкейсов.
-
Возможно, я не совсем точно понял суть проблемы. Я вижу в приведенной постановке отдельные процессы, выполнение которых можно рассматривать как параллельно, так и последовательно (в зависимости от точки зрения и поставленных задач). Но описывать надо раздельно. Поясню.
Пользователь веб- или мобильного приложения может разместить заявку на выполнение определенной услуги. При этом заявка попадает в список не распределенных заявок и ожидает своей очереди.
Процесс первый: "Регистрация зародыша заявки при помощи инструментов самообслуживания". Который начинается с манипуляций пользователя с фронтэндом и заканчивается регистрацией в системе заявки установленной формы. Всё.
А вот совсем другой процесс "оформление заявки оператором", никак не связанный с первым:
...лично или позвонив по телефону. В этом случае оформляет заявку оператор. Если заявку оформляет оператор, то заявка уже попадает в список заявок этого оператора. При оформлении заявки в таком случае существует возможность указывать больше деталей и особенностей этой заявки, чем у заявки, которую размещает обычный пользователь.
А дальше третий процесс, не зависящий от первых двух. Причем, пользователей не имеющий, поскольку полностью автоматический - банальная "маршрутизация" заявок по заранее установленным правилам, включающим тайминги, атрибуты заявки и наборы переходов:
В целом жизненные циклы заявки созданных разными способами одинаковы, за исключением начального состояния и одного правила перехода.
Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.
А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.
То, что в процессе пребывания в каком-то из состояний с этими заявками кто-то что-то делает, картины не портит и может быть описано отдельными процессами.
Таким образом, у меня получилось несколько самостоятельных процессов: два с живыми людьми, один полностью на железном болване и несколько потенциальных (состав участников непонятен), посвященных непосредственно обработке заявки в недрах организации. На них можно "натянуть" кейсы, или это против правил?
-
Возможно, я не совсем точно понял суть проблемы. Я вижу в приведенной постановке отдельные процессы, выполнение которых можно рассматривать как параллельно, так и последовательно (в зависимости от точки зрения и поставленных задач). Но описывать надо раздельно. Поясню.
Да, Леонид, Вы правы. Я это в последствии понял.
А дальше третий процесс, не зависящий от первых двух. Причем, пользователей не имеющий, поскольку полностью автоматический - банальная "маршрутизация" заявок по заранее установленным правилам, включающим тайминги, атрибуты заявки и наборы переходов:
Немного не понял об этом. Я то говорил о регистрации заявки, а то, что с ней происходит в дальнейшем записал для полноты картины. Понятно, что это отдельный процесс.
Таким образом, у меня получилось несколько самостоятельных процессов: два с живыми людьми, один полностью на железном болване и несколько потенциальных (состав участников непонятен), посвященных непосредственно обработке заявки в недрах организации. На них можно "натянуть" кейсы, или это против правил?
Конечно, можно. Про кейсы с железным болваном, у него ДЛ может быть время (ну или таймер) действие по расписанию. Впрочем эту функциональность можно описать разным способом: и кейсом и, например, машиной состояний.
-
Ещё такой вариант... Как уже писали выше сделать два юзкейса + include третьего с общим поведением. А далее если текущие реализации общего поведения сделаны по разному, тогда для общего юзкейса не нужно делать use case realization. А сделать разные use case realization для двух других юзкейсов.
Сергей, мне кажется в данном случае это не представляется возможным, там общая часть ну очень примитивна.
-
Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?
А какая разница? На что это повлияет?
-
Немного не понял об этом. Я то говорил о регистрации заявки, а то, что с ней происходит в дальнейшем записал для полноты картины. Понятно, что это отдельный процесс.
Привел в качестве дополнительного аргумента к мысли о раздельных процессах. Именно для полноты картины.
Конечно, можно. Про кейсы с железным болваном, у него ДЛ может быть время (ну или таймер) действие по расписанию. Впрочем эту функциональность можно описать разным способом: и кейсом и, например, машиной состояний.
Что такое "ДЛ"?
Да, что расписать можно разными способами, это понятно. Просто показалось, что кейс для этого - один из наименее подходящих способов. По крайней мере, для моего уровня понимания этого инструмента.
-
Что такое "ДЛ"?
Действующее лицо, эктор, actor, тот, кто инициирует или участвует в процессе, являясь нечто внешним по отношению к исполнительному объекту.
Да, что расписать можно разными способами, это понятно. Просто показалось, что кейс для этого - один из наименее подходящих способов. По крайней мере, для моего уровня понимания этого инструмента.
Для чего кейс наименее подходящий способ?
-
Эд, прошла неделя с моего вопроса.
Тебе правда интересна эта тема?
-
Эд, прошла неделя с моего вопроса.
Тебе правда интересна эта тема?
Денис, я все уже для себя выяснил.
-
ну т.е. ты публично отказываешься поддерживать со мной диалог?
-
С точки зрения реализации на UML, рекомендовать не могу. В BPMN, а уж тем более в BPMS, это однозначно описывал и реализовывал бы разными процессами.
Вы странно споткнулись на том, что выполнять заявку будет тот же, кто ее принимал. Но ведь делать то это он начнет не обязательно СРАЗУ, то есть процесс не сквозной. Да и не аксиома это. Принять заявку человек может в последний день перед отпуском или увольнением.
Рвите реализацию на "Заявка зарегистрирована". И под каждый вариант сериса выделяйте свой процесс. Тем более, что методов регистрации уже несколько, а может стать еще больше. Не расширять же каждый раз рабочий модуль, плодя в нём баги.
-
ну т.е. ты публично отказываешься поддерживать со мной диалог?
Я же сказал, что вопрос решен. Ситуацию следует рассматривать как два разных варианта использования.
-
С точки зрения реализации на UML, рекомендовать не могу. В BPMN, а уж тем более в BPMS, это однозначно описывал и реализовывал бы разными процессами.
Да, Андрей, вопрос уже решен. Оба этих случая действительно можно рассматривать как разные. Если бы процесс шел в правильном направлении от формирования спецификаций требований к проектных решениям и реализации, возможно описание было бы одним, но поскольку я выстраиваю описание задним числом, то сильно опираюсь на существующую реализацию, а в ней даже классы разные участвуют и разные модули приложения задействован. Я бы даже сказал, что это ВИ двух разных приложений (как оказалось в последствии).
-
Для чего кейс наименее подходящий способ?
Для описания полностью автоматических процессов. Как-то привычнее, когда под ДЛ подразумевается именно "лицо", субъект активности (а не ее объект). Со своими интересами, целями и ожиданиями. Который как-то использует систему (именно систему, как нечто цельное). Чаще всего, какой-нибудь человекопользователь, реже - сторонняя система в информационном обмене.
Назвать же "использованием" то, что происходит в недрах системы и скрыто от посторонних глаз, как-то язык не поворачивается.
Я не утверждаю, что нельзя. Просто выглядит это как-то... неуместно, что-ли. Впрочем, из меня кейсостроитель тот еще.
-
Для описания полностью автоматических процессов. Как-то привычнее, когда под ДЛ подразумевается именно "лицо", субъект активности (а не ее объект). Со своими интересами, целями и ожиданиями. Который как-то использует систему (именно систему, как нечто цельное). Чаще всего, какой-нибудь человекопользователь, реже - сторонняя система в информационном обмене.
Назвать же "использованием" то, что происходит в недрах системы и скрыто от посторонних глаз, как-то язык не поворачивается.
Я не утверждаю, что нельзя. Просто выглядит это как-то... неуместно, что-ли. Впрочем, из меня кейсостроитель тот еще.
А ну, да полностью согласен. Хотя любой автоматический процесс автоматичен ради каких-то ведь интересов и при прямом инжиниринге не сразу становится ясно, какой процесс будет автоматичным. Все-таки ВИ это требование.