Автоматизация процессов управления образовательным учреждением на основе онтологического моделирования и сервис-ориентированной архитектуры

Введение. В современных условиях одним из направлений повышения эффективности управления образовательным учреждением является внедрение информационно-управляющей системы (ИУС).

Внедрение в высшем учебном заведении информационно-управляющей системы решает следующие задачи: упорядоченное управление информационными потоками, создание единого информационного пространства, обеспечение распределённого доступа к данными и поддержка принятия решений.

В настоящий момент российские вузы находятся на стадии реформирования, связанного с присоединением России к Болонскому процессу, внедрением ЕГЭ, кредитных и рейтинговых систем. Закономерно, что большинство процессов вуза постоянно изменяются. Перемены в образовательных процессах требуют корректировки управления ими. При автоматизации этих процессов необходимо предоставить студентам доступ к информационным ресурсам вуза в полном объёме. Следует помнить также о том, что не каждый вуз может позволить себе единовременную автоматизацию своей деятельности — в этом случае временные издержки на обучение и адаптацию пользователей могут привести к срыву учебного процесса. Кроме того, потребуются весьма значительные материальные затраты. Таким образом, необходимо ещё на стадии проектирования закладывать в автоматизированную систему возможность гибкого внедрения.

Аспекты автоматизации вуза. Эффективность функционирования учебного заведения зависит от качества управления его процессами и своевременного принятия решений. ИУС — это своего рода инструмент реализации процессов учебного заведения и поддержки принятия решений, по- этому от возможностей ИУС напрямую зависит эффективность функционирования вуза в целом [1]. На первый план выходят вопросы разработки системы с гибкой архитектурой, которая могла бы легко вписываться в текущую инфраструктуру любого вуза, а также подстраиваться под изменяющиеся процессы.

Вуз представляет собой динамично изменяющуюся среду, поэтому программы, автоматизирующие некоторый процесс, могут устареть ещё до момента внедрения ИУС. Чем шире распространяется автоматизация, тем сложнее процесс модификации и сопровождения информационных систем. Начиная с определённого уровня сложности, разработчики занимаются поддержкой уже разработанных систем, что, в свою очередь, тормозит развитие ИУС в целом [2].

К сложности объекта автоматизации добавляется сложность самой ИУС. ИУС вуза включает в себя множество функциональных блоков, сервисов, коммуникационных устройств, систем, технологий, данных, пользователей и т. д. Сложность эксплуатации ИУС обусловлена длительным жизненным циклом, в течение которого происходят непрерывная смена аппаратного обеспечения (замена серверов, компьютеров, модернизация линий связи), появление нового программного обеспечения, модернизация элементов ИУС и т. п. Это приводит к необходимости разработки архитектуры жизнеспособной ИУС с возможностью быстрого расширения и модернизации используемых элементов.

Архитектура ИУС должна обеспечивать масштабирование по целому ряду направлений: данные, функциональность, пользователи, — т. е. быть адаптивной по отношению к внешней среде. Под адаптивностью следует понимать способность ИУС самонастраиваться с учётом изменений во внешнем окружении. Для решения этих задач требуется сервис-ориентированная архитектура (СОА), которая обеспечит автоматическое поддержание эффективной работы и качества данных ИУС.

Сервис-ориентированная архитектура ИУС. Приведём формальное определение сервис-ориентированной архитектуры, данное специалистами корпорации IBM [3]: «СОА — это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определённой последовательности позволяет реализовать тот или иной бизнес-процесс».

С точки зрения разработчиков, ту же мысль можно передать несколько иными словами: «СОА — это компонентная модель, в которой разные функциональные единицы, называемые сервисами, взаимодействуют по сети с пользователями посредством интерфейсов. При этом интерфейсы должны быть нейтральными к специфике реализации сервисов, которые определяются аппаратной платформой, операционной системой, языком программирования. Подобная нейтральность обеспечивает универсальность взаимодействия сервисов в разнородной (гетерогенной) среде, а сервисы, интегрированные посредством таких интерфейсов, являются слабо связанными».

