Хорошие ответы. На практических уровнях интеграции это очень важно. Интеграционный слой
с гистерезисом это сама подсистема. Понятно, что идеалом является отсутствие гистерезиса (машина Мура); но, как правило, существует несоответствие в конечных автоматах каждой из систем, и это может быть решено только переводчиком, использующим гистерезис. Например, модуль полевой службы Microsoft Dynamics / Great Plains записывает состояние в своей таблице журнала аудита основного обслуживания SVC00210. Каждый звонок находится в каком-то SRVSTAT. При интеграции планировщика, такого как планировщик оптимизации сервисов ClickSoftware, необходимо работать с его состоянием. Состояние CS определяется пользовательской реализацией. Например. Открыто, InRoute, OnSite, Incomplete, Cancelled, Complete. Кроме того, он также находится в состоянии незавершенности с ожидающими деталями, хотя он реализован как вспомогательный автомат в незавершенном состоянии. Итак, переходы в GP должны отображаться в CS. К сожалению, GP допускает (делает запись на экране ввода для вызова) переходы из одного состояния в себя; таким образом, событие перехода не может использоваться исключительно для запуска изменения состояния в GP. Следовательно, новое событие триггера представляет собой комбинацию перехода состояния GP, а также мета-состояния, определенного некоторой логикой на множестве прошлых событий. Как видите, гистерезис быстро превращает проблему из простого в сложный. С точки зрения компьютерных наук, идеалом является машина Мура, а практической - машина Мили. Я предпочитаю думать об этом как о мучной муке с жуками, живущими в ней, и все!
Я думаю, что возможно изготовить машину Мура из любой машины Мили, у машины Мура будет просто больше состояний. См .: Мили v / s. Мур