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