![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rКогда трава была зеленее, небо выше, за компьютерами работали люди с натуральным высшим образованием, и ещё существовали программы, не содержащие ошибок, были известны и использовались многие очень полезные методы, технологии и приёмы.
Сейчас они применяются только старыми опытными профессионалами, по какой-то причине не ушедшими в менеджмент. Иногда можно найти их изуродованные и раскрашенные под лубок следы в «передовых изобретениях» и «новейших открытиях». Современные учёные компьютерных наук и производители ррреволюционных тулов, когда с ними заговариваешь на эту тему, делают круглые глаза и уходят в несознанку. Подрастающее поколение вообще не понимает о чём речь. И только в редких случаях, в особо интимной обстановке коллегиальной пьянки можно изредка услышать от престарелых гуру и консультантов «Да. Конечно оно так. И лучше. И надёжнее. Но, ты понимаешь, спросом не пользуется.»
Почему так произошло? Одна из причин, неумолимый закон ИТ индустрии Worse is better. Про него все знают и я не буду дальше раскрывать этот аспект. А вот о другой, не менее существенной причине, я расскажу ниже.
Из всего потерянного на пути от научной разработки к индийским программистам мне больше всего не хватает STT (State Transition Table).
Конечный автомат получает сигнал, переходит в новое состояние и выполняет какие-то операции. Или в другом варианте получает сигнал, выполняет какие-то операции и переходит в новое состояние.
Новое состояние может быть тем же самым. В определённом состоянии конечный автомат может игнорировать какие-то сигналы, и есть сигналы, которые в таком состоянии придти не могут. То есть, если мы их получаем, то где-то в логике работы системы закралась ошибка.
Всё просто и банально. Можно запрограммировать это большой бородой if-else, можно нарисовать диаграммку с кучей стрелочек. Можно жульнически написать на функциональном языке, таская состояние в параметрах вызова. Чего нельзя сделать, так это описать в туле сигналы и состояния, сгенерить таблицу, расставить значения по клеточкам, а потом нажать кнопку и получить в одном окне красивые диаграммки, а в другом - работающий код.
Даже те редкие тулы, которые это умели, не в состоянии делать это в новых версиях. Разве что кроме тех немногих, что обитают где-то на задворках индустрии, не очень удобны в применении и дороги как престарелая Нокия, инкрустированная бриллиантами.
Если то, что тебе нужно, нельзя ни купить, ни найти, сделай это сам. Слева - сигналы, справа - состояния.
Выше почти не изменённый код реального проекта. На прошлой неделе я сделал нечто подобное снова, уже на другом языке и немного по-другому.
В чём тут фокус?
Первым делом я могу изменить логику поведения системы, просто поменяв одно значение на другое. Можно записать логику в файл и передать её по сети. Можно сгенерировать UML State Transition Diagram. Но всё это полезные добавления. Главным и наиболее ценным свойством является жестокосердие.
Сигналы и переходы полностью описывают поведение конечного автомата. То есть: полностью. Я могу забыть какой-то сигнал и получить ошибку в тесте или в поле. Я могу забыть состояние и получить поведение, не соответствующее требуемому. Я могу поставить в клеточку фигню или просто ошибиться. Чего я не могу сделать - это проигнорировать комбинацию сигнала и состояния.
Как-то я сделал подобную таблицу в Экселе и, когда на митинге она возникла на экране, сказал примерно следующее:
- Уважаемые коллеги. Я внимательно прочитал главу техзадания с функциональными требованиями. Все двадцать восемь страниц, и изучил все стоящие там картинки. Я формализовал то, что я понял. Но тут есть два места, где стоят толстые красные вопросительные знаки. Что должно произойти в этих двух случаях? Должно тут стоять «IGNORE», «ERROR» или что-нибудь ещё?
Минут пять продолжалась борьба с «Я не понимаю» и «У нас нет времени, давайте обсудим что-нибудь другое», а последующее вылилось в сорок минут обсуждения, неделю перекидывания мейлами и серьёзные изменения в финальной версии техзадания.
Это очень долгий, очень недемонстрационный процесс. Практически час митинга на то, чтобы написать два значения.
Практически все жестокосердные методики столь же компактны. Как-то мы с одним мужиком писали функциональную спецификацию на псевдокоде. Средняя цена вышла по одному человекочасу на две строчки.
Шестьдесят строчек - это одна страница. Покажите менеджеру документ и скажите, что страница стоит тысячу евро. И посмотрите на его лицо.
А теперь представьте, что с другого бока к этому менеджеру подходит экзальтированный Skrum Master и обещает счастье для всех, почти даром, и так, что никто от него не укроется.
Я частенько писал документацию, где страница стоила и в десять раз больше. Но это было скрыто в куче митингов, разъездов, мейлов, и никому не нужной писанины. Но попробуйте сказать среднему нормальному менеджеру, что целью недели работы будет десяток страниц текста.
Да, из этого псевдокода были сгенерированы диаграммы. На его основе были расставлены приоритеты. Открытые ошибки были отклассифицированы и расставлены по релизам. В результате проект вышел из штопора и смог скрипя и почти не разваливаясь доползти до стадии он-лайн.
Но сделать этот документ удалось только потому, что менеджменту было просто пофиг, чем мы там вдвоём с этим мужиком занимаемся. Менеджмент в это время храбро тонул в потоке новостей от отдела тестирования, что дало нам окно для свободной работы.
Конечно, таблица тридцать на тридцать - это место, где можно закопаться всерьёз и надолго. Но тем и отличается аналитик от аналоха, что он сделает не это, а три размерностью десять на десять. Чтобы было понятно. И чтобы задача решалась просто. Но даже таблица на девять сотен не проставленных реакций на сигнал лучше, чем её отсутствие. Потому что бардак будет точно такой же, а вот увидеть его в полном объёме не удастся даже настоящим экспертам.
Но самое главное, самое ценное для результата и самое вредное для распространения STT в массах - выше упомянутое жестокосердие. Это безжалостная методика, не дающая поблажек.
Тут нельзя нарисовать или не нарисовать стрелочку так, чтоб никто этого не заметил. В ячейке таблицы стоит или IGNORE, или ERROR, или новое состояние, или жирный красный вопросительный знак. И ни умные рассуждения о перспективах развития энтерпрайза, ни рассказы о важности и не важности, ни упоминания послемитингового обеда не ответят на вопрос «Что должно тут быть и почему?»
В немецкой культуре люди привыкли, что у каждой проблемы есть ответ, и этот ответ им известен. Причём, известен на уровне экспертном. Если, вдруг, ответ не известен, то вопрос ерундовый и малозначащий. И они экспертно объяснят это.
Порой приходиться выслушивать совершенно бредовые рассуждалки на уровне детского сада. Причём, все как-бы знают, что это может быть не совсем правильно и не совсем так. Но, если высказывание сделано громким уверенным голосом, человеком обличённым экспертными полномочиями, то так оно и есть. И сомневаться просто не прилично. Примерно на том же уровне, как ковыряться в носу за обедом.
Обычно у меня статус эксперта и мне часто задают разные вопросы. Иногда дельные, иногда идиотские. Но это как-бы получение дополнительных и не относящихся к области компетенции знаний из правильного источника. Только один раз ко мне подошёл коллега не из русскоговорящих и сказал «Слушай, у меня есть один глупый вопрос.» Он был студентом. И французом.
А вот этот гадкий жирный вопросительный знак в клетке STT таблицы как заноза встаёт посреди корпоративной культуры, плюёт на все написанные в визитке «Доктор Компьютерных Наук» или «Самый Главный Аналитик» и заставляет выдавить из себя предательское «Не знаю.»
У всех производителей тулов, которые поддерживали SST я постоянно спрашивал, есть ли у них, вдруг, клиенты в Германии. Ответ был неизменно отрицательным.
Продолжение может быть будет когда-нибудь потом. Сейчас хочется вернуться к более весёлым темам
Сейчас они применяются только старыми опытными профессионалами, по какой-то причине не ушедшими в менеджмент. Иногда можно найти их изуродованные и раскрашенные под лубок следы в «передовых изобретениях» и «новейших открытиях». Современные учёные компьютерных наук и производители ррреволюционных тулов, когда с ними заговариваешь на эту тему, делают круглые глаза и уходят в несознанку. Подрастающее поколение вообще не понимает о чём речь. И только в редких случаях, в особо интимной обстановке коллегиальной пьянки можно изредка услышать от престарелых гуру и консультантов «Да. Конечно оно так. И лучше. И надёжнее. Но, ты понимаешь, спросом не пользуется.»
Почему так произошло? Одна из причин, неумолимый закон ИТ индустрии Worse is better. Про него все знают и я не буду дальше раскрывать этот аспект. А вот о другой, не менее существенной причине, я расскажу ниже.
Про зазнайство, жестокосердие и утерянные технологии
Из всего потерянного на пути от научной разработки к индийским программистам мне больше всего не хватает STT (State Transition Table).
Конечный автомат получает сигнал, переходит в новое состояние и выполняет какие-то операции. Или в другом варианте получает сигнал, выполняет какие-то операции и переходит в новое состояние.
Новое состояние может быть тем же самым. В определённом состоянии конечный автомат может игнорировать какие-то сигналы, и есть сигналы, которые в таком состоянии придти не могут. То есть, если мы их получаем, то где-то в логике работы системы закралась ошибка.
Всё просто и банально. Можно запрограммировать это большой бородой if-else, можно нарисовать диаграммку с кучей стрелочек. Можно жульнически написать на функциональном языке, таская состояние в параметрах вызова. Чего нельзя сделать, так это описать в туле сигналы и состояния, сгенерить таблицу, расставить значения по клеточкам, а потом нажать кнопку и получить в одном окне красивые диаграммки, а в другом - работающий код.
Даже те редкие тулы, которые это умели, не в состоянии делать это в новых версиях. Разве что кроме тех немногих, что обитают где-то на задворках индустрии, не очень удобны в применении и дороги как престарелая Нокия, инкрустированная бриллиантами.
Если то, что тебе нужно, нельзя ни купить, ни найти, сделай это сам. Слева - сигналы, справа - состояния.
private static final int[][] STATE_TABLE = {
//=========================================================================================================|
// | INIT | CHECK_PRECOND | REGISTRATION | WAIT_ACCEPTED | LEVEL_OK |
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* START */ { CHECK_PRECOND , INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* PRE_CONDITIONS */ ,{ INIT , REGISTRATION , INT_ERROR , WAIT_ACCEPTED , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* NOT_PRE_CONDITIONS */ ,{ INIT , INIT , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* REGISTRATION_DONE */ ,{ INIT , CHECK_PRECOND , WAIT_ACCEPTED , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* REGISTRATION_FAIL */ ,{ INIT , INT_ERROR , INIT , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* ACCEPTED */ ,{ INIT , INT_ERROR , INT_ERROR , LEVEL_OK , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* INT_ERROR */ ,{ INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
};
Выше почти не изменённый код реального проекта. На прошлой неделе я сделал нечто подобное снова, уже на другом языке и немного по-другому.
В чём тут фокус?
Первым делом я могу изменить логику поведения системы, просто поменяв одно значение на другое. Можно записать логику в файл и передать её по сети. Можно сгенерировать UML State Transition Diagram. Но всё это полезные добавления. Главным и наиболее ценным свойством является жестокосердие.
Сигналы и переходы полностью описывают поведение конечного автомата. То есть: полностью. Я могу забыть какой-то сигнал и получить ошибку в тесте или в поле. Я могу забыть состояние и получить поведение, не соответствующее требуемому. Я могу поставить в клеточку фигню или просто ошибиться. Чего я не могу сделать - это проигнорировать комбинацию сигнала и состояния.
Как-то я сделал подобную таблицу в Экселе и, когда на митинге она возникла на экране, сказал примерно следующее:
- Уважаемые коллеги. Я внимательно прочитал главу техзадания с функциональными требованиями. Все двадцать восемь страниц, и изучил все стоящие там картинки. Я формализовал то, что я понял. Но тут есть два места, где стоят толстые красные вопросительные знаки. Что должно произойти в этих двух случаях? Должно тут стоять «IGNORE», «ERROR» или что-нибудь ещё?
Минут пять продолжалась борьба с «Я не понимаю» и «У нас нет времени, давайте обсудим что-нибудь другое», а последующее вылилось в сорок минут обсуждения, неделю перекидывания мейлами и серьёзные изменения в финальной версии техзадания.
Это очень долгий, очень недемонстрационный процесс. Практически час митинга на то, чтобы написать два значения.
Практически все жестокосердные методики столь же компактны. Как-то мы с одним мужиком писали функциональную спецификацию на псевдокоде. Средняя цена вышла по одному человекочасу на две строчки.
Шестьдесят строчек - это одна страница. Покажите менеджеру документ и скажите, что страница стоит тысячу евро. И посмотрите на его лицо.
А теперь представьте, что с другого бока к этому менеджеру подходит экзальтированный Skrum Master и обещает счастье для всех, почти даром, и так, что никто от него не укроется.
Я частенько писал документацию, где страница стоила и в десять раз больше. Но это было скрыто в куче митингов, разъездов, мейлов, и никому не нужной писанины. Но попробуйте сказать среднему нормальному менеджеру, что целью недели работы будет десяток страниц текста.
Да, из этого псевдокода были сгенерированы диаграммы. На его основе были расставлены приоритеты. Открытые ошибки были отклассифицированы и расставлены по релизам. В результате проект вышел из штопора и смог скрипя и почти не разваливаясь доползти до стадии он-лайн.
Но сделать этот документ удалось только потому, что менеджменту было просто пофиг, чем мы там вдвоём с этим мужиком занимаемся. Менеджмент в это время храбро тонул в потоке новостей от отдела тестирования, что дало нам окно для свободной работы.
Конечно, таблица тридцать на тридцать - это место, где можно закопаться всерьёз и надолго. Но тем и отличается аналитик от аналоха, что он сделает не это, а три размерностью десять на десять. Чтобы было понятно. И чтобы задача решалась просто. Но даже таблица на девять сотен не проставленных реакций на сигнал лучше, чем её отсутствие. Потому что бардак будет точно такой же, а вот увидеть его в полном объёме не удастся даже настоящим экспертам.
Но самое главное, самое ценное для результата и самое вредное для распространения STT в массах - выше упомянутое жестокосердие. Это безжалостная методика, не дающая поблажек.
Тут нельзя нарисовать или не нарисовать стрелочку так, чтоб никто этого не заметил. В ячейке таблицы стоит или IGNORE, или ERROR, или новое состояние, или жирный красный вопросительный знак. И ни умные рассуждения о перспективах развития энтерпрайза, ни рассказы о важности и не важности, ни упоминания послемитингового обеда не ответят на вопрос «Что должно тут быть и почему?»
В немецкой культуре люди привыкли, что у каждой проблемы есть ответ, и этот ответ им известен. Причём, известен на уровне экспертном. Если, вдруг, ответ не известен, то вопрос ерундовый и малозначащий. И они экспертно объяснят это.
Порой приходиться выслушивать совершенно бредовые рассуждалки на уровне детского сада. Причём, все как-бы знают, что это может быть не совсем правильно и не совсем так. Но, если высказывание сделано громким уверенным голосом, человеком обличённым экспертными полномочиями, то так оно и есть. И сомневаться просто не прилично. Примерно на том же уровне, как ковыряться в носу за обедом.
Обычно у меня статус эксперта и мне часто задают разные вопросы. Иногда дельные, иногда идиотские. Но это как-бы получение дополнительных и не относящихся к области компетенции знаний из правильного источника. Только один раз ко мне подошёл коллега не из русскоговорящих и сказал «Слушай, у меня есть один глупый вопрос.» Он был студентом. И французом.
А вот этот гадкий жирный вопросительный знак в клетке STT таблицы как заноза встаёт посреди корпоративной культуры, плюёт на все написанные в визитке «Доктор Компьютерных Наук» или «Самый Главный Аналитик» и заставляет выдавить из себя предательское «Не знаю.»
У всех производителей тулов, которые поддерживали SST я постоянно спрашивал, есть ли у них, вдруг, клиенты в Германии. Ответ был неизменно отрицательным.
Продолжение может быть будет когда-нибудь потом. Сейчас хочется вернуться к более весёлым темам
Copyright
(CC BY-NC-ND 3.0) 
vit_r, 2012
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Перевод на английский запрещён, потому как нефиг портить хорошую вещь.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-26 04:36 pm (UTC)p.s.
ну и вот вообще http://ru.wikipedia.org/wiki/Switch-%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
правда первую его книгу я нещадно выкинул так как решил что автор меня дурит, но вторую которую он мне подарил, читать гораздо интереснее и там более доходчиво
no subject
Date: 2012-10-26 04:47 pm (UTC)С тех пор методика была много раз имплиментирована вручную, подведена под UML, получила названия xUML, Executable UML, потом xtUML, поддерживающие это тулы стали достаточно мощными, научились, тестировать на моделях, производить код под разные платформы и языки и добились достаточно сложной для данной задачи оптимизации, были использованы во многих серьёзных проектах. (Правда только под embedded и не в Германии.)
Когда Шатыло дойдёт хотя бы до состояния вопроса на конец девяностых годов, или просто прочитает и поймёт первоисточники, свистни.
no subject
Date: 2012-10-26 05:24 pm (UTC)Очень хочется узнать, что в ней нет из того, что А.А.Шатыло проповедует сейчас как новейший прорыв в разработке софта.
no subject
Date: 2012-10-27 05:52 am (UTC)А сомневающихся в популярных в данный момент методиках и гуру во все времена как минимум подвергали остракизму, а как максимум сжигали на кострах.
Да что говорить о деталях когда через 40 лет после написания Бруксом книжки практически все проекты считают в человекочасах. :(
no subject
Date: 2012-10-27 07:11 am (UTC)Также знаю фирмы, которые хотя бы изображают, что считают размеры в Function Points. Правда таких мало. Прятать косяки в Scrum менеджерам гораздо выгоднее.
no subject
Date: 2024-01-08 03:12 pm (UTC)Нафига столько переходов в состояние INT_ERROR? Почему не IGNORE?
no subject
Date: 2024-01-08 03:16 pm (UTC)no subject
Date: 2024-01-08 04:12 pm (UTC)На сайте Sunburst Design раз в несколько лет выходит документ со свежей методикой построения Finite State Mashine. Щас там лежит ряд документов с 1998 по 2019. В документах и в примерах из прошлого века я не заметил подобных фанатичных обработок ошибок в FSM.
no subject
Date: 2024-01-08 04:48 pm (UTC)Если написать "Я использую Verilog и конечные автоматы для дизайна микросхем", то это совсем не то, что "Я использую конечные автоматы для mission critical софта" или "Я использую конечные автоматы для веб-сервиса с большой нагрузкой и низкими требованиями надёжности". Критерии оптимизации будут совсем другие.
Грубо говоря, для уровня железа этот метод имеет смысл использовать только для разработки. Когда дизайн разработан, оттестирован и зафиксирован, лишние проверки надо убирать и переходить от INT(ernal)_ERROR к IGNORE.
Потому как INT_ERROR выдаётся при ошибке дизайна или каких-то системных сбоях (вроде ошибки памяти). Также ошибку ставят в первоначальной версии, когда считают, что сообщение приходить не может, но получив сообщение, начинают разбираться, как и почему оно появилось, а потом добавляют соответствующий переход в схему конечного автомата.
Тут, действительно, нет другого пути как посмотреть первоисточники и прикинуть, что подходит для собственных задач. А ещё лучше, попробовать таким способом сделать чего-то посложнее учебного примера.
no subject
Date: 2024-01-08 05:16 pm (UTC)no subject
Date: 2024-01-08 03:15 pm (UTC)no subject
Date: 2024-01-08 03:20 pm (UTC)Тут же написано, что речь об утерянных технологиях. Можно найти что-нибудь из упомянутых выше источников информации. Можно считать это как данность.(Первый путь более продуктивен.)
no subject
Date: 2024-01-08 04:01 pm (UTC)no subject
Date: 2024-01-08 04:22 pm (UTC)Студенческое программирование сильно отличается от промышленного. Потому и стоит прочитать упомянутые источники.
no subject
Date: 2024-01-08 05:14 pm (UTC)Интересно. Оказывается у программистов есть завершающие состояния автоматов, где происходит конец жизненного цикла экземпляра.
Но я работаю на языках HDL, hardware description language. Грубо говоря язык описания цифровых микросхем, для получения железа, не для софта.
В моих автоматах не может быть концов жизненных циклов по физическим причинам.
no subject
Date: 2024-01-09 02:02 am (UTC)То есть, система не должна выдавать никаких выходных сигналов
- до завершения инициализации (первый столбец в таблице)
- при обнаруженном внутреннем сбое (состояние INTernal_ERROR, для которого столбца нет, потому что там всё банально -- при любом сигнале идёт re-entry в INT_ERROR)
- и при начавшемся отключении питания (в примере состояние LEVEL_OK, в железе POWER_OFF).
В правильном варианте INT_ERROR - это запись всех данных в (юридически стабильный) лог и перезапуск из сохранённого гарантированно стабильного состояния (в случае mission critical может быть и аварийная остановка управляемого объекта вплоть до подрыва и физической самоликвидации).
Конечное состояние для объектно-ориентированном варианта -- это вызов функции delete для объекта, а в других подходах -- ручное или полуавтоматическое освобождение памяти и занятых ресурсов.
А _ignore_ (строчными буквами, потому что не переход) тут нет просто из-за особенностей реализации в данном конкретном случае. А так, игнорирование должно отличаться от повторного входа в то же самое состояние, потому что вход в состояние -- это процесс, который может вызывать какие-то внутренние действия и посылку внешних сигналов.
Надо бы написать про автоматы. Всё-таки, за дюжину лет понимание немного улучшилось.