Формирую модель Сущность-связь в EA. Обычно такие модели делал в Visio в нотации Питера Чена. Полная нотация подразумевает, что атрибуты могут иметь не только сущности, но и связи. Такой поход позволял избавиться от описания множества технических таблиц и ввода новых сущностей.

Попробовал в EA формировать модели, очень все удобно, но нельзя сделать две вещи:

1) Установить связь сущности к самой себе
2) На связи задать дополнительные атрибуты, которые ее характеризуют (период времени, степень участия и т.д.)


Соответственно связи приходится описывать как сущности, что резко снижает читаемость диаграмм

Есть ли возможность настроить в EA поддержку полной нотации Чена? 

Нашел способ - отразить атрибуты связи позволяют N-арные ассоциации.

Попробовал в EA формировать модели, очень все удобно, но нельзя сделать две вещи:

Не могли бы указать версию ЕА?

1) Установить связь сущности к самой себе

Можно, это типичное действие.

2) На связи задать дополнительные атрибуты, которые ее характеризуют (период времени, степень участия и т.д.)

Этого нельзя сделать в нотации информационного инжиниринга. Для этого можно использовать класс ассоциации (на диаграммах классов)

Соответственно связи приходится описывать как сущности, что резко снижает читаемость диаграмм

Мне кажется, если у вас много таких связей, то у вас не слишком усложнена модель

Есть ли возможность настроить в EA поддержку полной нотации Чена? 

Думаю нет, поскольку нотация Чена используется редко. Стандартом все-таки является или IDEF1x или IE. А чем вас не устраивает диаграмма классов?

Не могли бы указать версию ЕА?

11.04

Можно, это типичное действие.

Да, спасибо, разобрался. Унарные связи и впрямь поддерживаются - просто лучше сначала привязать связь к другой сущности, а потом уже к самой себе

Этого нельзя сделать в нотации информационного инжиниринга. Для этого можно использовать класс ассоциации (на диаграммах классов)

Да, согласен. Нотацией Чена не предусмотрено специальное отражение ассоциативной сущности ,  с ее использованием выразительность диаграммы резко возрастает

Мне кажется, если у вас много таких связей, то у вас не слишком усложнена модель

Прошу прощения, не совсем Вас понял. Я как раз и добиваюсь компактного описания сложной модели.

Думаю нет, поскольку нотация Чена используется редко. Стандартом все-таки является или IDEF1x или IE. А чем вас не устраивает диаграмма классов?

На этапе концептуального проектирования не очень хочется навязывать разработчикам способ физической реализации связи "многие ко многим". У IDEF1x много видов "гусиных лапок" в которые трудно вчитываться. В ней так же очень плохо читаются "длинные связи", так как информация о мощности может находится только в месте примыкания соединительной линии к сущности.  Мне полная нотация Чена нравилась именно возможностью отражать наличие у связей собственных атрибутов (как я уже сообщал выше n-арная ассоциация тоже замечательно с этим справляется). Еще мне показалась нотация Чена более выигрышной именно при использовании EA - когда есть общий репозитарий сущностей , связей и атрибутов, на базе которого можно сформировать столько ERD, сколько необходимо, причем применительно к конкретной задаче. Стоит вытащить на диаграмму две связанные сущности, и все связи между ними вытащатся сами собой. После Визио для меня это магия  

Я считаю, что диаграмма классов делается все таки на более позднем этапе разработки, уже когда от логической модели БД переходят к ее физической реализации.

По крайней мере стиль обозначения мощности связи взят именно его


http://www.edrawsoft.com/Martin-ERD.php

Я опечатался, лишнее не добавил слишком сложная. если много связей многие-ко-многим. Это тоже некое евангелие: одни считают связи многие-ко-многим существющими, другие определяют как неспецифическими.

Потому диаграммы классов вполне хороши для использования - одна нотация, разные уровни представления. Впрочем о вкусах не спорят.

Я считаю, что диаграмма классов делается все таки на более позднем этапе разработки, уже когда от логической модели БД переходят к ее физической реализации.

Почему вы так считаете?

Почему вы так считаете?

ERD удобно использовать при переходе от моделирования БП в BPMN к системному проектированию. При соблюдении определенного соглашения по моделированию из BPMN диаграммы можно получить список объектов и хранилищ с ассоциированными с ними активностями. Соответственно такой список является хорошим "черновым" материалом для ERD. Точно так же хорошим черновым материалом для выделения акторов и вариантов использования является список исполнителей (в Bizaggi  в каждой активности можно указать ее ресурс) с перечнем активностей.

 А диаграммы классов появляются уже на этапе чистового системного проектирования.Еще ER- модель хороша тем, что в принципе ее может построить бизнес-аналитик (кто строит BPMN и IDEF0, тот ER тоже построит ), особенно при построении моделей AS IS.  А диаграмма классов совсем уж системная вещь, за которую чистый бизнес-аналитик не возьмется.

Вполне допускаю, что если системный аналитик подключается на более ранней стадии, или вообще БА и СА - один человек , то использование двух нотаций может показаться избыточным.   
 

ERD удобно использовать при переходе от моделирования БП в BPMN к системному проектированию. При соблюдении определенного соглашения по моделированию из BPMN диаграммы можно получить список объектов и хранилищ с ассоциированными с ними активностями. Соответственно такой список является хорошим "черновым" материалом для ERD. Точно так же хорошим черновым материалом для выделения акторов и вариантов использования является список исполнителей (в Bizaggi  в каждой активности можно указать ее ресурс) с перечнем активностей.

