Различия между концептуальной диаграммой классов UML и ERD?

Если я создам концептуальную диаграмму классов, такую, что каждый класс захватывает " имя " и "атрибуты", но не "операции", разве я в основном не создал то, что иначе считалось бы ERD? Я пытаюсь понять, в чем разница между созданием концептуальной диаграммы классов, как я описал, и называнием ее ERD? Если это все еще два разных животных, может кто-нибудь объяснить, в чем разница?

15
class-diagram er-diagram uml

5 ответов

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

правда, они выглядят очень разными, на графическом уровне, так как они используют разные символы для элементов, но "семантика" очень похожи. Они оба допускают наследование (опять же, я говорю об EER), N-арные ассоциации, классы ассоциаций,...

4

диаграмма классов содержит только классы в вашей объектной модели с возможными связями / отношениями, соединяющими элементы диаграммы. Однако эти ссылки не обязательно соответствуют физическим отношениям, как на диаграмме ERD, но вместо этого они представляют логические связи.

диаграмма классов - это просто объектная модель вашего приложения и не содержит никакой информации о персистентности. Когда вы думаете о диаграмме классов, забудьте о базе данных или любой другой другое хранилище вы можете использовать.

диаграмма ERD с другой стороны, является диаграммой персистентности, которая отображает сущности (таблицы), существующие в (чаще всего) реляционной базе данных. Он также отображает физические отношения (и мощности) между этими таблицами и всей другой информацией, относящейся к базе данных. Диаграмма ERD иногда может выглядеть аналогично диаграмме классов, но это не означает, что она совпадает с диаграммой классов.

18

Это зависит от ситуации, когда вам может не понравиться делать ER-D. Но представьте, что у вас есть отдельный слой данных, где обрабатывается логика данных. В этом случае многие детали данных не должны совместно использоваться с прикладным уровнем. И диаграмма классов не должна выходить за пределы уровня приложения. Я должен подчеркнуть, что обе диаграммы не равны. И есть ситуации, когда вам нужно сделать оба, в основном в многоуровневой архитектуре, и есть ситуации, когда вы можете просто используйте диаграмму классов; например, одноуровневое приложение.

Я решительно поддерживаю мнение, что диаграмма классов не отменяет диаграмму E-R.

1

диаграммы классов дизайна сделаны из концептуальных моделей и диаграмм совместной работы. Диаграммы классов дизайна включают:

  1. классы, ассоциации и атрибуты
  2. методы
  3. типы атрибутов
  4. мореходности
  5. зависимости
1

диаграммы ER, которые я видел (чаще всего Erwin IE notation), были сосредоточены на дизайне базы данных. Они связаны с первичными ключами, внешними ключами, имеют неназванные отношения и обычно не имеют обобщения / специализации.

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

1