«Беріть знання у мене, роздаю за «дякую». Безгубенко простою мовою пояснив про автомати Мура та Мілі

Своїм попереднім постом про важливість вищої IT-освіти я зчинив великий ґвалт серед спільноти, та, більш за все, читачів хвилювало питання автоматів Мілі та Мура.

Саме для тих, хто хоче дізнатися, що ж то таке та чому я надаю таку вагу цим знанням, і призначена ця публікація.

Я спробую простою мовою пояснити те, що не змогли вам пояснити раніше викладачі. Або так сталося, що ви ці заняття пропустили, і якимось чином дожили до сьогодення, не потрапивши під роздачу, коли банк зупиняє свою роботу на пів дня, або коли в метро збирається кілометрова черга всього-на-всього через те, що IT-шник, який проектував систему, знехтував цими знаннями.

Беріть знання у мене, роздаю за «дякую!».

Вітер, що гойдає штори або автомат Мура

Отож, уявіть, що ви будуєте автоматизовану систему, яка при відкритті дверей влаштовує протяг вітру.

Опис алгоритму виглядає приблизно так: безстатева особа (мене минулого разу звинуватили у сексизмі за згадування дівчинки) відкрила двері і по приміщенню пішов гуляти вітер, гойдаючи штори. Особа закрила двері і вітер припинився.

Двері відчиняються миттєво, і одразу це має результативний вплив на штори. І закриваються двері миттєво, одразу вплив припиняється.

Тривалість часу процесу відкриття зі скрипом, не змащених дверей — відсутня. У цій моделі зміна стану дверей — відкриті / закриті відбувається за нікчемно малий проміжок часу, яким ми нехтуємо. Ми лише описуємо події про вітер по стінах.

А двері — вони як вагітність: або є або немає, або відкриті або закриті.

Це — класичний автомат Мура. Бо для нього не розглядаються залежності від проміжних станів дверей. Він вважає, що то нікчемна мура дрібниця і ігнорує її.

Ну от прикладемо цю схему до турнікету в метро: пасажир приклав до турнікету банківську карту, турнікет його пропустив, списав гроші. Або на POS-терміналі в супермаркеті: касир ввів суму, клієнт приклав картку, банк списав гроші, касир роздрукував чек. Ну або ви в інтернет-магазині вводите свій логін і пароль, та потрапляєте в кабінет з історією замовлень, обираєте пункт оплатити і вводите номер картки, і сайт пише на екрані підтвердження оплати та номер відправки на поштовій компанії.

Ніби все норм, але ні. Така автоматизація не працює.

Автомат Мілі або знову про двері

Давайте повернемося до дверей. На відміну від автомата Мура, автомат Мілі по міліметру відслідковує, як змінювався стан самого автомату всередині себе, як відбувався перехідний процес зі стану дверей «закриті» у стан «відкриті». І від цього залежить і вітер, і гойдання штор, і падіння люстри, тощо.

Ну от якщо та дивна особа взялася за ручку дверей, але не повернула? Ну от вона повернула, але ще не натиснула. Ну от натиснула і давить. Вона давить, двері відчиняються на щілину, але не зовсім. Чи піде вітер, чи гойднуться штори? А люстра? А якщо відкрили двері на половину?

А от відкривали двері, чи тикали карткою в POS-термінал, а інтернет обірвався на половині процесу. Двері зачинилися, люстра вціліла, але банк встиг отримати команду на списання грошей, а от каса чек не видала, турнікет в метро не пропустив пасажира, інтернет-магазин відправив посилку, але номер посилки клієнту не повідомив. Чому? Бо розробник тієї автоматизації будував автомат Мура, який нехтує всякою мурою. А процеси відбуваються по принципу автомата Мілі, де кожен міліметр зміни статусу всередині автомату матиме різні наслідки.

Проміжні стани

Тепер давайте більш детально розглянемо яке значення можуть мати проміжні стани самого автомата по ідеології Автомата Мілі в нашому повсякденні.

Перший Автомат Мура ми можемо розглядати як прямокутний імпульс  події що змінює свій стан миттєво, і «передній фронт цього імпульсу», перша вертикальна палка — це відкриття дверей за нікчемно малий проміжок часу.

Друга вертикальна палка (лінія падає донизу) — це миттєве закриття дверей. Між цими палками є проміжок часу, коли двері відчинені і у нас відбуваються події наших процесів – наприклад, вітер гойдає штори. Поза межами цих вертикалей двері закриті і нічого в кімнаті не відбувається.

А тепер уявіть що відкриття дверей не завжди відбувається миттєво і може залежати від купи додаткових факторів. І сукупність цих факторів може призвести до невдалих спроб відкриття дверей. І сам процес відкриття — це не миттєва, а ступенева подія з накопиченням суми факторів.

Описаний вами автомат по принципу Мура, що переймається лише силою вітра в шторах після відкриття дверей, може не завжди працювати, оскільки ви не враховуєте причини відкриття та перехідні процеси що відбуваються в дверях при їх відкритті, як показано на малюнку.

Це може мати негативні наслідки. В ІТ автомат Мілі завжди треба розглядати в клієнт-серверних системах, де є дія клієнта на одній частині системи, наприклад, в мобільному додатку або на сайті, порталі тощо. І є дія системи на самому сервері.

Все що відбувається на самому сервері (наприклад в процесингу банку) частіше всього працює по принципу автомата Мура. І сам додаток в смартфоні чи в браузері вашого пристрою буде працювати сам по собі як автомат Мура. Але вся система в комплексі з урахуванням взаємодії і клієнтської сторони і серверної а також перехідних процесів обміну між ними інформацією, отриманням підтверджень і погоджень в обидва боки зв’язку між сайтом і браузером — це автомат Мілі.

Приклади з життя

