Соотношение ДС и агентных моделей
 

В ДС-модели уже есть индивидуальные объекты (заявки), что облегчает задачу ее «конвертации» в АМ: эти объекты, естественно, и станут агентами. Однако в ДС-моделировании заявки пассивны; ими управляют правила, определённые в блоках по-токовой диаграммы (flowchart). Таким образом, задача состоит в том, чтобы посмотреть на процесс с точки зрения заявки и попытаться децентрализовать некоторые из правил. Опять же, всё это имеет смысл, только если планируется учесть в агентной модели ка-кие-то индивидуальные поведения, не выражаемые в терминах ДС.
Рассмотрим простую систему обслуживания (рис. 14), где объекты (люди, тран-закции, и т.д.) входят в систему, обслуживаются (для этого требуется ресурс) один или несколько раз, в зависимости от каких-то их свойств, задерживаются на некоторое вре-мя и выходят. Эти объекты станут агентами. Событие генерации очередного объекта (заявки) будет соответствовать созданию нового агента. После создания агент запраши-вает обслуживания, но не обязательно сразу же его получает, так что у агента есть состояние ожидания Wait Resource (соответствует заявке, стоящей в очереди в блоке Service). Когда ресурс предоставлен, агент переходит в состояние обслуживания In Service (соответствует заявке, получившей ресурс и задержанной в том же блоке Service) и, по окончании обработки, решает, повторить ли процедуру или перейти в состояние задержки Delayed. По выходе из Delayed агент уничтожает себя, что соответствует заявке, выходящей из потоковой диаграммы.


Ресурсы также можно моделировать агентами, если в этом есть смысл (напри-мер, ресурсы – операторы, персонал с каким-либо индивидуальным поведением). В этом простом примере ресурсы могут иметь два состояния: свободен Idle и занят Busy. Для координации доступа к ресурсам будет необходим какой-то механизм, реализован-ный либо централизованно (диспетчер), либо децентрализованно через взаимодействие агентов.
Теперь, как и в примере Bass Diffusion, немного усложним задачу. Пусть в любой момент времени нахождения объекта в системе может произойти нечто, что заставит его немедленно покинуть систему независимо от стадии обработки (рис. 15).

Это может быть телефонный звонок, сердечный приступ, сигнал тревоги и т.п. В агентной модели это очень легко учесть: на карте состояний агента добавляется составное состояние, охватывающее все состояния, ранее нами определённые. Назовём это состояние Normal, оно будет соответствовать нормальному режиму. Из него определим переход в новое состояние Emergency Process, соответствующее процессу “аварийного покидания” системы. Переход будет срабатывать по особому событию. (При выходе из нормального процесса, возможно, придётся освободить захваченные ресурсы). В ДС-подходе такое поведение моделировать непросто, придётся вставлять специальный код во все блоки; в некоторых инструментах это вообще невозможно сделать.
 
назад

вперед