Подскажите что нужно дополнить в классы, а возможно и в другие диаграммы и материалы, буду очень благодарен. Задание прикреплено к сообщению.
Диаграмма прецедентов:

Диаграмма деятельности:

Диаграмма классов(вот её надо доделывать, но что то мысли кончились):



С уважением, Александр.

Ваши диаграммы не видны

Извините , просто с  другого форума http://www.cyberforum.ru/post4295406.html скопировал

ДВИ почти полностью не верна
1. варианты использования у вас по сути декомпозиция одного или двух реальных. Читайте постановку лучше. Мне как покупателя возможно интересно:
Просмотр каталога компьютеров и комплектующих
Составления конфигурации компьютера
Размещение заказа на приобретение компьютера

Т.е. имя ВИ и сам ВИ должен отражать цель использования системы (зачем, для чего) с точки зрения самого пользователя. И это однократные непрерывные последовательности взаимодействия.

Отправить имайл - зачем, с какой целью
Подсчитать стоимость - для чего, зачем
Выбор РС чем закончится, это цель обращения в магазин?
 
2. границы систем на мой взгляд выбраны странно, что за система веб-страница? веб-страница - это документ который пользователь видит у себя на экране, это интерфейс, да и рано еще говорить о веб-страницах
3. ДК лучше, но имо перемешаны программные классы и классы предметной области, при этом есть граничные классы - окна, но нет классов управления, вы что хотели изобразить на этой ДК

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

С уважением, Александр.

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

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

Александр, в Вашей обновлённой диаграмме случаев использования можно кое-что исправить и повысить читабельность:

1. Отношение между акторами Курьер и Клиент: в этой диаграмме отношение означает, что актор инициирует юзкейс. У Вас изображено отношение инициации между двумя акторами, что неверно.
Средствами UML можно отобразить что один актор является частным случаем другого (например, "продавец" - частный случай "сотрудника магазина"), но такое отношение изображается линией со стрелкой. Клиент и Курьер в Вашем случае не должны быть соединены какой-либо связью.

2. Акторы и юзкейсы геометрически перемешаны: это плохо, т.к. снижает читабельность - можно не заметить фигурку актора среди больших эллипсов.
Кроме того, если у Вас только одна система, можно не обводить юзкейсы прямоуголькой рамкой, обозначающей систему, в которой они лежат, но если при анализе выяснится что на диаграмме более одной системы, Вам придётся полностью её перекомпоновать, потому что акторы не должны быть внутри таких прямоугольников, т.к. не являются частью технической системы.
Хороший подход - изображать акторов справа и слева, а юзкейсы - в центре в 1-2 столбика.

3. Почти наверняка упущен актор - платёжная система. Внешние системы тоже могут быть акторами: платёжная система может авторизовать платёж или не сделать этого, заморозить счёт клиента или счёт магазина и т.д. То есть это некоторая внешняя сущность, обладающая "свободой воли".

4. Есть юзкейс "информировать склад о заказе". Мои догадки:
Курьер - скорее всего не единственный работник склада, тогда здесь тоже есть упущенный актор Работник склада.
Курьер не должен получать информацию о заказе сразу, м.б. товара нет на складе, или товар не могут в ближайшее время отгрузить, или ещё не оформлены какие-либо документы и т.д. Работник склада сообщит курьеру когда заказ готов к отпрвке.

5. Есть юзкейс, названный "Счёт для печати": не до конца очевидно из названия, что именно происходит со счётом - его создают в электронном виде, печатают, оплачивают, или посылают кому-либо (кому?, в каком виде?, по какому каналу?).
Хорошие названия для юзкейсов: "Создать счёт", "Распечатать счёт", "Отправить электронный счёт клиенту по e-mail".

6. Непонятна связь между кейсами "Проверка оплаты заказа" и "Доставка PC", нужно обозначить что доставка включает проверку оплаты - отобразить отношение <<include>>.