Менеджер построения графов

[Eugen Graf]

Лучше Граф Евгений фон Хомбург

[Pavel Krivozubov]

развели флейм понимаешь

[dancerdima]

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

[Pavel Krivozubov]

Ну скажем так - термины эти взаимозаменяемы.
http://ru.wikipedia.org/wiki/%D0%94%D0% ... E%D0%B2%29
Рисуют конечно сначалА алгоритм программы, но называется он не граф состояний а блок-схема. Со своими четкими обозначениями, описанными в ГОСТе. Граф состояний это другое.

[Eugen Graf]

Я называю это UML диаграммой или стейт диаграммой, но уже не важно. Ответ на вопрос был получен я думаю?
Кстати у нас на форуме создана отдельная ветка для этого:
http://labviewportal.org/viewforum.php?f=133

[dancerdima]

Подскажите плиз еще, State Diagram Toolkit отдельно ставиться, если да то где его качнуть для LV 8.2?? (сп всем за ответы))

[Eugen Graf]

купить на официальном сайте NI или у российского дистрибутора.

P.S. не понимаю зачем он нужен, можно спрограммировать один к одному с бумажки используя темплейт Standart State Machine.

[Pavel Krivozubov]

купить на официальном сайте NI или у российского дистрибутора.

P.S. не понимаю зачем он нужен, можно спрограммировать один к одному с бумажки используя темплейт Standart State Machine.

да, или скачать ознакомительную версию на ftp.ni.com
Кстати в понимании целей этого тулкита я солидарен с Женей - я тоже не понимаю зачем он нужен..

[FireFly]

Слово "граф" вообще редко употребляется, имхо.

Категорически не согласен.
У нас в универе, да и щас на работе часто используют слово граф, и все понимают о чём идёт речь и с графиками не путают. Про теорию графов знают все (хотя не все её знают ).
Хотя я конечно понимаю что в LabVIEW созвучность русского граф и английского Graph может вносить неясность.

[mzu2006]

По-русски я это называю диаграмма состояний конечного автомата.
Насчёт блок-схемы (flowchart) и диаграммы состояний (state diagram): ПМСМ, это 2 разные вещи, освещающие ко с разных сторон. Если ты делаешь конечный автомат, то рисовать блок-схему я бы не стал. Кроме того, блок-схема совершенно не отражает ОО дизайна программы. Мне кажется, если ГОСТ этого требует, то ГОСТ просто устарел.

Нужность модуля? Ну есть стремление такое: максимально абстрагироваться от кода + обеспечить автоматическую генерацию документации. Для начинающего или для простых проектов - стремление вредное. Для больших проектов, разрабатываемых многими разработчиками, немного полезное. Мне больше по описанию нравятся продукты Endevo, а также Rational (для С++).

Ещё я помню для облегчения построения конечных автоматов было любопытное решение: LabHSM написанное уважаемым Станиславом Румегой (Stanislav Rumega). Правда оно давно не обновлялось.

[Pavel Krivozubov]

Слово "граф" вообще редко употребляется, имхо.

Категорически не согласен.
У нас в универе, да и щас на работе часто используют слово граф, и все понимают о чём идёт речь и с графиками не путают. Про теорию графов знают все (хотя не все её знают ).
Хотя я конечно понимаю что в LabVIEW созвучность русского граф и английского Graph может вносить неясность.

В универе возможно что-то и было про графы, но универ был давно, и некоторые вещи уже стали стираться из памяти, тем более не профильные.
На работе же я с ними никогда не сталкивался если честно. Возможно они нужны в каких-нибудь мега-больших проектах, в которых задействованы несколько человек программистов. Но я на фирме один программист LabVIEW поэтому мне они особо не требуются. Да и зачем одному человеку все эти схемы? Для восстановления памяти спустя несколько лет, в случае если понадобиться что-то отладить? У меня были такие случаи, я в этом году корректировал проект который писал 4 года назад. И ничего - разобрался. Да и потом - тонкости и трудности бывают обычно в мелочах, а если расписывать алгоритмы программ до каждой мелочи этож какие тома документации надо сотворить??
В общем по моему мнению эти вещи нужны в двух случаях:
1) Для создания отчетной документации для программы. При патентовании например.
2) Для создания отчетной документации при передаче дел своему сменщику перед увольнением.
Ни то не другое для меня пока не актуально. насчет второго - ттт

[styrum]

Ещё я помню для облегчения построения конечных автоматов было любопытное решение: LabHSM написанное уважаемым Станиславом Румегой (Stanislav Rumega). Правда оно давно не обновлялось.

