Здравствуйте, petr_t, Вы писали:
V>>Просто "спецы" могут увлечься, могут проигнорировать составление и следование планам и графикам и т.д. _>Плох тот спец, у которого планирование работы и инкрементальная разработка не стали привычкой.
ЧТД. Вот тебе база UP.
Сам с собой споришь. ))
Re[6]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, Sinix, Вы писали:
S>ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
Здравствуйте, vdimas, Вы писали:
V>Не хочешь поделиться опытом, хотя бы в двух словах.
В реализации КА на мейнстримовых ЯВУ существуют две проблемы. Первая — это собственно нахождение приемлимого подхода к реализации КА с более чем двумя-тремя состояниями. Вторая — собственно в понимании того, что именно есть КА.
V>Применяли ли НКА вместо ДКА, например?
В нашей предметной области (не парсеры, а именно физические автоматы — роботы, исполнительные устройства, разнообразные сервисы и прочий полтергейст) НКА в принципе не должны применяться, но после анализа кода часто оказывалось, что реализован был именно НКА, что являлось ошибкой и причиной трудноуловимых багов.
V>Или, как в классике, насильно вводили "эквивалентные процессы", то бишь, разбивали автомат на подавтоматы, то бишь, отказывались от конечности автомата, получая почти МТ в итоге? ))
Вообще-то разбитие КА на подавтоматы — это один из простых способов его минимизации и избегания State Explosion.
На самом деле проблема тут очень проста. Каждый раз делается одна и та же ошибка — начинают реализовывать автомат, не имея диаграммы состояний (таблицы переходов, алфавита с функцией переходов и т.п., называй как удобно) перед глазами. Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. Обычно таблица переходов в коде просто отсутствует. Затем, вследствие отсутствия структуры изначального автомата, при отладке попытке заставить все это работать начинается все вышеописанное — превращение ДКА в НКА, а то и в самовозбуждающийся генератор, и state explosion.
Исправлять проблему state explosion в имеющемся коде, который уже вышел в продакшен — это большой нуегонафиг. Был случай, когда коллега, получивший от другого подразделения некий код, основывающийся на КА, решил выяснить, почему именно дальнейшее расширение и поддержка этого кода застопорились. Написал простой парсер и скормил его plantuml. Получил диаграмму одного автомата с 90 состояниями. И хотя эквивалентные процессы из этой диаграммы стали очевидными, стало понятно, что рефакторинг в данном случае будет синонимом полного переписывания с нуля.
Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем. Фреймворки, в которых таблица переходов существует в коде явно, тоже являются хорошим подспорьем — мы в итоге выработали свой похожий на бустовский FSM подход.
Re[11]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
S>>ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
V>Кстате, вспомнил про неплохой давний пост коллеги насчет "предварительного проектирования": V>"Бронебойные методики" были выработаны на больших (по тем временам) проектах.
Так я в хорошем смысле про бронебойные методики, "тяжёлый — значит надёжный"(c). При употреблении по месту, конечно. А вот с этим были баальшие проблемы, ибо тот самый ореол универсальной методики. Вплоть до попыток организовать курсы по RUP в виде "группа просто работает по RUP, организуясь в процессе". Мне в этом дурдоме повезло не участвовать, но рассказов наслушался.
Мне честно лень спорить, тем более что разговор вообще ушёл от "как оно было в прошлый раз на практике" к "как оно должно быть, в этот раз у них всё получится". Пока я не увидел ни одного принципиального отличия, те же грабли, те же люди.
Re[12]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>ЧТД. Вот тебе база UP. V>>Сам с собой споришь. ))
_>Черта с два. Пара простых практических правил, которым надо следовать — совсем не то же самое, что талмуд правил и вагон бюрократии.
Здравствуйте, landerhigh, Вы писали:
V>>Не хочешь поделиться опытом, хотя бы в двух словах. L>В реализации КА на мейнстримовых ЯВУ существуют две проблемы. Первая — это собственно нахождение приемлимого подхода к реализации КА с более чем двумя-тремя состояниями. Вторая — собственно в понимании того, что именно есть КА.
Странно, странно.
V>>Применяли ли НКА вместо ДКА, например?
L>В нашей предметной области (не парсеры, а именно физические автоматы — роботы, исполнительные устройства, разнообразные сервисы и прочий полтергейст) НКА в принципе не должны применяться, но после анализа кода часто оказывалось, что реализован был именно НКА, что являлось ошибкой и причиной трудноуловимых багов.
Ясно. Но жаль, жаль. Если предметная область позволяет явно выделить "промежуточные" состояния от "конечных", то на промежуточных вполне допустима неоднозначность и весь аппарат НКА в полный рост. Да, именно в парсерах это самая мощная на сегодня техника.
V>>Или, как в классике, насильно вводили "эквивалентные процессы", то бишь, разбивали автомат на подавтоматы, то бишь, отказывались от конечности автомата, получая почти МТ в итоге? ))
L>Вообще-то разбитие КА на подавтоматы — это один из простых способов его минимизации и избегания State Explosion.
И способ потери контроля над его детерминированностью. ))
L>На самом деле проблема тут очень проста. Каждый раз делается одна и та же ошибка — начинают реализовывать автомат, не имея диаграммы состояний (таблицы переходов, алфавита с функцией переходов и т.п., называй как удобно) перед глазами.
А, ну это при более 7-ми состояний и более двух десятков переходов — амба, ес-но. Тогда и говорить не о чем. Текстовое описание уже трудноверифицируемое в итоге.
А как представляли КА? Обязательно ли граф переходов, или допустимы регулярные выражения? Например (просто делюсь), в одной из разработок было удобней проектировать ДКА на основе регулярных выражений (не тех, которые regexp в Перле/JS и т.д., а именно класс грамматик). Входным сигналам был назначен алфавит и на основе этого алфавита были введены "пути" для целевых состояний. Удобным получилось то, что в этом случае доступен весь аппарат минимизации целевого КА по состояниям/переходам, а так же по кодированию самих состояний.
L>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду.
Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
L>Обычно таблица переходов в коде просто отсутствует.
Есть несколько популярных техник реализаций КА в ЯВУ. Таблица переходов, не смотря на удобство кодогенерации, не самая удачная. (Но, фактически, единственный вариант, когда автомат задан прямо в коде в виде исходного НКА, во время старта программы этот НКА преобразуется в ДКА, минимизируется, кодируется и получается в виде таблицы). Хождение "автомата" по таблице переходов — это классика интерпретации, т.е. когда программа выполняет данные. На switch/case + goto получаются до полутора-двух раз более более шустрые автоматы. В этом случае "курсором" состояния является не специально выделенная переменная, а положение указателя команд в автоматной процедуре.
L>Затем, вследствие отсутствия структуры изначального автомата, при отладке попытке заставить все это работать начинается все вышеописанное — превращение ДКА в НКА, а то и в самовозбуждающийся генератор, и state explosion. L>Исправлять проблему state explosion в имеющемся коде, который уже вышел в продакшен — это большой нуегонафиг. Был случай, когда коллега, получивший от другого подразделения некий код, основывающийся на КА, решил выяснить, почему именно дальнейшее расширение и поддержка этого кода застопорились. Написал простой парсер и скормил его plantuml. Получил диаграмму одного автомата с 90 состояниями. И хотя эквивалентные процессы из этой диаграммы стали очевидными, стало понятно, что рефакторинг в данном случае будет синонимом полного переписывания с нуля.
Ну я так и думал, что такое писали околопрограммисты. Профильные специальности гоняют по автоматам последние 3 года обучения.
L>Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем.
Не обязательно UML, порой удобней старый добрый граф переходов, особенно когда нет иерархии состояний или "разрывов".
L>Фреймворки, в которых таблица переходов существует в коде явно, тоже являются хорошим подспорьем — мы в итоге выработали свой похожий на бустовский FSM подход.
Цена такому "фреймворку" — полторы сотни строк темплейтного кода. Например, в одной из реализаций я принял за "курсор" состояния адрес ф-ии, которая вычисляет следующее состояние + текущий выход. Эдакая разновидность паттерна "State", где CurrentState-интерфейс содержал всего одну ф-ию, и вся кухня в итоге выродилась до, собственно, адреса этой ф-ии. Для отладки это оказалось большим бонусом, кста.
Re[11]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Ясно. Но жаль, жаль. Если предметная область позволяет явно выделить "промежуточные" состояния от "конечных", то на промежуточных вполне допустима неоднозначность и весь аппарат НКА в полный рост. Да, именно в парсерах это самая мощная на сегодня техника.
НКА в таких случаях — мина замедленного действия.
L>>Вообще-то разбитие КА на подавтоматы — это один из простых способов его минимизации и избегания State Explosion.
V>И способ потери контроля над его детерминированностью. ))
Вот не согласен, хотя и правда — запутаться проще простого.
L>>На самом деле проблема тут очень проста. Каждый раз делается одна и та же ошибка — начинают реализовывать автомат, не имея диаграммы состояний (таблицы переходов, алфавита с функцией переходов и т.п., называй как удобно) перед глазами.
V>А, ну это при более 7-ми состояний и более двух десятков переходов — амба, ес-но. Тогда и говорить не о чем. Текстовое описание уже трудноверифицируемое в итоге.
Больше трех, на самом деле.
V>А как представляли КА? Обязательно ли граф переходов,
Нужен паттерн State. С явной таблицей переходов.
L>>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. V>Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
Паттерн State — штука хорошая, но не решает проблему таблицы переходов.
L>>Обычно таблица переходов в коде просто отсутствует. V>В этом случае "курсором" состояния является не специально выделенная переменная, а положение указателя команд в автоматной процедуре.
можно использовать корутины. Но тут нужно сильно бить себя по рукам, чтобы избежать соблазна затолкать всю логику КА в одну процедуру. Но мы пользуем темплейты, примерно тем же способом, как ты ниже описал — быстрее не бывает.
V>Ну я так и думал, что такое писали околопрограммисты. Профильные специальности гоняют по автоматам последние 3 года обучения.
Вот не угадал. Еще раз, по моим наблюдениям — нормальную реализацию КА с большей вероятностью сделают инженеры не-программерских специальностей.
L>>Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем. V>Не обязательно UML, порой удобней старый добрый граф переходов, особенно когда нет иерархии состояний или "разрывов".
Дело в том, что можно скрестить doxygen с plantuml. Диаграмма состояний описывается прямо в комментариях к коду и попадает в документацию автоматически. Программисты техподдержки долго ссали кипятком по всем направлениям, увидев такое чудо.
L>>Фреймворки, в которых таблица переходов существует в коде явно, тоже являются хорошим подспорьем — мы в итоге выработали свой похожий на бустовский FSM подход. V>Цена такому "фреймворку" — полторы сотни строк темплейтного кода. Например, в одной из реализаций я принял за "курсор" состояния адрес ф-ии, которая вычисляет следующее состояние + текущий выход.
В правильной реализации вычислять следующее состояние в рантайме вообще не требуется — все известно в компайл тайм. Бонусом выступают бесплатные проверки компилятором того, что автор не забыл обработать входной сигнал и машина не содержит дублирующих переходов. Ну а наличие явно определенной в коде таблицы переходов вообще бесценно — моментально вправляет мозги любому ее увидевшему.
V>Эдакая разновидность паттерна "State", где CurrentState-интерфейс содержал всего одну ф-ию, и вся кухня в итоге выродилась до, собственно, адреса этой ф-ии. Для отладки это оказалось большим бонусом, кста.
Адреса этой функции или же адреса объекта, описывающего и обрабатывающего состояние. Я первую реализацию делал для ардуинки, получив оверхед по памяти в один указатель.
А вот отлаживать КА нам после внедрения юнит-тестирования и шаблонного фреймворка больше не пришлось ни разу.
Здравствуйте, landerhigh, Вы писали:
V>>А как представляли КА? Обязательно ли граф переходов, L>Нужен паттерн State. С явной таблицей переходов.
Спорно насчет "нужен". Если у тебя автомат Мура, то интерфейс CurentState будет пуст.
Далее, чем мне зачастую не нравится State. Дело в том, State удобен только для реализации той части функциональности автомата Мили, когда текущий выход автомата зависит от текущего состояния. В этом случае ф-ии интерфейса CurrentState являются теми самыми функциональными преобразователями входных сигналов в выходные, зависимые от состояния. Пока что всё ОК. Но беда в том, что программисты зачастую помещают логику вычисления следующего состояния в этот же CurrentState, в итоге в одном методе получается мешанина из двух независимых функций: функции текущего "поведения" и ф-ии вычисления следующего состояния.
L>>>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. V>>Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
L>Паттерн State — штука хорошая, но не решает проблему таблицы переходов.
Не обязательно переходы должны быть в виде явной таблицы. Раздели State на два состояния: первое пусть отвечает за "поведение", второе — за следующее состояние. Для их связки тебе надо будет создать некий транспорт — искусственные сигналы (в некоей кодировке), которые вырабатывает первый State для второго, т.е. кодирует некий "алфавит" сводя разнотиповые "внешние сигналы" к одному типу-коду из "алфавита". В этом случае становится возможным отдельно тестировать тот State, который отвечает за поведение и отдельно, отвечающий за переходы. Эта конструкция имеет право на жизнь при сильно разреженной таблице переходов, т.е. когда от каждого состояния в среднем оч мало переходов в следующие.
L>можно использовать корутины. Но тут нужно сильно бить себя по рукам, чтобы избежать соблазна затолкать всю логику КА в одну процедуру.
В случае корутин — да запросто. Опять же, техника корутин оправдана только при push распространении воздействий (обработка событий, например), в этом случае никакой паттерн State не нужен.
V>>Ну я так и думал, что такое писали околопрограммисты. Профильные специальности гоняют по автоматам последние 3 года обучения. L>Вот не угадал. Еще раз, по моим наблюдениям — нормальную реализацию КА с большей вероятностью сделают инженеры не-программерских специальностей.
Ну знач разные наблюдения.
L>>>Наличие же поддерживаемой в актуальном состоянии диаграммы стейтов рядом с кодом обычно помогает избежать этих проблем. V>>Не обязательно UML, порой удобней старый добрый граф переходов, особенно когда нет иерархии состояний или "разрывов".
L>Дело в том, что можно скрестить doxygen с plantuml. Диаграмма состояний описывается прямо в комментариях к коду и попадает в документацию автоматически. Программисты техподдержки долго ссали кипятком по всем направлениям, увидев такое чудо.
Спасибо за наводку.
Re[13]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Спорно насчет "нужен". Если у тебя автомат Мура, то интерфейс CurentState будет пуст.
Паттерн State вообще имеет очень опосредованное отношение к КА. Он просто отображает состояние некоей сущности. У нас, например, поведение некоего мощного объекта зависит от его текущего состояния.
V>Но беда в том, что программисты зачастую помещают логику вычисления следующего состояния в этот же CurrentState, в итоге в одном методе получается мешанина из двух независимых функций: функции текущего "поведения" и ф-ии вычисления следующего состояния.
Эта "беда" фиксится довольно просто — CurrentState просто не имеет возможности вычислить и установить следующее состояние (интерфейс не позволяет), но может подать входной сигнал.
L>>>>Сложность реализации КА на ЯВУ ведет к тому, что наличие КА в коде становится крайне неочевидным, а логика его — размазанной по коду. V>>>Это смотря как реализовать. Например, на ЯВУ удобно реализовать более мощный Мили, чем Мура. Как раз ООП-паттерн "State" — это про Мили.
L>>Паттерн State — штука хорошая, но не решает проблему таблицы переходов.
L>>можно использовать корутины. Но тут нужно сильно бить себя по рукам, чтобы избежать соблазна затолкать всю логику КА в одну процедуру. V>В случае корутин — да запросто. Опять же, техника корутин оправдана только при push распространении воздействий (обработка событий, например), в этом случае никакой паттерн State не нужен.
Согласен.
L>>Вот не угадал. Еще раз, по моим наблюдениям — нормальную реализацию КА с большей вероятностью сделают инженеры не-программерских специальностей.
V>Ну знач разные наблюдения.
У меня подозрение, что профильных программистов настолько закормили парсерами и формальными автоматами, что они банально за деревьями леса не видят.
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, beyv, Вы писали:
... B>Вы уверены что 1 + 1 = 2? Да, для двух спичек это верно — если сложить одну и одну спички получим две спички, а для двух капель воды это неверно, если сложить две капли воды получим одну каплю воды logic_error
Не в математике проблема, а в том, что кто-то не думаючи перегрузил оператор сложения для капель воды. Тут нужно использовать оператор "слияние".
Re[13]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Я не могу комментировать чьи-то мечты. Описанная тобой ситуация ни разу не новость. Гораздо обидней, когда собираются спецы, а проект заваливают. Подсказка сработала или опять мимо?))
Само существование этого сайта как бы намекаэ, что не все так печально, не?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, craft-brother, Вы писали:
CB>А что-то про SEMAT тут никто еще не написал? Исправляем.
Можно я тут чутка пофлужу? Проскроллил пост по диагонали и вспомнил, что бы когда-то такой прекрасный сайт, назывался пиши-код-[beep].рф (к сожалению, на территории .РФ его давно заблокировали и с тех пор домен протух). Ну, по крайней мере англоязычный вариант сохранился.
Re[8]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, AndrewVK, Вы писали:
V>>Я не могу комментировать чьи-то мечты. Описанная тобой ситуация ни разу не новость. Гораздо обидней, когда собираются спецы, а проект заваливают. Подсказка сработала или опять мимо?)) AVK>Само существование этого сайта как бы намекаэ, что не все так печально, не?
Дык, "заваленный проект" — это не потому, что люди оказались в принципе неспособны его сделать (такого практически не бывает), а потому что не вложились в сроки/деньги. А так-то любой проект, при желании, можно довести до ума. Особенно дотационный какой-нить, опен-сорс или как этот сайт — интересу ради.
Re[9]: SEMAT – Единая Теория Всего Программирования?
V>Дык, "заваленный проект" — это не потому, что люди оказались в принципе неспособны его сделать (такого практически не бывает), а потому что не вложились в сроки/деньги. А так-то любой проект, при желании, можно довести до ума. Особенно дотационный какой-нить, опен-сорс или как этот сайт — интересу ради.
Угу, вообще технически сложных задач не бывает. Бывает недостаток времени и отсутствие воли.
CB>А что-то про SEMAT тут никто еще не написал? Исправляем. >Единая Теория Всего Программирования
Это не теория программирования, это теория управления процессом проектирования
программирования. или, если просто, то проектный менеджмент.
ошибка перевода. software engineering — общий процесс, программирование только одна фаза этого процесса. >Within software engineering, programming (the implementation) is regarded as one phase in a software development process. http://en.wikipedia.org/wiki/Computer_programming
так что для программирования нужно что-то более мелкое по охвату (но не мелко-мягкое )) ).
