CC BY
17
Интернет-журнал «Науковедение» ISSN 2223-5167 http ://naukovedenie.ru/ Том 8, №5 (2016) http ://naukovedenie. ru/index.php?p=vol8-5 URL статьи: http://naukovedenie.ru/PDF/50TVN516.pdf Статья опубликована 31.10.2016 Ссылка для цитирования этой статьи:
Мьё Тхет Наунг, Девятков В.В. Формальная проверка правильности сетевого взаимодействия агентов, специфицируемых на языке процессных выражений // Интернет-журнал «НАУКОВЕДЕНИЕ» Том 8, №5 (2016) http://naukovedenie.ru/PDF/50TVN516.pdf (доступ свободный). Загл. с экрана. Яз. рус., англ.
УДК 004.413
Мьё Тхет Наунг
ФГБОУ ВПО «Московский государственный технический университет им. Н.Э. Баумана», Россия, Москва
Аспирант кафедры «Информационные системы и телекоммуникации»
E-mail: [email protected]
Девятков Владимир Валентинович
ФГБОУ ВПО «Московский государственный технический университет им. Н.Э. Баумана», Россия, Москва
Зав. кафедры «Информационные системы и телекоммуникации»
Доктор технических наук, профессор E-mail: deviatkov@ bmstu.ru
Формальная проверка правильности сетевого взаимодействия агентов, специфицируемых на языке
процессных выражений
Аннотация. Настоящая статья посвящена развитию методики формальной проверки правильности взаимодействия агентов, моделирующих сетевое взаимодействие. Поведение агентов специфицируется на языке процессных выражений. Взаимодействующие агенты широко применяются для моделирования сетевых взаимодействий, использующих различные протоколы. Автоматизацию проверки правильности спецификаций предлагается осуществлять логическими программами, получаемыми с помощью представленной в настоящей статье методики перехода от канонических процессных выражений, специфицирующих поведение агентов, а также требований правильности взаимодействия на языке модальной логики. В качестве языка логического программирования для проверки правильности сетевого взаимодействия используется Visual Prolog. Настоящая статья развивает методику, изложенную в предыдущих статьях авторов. Основное отличие изложенного в статье материала от уже опубликованных результатов состоит в использовании не графового описания поведения агентов, а канонического символического, ограничивающего выразительность описания, но облегчающего переход от него к логической программе и формулировку требований правильности на языке модальной логики. Методика формальной проверки правильности сетевого взаимодействия иллюстрируется простым примером логической программы, на одной из ранних версий языка Visual Prolog, позволяющей проверять требования обязательной реакции для случая двух взаимодействующих агентов.
Ключевые слова: агент; сетевое взаимодействие; модальная логика; проверка правильности; канонические процессные выражения; язык логического программирования.
1. Введение
Для описания поведения агентов и их взаимодействия могут использоваться различные языки. Так, например, в работе [1] использовались графы переходов. Одними из самых популярных языков, используемых для этих целей, является язык, который будем называть языком процессных выражений, являющийся вариантом языка алгебры (пи-исчисления) Роберта Милнера [2]. Процессные выражения предлагают достаточно естественный путь описания параллельных систем, состоящих из процессов, взаимодействующих по общим каналам. Однако главный вопрос, который мы хотели бы обсудить, - это какими должны быть процессные выражения, для того, чтобы с их помощью можно было однотипно описывать различные архитектуры взаимодействующих агентов с возможностью как можно более эффективной проверки различных требований к правильности взаимодействия по этим процессным выражениям.
Для такого обсуждения воспользуемся спецификацией на языке процессных выражений двух простых взаимодействующих агентов UAC и UAS, рассмотренных в работе [1] и унаследованных из работы [2]. Взаимодействие агентов осуществляется с помощью обмена сообщениями по 10 каналам, имена которых ackc, brpc, irpc, reqc, sake, acks, brps, irps, reqs, saks (рис. 1).
Рисунок 1. Взаимодействующие агенты UAC и UAS (рисунок авторов)
Каналы ackc, brpc, irpc, reqc, sake являются входными для агента UAC и выходными для агента UAS, а каналы acks, brps, irps, reqs, saks наоборот - выходными для агента UAC и входными для агента UAS. Каждый из агентов может выполнять только шесть типов действий соответственно: invitee, invsuccc, invfaile, ackc, byec, byeRspc и invites, invsuccs, invfails, acks, byes, byeRsps. Если какое-либо сообщение a берется из канала с именем ch, то оно является восприятием и записывается как ch?a, если же оно выдается в канал с, то оно является реакцией и записывается как ch!a.
Процессные выражения, описывающие поведение агентов UAC и UAS подробно представлены ниже. Описание начинается с выражения UA=UAC 11 UAS, задающего параллельное поведение агентов. Описание каждого агента начинается с описания одноименного процесса верхнего уровня (UAC или UAS) указанием в левой части процессного выражения имени процесса, а в правой после знака равенства - имени канала и действия, связанного с этим каналом, а затем подпроцесса, вызываемого после совершения действия. В такой же форме описываются подпроцессы процессов, подпроцессы
подпроцессов и т.д. использование каналов и действий может быть недетерминированным, что указывается знаком. Взаимодействие агентов начинается с выполнения процессов верхнего уровня. Какой из агентов является инициатором взаимодействия оговаривается особо.
UA=UAC 11 UAS UAC = reqc!invite.Inviting
Inviting = ackc!ack.0
I irps?invFail.Ending
Процесс UAC посылает в свой выходной канал reqc запрос !invite процессу UAS на разрешение обслуживания и вызывает процесс Inviting.
Процесс Inviting инициации связи с процессом UAS.
Процесс Inviting посылает в свой выходной канал ackc сообщение !ack для дальнейшего обслуживания.
Процесс Inviting процесса UAC получает в своем входном канале irps сообщение ?invFail от процесса UAS об отказе обслуживания по запросу ! invite и переходит к выполнению процесса Ending окончания связи с процессом UAS.
irps?invSucc.sakc!ack.Confirming Процесс Inviting процесса UAC получает в своем входном
канале irps сообщение ?invSucc от процесса UAS о согласии на обслуживание сообщения !ack, после чего процесс UAC, выдает в канал sakc уведомление о получении согласия на обслуживание сообщения ! ack и переходит к выполнению процесса Confirming.
reqs?bye.brpc!byeRsp.Ending
I brps?byeRsp.0
Confirming = irps?invFail.0
I irps?invSucc.0
I reqs?bye.brpc!byeRsp. brps?byeRsp.Ending
Процесс Inviting процесса UAC получает в своем входном канале reqs сообщение ?bye от процесса UAS о прекращении с ним связи, выдает в ответ в канал brpc прощальное сообщении !byeRsp процессу UAS и переходит к процессу Ending окончания связи с процессом UAS.
Процесс Inviting процесса UAC получает в своем входном канале brps входное прощальное сообщение ?byeRsp от процесса UAS о прекращении с ним связи и сразу переходит к процессу 0 прекращения своей активности.
Процесс Confirming ожидающий конца обслуживания сообщения !ack процессом UAS.
Процесс Confirming процесса UAC получает в своем входном канале irps сообщение ?invFail от процесса UAS о неправильном запросе ! invite и прекращает свою активность.
Процесс Confirming процесса UAC получает в своем входном канале irps сообщение ?invSucc от процесса UAS об успешном запросе ! invite и прекращает свою активность.
Процесс Confirming процесса UAC получает в своем входном канале reqs сообщение ?bye от процесса UAS о
I reqc!bye.Byeing
Byeing = irps?invFail.0
I irps?invSucc.0 I reqs?bye.brpc!byeRsp.0
brps?byeRsp.Ending
Ending = irps?invFail.0
irps?invSucc.0
reqs?bye.brpc!byeRsp.0
brps?byeRsp.0
завершении обслуживания, выдает в ответ в канал brpc прощальное сообщение !byeRsp процессу UAS, получает от него в канале brps уведомление ?byeRsp о получении сообщения ! byeRsp и переходит к процессу Ending окончания связи с процессом UAS.
Процесс Confirming процесса UAC выдает в свой выходной канал reqc выходное сообщение !bye процессу UAS о прекращении ожидания от него конца обслуживания и переходит к процессу Byeing.
Процесс Byeing извещения процессом UAC окончания связи с процессом UAS.
Процесс Byeing процесса UAC получает в своем входном каналеirps сообщение ?invFail от процесса UAS о неправильном запросе ! invite и прекращает свою активность.
Процесс Byeing процесса UAC получает в своем входном канале irps сообщение ?invSucc от процесса UAS об успешном запросе ! invite и прекращает свою активност.
Процесс Byeing процесса UAC получает в своем входном канале reqs сообщение ?bye от процесса UAS о прекращении с ним связи, выдает в ответ в канал brpc прощальное сообщение !byeRsp процессу UAS и прекращает свою активность.
Процесс Byeing процесса UAC получает в своем входном канале brps входное сообщение ?bye от процесса UAS о прекращении с ним связи и переходит к процессу завершения работы процесса UAC.
Процесс Ending завершения работы процесса UAC.
Процесс Ending процесса UAC получает в своем входном канале irps сообщение ?invFail от процесса UAS о неправильном запросе ! invite и прекращает свою активность.
Процесс Ending процесса UAC получает в своем входном каналеirps сообщение ?invSucc от процесса UAS об успешном запросе ! invite и прекращает свою активность.
Процесс Ending процесса UAC получает в своем входном канале reqs сообщение ?bye от процесса UAS о прекращении с ним связи, выдает в ответ в канал brpc прощальное сообщение !byeRsp процессу UAS и прекращает свою активность.
Процесс Ending процесса UAC получает в своем входном канале brps входное прощальное сообщение ?byeRsp от процесса UAS и прекращает свою активность.
UAS = reqc?invite.Invited
Invited = ackc?ack.0
I reqc?bye.0
I brpc?byeRsp.0
I irps!invFail.Ended
I irps!invSucc.Confirmed
Confirmed =
ackc? acked. acks ! acked .0
I reqc?bye.brps!byeRsp.0
I brpc?byeRsp.Ended
Byed =
ackc? ack. acks ! acked .0
I reqc?bye.brps!byeRsp.0
Процесс UAS получает в своем входном канале и вызывает процесс Invited.
Процесс Invited инициации связи с процессом UAC.
Процесс Invited процесса UAS получает в своем входном канале ackc запрос на обслуживание ?ack от процесса UAC и переходит в неактивное состояние.
Процесс Invited процесса UAS получает в своем входном канале reqc сообщение ?bye о конце связи от процесса UAC и переходит в неактивное состояние.
Процесс Invited процесса UAS получает в своем входном канале brpc прощальное сообщение ?byeRsp от процесса UAC и переходит в неактивное состояние.
Процесс Invited процесса UAS выдает в свой выходной канал irps сообщение! invFail о неправильном запросе ! invite от процесса UAC и переходит к выполнению процесса Ended.
Процесс Invited процесса UAS выдает в свой выходной канал irps сообщение !invSucc о правильном запросе ! invite от процесса UAC и переходит к выполнению процесса Confirmed.
Процесс Confirmed подтверждения связи с процессом UAC
Процесс Confirmed процесса UAS получает в своем входном канале ackc запрос на обслуживание ?ack от процесса UAC, выдает ему сообщение на согласие обслуживания ! acked и переходит в неактивное состояние.
Процесс Confirmed процесса UAS получает в своем входном канале reqc сообщение о конце связи ?bye от процесса UAC, выдает в свой выходной канал brps сообщение ! byeRsp о прекращении с ним связи и переходит в неактивное состояние.
Процесс Confirmed процесса UAS получает в своем входном канале brpc прощальное сообщение ?byeRsp от процесса UAC и переходит к выполнению процесса Ended.
Процесс Byed извещения процесса UAC об окончании с ним связи процессом UAS.
Процесс Byed процесса UAS получает в своем входном канале ackc запрос на обслуживание ?ack от процесса UAC, выдает ему в канал acks сообщение на согласие обслуживания ! acked переходит в неактивное состояние.
Процесс Byed процесса UAS получает в своем входном канале reqc сообщение о конце связи ?bye от процесса UAC, выдает в свой выходной канал brps сообщение !byeRsp о прекращении с ним связи и переходит в неактивное состояние.
I brpc?byeRsp.Ended Ended =
ackc? ack. acks! acked .0
reqc?bye.brps!byeRsp.0
brpc?byeRsp.0
Процесс Byed процесса UAS получает в своем входном канале brpc прощальное сообщение ?byeRsp от процесса UAC и переходит к выполнению процесса Ended.
Процесс Ended завершения работы процесса UAS.
Процесс Ended процесса UAS получает в своем входном канале ackc запрос на обслуживание ?ack от процесса UAC, выдает ему в канал acks сообщение на согласие обслуживания ! acked и переходит в неактивное состояние.
Процесс Ended процесса UAS получает в своем входном канале reqc сообщение о конце связи ?bye от процесса UAC, выдает в свой выходной канал brps сообщение !byeRsp о прекращении с ним связи и переходит в неактивное состояние.
Процесс Ended процесса UAS получает в своем входном канале brpc прощальное сообщение ?byeRsp от процесса UAC и переходит в неактивное состояние.
2. Формулировка и проверка требований к правильности взаимодействия агентов
Во многих работах, например, работе [3] для формулировки требуемых свойств интерфейсов предлагается использовать широко применяемую в области программных систем предварительную формулировку этих свойств на языке временной модальной логики. Поскольку этот язык хорошо изучен и известен [4, 5], то в настоящей статье не будем уделять ему слишком много внимания. Обсудим недостатки приведенного описания на языке процессных выражений поведения агентов UAC и UAS с точки зрения возможности эффективных проверок на примере простого требования правильности, называемого свойством обязательной реакции [3]. В простейшем случае суть этого свойства для нашего примера с двумя агентами иАС и UAS состоит в том, что в ответ на любую реакцию, поступающую в выходной канал одного агента, являющийся входным для другого, последний должен получить эту реакцию в виде восприятия и среагировать на него по своему выходному каналу, являющуюся входным для первого агента. Последний должен воспринять эту реакцию. Будем использовать введённые выше обозначения еИ8 входных для агента C и выходных для агента UAS каналов и обозначения еИС каналов входных для агента UAS и выходных для агента иАС Тогда на языке модальной логики формулировка некоторого свойства обязательной реакции может выглядеть следующим образом:
{(Р1 = сИС !а, ) =э ОГСР1 = сИС ? а, ) =э 0((Р 2 = сИ 51 ! а ,) =э 0(Р 2 = сИ 51 ? а , ) ) 1 }
4 иас 1 / >-V иая 1 / ^ч иая 2 У 4 иас 2 /У J *
Здесь
Р 1 = с НС ! а , Р 1 = сНС ? а , Р 2 = сНЗ ! а , Р 2 = сНЗ ? а
иас 1 ' иаз 1 ' иаз 2 ' иас 2
• предикаты с предикатным символом "=", представленные в инфиксной форме. Значение этих предикатов истинно, когда выполняется процесс, именуемый в левой части равенств, выполнение которого состоит в помещении в канал, именуемый в правой части сообщения, следующего после имени канала. Имена процессов, каналов и действий в этих предикатах являются переменными.
Формулировка любого свойства взаимодействия агентов на языке модальной логики -это по существу утверждение, которое требует определенной процедуры доказательства. В
частности, свойство обязательной реакции, сформулированное в разделе 2 предполагает, что поведение агентов UAC и UAS должно обладать определенным порядком выполнения процессов. Это означает, что в описании поведения агентов на языке процессных выражений
для любого процессного выражения Риас = скС ! а 1 агента иЛС должно найтись процессное
выражение процесса Риа° = скС ? а 1 агента UAS, а для любого процессного выражения
Р 2 = скЗ ! а _ тт л о Р2 = скБ ? а ттл/^
2 агента иЛа процессное выражение иас агента Ц^С, причем
1 12 2 Р , Р , Р , Р
выполнение процессов иас иас осуществляется в порядке слева направо.
Приведенное свойство обязательной реакции не единственное. В принципе, этих свойств может быть сколь угодно много, например, в зависимости от структуры восприятий и реакций, процессов, осуществляющих их выдачу и получение, и, может быть, каких - либо дополнительных условий.
Глядя на приведенное выше описание поведения процессов ЦАС и UAS, с точки зрения возможности организации формальной проверки по этому описанию правильности взаимодействия можно выделить следующие недостатки этого описания.
1. Имена подпроцессов вводятся, исходя из субъективных соображений функционального разбиения процессов UAC и UAS на подпроцессы.
2. Подпроцессы могут состоять из подпроцессов, разделяемых знаком | и никак не поименованных.
3. Нити действий подпроцессов могут иметь различную длину.
4. Имена каналов имеют обозначения, которые, в случае числа агентов большего двух, не позволяют определить, каким агентам они смежны.
5. Число уровней процессов ограничено двумя.
6. Функциональность процессов ограничена восприятиями и реакциями, помещаемыми в каналы.
7. Нет никакой информации о том, в какие каналы в ответ на реакцию должно поступать восприятие и наоборот.
Указанные недостатки описания взаимодействия агентов даже для проверки свойства обязательной реакции требуют выделения всех взаимодействующих подпроцессов и каналов по которым это взаимодействие осуществляется. Это может быть осуществлено преобразованием процессных выражений к некоторому каноническому виду, в котором указанное выделение осуществлено. Для случая простого взаимодействия двух агентов UAC и иЛБ это преобразование представляется разрешимым, поскольку обозначения каналов однозначно определяют, какие из них являются входными или выходными для каждого процесса, а подпроцессы, имеющие длину нитей более 1, могут быть разбиты на подпроцессы с именами, удовлетворяющими формулировке свойства обязательной реакции.
В более сложных случаях взаимодействия агентов разрешимость преобразования далеко не очевидна. Поэтому на наш взгляд предпочтительнее идти по пути не преобразований, а по пути использования для описания поведения агентов канонических процессных выражений.
3. Канонические процессные выражения
В канонических процессных выражениях используются нити единично длины. Продемонстрируем использование канонических процессных выражений на следующем простейшем примере.
P = P |Pb >
P = ch (P P ) ! а x а b ' 1 P 1
р. 1 = ch ( PbPa )? a 2 .0,
Pb = ch(P P ) ? а а b 1 Pb 1
Pb1 = ch (Pb Pa ) ! а2 .0
Здесь процессное выражение Р задает два параллельных процесса Ра и Рь. Процессное выражение Ра описывает поведение одноименного агента Ра, а процессное выражение Рь описывает поведение агента Рь. Процессы Ра1 и Рь1, являются подпроцессами соответственно процессов Ра и Рь. Процессы и соответственно агенты Ра и Рь взаимодействуют по двум
сh (РР ) ск (РР ) тт сh (РР ) 0
каналам а ь и а' . Канал а ь является выходным для процесса Ра и
входным для процесса Рь. Канал ск (РьРа) является выходным для процесса Рь и входным для процесса Рь. Свойство обязательной реакции взаимодействия для процессов Ра и Рь выглядит следующим образом
{1(ск(РаРь),\а^ =э О [(Г (с А (РаРь ),?«,)) =э 0(ЧсИ(РьРа ), ! )) =э О ( Г ( с к ( Рь Ра ) , ? а , ) ) ] }
Здесь ¿(СИ, А) - предикат, истинный, когда действие А поступает в канал СИ.
4. Проверка правильности взаимодействия агентов логическими программами
Как отмечалось в работе [1] перспективным путем автоматизации проверки правильности взаимодействия агентов является использование логического программирования, например, на основе языка логического программирования VISUAL PROLOG [7]. Иллюстрация структуры логической программы для проверки свойства обязательной реакции даже для сравнительно несложного примера агентов UAC и UAS в рамках настоящей стать слишком громоздка. Поэтому продемонстрируем проверку свойства обязательной реакции на простейшем примере, приведенном в предыдущем разделе. Предварительно введем понятия состояния процессов.
В примере предыдущего раздела поведение агентов Pa и Рь задано соответственно
P = ch (РД)! аР , ,Р = ch (PP )? а .0 процессными выражениями а а b 1 а 1 а 1 b а 2 и
P. = ch (P P^ )? аРк1 , P„ = ch (PP )! a .0 ^ P
b а b 1 b 1 b1 b а 2 . Перед началом взаимодействия процесс а
находится в состоянии pa, а после выдачи по собственной инициативе в канал ch (РаРь)
реакции !ai процесс Pa переходит в состояние pal. После получения по каналу ch(PbPa) восприятия ?a2 в ответ на свою реакцию !ai процесс Pa прекращает свою работу (переходит к
выполнению процесса 0 в состоянии pao)). Аналогично процесс b до начала взаимодействия
находится в состоянии рь, ожидая в канале ch (РаРь) восприятия ?ai. После этого восприятия процесс Рь переходит в состояние рь1 ожидания выполнения реакции !a2. После выдачи в
канал ch(PbPa) реакции !a2 процесс Рь прекращает свою работу (переходит к выполнению процесса 0 в состоянии рьо).
Логическая программа проверки свойства обязательной реакции для нашего примера может выглядеть следующим образом.
domains
f =f(symbol, symbol, symbol) list = f* predicates
nondeterm transition(symbol, f symbol) nondeterm accessible(symbol, list, symbol) clauses
transition(pa, fa,b,ia1), pa1). transition(pa1,ftb,a,oa2), pa0). transition(pb, fa,b,oa1), pbl). transition(pb1,f(b,a,ia2), pb0).
accessible(P1, fX,Y,Z)l P2) :- transition(P1, f(X,Y,Z), P2).
accessible(P1, fX,Y,Z)\Restl P2) :- transition(P1, f(X,Y,Z), P3), accessible(P3, Rest, P2). goal
accessible(pa,[fa,b,ia1), f(b,a,oa2)], pa0), accessible(pb,[fa,b,oa1), f(b,a,ia2)], pb0).
Раздел goal содержит задачу нахождения двух последовательностей (списков) функторов, ведущих из начального состояния pa в состояние pa0 и из начального состояния pb в состояние pb0, представляющих каналы и правильные последовательности реакций и восприятий, поступающие в них. Результатом работы данной программы является ответ "yes", означающий выполнение свойства обязательной реакции для этого простого примера. В случае более сложных процессов эти последовательности могут содержать промежуточные функторы, представляющие другие каналы и действия.
5. Заключение
В настоящей статье рассмотрены принципы проверки правильности сетевого взаимодействия, представленного моделями последовательностных взаимодействующих процессов. В отличие от других работ здесь для описания процессов предлагается использовать канонический вариант языка, облегчающий формулировку требований правильности на языке временной модальной логики и переход к логической программе на языке логического программирования ПРОЛОГ. Приведен пример простой логической программы и результаты ее работы.
ЛИТЕРАТУРА
1. Девятков В.В., Мьё Т.Н. Формальный логический анализ корректности спецификаций сетевых SIP-протоколов. Инженерный журнал: наука и инновации, 2013, вып. 11.
2. Zave P. Understanding SIP Through Model-Checking. Proc. of the 2nd International Conference of Principles, Systems and Applications of IP Telecommunications. Springer-Verlag, 2008, vol. 5310, pp. 256-279.
3. Robin M. Communicating and Mobile Systems: The п-calculus. Cambridge. - UK: Cambridge University Press, 2003. 159 с.
4. Девятков В.В., Алфимцев А.Н. Необходимые и достаточные формальные свойства мультимодального интерфейса // Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение. Спец. вып. «Информационные технологии и компьютерные системы». М., 2011. С. 159-167.
5. Chellas B.F. Modal Logic an Introduction. The Press Syndicate of the University of Cambridge, 1980, 295 p.
6. Gabbay D., Hodkinson I., Reynolds M. Temporal Logic: mathematical founditions and computational aspects, vol. 1. Clarendon Press, Oxford, 1994.
7. Адаменко А.Н., Кучков А. Логическое программирование и Visual Prolog. Изд. БХВ - Петербург, 2003.
8. Девятков В.В., Алфимцев А.Н. Способ управления телевизором с помощью мультимодального интерфейса // Заявка на патент №2010103629, ФГУ ФИПС, Москва. 2010. 16 с.
9. Bishop S., Fairbairn M., Norrish M., Sewell P., Smith M., Wansbrough K. Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP and sockets. Proc. SIGC0MM'05. ACM, 2005, August.
10. Holzmann G.J. The Spin Model Checker: Primer and Reference Manual. Addison-Wesley, 2004, 596 p.
11. Девятков В.В., Сидякин И.М. Мультипроцессная система анализа телеметрической информации. Вестник МГТУ им. Н.Э. Баумана, Сер. Приборостроение, 2005, №4 (61), с. 56-85.
12. Девятков В.В. Построение, оптимизация и модификация процессов. Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение, 2012, №4, с. 60-79.
Myo Thet Naung
Bauman Moscow state technical university, Russia, Moscow E-mail: [email protected]
Devyatkov Vladimir Valentinovich
Bauman Moscow state technical university, Russia, Moscow
E-mail: [email protected]
Formal validation networking agents, specifiable in the language of process expressions
Abstract. This article is dedicated to the development of methods of formal validation agent interaction modeling networking. The behavior of agents specified in the language of process expressions. Interacting agents are widely used to simulate network communications using different protocols. Automation validation specifications are encouraged to implement logic programs are prepared by the presented in this article methodology of process of transition from the canonical expressions that specify the behavior of agents, as well as the requirements of the correctness of the interaction in the language of modal logic. As a logical programming language to validate networking using Visual Prolog. This article develops the methodology outlined in the previous article the author. The main difference in the above article from the material already published the results is to use the graph does not describe the behavior of agents and canonical symbolic limiting expression to describe, but it facilitates the transition from a logic program and the correctness of the wording of claims in the language of modal logic. Methods of formal verification of correctness of networking illustrated by a simple example of the logic program on one of the earlier versions of Visual Prolog language, allows you to check the mandatory requirements of the reaction to the case of two interacting agents.
Keywords: agent; networking; modal logic; validation; process canonical expression; logic programming language
