Что должно быть создано в первую очередь ER Diagram OR Class Diagram?

Question

Самым первым шагом я создал DFD. Затем я перешел к созданию диаграммы классов. И при этом я чувствовал, что должен сначала создать диаграмму ER. Поскольку было много деталей, которые не могли быть зафиксированы в диаграмме классов. Итак, мой вопрос, я должен сначала создать ERD ИЛИ диаграммы классов?

Ваши ценные материалы ценятся, ребята !!! спасибо за чтение

Answer 1

При моделировании я склонен мыслить в терминах создания диаграмм в любом порядке, который имеет для меня наибольшее значение в то время. Иногда это сначала диаграмма классов, иногда диаграмма отношений сущностей, иногда даже диаграмма последовательности. Главное, что нужно помнить, это то, что вы пытаетесь понять вещи и записать их, чтобы другие люди могли их понять; беспокоиться о том, каков наилучший способ упорядочить свои мысли, далеко не так полезно, как просто взяться за дело и написать те части, которые вы делаете понимаете.

[РЕДАКТИРОВАТЬ]: FWIW, я также, как правило, начинаю свое моделирование на бумаге или белой доске и переключаюсь на использование компьютера только тогда, когда я подхожу ближе к тому, что понимаю. (Полагаю, я просто не люблю рисовать на компьютерах.) Главное в том, что моделирование - это понимание, а не (очень) о компьютерах.

Answer 2

ОО-пуристы склонны сначала делать диаграмму классов. Люди с опытом работы с базой данных сначала делают диаграмму ER и «выводят» диаграмму классов из этого (этот подход не одобряется пуристами ОО)

Я предпочитаю гибридный подход.

Сначала определите сущности. Это должно быть одинаково как с точки зрения базы данных, так и приложения (классов).

После того, как вы согласовали сущности на высоком уровне, переходите к диаграмме классов и диаграмме ER в параллельных направлениях - потому что «отношения» различны в каждой. (Если вы являетесь единственным человеком, работающим над ними, то сначала начните с диаграммы классов, а затем с ERD. Но сначала определите уполномоченного).

По моему мнению, сущности высокого уровня должны быть одинаковыми как в базе данных, так и в приложении (Java / C # ...). И очень просто перейти к общей базе, особенно если над разными частями (классы, база данных) работают разные люди.

Answer 3

Я бы сказал, что это действительно зависит от вашего приложения. & Я немного знаю об UML, и я знаю, что вы можете моделировать множественность отношений, а также первичные ключи, просто используя стандартные диаграммы классов UML, поэтому часто достаточно диаграмм классов. Мне нравится начинать с диаграммы классов, потому что я люблю использовать объектно-ориентированный анализ и проектирование, варианты использования, реализации сценариев использования и аналитические классы. С другой стороны, хороший дизайн базы данных требует нормализации, а иногда и денормализации, различных оптимизаций для запросов данных ... Но для этого сначала мне нужно знать, к чему я буду обращаться и, возможно, как. Я лично рассматриваю реляционную часть большинства приложений просто как механизм хранения, я думаю о системе с точки зрения объектно-ориентированного программирования. Это особенно полезно, например, для Ruby on Rails, который благодаря шаблону Active Record полностью абстрагируется от реляционной модели, поэтому мне не нужно моделировать дважды.

Answer 4

Диаграммы ER отстойны как начало - потому что они содержат МЕНЬШУЮ информацию, чем диаграмма объекта, которая включает в себя намного больше информации о методах объектов и деревьев наследования - оба элемента, которые диаграмма ER пропустит.

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