541

Методологии / Re: Как проанализировать причину непопулярности приложения.

« : 01 Сентября 2015, 13:47:54 »

Начните с маркетинга и затем продажами продолжите, если это не поможет, тогда начнете анализировать

542

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 01 Сентября 2015, 13:46:49 »

Для описания полностью автоматических процессов. Как-то привычнее, когда под ДЛ подразумевается именно "лицо", субъект активности (а не ее объект). Со своими интересами, целями и ожиданиями. Который как-то использует систему (именно систему, как нечто цельное). Чаще всего, какой-нибудь человекопользователь, реже - сторонняя система в информационном обмене.

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

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

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

543

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 30 Августа 2015, 19:35:14 »

С точки зрения реализации на UML, рекомендовать не могу. В BPMN, а уж тем более в BPMS, это однозначно описывал и реализовывал бы разными процессами.

Да, Андрей, вопрос уже решен. Оба этих случая действительно можно рассматривать как разные. Если бы процесс шел в правильном направлении от формирования спецификаций требований к проектных решениям и реализации, возможно описание было бы одним, но поскольку я выстраиваю описание задним числом, то сильно опираюсь на существующую реализацию, а в ней даже классы разные участвуют и разные модули приложения задействован. Я бы даже сказал, что это ВИ двух разных приложений (как оказалось в последствии).

544

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 30 Августа 2015, 19:23:17 »

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

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

545

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 29 Августа 2015, 00:17:06 »

Эд, прошла неделя с моего вопроса.

Тебе правда интересна эта тема?

Денис, я все уже для себя выяснил.

546

Sparx / Re: Проверка орфографии русского языка

« : 28 Августа 2015, 00:19:31 »

Нет, предложите свои услуги Спарксу, вдруг он найдет это интересным.

547

Sparx / Re: Фильтрация элементов при выводе в документ (Enterprise Architect 12)

« : 28 Августа 2015, 00:18:17 »

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

548

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 26 Августа 2015, 12:58:39 »

Что такое "ДЛ"?

Действующее лицо, эктор, actor, тот, кто инициирует или участвует в процессе, являясь нечто внешним по отношению к исполнительному объекту.

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

Для чего кейс наименее подходящий способ?

549

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 20 Августа 2015, 23:28:31 »

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

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

550

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 20 Августа 2015, 23:27:16 »

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

Да, Леонид, Вы правы. Я это в последствии понял.

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

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

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

Конечно, можно. Про кейсы с железным болваном, у него ДЛ может быть время (ну или таймер) действие по расписанию. Впрочем эту функциональность можно описать разным способом: и кейсом и, например, машиной состояний.

551

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 19 Августа 2015, 20:19:45 »

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

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

552

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 19 Августа 2015, 20:13:50 »

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

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

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

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

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

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

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

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

553

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 18 Августа 2015, 16:24:33 »

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

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

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

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

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

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

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

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

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

554

Варианты Использования (Use Case) / Re: Вариация одного варианта использования или разные варианты использования

« : 18 Августа 2015, 12:51:05 »

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

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

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

555

Варианты Использования (Use Case) / Вариация одного варианта использования или разные варианты использования

« : 18 Августа 2015, 11:43:06 »

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

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

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

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

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

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

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

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