Здравствуйте, глубокоуважаемые аналитики!

Вопрос такой. Как с вашей точки зрения, корректна ли слудующая диаграмма вариантов использования (картинка во вложении)

Если словами, то коррекно ли:
1. Выносить UseCase за границы системы? (вынося UseCase, я хочу показать, что существует некоторая функциональность, которая
       1.1 важна для пользователя в контексте (бизнес-контексте) использования системы
       1.2 является предусловием к началу использования системы
       1.3 может быть выполнена неявно в одном из юзкейсов системы (скрыто от пользователя), т.е. для неё нет пользовательского интерфейса в системе, но есть программный)
2. Использовать "внешний" UseCase в качестве расширяющего для системного юзкейса?

1. Поясните, пожалуйста, вот эту фразу:

"вынося UseCase, я хочу показать, что существует некоторая функциональность, которая ... является предусловием к началу использования системы".
Функциональность чего?

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

Нет, не корректно. Суть варианта использования описать взаимодействие. Взаимодействие двух агентов:
внешнего агента - устройство, которого нас не волнует, нам не известно. Однако для нас важан его цель использования. И агента-системы - т.е. субъекта нашего рассмотрения.

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

Варианту использования придаются свойства фнукции системы, но это не так. ВИ  - это требование.
Потому 1.2 - нет, 1.3 - нет (либо на уровне абстрактного варианта использования)

2 - непонятна терминология:
что есть внешний UC, что есть в (вашем понимании) системный?

"вынося UseCase, я хочу показать, что существует некоторая функциональность, которая ... является предусловием к началу использования системы".
Функциональность чего?

Моё приложение, это плагин к другому, более крупному, приложению. Часть функциональности реализовано в "материнской" системе (внешние, по отношению к моей системе UC). Так вот, некоторая функциональность - это UC Create Model

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

UC Create Model реализован в "материнской" системе и является как бы предусловием к использованию моей системы. Если модель не была создана в "материнской" системе, то срабатывает точка расширения в моём UC Create Project и модель в "мартеринской" системе создаётся вместе с проектом в моей (UC Create Model).

что есть внешний UC, что есть в (вашем понимании) системный?

Системный UC - тот, которые находится в границах системы (system boundaries), внешний - за её пределами.

Кстати, во вложении картинка с MSDN, а ниже текст, поясняющий UC Deliver Meal:
Use cases outside the system scope
It is frequently useful to include on the diagram use cases that are part of the business but not dealt with by the system that you are developing. This helps developers understand the context of their work. For example, Deliver Meal could be shown as a use case involving the actors Restaurant and Customer, but outside the responsibility of the Meal Ordering Web Site.

Я действовал по аналогии, единственное, позволил себе соединить внешний и внутренний UC отношением расширения.

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

Но с другой стороны нужно понимать, что ДВИ - это не вся модель ВИ, еще есть сценарии и там на много удобнее описывать вещи, которые лишние на ДВИ или нагружают ее.

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

Честно говоря, я такого подхода не встречал, but why not?

Саша, я не понял ни слова, что ты сказал. Кроме одного - почему нет.

Андрей, по правилам UML, то я скажу нет нельзя. И картинка с MSDN тоже не верна. Вариант использования всегда требует контекста. Либо он все равно подразумевается. На этой картинки видно, что Dinner Now System - это отдельная система услугами, которой пользуются ресторан (чтобы предоставить меню и получить заказы на еду) и клиент (чтобы просмотреть меню и сделать заказ). При этом из данной диаграммы можно сделать вывод, что либо ресторан доставкой не занимается, либо занимается как-то по-другому, как тогда? Если доставка автоматически включается в заказ, то зачем вообще нужен этот ВИ, это определяется описанием "сделать заказ" или другими требованиями.

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

Формально, скорее всего Вы правы, но мне кажется, что UC Deliver Meal может помочь в лучшем понимании границ проекта. Сразу становится понятно, что доставка в принципе есть и что она реализуется в другой системе (точно не в нашей). Можно предположить, что эта дополнительная информация может быть полезна для снятия возможной неопределённости в каких-то других местах...

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

Формально, скорее всего Вы правы, но мне кажется, что UC Deliver Meal может помочь в лучшем понимании границ проекта.

