Спасибо за ответы:) Не думала что они платные;)

Это так, стимул к самостоятельности. Все-таки сначала надо изучать справку и опцион

Ещё вопрос: каким образом правильнее отображать на диаграмме владельцев (создателей) каких-либо компонентов?
Конкретнее: автора отдельного компонента -программного модуля.
Можно ли отобразить другим способом, чем в виде Note ?
Примечание: фамилию создателя компонента необходимо видеть на диаграмме в "чистом" виде, не заходя в свойства компонента.

Т.е. вы хотите на диаграмме видеть значение поля Author компонента? хм, я такого функционала для визуализации не нашла. Кроме Notes можно тегом. Но в таком случае будут видны все теги, а не только этот

Спасибо!

Т.е. этот рецепт подошел? На здоровье!

Подошёл)
Ещё вопрос: в свойствах диаграммы есть флажок: Show details on diagram.
Если его установить, то видны следующие данные:
Название диаграммы
Автор
Версия
Название пакета

В деталях присутствуют ещё поля:
дата создания
дата изменений.

Не получается их сделать видимыми...Подскажите, возможно ли это?

По-моему нет. А для чего? Мне кажется, это только замусорит всю диаграмму.

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

Для чего удобно видеть эти даты? Какова цель создания диаграммы? Обычно диаграмма создается для визуального отображения элементов и связей между ними, а информация о том, когда она делалась, обычно важна далеко не всем. Даты прекрасно хранит и показывает подключенная система контроля версий.

Для чего удобно видеть эти даты? Какова цель создания диаграммы?
Обычно диаграмма создается для визуального отображения элементов и связей между ними,

Irr, не совсем так.
Есть много любителей, в роде меня, работать с диаграммами в бумажном варианте.
Я нахожу в этом особую прелесть:
держать в реале картинку и разрисовывать её маркером и карандашом :-)
Так вот, в процессе работы таких бумажек собирается много, каждая из них хранит безценные зацепки для вытягивания из недр памяти "гениальных мыслей" или важных аспектов.
Как правило, эти зацепки - в виде мазков маркером и карандашных каракулей-приписок, родившихся в транспорте или на митинге с Заказчиком.
А когда такие бумаги начинаешь пересматривать - вот тут и жалеешь, что не видна версия диаграммы и дата её распечатки.

а информация о том, когда она делалась, обычно важна далеко не всем.
Даты прекрасно хранит и показывает подключенная система контроля версий.

ох уж эта мне больная тема с контролем версий в ЭА :-)

тут мысль родилась:
вообще все элементы, которые выносятся из системы версионного контроля надо бы снабжать "бирками", какой они версии.

Вот, теперь понимаю, для чего это надо :-) Так бы сразу и сказали :-)
Если печатать диаграмму через правый клик documentation\rtf report, и предварительно настроить шаблон отчета, то будет вам и белка, будет и свисток. Там есть возможность настройки вывода для диаграммы этих и не только этих полей.
А вот как на экран вывести, пока не знаю.

Проблема:
Для создании структуры требований используется RaQuest. После формирования части или всего списка требований - список иерахический, данные по требованиям переносятся в EA, где возникает собственная - но аналогичная структура требований (см. рисунки). При построении моделей требований - т.е. формирования связей трассировки и визуализации отношений между требованиями и в будущем с элементами аналитической, проектной и т.п. моделями - может произойти нарушение первоначальной структуры вложеннности требований.
Ниже проблема проиллюстрирована:
Собственно созданная структура в RaQuest и ее образ в EA после переноса в EA (все это осуществляется прозрачно для пользователя)


Далее, формируем некоторую диаграмму и перетаскиваем нужные требования мышкой из дерева требований на диаграмму. Рисуем связи и трассировки.


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


Происходит ли это в результате формирования связи?

Решение проблемы:
В ответ на запрос служба поддержки EA написала следующее:

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

Это поведение может быть изменено или использованием [alt] при перемещении объект на  (по) диаграмму(е), или отключением опции "Auto Group Elements" в "Tools | Options | Diagram | Behaviour".
Более подробно смотри http://www.sparxsystems.com/EAUserGuide/diagrambehavoir.htm

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

Если в любое время Вам потребуется изменить вложение любых элементов на диаграмме, Вы можете удерживать [alt] во время перемещения объекта, что обеспечивает изменения поведения объектов на диаграмме на противиположный тип, установленному в  "Tools | Options | Diagram | Behaviour" (в данном случае приводит к включению опции автогруппировки).

Проблема:
Для создании структуры требований используется RaQuest. После формирования части или всего списка требований - список иерахический, данные по требованиям переносятся в EA, где возникает собственная - но аналогичная структура требований (см. рисунки).

маленькое уточнение: данные по требованиям - одни и те же, хранятся в одних и тех же таблицах, только есть возможность с ними работать, как из RaQuest, так и через EA.
в моём случае окзывается удобным вначале создавать требования в RaQuest, а потом открывать EA и уже там дальше с ними работать.

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

Начинаю работатать с  Enterprise Architect, делаю кучу ошибок. Возникают задачи типа этой - надо в паре сотне классов поменять стереотип. Как это сделать быстро? Такая же задача для стрелок связей. Нужен нормальный механизм массовых изменений. Пока нашел примитивный вариант - импорт/экспорт csv, в промежутке правлю поля csv файла, но такой механизм срабатывает не во всех случаях. Похожий вариант - импорта/экспорт  хмл файла, не устраивает так как очень неудобно править такой файл. Какие еще есть варианты?