какое-то нагромождение понятий.
Вроде как UC = описание взаимодействия с системой, грубо говоря описание последовательности нажатий кнопок. Если между нажатиями пользователь должен выполнять какие-нибудь строго (или не очень строго) предписанные действия, описываемые в UC, то значит система их (эти действия) охватывает, т.е. возникает коллизия между определением и содержанием границы системы.

UC при этом не принадлежит системе и не является ее свойством. Он ее всего лишь описывает в ракурсе "как с нею взаимодействовать пользователю". в этом описании "упоминаются" используемые пользователем функции (вот они - свойства системы) для достижения его цели.

Может быть, я пишу сложно. Но так UML устроен.

UML рассматривает любой объект с двух точек зрения: снаружи (что объект делает) и изнутри (как он это делает взаимодействием своих внутренних объектов).

Дихотомия "UC - UCRealization" - это как раз такой случай. Это один элемент, который представляет две точки зрения: аналитика и проектировщика (кодера).

В системе не может быть UC, если нет UCRealization. Ну, а UCRealization не может существовать без UC хотя бы потому, что UC - это описание функциональности UCRealization.

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

Если кто из аналитиков не помнит, UCRealization на диаграммах представляется эллипсом с пунктирным контуром и должна иметь одинаковое с UC название. Это стандартный стереотип UML модельного элемента Collaboration.

Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.

Можно на русском?

UC 1: Забивание гвоздя
Краткое описание: Дядька берет молоток за ручку правой рукой и, предварительно замахнувшись, ударяет плоской ударной поверхностью по шляпке гвоздя, предварительно приставленного к нужному месту.

Primary actor: Дядька

Actor: Гвоздь

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

не обязательно правой, а в остальном, прекрасная маркиза....

опять же можно ввести родительский UC "ударение молотком", а от него произвести дочерние "ударение молотком по пальцам", "забивание молотком гвоздя", "забивание молотком самореза", "забивание молотком насмерть" :о)))

Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.

насколько хорошем? :о)) прошу указать критерии хорошести. а то, понимаешь, english speaking people are very very different <произносится с индийским акцентом> (for example http://www.youtube.com/watch?v=dABo_DCIdpM :о)))

не обязательно правой, а в остальном, прекрасная маркиза....

При внимательном рассмотрении я обнаружил ряд недостатков.

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

Проектировщик создаст кооперацию реализации UC и начнет рисовать диаграмму последовательности. В процессе рисования и определятся соответствующие объекты: экземпляры ручки и "ударника" с его плоской поверхностью.

На основе модели реализации будет уточнено и детализировано описание UC (не обязательно, но полезно, т.к. описание UC - это плацдарм для написания руководства пользователя и тест-кейса).

Я работаю в RSA и наделал множество шаблонов SoDA на разные случаи жизни. Спецификацию UC, Руководство пользователя и TestCase я генерю из одной и той же модели UC.

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

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

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

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

Ограничения нужно устанавливать осторожно.
В начале 90-x на Калининской АЭС было требование на поставку любого ПО: язык PowerBuilder. Обоснование: 100% работников IT прошло соответствующее обучение и за деньги Еврокомиссии было закуплено соответствующее программное обеспечение. Редкий случай, когда требование использования платформы было обосновано.

Так что, м.б. и шарообразная поверхность. Исполнитель несет ответственность, чтобы гвозди можно было забивать (сапожные или в доску: гвозди и молотки разные).

Друзья, я про молоток вот почему приплел. Может это, конечно, бред, но -
 все что вы тут про молоток рассказали - все это ВАРИАНТЫ ЯГО ИСПОЛЬЗОВАНИЯ (кстати и кувалда сюда жа)

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

Но ... ясно и, наверное, очевидно, что просто знания функции маловато, тут аспекты использования тоже важны, так как в конечном итоге определят и эргономику, и эстетику, и практичность

А кто говорит, что одних только функциональных требований достаточно.
Классификация требований FURS+. Но "F" здесь то, ради чего, собственно, делается система (молоток).

Простите, но Actor взаимодействует с системой через UC.

Да, но юзкейс, как мы знаем - это последовательность действий типа Пользователь <сделал что-то> ... Система сделала <что-то>. Скорее к функциям системы (или если угодно, к подфункциям, но это тоже функции ...) можно отнести то, что описывается в сценарии как "Система сделала <что-то>", а не действия пользователя ...

Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).

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

И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?

Вы неверно интерпретируете сказанное мной. Утверждение, что UC это интерфейс СИСТЕМЫ - это ваше утверждение, а не мое. У меня простой вопрос - шаги юзкейса, которые делает Эктор (например, принимает решение дать кредит или нет) - это функция системы или нет?

Загибаешь!

Отнюдь!

UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?
А какой пример функции, который не является реализацией UC?

Не согласен, что юзкейс не содержит действий пользователя ... совершенно. Еще как содержит!

Кстати вы так и не ответили на вопрос про количество юзкейсов, которые в среднем вы выделяете в системе ... сколько их?

А кто говорит, что одних только функциональных требований достаточно.
Классификация требований FURS+. Но "F" здесь то, ради чего, собственно, делается система (молоток).

Функциональные требовании = функции системы? (Эд говорит о функциях, а не о требованиях к ним ...)

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

А по количеству как скажешь? Где то много, где мало. Ну, в системе управления ремонтом для АЭС Tihange где-то, наверное, до 50 (основных) доходило (список на две с половиной страницы елочкой, почти три года проект был).
 
И детализация разная. От краткого описания до storyboard (с диаграммами граничных классов), в зависимости от сложности.

У меня за много лет уже стандартные приемы наработаны, т.ч. это не трудно - модель сделать. Труднее информацию нужную собрать (особенно, когда с языком напряженка).

Сегодня, обсудили со студентами данную задачу (ну тут которую я ставил в начале).

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

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

Предложил - кто по нашей модели может реализовать то, что мы тут напридумывали.

Один парнишка меньше чем за 40 минут сделал это

Классно!

А чем программки отличаются?