Спасибо, что вспомнили. LabHSM позволял состояния (иерархические, с наследованием реакций на события от "родителей" к "детям"!) программировать напрямую. Может у меня мания величия конечно, но мне кажется, что именно LabHSM заставил тогда NI сделать поддержку вложенных состояний в State Diagram Toolkit. Когда они это наконец сделали, я уже не видел смысла обновлять LabHSM. В этой новой версии State Diagram Toolkit (теперь это Statechart Kit называется http://www.ni.com/labview/statechart) конечно тоже ещё не всё по уму. Например, им и в голову не приходит, что событие кроме идентификатора (имени) должно быть способно ещё и любые данные нести с собой в обработчик (там надо заранее данные передавать). Про приотизацию событий я уже и вспоминаю.

Я потом попроще шаблон сделал, без поддержки иерархии, но всё равно гораздо более мощный, чем все остальные известные мне шаблоны State Machines, потому что он всё-таки разделял понятия "состояние", "действие" и "событие". Т.е. позволяет программировать автомат Мили (где действия можно ассоциировать с переходами между состояниями а не только со входами в них, как в автомате Мура, который NI до сих пор пихает как единственно возможный вариант машины состояний, отождествляя состояние и действие). Тот попроще шаблон EDQSM называется. Кому интересно, на LavaG.org посмотрите (http://lavag.org/topic/4623-simple-even ... entry25359).

Заметьте, что NI всегда делало вид, что никогда и не слышали ни про LabHSM, ни про EDQSM. Они не упоминаются ни в одной их статье на тему State Machines.

[Eugen Graf]

Привет!!!
Очень рад встретить здесь человека - серьёзного разработчика, с которым я (и многие здесь) когда то общался

На счёт LabHSM - в какое то время мне очень хотелось его использовать, но т.к. лицензия была платной, так и не решился (в то время). Позже, после того как я научился программировать и в какой то степени приобрёл свой стиль и темплейт (на основе QSM) просто не вспоминал о каких либо тулкитах на эту тему.

В любом случае я хотел бы подробнее узнать о начинке, плюсах, возможно минусах непосредственно от разработчика. Так же хотелось бы узнть что побудило тебя, Станислав, (и возможно твою команду) спрограммировать такой тулкит.

Привет, Женя

[mzu2006]

Станислав,

Спасибо, что вспомнили.

Автора хорошего тулкита и вспомнить приятно. Спасибо за рассказ о том, почему прекратилась разработка LabHSM. Я разобрал сейчас несколько старых твоих нитей с Autmoationlabs и с lava. Там говорилось об автогенерации кода, например, по UML спецификации (нарисованной в Visio, или как ещё). Было ли что-то сделано, что можно пощупать? Была ли уже к тому времени среда NI Requirements Gateway?

[styrum]

LabHSM я сделал в основном месяца за полтора, один. Ваять графический редактор состояний самому это уже мне было не по силам, интегрировать с Visio - уже не до того тогда было- с основной работой плохо стало, а я тогда на H1B визе в Штатах был (читай-на птичьих правах, не смотря на то, что к тому времени уже лет 7 тут прожил - ну это отдельная песня). Так что, извините, щупать особо нечего. Контора, где я сейчас работаю, никак не соберётся Statechart Kit купить, но в принципе в моих теперешних проектах мне и EDQSM вполне хватает (хотя он и не поддерживает вложенные состояния и наследование транзакций между ними). Главное, чего не хватало в LabHSM для полноты функционала - это поддержки параллельных состояний в иерархии ("AND" states).

Основные фишки LAbHSM и EDQDSM:
1. Программа должна состоять из модулей (1 или больше), каждый из которых имеет собственную "жизнь" (машину состояний со своими состояниями, событиями и действиями), но также может посылать асинхронные сообщения другим модулям (это одно из возможных действий) и получать сообщения от других модулей (если эти сообщения известны модулю-адресату, они становятся событиями для него)
2. Они позволяют мыслить ("делать дизайн") и тут же программировать (design is code!) на более высоком уровне абстракции, в терминах "состояние", "событие" и "действие": "Когда этот модуль состоянии А и происходит событие Б, какие действия он должен выполнить и в каком состоянии оказаться после их выполнения?" Эта модель намного более близка к взаимодействию объектов в реальном мире, не правда ли? Собака гавкает тогда и потому что увидела прохожего (но только если она не спит в этот, например), а не потому что господь Бог (Основная Программа) почему-то вдруг вызвала метод Гавкнуть.
3. Разделение понятий "действие" и "состояние", чему так упорно сопротивляется NI и многие разработчики в своих шаблонах, позволяет не только упростить модель поведения, сократить количество состояний, но и повторно использовать куски кода (действия) внутри одного модуля без выделения их в subVI!

Что побудило меня всё это наворотить? 1. Чтобы жизнь себе облегчить и во время разработки и во время модификации потом. 2. Чтобы работу легче находить - мирок LabVIEW не очень то велик, даже в Штатах, для этого казолось нужным, чтобы меня в нём знали (а не из тщеславия). Для второго пришлось ещё и примазаться к чужой славе (подправить для "восьмёрки" Tunnel Wiring Wizard) и похулиганить: PMS assistant, если кто знает, давал доступ к VI Scripting после того, как NI попыталась его прикрыть в той же "восьмёрке". Сейчас то они его открыли наконец, а тогда не хотели. Вообще-то PMS это Property and Method Selection, но я же в сопроводилке тогда издевательски так написал, что типа у нашей "мамы" (NI) наверно ПМС, вот она и разозлилась на нас, "деток", и положила самую интересную игрушку на верхнюю полку. Ну так нате мол вам, "детки", "лестницу". С тех пор они меня особенно не любят, хотя и хотели нанять однажды - ездил я к ним в Остин на интервью, кстати работа должна была быть по написанию Asstant какого-то (естественно с применением VI scripting).