Хочу предложить вниманию участников форума статью, представляющую нотацию для ORM диаграмм. Она основана на Hibernate и ActiveRecord подходах к ORM, а так же UML диаграмме классов и Data Structure Diagram для RDB таблиц.
Статья на английском языке.

Это вводная статья, состоит из описания базовых конструкций и трех views.

Секции:
— Problem
— Solution — основные элементы нотации и views
— Tools
— Conclusion

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

Ссылка на zip архив pdf файла, на сайте uml2.ru:
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&action=dlattach;topic=148.0;attach=188

Здравствуйте, cosmicdustman, Вы писали:

C>Хочу предложить вниманию участников форума статью, представляющую нотацию для ORM диаграмм. Она основана на Hibernate и ActiveRecord подходах к ORM, а так же UML диаграмме классов и Data Structure Diagram для RDB таблиц.
C>Статья на английском языке.

C>Это вводная статья, состоит из описания базовых конструкций и трех views.

C>Секции:
C>- Problem
C>- Solution — основные элементы нотации и views
C>- Tools
C>- Conclusion

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

Мне после прочтения не стало понятно для чего нужна еще одна нотация.
Я могу, опираясь на свой опыт с PowerDesigner(PD), кое что описать.
В статье говорится про то что тяжеловато из объектной модели(OOM-object oriented model) переходить к модели БД (PDM — phisical data model)
В PD, как в прочем и в других case существует концептуальная модель (CDM). При проекте "c нуля" аналитику удобней и правильней создать CDM, а затем параллельно на основе CDM сгенерировать и работать с OOM и PDM.
Если не нравится CDM, то есть analisys OOM суть которой примерно таже, но вы используете UML-нотацию.
Касательно маппинга/ORM то это расширения моделей. Имхо, незачем нагромождать еще один дополнительный тип модели со своей нотацией. Это было бы контрпродуктивно.
В PD существует возможность создавать расширения модели на основе extended attributes, которые могут иметь любой тип используемый в PD, будь то класс или таблица, или список значений и т.п.
Как раз с помощью подобных расширений+mapping editor и сделана в PD возможность генерации кода для Hibernate/NHibernate/ADO.NET
В ранних версиях, когда еще расширения для маппинга не поставлялись с PD, ничто не мешало людям, создавать собственные гибкие генераторы на основе моделей:
Разработка на основе моделей (Model Driven Development) с примерами использования

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

Здравствуйте, снежок, Вы писали:

С>Здравствуйте, cosmicdustman, Вы писали:

C>>Хочу предложить вниманию участников форума статью, представляющую нотацию для ORM диаграмм. Она основана на Hibernate и ActiveRecord подходах к ORM, а так же UML диаграмме классов и Data Structure Diagram для RDB таблиц.
C>>Статья на английском языке.

C>>Это вводная статья, состоит из описания базовых конструкций и трех views.

C>>Секции:
C>>- Problem
C>>- Solution — основные элементы нотации и views
C>>- Tools
C>>- Conclusion

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

С>Мне после прочтения не стало понятно для чего нужна еще одна нотация.
С>Я могу, опираясь на свой опыт с PowerDesigner(PD), кое что описать.
С>В статье говорится про то что тяжеловато из объектной модели(OOM-object oriented model) переходить к модели БД (PDM — phisical data model)
С>В PD, как в прочем и в других case существует концептуальная модель (CDM). При проекте "c нуля" аналитику удобней и правильней создать CDM, а затем параллельно на основе CDM сгенерировать и работать с OOM и PDM.
С>Если не нравится CDM, то есть analisys OOM суть которой примерно таже, но вы используете UML-нотацию.
С>Касательно маппинга/ORM то это расширения моделей. Имхо, незачем нагромождать еще один дополнительный тип модели со своей нотацией. Это было бы контрпродуктивно.

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

С>В PD существует возможность создавать расширения модели на основе extended attributes, которые могут иметь любой тип используемый в PD, будь то класс или таблица, или список значений и т.п.
С>Как раз с помощью подобных расширений+mapping editor и сделана в PD возможность генерации кода для Hibernate/NHibernate/ADO.NET

mapping editor — решает лишь частично проблему не идеальной ORM, он не предполагает нотации, для диаграммного представления ORM.

С>В ранних версиях, когда еще расширения для маппинга не поставлялись с PD, ничто не мешало людям, создавать собственные гибкие генераторы на основе моделей:

Генератор тем более не решает проблемы, а скорее ее создает, если мы не говорим о генераторе с нотацией 8-).

С>Разработка на основе моделей (Model Driven Development) с примерами использования

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

Хочу отметить, что я предлагаю нотацию, а не инструмент, хотя проблема уходит корнями в несовершенство существующих инструментов, однако без соответствующей нотации, не решается.

Здравствуйте, снежок, Вы писали:

С>p/s/
С>я против дополнительных нотаций, а также против дополнительных инструментов, которые в конечном итоге не покроют моих нужд, так как все модели должны быть тесно интегрированы между собой в используемом case.

Согласен, но данная нотация не лишняя и логично дополняет существующие и покрывает более полно разработку ПО.

Здравствуйте, снежок, Вы писали:

С>p/s/
С>я против дополнительных нотаций, а также против дополнительных инструментов, которые в конечном итоге не покроют моих нужд, так как все модели должны быть тесно интегрированы между собой в используемом case.

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