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

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

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

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

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

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

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

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

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

А какая разница? На что это повлияет?

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

Привел в качестве дополнительного аргумента к мысли о раздельных процессах. Именно для полноты картины.

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

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

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

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

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

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

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

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

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

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

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

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

С точки зрения реализации на UML, рекомендовать не могу. В BPMN, а уж тем более в BPMS, это однозначно описывал и реализовывал бы разными процессами.
Вы странно споткнулись на том, что выполнять заявку будет тот же, кто ее принимал. Но ведь делать то это он начнет не обязательно СРАЗУ, то есть процесс не сквозной. Да и не аксиома это. Принять заявку человек может в последний день перед отпуском или увольнением.
Рвите реализацию на "Заявка зарегистрирована". И под каждый вариант сериса выделяйте свой процесс. Тем более, что методов регистрации уже несколько, а может стать еще больше. Не расширять же каждый раз рабочий модуль, плодя в нём баги.

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

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

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

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

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

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

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

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

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

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

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

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