Здравствуйте, Аноним, Вы писали:
А>Как такое запрограммировать с применением конечного автомата?
По ссылке статья от студента некоего Шалыто (или иначе причастного). Судя по доступным в интернете статьям этой секты из ИТМО, ребята живут в каком-то своём, оторванном от нашей реальности мире, занимаются имитацией бурной деятельности, называют себя адептами «автоматного программирования» и на полном серьёзе считают, что двигают науку вперёд. Т.е. делают из вполне заурядного (в ремесле программиста) инструмента какой-то rocket science. Причём собственно science уже был сделан в середине прошлого века Хопкрофтом, Ульманом и прочими Ахо.
А так — да, конечные автоматы при разработке логики UI часто используются. Без нагнетания пафоса и приукрашивания заявлениями о революционности подхода. Причём фактически используются инструменты принципиально более сильные, чем теоретическая конструкция «конечный автомат», так что их часто называют «машина состояний». В C++ можно использовать Boost.Statechart или Boost.Msm, в .NET — библиотеку Stateless или Forkflow Foundation, в WPF/Metro — (несколько ограниченный) VisualStateManager.
А>Как быть если следующее состояние автомата не может быть однозначно определено парой: (<текущее_состоянием>, <выполняемое_действие>), а завит также от других факторов? В этом случае вариант с автоматной организацией интерфейса не применим или надо как-то иначе организовать автомат?
Обычное дело, в UML это называется guard condition.
Здравствуйте, Tanker, Вы писали:
Q>>Не был бы так категоричен насчёт «обязательно». В мире есть и много других отличных книг, и даже курсы на Coursera, причём от первоисточников. T>А на русском слабо показать, что бы не переводная была?
Зачем непременно непереводная? Какие-то комплексы (как у Шалыто) по поводу не отечественных разработок в computer science? В топку Ульмана — только Ершов, только хардкор?
T>А на русском слабо показать, что бы не переводная была?
Что подразумевает «слабо»? Это типа я должен кидаться доказывать, что не слабо, да?
Q>>По-моему, люди зарабатывают деньги профанацией. Они пишут горы пустых статей о ношении воды в решете, только называют это «инновационный метод транспортировки дигидрогена монооксида в ёмкости с перфорированным дном». T>Покажи профанацию в виде ссылки, абзаца и тд.
Q>>Я припоминаю исходную статью про SWITCH-технологию. Там в качестве образца их новейшей методики приводилась таки действительно switch-простыня на Си (для разбора какой-то строки, что ли), за которую в приличных конторах как минимум лишают премии, а в неприличных — коллеги устраивают «тёмную». T>Статья, абзац, цитата?
Tanker, ты случайно не из ИТМО?
Я не коллекционирую творчество г-на Шалыто, рассказал по памяти. Резона и необходимости повторно копаться в шлаке в поисках цитат у меня нет, не тот случай. Можешь просто принять к сведению оценочное суждение некоего форумчанина, можешь проверить сам, можешь отбросить как неудобное. Я же со своей стороны на юридическую строгость не претендую, если ты мне не поверишь — я совершенно не расстроюсь.
Здравствуйте, Qbit86, Вы писали:
Q>«Теоретический» конечный автомат — довольно слабоватая махина...
Обратите внимание, в указанную ссылку из Википедии тоже просочились адепты культа Шалыто со ссылками на своё «автоматное программирование» aka «SWITCH-технология», или как там их фрико-ересь называлась.
Здравствуйте, Tanker, Вы писали:
T>По моему из этого можно сделать вывод или о том, что тебе попадался только научпоп или что люди зарабатывают деньги научпопом.
По-моему, люди зарабатывают деньги профанацией. Они пишут горы пустых статей о ношении воды в решете, только называют это «инновационный метод транспортировки дигидрогена монооксида в ёмкости с перфорированным дном».
T>Я вот немного логики не понял, на основе наличия среди статей научпопа на тему автоматов ты сделал вывод про секту?
Не только я, увы.
T>Книга про автоматы у них просто отличная, студентам 2-3го курса просто обязательная к освоению.
Не был бы так категоричен насчёт «обязательно». В мире есть и много других отличных книг, и даже курсы на Coursera, причём от первоисточников.
Я припоминаю исходную статью про SWITCH-технологию. Там в качестве образца их новейшей методики приводилась таки действительно switch-простыня на Си (для разбора какой-то строки, что ли), за которую в приличных конторах как минимум лишают премии, а в неприличных — коллеги устраивают «тёмную». Ну и всё перемежалось тоннами самолюбования господина Шалыто о том, как к нему приходят все советоваться, как писать ПО для самолётов, и он всем всё понятно разъясняет (не написав в жизни ни строчки).
Здравствуйте, Sharov, Вы писали:
Q>>Причём фактически используются инструменты принципиально более сильные, чем теоретическая конструкция «конечный автомат», так что их часто называют «машина состояний».
S>А Вы не могли по подробнее раскрыть тему...
«Теоретический» конечный автомат — довольно слабоватая махина, пригодная для разбора максимум регулярного языка. Число состояний в них конечно, в то время как в «программистских» конечных автоматах их может быть фактически бесконечное число (т.е., например, можно использовать для разборка контекстно свободных грамматик). С точки зрения программиста, состояния MyState(42.0, "Hello") и MyState(3.14, "World") — это два состояния одного стостояния (тавтология, да), в то время как с точки зрения теории их нужно признавать разными состояниями. Второй момент, что переходы могут зависеть не только от пары <текущее состояние, пришедшее событие>, но и от состояния этого события (Event(1928, "Jackie Brown") или Event(1956, "John Doe")) или вообще от фазы луны. Далее, в машинах состояний в описании перехода указывается не только целевое состояние, как в классических конечных автоматах, но и action, то есть произвольное действие, которое может при необходимости читать/писать состояние машины/мира.
S>...желательно с сылками?
UML state machine, also known as UML statechart, is a significantly enhanced realization of the mathematical concept of a finite automaton in computer science applications as expressed in the Unified Modeling Language (UML) notation.
(Кстати, automata — это лат. множественное число от «автомат», почему автор обсуждаемой статьи его использует в примерах?)
Ещё неплохо раскрывается тема (в частности, иерархически вложенные состояния/машины) в документации к Boost.Statechart.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Аноним, Вы писали:
А>>Как такое запрограммировать с применением конечного автомата? LVV>Это два разных состояния автомата. LVV>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта. LVV>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
На практике — сложнее. Мы ведь хотим все правильно сделать? Значит для "статус введенных данных" появлюятся как минимум три состояния:
* Данные корректны
* Данные некорректны
* Данные проверяются (выполняется асинхронный запрос).
Может быть, еще и четвертое состояние (ошибка асинхронного запроса). Из третьего состояния может быть спонтанный переход по "внешнему" (не пользовательскому) событию в остальные. Из любого из этих четырех на одно событие (пользовательский ввод) может быть переход в третье состояние (т.е. начало асинхронной загрузки). Если чуть усложнять, будет еще и переход в любое из трех состояний (например, мы кэшируем балансы счетов на клиенте). И еще подобная груда стрелочек будет для каждого события "ввод суммы платежа".
Теперь нужно учесть, что есть какие-то другие состояния, т.е. на самом деле будет произведение <some states> * <payment state>, в общем, душераздирающее зрелище. Хотя в UML стоит попробовать нарисовать, чтобы убедиться, что конечные автоматы туда плохо подходят. Или нужна хорошая библиотечка комбинаторов.
А еще у КА есть идеологические проблемы. Например, заносить ли "вычислимое состояние" в еще одну размерность автомата. Ладно у ТС пример с async'ом. А ведь может быть ветвление и полностью синхронное (форма подтверждения пароля). Вот будет ли автомат в виде (<password1> * <password2>) (минимальный набор) или в виде (<password1> * <password2> * <confirmed successfully>) (удобное для действий). Чисто математически, это вообще одно и то же множество. Но ведь на практике <password1> очень захочется записать "одним" состоянием, а не их бесконечным множеством. Там мы получим все те проблемы, которые возникли у ТС.
На практике иметь понятие "Состояние" очень удобно. И привязываться к нему для выполнения набора действий — тоже. А формализовывать состояние до универсального КА — не стоит. Т.е. на практике работает композиция. Например, базовые состояния a, b, c, и d. Какое-то вычислимое состояние e = f1(a, c), другое вычислимое состояние g = f2(e, a, d) и т.д. В нужных проверках используются только отдельные состояния, UI биндится только к нужным состояниям, события меняют только нужные базовые состояния и т.п. Математически это, конечно, переводится в КА, только вот на практике результат получается печальный. А само выделение явных состояний таки полезно — оно позволяет все "нетривиальные сценарии" пользователя заставить более-менее продумывать (если все параметры UI вычисляются только от моделей, придется хотя бы задуматься о некорректных состояниях).
статью, оценил оригинальность идеи, а потом попытался притянуть ее к реальной ситуации и кое-чего не понял.
Как быть если следующее состояние автомата не может быть однозначно определено парой: (<текущее_состоянием>, <выполняемое_действие>), а завит также от других факторов? В этом случае вариант с автоматной организацией интерфейса не применим или надо как-то иначе организовать автомат?
Например.
Есть диалог, в котором надо выбрать из плана счетов счет плательщика, ввести сумму платежа и разные другие параметры, а затем нажать кнопку "Сохранить".
По одному из требований бизнес-логики введенные параметры считаются корректными, если на выбранном счете плательщика есть остаток не ниже заданной суммы платежа.
Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать.
Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.
Как такое запрограммировать с применением конечного автомата?
Q>Причём фактически используются инструменты принципиально более сильные, чем теоретическая конструкция «конечный автомат», так что их часто называют «машина состояний».
А Вы не могли по подробнее раскрыть тему, желательно с сылками?
Здравствуйте, Аноним, Вы писали:
А>Есть диалог, в котором надо выбрать из плана счетов счет плательщика, ввести сумму платежа и разные другие параметры, а затем нажать кнопку "Сохранить". А>По одному из требований бизнес-логики введенные параметры считаются корректными, если на выбранном счете плательщика есть остаток не ниже заданной суммы платежа. А>Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать. А>Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.
А>Как такое запрограммировать с применением конечного автомата?
Это два разных состояния автомата.
Если введенные данные корректны — переходим в новое состояние, где кнопка открыта.
Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
На диаграмме — это петля в вершине графа автомата (она же — диаграмма состояний в UML).
А вообще построение автомата надо начинать с рисования графа состояний...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Qbit86, Вы писали:
Q>По ссылке статья от студента некоего Шалыто (или иначе причастного). Судя по доступным в интернете статьям этой секты из ИТМО, ребята живут в каком-то своём, оторванном от нашей реальности мире, занимаются имитацией бурной деятельности, называют себя адептами «автоматного программирования» и на полном серьёзе считают, что двигают науку вперёд. Т.е. делают из вполне заурядного (в ремесле программиста) инструмента какой-то rocket science. Причём собственно science уже был сделан в середине прошлого века Хопкрофтом, Ульманом и прочими Ахо.
Я вот немного логики не понял, на основе наличия среди статей научпопа на тему автоматов ты сделал вывод про секту ? По моему из этого можно сделать вывод или о том, что тебе попадался только научпоп или что люди зарабатывают деньги научпопом.
Книга про автоматы у них просто отличная, студентам 2-3го курса просто обязательная к освоению.
The animals went in two by two, hurrah, hurrah...
Re[2]: Применимость конечных автоматов в GUI
От:
Аноним
Дата:
17.01.13 09:00
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта. LVV>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
Так в том-то и дело, что не понятно как в классическом конечном автомате (автомате Мура например) реализовать ветвление...
LVV>А вообще построение автомата надо начинать с рисования графа состояний...
Это само собой, просто я пытаюсь остаться в пределах классической модели конечного автомата, не вводя всякие узлы-разветвители.
И такое складывается впечатление, что пытаюсь натянуть противогаз на глобус... Причем глобус какой-то квадратный получается.
Просто я с универа (уже 10 лет прошло) как-то обходился без КА. "Традиционных" способов хватало.
А тут вдруг оригинальную идею встретил, решил попробовать, а гибкость мышления в направлении КА уже атрофировалась как-то.
Расширить модель всякими "отсебятинами" можно конечно, но это я на крайний случай оставляю.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, LaptevVV, Вы писали:
LVV>>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта. LVV>>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?) А>Так в том-то и дело, что не понятно как в классическом конечном автомате (автомате Мура например) реализовать ветвление...
D автомате переход зависит от сигнала на ребре.
Вершина автомата — там вычисляется некая функция, которая выдает, например, true или false
Соответственно, либо переход, либо — нет
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Qbit86, Вы писали:
Q>По-моему, люди зарабатывают деньги профанацией. Они пишут горы пустых статей о ношении воды в решете, только называют это «инновационный метод транспортировки дигидрогена монооксида в ёмкости с перфорированным дном».
Покажи профанацию в виде ссылки, абзаца и тд.
Q>Не был бы так категоричен насчёт «обязательно». В мире есть и много других отличных книг, и даже курсы на Coursera, причём от первоисточников.
А на русском слабо показать, что бы не переводная была ?
Q>Я припоминаю исходную статью про SWITCH-технологию. Там в качестве образца их новейшей методики приводилась таки действительно switch-простыня на Си (для разбора какой-то строки, что ли), за которую в приличных конторах как минимум лишают премии, а в неприличных — коллеги устраивают «тёмную».
Здравствуйте, Qbit86, Вы писали:
Q>Я не коллекционирую творчество г-на Шалыто, рассказал по памяти. Резона и необходимости повторно копаться в шлаке в поисках цитат у меня нет, не тот случай. Можешь просто принять к сведению оценочное суждение некоего форумчанина, можешь проверить сам, можешь отбросить как неудобное. Я же со своей стороны на юридическую строгость не претендую, если ты мне не поверишь — я совершенно не расстроюсь.
Вобщем, все ясно, "мотороллер не его, он просто дал объяву" @ Выглядит так, как будто эти ребята тебе чего то прищемили
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, LaptevVV, Вы писали:
LVV>>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта. LVV>>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?) А>Так в том-то и дело, что не понятно как в классическом конечном автомате (автомате Мура например) реализовать ветвление...
А насколько у вас классический автомат? Совсем простейший автомат не имеет никакой памяти. Т.е. "В поле Х введено А" и "В поле Х введено Б" — это разные состояния автомата (потому что иначе он их не отличит). Введение памяти (а вот у нас состояние St с контекстом <X=A>) заставляет усложнять механику автомата. Появляются guards на стрелках перехода, например, которые такой "автомат" разделяют обратно в "классический" автомат без памяти (точнее, в другую группу "склеенных" состояний).
статью, оценил оригинальность идеи, а потом попытался притянуть ее к реальной ситуации и кое-чего не понял.
В принципе, все, что имеет состояния и переходы из одного в другое, это КА. Если при разработке их вовремя формализовывать, то можно избежать многих проблем.
А>Как быть если следующее состояние автомата не может быть однозначно определено парой: (<текущее_состоянием>, <выполняемое_действие>), а завит также от других факторов? В этом случае вариант с автоматной организацией интерфейса не применим или надо как-то иначе организовать автомат?
В таком случае не надо пытаться натягивать сами знаете что на глобус. КА — это КА, пытаться заставить КА делать то, для чего он не предназначен, чревато state explosion и соответствующим трешем.
А>Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать. А>Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.
А>Как такое запрограммировать с применением конечного автомата?
Конечный автомат в данном случае представляет собой состояние формы, даже не всей формы, а кнопки "Сохранить". Выглядит такой КА примерно вот так
И, что самое смешное, реализуется этот автомат посредством установки SaveButton.enabled в true или false.
А вот уже сама проверка условий не входит в сферу ответственности КА и запихивать ее туда не надо, облом выйдет.
Здравствуйте, Privalov, Вы писали:
P>Ну, вот эта статья, например.
Блин, я как раз завтракал, когда открыл так называемый исходный, прости господи, код в ПРИЛОЖЕНИЕ 1 и ПРИЛОЖЕНИЕ 2. Да там вся статья феерична, включая список литературы.
Здравствуйте, Qbit86, Вы писали:
Q>Блин, я как раз завтракал, когда открыл так называемый исходный, прости господи, код в ПРИЛОЖЕНИЕ 1 и ПРИЛОЖЕНИЕ 2. Да там вся статья феерична, включая список литературы.
Ну извини, я совсем не намеревался испортить тебе аппетит. Просто я когда-то пытался читать монографию "SWITCH-технология", ну и вспомнил, где искать примеры примерения этой технологии. А о книжке я как-то упоминал
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Tanker, Вы писали:
T>>Статья, абзац, цитата ?
P>Ну, вот эта статья, например.
О, дайте мне это развидеть.
Разработка унитаза с улучшенной смываемостью по сравнению с ЭТИМ должна тянуть на пять Нобелевских премий по всем номинациям сразу.
Немного конструктивной критики — эта т.н. switch технология широко используется в автоматизации производственных процессов с 70-х годов во всевозможных PLC.
