Создание диаграммы классов UML для входной системы?

Question

Я смотрю на входную систему тренажерного зала. Клиент входит в здание, дает свои данные регистратору, регистратор вводит данные в базу данных, проверяет детали, регистратор берет платеж, если клиент не является участником, а клиент продолжает работу внутри.

У меня есть четыре класса: клиент, администратор, администратор, база данных. У меня нет члена и член обобщен под заказчиком. существует множество отношений между клиентом и регистратором (многие из клиентов). отношения один к одному между регистратором и базой данных. отношения между регистратором и администратором.

ли мои классы и отношения правильно?

Answer 1

это непросто ответить. Вы говорите о классах, поэтому я предполагаю, что вы создаете диаграмму классов. Если это так, я не уверен, что буду включать класс администратора (по крайней мере, не для этого случая использования). Регистратор может существовать на диаграмме потока данных. На диаграмме классов класс-регистратор может существовать в рамках процесса оплаты персонала или оплаты персонала. Внутри системы ввода с точки зрения программирования, как ваш клиентский класс взаимодействует с классом администратора? Какие методы класс приемника содержит для этого взаимодействия? Я бы предположил, что нет, реальный человек-регистратор взаимодействует с реальным клиентом, но класс клиента не будет взаимодействовать с классом администратора, если только вы не регистрируете, какой администратор обработал транзакцию.

Даже в этой ситуации я бы предположил, что это будет другой класс, который управлял этим действием.

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

Answer 2

Так вот мои наблюдения:

• Все атрибуты/операции должны начинаться с прописной буквы (и, как вы сделали все классы с прописной буквы). Это общая конвенция, принятая в списке всех языков, которые я знаю (что определенно не является полным, но это более одного или двух).
• Вы используете общую композицию с Member и Non-Member. Скорее всего, это должно быть отношением обобщения. Поэтому вам нужно использовать треугольник треугольника вместо алмаза.
• Вы должны использовать имена ролей с ассоциациями. То есть вы должны отметить administrator в сторону класса Administrator. Это сделает его атрибутом administrator типа Administrator внутри Receptionist.
• Нельзя определять атрибуты ID в черновике/бизнес-модели. Идентификатор обычно выводится при компиляции позже с адреса объекта. Таким образом, вы ссылаетесь на объект как таковой, а не на идентификатор.
• Существует связь между Receptionist и Database. Я не думаю, что это мудрое дизайнерское решение здесь. Неясно, для чего будет использоваться база данных. Вероятно, каждый и любой класс каким-то образом будут зеркалироваться в базе данных. Таким образом, вместо этого эти классы должны реализовать интерфейс Serializable, который позволяет их зеркалировать в базе данных. Наличие Database как класса в бизнес-модели неправильное. Просто сосредоточьтесь на бизнес-объектах и ​​реализуйте слой сохранения на более позднем этапе.
• Из вашего описания я не вижу, где находится Administrator. Кажется довольно параноидальным, чтобы у администратора был один администратор.