Отзыв о диаграмме классов UML

Question

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

Спасибо. URL изображения: http://i.stack.imgur.com/zWiGW.jpg

Answer 1

Вот несколько рекомендаций, которые вы можете включить или игнорировать по своему усмотрению:

• Я не согласен с отношениями между Шоу и Местом проведения. Кажется более естественным, чтобы бронирование поддерживало отношения между выставкой и местом проведения.
• Я нигде не вижу Даты для Шоу. Я пропустил это? Это кажется важным.
• Шоу не имеет мест; Место проведения имеет места.
• Билет должен дать вам право на место в месте проведения в определенную дату. Я этого не вижу.
• TicketType должен быть только перечислением.
• Разложить пользователя на классы Name, Address и Credential. Отделите учетные данные от пользователя.
• Реальной платежной системе потребуется гораздо больше, чем то, что вы показываете (например, CreditCard и т. Д.)

Я думаю, что вашей модели нужно много работать.

Answer 2

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

• Если связь является односторонней, то нет необходимости называть оба конца. Вы назвали оба конца всех ассоциаций, но только для судоходного конца требуется имя.

• Удалите ' банка ' со всех концов ассоциации. В некоторых случаях есть удобный термин, например шоу может быть размещено в месте проведения. Но в других случаях совершенно нормально, и даже общепринятая практика называть ассоциации заканчивающимися так же, как и класс на этом конце. (так назовите конец Seat просто Seats )

• Избегайте многих-многих отношений, если можете. Если вы не можете потом добавить промежуточный класс ассоциации, это почти всегда имеет смысл.