Мифы о звукоизоляции Как построить дом из пеноблоков Как построить лестницы на садовом участке Подбираем краску для ремонта Каркасные дома из дерева |
Главная » Спецификация функциональной модели 1 2 Спецификация функциональной модели информационного портала сетями Петри. Зыбарев Ю.М., Чернев С.П. (ser@sibinfo.ru) Институт дискретной математики и информатики Министерства образования РФ Информационный портал и его функциональная структура. Одним из системообразующих решений, которое ориентировано на интеграцию в рамках единой корпоративной информационной среды различных проблемно-ориентированных информационных систем, сервисов и информационных ресурсов (БД и т.д.) с организацией консолидированной точки доступа к ним пользователей различных категорий с учетом их полномочий и решения задач информационной безопасности в числе Интернет/интранет - решений рассматривается информационный портал [3,4,8]. Информационный портал как одно из базовых Интернет-решений появилось и развивается в последние несколько лет [7]. Тот факт, что информационный портал становится массовым информационно-программным продуктом как в глобальном Интернет-пространстве, так и в корпоративных информационных средах, придает актуальность решению комплекса методических, технологических и инструментальных проблем создания индустриального подхода к производству информационных порталов различного назначения. Информационный портал, как субъект Интернет/Интранет пространства, - это Web-сайт, который: организован в виде системного многоуровневого объединения различных информационных ресурсов и сервисов; ориентирован на определенную целевую группу пользователей (по тематике, функциям, сервисным службам и т.д.) является отправной точкой в Интернет/Интранет пространство своей целевой группы и играет роль навигационной системы. В Интернете, термин портал первоначально использовался для называния таких информационных ресурсов и служб как Excite, Yahoo, MSN, Netscape Netcenter, Rambler, Яndex, обеспечивающих пользователям централизованный вход и специальные средства для удобной навигации и поиска информации в сети. К настоящему времени многообразие информационных порталов можно разбить на следующие подклассы однотипных : горизонтальные (или потребительские), вертикальные (или профильные), торговые, корпоративные и т. д.. Многие информационные порталы трудно строго отнести к одному определенному подклассу. Так портал учреждений науки и образования далеко не всегда возможно строго отнести к одному из указанных типов порталов: наборы страниц отдельной лаборатории могут прорабатывать строгую вертикаль по определенной тематике, при этом горизонтальная специфика порталов проявится благодаря наличию большого количества лабораторий, публикующих свои ресурсы в портале; одновременно, сотрудники лабораторий и отделов могут осуществлять обмен результатами работы, производить интерактивное обсуждение задач, что привносит ресурсу элементы корпоративного портала. В качестве одного из основных конкурентных преимуществ создания системы порталов как среды доступа к информационным ресурсам являются: способность интеграции и агрегации большого объема неоднородных данных; наличие развитых механизмов поиска, средств персонификации содержимого портала для определенного пользователя и систем кастомизации. Функциональная структура информационного портала включает, как правило, следующие группы функциональных подсистем: базовые подсистемы (авторизации и аутентификации; каталогов; дискуссионных форумов; новостей; настройки пользовательского интерфейса), адаптеры портала (информационные адаптеры, адаптеры приложений, средства взаимодействия адаптеров, предустановленные адаптеры (библиотеку портлетов), поддержку XML и web-служб), средства организации и доступа к данным (хранение данных и работа с информационной базой портала, работа с метаинформацией (службы поддержки метаданных, справочники метаданных)), средства управления (управление производительностью и администрирование, средства обеспечения безопасности портала; управление кластерами; многоаспектный аудит и мониторинг портала, статистика; трассировка и моделирование web-сред и сетей, средства кэширования контента), средства интеграции (обеспечение межпортальной интеграции баз данных, метаданных (импорт, экспорт, координация), поисковых процедур, систем безопасности, приложений, событийных и справочных систем.; формирование кооперативной системы зеркал и виртуальных серверов (для корпоративного или персонального хостинга), CDN - сети доставки контента, grid-структуры), средства коммуникации (почта, различные Web-браузеры, клиенты, мобильные устройства, факс, пейджер, телефон; сетевые форумы, чаты, опросы, голосования, службы поддержки коллективной работы (web-встречи, телеконференции, видеоконференции, единые событийные и офисные системы и т.д.)), средства развития (инструментарий для модификации и разработки (сервисов и адаптеров); средства создания персональных страниц портала пользователей), средства портальных приложений и профильных сервисов, проблемные информационные системы. Инструментально-технологические аспекты создания информационных порталов. Как уже отмечалось выше, портал становится массовым ИТ-продуктом в Интернет/Интранет средах, в связи с чем приобретает особую актуальность решение задачи реализации промышленных методов их производства. Для реализации промышленных методов производства информационных порталов, на наш взгляд, необходимо решить задачу создания специализированной инструментально-технологической среды разработки, которая включает: актуализацию состава и содержания жизненного цикла информационного портала с учетом международных стандартов [1] на производство ИТ-продуктов, развивающихся технологий (CDM, RUP и др.) разработки ИТ-систем [11] и их поддержки инструментальными программными средствами; развитие специализированного программно-технологического инструментария на уровне макросредств для реализации функциональной модели портала и его подсистем в виде информационно-программного комплекса; формирование специализированного депозитария (банка) формализованных решений по реализационно-независимым функциональным моделям информационных порталов и их функциональных подсистем с учетом выделенных типовых классов. По первой позиции в данной статье (по причине ограниченного объема и отдельного предмета) ограничимся кратким комментарием, который заключается в том, что технологии CDM (Oracle) и RUP с их инструментарием позволяют сформировать корпоративную систему поддержки управления реализации жизненного цикла портала и его отдельных этапов. На второй позиции - программном инструментарии создания информационно-программных портальных комплексов остановимся несколько подробней. При наличии функционального описания для создания информационно-программного комплекса важно определить технологическую архитектуру портала, набор подходов и методов для его реализации. Современные технологические подходы к построению портальных программных комплексов предполагают создание большого количества сложных программных модулей, реализация которых без переиспользования элементов программного кода является весьма ресурсоемкой задачей. Альтернативным вариантом является подход с использованием серверов приложений. При таком подходе сервер приложений предоставляет разработчику наборы сервисов с возможностью использования высокоуровневых блоков, не требуя низкоуровневой разработки, что позволяет акцентировать внимание разработчика на проектировании и реализации логики приложения и в меньшей степени размышлять над техническими и технологическими проблемами. Для создания информационно-программных портальных комплексов имеются различные инструментально- технологические подходы на основе продуктов из списка основных производителей соответствующего программного обеспечения: 1. IBM Lotus Notes - позволяет предоставлять доступ к информационным системам и системам документооборота через web-интерфейс. Использует собственные способы хранения и управления данными. 2. Microsoft .Net - технология, тесно интегрирующаяся со всеми продуктами компании Microsoft - от офисных решений до серверов управления базами данных. 3. Sun iPlanet Application Server - решение от компании Sun Microsystems позволяет создавать крупномасштабные серверные приложения, акцентируясь на комплексы под управлением Sun Solaris. В базовую поставку платформы для построения порталов входит высокопроизводительный Web сервер и стандартный набор J2EE (Java 2 Enterprise Edition) компонент. 4. Oracle Application Server - технологии создания порталов на основе продуктов Oracle предоставляют реализовывать различные механизмы автоматизации доступа к информации базы данных и других систем. Технологии обеспечивают различные API для взаимодействия между клиент-серверными приложениями и предоставляют удобные средства автоматизации информационного наполнения. 5. IBM WebSphere - сервер приложений от компании IBM является одним из лидеров среди подобных комплексов от других производителей в плане внедрения новейших стандартов и технологических решений. Тем не менее, производительность данного решения уступает серверам других вендоров. 6. Другие (BEA WebLogic, Cold Fusion, Netscape etc.) - при реализации специфичных задач (задачи систем реального времени, систем для определенного программного комплекса, систем для фиксированной аппаратной платформы, задачи поддержки старых систем и других) необходимо так же обратить внимание на системы других производителей, для которых обеспечивается технологическая поддержка от соответствующих компаний. Список серверов приложений [17] может быть большим. Анализ показывает, что каждое из предлагаемых лидерами IT-промышленности решений обладает своими преимуществами и недостатками, детальный анализ которых необходимо принимать во внимание при выборе соответствующей технологии и программного инструментария. Спецификация функциональной модели информационного портала сетями Петри. Основной акцент в дальнейшем содержании данной статьи будет нами сделан на вопросах формальной спецификации функциональной модели информационного портала и его функциональных подсистем как основы формирования специализированного депозитария (банка) формализованных решений по реализационно-независимым функциональным моделям информационных порталов и их функциональных подсистем с учетом выделенных типовых классов. В качестве языка спецификации в предлагаемом подходе используется аппарат высокоуровневых сетей Петри[12,13,15,16]. Согласно [12] классическая сеть Петри определяется следующим набором < (P,T,Z);у, 1л{);51;52 >, где 1) (P,T,Z) - ориентированный двудольный граф с множеством вершин (P <j T) и множеством дуг Z = {z/z е (P х T) <j (T х P)}, при этом: подмножество вершин P = {p1,Р2,--,Pm{p)} называется позициями сети Петри, а подмножество вершин T = {t1,12tm(t)} называется переходами сети Петри; 2) у : Z == N+ - функция кратности дуг z е Z , где у(z) - неотрицательное целое 3) /и0: P => N - функция начальной маркировки, которая ставит в соответствие каждой позиции p е P неотрицательное целое число 0 (p), интерпретируемое как количество маркеров в позиции p ; 4) (51 (р t) - условия возбуждения перехода t е T в состоянии маркировки jUt сети Петри, которые имеют вид: 51 (р, t) = Vp е P /(p, t) е Z : р (p) > у(p, t), т.е. во всех входных позициях p для перехода tколичество маркеров p(p) при текущей маркировке должно быть не меньше кратности соответствующей дуги (p, t) ; если условия возбуждения выполнены, то 5 1 (р , t) = 1 и переход t считается возбужденным, в противном случае 5 1 (р , t) = 0; 5) 52 (р, t) = р+1 - правило изменения маркировки в результате срабатывания возбужденного перехода t (5 1 (р , t) = 1), которое для классической сети Петри определяется следующими соотношениями: Vp е P: р+1(p) = р (p) + у(t, p) - Ялt) (здесь и далее функция со значком ~ тождественно равна функции без этого знака на всей области ее определения и равна 0 вне нее), т. е. из каждой входной позиции p перехода t удаляется количество маркеров, равное кратности соответствующей дуги у( p, t) , а в каждую входную позицию p перехода t добавляется соответствующее количество маркеров у( p, t). Поскольку изобразительных средств классических сетей Петри при спецификации сложных систем оказывается недостаточно, в аппарате сетей Петри имеются их расширения (обобщения) в виде раскрашенных, временных, иерархических и др. сетей Петри. Нами в данной работе будут использован класс раскрашенных временных сетей Петри. Для этого класса сетей Петри в приведенное выше классическое определении дополнительно вводятся следующие функции: функция цвета C P Е , где Е является конечным множеством непустых типов, или множество цветов; G - функция охраны, которая действует из T в выражения такие, что Vt е T : [Type(G(t)) = ZЛ Type(Var(G(t))) с Е] * вводится функция временных интервалов Time : T Interv(N + ), где Interv(N+ ) = {[t1,12],[t3, оо) 11, t2, t3 е N +, t1 < 12} и границы временного интервала трактуются как раннее и позднее время срабатывания перехода раскрашенной сети Петри. С точки зрения наглядности восприятия сети Петри и качественного анализа моделируемых процессов, что особенно важно при разработке спецификаций как инструмента проектирования, особое место занимает графическое (графовое) представление Сетей Петри. Такой подход (визуального представления) является основой для графических редакторов в специализированных инструментальных программных системах моделирования сетями Петри [18]. При дальнейшем изложении нашего подхода к спецификации функциональной модели информационного портала воспользуемся именно графическим представлением. В комментариях к графическому представлению и в самом графическом представлении будем придерживаться системы обозначений, используемых в монографии K.Jensen [13] и инструментальной программной системы моделирования раскрашенных сетей Петри Design/CPN [17]. Ниже предложены варианты спецификаций функциональной модели информационного портала и одной из его базовых функциональных подсистем в виде раскрашенных сетей Петри: обобщенной модели функционирования Web-сервера; общей модели функционирования информационного портала; модели функциональной подсистемы портала - система новостей . По аналогии с представленными спецификациями авторами разработан полный набор спецификаций базовых функциональных подсистем портала, но из-за ограничения объема статьи здесь не приводятся. Обобщенная модель функционирования Web-сервера. Каждое портальное решение имеет в своем распоряжении Web-сервер [3], который осуществляет посредническое взаимодействие между клиентом и сервером. В общем случае, процесс функционирования Web-сервера, моделирующий реализацию запроса статического ресурса, может быть специфицирован в виде раскрашенной сети Петри, которая представлена на рис.1. Рисунок 1. Обобщенная модель Web-сервера в виде раскрашенной сети Петри. Опишем параметры этой сети. Функция цвета С определена для фишек сети на множестве цветов двух типов: (ID, Req) и (ID, Data). В обоих случаях ID обозначает идентификатор сетевого соединения, по этому идентификатору Web-сервер определяет, кому направить ответные данные. Req - это сам запрос, Data - полученные данные в результате обработки запроса сервером. Переход Get Res моделирует работу сервера, при этом функция охраны этого перехода всегда истинна, то есть этот переход всегда выполняется при наличии фишки цвета (ID, Req) во входном месте Input без дополнительных ограничений. При срабатывании перехода фишка цвета (ID,Req) удаляется из элемент-места (Input, (ID,Req)), а элемент-место (Output, (ID, Data)) получает фишку цвета (ID, Data). Механизм работы такой сети позволяет одновременно выполнятся нескольким элемент-переходам, то есть несколько фишек разных цветов могут поступать на вход перехода и обрабатываться им независимо друг от друга. Идентификатор каждой фишки гарантирует, что каждый ответ найдет своего заказчика. Для спецификации информационного портала, как специализированной Web-системы, с учетом отображения механизмов персонификации и кастомизации, других базовых функциональных подсистем портала разработан вариант раскрашенной временной сети Петри, которая представлена на рис.2. Рисунок 2. Обобщенная модель портала на основе временных сетей Петри. Опишем параметры данной сети (цвета, позиции, переходы и т.д.). Допустимые в сети цвета определены следующим образом: ID=(Id client, Id req, Full, Number, Id app), где Idclient - целое неотрицательное число. Id req - целое неотрицательное число. Full - логического типа с набором значений {true,false}; Number - целое неотрицательное число. Id app - целое неотрицательное число. Req = list of (key, value), где Key - строкового типа. Value - строкового типа. Data = list of (key, value), где, также, Key - строкового типа. Value - двоичный набор данных. Позиции сети включают: Input - позиция, наличие фишки в которой свидетельствует о наличии запроса к порталу от пользователя, т.е. появление новой фишки вызывается внешней по отношению к порталу системой. Фишки этой позиции характеризуются цветом (ID, Req). Form Add Req - позиция, фишки которой определяют обязательность передачи дополнительных данных пользователем, т.е. при наличии фишек в этой позиции портал генерирует форму для пользователя и требует ее заполнения. Цвет фишек позиции определяется как (ID, Data), записи поля Data определяют характеристики формы дополнительных запросов пользователю. Temp - позиция для сохранения результатов заполнения промежуточных форм и сохранения промежуточных результатов работы приложения. Цвет фишек позиции определяется как (ID,Req). AppData - позиция, фишки которой инициируют запуск приложения. Цвет фишек AppData определяется как (ID, Data). Res - позиция моделирующая наличие результата работы приложения и возможность дальнейшего преобразования ответа системами персонификации и кастомизации. Цвета фишек позиции определяются как (ID, Data). Pers res - позиция, фишки которой определяют наличие персонифицированного ответа для пользователя. Цвет фишек этой позиции имеют вид (ID, Data). Cust res - позиция, моделирующая наличие кастомизированного ответа для пользователя. Позиция, так же как и позиция Pers res, содержит фишки цвета (ID, Data), содержащие набор данных, в дальнейшем, отображаемых для пользователя. Output - фишки этой позиции определяют результат работы портала по предоставлению информации пользователю. Фишки позиции имеют цвет (ID, Data). Данные поля Data фишек этой позиции, есть законченный HTML-документ. Переходы и правила срабатывания для них в данной сети Петри определены следующим образом: Check Add Req - переход выполняет анализ фишек позиции Input на основе поля Full и срабатывает только в том случае, если поле Full для фишек входной позиции имеет значение false. В этом случае, переход копирует фишку в позицию Temp и создает новую фишку в позиции Form Add Req со значением Number = Number + 1 и полем Data, содержащем дополнительную информацию для пользователя, которому отобразится форма. Add Req - переход, моделирующий подготовку ответа пользователя на основе данных, запрашиваемых сервером в позиции Form Add Req, т.е. переход моделирует работу пользователя с дополнительными данными, запрашиваемыми порталом. Check Ready - переход срабатывает в случае поступления завершенного ответа от пользователя в том случае, если поле Full в фишке позиции Input будет иметь значение true. В этом случае, переход изымает фишку из входной позиции и создает фишку в позиции App data, наличие которого инициирует процедуру запуска одного из приложений. App 1 ... App N- эти переходы моделируют работу функциональных подсистем (проблемно-ориентированных приложений) в портале. В качестве требования к срабатыванию перехода является наличие фишки в позиции App data и в позиции Temp со значением поля Id App равному идентификатору приложения App N. Работа перехода определяется бизнес-логикой приложения и в данной сети представляется черным ящиком (для примера, далее в данной статье дается спецификация новостной подсистемы портала) . Обязательным требованием для приложения является требование к подготовке ответа в виде фишки для позиции Res. Person - переход моделирует работу компоненты персонификации. Требованием к срабатыванию перехода является наличие фишки в позиции Res, результатом работы является создание фишки цвета (ID, Data) в позиции Pers res. Custom - этот переход моделирует работу компоненты кастомизации. Переход срабатывает при наличии фишки в позиции Pers res и выполняет подготовку кастомизированного ответа в позицию Cust res. Visual - переход выполняет визуализацию ответа, находящегося в поле Data, позиции Cust res. На основе данных выполняется подготовка отображаемого ответа в формате HTML или в виде бинарных данных мультимедиа-потока. TimerIn, Timer Add Req, и TimerApp и Timer Temp Data - переходы-таймеры реализуют механизм удаления устаревшей информации из позиций в том случае, если информационные сообщения, моделируемые фишками, не обрабатываются в течение продолжительного времени базовыми функциональными компонентами портала (переходами приложений, визуализации и др.). Функция выражений дуг для выходных дуг по отношению к переходу-таймеру Timer Temp Data равна пустому мультимножеству, а ко всем остальным - (ID,Data), где Data имеет вид отрицательного ответа. В этой сети все переходы-таймеры имеют временную задержку в выполнении, равную определенному времени ожидания ответа, а все остальные переходы имеют нулевую задержку, то есть, готовы выполняться сразу после активизации. Это определяется функцией времени, которая ставит в соответствие переходам-таймерам интервалы [LifeTime, оо), а всем остальным - [0,LifeTime]. Заметим, что LifeTime означает время ожидания ответа и имеет натуральный тип. В реальности эта временная величина не обязана быть целой, но ее всегда можно округлить до целого значения, что не отразится на работе портала. Таким образом, если некоторая фишка задерживается в каком либо месте дольше, чем ей положено, то она удаляется из него, при этом клиент получает информационное сообщение о прекращении соединения в связи с окончанием времени ожидания. Заметим, что данные из временного хранилища могут удаляться без отправки такого сообщения. Опишем механизм работы этой сети. Идентификатор запроса представляется в виде ID=(Id client, Id req, Full, Number, Id app). Первые две компоненты позволяют идентифицировать клиента и сам запрос, соответственно. Full - переменная логического типа, отвечающую за полноту запроса, Number - количественная величина натурального типа, характеризующую количество дополнительных данных запроса. Последняя составляющая, Id app, определяет, какое именно приложение должно будет обработать полученный запрос. Таким образом, мы зафиксировали набор цветов, с которыми работает наша сеть. Заметим, что рисунок достаточно явно определяет множества мест, переходов и дуг сети. Теперь определим функции, которые полностью опишут построенную сеть. Функция вершин может быть легко вычислена по графу сети, так как каждая дуга имеет начало и конец (помечен стрелочкой), при этом оба связаны с какой-нибудь вершиной (местом или переходом). Функция цвета местам Input, Form Add Req, App Data ставит в соответствие цвета типа (ID,Req), месту Temp - оба типа цветов, а всем остальным - цвета типа (ID,Data). Функция охраны перехода Check Add Req имеет вид (Full = false), для перехода Check Ready она равна выражению (Full =true), для переходов App i (i=1..N) функция охраны записывается в форме (Id App = App i), а все остальные переходы имеют тождественно истинную функцию охраны. Функция начальной разметки должна сопоставлять месту Input любое количество разных фишек (число фишек одного цвета равно единице), а всем остальным местам - пустое мультимножество. Таким образом, для полноты описания сети осталось расписать функцию выражений дуг. Сделаем это в процессе описания работы сети. Начальная маркировка означает поступление запросов от клиентов. Так как работа портала не зависит от количества запросов, то мы рассмотрим процесс работы сети на примере единственного запроса. Таким образом, в начале имеем фишку в элемент-месте (Input,(ID,Req)) цвета (ID,Req). Далее в зависимости от цвета фишки (в зависимости от значения переменной Full) может выполниться один из переходов Check Add Req или Check Ready. Пусть Full = false, что означает неполноту поступившего запроса. Тогда выполняется переход Check Add Req, при этом из места Input удаляется фишка цвета (ID,Req), а место Temp получает фишку цвета ((Id client, Id req, true, Number, Id app),Req) (таким образом, информация сохраняется во временном хранилище Temp), кроме того, появляется фишка цвета (ID,Data) (где Data - это форма дополнительной информации о запросе) в месте Form Add Req. Клиент заполняет поступившую форму и посылает порталу новый запрос, все это моделируется переходом Add Req. Для дуги из Form Add Req в Add Req функция выражения имеет вид (ID,Data), а для дуги из перехода Add Req в место Input ((Idclient, Id req, Full, Number+1, Id app),Req). Далее процесс повторяется до тех пор, пока вновь поступившая фишка не будет иметь Full = true. В этом случае выполняется переход Check Ready и запрос поступает в место App Data в виде, удобном для приложений. То есть функция выражений дуги из Input в CheckReady равна ((Idclient, Id req, true, Number, Id app),Req). Для понимания происходящего процесса приведем такой пример: происходит регистрация клиента Web-сервером, получив начальную информацию сервер сохраняет ее у себя и посылает клиенту очередную страницу анкеты и лишь получив всю анкету целиком (при моделировании это может быть уже не одна, а несколько фишек) сервер регистрирует нового клиента. Таким образом, место Temp выступает накопителем системы. После того, как приложения получили начальные данные, они начинают свою работу, при этом выбор приложения может осуществляться функциями охраны переходов App 1 ...App N. Кроме того, любое приложение имеет доступ к временному хранилищу, то есть может как считывать/удалять информацию из него, так и записывать/изменять ее. Функция выражения для дуг из Temp в любой из переходов App i (i=1..N) равна ((Idclient, Id req, true, Number-1, Id app),Req(Number-1)) + ... + ((Id client, Id req, true, 1, Id app),Req(1)). После выполнения перехода приложения в место Temp возвращаются все полученные переходом фишки, то есть для этой дуги функция выражения равна ((Idclient, Idreq, true, Number, Id app),Req) + ((Idclient, Idreq, true, Number-1, Id app),Req(Number-1)) + ... + ((Idclient, Idreq, true, 1, Id app),Req(1)). Функция выражений для обратных дуг может быть либо равна только что упомянутой, либо добавлять к этому выражению еще несколько фишек цветов типа (ID,Req). Это зависит от приложения App i. Следствием работы приложений является появление ответной информации в месте Res, при этом поступившая фишка имеет цвет ответа, то есть ее цвет выглядит так (ID, Data). После этого происходит персонификация и кастомизация ответных данных, то есть определяются ограничения по доступу к данным (ответ либо урезается, либо пополняется) и выявляются персональные особенности клиента (тип браузера, степень детализации ответа, возможности соединения и т. п.). Скорректированный ответ визуализируется (выполнение перехода Visual) и клиент получает готовый HTTP ответ в выходном месте Output. Для этих дуг функция выражений дуг равна (ID,Data(ID)), где значения компоненты Data изменяются в зависимости от идентификатора запроса. Спецификация функциональной модели информационного портала сетями Петри позволяет проанализировать предлагаемый сценарий (алгоритм) ее функционирования на свойства живости и ограниченности , которые важны при программной реализации. Проанализируем на свойство живости . Переходы Check Add Req, AddReq и Check Ready являются живыми, что следует из условия начальной маркировки (наличие запросов в позиции Input). Переходы App N являются живыми только в том случае, если во входной позиции Input возникают запросы с обращениями к соответствующим приложениям. Далее, живость переходов Person, Custom и Visual определяются появлением ответа от приложения в позиции Res: переходы выполнятся хотя бы один раз, при появлении хотя бы одного ответа от любого приложения App N. Условия живости переходов, занимающихся очисткой устаревших фишек (Timer In, Timer Add Req, и Timer App и Timer Temp Data), определяется наличием фишек во входных позициях и 1 2 |
© 2024 РубинГудс.
Копирование запрещено. |