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

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

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


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

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



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



Попробовал в EA формировать модели, очень все удобно, но нельзя сделать две вещи:
Не могли бы указать версию ЕА?

Цитировать
1) Установить связь сущности к самой себе
Можно, это типичное действие.

Цитировать
2) На связи задать дополнительные атрибуты, которые ее характеризуют (период времени, степень участия и т.д.)
Этого нельзя сделать в нотации информационного инжиниринга. Для этого можно использовать класс ассоциации (на диаграммах классов)

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

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



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

Я считаю, что диаграмма классов делается все таки на более позднем этапе разработки, уже когда от логической модели БД переходят к ее физической реализации.
« Последнее редактирование: 20 Ноября 2014, 14:39:41 от Humbert »



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


http://www.edrawsoft.com/Martin-ERD.php
« Последнее редактирование: 20 Ноября 2014, 14:34:09 от Humbert »



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

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



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



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

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

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

Вполне допускаю, что если системный аналитик подключается на более ранней стадии, или вообще БА и СА - один человек , то использование двух нотаций может показаться избыточным.   
 
« Последнее редактирование: 25 Ноября 2014, 23:55:52 от Humbert »



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

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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19