Аннотация:
Опыт авторов показывает, что решения, получающиеся при традиционном подходе к реализации реактивных систем, редко оказываются удобными и простыми для дальнейшего расширения и поддержки, особенно в случаях, когда поведение системы нетривиально. В данной статье рассматривается методика разработки, эффективно решающая большую часть подобных проблем. Поведение системы в целом описывается в виде конечного автомата на диаграмме состояний UML. Локальные действия в отдельных состояниях системы определяются при помощи соответствующих классов и функций C++. В статье также описывается расширение средства моделирования ArgoUML, предназначенное для автоматизации процесса разработки.
E>Кстати, обращение к авторам статьи, если они читают данное обсуждение: можно ли увидеть скриншоты вашей системы и примеры кода, который генерируется для дальнейшей правки руками?
К сожалению, там все строго закрыто NDA. Для того, чтобы не нарушить это соглашение, весь код для статьи пришлось написать с нуля (конечно, машина состояний получилась сильно упрощенной). Но хорошее представление о том, как выглядит самописный и сгенерированный код можно получить из исходников: http://rsdn.ru/File/22883/hsm-src.zip. В реальной жизни файлы .inc были бы сгенерированы, а все остальные — написаны руками.
так же изначально предназначался для упрощения программирования конечных автоматов. Похоже, разработка фреймворков на эту тему не собирается останавливаться
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
В конце концов авторы пришли к тому, к чему и должны были — автоматически генерируемый код по формальному описанию. Из этого следует замечания:
1) Непонятно, чем эта реализация колеса, лучше чем предыдущие. (Обычно на SDL такие вещи пишут).
2) Когда авторы подойдут к реализации систем еще бОльших масштабов (с бОльшим числом состояний), они убедяться, что графическая нотация уже неудобна, т.к. очень громоздка. И придут к тому, что проще описывать с помощью формального текстового, а не графического, языка — и опять привет колесо. см п.1.
3) Рассуждения о выборе языка программирования — в какой-то степени лукавство. Какая разница во что генерить.
так же изначально предназначался для упрощения программирования конечных автоматов. Похоже, разработка фреймворков на эту тему не собирается останавливаться
E>
Угу, читали. Но там, имхо, черезчур сложные шаблонные навороты. Преимуществом описанного в обсуждаемой статье похода является наличие кодогенератора.
Кстати, обращение к авторам статьи, если они читают данное обсуждение: можно ли увидеть скриншоты вашей системы и примеры кода, который генерируется для дальнейшей правки руками?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
так же изначально предназначался для упрощения программирования конечных автоматов. Похоже, разработка фреймворков на эту тему не собирается останавливаться
Ах, всё бы это объединить в один мега-фреймворк с мега-возможностями, что бы вообще всё автоматически генерировалось
Хорошо иметь возможность автогенерации кода, хорошо иметь механизм доставки сообщений (многопоточный/однопоточный/активные агенты/автоматы), хорошо иметь механизм отделения состояния от агента, а иногда плохо...
Только не упадёт ли фреймворк под собственным весом?
E>
Здравствуйте, remark, Вы писали:
R>Ах, всё бы это объединить в один мега-фреймворк с мега-возможностями, что бы вообще всё автоматически генерировалось R>Хорошо иметь возможность автогенерации кода, хорошо иметь механизм доставки сообщений (многопоточный/однопоточный/активные агенты/автоматы), хорошо иметь механизм отделения состояния от агента, а иногда плохо... R>Только не упадёт ли фреймворк под собственным весом?
Нет. Просто его никто не напишет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Любопытная статья.
Хотя то что авторы называют "конечным автоматом" уже больше похоже на Сеть Петри.
И еще авторы не дали определение "машины состояний".
Вообще, получается что авторы сами дали определения известных математических терминов. Обычно в таких случаях берут готовое определение и делают ссылку на источник
Здравствуйте, LelicDsp, Вы писали:
LD>В конце концов авторы пришли к тому, к чему и должны были — автоматически генерируемый код по формальному описанию. Из этого следует замечания: LD>1) Непонятно, чем эта реализация колеса, лучше чем предыдущие. (Обычно на SDL такие вещи пишут).
SDL имеет очень узкую область применения. Да и statechart-ы UML-я несколько отличны от SDL-ых процессов. В SDL-е автомат — неотъемлемая часть процесса и формальная run-time семантика SDL-я оперирует абстрактным statemachine-ами.
В случае же UML-я, statechart носит несколько более неформальный характер. И state в контексте UML-я скорее объект со своими свойствами, чем state в контексте SDL-я. Объектизировали state-ы лишь в SDL2000, но эта спецификация не получила особого распространения.
RGB>Хотя то что авторы называют "конечным автоматом" уже больше похоже на Сеть Петри.
С другой стороны, это вполне соответствует тому, что назвается "конечным автоматом" в UML.
RGB>Вообще, получается что авторы сами дали определения известных математических терминов. Обычно в таких случаях берут готовое определение и делают ссылку на источник
Математические определения обычно несколько замороченные. Поэтому мы придерживались UML-ных определений и семантики (что разумно, потому что в реальных проектах машины состояний генерировались из диаграмм).
RGB>Но, в принципе, неплохо.
Спасибо.
LD>2) Когда авторы подойдут к реализации систем еще бОльших масштабов (с бОльшим числом состояний), они убедяться, что графическая нотация уже неудобна, т.к. очень громоздка. И придут к тому, что проще описывать с помощью формального текстового, а не графического, языка — и опять привет колесо. см п.1.
Вполне возможно. В наших системах помогал реюс компонентов — т.е. один раз нарисованная машина состояний использовалась в разных контекстах. Это очень хорошо работало в нашей области — моделирование железа — там типичная ситуация, когда у вас есть какой-то, условно говоря, сумматор и вы 16 экземпляров этого сумматора запихиваете в разные куски схемы. Таким образом число состояний *на одной диаграмме* удавалось держать в разумных рамках.
Здравствуйте, Димчанский, Вы писали:
Д>Здравствуйте, pintelou, Вы писали:
P>>Конечно. Вот они: http://rsdn.ru/File/22883/hsm-src.zip
Д>Не критично в данном случае, но всё же. Д>В тестах в функции build_events куча new, но ни одного delete для них я не нашёл.
почему-то эти исходники не компилируются.
говорит
Error 1 error C2989: 'hsm::StateMachine' : class template has already been declared as a non-class template d:\private\workspace\песочница\hsm\hsm.h 230 HSM
для того, чтобы компилировались мне пришлось сделать вот что.
исправить строчку