Существует некоторый "технический слой" при описании БП - БД существующей системы (или нескольких систем). ERD по ним можно получить сразу же, а вот диаграмму классов так просто не получишь...
Диаграмму классов (со стереотипами Table) получить очень легко:
http://www.sparxsystems.com/enterprise_architect_user_guide/9.0/database_engineering/importdatabaseschemafromod.html...- даже если есть исходники и возможность осуществить реверс-инжениринг, выделить в полученных ДК реальной системы предметные классы весьма затруднительно.
Выделить их в полученной ERD намного легче?
На мой взгляд на начальном этапе DC избыточна - слишком много видов связей , которые на начальном этапе очень тяжело осознавать. Можно для простоты ограничить количество используемых видов связей, но тогда это будет ERD 
Не согласен. Если на ранних стадиях использовать только ассоциации, то у диаграммы классов останутся и другие отличия от ERD.
А почему просто не использовать ERD ?
В этом плане мне понравился подход к ERD, заложенный в EA : всегда можно дополнить ERD расширениями - (disjointed и overlapping, n- арные сущности и т.д.), если они осознаются или нужны для оформления. А не осознаются, или нет необходимости их использования, то и не используешь
В диаграмму классов точно так же можно в нужные моменты включать дополнительные элементы.
Бизнес- и системный анализ - это все таки методологии, а не этапы.
Это всё-таки не методологии:) Сами эти понятия не подразумевают наличие обязательных атрибутов методологии. В разных источниках им даются определения типа "набор задач и техник", "дисциплина", "область знаний", но не "методология".
По идее эти методологии используются на всех этапах разработки.
Не согласен.
1. Каким образом, к примеру, тестировщик и программист в конце проекта при исправлении последней ошибки реализации (перед поставкой) должны использовать бизнес- или системный анализ? Даже если это итеративная разработки, бизнес-аналитик и системный аналитик уже на другом проекте.
2. Если в водопадной модели разработки дело дошло до проектирования, то часто аналитиков уже не заставишь работать в этом проекте. Документы написаны и утверждены, возможно за них уже даже получена оплата от заказчика. Бизнес-анализ или системный анализ? Только за дополнительные деньги:)
В нотации Чена элементов очень мало - сущности, связи и атрибуты (причем атрибуты может иметь и сама связь). Независимые , зависимые, ассоциативные сущности и пр. появились в более поздних нотациях.
На мой вкус обозначение связей и сущностей с помощью отдельных графических элементов (ромбы/овалы) - это усложнение по сравнению с аналогичными текстовыми обозначениями диаграммы классов UML.
Хотя первоначально диаграмма в нотации Чена более громоздка.
Этим она мне и не нравится.
Ну не все бизнес-аналитики знают и даже имеют представление об OOP. Более того, существует мнение, что опыт программиста для BA вреден:).
Бизнес-аналитику далеко не обязательно быть мастером ООАП чтобы уметь выделять сущности и строить между ними связи.
Далеко не все бизнес-аналитики (по наименованию должности) имеют представление о том, что такое бизнес-анализ. Это гораздо более серьёзный диагноз:)
А соответственно специфицировать связи между классами ему затруднительно.
Как минимум не более затруднительно, чем специфицировать связи между сущностями ERD.
Я думаю, что любой СА ERD поймет с легкостью. Достаточно спорно, нужно ли БА понимать DC - это все таки разработческая кухня, ему скорее понадобятся use case и test case.
Я думаю, что ERD не менее разработческая кухня, чем DC. Если верить RUP, OpenUP и прочим, то аналитик не занимается даже выделением ключевых сущностей, не говоря уже о построении диаграммы с участием таких классов. А вообще люблю одну цитату: "Чем занимается аналитик? Чем поручат заниматься, тем и занимается"
А трассировку можно делать между любыми моделями и разность нотаций не является ограничением.
Можно конечно, только в таком случае придётся знать две разные нотации, а не одну, что усложнит для многих понимание обеих моделей.
Просмотр сообщений