Все, есть очередная версия....

ID обычно не пишут как атрибуты классов. Используйте квалификаторы.

Смотрю на очередную версию модели: выглядит чисто и красиво. Теперь можно сосредоточиться над соответствием модели нотации UML, чтоб количество диаграмм было побольше, элементы по-разнообразней. На них можно будет с трассировкой поиграть. - но выбор дальнейшего направления для усилий оставляю за автором :-)
Теперь комментарии:
Смущает пока схожесть модели классов и словаря предметной области. По идее в словаре предметной области все должно быть на русском языке, и классы словаря не должны принадлежать какому-то языку (а в модели это Java). А вот модель классов приложения - она как раз наоборот может строиться под определенный язык реализации, для дальнейшей кодогенерации. В общем, по этому поводу хорошо спросить знатоков UML:
1. Как нарисовать правильно словарь предметной области? Она же BusinessDomainModel (если пользоваться терминами RUPа) или DomainModel  в примере к ЕА. Кстати, в примере классы словаря имеют стереотип Entity и Language None.  - я думаю, это неспроста!
2. Рисование классов проекта - это такой сложный момент, классы проекта могут быть сначала нарисованы в виде абстрактной модели, а потом трансформированы в конкретную реализацию Переход от абстрактной модели классов к конкретной  реализации в примере показан как MDA Transforms из AbstractClassModel  (PIM - платформонезависимая модель) в ImplementationModel (PSM - платформозависимая модель). Решение о том, какие модели классов строить, а какие нет, принимает архитектор/проектировщик - в общем, это густо замешано на конкретной разработке, и зависит от того, собираемся ли мы генерировать исходный код из модели или нет. Эти решения так же принимать автору модели.

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

Диаграмма использования - это мой термин, не общеупотребительный. Я предложила нарисовать метамодель нашей модели. Т.е. описать структуру нашй модели в виде классов. Практически это будет выглядеть как диаграмма классов, где на текущий момент есть следующие классы: Словарь предметной области, Заинтересованные лица (ЗЛ), связанный с ним класс Цели заинтересованных лиц, связанный с ЗЛ класс Бизнес-требования. В общем, когда будет побольше исходная модель - могу нарисовать и объяснить подробней.

Ира,

А что ты хотела конкретно спросить про Business Domain Model? Ты вроде сама написала ответы

А что ты хотела конкретно спросить про Business Domain Model? Ты вроде сама написала ответы

Из каких элементов она строится. Когда-то давно мы такое строили из элементов (видимо, классов, но не помню) со стереотипом BusinessEntity. Используется ли такое в свежих вариантах нотации UML, я не знаю, хочу узнать у вас, знатоки. Просто в EA, например, с 7й версии в дефолтном списке стереотипов нет ни businessentity, ни businessworker'а, а вот если ручками прописать, он меняет графическое отображение.

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

Именно нотация UML ничего не говори про Business Domain Model, что и правильно, т.к. она дает нотацию, а представление мы сами строим.
Business Domain Model определена в РУПе и ОпенУПе.
Она строится из элементов Класс со стереотипом Actor и  Business Entity.

А помочь - поможем.

Business Domain Model определена в РУПе и ОпенУПе.
Она строится из элементов Класс со стереотипом Actor и  Business Entity.

О! Предчувствия меня не обманули, я как раз смутно помню, что не все так просто с ними...
А Actor просто или таки businessActor с кривой палочкой в районе шарика-головы?
Все-таки интересно, как называется эта нотация, где их ввели. Я помню, что видела их в RUPе, но это ж не нотация, а методология...

Можно почитать РУП, что нужно включать:
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/reports/re_bom.htm

Ира, это нотация ЮМЛ, т.е. обычная ДК со стереотипами.

О! Предчувствия меня не обманули, я как раз смутно помню, что не все так просто с ними...
А Actor просто или таки businessActor с кривой палочкой в районе шарика-головы?
Все-таки интересно, как называется эта нотация, где их ввели. Я помню, что видела их в RUPе, но это ж не нотация, а методология...

Ира, было введено именно в РУП процессе. Другими поддерживается или нет.

Спасибо всем за комментарии! Извиняюсь, что долго попадала.
Ошибки с языком модели исправлю. По дальнейшему курсу есть предложение сделать диаграммы анализа, т.е. набор диаграмм с т.з. системного аналитика + диаграмму процесса.
Irr, нам такой вариант подходит?

По дальнейшему курсу есть предложение сделать диаграммы анализа, т.е. набор диаграмм с т.з. системного аналитика + диаграмму процесса.
Irr, нам такой вариант подходит?

