CC BY
48Спецификация функциональной модели информационного портала сетями Петри.
Зыбарев Ю.М., Чернев С.П. [email protected]) Институт дискретной математики и информатики Министерства образования РФ
Информационный портал и его функциональная структура. Одним из системообразующих решений, которое ориентировано на интеграцию в рамках единой корпоративной информационной среды различных проблемно-ориентированных информационных систем, сервисов и информационных ресурсов (БД и т.д.) с организацией консолидированной точки доступа к ним пользователей различных категорий с учетом их полномочий и решения задач информационной безопасности в числе Интернет/интранет - решений рассматривается информационный портал [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] классическая сеть Петри определяется следующим набором
< (Р,Т,7);у,д^^ >, где 1) (Р,Т,2) - ориентированный двудольный граф с множеством вершин (Р ^ Т) и множеством дуг 7 = [г/г е (Р х Т) ^ (Т х Р)}, при этом: подмножество вершин Р = [А,Р2, -,Рт{Р)} называется позициями сети Петри, а подмножество вершин Т = [г1, г 2,..., гт{1)} называется переходами сети Петри;
2) у : 7 ^ N - функция кратности дуг г е 7 , где у(г) - неотрицательное целое
число;
3) д : Р ^ N - функция начальной маркировки, которая ставит в соответствие каждой позиции р е Р неотрицательное целое число /и0 (р), интерпретируемое как количество маркеров в позиции Р ;
4) 81 (д, г) - условия возбуждения перехода г е Т в состоянии маркировки д сети Петри, которые имеют вид:
8 (д, г) = Ур е Р /(р, г) е 7 : д (р) >у(р, г),
т.е. во всех входных позициях р для перехода г количество маркеров д (р) при текущей маркировке должно быть не меньше кратности соответствующей дуги (р, г) ; если условия возбуждения выполнены, то 81 (д, г) = 1 и переход г считается возбужденным, в противном случае 81 (д, г) = 0;
5) 82 (д., г) = д+1 - правило изменения маркировки в результате срабатывания возбужденного перехода г (81 (д, г) = 1), которое для классической сети Петри определяется следующими соотношениями:
ур е Р : д+1 (р) = д (р) + У(и р) - Y(Р,г)
(здесь и далее функция со значком ~ тождественно равна функции без этого знака на всей области ее определения и равна 0 вне нее), т. е. из каждой входной позиции р перехода г удаляется количество маркеров, равное кратности соответствующей дуги у(р, г), а в каждую входную позицию р перехода г добавляется соответствующее количество маркеров у(р, г) .
Поскольку «изобразительных» средств классических сетей Петри при спецификации сложных систем оказывается недостаточно, в аппарате сетей Петри имеются их расширения (обобщения) в виде раскрашенных, временных, иерархических и др. сетей Петри. Нами в данной работе будут использован класс раскрашенных временных сетей Петри. Для этого класса сетей Петри в приведенное выше классическое определении дополнительно вводятся следующие функции:
• функция цвета C P ^ ^ , где ^ является конечным множеством непустых типов, или множество цветов;
• G - функция охраны, которая действует из T в выражения такие, что Vt е T : [Type(G(t)) = ZЛ Type(Var(G(t))) с £]
• вводится функция временных интервалов Time : T ^ Interv(N + ), где Interv(N+ ) = |[tj, 12],[t3, да) | tj, t2, t3 е N +, tj < 12} и границы временного интервала
трактуются как раннее и позднее время срабатывания перехода раскрашенной сети Петри.
С точки зрения наглядности восприятия сети Петри и качественного анализа моделируемых процессов, что особенно важно при разработке спецификаций как инструмента проектирования, особое место занимает графическое (графовое) представление Сетей Петри. Такой подход (визуального представления) является основой для графических редакторов в специализированных инструментальных программных системах моделирования сетями Петри [18]. При дальнейшем изложении нашего подхода к спецификации функциональной модели информационного портала воспользуемся именно графическим представлением. В комментариях к графическому представлению и в самом графическом представлении будем придерживаться системы обозначений, используемых в монографии K.Jensen [13] и инструментальной программной системы моделирования раскрашенных сетей Петри Design/CPN [17].
Ниже предложены варианты спецификаций функциональной модели информационного портала и одной из его базовых функциональных подсистем в виде раскрашенных сетей Петри:
• обобщенной модели функционирования Web-сервера;
• общей модели функционирования информационного портала;
• модели функциональной подсистемы портала - «система новостей».
По аналогии с представленными спецификациями авторами разработан полный набор спецификаций базовых функциональных подсистем портала, но из-за ограничения объема статьи здесь не приводятся.
Обобщенная модель функционирования Web-сервера. Каждое портальное решение имеет в своем распоряжении Web-сервер [3], который осуществляет посредническое взаимодействие между клиентом и сервером. В общем случае, процесс функционирования Web-сервера, моделирующий реализацию запроса статического ресурса, может быть специфицирован в виде раскрашенной сети Петри, которая представлена на рис.1.
True
О
Input
(ID,Req)
(ID,Data)
•О
Output
Get Res
Рисунок 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), где Id_client - целое неотрицательное число. 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 или в виде бинарных данных мультимедиа-потока.
Timer_In, Timer_Add_Req, и Timer_App и 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 ((Id_client, Id_req, Full', Number+1, Id_app),Req'). Далее процесс повторяется до тех пор, пока вновь поступившая фишка не будет иметь Full = true. В этом случае выполняется переход Check_Ready и запрос поступает в место App_Data в виде, удобном для приложений. То есть функция выражений дуги из Input в Check_Ready равна ((Id_client, Id_req, true, Number, Id_app),Req).
Для понимания происходящего процесса приведем такой пример: происходит регистрация клиента Web-сервером, получив начальную информацию сервер сохраняет ее у себя и посылает клиенту очередную страницу анкеты и лишь получив всю анкету целиком (при моделировании это может быть уже не одна, а несколько фишек) сервер регистрирует нового клиента. Таким образом, место Temp выступает накопителем системы. После того, как приложения получили начальные данные, они начинают свою работу, при этом выбор приложения может осуществляться функциями охраны переходов App_1 ...App_N. Кроме того, любое приложение имеет доступ к временному хранилищу, то есть может как считывать/удалять информацию из него, так и записывать/изменять ее. Функция выражения для дуг из Temp в любой из переходов App_i (i=1..N) равна ((Id_client, Id_req, true, Number-1, Id_app),Req(Number-1)) + ... + ((Id_client, Id_req, true, 1, Id_app),Req(1)). После выполнения перехода приложения в место Temp возвращаются все полученные переходом фишки, то есть для этой дуги функция выражения равна ((Id_client, Id_req, true, Number, Id_app),Req) + ((Id_client, Id_req, true, Number-1, Id_app),Req(Number-1)) + ... + ((Id_client, Id_req, true, 1, Id_app),Req(1)). Функция выражений для обратных дуг может быть либо равна только что упомянутой, либо добавлять к этому выражению еще несколько фишек цветов типа (ID,Req). Это зависит от приложения App_i. Следствием работы приложений является появление ответной информации в месте Res, при этом поступившая фишка имеет цвет ответа, то есть ее цвет выглядит так (ID, Data). После этого происходит персонификация и кастомизация ответных данных, то есть определяются ограничения по доступу к данным (ответ либо урезается, либо пополняется) и выявляются персональные особенности клиента (тип браузера, степень детализации ответа, возможности соединения и т.п.). Скорректированный ответ визуализируется (выполнение перехода Visual) и клиент получает готовый HTTP ответ в выходном месте Output. Для этих дуг функция выражений дуг равна (ID,Data(ID)), где значения компоненты Data изменяются в зависимости от идентификатора запроса.
Спецификация функциональной модели информационного портала сетями Петри позволяет проанализировать предлагаемый сценарий (алгоритм) ее функционирования на свойства «живости» и «ограниченности», которые важны при программной реализации. Проанализируем на свойство «живости». Переходы Check_Add_Req, Add_Req и Check_Ready являются живыми, что следует из условия начальной маркировки (наличие запросов в позиции Input). Переходы App_N являются живыми только в том случае, если во входной позиции Input возникают запросы с обращениями к соответствующим приложениям. Далее, живость переходов Person, Custom и Visual определяются появлением ответа от приложения в позиции Res: переходы выполнятся хотя бы один раз, при появлении хотя бы одного ответа от любого приложения App_N. Условия живости переходов, занимающихся очисткой устаревших фишек (Timer_In, Timer_Add_Req, и Timer_App и Timer_Temp_Data), определяется наличием фишек во входных позициях и
корректной настройкой констант задержек перед срабатыванием перехода. То есть, при установке слишком больших задержек, срабатывания этих переходов может не произойти. Проанализируем сеть на свойство «ограниченности». Позиция Input является n-ограниченной, по построению, где n-число фишек в позиции в начальной маркировке. Рассмотрим ситуацию, когда суммарное число итераций по получению дополнительной информации от пользователей не превышает k. В таком случае, позиция Form_Add_Req является k-ограниченной, позиция Temp и Output имеет уровень ограничения n+k, остальные позиции также n-ограничены по построению сети.
Как было отмечено выше, в предложенной спецификации функциональной модели портала работа его функциональных подсистем не описана явным образом, а скрыта переходами App_i. В качестве примера спецификации функциональных подсистем приведем вариант спецификации новостной подсистемы портала (система публикации и просмотра новостей). Такая система позволяет создавать, отображать, удалять и редактировать новостные группы и статьи. При этом в этой сети мы будем учитывать проблему доступа, хотя эту проблему решает компонент авторизации. Это связано с тем, что портал, как инфраструктура для создания приложений не может реализовывать логику каждой прикладной задачи, следовательно, в случаях работы проблемных приложений имеет смысл самостоятельно отслеживать безопасность (на уровне приложения). В системе публикации и просмотра новостей для безопасной работы необходимо проверять, есть ли ограничения по доступу у конкретного клиента и в ответных данных необходимо учитывать эти ограничения.
На рис.3 приведен вариант спецификации новостной подсистемы в виде раскрашенной временной сети Петри.
Рисунок 3. Спецификация функциональной модели системы новостей.
Опишем предложенный вариант сети Петри. Множество цветов для построенной сети устроено так же, как и ранее, но теперь для пояснения работы необходимо сказать, что компонент Data цвета устроен таким образом, что по нему можно определить какой именно запрос был выполнен. Заметим, что для работы именно этого приложения необходимо, чтобы запрос содержал флаг работы с системой новостей (этот факт фиксируется в главной сети функцией охраны перехода App_i), то есть считаем, что конструируемая сеть работает только с фишками, флаг приложения которых равен системе новостей. Так как запросы в этой системе могут касаться только нескольких функций, таких как чтение списка группы/новостей, чтение группы/новости, запрос на редактирование, запрос на сохранение редактирования, запрос на создание новой группы/новости, сохранение новой группы/новости, то поступившая информация обрабатывается в соответствии с флагом функции. То есть, по цвету фишки определяется, что именно запрашивает клиент и далее выполняется только одно требуемое действие. То есть компонент Id_req содержит информацию о запрашиваемом действии, что означает, что Id_req.Act может быть равен DisplayList, Display, SaveEdit, EditForm, CreateNew, SaveNew или Delete. В нашей сети это моделируется наложением функций охраны на переходы DisplayList, Display, SaveEdit, EditForm, CreateNew, SaveNew и Delete.
Выполнение любого из этих переходов удаляет входную фишку цвета (ID,Req) и отправляет в место AppRes фишку цвета (ID,Data), но при этом флаги запроса сохраняются. Так, например, если запрос касался создания новой группы новостей, то выполнится переход CreateNew, и цвет появившийся фишки будет содержать флаг работы по созданию новой новостной группы и саму креативную форму. Поскольку для портала
не важно, работает ли клиент с группой или с одной новостью, то разделять эти действия при моделировании не имеет смысла. Все различия при работе с базой данных (обращение к базе данных производят сами функциональные переходы) определяются флагом работы с группой или новостью. Далее, полученный ответ проверяется на безопасность, то есть определяется, есть ли доступ у данного клиента на конкретное действие и скорректированные данные отправляются в место Res. Это моделируется переходом Check_Secur, который удаляет фишку цвета (ID,Data) из AppRes и помещает фишку цвета (ID, Data') в место Res. Кроме того, в случаях подтверждений изменений или сохранения новых данных именно этот переход осуществляет изменение базы данных.
Чтобы пояснить работу этого приложения опишем один из переходов более подробно на примере EditForm. Этот переход выполняется только в том случае, когда клиент запросил редактирование какого либо сообщения, то есть Id_req.Act = EditForm. Данный переход создает форму редактирования, помещает в нее требуемое сообщение, в соответствии с этим меняет цвет выходной фишки (идентификатор запроса в этом случае остается неизменным, а компонента Data содержит флаг операции редактирования и идентификатор исправляемой новости). Все переходы действия только подготавливают ответ для клиента, реальные изменения в базе данных происходит после выполнения проверки доступа. Различия проверки для разных запросов моделируются сложной функцией определения компоненты Data' по компоненте Data, упомянутых в функциях выражения дуг для входных и выходной дуг перехода CheckSecur. Эта функция подобна оператору case, она перебирает все возможные варианты для поступивших фишек, и в каждом случае цвет выходной фишки будет определяться по-своему, исходя из цвета входной. Функция времени для переходов определена уже привычным способом. Как и ранее переходы-таймеры имеют временную задержку и отправляют клиенту сообщение о разрыве соединения в связи с превышением времени ожидания ответа (реально такой переход выполняется, если сервер получил слишком много запросов и не в состоянии обработать их все).
В рамках работ по апробации предложенных методологических и технологических подходов на основе разработанных спецификаций функциональной модели портала и его подсистем реализованы портальные комплексы:
• портал Югорского НИИ ИТ, акцентирующийся на предоставлении информации научно-образовательной тематики, выполненный при использовании технологии J2EE;
• прототип образовательного портала ГНИИ ИТТ "Информика" с использованием технологии Oracle 9iAS Portal.
Литература.
1. Стандарты в проектах современных информационных систем. Сборник трудов 2 всеросс. практ. конференции. М.:, Изд-во «Открытые Системы», 2002. - 240 с.
2. Чеботарев Валерий. Интегрированные системы управления предприятием: взгляд системного аналитика. // PCWeek №14(188),1999
3. Чернев С. П. "Информационные порталы и технологии их реализации", // Материалы Международной научно-методической конференции "НОВЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В УНИВЕРСИТЕТСКОМ ОБРАЗОВАНИИ", 2002, Кемерово, 2002
4. Леонид Черняк. "Корпоративный портал", http://kis.pcweek.ru/kis/win/techno/p.html
5. Леонид Черняк. "Управление кораблем корпорации", журнал БОСС, 1997, № 1
6. Питтс Д. XML для профессионалов: WЗС DOM, SAX, CSS, XSLT, DTD, XML Schemas, Xlink, Xpoiner, Xpath, электронная коммерция, BizTalk, B2B, SOAP, WAP, WML. : М: Мир,2002 - 444 c.
7. "Best Practices in Enterprise Portals", KMWorld, 2001, July/August, http://www.kmworld.com
8. "Corporate portals: A Simple View of a Complex World", Plumtree Software, 1998
9. Robert Papaj, Donald Burleson Oracle Database on the WEB. - The Coriolis Group, Inc. 1997г. - 572с.: ил.
10. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. - М.: Мир, 1999. - 191с., ил.
11. Уэнди Боггс, Майкл Боггс UML и Rational Rose. Пер. с англ. - М. «Издательство Лори», 2000г. - 580с.: ил.
12. Peterson J.L. Petri Net Theory and the Modelling of Systems. Prentice-Hall, 1981.
13. Jensen K. Coloured Petri Nets - Berlin a. o.: Springer-Verlag, 1996.
14. Ramchandani C. Analysis of Asynchronous Concurrent Systems by Petri Nets. -Cambridge: MIT, 1974.
15. Reisig W. Petri Nets: An Introduction // EATCS Monographs on Theoretical Computer Science - 1985. - Vol. 10.
16. Braner W., Rezig W., Rozenberg G.Petri Nets: Central Models and Their Properties/Ed. - Berlin a. o.: Springer-Verlag, 1987.
17. Transaction Processing Performance Council // http://www.tpc.org/
18. Design/CPN - Computer Tool for Coloured Petri Nets// http://www.daimi.au.dk/designCPN/
