Преамбула:
Есть задача сделать интернет-магазин, да еще и так, чтоб я все понял, т.к. потом надо будет объяснить преподу (дело в том, что он сам не особо понимает UML, а знаниями надо делиться)

Амбула:
Необходимо реализовать интернет-мазагин, в котором есть админы, менеджеры и клиенты. Клиенты делают заказ пользуясь каталогом или заказ формируется сам на основе истории заказов клиента. Заявка уходит менеджеру, который подтверждает её и отправляет заказ на склад или отклоняет заявку. Админы просто управляет учётками.

Накидал примерно так:
Пользователь ( авторизоваться, получить сообщение, отправить сообщение )
1.   Клиент
—   Сформировать заказ
—   Изменить заказ
—   Удалить заказ
—   Оформить заявку
—   Посмотреть историю заказов
2.   Менеджер
—   Отклонить заявку
—   Подтвердить заявку
—   Отправить запрос на склад
3.   Администратор
—   Добавить пользователя
—   Удалить пользователя
—   Изменить пользователя
—   Забанить пользователя

Необходимо сделать:
1. ДВИ (видимо, ДСВИ)
2. Диаграмму классов модели бизнес-анализа (что это ваще? О_о)
3. Идентификацию основных абстракций
3.1. Классы анализа системы
3.2. Диаграмма трассировки
4. Диаграмму последовательности


Если объяснят что нужно бы делать еще, а что не делать вообще при проектировке чего либо -- буду рад узнать

ДВИ у Вас получилась как функциональная декомпозиция.
НАдо сделать следующее:
1. Все ВИ, которые отвечают за добавление\изменение\удаление\... одного бизнес-объекта (БО), следует объединить в в один ВИ - Управлять <БО>
2. ВИ "Сформировать заказ", "Отклонить заявку", "Подтвердить заявку", "Отправить запрос на склад" - это один ВИ "Подать\Оформить Заказ", в кот. участвуют Менеджер и Клиент, и уже в сценарии следует описать все действия, кот. Вы выделили в виде ВИ.
3. ВИ "Изменить заказ", "Удалить заказ" следует объединить тоже в один ВИ "Изменить заказ"

Диаграмма классов модели бизнес-анализа (что это ваще? О_о) - это скорее всего модель бизнес-объектов, т.е. сущностей предметной области и связей м.у. ними.

Можно поподробнее о модели бизнес-объектов?? Как строятся такие диаграммы?

Про декомпозицию уже понял Описываю ВИ, буду строить заново

Начал описывать ВИ... аттач внизу

UPD:
Немного поправил файлег

Можно поподробнее о модели бизнес-объектов?? Как строятся такие диаграммы?

http://ito.edu.ru/2005/Moscow/VII/VII-0-5032.html

Начал описывать ВИ... аттач внизу

Ну, во-первых, можно сохранить хотябы в формате 2003 Ворда файл, чтобы все могли его прочитать. А, во-вторых, что нуна-то?

Нужно:
Сделать проект, как он должен делаться по-настоящему, построить все нужные диаграммы. Вариации последовательности действий свободные

что от участников форума нужно-то ? по посту совсем не понятно:

Начал описывать ВИ... аттач внизу

UPD:
Немного поправил файлег

и что? так и хочется ответить - продолжай описывать, сделай теперь аттач вверху.

что от участников форума нужно-то ? по посту совсем понятно:

и что? так и хочется ответить - продолжай описывать.

Нужно взять меня за ручку и сопроводить от начала моделирования до его логического завершения Да еще и так, чтобы я всё понял... просто я видать тугой очень, по книжкам плохо въезжаю... вчера сутки просидел, сделал -- и то не верно оказалось

Итак, что мы имеем...
1. Файлег с описанием всех ВИ
Когда вы его утвердите, я соберу СДВИ.... как делать БДВИ мне надо немного объяснить....

