EA позволяет использовать любые типы элементов на диаграмме любого типа.

ага, это точно: свобода действий большая
Irr, есть желание продолжить разработку диаграмм? Я понимаю, что особо развернуться негде, но первый этап был на мой взгляд оч удачным - цель достигнута. По поводу Д, которая осталась "бесхозной" - можно ее вообще исключить из рассмотрения

Не вопрос, давайте продолжим.
В проекте получалась куча заинтересованных лиц, целей, потребностей и т.д.
Можно их замоделировать, а потом сюда пакетик выложить - там как раз вылезут те вопросы, которые мы не рассматривали на предыдущем наборе.

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

Irr, выкладываю обновленный пакет.
В пакет добавила 3 диаграммы (целей,обоснования, заинтересованных лиц)+диаграмму-контейнер под них
Внесла соответствующие изменения на начальную диаграмму. Посмотрите плз)

Отлично, Helga! Посмотрю и дам ответ в четверг вечером, раньше не получится.

Сейчас уже более чистенько получилось.
Комментарии:
- англо-русскость названий диаграмм и элементов на этом уровне детализации описания системы, по-моему, мешает воспринимать модель.
- в ходе 2 итераций моделирования у нас actor Преподаватель в модели встречается 2 раза. А зачем? По идее это один и тот же элемент. Просто в одном случае мы объявляем о его существовании, в другом описываем его цели, а в третьем ВИ с его участием. Ответ на вопрос, в каком пакете должен жить элемент Преподаватель, а на каких диаграммах должна быть ссылка на этот элемент, ожидаю от Вас.
- на диаграмме заинтересованных лиц нарисована иерархия Ректор-Декан-Преподаватель. Возможно, что я не права, но как читателю мне хотелось видеть не только связь Dependencу, но и ее название, т.е. как именно они связаны. Ну что-то типа Ректор руководит Деканом и т.п. Но тут я не настаиваю, возможно, это и так понятно.
- с какой целью добавлена диаграмма Обоснование необходимости системы?
- на верхнем уровне у нас сейчас 3 пакета - Opportunity Definition, объекты предметной области, Требования. А все эти названия корректны с точки зрения логики? Все ли они описывают явления одного порядка?  Предлагаю сформировать rtf-документ по этому пакету и посмотреть, на что он похож, какую информацию о системе он несет, кто мог бы быть читателем этого документа? Возможно, взгляд на печатный документ позволит уточнить структуру текущей модели.
Пока все.
И еще вопросик: будут ли дорабатываться диаграммы 1 итерации по комментариям 2 итерации? Хотелось бы получить цельную красивую модель

Irr, прежде чем я пойду править очередную порцию "багов", посмотрите плз: насколько корректно я их поняла)):

- англо-русскость названий диаграмм и элементов на этом уровне детализации описания системы, по-моему, мешает воспринимать модель.

это точно (особенно в файле-отчете rtf). Все названия я переведу. А путаница с двумя языками возникла по тривиальной причине:в качестве примеров смотрела на разные диаграммы (с разными языками), ну и сделала на автомате по аналогии)))))

- в ходе 2 итераций моделирования у нас actor Преподаватель в модели встречается 2 раза. А зачем? По идее это один и тот же элемент. Просто в одном случае мы объявляем о его существовании, в другом описываем его цели, а в третьем ВИ с его участием. Ответ на вопрос, в каком пакете должен жить элемент Преподаватель, а на каких диаграммах должна быть ссылка на этот элемент, ожидаю от Вас.

По идее жить он должен там, где мы объявляем о его существовании. Вся соль ситуации в том, что у меня есть вариант 2 и 3. Но нет объявления существования. В связи с этим можно рассмотреть такой вариант:
добавить элементы actors на Д "объекты предметной области" . На Д заинт.лиц, ДВИ сделать наследование. насколько это верно?

- на диаграмме заинтересованных лиц нарисована иерархия Ректор-Декан-Преподаватель. Возможно, что я не права, но как читателю мне хотелось видеть не только связь Dependencу, но и ее название, т.е. как именно они связаны. Ну что-то типа Ректор руководит Деканом и т.п. Но тут я не настаиваю, возможно, это и так понятно.

