UML vs DSL

А чем тебе UML сам по себе не DSL?

Изначально это _унифицированный_ язык моделирования(unified modeling language), поэтому он не может быть DSL(_domain specific_ language) по определению. Однако в последнее время UML был расширен, собственно по поводу этих расширений и возникают вопросы(ну и всякие общие).

5. в UML много видов диаграмм, вообще-то. структурная - да, является графической нотацией объектной архитектуры; и нет, не помогает - в сколько-нибудь крупных проектах куда проще работать с графическим представлением, близким к более высокоуровневым абстракциям: компонентам, FSM'ам, подсистемам, логическим устройствам, etc (т.е. с графическим DSL). я бы сказал, что структурные диаграммы - самое слабое место UML

На основе чего делаются «высокоуровневые абстракции»? Если это не UML, получается на его основе невозможно(сложно) повышать уровень абстракции описания системы?

например SysML(UML + SysML profile) имеет диаграмму для выражения конечных автоматов

Если это не UML, получается на его основе невозможно(сложно) повышать уровень абстракции описания системы?

почему не UML? можно и UML, вполне. просто к объектной архитектуре это уже никакого отношения не имеет

ок. Сделаю выводы:

1. UML и DSL можно сравнивать(при учете дополнений к UML).

2. UML позволяет повысить уровень абстракции при разработке.

3. На счет текстовой нотации - довольно много проектов, думаю если хорошо поискать то можно найти.

Если есть замечания/дополнения - буду слушать

UML диаграммы годятся для описания ключевых моментов в архитектуре программы. Ни в коем случае не для описания архитектуры в мельчайших деталях, ибо тогда они станут бесполезны. В них будет так же трудно разобраться, как и в самом коде. Генерировать по ним спецификации объектов можно, но генерировать по ним весь код, это бредовая идея.

например в случае с DSL уровень абстракции приближается к уровню спецификации задачи

Ну вот не видел я такое в жизни. Для каких-то маленьких частей приложения таки да, но это не серьезно.

Я бы сказал так.

DSL можно спроектировать тогда, когда есть представление об модели предметной области. Хотя бы, некоторое хорошее приближение этой модели, которое при углубляющем рефакторинге (в сторону лучшего описания предметной области) не сильно меняется.

А модель предметной области, во время её формирования, дистилляции так сказать, должна как-то описываться, правильно? Вот для этого и можно использовать UML.

В конце-концов, суть не в UML и не в DSL. Суть в том, чтоб сформировать модель предметной области, и выразить её в коде. DSL удобен для выражения её в коде, по определению.

Но удобно ли вам будет формировать модель предметной области в терминах DSL? Удобно ли будет производить углубляющий рефакторинг этого DSL? Если да, то пользуйтесь им. Если нет, попробуйте для этого UML. Не понравится UML, используйте свою собственную нотацию.

>>например в случае с DSL уровень абстракции приближается к уровню спецификации задачи

Ну вот не видел я такое в жизни. Для каких-то маленьких частей приложения таки да, но это не серьезно.

MARTE - UML профиль для описания embedded систем, судя по спецификации позволяет исследовать даже время выполнения частей системы. Executable UML - позволяет описывать _действия_ как части UML диаграммы. Но если вы на практике не встречали - так и запишу. На часть изначальных вопросов я уже нашел ответы сам, сейчас интересует и опыт использования(кстати, а использование хаскела в жизни вы видели?).

Спасибо, отличный ответ! Судя по другим обсуждениям соотношения UML и DSL, его представляют именно так.

неужели UML не предоставляет возможности фокусировки и ограничений разных концептов программ? К тому же можно специализировать модели(уже десятый раз повторяю) и тогда по ним можно будет генерировать вполне рабочий код(похожий пример есть в книге DSM : enabling full code generation, только там не UML а похожий язык с графической нотацией). В общем как правильно сказал анонимус - UML это одно из средств(возможных) для реализации DSL, и это подтверждают различные обсуждения по этой тематике(хотя иногда говорят и на оборот).

возможности фокусировки и ограничений разных концептов программ

Жесть какая-то. Вообще все просто. Будут косяки в uml, соответсвенно они будут оттранслированны в косячный код. А можно сразу писать косячный код, это тоже самое, но быстрее.

в принципе да, от неправильной спецификации никто не страхует, чем DSL на основе Haskell или Coq кажутся выгодней - в основе лежит логика которая позволяет изучать свойства созданой модели, а в основе UML лежит текстовое описание семантики, причем с неоднозначностями.

чем DSL на основе Haskell или Coq кажутся выгодней - в основе лежит логика которая позволяет изучать свойства созданой модели

К этому утверждения стоит добавить, что сам моделируемый объект должен обладать достаточно простыми и однозначными свойствами. Нельзя взять хаос, из этого хаоса вычленить хаос меньшего размера и получить какие-то адекватные результаты анализа этого малого хаоса. Иными словами предметная область должнать быть хорошо формализуемой, тогда от DSL на Haskell или Coq будет какой-то толк.

