Краткий обзор диаграммы и советы
Сначала несколько небольших замечаний по поводу именования классов: Ordered следует назвать Order.
Композиция между Article и Order является просто неправильной (не с формальной точки зрения, а из значения, которое она передает). Используйте обычную ассоциацию один-ко-многим : она намного лучше отражает реальный характер отношений между двумя классами. Пожалуйста, примите во внимание, что новая статья может существовать без заказа, поэтому она должна быть 0..* вместо 1..*
+belongs и +do в серединеассоциация синтаксически неверна. Вместо этого вы должны использовать простой треугольник (или вообще ничего). Треугольник должен быть ориентирован в направлении чтения Person do |> Order и Article belongs to |> Category
Методы кажутся нормальными. Вам не нужно добавлять суффикс.
Как должны управляться объекты (создаваться / обновляться / удаляться)?
Более сложная задача связана не с диаграммой, а с тем, как вы хотите организовать постоянство (т. Е. Хранение базы данных):
- Вы действительно хотите, чтобы объект был активной записью , то есть объектом, который добавляет, обновляет и удаляет себя (в базу данных)? Он прост в настройке, работает хорошо, но делает класс зависимым от базовой реализации базы данных и, таким образом, усложняет обслуживание;
- или не лучше было бы использовать репозиторий за каждый объект? В этом случае хранилище действует как коллекция, которая управляет всеми операциями базы данных. В этом случае объекту домена (Article, Order, User, ...) нечего знать о базе данных, что приводит к созданию более понятного кода.
Но это более широкий архитектурный вопрос. Если это только для первого экспериментального проекта с JEE, вы можете очень хорошо использовать активные записи. Проще настроить. Однако в этом случае обязательно устраните неоднозначность добавления / обновления / удаления на Person, поскольку в настоящее время может сложиться впечатление, что любой человек может добавить кого-либо.
Улучшение модели
Последнее замечание, опять же не о самой диаграмме, касается области. Ваша модель считает, что Order это примерно один Article.
В действительности, однако, заказы, как правило, состоят из одной или нескольких статей: если бы это также имело место здесь, ваш Order стал бы OrderItem, а реальное Order было бы вставлено между Person и OrderItem. Затем вы могли бы сделать соотношение между Order и OrderItem композицией (то есть: OrderItem принадлежит Order, который отвечает за создание своих элементов, и эти элементы не имеют смысла без соответствующего порядка).