Различия между концептуальной диаграммой классов UML и ERD?
Если я создаю концептуальную диаграмму классов, чтобы каждый класс захватывал "имя" и "атрибуты", но не "операции", не создал ли я в основном то, что в противном случае считалось бы ERD? Я пытаюсь понять, что такое различия между созданием диаграммы концептуального класса, как я описал, и называя ее ERD? Если это все еще два разных животных, может кто-нибудь объяснить, что это за различия?
Ответы
Ответ 1
Мало различий в выразительности обоих (если мы просто сосредоточимся на атрибутах, классах и ассоциациях), если вы используете диаграммы Extended Entity Relationship (наиболее распространенный случай в настоящее время)
Правда, они выглядят совсем по-другому на графическом уровне, так как они используют разные символы для элементов, но "семантика" очень похожа. Они оба позволяют наследование (опять же, я говорю об EER), n-арные ассоциации, классы ассоциаций,...
Ответ 2
Диаграмма классов содержит только классы в вашей объектной модели с возможными связями/отношениями, соединяющими элементы диаграммы. Однако эти ссылки не обязательно соответствуют физическим отношениям, как на диаграмме ERD, но вместо этого они представляют собой логические соединения.
Диаграмма классов - это всего лишь объектная модель вашего приложения и не содержит никакой информации, связанной с сохранением. Когда вы думаете о диаграмме классов, забудьте о базе данных или любом другом хранилище, которое вы можете использовать.
Диаграмма ERD на другой стороне - это диаграмма, зависящая от сохранения, которая отображает сущности (таблицы), существующие в (чаще) реляционной базе данных. Он также отображает физические отношения (и мощности) между этими таблицами и всей другой информацией, специфичной для базы данных. Диаграмма ERD иногда может быть похожа на диаграмму классов, но это не значит, что она аналогична диаграмме классов.
Ответ 3
Это зависит от ситуации, когда вам может не нравиться делать ER-D. Но представьте, если у вас есть отдельный слой данных, где обрабатывается логика данных. В этом случае многие детали данных не должны использоваться совместно с прикладным уровнем. И диаграмма классов не должна выходить за пределы прикладного уровня. Я должен подчеркнуть, что обе диаграммы не равны. И бывают ситуации, когда вам нужно делать оба, главным образом в многоуровневой архитектуре, и есть ситуации, когда вы можете просто использовать диаграмму классов; например одноуровневое приложение.
Я решительно выступаю за то, что диаграмма классов не отменяет диаграмму E-R.
Ответ 4
Диаграммы классов конструкций сделаны из концептуальной модели и диаграмм совместной работы.
Диаграммы классов проектирования включают в себя:
- Классы, ассоциации и атрибуты
- Методы
- Типы атрибутов
- Судоходность
- Зависимости
Ответ 5
Диаграммы ER, которые я видел (чаще всего ERWin IE notation), были сосредоточены на дизайне для базы данных. Они связаны с первичными ключами, внешними ключами, имеют неназванные отношения и обычно не имеют обобщения/специализации.
Хорошая диаграмма концептуального класса UML, с другой стороны, не связана с ключами, отражает проблемную область и имеет свойства конца ассоциации, которые хотя бы намекают на семантику того, почему все связано. Это помогает сообщать домену более молодым разработчикам, поэтому им не нужно гадать.