Чтобы внести свежую струю в обсуждение, добавлю, что в рамках гибкого моделирования (Agile Modeling) дозволяется использовать пакеты на ДВИ:

См. http://www.agilemodeling.com/style/packageDiagram.htm#UseCasePackageDiagrams. Оно и понятно, "гибким ребятам" стандарты не указ.
Пакет вариантов использования (ПВИ) является одним из артефактов RUP. При его изучении мне доводилось встречать ПВИ на диаграммах вариантов использования для бизнес-моделирования и работы с требованиями.
Указанная диаграмма из суперструктуры позволяет объединять варианты использования в ПВИ, насколько я могу разобраться.

...Это кстати на заметку Виталию Григорашу, кот показывал патерн ВИ "Пакеты", где было отношение зависимости м\у ДЛ и Пакетами.

Хочу немного своего мнения внести.
Во-первых. Нужно определится в чем цель моделирования вариантов использования? Если цель в строгом соблюдении UML, то использование dependency между актором и пакетом нельзя, тк актор может быть связан только с ВИ, компонентами, классами и др акторами. В таком случае нужно использовать компоненты, точно также как пакеты, но на практике это не всегда удобно.
Я же, когда использую пакеты, пытаюсь достичь двух целей:1. Структурирование модели. 2. Понятность модели для команды разработки и заказчика.

Во-вторых. Я не первый кто это использует. Связь акторов с пакетами я подсмотрел в книге Podeswa "UML for the IT Business Analyst" (стр. 94-98)  и просто оформил это как паттерн, потому что мне так удобно работать. Тот же Овергаард использует подобную связь в паттерне Lecacy System.

В-третьих. Современные CASE позволяют устанавливать такие связи, следовательно, про них можно сказать что они 100% не соблюдают правила UML.

ЗЫ Связь зависимости между акторами и пакетом показывает, что актор инициирует ВИ (участвует в ВИ), которые принадлежат пакету

Пакет вариантов использования (ПВИ) является одним из артефактов RUP. При его изучении мне доводилось встречать ПВИ на диаграммах вариантов использования для бизнес-моделирования и работы с требованиями.

С ПВИ я согласен - это пакет со стереотипом <<use case>>, это никто не запрещает делать. Но что ПВИ - это артефакт РУП, я слышу впервые, можно ссылочку.

Указанная диаграмма из суперструктуры позволяет объединять варианты использования в ПВИ, насколько я могу разобраться.

Вот тут я Вас не понял. Какая Д из какой суперструктуры?

Хочу немного своего мнения внести.
Во-первых. Нужно определится в чем цель моделирования вариантов использования? Если цель в строгом соблюдении UML, то использование dependency между актором и пакетом нельзя, тк актор может быть связан только с ВИ, компонентами, классами и др акторами. В таком случае нужно использовать компоненты, точно также как пакеты, но на практике это не всегда удобно.

Энто как ты будешь использовать Компоненты также?

Я же, когда использую пакеты, пытаюсь достичь двух целей:1. Структурирование модели. 2. Понятность модели для команды разработки и заказчика.

Во-вторых. Я не первый кто это использует. Связь акторов с пакетами я подсмотрел в книге Podeswa "UML for the IT Business Analyst" (стр. 94-98)  и просто оформил это как паттерн, потому что мне так удобно работать. Тот же Овергаард использует подобную связь в паттерне Lecacy System.

В-третьих. Современные CASE позволяют устанавливать такие связи, следовательно, про них можно сказать что они 100% не соблюдают правила UML.

ЗЫ Связь зависимости между акторами и пакетом показывает, что актор инициирует ВИ (участвует в ВИ), которые принадлежат пакету

1. Я не против такого использования, но просто как правило ДЛ не участвует во всех ВИ данного пакета, а, во-вторых, ДВИ с Пакетами и ДЛ может получиться нечитаемой, т.к. одно или несколько ДЛ будет связано со всеми Пакетами, и поэтому данный вид Д нужно использовать осторожно (не все еще ДВИ одолели то).
2. Поверим Но я нигде не видел использования такой техники до этой дискуссии.
3. Так ЕА позволяет делать все что угодно Это ни о чем не говорит
З.Ы. Это твое ИМХО, хотя логичное. М.б. написать в ОМГ на счет включения Пакетов на ДВИ или спросить причину того что они этого не сделали?

Но что ПВИ - это артефакт РУП, я слышу впервые, можно ссылочку.

Дальше РУПа послать не могу, ближе тоже.

Вот тут я Вас не понял. Какая Д из какой суперструктуры?

Ту, что Вы приводили. ВИ может входить в классификатор, а пакет -- это классификатор, как мне кажется.

Дальше РУПа послать не могу, ближе тоже.

Действительно, в РУП написано, что ПВИ - это часть ДВИ. Но про ПВИ сказано, что он служит только для группировки ВИ или ДЛ, но не сказано про то, что ДЛ могут быть связаны с ПВИ зависимостью:
http://rup.hops-fp6.org/process/artifact/ar_ucmod.htm
http://rup.hops-fp6.org/process/artifact/ar_ucpkg.htm
И тогда не понятно чем ДВИ с Пакетами будет отличаться от Д Пакетов?

.. а пакет -- это классификатор, как мне кажется.

А по-моему пакет не относится к классификаторам. Хотя могу ошибаться

Энто как ты будешь использовать Компоненты также?

При моделировании ВИ в IBM Rational Software Architect граница системы представляет собой компонент со стереотипом <<subsystem>>, а не просто картинка в виде рамочки. Такой подход позволяет помещать ВИ внутрь действительной системы. Декомпозируя систему на подсистемы (компоненты), мы тем самым группируем ВИ по подсистемам. См. рисунок1 в аттаче. Так как по правилам UML актор может быть связан с компонентом, то мы можем на верхнем уровне абстракции показать эту связь, скрыв внутреннее содержание компонента. Связи акторов с компонентами, на этапе проектирования перерастут в интерфейсы.
Данные компоненты не являются "design", а представляют собой аналитический взгляд на состав системы. Хотя системный аналитик - это PIM архитектор, то вполне может быть, что компоненты будут design

1. Я не против такого использования, но просто как правило ДЛ не участвует во всех ВИ данного пакета, а, во-вторых, ДВИ с Пакетами и ДЛ может получиться нечитаемой, т.к. одно или несколько ДЛ будет связано со всеми Пакетами, и поэтому данный вид Д нужно использовать осторожно (не все еще ДВИ одолели то).

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

2. Поверим Но я нигде не видел использования такой техники до этой дискуссии.

Доверяй, но проверяй  . См. рисунок 2 в аттаче

3. Так ЕА позволяет делать все что угодно Это ни о чем не говорит
З.Ы. Это твое ИМХО, хотя логичное. М.б. написать в ОМГ на счет включения Пакетов на ДВИ или спросить причину того что они этого не сделали?

Да, это ИМХО., и я его никому не навязываю и не утверждаю что это правильно  . А в ОМГ написать можно. Займешься? 

А по-моему пакет не относится к классификаторам. Хотя могу ошибаться

Не можете.
Не хай будет подсистема. Это я застрял между 1ым и 2ым UML.

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

В общем пишу в ОМГ