Леонид, а что такое архитектурно существенные варианты использования? Каков критерий их отбора, отображения?

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

Просьба не отождествлять функции системы и варианты использования, это разные вещи, с несколько разным назначением. Функции системы, это взгляд с точки зрения системы "на мир ее окружающий" :-), т.е. это в т.ч. то, что система экспонирует наружу. Юзкейс - это именованная цель пользователя по отношению к системе (бизнес- или технической). При этом функции легко декомпозируемы, юзкейсы - только в пределах отношений между уровнями описаний (т.е. не декомпозируемы). Очевидно, в процессе выполнения сценариев юзкейса будут использованы те или иные функции. Более того, на основании юзкейсов могут быть определены сами функции системы (подход сверху-вниз). Как в прочем и по набору функций можно придумать юзкейсы, но нужно иметь определенную фантазию :-) (подход снизу-вверх).

Так же очевидно, что для проектирования системы одних юзкейсов не достаточно, если под проектированием мы понимаем, как минимум blueprint.

По-прежнему продолжаете считать мой ответ, ответом Шерлока Холмса?

Ну, это термин из RUP-а. Изначально использовался в планировании.

Для снижения рисков производится сортировка UC по их потенциальному влиянию на архитектуру продукта.
Т.к. в RUP фактически каждый UC предполагает выпуск (внутренней или внешней версии), производится анализ степени изменения архитектуры от выпуска к выпуску. Незначительность изменения архитектуры сигнализирует о достижении стабильной архитектуры (веха Архитектура жизненного цикла).

Основной элемент планирования в RUP - это UC. Отсюда признак (и мера) существенности: планируется отдельно или нет.

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

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

Ну, то же самое с UCI: есть смысл выделять, или проще в каждом UC этот несущественный фрагмент повторить.

UCI ставятся в план перед первым использующим основным UC, UCE - после включающего UC.

Юра! Это, наверное, очень строгие определения.
Но у меня вопрос: функции системы и функциональные требования к системе - это сильно разное?

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

Юра, прости, а как понимать, что UC не декомпозируемы?

UC как описание процесса? как формулировка функционального требования? как "название"?

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

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

И чем система проявляет себя в среде, как не интерфейсами (те же UC), если не вспоминать нефункциональные требования, например, цвет корпуса компьютера?

Юра! Это, наверное, очень строгие определения.
Но у меня вопрос: функции системы и функциональные требования к системе - это сильно разное?

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

Леонид Борисович, учитывая что вопрос отношений функций и юзкейсов всплывает периодически, я в свое время написал заметку в своем блоге http://yurybuluy.blogspot.com/2010/12/use-cases.html. Позволю себе адресовать к ней в качестве ответа на вопрос, и конечно же рад буду услышать ваше мнение.

Юра, прости, а как понимать, что UC не декомпозируемы?

UC как описание процесса? как формулировка функционального требования? как "название"?

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

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

И чем система проявляет себя в среде, как не интерфейсами (те же UC), если не вспоминать нефункциональные требования, например, цвет корпуса компьютера?

Декомпозиция - как правило это иерархия. Говоря о функциях, можно построить дерево функций, где наверху будет некая "большая функция", уровнем ниже - ее детализация. Юзкейсы не имеют как таковой строгой иерархии, иначе они бы выродились в функции. В то же время, если принимать "классификацию" Коберна - он определяет уровни целей юзкейсов, и соответственно можно говорить о контексте - например, юзкейсы уровня моря МОГУТ (но не обязательно должны) выполняются в контексте юзкейсов уровня змея/облака. Невозможность построения иерархии юзкейсов вполне может быть трактовано, как их недекомпозируемость.

Декомпозиция - как правило это иерархия. Говоря о функциях, можно построить дерево функций, где наверху будет некая "большая функция", уровнем ниже - ее детализация. Юзкейсы не имеют как таковой строгой иерархии, иначе они бы выродились в функции. В то же время, если принимать "классификацию" Коберна - он определяет уровни целей юзкейсов, и соответственно можно говорить о контексте - например, юзкейсы уровня моря МОГУТ (но не обязательно должны) выполняются в контексте юзкейсов уровня змея/облака. Невозможность построения иерархии юзкейсов вполне может быть трактовано, как их недекомпозируемость.

Спасибо за ответ, но он меня не удовлетворил.

1. Декомпозиция не всегда иерархия (элемент этой декомпозиции м.б элементом многоразового использования, т.е. элементом и другой декомпозиции).
2. Декомпозиция допускает, что элементы дочернего уровня представляют собой нечто иное, чем их агрегат (в нашем случае элемент декомпозиции UC вовсе не обязан быть UC).
3. UC (описание взаимодействий для достижения цели) декомпозируется в набор описаний отдельных действий по достижению этой цели.
4. UC - это описание функции (но не любой, а отвечающей некоторым требованиям, сформулировнным в определении термина UC).
5. UC не может выродится в функцию, не являющуюся UC, т.к. в этом случае не будет соответствовать определению UC.

И вопрос, на который я ответа не получил:

И чем система проявляет себя в среде, как не интерфейсами (те же UC), если не вспоминать нефункциональные требования, например, цвет корпуса компьютера?

Спасибо.

А вообще-то, Юра, я сожалею, что завел эту бодягу.

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

И какая, суть, разница, декомпозиция это или детализация, является прецедент описанием функции, или нет.
Нам их "рисовать" правильно нужно!.

И это главное.

Спасибо за ответ, но он меня не удовлетворил.
1. Декомпозиция не всегда иерархия (элемент этой декомпозиции м.б элементом многоразового использования, т.е. элементом и другой декомпозиции).

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

2. Декомпозиция допускает, что элементы дочернего уровня представляют собой нечто иное, чем их агрегат (в нашем случае элемент декомпозиции UC вовсе не обязан быть UC).

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