Идея СОА состоит в том, чтобы рассматривать ИУС как совокупность сервисов, которые выполняют единицу работы, и клиентов, которые обращаются к этим сервисам по простому документированному протоколу. В качестве сервисов можно выделять как повторяющиеся задачи внутри процессов [4], так и весь процесс.

Архитектура ИСУ предполагает использование структурных компонентов (СК), которые выполняют большую часть логики программы. Предназначение СК сводится к взаимодействию с базами данных и к обработке данных. Структурный компонент — довольно широкое понятие. Так можно назвать хранимые процедуры, функции баз данных, а также сами сервисы, если принимать к рассмотрению уровень подсистем.

Использование СК обеспечивает минимизацию изменений кода, так как, во-первых, способствует увеличению производительности процесса разработки приложений-сервисов, а, во- вторых, позволяет разработчикам использовать унифицированные куски программного кода. Это даёт возможность уменьшить затраты на сопровождение ИУС. В результате использования компонентов сервисы становятся независимы от источника данных. Любые изменения источника данных никоим образом не влекут функциональных изменений сервиса, т. к. всю нагрузку по изменениям берут на себя СК, взаимодействующие с источником данных.

В общем случае архитектура ИУС является многоуровневой (рисунок 1). Уровни интерфейса и процессов взаимодействуют только с нижележащими уровнями. А на уровне функциональности, равно как и на уровне данных, взаимодействие может осуществляться между элементами уровня.

Развитие ИУС на основе сервис-ориентированного подхода рано или поздно может привести к тому, что сервисов (и, как следствие, структурных компонентов, которые они используют) становится достаточно много и без управления эффективность их использования снижается. Для решения этой проблемы необходимо использовать специализированный управляющий сервис (мета-сервис), основной задачей которого будет координация взаимодействия между структурными компонентами сервисов.

Рис. 1. Уровневая модель ИСУ

Проанализировав структурную модель ИУС с точки зрения сервис-ориентированной архитектуры, можно заключить следующее:

• 1)    ИУС с сервис-ориентированной архитектурой 9^оа включает множество структурных компонентов S^c = {S,f} и множество сервисов S = {5^}.

• 2)    Структурные компоненты и сервисы находятся в таких отношениях, что каждый сервис для своего успешного функционирования требует определённого множества структурных компонентов.

• 3)    ИУС с сервис-ориентированной архитектурой S^oa является динамической, т. е. для каждого определённого момента времени t вызывает некоторое множество сервисов S_t = {S₉^ и соответствующее им множество структурных компонентов S_t^c = ^5^, между которыми устанавливаются отношения зависимости.

• 4)    Любая конфигурация ИУС с СОА включает сервис управления.

• 5)    Будем считать, что качество функционирования ИУС с СОА (5^s03) в целом определяется качеством функционирования каждого сервиса в данный момент времени.

• 6)    Каждый сервис S = {^} и структурный компонент S^c = {Af} имеют множество требований С = {C_W}, критический уровень которых определяется соглашениями об уровне предоставления сервисов, стандартами, техническими регламентами, что и определяет качество функционирования S^oa в целом.

