Доброго времени суток!
Недавно начала изучать ЕА (а еще немногим раньше UML). Как обычно - в начале  - много вопросов. На этом форуме посоветовали завести отдельную ветку на проверку корректности UML-диаграмм. которые я создам в рамках выбранного проекта (структура диаграмм обсуждается в другой ветке). Исходя из того. что мои собственные диаграммы пока не сложные и некоторых компонентов я пока (как выяснилось) не знаю, у меня  возникло такое предложение: сделать что-то вроде "путеводителя" по примеру, который поставляется вместе с ЕА. руководство новичка, который начинает разбирать этот самый пример. Получится должно что-то вроде:
"Открываем проект. На странице (диаграмме) Welcome перечислены основные разделы проекта.
Название каждого раздела - это "гиперссылка", по которой можно пройти в сам раздел...(каким образом можно настроить данную ссылку?)..."
В итоге можно сделать "методичку" по приемам создания проекта в ЕА и выложить ее вместе с примером на сайте. В качестве "брошюриста" могу выступить я, только тогда мне понадибится помощь участников форума. Если такая инициатива найдет отклик - предлагаю попробовать.

ИМХО хорошая идея. Задавайте вопросы - ответим.

Ок. начинаю.
Вопросы буду формировать в общем и пояснять на конкретном примере.
По ходу буду комментировать - куда двигаюсь по проекту-примеру (эт для того, чтобы если я нарушу логику алгоритма - меня смогли вовремя выловить и направить на путь истинный), также будут общие вопросы. которые актуальны для проекта в общем. При сборке - посмотрю - куда лучше определить ответы на них.
Также по мере готовности буду выкладывать версии брошюры.
Есть ли предложения по регламенту задавания вопросов?

Собственно вопросы:
1. как связать элемент А на диаграмме 1 с диаграммой2? (В примере есть страница Welcome. С нее с помощью клика мышки можно переместиться на другие диаграммы.Из контекстной справки видно, что достигается это с помощью гиперссылки. Если это так, то каким образом можно задать эту гиперссылку?)
2.как "красиво" разместить элементы диаграммы? (команда конт.меню Appearance->Default не спасает Может есть «тайная» кнопка быстрой организации?)

1. как связать элемент А на диаграмме 1 с диаграммой2? (В примере есть страница Welcome. С нее с помощью клика мышки можно переместиться на другие диаграммы.Из контекстной справки видно, что достигается это с помощью гиперссылки. Если это так, то каким образом можно задать эту гиперссылку?)

ссылки на диаграммы
выберете требуемую диаграмму в браузере проекта и отбуксируйте ее с помощью мыши на активную страницу.
Появится окно вида
Diagram Frame – создается окно с вложенной в нее диаграммой
Diagram Reference – аналогичен Frame, но без демонстрации подробностей диаграммы
Hyperlink – создается ссылка на диаграмму, вид ссылки зависит от типа диаграммы на которой Вы размещаете ссылку.

ссылки на пакеты
пакеты переносятся как иконки с указанием вложенных в него других элементов

