1

Задачи студентов / Re: Какую классовую диаграмму выбрать из имеющихся?

« : 19 Мая 2019, 23:09:23 »

1. Никакая не лучше. Попробуйте прописать наименование каждой связи, ну там типа "работает в", "состоит в " и мощности пропишите, вполне возможно у вас получится сделать еще один вариант, и выбирать уже не надо будет.
2. Операция аутентификации пишется в класс аля пользователь. Но тогда вам придется вводить роли, логины, пароли, поиски, просмотры списков и проч элементы, которые не имеют отношения к предметной области, а появляются уже при описании уровня системы.
3. Если вам надо хранить всю историю, то у вас не может быть операций удаления как минимум у сотрудника и истории.
4. Ну и поотвечайте себе сами на вопросы: а что если поменяется имя подразделения, или название должности, или если поменяют шр и из подразделения выведут должность, что если сотрудник по совместительству на нескольких должностях в одном подразделении и в разных, должность относится только к сотруднику или к паре сотрудник-подразделение (т.е. должность это начальник отдела или начальник первого отдела) и меняется ли должность при смене подразделения, относится ли текущая (актуальная) должность (и) к истории или к сотруднику, что написано в истории у уволившихся и сначала уволившихся, а потом снова принятых. Ответите, вам будет проще определить зависимости.

2

Проектирование / Re: Как спроектировать систему

« : 06 Мая 2019, 22:05:22 »

Про график обслуживания. Сложности могли бы возникнуть, если бы система должна была по-разному реагировать на разные виды событий графика обслуживания. Но реакций то всего две: 1. обслуживание по времени, причем точка отсчета введена в систему. Т.е. система знает точку отсчета и автоматически отслеживает время. 2. обслуживание на основании изменения информации, введенной пользователем. У вас же система не может автоматически контролировать пробег, запуски и прочее - она должна реагировать на изменение значения и сигнализировать о превышении этим значением заданного.
Т.о. все эти ваши запуски, пробеги и прочие виды, автоматически не контролируемые, ложатся в обычный какой-нибудь справочник.  Появился у вас третий тип автомобиля, в справочник событий просто добавляется "количество запусков". А уже при описании типа количество запусков ничем не отличается от пробега - указывается контрольное значение и отношение (меньше там или наоборот больше).  Системе все равно, что проверять поле под названием "пробег", в которую пользователи вводят числа или поле под названием "запуски", в которые те же самые пользователи вводят те же самые числа. А раз нет разницы, то список может и пользователь расширять.

А по поводу проверки корректности.  Пользователь сначала описывает тип автомобиля, куда как раз добавляет все агрегаты, графики ТО, маски и прочие данные. А уже потом создает экземпляры автомобиля этого типа. К тому моменту как создается конкретный автомобиль в системе уже сохранена информация, что у этого типа автомобиля сер.номер числовой 15-ти значный, а у этого  - 20 знаков смеси латиницы и цифр. Когда система показывает пользователю форму для ввода данных по автомобилю, в контроль данных этой формы уже заложены все необходимые проверки. Форма генерится каждый раз на основании сохраненных ранее данных.

3

Проектирование / Re: Как спроектировать систему

« : 05 Мая 2019, 17:16:54 »

Не вижу никаких проблем с точки зрения реализации как форм так и хранения.
У пользователя в админке будет форма описания типа автомобиля. Ему нужно будет на этой форме описать новые (или добавить уже ранее описанные) атрибуты. При описании атрибуты, например, будет указывать его наименование, ставить флажок нужен контроль или нет, выбирать тип значения или маску для ввода, как вариант.
Когда пользователь будет создавать новый автомобиль - форма для ввода будет генериться уже с учетом информации о необходимых контролях и типах.
Хранение этих новых атрибутов тоже может быть разным, в зависимости от того, на чем пишем, какая нагрузка, объема данных и прочих факторов. Начиная от общей таблицы, в которой просто будут поля для раскладывания туда атрибутов разных типов (а контроль обязательности делать только на форме), заканчивая созданием отдельной таблицы для каждого атрибута при описании типа автомобиля.

Можете как-то подробнее описать, в чем именно вы видите проблемы?