Замечательные планы! Вполне подойдет!

А где можно последнюю модель в виде набора картинок посмотреть?
Я видел несколько скриншотов и к ним есть вопросы на самом деле...

Denis, полный набор диаграмм в картинках - вот в этих двух вложениях (ч.1.и ч.2). Остальные - анализ и процесс - будут немного позже.
И... еще оч хотелось бы узнать: как задать в EA квалификатор (если это можено сделать в ЕА) вместо идентификаторов-атрибутов (сама честно пыталась найти, но поиск результатов не выдал)?

это вторая часть диаграмм модели

Я посмотрел диаграммы. Спасибо.

С точки зрения синтаксиса UML следующие замечания:
1) Раздел Р3-2 Д Заинтересованные лица.
   Раздел Р3-3 Д Цели заинтересованных лиц
Между ДЛ не может быть зависимостей, как нарисовано. ДЛ могут быть связаны только обобщениями. Больше никак.

2) ВИ Запросить документы.
Что такое "Напечатать документ" слева сверху от деятельности "Напечатать документ"?
То же самое на следующей диаграмме.

По проектированию тоже есть замечание. Хотя это все не слишком принципиально. Я ТЗ не видел, поэтому не могу утверждать, как должно быть.

1) Д Словаря предметной области.
Обычная практика : Предмет-преподаватель-студент связаны тернарной ассоциацией, а Журнал - это класс-ассоциации. То что сейчас нарисовано допускает такие вещи, например: студент слушает ОДИН и тот же курс у разных преподавателей или преподаватель читает ВСЕ курсы.
2) там же
Журнал обычно принадлежит группе, а не предмету или преподавателю или студенту. Это никак не отражено.

Helga, hi.

Можно покритиковать?

1. Словарь предметной области.
1. Вы используете для идентификации объектов некий ID. Мне кажется это не правильно. Неправильно по разным причинам. Для начала нужно понимать, что концепции ООП предполагают идентификацию объектов по умолчанию.
2. Это больше похоже не на словарь, а на реализацию
3. ID как внешняя ссылка в журнале - некорректна. Вы же уже указали ассоциацию. Каким образом будет осуществлена связь объектов, нам сейчас не важно. Будет ли это концепция внешнего ключа или ссылка на объект или что-то иное, все это в будущем. При проектировании и реализации
4. Следовательно нужно убрать все ID или заменить их ясными и точными атрибутами ПРЕДМЕТНОЙ ОБЛАСТИ.
Предмет никогда не идентифицирется по ID, он идентифицирется через название
Преподаватель скорее идентифицируется или через табельный номер, или через принадлженость к кафедре и ФИО
Студент может идентифицироваться номером зачетной книжки, студенческого билета
Группа идентифицируется специальностью, годом поступления, возможно номером, если на специальности несколько групп
Журнал - что за журнал? Журнал успеваемости? Если так то используйте это название, т.е. название ПРЕДМЕТНОЙ области
Роли на ассоциациях тоже важны, у вас они какие-то странные, сборник? непонятно. Мне как заказчику Ваша модель предметной области не понятна
5. Связь Студент - группа. Я бы поставил некоторое ограничение кратности со стороны студента скажем (12..30), т.е. такми образом я учитываю бизнес-правило - количество студентов в группе не меньше 12 и не больше 30
6. Связь Студент - Журнал. Студент может встречаться в разных записях журнала или объектах журнала. Но в 1 журнале может быть только один Студент - разве это верно?

Резюме - смесь реляционного (порой не правильного ) и объектного подхода. Диаграмма не пойдет!

2. по ВИ и диаграммам деятельности
1. ВИ запросить документы. А описано по сути создание документа. Если моя цель запросить документы, то каков результат? Он очевиден запрос послан и скажем принят или не принят
2. ВИ регистрации оценок - ДД непонятна, что значит запрос на регистрацию?? Мне представляется это таким образом. Выбрать группу, открыть документ, выбрать студента, ввести оценки по студенту, сохранить
3. ДК - это что? проектная диаграмма классов? Диаграмма классов аналитической модели, VOPC реализации ВИ, проектная диаграмма классов, модель данных - не понятно. При этом все ошибки ПРЕДМЕТНОЙ области перемещены в сюда, хотя добавлены операции, а как Вы получали эти операции? Кроме того все показанные операции это типичные операции любого класса (конструктор и деструктор). Не принято указывать то, что подразумевается по умолчанию. А вот семантически значимых операций нет

Резюме - должно быть переделано и осознано почему и что

Сорри если резковато