Спорить тут бессмысленно. Ибо одна точка зрения против другой. Она действительно не подкреплена физическим законом Игры чистого разума. Для меня овальчик - это только ярлык, смысл которого все равно заложен в его описании. Ровно того же эффекта вы могли бы достичь просто оставив комментарий (доставку ресторан не осуществляет).

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

не - это описка? или оговорка по Фрейду. Или это осознанное написание?

Конечно опечатка! По Фрейду или нет - надеюсь нет Вообще я большой мастер художественной опечатки а Вы Эдуард Геннадьевич зоркий глаз!

UC Create Model реализован в "материнской" системе и является как бы предусловием к использованию моей системы. Если модель не была создана в "материнской" системе, то срабатывает точка расширения в моём UC Create Project и модель в "мартеринской" системе создаётся вместе с проектом в моей (UC Create Model).

1. Мне кажется, в таком случае нельзя считать Create Model предусловием Create Project. Предусловие - это в некотором роде булевское выражение, которое вычисляется для определения доступности "кнопки", нажав на которую пользователь вызывает выполение кейза. У вас получается, что "кнопка" (условно) Create Project неактивна ("серая"), если до этого не были выполнены действия из Create Model. А вам нужно, чтобы она всегда была активна ("черная"), но если при ее нажатии Create Model еще не выполнялось, то чтобы оно было выполенено.

2. Соглашусь с bas, что отсутствие указания границ "материнской системы" делает более трудным понимание этой диаграммы и вызывает лишние вопросы.

1. Мне кажется, в таком случае нельзя считать Create Model предусловием Create Project. Предусловие - это в некотором роде булевское выражение, которое вычисляется для определения доступности "кнопки", нажав на которую пользователь вызывает выполение кейза. У вас получается, что "кнопка" (условно) Create Project неактивна ("серая"), если до этого не были выполнены действия из Create Model. А вам нужно, чтобы она всегда была активна ("черная"), но если при ее нажатии Create Model еще не выполнялось, то чтобы оно было выполенено.

Согласен, UC Create Model не может называться предусловием для UC Create Project в формальном понимании этого термина, потому что UC Create Model (возможно) выполняется уже после начала UC Create Project, а значит предусловием не является.
У меня встречный вопрос. Если взять, Вашу аналогию с кнопками, то верна ли для неё диаграмма (отношение расширения между UC Create Model и UC Create Project)?

2. Соглашусь с bas, что отсутствие указания границ "материнской системы" делает более трудным понимание этой диаграммы и вызывает лишние вопросы.

В ответ позволю себе процитировать себя же

Кстати, во вложении картинка с MSDN, а ниже текст, поясняющий UC Deliver Meal:
Use cases outside the system scope
It is frequently useful to include on the diagram use cases that are part of the business but not dealt with by the system that you are developing. This helps developers understand the context of their work. For example, Deliver Meal could be shown as a use case involving the actors Restaurant and Customer, but outside the responsibility of the Meal Ordering Web Site.

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

P.S.

Кстати, хочу запостить этот топик на англоязычном форуме. Интересно будет посмотреть, что скажут "на западе"...

Думаете так (картинка во вложении) будет понятнее/формально правильнее?

Если Вы еще опишите где-то (не обязательно на Д), что такое VISSIM и v.1, то безусловно - да. Я бы еще нарисовал границы самой Системы, чтобы получить совсем цельную картинку.

Кстати, хочу запостить этот топик на англоязычном форуме. Интересно будет посмотреть, что скажут "на западе"...

ТОлько результатами или ссылкой на пост не забудьте поделиться )

У меня встречный вопрос. Если взять, Вашу аналогию с кнопками, то верна ли для неё диаграмма (отношение расширения между UC Create Model и UC Create Project)?

Расширение ИМХО - это когда нажав кнопку основного действия, вы затем можете нажать кнопку расширяющего действия. А можете и не нажать.

Думаете так (картинка во вложении) будет понятнее/формально правильнее?

Лично мне так понятнее.

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

Я тут статью одну прочитал и у меня появился ещё один вариант как показать тот факт, что в некотором случае, моя система обратится к другой систме "за помощью". Т.е., в моём случае, если пользователь активизирует UC Create Project и сработает точка расширния Create Model, то моя система обратиться к другой системе VISSIM для создания этой самой модели. При этом, линии соединяющие User с прецедентами моей системы - это GUI, а линия к VISSIM это COM Interface.
Мне этот вариянт нравится больше других. И с комментарием Виктора очень удачно совпало:

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