Который должен быть создан первая Схема ER ИЛИ Диаграмма классов?
Самый первый шаг я создал DFD. Затем я шел дальше для создания Диаграммы классов. И при выполнении этого я чувствовал, что должен создать схему ER сначала. Как было много деталей, которые не могли быть получены в Диаграмме классов. Так, мой вопрос я должен создать ERD первые ИЛИ Диаграммы классов?
Ваши ценные вклады являются ценившими парнями!!! благодарит читать
4 ответа
При моделировании, Я склонен мыслить категориями построения диаграмм в том порядке, который для меня наиболее понятен в данный момент. Иногда это сначала диаграмма классов, иногда диаграмма сущности-отношения, иногда даже диаграмма последовательности. Главное помнить, что вы пытаетесь понять вещи и записать их так, чтобы другие люди тоже могли их понять; Беспокойство о том, как лучше всего упорядочить свои мысли, не так полезно, как просто приступить к этому и записать те части, которые вы понимаете .
[EDIT]: FWIW, я также склонен начинать моделирование на бумаге или доске и переключаюсь на использование компьютера только тогда, когда я приближаюсь к тому, что я понять, что происходит. (Думаю, мне просто не нравится рисовать на компьютерах.) Ключ в том, что моделирование - это понимание, а не (очень) компьютеры.
ОО пуристы обычно сначала создают диаграмму классов. Люди с опытом работы с базами данных сначала создают диаграмму ER и «выводят» из нее диаграмму классов (этот подход не одобряется пуристами OO)
. Я предпочитаю гибридный подход.
Сначала определите сущности. Это должно быть одинаково как с точки зрения базы данных, так и с точки зрения приложения (классов).
После того, как вы согласовали сущности на высоком уровне, переходите к диаграмме классов и диаграмме ER в параллельных направлениях - потому что «отношения» различны в каждом из них. (Если вы единственный, кто работает над ними, то сначала начните с диаграммы классов, а затем с ERD. Но сначала определите уполномоченных).
На мой взгляд, сущности высокого уровня должны быть одинаковыми как в базе данных, так и в приложении (Java / C # ...). И работать с общей базой очень легко, особенно если над разными частями (классами, базой данных) работают разные люди.
Я бы сказал, что это действительно зависит от вашего приложения. & Я немного знаю UML, и я знаю, что вы можете моделировать множественность отношений, а также первичные ключи, просто используя стандартные диаграммы классов UML, поэтому часто диаграммы классов достаточно. Мне нравится начинать с диаграммы классов, потому что мне нравится использовать объектно-ориентированный анализ и дизайн, варианты использования, реализации вариантов использования и аналитические классы. С другой стороны, хороший дизайн базы данных требует нормализации, а иногда и денормализации, различных оптимизаций для запросов данных ... Но для этого сначала мне нужно знать, что я буду запрашивать и, возможно, как. Я лично вижу реляционную часть большинства приложений просто как механизм хранения, я думаю о системе с точки зрения объектно-ориентированного программирования. Это особенно полезно, например, с Ruby on Rails, который благодаря шаблону Active Record полностью абстрагируется от реляционной модели, поэтому мне не нужно моделировать дважды.
Диаграммы ER плохи как начало - потому что они содержат МЕНЬШЕ информации, чем диаграмма объектов, которая включает намного больше информации о методах объектов и деревьях наследования - оба элемента диаграмма ER будет пропускать.
Таким образом, вам лучше начать с иерархии объектов (диаграммы классов), а затем перейти к отображению вещей;)