Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Sparx => Тема начата: Humbert от 18 Ноября 2014, 13:29:09
-
Формирую модель Сущность-связь в 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 - где нет ромбиков на связях и атрибуты внутри прямоугольников.
К примеру те самые вороньи лапы. Если и их убрать, то действительно сложно будет различить нотации. При дальнейшей разработке лапы, ромбы и прочие "части тела" будут нарастать и тогда диаграмма окажется менее читаемой и универсальной (на мой взгляд).
Это все-таки особенности ведения разработок в стиле "поматросил и бросил", когда БА и СА используются в качестве главных умников для получения контракта или для перехода от предпроектного обследования к более денежному этапу разработки:)
Вы говорили про этапы разработки. Когда говорят про этапы и стадии проекта в целом, то обычно подразумевают "Водопад", а в нём именно так и происходит, "поматросил и бросил". Даже если разработка ведётся в итерационной методологии, то предусматривается постепенное освобождение аналитиков со снижением их загруженности по мере приближения к концу проекта. Какой бизнес-анализ может применяться при развертывании системы в продуктивной среде Клиента перед подписанием акта сдачи-приемки?
Ну и реалии таковы, что изменения БП происходят за периоды времени, сопоставимые с разработкой.
Ранее, как я понял, вы однозначно утверждали, что анализ применяется на всех этапах разработки. Теперь, как я понял, мы договорились, что это происходит, если соблюдены некоторые доп. условия.