Дальше надо делать (если я не ошибаюсь) диаграмму последовательности, а потом диаграмму классов

Очень прошу помощи.. надеюсь доделать за ближайшие дни этого зверя

Итак... немного поделал UC... что получилось в аттаче... ну и дописал "описание ВИ".
Я кстати всё разнес по Package и создал отдельно диаграмку, где есть всё (для препода).

Как делать диаграммы последовательностей?? И вообще, что надо делать после UC модели?

Я про связи хотел узнать в UC модели. Вот около клиента написано 1, около "Оформить заказ" 1..4. Это значит, что клиент может оформлять 4 заказа в раз, или всего 4 за всё время?

К сожалению сейчас нет времени, поэтому небольшое замечания только по ДВИ:
1. По первой ДВИ:
1.1. Я бы сделал "Выйти из Системы" как альтернативный поток в ВИ "Войти в Систему"
1.2. Я бы убрал ВИ "Модерировать Заказы", а описал бы взаимодействие внутри "Управлять Заказами" и к нему два Актера - Клиент и Менеджер
1.3. По классике "Зарегистрироваться в Системе" делает Пользователь, но на сколько это правильно? Что скажут другие участники Форума?
2. ПО второй ДВИ:
2.1. Что ты на не хотел показать??
2.2. На ДВИ нет связи зависимости от ВИ к Актеру и нет множественности
2.3. Почему на этой ДВИ есть Банк а на первой ДВИ нет его?

1. Регистрация в системе сама по себе не является целью пользователя, т.к. value пользователь получает  от приобретения товара в интернет-магазине. А регистрация -- это лишь условие использования интернет-магазина, диктуемое технологическими особенностями работы магазина. Кроме этого, регистрация нужна только для того чтобы делать покупки, а чтобы просмотреть каталог товаров и цены, обычно не нужно регистрироваться. Кроме этого, а вообще нужна такая функциональность, как наличие аккаунта? Может сделать проще - хочешь купить товар - укажи данные о себе, чтобы с тобой могли связаться и т.п. Тем более это учебный проект.
2. Вход и выход из системы я бы не выделял как отдельные юзкейсы ... какой под ними важный сценарий кроме сопоставления user name и password-а? Вот если бы планировался вход помимо user name\password через смарт-карты или по отпечаткам пальцев :-) ... тогда имело смысл выделять как отдельный юзкейс в котором в вариациях технологий и данных это бы и указал. 
С выходом та же ситуация -- выделять имеет смысл если мы хотим сделать акцент на то, что система тайм-ауты считает и т.п. ... т.е. выход из системы пользователи делают не всегда по кнопочке log off .. часто просто закрывают браузер, при этом (в зависимости от реализации) сессия может еще висеть и отрубиться по тайм-ауту.
Т.о., при простом случае вход в систему и выход можно просто указывать шагами других юзкейсов, или вообще в предусловиях в теле юзкейса говорить что пользователь должен быть залогинен в систему.

По диаграмме "бизнес-объектов". Рекомендую нарисовать обычную domain model и не париться. Т.е. показать какие экторы с какими бизнес-сущностями связаны и каким образом. Т.е. имеем ту же самую диаграмму классов.

По диаграмме "бизнес-объектов". Рекомендую нарисовать обычную domain model и не париться. Т.е. показать какие экторы с какими бизнес-сущностями связаны и каким образом. Т.е. имеем ту же самую диаграмму классов.

Юрий, дело в том что я начинающий... всё, с чем я успел разобраться -- я нарисовал Можно поподробнее как делать диаграмму классов и чем вообще БДВИ от СДВИ отличается?? Я во второй диаграмме БДВИ пытался изобразить

Вопрос в силе:
Я про связи хотел узнать в UC модели. Вот около клиента написано 1, около "Оформить заказ" 1..4. Это значит, что клиент может оформлять 4 заказа в раз, или всего 4 за всё время?