Здесь вы говорите не о том чем Вас более привлекает сама нотация, а о том откуда хорошо брать информацию для построения диаграммы. Ту же информацию можно использовать для диаграммы классов UML.
Существует некоторый "технический слой" при описании БП - БД существующей системы (или нескольких систем). ERD по ним можно получить сразу же, а вот диаграмму классов так просто не получишь - даже если есть исходники и возможность осуществить реверс-инжениринг, выделить в полученных ДК реальной системы предметные классы весьма затруднительно.
Тогда чем ERD лучше?
На мой взгляд на начальном этапе DC избыточна - слишком много видов связей , которые на начальном этапе очень тяжело осознавать. Можно для простоты ограничить количество используемых видов связей, но тогда это будет ERD
А почему просто не использовать ERD ?
В этом плане мне понравился подход к ERD, заложенный в EA : всегда можно дополнить ERD расширениями - (disjointed и overlapping, n- арные сущности и т.д.), если они осознаются или нужны для оформления. А не осознаются, или нет необходимости их использования, то и не используешь
А что ей мешает появиться на этапе бизнес- или системного анализа?
Бизнес- и системный анализ - это все таки методологии, а не этапы. По идее эти методологии используются на всех этапах разработки.
Если брать начальный этап, то можно строить и ERD и DС - вопрос удобства и привычки. А вот на этапе конструирования естественно необходима DС. Но она и строится уже по другому - от абстрактных классов, и связи нужно уже точно специфицировать, и методы описывать. То есть это уже совсем другая диаграмма классов.
Спорное утверждение. В нотации Чена и в вороньих лапках больше элементов, поэтому научиться строить диаграммы классов UML, по моему, сложнее.
В нотации Чена элементов очень мало - сущности, связи и атрибуты (причем атрибуты может иметь и сама связь). Независимые , зависимые, ассоциативные сущности и пр. появились в более поздних нотациях.
Мне нотация Чена всегда была удобна тем, что в отличии от IDEF1X атрибуты рисуются отдельными овалами. То есть по мере накопления информации очень легко переводить сущности в атрибуты и наоборот - это приходится делать довольно много, если работаешь с малоизученной предметной областью и есть много операций синтеза моделей из предсхем в общую ERD. При этом вид диаграммы меняется не так кардинально, как при вводе новой сущности в IDEF1X. Хотя первоначально диаграмма в нотации Чена более громоздка.
Что придаёт ей такую системность, что она становится совсем уж системной вещью?
Ну не все бизнес-аналитики знают и даже имеют представление об OOP. Более того, существует мнение, что опыт программиста для BA вреден:). А соответственно специфицировать связи между классами ему затруднительно. А вот с базами работать приходилось практически всем. А для системного аналитика как правило характерно обратное.
Понятно, что и там и там есть исключения.
Я считаю что в большинстве случаев использование одной нотации лучше. Даже если са и ба это разные люди, им будет легче понимать друг друга, создавать трассировки между моделями и т.п.
Я думаю, что любой СА ERD поймет с легкостью. Достаточно спорно, нужно ли БА понимать DC - это все таки разработческая кухня, ему скорее понадобятся use case и test case.
А трассировку можно делать между любыми моделями и разность нотаций не является ограничением. С этой точки зрения трассировка между "концептуальной" DC и "сконструированной" DC ничем не отличается от трассировки между ERD и "сконструированной" DC. Так что вопрос трассировки - это скорее вопрос инструментария, а не нотации. Кстати EA позволяет устанавливать trace между сущностями и классами.
Просмотр сообщений