Для ще більшого розуміння приведу кілька прикладів. Ви підписуєте документ використовуючи Дія ЕЦП. Це — класичний автомат Мілі. Оскільки від моменту сканування вами QR-коду на сторінці документу до фактичного завершення підпису відбувається кілька десятків обмінів токенами і сертифікатами безпеки між сайтом документу, сайтом Дії, вашим смартфоном, оператором зв’язку, центром сертифікатів та вашою камерою смартфону. На кожному кроці може статися відміна операції і повернення до початку вибудови каналу підтвердження особи.

Ви не завжди можете це помітити, але ці двері відчиняються повільно, покроково, зі скрипом та гуркотом. І доки всі зірки на небі не вишикуються в одну лінію, всі сертифікати і токени не будуть отримані у очікуваній послідовності, ви не отримаєте підтвердження підпису документу.

Цей процес я вважаю вищим пілотажем побудови автомата Мілі. Хто зробив таку автоматизацію і додав в свої функції такий сервіс (без глюків) – герой нашого часу.

Трохи інша ситуація з метро і сплатою карткою. В київському метро ви можете сплатити карткою будь-якого банку і навіть карткою без грошей, але всього один раз. Дані вашої картки перевіряються турнікетом миттєво, локально, лише по двом аспектам – картка не прострочена і не міститься в локальному чорному списку турнікета. Якщо годиться – турнікет вас пропускає, як автомат Мура. Це необхідно щоб не було черги на вхід в метро.

А от далі турнікет передає запит мені в «Ощадбанк» і повідомляє, що ось така картка тільки що (пів години тому) була використана для проходу в метро. І вже у відкладеному режимі ми перевіряємо, якій пільговій категорії громадян належить картка і скільки з неї списати грошей за цей проїзд, з пільгами чи ні. І якщо виявляється що картка без коштів або заявлена як втрачена, то ми повідомимо на всі турнікети її номер щоб автоматично додати в чорний список. Тобто, через 15-20 хвилин цією карткою вже неможливо буде скористатися на любому турнікеті метро.

Основне що треба пам’ятати автоматизатору — якщо ми можемо знехтувати затримками у виконанні якогось кроку автоматизації, то цей фрагмент ми автоматизуємо по принципу автомата Мура і не паримося над аналізом розміру шпарини у дверному отворі. Для нас в подальшому ці двері або однозначно відкриті, або однозначно закриті. І крапка.

А от якщо ми заздалегідь знаємо що перехід з одного стану в інший супроводжується купою нюансів та можуть бути варіанти «не все так просто» — то ми цю частину нашої системи автоматизуємо по принципу автомата Мілі з подальшим врахуванням стану самого автомату та проміжних статусів його компонентів, глибини відкриття дверей. І закладаємо в систему реакцію на всі можливі варіанти цих проміжних статусів (відкрили, але не зовсім; хотіли відкрити, але передумали; почали відкривати і під кінець не втримали і захлопнули, тощо).

Надокучливі питання

Ну і далі є купа суміжних питань. Наскільки повна ваша автоматизована модель? Чи є перелік статусів, які ви можете ігнорувати, як не суттєві? Чи можуть у вашій системі разом вживатися її частини, як автомат Мура, і суміжні частини, як автомат Мілі? Або якими засобами ви поєднуєте частини вашої системи, щоб те, що ви запрограмували як Мура, не отримало впливу від сусіднього модуля, який потерпає від проміжних станів процесу, як Автомат Мілі? Між автоматами треба створювати захисний екран який перетворює багатозначність перехідних процесів в однозначні (так / ні)?

Також часто я вирішую такі питання в банківських системах, логістичних, комунікаційних кол-центрах. Ну ось, наприклад, в кол-центрі оператор готується виконати дзвінок клієнту. Він у стані «готовий». Оператор додзвонився клієнту, перейшов у стан «виконує дзвінок», але під час розмови клієнт кинув слухавку. В якому стані тепер оператор? Стан у лінії — «розрив зв’язку». Стан у клієнта – «завершив дзвінок». А стан у оператора? Ту-ту-ту-ту…

Тобто зовнішня магічна сила, що відслідковує стан цього автомата Мілі повинна для цієї ситуації насильно зачинити двері, перевести оператора у стан «обробка дзвінка після завершення». От і маємо рішення, що для функціонування цього автомату маємо написати ще одну програму, що буде за ним слідкувати і вирішувати такі обриви переходів зі стану в стан.

Не може автомат сам себе змінювати, якщо це не входить в схему його переходів з одного стану в інший. Він може бути змінений зовнішнім іншим автоматом. І якщо ви це зрозуміли і будуєте два автомати (два сервіси, джоби, чи як завгодно їх назвіть) то ви мій герой. А якщо намагаєтеся все те впихнути всередину одного і того ж автомата, то у вас нічого робочого не вийде. У програмістів це називається «вткнути костиль».

Колцентр — це сукупність великої кількості автоматів Мілі та Мура, між якими така ж велика кількість захисних екранів, які багатозначні статуси телефонної лінії чи стану клієнта, черги, чатів і операторів, перетворюють в однозначні стани «так/ні» — додзвонилися чи ні, повідомили чи ні, отримали згоду чи ні.

Висновок

Розуміння автомата Мура і автомата Мілі є нескладним, але вкрай важливим для кожного справжнього айтівця. І цей предмет (Теорія атоматів) входить у програму навчання всіх ІТ спеціальностей на самому початку. Далі без цього не можна.

Як би ви самі відреагували на закиди в коментарях попереднього мого поста «ми цього не вчили, у нас й ІТ освіти немає , але ми стали видатними програмістами»? Я не коментував такі безглузді репліки.

Цей текст з особистого блогу, опублікований з дозволу автора.