. Очень интересно услышать мнение уважаемого сообщества по этому вопросу.
10.08.05 11:44: Перенесено из 'Архитектура программного обеспечения'
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
. Очень интересно услышать мнение уважаемого сообщества по этому вопросу.
Вот этот абзац вызывает сильное неприятие:
Немного о DSL
Но сначала немного о DSL (о том, что такое UML, я думаю, знают практически все – на его маркетинг было потрачено очень много усилий). DSL (Domain Specific Languages) – это технология и методология, которую предлагает Microsoft в области моделирования. Суть DSL состоит в том, что в каждой предметной области стоит не пытаться использовать унифицированный язык моделирования, а вместо этого стоит создавать для каждой задачи зык моделирования и описания,
Этому, без сомнения, грамотному подходу очень много лет. Как минимум, столько же,
сколько Лиспу. И причем тут майкрософт?
dmz>Этому, без сомнения, грамотному подходу очень много лет. Как минимум, столько же, dmz>сколько Лиспу. И причем тут майкрософт?
Подходу — без сомнения. Думаю, что подход, заключающийся в ориентации на предметную облась, появился и раньше Лиспа. Я же говорю лишь о технологии и методологии DSL от Microsoft. И кстати, говорю, что это предлагает Microsoft, а не изобрел Microsoft. Что в этом заявлении некорректного?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
AL>Подходу — без сомнения. Думаю, что подход, заключающийся в ориентации на предметную облась, появился и раньше Лиспа. Я же говорю лишь о технологии и методологии DSL от Microsoft. И кстати, говорю, что это предлагает Microsoft, а не изобрел Microsoft. Что в этом заявлении некорректного?
Да, в общем, ничего. Формулировка просто немного провоцирующая.
dmz>Да, в общем, ничего. Формулировка просто немного провоцирующая.
Sorry, не было цели провоцировать На мой взгляд я там ничего некорректного не сказал. Тем более, что я говорил именно о реализации Microsoft подхода DSL.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
. Очень интересно услышать мнение уважаемого сообщества по этому вопросу.
Кстати, а где в голосовании DSL? Я, например, пользуюсь при каждлом удобном случае.
Есть технологии, полезность которых нуждается в постоянном доказательстве (UML) — то есть сомнительно,
а есть такие, которые трудно переоценить, когда начинаешь ими пользоваться.
Вообще, давно хотел написать статью про применение метапрограмирования / dsl, но руки не
доходят как-то.
dmz>Кстати, а где в голосовании DSL? Я, например, пользуюсь при каждлом удобном случае. dmz>Есть технологии, полезность которых нуждается в постоянном доказательстве (UML) — то есть сомнительно, dmz>а есть такие, которые трудно переоценить, когда начинаешь ими пользоваться.
Я не заводил. Цель этого голосования — понять, как используется UML.
dmz>Вообще, давно хотел написать статью про применение метапрограмирования / dsl, но руки не dmz>доходят как-то.
Статья была бы интересна и полезна, я как раз собираюсь про Microsoft DSL написать в блоге поподробнее. А вы смотрели на DSL от Microsoft? Какое мнение о них?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
AL>Статья была бы интересна и полезна, я как раз собираюсь про Microsoft DSL написать в блоге поподробнее. А вы смотрели на DSL от Microsoft? Какое AL>мнение о них?
Нет, не смотрел, да и наверное не будет такой возможности. Хотя, в общем, любопытно. По ссылкам пробежался —
но конкретных примеров не нашел — только объемистые статьи.
Хотя мне пока не кажется, что для того, что бы использовать DSL, нужны какие-то специальные средства.
C>А где-нибудь можно посмотреть спецификации DSL или примеры использования?
Да, здесь
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
По моему мнению, постановка вопросов в предложенном голосовании "Для чего и как вы используете UML?", изначально, некорректа.
- Для создания высокоуровневых диаграмм без привязки к коду.
Какие диаграммы имеются в виду? Use Case? (определяя scope проекта) Activity? (для бизнес-моделирования; визуализации, например, функциональных требований; описания высокоуровневых поведенческих характеристик архитектурного решения/концепции,....)
По мере изменения кода диаграммы устаревают, т.к. их лень обновлять. — это замечание не очень напоминает конструктивный вопрос. Если речь идет об актуализации той или иной диаграммы, вопрос мог бы звучать так "Обновляете ли Вы диаграммы для отражения изменившихся характеристик моделирумых объектов, сущностей, процессов?"
- Для создания высокоуровневых диаграмм без привязки к коду. Стараюсь вручную их обновлять по ходу проекта.
см. комментарии выше.
- Для однократной генерации кода.
см. выше. комментарий Впоследствии диаграммы и код рассинхронизируются. imho, крайне некорректен, так как это вопрос качества поддержки синхронизации кода и модели (если речь идет о коде) в конкретном инструментарии, обеспечивающем поддержку UML.
- Для постоянной генерации и обновления кода и reverse engineering диаграмм (возможно, с использованием инструментов постоянной синхронизации – 2-way tools). При этом код и диаграммы всегда синхронизированы.
2-way tools не то же самое, что reverse&forward engineering. Можно воспринимать модель как еще одно представление кода, которое работает с той же метамоделью кода (в VS.NET — CodeDOM). Ведь вроде так работает визуальный редактор форм? Чем UML-модель (если обсуждается модель, связанная с кодом) хуже?
Не стоит забывать об MDA, о таком понятии как мета-модель (которую, кстати, можно верифицировать, к которой можно обращаться с запросами через OCL, трансформировать в код через QVT и т.п....), профили и т.п.
По-моему мнению, изначально, в данном треде сформулировано некорректное позиционирование UML как комплекса средств связанных только с вопросами кодирования. Отсюда, веротяно, и попытка противопоставлять UML и DSL, хотя, по логике, они могут друг друга естественно дополнять (сейчас скажу ересь — трансформировать UML в DSL через механизмы MDA).
Необходимо четко разделять моделироване предметной области и проектирование. Первое — работа аналитика, второе — архитектора, разработчика и других технических специалистов. UML позволяет провести сквозную детализацию — от определения содержания (границ проекта — scope) до работы с кодом, через проектирование архитектуры.
Просто один пример — диаграммы классов могут использоваться:
1. для работы с набором классов (проектирование и разработка)
2. для объектов как экземпляров класса (проектирование)
3. для описания бизнес-сущностей и связей между ними (анализ)
Здравствуйте, Сергей Орлик, Вы писали:
СО>Приветствую, Александр!
СО>По моему мнению, постановка вопросов в предложенном голосовании "Для чего и как вы используете UML?", изначально, некорректа.
СО>- Для создания высокоуровневых диаграмм без привязки к коду.
СО>Какие диаграммы имеются в виду? Use Case? (определяя scope проекта) Activity? (для бизнес-моделирования; визуализации, например, функциональных требований; описания высокоуровневых поведенческих характеристик архитектурного решения/концепции,....)
СО>По мере изменения кода диаграммы устаревают, т.к. их лень обновлять. — это замечание не очень напоминает конструктивный вопрос. Если речь идет об актуализации той или иной диаграммы, вопрос мог бы звучать так "Обновляете ли Вы диаграммы для отражения изменившихся характеристик моделирумых объектов, сущностей, процессов?"
СО>- Для создания высокоуровневых диаграмм без привязки к коду. Стараюсь вручную их обновлять по ходу проекта.
СО>см. комментарии выше.
СО>- Для однократной генерации кода. СО>см. выше. комментарий Впоследствии диаграммы и код рассинхронизируются. imho, крайне некорректен, так как это вопрос качества поддержки синхронизации кода и модели (если речь идет о коде) в конкретном инструментарии, обеспечивающем поддержку UML.
СО>- Для постоянной генерации и обновления кода и reverse engineering диаграмм (возможно, с использованием инструментов постоянной синхронизации – 2-way tools). При этом код и диаграммы всегда синхронизированы.
СО>2-way tools не то же самое, что reverse&forward engineering. Можно воспринимать модель как еще одно представление кода, которое работает с той же метамоделью кода (в VS.NET — CodeDOM). Ведь вроде так работает визуальный редактор форм? Чем UML-модель (если обсуждается модель, связанная с кодом) хуже?
СО>Не стоит забывать об MDA, о таком понятии как мета-модель (которую, кстати, можно верифицировать, к которой можно обращаться с запросами через OCL, трансформировать в код через QVT и т.п....), профили и т.п.
СО>По-моему мнению, изначально, в данном треде сформулировано некорректное позиционирование UML как комплекса средств связанных только с вопросами кодирования. Отсюда, веротяно, и попытка противопоставлять UML и DSL, хотя, по логике, они могут друг друга естественно дополнять (сейчас скажу ересь — трансформировать UML в DSL через механизмы MDA).
СО>Необходимо четко разделять моделироване предметной области и проектирование. Первое — работа аналитика, второе — архитектора, разработчика и других технических специалистов. UML позволяет провести сквозную детализацию — от определения содержания (границ проекта — scope) до работы с кодом, через проектирование архитектуры. СО>Просто один пример — диаграммы классов могут использоваться: СО>1. для работы с набором классов (проектирование и разработка) СО>2. для объектов как экземпляров класса (проектирование) СО>3. для описания бизнес-сущностей и связей между ними (анализ)
СО>остальное — см. здесь.
СО>С уважением, СО>Сергей Орлик СО>Borland СО>http://www.borland.com СО>http://www.almportal.ru СО>http://sorlik.blogspot.com
СО>P.S. При данном наборе и форме вопросов для голосования, их вполне естественно обсуждать в "священных войнах".
Изначально создавая это голосования я отдавал себе отчет, что его можно счесть некорректным — именно поэтому я оставил в нем возможность создания своего варианта ответа. Но мне кажется, что во многом мои, возможно некорректные, варианты ответов отражают реалии применения UML! В теории, возможно, все выглядит совсем иначе, но практика применения UML, как мне кажется, именно такова, как я отразил в вариантах ответов. Причем полученные ответы показывают, что я не одинок в своем возможном заблуждении. Причем, как мне кажется, причина во многом в самом UML, который слишком сложен для того, чтобы упрощать.
Далее по тексту.
СО>- Для создания высокоуровневых диаграмм без привязки к коду. СО>Какие диаграммы имеются в виду? Use Case? (определяя scope проекта) Activity? (для бизнес-моделирования; визуализации, например, функциональных требований; описания высокоуровневых поведенческих характеристик архитектурного решения/концепции,....)
Все диаграммы.
СО>По мере изменения кода диаграммы устаревают, т.к. их лень обновлять. — это замечание не очень напоминает конструктивный вопрос. Если речь идет об актуализации той или иной диаграммы, вопрос мог бы звучать так "Обновляете ли Вы диаграммы для отражения изменившихся характеристик моделирумых объектов, сущностей, процессов?"
В данном случае это не вопрос, а вариант ответ. Плюс, если он не устраивает, именно из-за некоторой эмоциональной окраски, отвечающего, то он может выбрать свой вариант. Смысл ответа в любом случае не изменяется: устаревают или нет UML-диаграммы по ходу проекта.
СО>- Для создания высокоуровневых диаграмм без привязки к коду. Стараюсь вручную их обновлять по ходу проекта. СО>см. комментарии выше.
Если это относится к вопросу "какие диаграммы", то ответ — любые.
СО>- Для однократной генерации кода. СО>см. выше. комментарий Впоследствии диаграммы и код рассинхронизируются. imho, крайне некорректен, так как это вопрос качества поддержки синхронизации кода и модели (если речь идет о коде) в конкретном инструментарии, обеспечивающем поддержку UML.
Согласен. Мой вопрос был как раз безотносительно инструментов, о практике использования UML в реальных проектах.
СО>- Для постоянной генерации и обновления кода и reverse engineering диаграмм (возможно, с использованием инструментов постоянной синхронизации – 2-way tools). При этом код и диаграммы всегда синхронизированы. СО>2-way tools не то же самое, что reverse&forward engineering. Можно воспринимать модель как еще одно представление кода, которое работает с той же метамоделью кода (в VS.NET — CodeDOM). Ведь вроде так работает визуальный редактор форм? Чем UML-модель (если обсуждается модель, связанная с кодом) хуже? СО>Не стоит забывать об MDA, о таком понятии как мета-модель (которую, кстати, можно верифицировать, к которой можно обращаться с запросами через OCL, трансформировать в код через QVT и т.п....), профили и т.п.
Тут суть ответа не в том, как осуществляется синхронизация кода и диаграмм а в том, осуществляется ли она хоть как-нибудь.
СО>По-моему мнению, изначально, в данном треде сформулировано некорректное позиционирование UML как комплекса средств связанных только с вопросами кодирования. Отсюда, веротяно, и попытка противопоставлять UML и DSL, хотя, по логике, они могут друг друга естественно дополнять (сейчас скажу ересь — трансформировать UML в DSL через механизмы MDA).
UML, как впрочем и DSL — это способы моделирования. Но если в UML больший упор делается на именно рисование (простите такое упрощение), то DSL изначально делается упор на то, чтобы модель не была оторвана от кода.
СО>Необходимо четко разделять моделироване предметной области и проектирование. Первое — работа аналитика, второе — архитектора, разработчика и других технических специалистов. UML позволяет провести сквозную детализацию — от определения содержания (границ проекта — scope) до работы с кодом, через проектирование архитектуры. СО>Просто один пример — диаграммы классов могут использоваться: СО>1. для работы с набором классов (проектирование и разработка) СО>2. для объектов как экземпляров класса (проектирование) СО>3. для описания бизнес-сущностей и связей между ними (анализ)
Аналогично DSL используется и в моделировании предметной области и в проектировании. Только при этом в DSL предлагается оперировать не предельно общими для любой предметной области абстракциями, а конкретными сущностями.
СО>P.S. При данном наборе и форме вопросов для голосования, их вполне естественно обсуждать в "священных войнах".
Посмотрим, что скажут модераторы Пока я как раз хочу не воевать, а узнать мнение разработчиков об их опыте использования UML.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
SR>+10 SR>Приятно слышать (и читать) практиков !!!
Сергей, расскажите, плз, о своем реальном и практическом опыте использования UML в реальных, доведенных до конца, проектах?
Если можно, с конкретикой:
1. Какие создавались диаграммы?
2. Каким образом поддерживалась их непротиворечивость друг другу?
3. Создавался ли на основе диаграмм код? Каким образом?
4. Поддерживались ли диаграммы в актуальном состоянии в течение проекта? Каким образом?
5. Какие проблемы помогло решить использование UML в проекте?
6. Насколько сложные это были проекты?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
Возможно, на вопрос будет ответить проще, если вы расскажете о реальном и практическом опыте использования DSL Tools в реальных, доведенных до конца, проектах?
C>Возможно, на вопрос будет ответить проще, если вы расскажете о реальном и практическом опыте использования DSL Tools в реальных, доведенных до конца, проектах?
Замечательный ответ Не буду иронизировать по этому поводу, отвечу по сути:
1. Технология DSL от Microsoft только создается.
2. Несмотря на это, реальных применений DSL уже как минимум 2: Logical Application Designer и Class Designer в Visual Studio 2005.
Кстати, ваш вариант ответа в голосовании соответствует либо 1 либо 2 варианту из созданных мной. Разрешая создание собственных вариантов ответов я рассчитывал на варианты, отличающиеся по сути, а не по формулировке.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
Привествую, Александр
AL>Сергей, расскажите, плз, о своем реальном и практическом опыте использования UML в реальных, доведенных до конца, проектах?
AL>Если можно, с конкретикой: AL>1. Какие создавались диаграммы?
1. определение содержания проекта, визуализация требований/моделирование бизнес-процессов и бизнес-сущностей:
use case -> activity -> sequence
|
V
class (business entities)
2. архитектура
class
component
activity/collaboration
statechart
3. работа с кодом
class
sequence
в некоторых случаях — component (для EJB)
4. были проекты (особенно последнее время), где UML использовался для визуализации/документирования процессов разработки и сопровождения (например, для описания прохождения запросов на изменения), а также, SPI-процедур (software process improvement).
AL>2. Каким образом поддерживалась их непротиворечивость друг другу?
В зависимости от решаемых с помощью UML задач.
По бизнес-составляющей проекта (бизнес-моделированию) через соотв. review-процедуры, аналогично и часто в процессе анализа полноты и непротиворечивости требований + исопльзованись и проверялись в процессе impact-анализа. там где был организован CCB (change control board) — его члены (не все) были вовлечены в процесс изменения существующих моделей.
AL>3. Создавался ли на основе диаграмм код? Каким образом?
да. автоматически.
в ряде случаев, в проектах на основе EJB (Enterprise Java Beans), сами EJB создавались частично (те которые Entity и отображаются на БД) в специальном JBuilder EJB-дизайнере. Другие компоненты (Sessions) — создавались в Component и Class-диаграммах. MDB — и там и там.
Там где речь шла о .NET-клиентах к J2EE-серверу приложений, там инфраструктура бизнес-классов создавалась через диаграмму классов
Для визуализации и кооректировки структуры и поведения бизнес-методов использовались sequence-диаграммы и вызов средств рефакторинга непосредственно в режиме дизайна (а не кодирования).
И для серверных компонент и для клиентских использовались как стандартные GoF паттерны, так и те, кот орые относились к app-specific фреймворку, последние делались как сохранение конгломерата моделируемых элементов в форме паттерна.
AL>4. Поддерживались ли диаграммы в актуальном состоянии в течение проекта? Каким образом?
Да. Средствами конкретных инструментов моделирования и проектирования, в том числе, встроенных в различные среды ыразработки.
AL>5. Какие проблемы помогло решить использование UML в проекте?
часть из проблем
— нахождение общего языка между аналитиками (работавшими ранее в методоологии SADT и использования для бизнес-моделирования IDEF), архитекторами, разработчиками и заинтересованными лицами со стороны LOB (Line of Business)
— передача знаний участникам проектной команды, которые в дальнейшем развивали систему.
— автоматическая генерация документации.
— применение паттернов, в том числе, специфичных для конкретной задачи
AL>6. Насколько сложные это были проекты?
Комментарий: в чем мерить? в KLOC? FP? Efforts?....
Ответ: Достаточные для того, чтобы сформулировать свои собственные (частные) patterns & best practices.
AL>Замечательный ответ Не буду иронизировать по этому поводу, отвечу по сути: AL>1. Технология DSL от Microsoft только создается.
Т.о. пока не возможно их адекватно сравнивать. Лет через 5-10 посмотрим.
AL>2. Несмотря на это, реальных применений DSL уже как минимум 2: Logical Application Designer и Class Designer в Visual Studio 2005.
Ну имелись в виду реальные проекты, а не утилиты.
AL>Кстати, ваш вариант ответа в голосовании соответствует либо 1 либо 2 варианту из созданных мной. Разрешая создание собственных вариантов ответов я рассчитывал на варианты, отличающиеся по сути, а не по формулировке.
Вовсе не так, потому как:
варианты 1 и 2 лежат в контексте "высокоуровневых диаграмм без привязки к коду". Мой вариант лишён этого ограничения. Более того, контекст моего варианта существенно расширен за счет того, что точнее отражает жизненный цикл проектов, не ограничиваясь только "высокоуровневыми" диаграммами. При этом дополнительно включаются и "низкоуровневые диаграммы" (спецификация), и диаграммы, облегчающие переход от высокого уровня к низкому (проектирование).
На мой взгляд я там ничего некорректного не сказал. Тем более, что я говорил именно о реализации Microsoft подхода DSL.
Если нам не помогут, то мы тоже никого не пощадим.