Рекомендую расматривать UML в первую очередь как средство описания модели предметной области при проектировании. Потом можно спроектировать DSL, отражающий построенную модель.

Можно обойтись без одного из них, или даже без обоих, но модель предметной области должна быть спроектирована, и должна лежать в основе программы.

Опытные проектировщики (напирмер, Эрик Эванс) указывают на то, что модель предметной области следует изначально проектировать без сильного отрыва от вопросов реализации. Часто получается так, что реализация и проектирование модели идут параллельно, и влияют друг на друга. Это следует иметь ввиду, когда заходит речь о детализации модели.

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

Впрочем, даже если код по UML диаграмме генерируется не полностью, это не значит, что такая генерация бесполезна. Я за то, чтоб извлекать из этого максимум пользы, не следуя какой-то одной идеологии.

хм, можете привести пример плохо формализуемой области, для которой, тем не менее, можно писать программы. Мое мнение : программа - это уже ,по сути, модель области, притом формальная, и интересных свойств у этой модели найдется предостаточно. Просто в обычных языках их изучить крайне затруднительно.

Спасибо! Вы составляете впечатление компетентного человека по этим вопросам. Можете посоветовать литературы по теме?

можете привести пример плохо формализуемой области

Большинство областей таких :) В общем там, где фигурируют люди, все уже сразу весело. К примеру если вы захотите написать неблокирующий веб-сервер, а в качестве формальной модели возьмете модель СМО, то поймете, что поток заявок на обработку не является пуассоновским, и модель будет очень сложной. Конечно можно угрохать очень много времени и таки осилить, но все равно вы промоделируете только один из аспектов приложения. А оно того стоило? Можно ресурсы использовать более рационально, например быстрее выпустить первую версию и запустить в продакшн. Не стоит забывать что программисты работают с идеальными объектами, изготовление и копирование которых ничего не стоит, поэтому моделирование не является столь необходимым как в случае, к примеру, с запуском спутника.

программа - это уже ,по сути, модель области, притом формальная

Вот именно, программа уже и есть модель. А стоит ли строить модели моделей?

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


А ещё в современном мире очень выгодно торговать возможностью reduce costs.


а вот ещё последний поток сознания.
1 + 1 + 1 + 1 = 4*1 = 4 (было 7 символов, а стал один. Если просто смотреть, то какие-то свойства модели сохранились, а энтропия уменьшилась)

есть ли правила вывода в UML, которые сохраняют максимум свойств в минимуме информации с минимумом вычислений? Какая информация нужна тебе для принятия решения(ты принимаешь всегда однотипные решения и тебе нужна одна и та же ин-ция?), легко ли нужную для принятия решения ин-цию получить из всей системы?

Давайте посоветую, но я далеко не гуру в этой области.

Из тех, что читал:

Мартин Фаулер, Рефакторинг. Не помню кто, Рефакторинг баз данных. Джошуа Кириевски, Рефакторинг с использованием шаблонов. Эрик Эванс, Предметно-ориентированное проектирование. (особенно выделю!) (Нет слова UML в названии, тем не менее, эти книги здесь не зря.)

Крэг Ларман, Применение UML и шаблонов проектирования. Буч и др., Объектно-ориентированный анализ и дизайн с примерами приложений.

Из тех, что хочу прочитать:

Мартин Фаулер, Domain-Specific languages. Terence Parr, Language Implementation Patterns. Domain Specific Modeling.

в принципе вы правы - в большинстве случаев стоимость ошибки не так велика по сравнению со стоимостью полной формализацией задачи. Хотя для неблокирующего сервера наиболее близкий по уровню абстракции язык это как раз языки «высокого» уровня, где концептами являются сокеты, системные вызовы и прочее. Это задача больше относится к системному уровню(обслуживающему). В прикладных задачах можно найти больше применений методам повышения уровня абстракции. ИМХО, детальная спецификация неблокирующего сервера и будет сводиться к концепциям сокетов, пулов и системных вызовов(хотя бы по тому что это заложено в его названии), но это верно не для каждой задачи - иногда можно получить детальную спецификацию задачи без низкоуровневых деталей(которые в принципе не важны, как не важны нам инструкции процессора в которые компилируется наш код), и тогда моделирование будет очень полезно.

примерно тоже самое я пытался написать в прошлом посте - про уменьшение количества информации с сохранением возможности принятия конечного решения(программы), только не так кратко

для текстового представления смотри, например, plantuml

Может быть кто-нибудь подскажет где можно найти электронную версию новой книги Мартина Фаулера Domain Specific Languages?

>электронную версию новой книги Мартина Фаулера Domain Specific Languages
Вроде, пока ещё она пиратам не досталась. :( Да и ссылки на варез на данном форуме запрещены.