ссылки на внешние ресурсы
используется иконка New Hypelink. В появившемся диалоге в поле адрес гиперссылки либо вводим url ресурса, либо используем стандартное окно Windows для поиска нужного файла
Тут же можно сделать ссылку на некоторые внутренние ресурсы. Для этого используется предопределенная переменная и алиас ресурса в проекте ЕА. ($matrix//алиас ресурса, $help//алиас ресурса, $forum//алиас ресурса, $inet//url ресурса)

Впрочем все есть в хелпе

2.как "красиво" разместить элементы диаграммы? (команда конт.меню Appearance->Default не спасает Может есть «тайная» кнопка быстрой организации?)

Это просто отображение элемента - по умолчанию или какую картинку на место элемента прикрутите, или еще что сделаете.
Красивость достигается также как во многих графических редакторах с помощью кнопок Align. Т.е. выделяем диаграмму или нужные объекты и align их

А как в ЕА загрузить диаграмы из .xml файла?

Заранее спасибо.

А как в ЕА загрузить диаграммы из .xml файла?

А там точно диаграммы? Может быть, там пакет?
StUtk, если Вы хотите загрузить xml, который выгрузила Helga, то для этого надо в ЕА создать новый пакет, на пакете нажать правую кнопку мыши, выбрать import/export - import package from XMI file, выбрать файл, нажать ОК.
Если это диаграммы, то там все сложнее, пришлите мне в личку xml-ку, я на ней поиграюсь и отвечу позже.

StUtk, если Вы хотите загрузить xml, который выгрузила Helga, то для этого надо в ЕА создать новый пакет, на пакете нажать правую кнопку мыши, выбрать import/export - import package from XMI file, выбрать файл, нажать ОК.

Именно это я и хотел, спасибо.

Доброго вечера всем!
Спасибо за комментарии...кстати, вопрос импорта/экспорта я тоже включу в описание примера.
Есть очередной вопрос: в примере одна из основных моделей - Business Domain Model (в свою очередь нескольких моделей, одна из которых Domain Model). В описании примера поясняется, что DM - это описание словаря проекта. В качестве основного элемента модели используется класс. В связи с этим вопрос:
DM  - это аналог модели классов или какой-либо другой вид диаграммы 
и BDM - то своего рода просто "контейнер" для однотипных диаграмм?
Спасибо!

В связи с этим вопрос:
DM  - это аналог модели классов или какой-либо другой вид диаграммы 
и BDM - то своего рода просто "контейнер" для однотипных диаграмм?

Business Domain Model - это бизнес контекст рассматриваемой задачи, ее рамки и окружение. Модель включает в себя описание внешних и внутренних связей, объектов предметной области и процессов. Обычно содержит описание организационной структуры, характеристик ролей, высокоуровневые требования, потребности заинтересованных лиц.

Domain Model - концептаальная модель классов, модель бизнес объектов - действительно отражает словарь предметной области,т.е. понятия предметной области и их отношения, или реальные объекты и устойчивые связи между ними.
Такая модель предусматривает описание классов без операций, ассоциации или отношения не уточняются, кратность не уточняется, дается имя отношения. Точность такой модели обычно не высока, она и не требуется. Главное, чтобы она отражала реальные предметы и отношения между ними...

Спасибо! Получается, что Domain model  - это Д, которую следут строить одной из первых, т.к. с т.з. построения ИС сначала (после получения требований пользователя) нужно их формализовать на верхнем уровне (бизнес-требования)...это верно?
На DM примера активно используются стереотипы. Д включает 2 группы элементов. Элементы одной группы  - классы(часть на рис. stereoT_1). Другой  - actor-ы, хотя по внешнему виду они не отличаются друг от друга(отличаются стереотипами: у гр1 они есть, у гр2 их нет, хотя на интерфейсе ст-пы отображаются в обоих случаях). Попытка создать класс и присвоить ему стереотип actor  к успеху не приводит(нет этого стреотипа в списке). Каким образом тогда можно создать с помощью элемента "класс" (или другого) аналог элемента, который представлен на рис. stereoT_2?

Я не уверена в том, что actor это класс, но знаю хакерский метод простановки стереотипа элемента. Открываем элемент, смотрим на список возможных стереотипов для него и вписываем нужный нам стереотип ручками в соответсвующее поле. Это должно помочь.
Domain model - по-русски это модель предметной области. И она действительно строится одной из первых (если, конечно, в ней есть необходимость)

ИМХО для построения взаимоотношения Пользователей (а вернее их ролей) лучше использовать элемент - Actor. Так и понятнее и меньше проблем.

А насчет Domain model - модель БП можешь ты не строить, а Domain model построить ты обязан. Она очень пригодится на последующих этапах разработки (БД, Классы программы)

Доброго вечера!
С DM все стало понятно...скоро появится первый раздел
А пока хотелось бы задать пару вопросов по следующим видам диаграмм
Opportunity Definition - в проекте это опять-таки похоже на "контейнер", в котором содержатся такие Д:
positioning - что-то вроде стратегических целей проекта (рис1)
stakeholders interests - цели каждого конкретного stakeholder'а (рис2)
Есть ли названия аналоги для трех этих диаграмм на русском?

Процессная модель. Заметила интересную вещь: входы в процесс оформлены с помощью элемента DEPENDENCY, а выходы - OBJECT FLOW, подскажите, плз - это требование нотации или свобода действий автора?

Процессная модель. Заметила интересную вещь: входы в процесс оформлены с помощью элемента DEPENDENCY, а выходы - OBJECT FLOW, подскажите, плз - это требование нотации или свобода действий автора?

А ничего удивительного нет. Поскольку это очень переклиается с IDEF3. Действительно Заказ - это же не просто информация о таковом, это и нечто материальное в данном случае книга, т.е. вполне себе объект. А все входы - это по сути информация. Ведь мы же описываем магазин, который только использует информацию. А заказ потом исполняет склад например. Хотя на самом деле я полагаю никакой большой ценности это не дает

...Д включает 2 группы элементов. Элементы одной группы  - классы(часть на рис. stereoT_1). Другой  - actor-ы, хотя по внешнему виду они не отличаются друг от друга(отличаются стереотипами: у гр1 они есть, у гр2 их нет, хотя на интерфейсе ст-пы отображаются в обоих случаях). Попытка создать класс и присвоить ему стереотип actor  к успеху не приводит(нет этого стреотипа в списке). Каким образом тогда можно создать с помощью элемента "класс" (или другого) аналог элемента, который представлен на рис. stereoT_2?

1) по поводу рис. stereoT_1. <<enumeration>> никогда не соединяют никакими ассоциациями с другими классификаторами. Его обычно рисуют отдельно. А в классе Order надо написать status:OrderStatus
2) по поводу рис. stereoT_2. Тут либо надо использовать tagged value, либо вводить новый элемент через механизм стереотипов.