Всем доброго дня. Прохожу обучение на БА. Выполняю практику и возник вопрос, надеюсь на помощь. Заранее прошу прощения, если некоторые вещи описал слегка сумбурно, еще не до конца в теме.

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

Получается, что в Use Case диаграмме КП будет по отношение к СУ вторичным актером. Но юз кейс "Импорт задач" по идее из ниоткуда порождаться не может. Правильно ли я понимаю, что в данном случае это и вовсе не будет юз кейсом?

Прикладываю скрин для лучшего понимания.

Когда ВИ описывает взаимодействие системы со второстепенным ДЛ, стартующее по триггеру (событию времени), тогда на диаграмме заводят фиктивное действующее лицо Время, инициирующее взаимодействие. Например, так рекомендует поступать Скотт Амблер.

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

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

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

Вы согласны, коллега НЛО?

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

Вы согласны, коллега НЛО?

Если бы условия не было, то да, как вариант. Но условие в том, что система автоматически импортирует проекты и задачи, как только они появляются в КП.

С этим можно согласиться в том плане, что включаемые ВИ и расширяющие ВИ разрешено не соединять ассоциациями с ДЛ, связанными с включающим или расширяемым ВИ.   
Правомерность инклюдов / экстендов мне кажется разумным проверять по описаниям ВИ. Если от сценария "Создать отчёт" можно проложить дорожку к "Импортировать задачи", то так тому и быть.
Абстрактный ВИ описывает некую общую схему, которая сама по себе не реализуется (её экземпляр не может быть порождён), а лишь используется для удобства описания других ВИ -- своих наследников. В стандарте не проведена граница между абстрактным/конкретным ВИ и полностью описанным (=полным)/ не полностью описанным (=неполным) ВИ. Это ведёт к недопониманию вроде такого.
ВИ с включениями по стандарту неполный, т. к. его описание содержит ссылки на включаемые ВИ. Но он может быть конкретным или абстрактным. Включаемый ВИ по стандарту полный, так как его описание не ссылается на включающие его ВИ (допустим, что других связей нет). Он также может быть конкретным или абстрактным.
ВИ с расширением по стандарту полный, т. к. его описание  не зависит от описаний расширяющих ВИ. Он может быть конкретным или абстрактным. Расширяющий ВИ неполный, т. к. в его описании обязательны ссылки на точки расширения, т. е. на другие описания. Он может быть конкретным или абстрактным.
Представляется, что у абстрактного включаемого ВИ и у абстрактного расширяющего ВИ должны быть конкретные наследники, возможно, не прямые.
Стандарт проводит параллель между включением ВИ и композицией. Напрасно, на мой взгляд. Инклюды и экстенды не зря рисуются как пунктирные стрелки, намекая на зависимость описаний. Ассоциации (композиции) между ВИ стандарт не запрещает (если это ВИ из разных сабжектов), но и не описывает, каков их смысл.