Здесь вы говорите не о том чем Вас более привлекает сама нотация, а о том откуда хорошо брать информацию для построения диаграммы. Ту же информацию можно использовать для диаграммы классов UML. Тогда чем ERD лучше?

А диаграммы классов появляются уже на этапе чистового системного проектирования.

А что ей мешает появиться на этапе бизнес- или системного анализа?

Еще ER- модель хороша тем, что в принципе ее может построить бизнес-аналитик (кто строит BPMN и IDEF0, тот ER тоже построит ), особенно при построении моделей AS IS.

Спорное утверждение. В нотации Чена и в вороньих лапках больше элементов, поэтому научиться строить диаграммы классов UML, по моему, сложнее.

А диаграмма классов совсем уж системная вещь, за которую чистый бизнес-аналитик не возьмется.

Что придаёт ей такую системность, что она становится совсем уж системной вещью?

Вполне допускаю, что если системный аналитик подключается на более ранней стадии, или вообще БА и СА - один человек , то использование двух нотаций может показаться избыточным.

Я считаю что в большинстве случаев использование одной нотации лучше. Даже если са и ба это разные люди, им будет легче понимать друг друга, создавать трассировки между моделями и т.п.

Здесь вы говорите не о том чем Вас более привлекает сама нотация, а о том откуда хорошо брать информацию для построения диаграммы. Ту же информацию можно использовать для диаграммы классов 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 между сущностями и классами.

Существует некоторый "технический слой" при описании БП - БД существующей системы (или нескольких систем). 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 и прочим, то аналитик не занимается даже выделением ключевых сущностей, не говоря уже о построении диаграммы с участием таких классов. А вообще люблю одну цитату: "Чем занимается аналитик? Чем поручат заниматься, тем и занимается"

А  трассировку можно делать между любыми моделями и разность нотаций не является ограничением.

Можно конечно, только в таком случае придётся знать две разные нотации, а не одну, что усложнит для многих понимание обеих моделей.

Диаграмму классов (со стереотипами Table) получить очень легко:
http://www.sparxsystems.com/enterprise_architect_user_guide/9.0/database_engineering/importdatabaseschemafromod.html

Почти убедили - это меняет дело! Если есть удобный инструментарий по построению ДК из БД, то можно будет  попробовать и ДК. До этого сталкивался только с ДК полученными из кода. Для меня они были абсолютно нечитаемыми...

Не согласен. Если на ранних стадиях использовать только ассоциации, то у диаграммы классов останутся и другие отличия от ERD.

Какие именно? Ну если не брать нотацию Чена, а Crow's Foot или IDEF1X - где нет ромбиков на связях и атрибуты внутри прямоугольников. 

Не согласен.
1. Каким образом, к примеру, тестировщик и программист в конце проекта при исправлении последней ошибки реализации (перед поставкой) должны использовать бизнес- или системный анализ? Даже если это итеративная разработки, бизнес-аналитик и системный аналитик уже на другом проекте.
2. Если в водопадной модели разработки дело дошло до проектирования, то часто аналитиков уже не заставишь работать в этом проекте. Документы написаны и утверждены, возможно за них уже даже получена оплата от заказчика. Бизнес-анализ или системный анализ? Только за дополнительные деньги:)

Это все-таки особенности ведения разработок в стиле "поматросил и бросил", когда БА и СА используются в качестве главных умников для получения контракта или для перехода от предпроектного обследования к более денежному этапу разработки:)

А вот на домашних разработках ответственным за тестирование и  внедрение частенько становится именно БА. Ну или как минимум он осуществляет авторский надзор. Ну и нормальный РП все-таки предусмотрит некоторое время БА и СА для консультирование разработчиков в процессе и для актуализации моделей в процессе ведения проекта. Понятно, что в идеале нужно выдавать документ, не нуждающийся в комментариях, но такое требование делает проект еще более дорогим. Ну и реалии таковы, что изменения БП происходят за периоды времени, сопоставимые с разработкой.

Какие именно? Ну если не брать нотацию Чена, а Crow's Foot или IDEF1X - где нет ромбиков на связях и атрибуты внутри прямоугольников.

К примеру те самые вороньи лапы. Если и их убрать, то действительно сложно будет различить нотации. При дальнейшей разработке лапы, ромбы и прочие "части тела" будут нарастать и тогда диаграмма окажется менее читаемой и универсальной (на мой взгляд).

Это все-таки особенности ведения разработок в стиле "поматросил и бросил", когда БА и СА используются в качестве главных умников для получения контракта или для перехода от предпроектного обследования к более денежному этапу разработки:)

Вы говорили про этапы разработки. Когда говорят про этапы и стадии проекта в целом, то обычно подразумевают "Водопад", а в нём именно так и происходит, "поматросил и бросил". Даже если разработка ведётся в итерационной методологии, то предусматривается постепенное освобождение аналитиков со снижением их загруженности по мере приближения к концу проекта. Какой бизнес-анализ может применяться при развертывании системы в продуктивной среде Клиента перед подписанием акта сдачи-приемки?

Ну и реалии таковы, что изменения БП происходят за периоды времени, сопоставимые с разработкой.

Ранее, как я понял, вы однозначно утверждали, что анализ применяется на всех этапах разработки. Теперь, как я понял, мы договорились, что это происходит, если соблюдены некоторые доп. условия.