Тут нужно сказать следующее — звучит сие чрезмерно претенциозно.
Семантика выражения
"это технология и методология, которую предлагает Microsoft в области моделирования"
несколько отлична
от "это технология и методология, которую Microsoft начала другим советовать."
Правда звучит так:
Domain Specific Language — Специализированный язык предметной области.
Создание DSL — старый как человеческий разум подход к абстрагированию,
который переживет и UML и много других страшных терминов из
современного IT.
Microsoft приняло решение обратить мощь PR машины и подразделений
разработчиков внутри компании на этот факт и предоставить (i.e. продать)
методологию и средства ее поддержки (tools) для технологий MS.
Как обычно чтобы сделать сообщение полезным, несколько ссылок и цитат: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4
Chapter 4 Metalinguistic Abstraction
...
Metalinguistic abstraction -- establishing new languages -- plays an
important role in all branches of engineering design. It is
particularly important to computer programming, because in programming
not only can we formulate new languages but we can also implement
these languages by constructing evaluators. An evaluator (or
interpreter) for a programming language is a procedure that, when
applied to an expression of the language, performs the actions
required to evaluate that expression.
It is no exaggeration to regard this as the most fundamental idea in
programming:
The evaluator, which determines the meaning of expressions in a
programming language, is just another program.
To appreciate this point is to change our images of ourselves as
programmers. We come to see ourselves as designers of languages,
rather than only users of languages designed by others.
И сюрприз:
Форматная строка в fprintf(), regexp, конфигурация от make, скрипты
awk, yacc/lex, и SQL, HTML, это то же DSL.
Мир нормального программирования, не зашторенный
"умными" IDE, монстровидными run-time библиотеками для всего,
полон DSL'а уже давно, т.к. ценится возможность компактного
описания проблемной области.
The Practice of Programming
by Brian W. Kernighan and Rob Pike. http://cm.bell-labs.com/cm/cs/tpop/
Chapter 9: Notation
9.1 Formatting Data
9.2 Regular Expressions
9.3 Programmable Tools
9.4 Interpreters, Compilers, and Virtual Machines
9.5 Programs that Write Programs
9.6 Using Macros to Generate Code
9.7 Compiling on the Fly
Б. Керниган, Р. Пайк Практика программирования)
--
Что же касается того, что в Microsoft сами ее уже давно используют
разнообразные DSL то в этом нет сомнений, т.к. там вполне адекватные люди.
А отношение к CASE утилитам в Microsoft:
Освящено в вышей степени ироничной, но глубокой книге
посвященной снятию лапши с ушей "молодых профессионалов":
Edward Yourdon "Death March"
известной в переводе как Эдвард Йордан «Смертельный марш»
ГЛАВА 6. ТЕХНОЛОГИЯ И СРЕДСТВА
Летом 1992 года мне довелось обедать с дружной группой менеджеров
среднего уровня Microsoft. Во время завязавшейся беседы я спросил,
является ли для проектных команд Microsoft обычным делом использование
таких методологий, как структурный анализ или объектно-ориентированное
проектирование. Ответы были примерно следующими: «иногда», «хммм,
вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я
спросил их относительно использования CASE-средств (которые в то время
все еще были довольно популярными в индустрии ПО), то из их ответов
понял, в чем заключается общее мнение майкрософтовцев: такие средства
годятся для «людей с улицы». С таким выражением я еще не встречался,
его можно грубо интерпретировать как «невежественные дикари, которые
только что вылезли из своего первобытного леса и начали обучаться
программированию, в отличие от настоящих программистов, которые не
нуждаются во всяких финтифлюшках».
Будучи слегка уязвленным, я поинтересовался, используют ли их
проектные команды хоть какие-нибудь средства, и в ответ услышал, что
каждая команда Microsoft может выбрать любые средства, которые сочтет
подходящими для своего проекта. Ухватившись за такой ответ, я спросил,
какое средство считает наиболее важным типичная проектная команда?
«На днях я задал одной из проектных команд такой же вопрос», — ответил
один из менеджеров. «Как вы думаете, что они ответили?» «Какой-нибудь
высокопроизводительный компилятор С++?», — спросил я. «Ассемблер? Или
мощное средство отладки для устранения множества ошибок в их коде
(хи-хи-хи)?» «Ничего подобного», — ответил менеджер, игнорируя мое
гнусное хихиканье. «Они ответили: электронная почта. Средний
разработчик Microsoft получает сотню сообщений в день; он живет в
электронной почте. Уберите электронную почту, и проект умрет».
---------------------------------------------------------------------
Итог: следите за тем не превратилась вы вы в «людей с улицы».
Снимайте лапшу, и читайте книги — они ключ к знаниям.
Статьи от MSFT надо воспринимать как PR — это есть их работа.
В данном случае, статья привлекает внимание к важной теме — DSL
(более актуальной чем прибитый гвоздями UML), незаслуженно мало
обсуждаемой.
И в ближайшем будущем надеюсь автор раскроет нам суть Microsoft way,
в отношении DSL, сделав упор на предлагаемые методологии и утилиты.
P.S. а определение 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. для описания бизнес-сущностей и связей между ними (анализ)
. Очень интересно услышать мнение уважаемого сообщества по этому вопросу.
Вот этот абзац вызывает сильное неприятие:
Немного о DSL
Но сначала немного о DSL (о том, что такое UML, я думаю, знают практически все – на его маркетинг было потрачено очень много усилий). DSL (Domain Specific Languages) – это технология и методология, которую предлагает Microsoft в области моделирования. Суть DSL состоит в том, что в каждой предметной области стоит не пытаться использовать унифицированный язык моделирования, а вместо этого стоит создавать для каждой задачи зык моделирования и описания,
Этому, без сомнения, грамотному подходу очень много лет. Как минимум, столько же,
сколько Лиспу. И причем тут майкрософт?
C>А где-нибудь можно посмотреть спецификации DSL или примеры использования?
Да, здесь
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
. Очень интересно услышать мнение уважаемого сообщества по этому вопросу.
Кстати, а где в голосовании DSL? Я, например, пользуюсь при каждлом удобном случае.
Есть технологии, полезность которых нуждается в постоянном доказательстве (UML) — то есть сомнительно,
а есть такие, которые трудно переоценить, когда начинаешь ими пользоваться.
Вообще, давно хотел написать статью про применение метапрограмирования / dsl, но руки не
доходят как-то.
. Очень интересно услышать мнение уважаемого сообщества по этому вопросу.
10.08.05 11:44: Перенесено из 'Архитектура программного обеспечения'
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
dmz>Этому, без сомнения, грамотному подходу очень много лет. Как минимум, столько же, dmz>сколько Лиспу. И причем тут майкрософт?
Подходу — без сомнения. Думаю, что подход, заключающийся в ориентации на предметную облась, появился и раньше Лиспа. Я же говорю лишь о технологии и методологии DSL от Microsoft. И кстати, говорю, что это предлагает Microsoft, а не изобрел Microsoft. Что в этом заявлении некорректного?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
AL>Подходу — без сомнения. Думаю, что подход, заключающийся в ориентации на предметную облась, появился и раньше Лиспа. Я же говорю лишь о технологии и методологии DSL от Microsoft. И кстати, говорю, что это предлагает Microsoft, а не изобрел Microsoft. Что в этом заявлении некорректного?
Да, в общем, ничего. Формулировка просто немного провоцирующая.
dmz>Да, в общем, ничего. Формулировка просто немного провоцирующая.
Sorry, не было цели провоцировать На мой взгляд я там ничего некорректного не сказал. Тем более, что я говорил именно о реализации Microsoft подхода DSL.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
dmz>Кстати, а где в голосовании DSL? Я, например, пользуюсь при каждлом удобном случае. dmz>Есть технологии, полезность которых нуждается в постоянном доказательстве (UML) — то есть сомнительно, dmz>а есть такие, которые трудно переоценить, когда начинаешь ими пользоваться.
Я не заводил. Цель этого голосования — понять, как используется UML.
dmz>Вообще, давно хотел написать статью про применение метапрограмирования / dsl, но руки не dmz>доходят как-то.
Статья была бы интересна и полезна, я как раз собираюсь про Microsoft DSL написать в блоге поподробнее. А вы смотрели на DSL от Microsoft? Какое мнение о них?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
AL>Статья была бы интересна и полезна, я как раз собираюсь про Microsoft DSL написать в блоге поподробнее. А вы смотрели на DSL от Microsoft? Какое AL>мнение о них?
Нет, не смотрел, да и наверное не будет такой возможности. Хотя, в общем, любопытно. По ссылкам пробежался —
но конкретных примеров не нашел — только объемистые статьи.
Хотя мне пока не кажется, что для того, что бы использовать 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. для описания бизнес-сущностей и связей между ними (анализ)
СО>остальное — см. здесь.
СО>С уважением, СО>Сергей Орлик СО>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 лежат в контексте "высокоуровневых диаграмм без привязки к коду". Мой вариант лишён этого ограничения. Более того, контекст моего варианта существенно расширен за счет того, что точнее отражает жизненный цикл проектов, не ограничиваясь только "высокоуровневыми" диаграммами. При этом дополнительно включаются и "низкоуровневые диаграммы" (спецификация), и диаграммы, облегчающие переход от высокого уровня к низкому (проектирование).
Здравствуйте, AlexanderLozhechkin, Вы писали:
SR>>+10 SR>>Приятно слышать (и читать) практиков !!!
AL>Сергей, расскажите, плз, о своем реальном и практическом опыте использования UML в реальных, доведенных до конца, проектах?
Александр , приветствую!
Извини, конечно, за предыдущий пост, но заголовок треда "UML и\или DSL", и последующий опрос, где вопросы, в принципе вполне адекватные до "точки", а далее "маркетинговый спам" , цитирую "Для создания высокоуровневых диаграмм без привязки к коду" — вполне нормальная формулировка, но далее "По мере изменения кода диаграммы устаревают, т.к. их лень обновлять" — то что кому-то лень, проблема вовсе не UML, а инструментальной поддержки или организации процесса. И как я могу голосовать за такой ответ? — да я использую UML создания ..., но мне не лень.
Вообще Сергей Орлик высказался (как и часто это он делает) как говорится в точку.
Что касается реальных проектов, вот некоторые из них: ИС учета дорожного хозяйства «ДОДД Спб», ЕУС «ЗАО Петербургрегионгаз», ЕУС КЭП Спб, ГИС "Водоканал" итд. Во всех проектах по крайней мере документ "Концепция и логика" полностью сопровождался диаграммами, причем ни разу не слышал от заказчика каких либо нареканий насчет недоступности представления информации. Задания разработчикам также в основном представлялись с сопутствующими диаграммами.
Особо хотелось подчеркнуть пару проектов ИСУП МЭРТ, СЭДО МЭРТ, Обмен СЭДО МЭРТ и РФФИ , проекты выполнены на платформе DocsVision (узнаешь ), так вот учитывая "ограничения" платформы в средствах моделирования и проектирования, без применения UML просто не реально было что-либо описать, спроектировать, а самое главное донести до разработчиков постановку задачи
AL>Если можно, с конкретикой: AL>1. Какие создавались диаграммы?
UseCase, Activity, State, Sequence,Class (правда обычно при моделировании, при проектировании редко и в основном на бумаге для коммуникации между членами команды.
Могу сказать какие не использовал, так как трудны понимания (для меня) — Collaboration
AL>2. Каким образом поддерживалась их непротиворечивость друг другу?
Я никогда не задавался такой целью, я использовал UML как стандарт при коммуникации.
AL>3. Создавался ли на основе диаграмм код? Каким образом?
Создавал и создаю. Например, для генерации мэппинга, Entity-классов, DAO-классов при использовании ORM.
AL>4. Поддерживались ли диаграммы в актуальном состоянии в течение проекта? Каким образом?
Нет. Считаю это излишним. IMHO, "рисовать" — нужно до тех пор, пока это полезно, но не использовать модели ради самих моделей
AL>5. Какие проблемы помогло решить использование UML в проекте?
Основная решаемая проблема — это IMHO, коммуникация, все члены команды говорят на одном языке.
AL>6. Насколько сложные это были проекты?
Про некоторые ты и сам знаешь Вообще трудно по каким-либо метрикам оценить "сложность"
1. Мое определение, если его так можно называть, относится _только_ к реализации технологии DSL от Microsoft.
2. По поводу цитаты из Йордана. Мой опыт общения с членами команд разработки в Microsoft показывает, что каждая команда выбирает средства разработки и проектирования, которыми она будет пользоваться, самостоятельно. Поэтому нельзя говорить о таком понятии, как «типичная проектная команда». Я знаю команды в Microsoft, в которых пишут на голом С без использование IDE и знаю команды, которые используют Visual Studio в полный рост.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
Здравствуйте, AlexanderLozhechkin, Вы писали:
AL>UML, как впрочем и DSL — это способы моделирования. Но если в UML больший упор делается на именно рисование (простите такое упрощение), то DSL изначально делается упор на то, чтобы модель не была оторвана от кода.
Я согласен с Сергеем в том, что вопрос поставлен некорректно. UML слишком большой, чтобы его можно было сравнивать с DSL. Его можно разделить на две части. 1 часть, моделирование бизнес-процессов, и написание требований. Вторая часть — логическая и физическая модели. Если с первой частью все понятно (хотя мы максимум используем use case диаграммы), то вторую часть мы практически используем не для моделирования, а именно для документирования. Максимум моделирования диаграммы компонентов. И физику мы вообще тут uml'ом не трогаем. Описанию поддвергаются только наиболее важные вещи, например внешние интерфейсы. Физический уровень практически никому(кроме узкого класса девелоперов) не нужен. По нему легче прокатится какой-нибудь автоматикой для сборки информации из комментариев. И в данном случае, DSL будет очень полезен. Но то что касается тех важных мест, которые мы должны отдать клиентам, отдается только внешний интерфейс, на который пишется документация(часть которой и является диаграмма), и к которому подходят особенно тщательно. Поэтому ручное управление этими диаграммами не является преступлением.
Что касается моделирования архитектуры, то моделирование с помощью uml — это большая потеря времени, по сравнению с обсуждениями, исписанными листочками, и примерным описанием в word. Подробности предоставляемые DSL здесь не особо важны.
Полностью поставленный процесс документирования именно в UML, или близкий к этому, я никогда не видел, и об этом никогда не слышал. Значительно важнее те документы на русском(английском) языке которые сопровождают софт.
Автор(ы): Б. Керниган, Р. Пайк
Если нам не помогут, то мы тоже никого не пощадим.
На мой взгляд я там ничего некорректного не сказал. Тем более, что я говорил именно о реализации Microsoft подхода DSL.
, цитирую "Для создания высокоуровневых диаграмм без привязки к коду" — вполне нормальная формулировка, но далее "По мере изменения кода диаграммы устаревают, т.к. их лень обновлять" — то что кому-то лень, проблема вовсе не UML, а инструментальной поддержки или организации процесса. И как я могу голосовать за такой ответ? — да я использую UML создания ..., но мне не лень.
), так вот учитывая "ограничения" платформы в средствах моделирования и проектирования, без применения UML просто не реально было что-либо описать, спроектировать, а самое главное донести до разработчиков постановку задачи