спасибо, что напомнили, что у всех  зависимостей есть названия - я про них просто забыла((

- с какой целью добавлена диаграмма Обоснование необходимости системы?

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

- на верхнем уровне у нас сейчас 3 пакета - Opportunity Definition, объекты предметной области, Требования. А все эти названия корректны с точки зрения логики? Все ли они описывают явления одного порядка?  Предлагаю сформировать rtf-документ по этому пакету и посмотреть, на что он похож, какую информацию о системе он несет, кто мог бы быть читателем этого документа? Возможно, взгляд на печатный документ позволит уточнить структуру текущей модели.

в документе rtf это смотрится откровенно не оч хорошо. Нужно что-то менять - подозреваю, что Объекты предм.области придется понижать хотя бы на 1 ур.
OpDef переместить в Требования (если рассматривать пакет Требования как бизнес-требования к системе)
если говорить о читателях, могу предположить:
цели, ЗИ - это для заказчика или руководства +БА.
объекты предм.области - БА+СА
требования - БА

И еще вопросик: будут ли дорабатываться диаграммы 1 итерации по комментариям 2 итерации? Хотелось бы получить цельную красивую модель

будет:))

это точно (особенно в файле-отчете rtf). Все названия я переведу. А путаница с двумя языками возникла по тривиальной причине:в качестве примеров смотрела на разные диаграммы (с разными языками), ну и сделала на автомате по аналогии)))))

Очень хорошо. Для этого мы и пересматриваем модель, чтоб она была смысловая, а не на автомате.

По идее жить он должен там, где мы объявляем о его существовании. Вся соль ситуации в том, что у меня есть вариант 2 и 3. Но нет объявления существования. В связи с этим можно рассмотреть такой вариант:
добавить элементы actors на Д "объекты предметной области" . На Д заинт.лиц, ДВИ сделать наследование. насколько это верно?

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

спасибо, что напомнили, что у всех  зависимостей есть названия - я про них просто забыла((

Тут кстати, может быть название не UML-ное, а просто логически интуитивно понятное. Какое название выбрать, зависит от квалификации пользователей диаграммы. Если заказчик не знает УМЛ, то ему захочется видеть нормальное русское название.

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

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

в документе rtf это смотрится откровенно не оч хорошо. Нужно что-то менять - подозреваю, что Объекты предм.области придется понижать хотя бы на 1 ур.
OpDef переместить в Требования (если рассматривать пакет Требования как бизнес-требования к системе)

Я согласна с Вами, поэтому предлагаю Вам подумать на тему переструктурирования иерархии пакетов и переименования пакетов. Если рассматривать пакет Требования - как бизнес-требования, почему бы так его и не назвать?

если говорить о читателях, могу предположить:
цели, ЗИ - это для заказчика или руководства +БА.
объекты предм.области - БА+СА
требования - БА

В принципе, в отдельном пакете можно построить модельку структуры и использования нашей модели: у нее есть читатели (пользователи), пакеты (составные части) и появятся документы (т.е. этот пакет пойдет в ТЗ, этот в концепцию и т.д. - этакий userguide по модели

Irr, пасиб! беру тайм-аут до понедельника - есть над чем подумать и что сделать))

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

Замечательно! Подробно посмотрю как всегда, в четверг :-)

Девчата, молодцы!!!!

Здорово, если результаты будут потом оформлены окончательно.

Спасибо за поддержку!
А под оформленными результатами что понимается:
выложенная модель в пакете+краткое описание (что в какой последовательности делали)?
а еще в соседней ветке зависла пара вопросов по существующему примеру ЕА...
Помогите плз, чтоб там тоже были результаты )

А под оформленными результатами что понимается:

Нечто законченное и готовое для использования (изучения). Статья, брошюра, блог, все что Вам больше нравится

Helga, я написала Вам в личные сообщения.

Galogen, что-нибудь обязательно получится законченное и готовое для использования. Мы оформим.