Аннотация:
Опыт авторов показывает, что решения, получающиеся при традиционном подходе к реализации реактивных систем, редко оказываются удобными и простыми для дальнейшего расширения и поддержки, особенно в случаях, когда поведение системы нетривиально. В данной статье рассматривается методика разработки, эффективно решающая большую часть подобных проблем. Поведение системы в целом описывается в виде конечного автомата на диаграмме состояний UML. Локальные действия в отдельных состояниях системы определяются при помощи соответствующих классов и функций C++. В статье также описывается расширение средства моделирования ArgoUML, предназначенное для автоматизации процесса разработки.
так же изначально предназначался для упрощения программирования конечных автоматов. Похоже, разработка фреймворков на эту тему не собирается останавливаться
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, но эта спецификация не получила особого распространения.
E>Кстати, обращение к авторам статьи, если они читают данное обсуждение: можно ли увидеть скриншоты вашей системы и примеры кода, который генерируется для дальнейшей правки руками?
К сожалению, там все строго закрыто NDA. Для того, чтобы не нарушить это соглашение, весь код для статьи пришлось написать с нуля (конечно, машина состояний получилась сильно упрощенной). Но хорошее представление о том, как выглядит самописный и сгенерированный код можно получить из исходников: http://rsdn.ru/File/22883/hsm-src.zip. В реальной жизни файлы .inc были бы сгенерированы, а все остальные — написаны руками.
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
для того, чтобы компилировались мне пришлось сделать вот что.
исправить строчку