3. UC (описание взаимодействий для достижения цели) декомпозируется в набор описаний отдельных действий по достижению этой цели.

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

4. UC - это описание функции (но не любой, а отвечающей некоторым требованиям, сформулировнным в определении термина UC).
5. UC не может выродится в функцию, не являющуюся UC, т.к. в этом случае не будет соответствовать определению UC.

Я предпочитаю это формулировать иначе - скорее это некоторые функции могут соответствовать юзкейсам, а не юзкейс - функцимя :-).

И вопрос, на который я ответа не получил:

Интерфейсами системы скорее будут функции, а не UC  в целом. Т.к. набор функций системы сущность менее зависимая от контекста использования системы, чем UC. Пример - текстовый редактор Word. При его множестве функций, для набора и распечатки текста "Hello world" мы не будем задействовать все его функции. А UC будет существовать - получить распечатку "Hello world". UC можно признать интерфейсом, только вводя понятие контекста использования - т.е. при определенном контексте использования это будет единственным интерфейсом.

А вообще-то, Юра, я сожалею, что завел эту бодягу.

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

И какая, суть, разница, декомпозиция это или детализация, является прецедент описанием функции, или нет.
Нам их "рисовать" правильно нужно!.

И это главное.

Ну почему ... подискутировать на "общефилософские" вопросы иногда очень интересно :-). А то сидишь в рутине конкретных проектов ... заказчику же это рассказывать не будешь :-).

Просьба не отождествлять функции системы и варианты использования, это разные вещи, с несколько разным назначением. Функции системы, это взгляд с точки зрения системы "на мир ее окружающий" :-), т.е. это в т.ч. то, что система экспонирует наружу. Юзкейс - это именованная цель пользователя по отношению к системе (бизнес- или технической). При этом функции легко декомпозируемы, юзкейсы - только в пределах отношений между уровнями описаний (т.е. не декомпозируемы). Очевидно, в процессе выполнения сценариев юзкейса будут использованы те или иные функции. Более того, на основании юзкейсов могут быть определены сами функции системы (подход сверху-вниз). Как в прочем и по набору функций можно придумать юзкейсы, но нужно иметь определенную фантазию :-) (подход снизу-вверх).

Так же очевидно, что для проектирования системы одних юзкейсов не достаточно, если под проектированием мы понимаем, как минимум blueprint.

По-прежнему продолжаете считать мой ответ, ответом Шерлока Холмса?

Ну, хорошо! Как хочешь.

Ты считаешь, что функции и UC разные вещи?

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

1. Можно говорить об отношении пользователя к использованию системы, но это еще не все.

2. Есть рекомендации именовать UC в терминах названия цели пользователя. Но даже эллипс с названием - это еще не цель. UC - это описание последовательности взаимодействий пользователя с системой для достижения цели. И в этом смысле UC ведет себя в точности как описание внешнего поведения функции.

3. Функция и UC, конечно, разное.
   - Функция в ПО - это некоторый выделенный фрагмент, который можно выполнить. Где-то в документации есть описание (назначение, указания на предусловия, правила запуска, результат и т.п.).
   - UC выполнить невозможно по определению: это описание (у Коберна - соглашение ...). Его сначала нужно реализовать: проанализировать, спроектировать, закодировать, интегрировать в систему. И с этой (я позволю себе дать условное название) реализацией UC поступают точно так же, как с функцией

4. Если отождествлять описание и реализацию (это разное, но допустим в этом контексте), то функция - это понятие более широкое, чем UC: любой UC - это функция, но не любая функция - это UC.

5. ООП предполагает, что все функциональные требования к системе выражаются с использованием UC. О каких других функциях системы ты говоришь? И как они выражаются, определяются?

Ну, хорошо! Как хочешь.

Ты считаешь, что функции и UC разные вещи?

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

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

1. Можно говорить об отношении пользователя к использованию системы, но это еще не все.

Речь идет о контексте использования?

2. Есть рекомендации именовать UC в терминах названия цели пользователя. Но даже эллипс с названием - это еще не цель. UC - это описание последовательности взаимодействий пользователя с системой для достижения цели. И в этом смысле UC ведет себя в точности как описание внешнего поведения функции.

Я бы сказал, что в данном случае скорее у системы может быть высокоуровневая функция, которая тождественна юзкейсу.

3. Функция и UC, конечно, разное.
   - Функция в ПО - это некоторый выделенный фрагмент, который можно выполнить. Где-то в документации есть описание (назначение, указания на предусловия, правила запуска, результат и т.п.).
   - UC выполнить невозможно по определению: это описание (у Коберна - соглашение ...). Его сначала нужно реализовать: проанализировать, спроектировать, закодировать, интегрировать в систему. И с этой (я позволю себе дать условное название) реализацией UC поступают точно так же, как с функцией

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

4. Если отождествлять описание и реализацию (это разное, но допустим в этом контексте), то функция - это понятие более широкое, чем UC: любой UC - это функция, но не любая функция - это UC.

Ну я бы все-таки не так категорично определял. Хотя-бы потому, что UC вполне может содержать ряд шагов (действий) пользователя, которые он не делает при помощи system under consideration, но они необходимы для достижения цели пользователя. UC при этом будет существовать, т.к. пользователь имеет определенную цель, но такой функции в системе может попросту не быть! Пример - целью пользователя является принятие решения о выдаче или не выдаче кредита физлицу. Ни одна банковская система не имеет такой функции (решение будет принимать ЧЕЛОВЕК)!!! Но UC такой вполне может существовать :-).

5. ООП предполагает, что все функциональные требования к системе выражаются с использованием UC. О каких других функциях системы ты говоришь? И как они выражаются, определяются?

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