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