Диаграммы классов UML: наследование классов и связи между классами

Question

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

это моя база данных дизайна

, и это диаграмма класса, котораяЯ сделал на основе дизайна базы данных.

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

1. Связи с общественностью = Входные данные от внешнего пользователя (заявитель приходит и дает письменное предложение), затем данные сохраняются в базе данных.Данные включают в себя данные заявителя и данные предложения.PR также может видеть данные, которые были подтверждены отделом
2. Division = Отдел может видеть данные, которые были сохранены PR, и подтверждать данные.Подтвержденные данные будут сохранены и составлены в виде отчета.
3. Manager = может видеть только отчеты

Answer 1

В дополнение к наблюдениям Томаса Киллиана, ваши композиционные ассоциации кажутся неточными.В действительности, например, вы указываете, что время жизни объекта Department зависит от времени жизни объекта User.Вы также указываете целочисленные отношения между пользователями и отделами, где пользователь представляет собой совокупность отделов.Я думаю, что все наоборот.Я также подозреваю, что время жизни пользователя не зависит от времени жизни отдела, так как пользователь обычно может менять отделы.Таким образом, алмаз агрегации (белый), вероятно, является правильным, и он должен быть в конце Департамента.

Точно так же у меня возникли проблемы с пониманием ваших двух других композиционных ассоциаций.

Answer 2

Вот несколько выводов:

• Пользователь-> Логин: Это не обобщение.Пользователь не логин.С ним может быть связана некоторая информация для входа.Так что это будет ассоциация.
• Аналогично для предложения-> Статус предложения.Но здесь это зависимость, так как вы не будете создавать объект перечисления.Вы просто используете его для ввода атрибута.
• То же самое для User-> Gender / RoleUser.Обе являются зависимостями.

Есть также несколько проблем проектирования.Но здесь YMMV слишком много.Наличие пользователем реализации userLogin (), по крайней мере, сомнительно.Должна быть система безопасности, которая проверяет логин пользователя.Так почему логин имеет loginStatus ()?Однако дизайн здесь не обсуждается.

Что касается класса / ERD: они похожи, но не одинаковы.UML имеет более широкую область применения, в то время как ERD фокусируется исключительно на базах данных.Таким образом, все атрибуты * _id в ваших классах основаны на дизайне базы данных.Дизайн класса в этом состоянии очень ориентирован на базы данных.В MDA он может быть получен из PIM в PSM (то есть из абстрактного представления в специфичное для БД).