Менеджер построения графов
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Менеджер построения графов
развели флейм понимаешь
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
- beginner
- Сообщения: 29
- Зарегистрирован: 09 апр 2010, 09:34
- Версия LabVIEW: 8.6
- Контактная информация:
Re: Менеджер построения графов
ну ведь правильно называть граф состояний ( так в универе учили), а по поводу редкого использования, помоему всегда сначало алгоритм программы ресуют или граф состояний.(особенно если речь о программирование физических процессов)
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Менеджер построения графов
Ну скажем так - термины эти взаимозаменяемы.
http://ru.wikipedia.org/wiki/%D0%94%D0% ... E%D0%B2%29
Рисуют конечно сначалА алгоритм программы, но называется он не граф состояний а блок-схема. Со своими четкими обозначениями, описанными в ГОСТе. Граф состояний это другое.
http://ru.wikipedia.org/wiki/%D0%94%D0% ... E%D0%B2%29
Рисуют конечно сначалА алгоритм программы, но называется он не граф состояний а блок-схема. Со своими четкими обозначениями, описанными в ГОСТе. Граф состояний это другое.
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Менеджер построения графов
Я называю это UML диаграммой или стейт диаграммой, но уже не важно. Ответ на вопрос был получен я думаю?
Кстати у нас на форуме создана отдельная ветка для этого:
http://labviewportal.org/viewforum.php?f=133
Кстати у нас на форуме создана отдельная ветка для этого:
http://labviewportal.org/viewforum.php?f=133
-
- beginner
- Сообщения: 29
- Зарегистрирован: 09 апр 2010, 09:34
- Версия LabVIEW: 8.6
- Контактная информация:
Re: Менеджер построения графов
Подскажите плиз еще, State Diagram Toolkit отдельно ставиться, если да то где его качнуть для LV 8.2?? (сп всем за ответы))
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Менеджер построения графов
купить на официальном сайте NI или у российского дистрибутора.
P.S. не понимаю зачем он нужен, можно спрограммировать один к одному с бумажки используя темплейт Standart State Machine.
P.S. не понимаю зачем он нужен, можно спрограммировать один к одному с бумажки используя темплейт Standart State Machine.
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Менеджер построения графов
да, или скачать ознакомительную версию на ftp.ni.comeg писал(а):купить на официальном сайте NI или у российского дистрибутора.
P.S. не понимаю зачем он нужен, можно спрограммировать один к одному с бумажки используя темплейт Standart State Machine.
Кстати в понимании целей этого тулкита я солидарен с Женей - я тоже не понимаю зачем он нужен..
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
FireFly
- expert
- Сообщения: 1321
- Зарегистрирован: 25 апр 2009, 08:58
- Награды: 2
- Версия LabVIEW: 2014
- Откуда: Санкт-Петербург
- Поблагодарили: 1 раз
Re: Менеджер построения графов
Категорически не согласен.Indey писал(а):Слово "граф" вообще редко употребляется, имхо.
У нас в универе, да и щас на работе часто используют слово граф, и все понимают о чём идёт речь и с графиками не путают. Про теорию графов знают все (хотя не все её знают ).
Хотя я конечно понимаю что в LabVIEW созвучность русского граф и английского Graph может вносить неясность.
Иногда лучше молчать и слыть идиотом, чем заговорить и развеять все сомнения.
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: Менеджер построения графов
По-русски я это называю диаграмма состояний конечного автомата.
Насчёт блок-схемы (flowchart) и диаграммы состояний (state diagram): ПМСМ, это 2 разные вещи, освещающие ко с разных сторон. Если ты делаешь конечный автомат, то рисовать блок-схему я бы не стал. Кроме того, блок-схема совершенно не отражает ОО дизайна программы. Мне кажется, если ГОСТ этого требует, то ГОСТ просто устарел.
Нужность модуля? Ну есть стремление такое: максимально абстрагироваться от кода + обеспечить автоматическую генерацию документации. Для начинающего или для простых проектов - стремление вредное. Для больших проектов, разрабатываемых многими разработчиками, немного полезное. Мне больше по описанию нравятся продукты Endevo, а также Rational (для С++).
Ещё я помню для облегчения построения конечных автоматов было любопытное решение: LabHSM написанное уважаемым Станиславом Румегой (Stanislav Rumega). Правда оно давно не обновлялось.
Насчёт блок-схемы (flowchart) и диаграммы состояний (state diagram): ПМСМ, это 2 разные вещи, освещающие ко с разных сторон. Если ты делаешь конечный автомат, то рисовать блок-схему я бы не стал. Кроме того, блок-схема совершенно не отражает ОО дизайна программы. Мне кажется, если ГОСТ этого требует, то ГОСТ просто устарел.
Нужность модуля? Ну есть стремление такое: максимально абстрагироваться от кода + обеспечить автоматическую генерацию документации. Для начинающего или для простых проектов - стремление вредное. Для больших проектов, разрабатываемых многими разработчиками, немного полезное. Мне больше по описанию нравятся продукты Endevo, а также Rational (для С++).
Ещё я помню для облегчения построения конечных автоматов было любопытное решение: LabHSM написанное уважаемым Станиславом Румегой (Stanislav Rumega). Правда оно давно не обновлялось.
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Менеджер построения графов
В универе возможно что-то и было про графы, но универ был давно, и некоторые вещи уже стали стираться из памяти, тем более не профильные.FireFly писал(а):Категорически не согласен.Indey писал(а):Слово "граф" вообще редко употребляется, имхо.
У нас в универе, да и щас на работе часто используют слово граф, и все понимают о чём идёт речь и с графиками не путают. Про теорию графов знают все (хотя не все её знают ).
Хотя я конечно понимаю что в LabVIEW созвучность русского граф и английского Graph может вносить неясность.
На работе же я с ними никогда не сталкивался если честно. Возможно они нужны в каких-нибудь мега-больших проектах, в которых задействованы несколько человек программистов. Но я на фирме один программист LabVIEW поэтому мне они особо не требуются. Да и зачем одному человеку все эти схемы? Для восстановления памяти спустя несколько лет, в случае если понадобиться что-то отладить? У меня были такие случаи, я в этом году корректировал проект который писал 4 года назад. И ничего - разобрался. Да и потом - тонкости и трудности бывают обычно в мелочах, а если расписывать алгоритмы программ до каждой мелочи этож какие тома документации надо сотворить??
В общем по моему мнению эти вещи нужны в двух случаях:
1) Для создания отчетной документации для программы. При патентовании например.
2) Для создания отчетной документации при передаче дел своему сменщику перед увольнением.
Ни то не другое для меня пока не актуально. насчет второго - ттт
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
- interested
- Сообщения: 2
- Зарегистрирован: 21 май 2010, 20:35
- Версия LabVIEW: 9.o
- Контактная информация:
Re: Менеджер построения графов
Спасибо, что вспомнили. LabHSM позволял состояния (иерархические, с наследованием реакций на события от "родителей" к "детям"!) программировать напрямую. Может у меня мания величия конечно, но мне кажется, что именно LabHSM заставил тогда NI сделать поддержку вложенных состояний в State Diagram Toolkit. Когда они это наконец сделали, я уже не видел смысла обновлять LabHSM. В этой новой версии State Diagram Toolkit (теперь это Statechart Kit называется http://www.ni.com/labview/statechart) конечно тоже ещё не всё по уму. Например, им и в голову не приходит, что событие кроме идентификатора (имени) должно быть способно ещё и любые данные нести с собой в обработчик (там надо заранее данные передавать). Про приотизацию событий я уже и вспоминаю.mzu2006 писал(а): Ещё я помню для облегчения построения конечных автоматов было любопытное решение: LabHSM написанное уважаемым Станиславом Румегой (Stanislav Rumega). Правда оно давно не обновлялось.
Я потом попроще шаблон сделал, без поддержки иерархии, но всё равно гораздо более мощный, чем все остальные известные мне шаблоны State Machines, потому что он всё-таки разделял понятия "состояние", "действие" и "событие". Т.е. позволяет программировать автомат Мили (где действия можно ассоциировать с переходами между состояниями а не только со входами в них, как в автомате Мура, который NI до сих пор пихает как единственно возможный вариант машины состояний, отождествляя состояние и действие). Тот попроще шаблон EDQSM называется. Кому интересно, на LavaG.org посмотрите (http://lavag.org/topic/4623-simple-even ... entry25359).
Заметьте, что NI всегда делало вид, что никогда и не слышали ни про LabHSM, ни про EDQSM. Они не упоминаются ни в одной их статье на тему State Machines.
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Менеджер построения графов
Привет!!!
Очень рад встретить здесь человека - серьёзного разработчика, с которым я (и многие здесь) когда то общался
На счёт LabHSM - в какое то время мне очень хотелось его использовать, но т.к. лицензия была платной, так и не решился (в то время). Позже, после того как я научился программировать и в какой то степени приобрёл свой стиль и темплейт (на основе QSM) просто не вспоминал о каких либо тулкитах на эту тему.
В любом случае я хотел бы подробнее узнать о начинке, плюсах, возможно минусах непосредственно от разработчика. Так же хотелось бы узнть что побудило тебя, Станислав, (и возможно твою команду) спрограммировать такой тулкит.
Привет, Женя
Очень рад встретить здесь человека - серьёзного разработчика, с которым я (и многие здесь) когда то общался
На счёт LabHSM - в какое то время мне очень хотелось его использовать, но т.к. лицензия была платной, так и не решился (в то время). Позже, после того как я научился программировать и в какой то степени приобрёл свой стиль и темплейт (на основе QSM) просто не вспоминал о каких либо тулкитах на эту тему.
В любом случае я хотел бы подробнее узнать о начинке, плюсах, возможно минусах непосредственно от разработчика. Так же хотелось бы узнть что побудило тебя, Станислав, (и возможно твою команду) спрограммировать такой тулкит.
Привет, Женя
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: Менеджер построения графов
Станислав,
Автора хорошего тулкита и вспомнить приятно. Спасибо за рассказ о том, почему прекратилась разработка LabHSM. Я разобрал сейчас несколько старых твоих нитей с Autmoationlabs и с lava. Там говорилось об автогенерации кода, например, по UML спецификации (нарисованной в Visio, или как ещё). Было ли что-то сделано, что можно пощупать? Была ли уже к тому времени среда NI Requirements Gateway?styrum писал(а):Спасибо, что вспомнили.
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
- interested
- Сообщения: 2
- Зарегистрирован: 21 май 2010, 20:35
- Версия LabVIEW: 9.o
- Контактная информация:
Re: Менеджер построения графов
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).
Основные фишки 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).
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 9 Ответы
- 739 Просмотры
-
Последнее сообщение dadreamer