Анализ диаграммы классов - связывание классов

Question

Новый пользователь, поэтому я не могу публиковать изображения.Ссылка на изображение представлена ​​ниже:

http://i.stack.imgur.com/EXf0G.jpg

Это для встроенной системы бронирования, а не системы онлайн-бронирования.

Нормальный сценарий бронирования:

Пользователь / Участник дает информацию администратору.Пользователи могут забронировать за месяц до начала.

Регистратор ищет информацию о пользователе / ​​участнике.Регистратор должен войти в систему, чтобы выполнить поиск пользователя / участника или сделать заказ.

если найдены подробности, бронирование продолжается как обычно, если нет сведений о пользователе, добавленных в файл пользователя.

Время бронирования/ date / type затем проверяется на наличие.Если доступно, то бронирование выполняется.

Дополнительно:

Существует два типа учетной записи персонала: «обычный пользователь» (администратор) и «администратор» (менеджер).

Менеджер может сбрасывать пароли учетных записей сотрудников и создавать новые учетные записи сотрудников.

Менеджер может редактировать сведения о сеансе в расписании (время, дата, тип) и т. Д. Нужен ли здесь класс расписания?

Answer 1

Чтобы ответить на это, нам понадобится гораздо более развитая спецификация.

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

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