task-5

[ValchukDmitry]

No description provided.

[artbez]

1. веб-интерфейс это MainController, а веб-сервисы выражаются через RestController? Насколько я вижу, они ссылаются на одни и те же сервисы, и эти связи сильно усложняют диаграмму. Мб ввести промежуточную сущность ServiceFacade которая бы объединяла эти сервисы. Тогда MainController и RestController будут ссылаться только на нее.

Интернет-магазин должен иметь веб-интерфейс, но он должен иметь возможность подключения через другие интерфейсы (веб-сервисы и т.п.)

2. Хорошо бы добавить какой-нибудь AuthService, который бы занимался аутентификацией.
3. Было бы здорово добавить методы для изменений в Review. Если предполагается, что модификация = get + addReview, то лучше назвать просто save.
4. Нужно еще раз прочитать презентацию и внимательно проработать откуда, куда и какие следует ставить стрелки. Приведу несколько замечаний:
   а) SearchService не агрегирует RestController, здесь лучше подойдет подойдет обыкновенная
   ассоциация, причем из RestController в SearchService
   б) Если ассоциацию и ставить между Book и WishList, то стрелку нужно заменить на противоположную. Но на мой взгляд, здесь лучше подойдет агрегация. WishList содержит книги, но не управляет их жизненным циклом.
5. Если ставить ассоциацию, следует убрать соответсвующие ей поля. Например, с книгами.
6. Отсутствуют показатели множественности (1:1, 1:* и тд).

Диаграмма имеет хорошую структуру, но лучше постараться расположить элементы таким образом, чтобы она была боле наглядна. Мб разбить на логические уровни.

[ValchukDmitry]

1. Исправил
2. Чтобы еще сильнее не нагромождать структуру, добавил у User метод для проверки правильности пароля.
3. Переименовал в save
4. Еще раз прочитал лекцию и исправил.
5. Исправил.
6. Добавил

Насчет структуры диаграммы: попытался решить все передвижением элементов, но тогда стрелки наезжали друг на друга и становилось только хуже. Поэтому оставил примерно такую же структуру.

[yurii-litvinov]

Добавлю ещё от себя.

• Неплохо бы выкладывать исходники диаграмм, а то править это можно будет только в графическом редакторе.
• Не стоит рисовать геттеры для полей --- это детали реализации, а не часть архитектуры. Можно просто обозначить поле как public, программист догадается сделать его private и сделать ему геттер (и сеттер, если нужно).
• Связь между SearchService и BookRepository нарисована поверх SearchService, неаккуратно. Вообще, связи не должны пересекать фигуры классов, это сильно снижает читаемость диаграммы.
• Ассоциации к enum-ам обычно не рисуются, enum в UML --- тип-значение, а типы-значения обычно представляются как поля (в частности, чтобы не загромождать диаграмму).

Но в целом теперь всё ок, можно зачесть.