Здравствуйте!

Разрабатываю USE CASE диаграмму для учебного проекта. Есть сомнения в ее правильности, в связи с этим два вопроса:
1. Легально ли делать связь "include" к прецеденту, который уже является "инклудом" для другого прецедента? (см. рисунок).
2. Можно ли связывать актора, допустим, с одним прецедентом "include", при этом не связывая с основным? (Красная стрелка)

Спасибо!

Осознала, что стрелки не в ту сторону. Но вопрос открытый..

Это должно умереть. Это не диаграмма вариантов использования.

В лучшем случае - это можно назвать диаграммой иерархии функций.

Это должно умереть. Это не диаграмма вариантов использования.

В лучшем случае - это можно назвать диаграммой иерархии функций.

Да, хорошо, этот вариант умирает.
Но если убрать лишний промежуточный "прецедент", то  есть ли у этого шанс на жизнь?

Да, хорошо, этот вариант умирает.
Но если убрать лишний промежуточный "прецедент", то  есть ли у этого шанс на жизнь?

А что изменилось?

Вы разрабатываете систему предназначенную для управления отоплением, вся система это делает. В чем смысл делать инклюды?
Начните с того, что
1. уберите управление отоплением к чертям
2. нарисуйте оставшееся без инклюдов, посмотрим дальше

Разрабатываю USE CASE диаграмму для учебного проекта. Есть сомнения в ее правильности, в связи с этим два вопроса:

Без текстовых описаний ВИ и условий Вашего учебного проекта затруднительно оценить правильность в плане содержания. Остаётся оценивать соблюдение правил стандарта UML.

1. Легально ли делать связь "include" к прецеденту, который уже является "инклудом" для другого прецедента?

Да.

2. Можно ли связывать актора, допустим, с одним прецедентом "include", при этом не связывая с основным?

Можно. Если направлением связи Вы показываете является ли действующее лицо основным, то стрелки идут обычно от включаемых ВИ ко второстепенным ДЛ. Иначе может оказаться, что у включаемого ВИ два основных ДЛ: 1) непосредственно связанной с ним + 2) основное ДЛ включающего ВИ.

Содержательная "правильность" инклудов вытекает из описаний сценариев ВИ. Но Вы их не приводите (у Вас их нет). Значит учебное упражнение в этой части бессмысленно. 

1. Легально ли делать связь "include" к прецеденту, который уже является "инклудом" для другого прецедента? (см. рисунок).

Да.

Можете ли привести внятный пример, подтверждающий обоснованность этого утверждения?

Пример нарисовали Рамбо и Блаха в своей книге:

Ещё раз обращаю внимание, ответ дан в смысле соблюдения/нарушения стандарта UML.
Можно вместо стандарта рассматривать правила каких-либо методик, стилей рисования диаграмм и проч. Можно восклицать: "Что в голове у автора диаграммы!" -- как это кое-где кое у кого принято. Можно всё.
P. S. Авторы стандарта придумали операцию allIncludedUseCases(), которая собирает все включённые (непосредственно или косвенно) UC для заданного UC. Если бы косвенное включение не допускалось бы стандартом, то учитывать бы его не стали и OCL-body для операции было бы проще.

Пример нарисовали Рамбо и Блаха в своей книге:

А что-нибудь кроме этого?

Вот наверное правильная не противоречащая стандарту диаграмма

А что-нибудь кроме этого?

Пример с сайта Kirill'a Fakhroutdinov'a:


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

Пример с сайта Kirill'a Fakhroutdinov'a:


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

ОК пример прекрасен, но что он дает, чего не даст например простое описание, к чему такая сложная структуризация? В чем ее сила, в какой момент она возникает. Каковы правила такой структуризации?

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

Отбросив воду:
Каковы правила структуризации диаграммы вариантов использования? Могли бы Вы их представить?

Диаграмма является продолжением примера, в котором в начале приводится (составляется) диаграмма т. н. "top level UC", а затем вводятся UC уровня пониже. Пример иллюстрирует примитивы языка. Он сродни учебным текстам из учебника английского языка.
Можно в N-ный раз зайти на круг разговоров о том, что язык не является технологией, что на практике отдельные средства языка могут оказаться уместны или не уместны.
В правилах языка может что-то нравиться, что-то не нравиться. Мне, например, не нравится многое накрученное понапрасну вокруг include'ов. Как иллюстрация ещё одна страничка с того же сайта. Увязывание abstract с incomplete, concrete с complete видится мне лишним. Как и заклинание о якобы безусловном включении.

Диаграмма является продолжением примера, в котором в начале приводится (составляется) диаграмма т. н. "top level UC", а затем вводятся UC уровня пониже. Пример иллюстрирует примитивы языка. Он сродни учебным текстам из учебника английского языка.
Можно в N-ный раз зайти на круг разговоров о том, что язык не является технологией, что на практике отдельные средства языка могут оказаться уместны или не уместны.
В правилах языка может что-то нравиться, что-то не нравиться. Мне, например, не нравится многое накрученное понапрасну вокруг include'ов. Как иллюстрация ещё одна страничка с того же сайта. Увязывание abstract с incomplete, concrete с complete видится мне лишним. Как и заклинание о якобы безусловном включении.

Да, примеры выглядят интересно. Смотрю раздел use case значительно обновился. Спасибо за просвещение.