• 7)    Существует множество регуляторов А = {А"} сервисов, когда каждому отклонению от требований поставлено в соответствие множество регуляторов о" ^{А*} ■

Математическая модель мониторинга показателей структурных компонентов в сервис-ориентированной ИУС показывает, что функции F системы S^oa могут быть реализованы в момент времени tлишь при условии, что каждый структурный компонент обладает определёнными свойствами и параметрами, удовлетворяющими требованиям С = {C_w}.

F :STC хН xV хС хК хМ А, где STC = |ST^}, л1 = 1, л10 — множество состояний элементов множества 5е; SC={S„C}, л = 1,л0 — множество структурных компонентов; Н ={^д), д = 1,д0 — множество характеристик, используемых для описания структурных компонентов; I/ = {А}, s = l,s0 — множество значений показателей структурных компонентов; С = { СД, е = 1,е0 — множество тре- бований к структурным компонентам; К = {^у}, j = ^,j0 — мых для оценки соответствия предъявляемым требованиям компонентов; М =^МД, г = 1,г0 — множество возможных множество критериев, используе-состояния и свойств структурных регуляторов (действий) для при-

ведения в соответствие предъявляемым требованиям показателей сервисов; А = {А}' к = 1,^0 — множество регуляторов, необходимых для устранения отклонений текущих значений показателей структурного компонента от требуемых.

Требуется в определённые моменты времени t выявлять для каждого показателя V = {И₅} сервисов отклонение от соответствующего критического фактора, входящего в множество С = {C_W}, и запускать в действие множество регуляторов А„ —> {Ai} для приведения показателя сервиса в заданные границы. Эти задачи реализуют в ИУС сервисы мониторинга показателей структурных компонентов, входящие в состав сервисов управления СОА и управления информационной безопасностью.

Согласно принципу повторного использования, каждый структурный компонент может быть сервисом корпоративного уровня или предоставляться внешним потребителям, может быть использован как атомарный сервис и как элемент композитного сервиса. Поэтому любые неконтролируемые изменения в структурных компонентах могут привести к сбоям, к прерыванию или остановке процессов. Таким образом, в сервис-ориентированной ИУС мониторинг показателей структурных компонентов играет важную роль в управлении СОА.

Грамотное и полноценное управление невозможно без целостного понимания тех компонентов, или столпов, которые поддерживают зрелый СОА-проект. Конечно, СОА-проект можно строить только на основных механизмах (механизме) поддержки. Однако зрелый проект подразумевает больший уровень поддержки и рост уровня ответственности. Каждая предметная область требует разного подхода к управлению СОА, что соответствующим образом отражается на «политике». Поэтому необходимо по возможности производить унифицированное описание предметной области в виде взаимодействующих объектов, имеющих более понятные для специалистов-предметников средства. Примером может служить подход, использующий метаописание предметной области — онтологическое моделирование предметной области, ставшее особенно популярным в связи с идей семантического Web [5], для которого разработан язык OWL (Ontology Web Language) [6].

Онтологический подход к описанию предметной области ИУС. Онтология является спецификацией концептуализации предметной области [7]. Онтологии содержат словарь понятий предметной области, описание их смысла, иерархию понятий, связанных друг с другом некоторым видом отношений [8]. Согласно онтологическому подходу, предметная область представляет собой совокупность взаимосвязанных понятий, имеющих некоторые атрибуты и свойства. Одной из сильных сторон онтологии является возможность создавать определённые пользователем отношения между классами [9].

Онтологии определяют термины для представления или описания некоторой предметной области. Онтологии включают определённые пользователем формальные базовые концепции предметной области и их взаимоотношения. Компоненты онтологии — это концепты, или классы (описывают понятия предметной области), свойства класса (описывают различные характеристики концепта) и ограничения на свойства.

Онтологии вместе с множеством экземпляров классов представляют собой базу знаний. Класс может иметь подклассы — это более специализированные концепты, чем надклассы. Свойства классов представляют собой либо атрибуты, либо отношения между классами. Собственно отношения являются свойствами классов. Согласно OWL [6], онтологии состоят из последовательности аннотаций, аксиом и фактов. Аннотации описывают некоторые сведения об онтологии. Факты представляют собой экземпляры классов (представители), типы или утверждения об эквивалентности или различии экземпляров. Аксиомы обеспечивают информацию о классах и свойствах. Каждая аксиома класса содержит коллекцию более общих классов, т. е. классов, являющихся базовыми к данному классу, и набор ограничений на свойства. Ограничения описывают надклассы свойств, сколько элементов допустимо и набор этих элементов. Также в аксиомах описывается эквивалентность классов и характеристики свойств.

Свойства могут иметь характеристики симметричности, транзитивности, функциональности и инверсной функциональности.

Отношение P(X,Y) называется транзитивным, если для экземпляров понятий Vx 6 Х,у е Y,z е Z выполняется соотношение:

p(x,y^p(y,z^ p(x,zY где X,Y,Z — множества экземпляров понятий X, Y, Zсоответственно, р(х,у), p(y,z), p(z,x) — экземпляры отношений F\X,Y), P(Y,Z), P^X.Z) соответственно.

Отношение P(X,Y) называется симметричным, если ^х,у выполняется условие р(х,у^ р(у,ху

Отношение P(X,Y) называется функционально-эквивалентным (или функциональным), если Mx,y,z верно соотношение р(х,у)л p(x,z) =» у = z.

Отношения P^X,Y} и Pi(Y,X) называются инверсными, если ^х,у верно соотношение pl(x,y)« pl^x.zy На отношения наследования наложена по умолчанию характеристика транзитивности, т. е. если класс Xявляется подклассом Y, а класс /является подклассом Z, то класс X является подклассом Z. Транзитивность также является характеристикой отношений агрегации, т. е. отношений «быть частью». Если класс X содержит класс Y, а класс Y содержит класс Z, то класс X содержит класс Z.

На свойства могут накладываться ограничения. Первый тип ограничений — ограничение типов данных: свойство имеет тип данных из некоторого ограниченного набора типов данных («целое», «беззнаковое целое», «строка», «число с плавающей точкой», «булевская переменная», «длинное целое» и т. п.). Второй тип ограничений обычно связан с отношениями. Это ограничения на допустимые значения экземпляра класса Y в отношениях Р (X, Y). Допустимость значений определяется множеством существующих экземпляров класса Y ;Y . Ограничения могут накладываться и на мощность множества экземпляров отношений Р{Х ,Y{: |Р(%,К)|. Допускается указывать минимальное, максимальное и точное число в множестве. К ограничениям относится также требование на равенство экземпляров Y в отношениях Р (X, У) некоторым определённым экземплярам понятия Y. Допускается и предикат из ограничений.

Онтологии предлагается рассматривать как концептуальную основу декларативного описания понятий и семантического ядра, выполняющих описательные и управляющие функции в ИУС.

В рамках описания ИУС предлагается выделить три основные области (рисунок 2) понятий (онтологии): понятия предметной области, понятия области управления сервисами, понятия ИТ-области, — а также определить базовую, общую для них онтологию.

Общая онтология содержит понятие базового объекта и некоторые другие понятия, которые в равной степени принадлежат к любой из онтологий.

Онтологии предметной области выделяются в связи с тем, что ИУС предназначена для решения задач жизнедеятельности вуза в различных предметных областях. Поэтому ИУС должна оперировать понятиями предметной области.

Область ИТ-онтологий выделяется для реализации идеи отображения предметной области на область ИТ. Область управления процессами выделяется в связи с тем, что, во-первых, ИУС представляет собой автоматизированные сервисы, а, во-вторых, управление сервисами в равной степени относится к предметной области и к области ИТ.

Итак, ИУС можно представить как

15 = {BS,SO,rr,R_s}                                 (1)

где BS = ^b_k,k = 0,К -1} — понятия области управления сервисов (и отношений между ними), SO = {s,},/ =0,/-1 — множество понятий предметной области (в том числе отношений между понятиями), ГГ = {f_;|, j = 0,J -1 — множество понятий управления информационной средой и отношений между ними, R_s ={г₈{,1 = 0,1 -l,j = 0,J -1 — отношения между понятиями предметной области, ИТ-области и области управления сервисами:

D —fp Р Р Р X                                 ^7^

к₅ - |K_SS , K_SI, K_0I, Kg_S j                                            ^ZJ

Здесь:

R_ss = {BS ® 5}                                     (3)

описывает множество отношений между областью управления сервисами и понятиями предметной области — сервисы могут создавать, изменять, просматривать, удалять экземпляры понятий предметной области.

Множество

RSI={BS®IT}

описывает отношения между областью управления сервисами и понятиями ИТ-области. Эти отношения включают назначения прав пользователей на выполнение процессов, отношения сервисов со структурными компонентами и т. п. Множество

ROI = {SO ® IT{

описывает отношения между понятиями предметной области и ИТ-области, т. е. отражение объектов реального мира на ИТ-объекты.

Отношения Дописывают отношения, которые определены между понятиями в любой онтологии.

Таким образом, чтобы разработать эффективно сопровождаемую и эксплуатируемую ИУС вуза, необходимо разработать модель системы, представляющую собой онтологическое описание понятий и отношения между понятиями, семантическое ядро (с возможностью расширения) и механизм трансформации онтологического описания.

Семантическое ядро представляет собой элементарную функциональность (структурные компоненты). Данная функциональность может использоваться в различных подсистемах ИУС, из структурных компонентов могут быть составлены другие, более сложные, функциональности. Всё, что может быть выделено как общая функциональность, которая используется в ИУС более одного раза, реализует семантическое ядро. К семантическому ядру также относятся процедуры интерпретации понятий и отношений между ними.

Семантическое ядро позволяет в небольшие сроки разрабатывать новые сервисы и изменять существующие.

В обобщённую функциональность ИУС входит управление пользователями и их правами, маршрутизация запросов, управление эффективной работой СК, интерпретация понятий и отношений между ними, создание и редактирование экземпляров понятий и отношений, а также механизм создания отчётов из различных систем на основе интерпретации понятий и отношений между понятиями. Онтологическое описание содержит онтологии предметных областей деятельности вуза, управления процессами и описание понятий ИТ-области, а также отношения между понятиями.

Структурная схема концепции ИУС вуза представлена на рисунке 3. В основе концепции лежит онтологический подход, обеспечивающий разработку ИУС с использованием онтологической модели. Элементарная функциональность, входящая в семантическое ядро, реализует управляющие функции ИУС (авторизацию, аутентификацию, извлечение экземпляра понятия и т. п.) и функциональность предметной области (расчёт штатного расписания, составление отчётов и т. п.).

Кроме этого в семантическое ядро входят компоненты интерпретации правил поведения системы.

Для реализации алгоритмов управления процессами онтологическая модель содержит онтологии предметных областей деятельности вуза, области управления процессами и ИТ-области, а также отношения между онтологиями.

Возможность изменения онтологической модели реализуется с помощью инструмента создания понятий, отношений между понятиями, ограничений на атрибуты и создание, редактирование и удаление экземпляров понятий.

Онтологическое описание предметной области, в свою очередь, является совокупностью описаний предметных областей каждого сервиса (рисунок 4).

Рис. 3. Схема концепции ИУС вуза

Рис. 4. Онтология предметных областей

Механизмы трансформации онтологических описаний представляют собой инструментарий, обеспечивающий создание новых и изменение существующих понятий, установление между ними связей, определение ограничений на атрибуты понятия, на отношения между понятиями и на их удаление. Кроме этого механизм онтологических описаний включает создание и редактирование экземпляров любого из существующих понятий и описание экземпляров отношений между понятиями.

Заключение. Предлагаемая архитектура построения ИУС вуза обеспечивает масштабирование по ряду направлений, что в свою очередь, позволяет говорить о построении адаптивной системы. Гибкие настройки системы позволяют адаптироваться к меняющимся условиям внешней среды. Использование сервис-ориентированной технологии даёт возможность автоматически поддерживать качество данных, а также снижает временные и материальные затраты. Таким образом, систему можно внедрять по мере автоматизации отдельных направлений деятельности.

Использование единообразного описания предметной области посредством онтологического моделирования обеспечивает высокую интеграцию данных при постепенной автоматизации. В итоге общая онтологическая модель является суммой онтологических моделей внедряемых сервисов и модели управления ими.