Принципы построения информационных систем для управления учебным процессом

08.12.2009

А.В. Адаманский

А.Л. Денисов

Принципы построения информационных систем для управления учебным процессом.


Автоматизация управления учебным процессом в вузе это задача, способы решения которой ИТ-компании предлагали всегда, но в течение и после реализации Инновационных образовательных программ, проведенных в рамках национального проекта «Образование», эта тема стала особенно популярной у многих компаний – интеграторов и производителей программного обеспечения. Вузам предлагается широкий спектр решений, разнообразный как по технологическим и архитектурным подходам, так и и по ценовому диапазону. Тем не менее, вузы, на наш взгляд, обладают определенной спецификой в использовании программных систем и спецификой бизнес-процессов, которые сильно отличаются от бизнес-процессов коммерческих структур. Авторы, имея некоторый опыт в разработке и внедрении подобных систем [1,2], хотели бы здесь поделиться этим опытом и предложить ряд принципов, которые представляются важными в данном контексте.

Целью любого вуза является обучение студентов, тем самым перед любым вузом стоит проблема повышения качества предоставлямых образовательных услуг и проблема управления качеством. Поэтому цели которые должны учитыватьcя при проектировании информационных систем, управляющих, по сути, производственным процесом, должны содержать в себе повышение качества образования, а также повышение качества управления и планирования в образовательном учреждении. Автоматизированная система управления должна давать инструменты, которые будут позволять системе менеджмента качества контролировать соответствующие процессы.

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

Основываясь на сформулированных целях, следует определить некоторые общие принципы построения таких систем, которые принимались авторами во внимание при создании Университетской информационной системы.

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

Рассмотрим детально структуру лицензий, использованных при создании Университетской информационной системы.

Уровень приложения

Компонент

Лицензии использованных программных продуктов

СУБД

IBM DB2 Express C

Бесплатный коммерческий продукт

Сервер приложений

Сервер УИС

Apache Software License, LGPL — Lesser GNU Public License

Клиент

UIS Client

Mozilla Public License

 

Не представляется разумным и возможным использовать для этих целей продукты с «копилефтными» лицензиями типа GNU GPL, так как это может, с одной стороны, затруднить профессиональную поддержку, ввиду того, что пользовательская база такого программного обеспечения недостаточно широка, а с другой — соответствие этой лицензии Части 4 Гражданского кодекса РФ является, по мнению некоторых, спорным вопросом [3]. В тоже время лица, заинтересованные в развитии такого проекта, так или иначе должны быть связаны с организациями, которые используют эту систему, поэтому необходимости передавать код сторонним лицам не возникает. Использование же LGPL не накладывает существенных ограничений на конечный продукт, а Mozilla Public License и Apache Software License полностью лишены «вирусной» составляющей GPL.

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

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

Другим принципом, который мы считаем важным в данном контексте, является доступность системы в любой момент через интернет по зашифрованному соединению по стандартному протоколу https. Необходимость расширения территории предоставления сервиса за пределы корпоративной сети может возникать, а может и не возникать. Но она должна быть предусмотрена архитектурой системы. Хотя, на данный момент, когда теденция переноса всех информационных сервисов в web является бесспорным фактом, аргументировать указанный принцип представляется излишним. Другой стороной выбора этой технологии является проблема отображения интерфейсов, так как HTML, как язык разметки не был изначально предназначен для отображения динамически меняющихся страниц, что принято обозначать термином Ajax (Asychronous Javascript and XML). На сегодняшний день эта тема является активным полем битвы между разными технологиями, среди которых Macromedia Flex (http://www.adobe.com/products/flex/), Microsoft Silverlight (http://www.microsoft.com/SILVERLIGHT/), JavaFX (http://javafx.com/), ряд библиотек, реализующих принципы Ajax для HTML (Qooxdoo — http://qooxdoo.org/, Google Web Tollkit — http://code.google.com/webtoolkit/, ZK — http://www.zkoss.org/), и, в том числе, «стандарт будущего» HTML 5 (http://www.w3.org/TR/html5/). Кроме того, задача выбора инструмента отображения интерфейсов для автоматизированной системы является более специальной. Основным требованием в данном случае является возможность построения удобных элементов управления, медиа-контент не имеет важного значения, кроме этого, важна простота и относительно низкая трудоемкость создания пользовательских интерфейсов.

На момент проектирования Университетской информационной системы не все из представленных сегодня инструментов и технологий, поддерживающих Ajax, были доступны. Большая часть из них ориентирована на отображение богатого медиа-контента и не удовлетворяла нашим лицензионным предпочтениям, подходы к которым изложены выше. В результате ряда проб выбор был остановлен на технологии XUL (https://developer.mozilla.org/En/XUL), используемой в проекте Mozilla (http://www.mozilla.org/) и браузере Firefox. XUL позволяет достаточно легко строить пользовательские интерфейсы, которые, отображаясь внутри браузера, оказываются неотличимыми от «родных» приложений Windows или Linux. Ограничение, которое принес XUL — это использование исключительно браузера Firefox для подключения к системе, что было бы неприемлемым для публичных веб-приложений. С другой стороны, это не является принципиальным ограничением в том случае, когда мы говорим об автоматизированных системах, так как экплуатация автоматизированных систем может предполагать определенную политику использования. Более того, в настоящее время, это ограничение можно рассматривать как преимущество. В процессе разработки УИС в Firefox были внесены некоторые изменения, которые, с одной стороны, были связаны с исправлением некоторых ошибок, важных только для нашего специального применения этого браузера, с другой, касались некоторых незначительных визуальных изменений. В то же время это дало возможность повысить уровень безопасности системы, так как дало возможность настройки пары сервер системы — браузер таким образом, что к серверу может подключится только определенная, специальная для этого сервера сборка браузера. Налагая административные ограничения на распространение дистрибутива этого браузера в организации, мы получаем повышение уровня безопасности. В то же время система остается веб-ориентированной, и все что нужно для работы с ней это браузер, который устанавливается двумя щелчками мыши.

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

Следующим принципом, который мы хотели бы здесь рассмотреть является совместимость с другими информационными системами, построенная на открытых стандартах. Комплексная автоматизация в большинстве случаев остается нереализованной, как правило в учреждениях работают несколько автоматизированных систем, закрывающих те или иные участки работы, данные необходимо передавать между этими системами, выгружать в сторонние программы для контролирующих организаций, предоставлять открытый доступ к тем или иным данных, которые формируются в системе (например расписание занятий или рейтинг-списки абитуриентов). Более того, иногда возникает необходимость обрабатывать данные, храниящиеся в системе, сторонними, специально к случаю написанными обработчиками. Такая необходимость может возникать, например, если организация хочет частную, временную проблему решить своми силами, не привлекая к ее решению разработчиков системы. Таким образом необходима не только совместимость с другими системами, но и возможность доступа к данным через определенный программный интерфейс, который также должен быть основан на некоторых открытых стандартах. Необходимость этого осознается многими, например ФГУ ГНИИ ИТТ «Информика» ведет большую работу в этой области [4]. Рассмотрим вкратце те подходы, которые были использованы для реализации этого принципа при создании Университетской информационной системы.

На самом деле задача совместимости или интероперабельности распадается на две части: с одной стороны, нам необходимо иметь программный интерфейс, который позволял бы изменять те или иные данные внутри системы, а с другой — программный способ получения заданных срезов данных по запросу. При этом мы должны учитывать, что стандартом де-факто при построении сложных автоматизированных систем является использование тех или иных средств объектно-реляционной проекции. Университетская информационная система не является здесь исключением, используя библиотеки Hibernate. Коротко требования к протоколу обновления данных следующие. Данный протокол должен предоставлять возможность работать с данными системы УИС и избирательно их изменять, используя платформо-независимый программный API доступный по сети. Сообщения протокола, должны быть определены в формате который может быть представлен в текстовом виде и понятен для чтения человеком. Для передачи сообщений протокола должны быть использованы открытые стандарты передачи информации, которые в настоящий момент наиболее полно реализуются сторонними производителями программных систем. Должна иметься возможность использования криптографически устойчивого шифрования при передаче сообщений протокола. Таким образом, чтобы описывать стуктуры данных, которые необходимо загрузить в систему, или изменить существующие, наиболее логичным средством представляется использование XML. Для УИС на основе XML был разработан протокол, который полностью покрывает модель данных системы, передача сообщений этого протокола реализована с помощью HTTP и SOAP.

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

  1. Система выборки данных должна быть доступна для сторонних программных клиентов по Ethernet сети используя HTTP и RMI протоколы передачи данных.

  2. Для эффективного взаимодействия с клиентами, реализованными на Java платформе, должен быть организован доступ к данным по RMI протоколу.

  3. При доступе по HTTP протоколу должна обеспечиваться кроссплатформенность программных клиентов, т.е. программные клиенты могут быть реализованы на языках и технологиях отличных от Java и стека стандартов Java EE, например на C/C++, PHP, Perl, Python, Ruby, JavaScript. Данные могут быть представлены в формате JSON или YAML, что должно позволить их интерпретацию как программами, скриптовыми программами (JavaScript), а также легкий просмотр и интерпретацию человеком.

  4. При доступе по HTTP протоколу, необходимо обеспечить доступ к данным используя идеологию REST (Representational state transfer), для обеспечения кроссплатформенной передачи данных без сохранения состояния между запросами, что должно обеспечивать широкие возможности для масштабирования производительности системы выгрузки данных, а также удобство взаимодействия с тонкими скриптовыми клиентами (JavaScript программа в web обозревателе).

  5. Должен быть обеспечен доступ к данным через технологию web сервисов по высокоуровневому SOAP протоколу через HTTP протокол.

  6. Необходимо иметь возможность делать выборки по всей модели данных системы. При выборке данных внешняя программная система должна иметь возможность задавать условия выборки, перечень выбираемых объектов в желаемых отношениях.

  7. На стороне источника данных должна обеспечиваться проверка прав доступа клиентов к объектам модели данных.

  8. На стороне источника данных необходимо обеспечить кеширование в памяти и жестком диске выгружаемых объектов модели данных, в целях снижения нагрузки на СУБД и уменьшения времени отклика системы при передачи данных клиентам.

Основываясь на этих условиях, выбор формата данных для выгрузки был сделан в пользу YAML (http://yaml.org/). Этот выбор был продиктован следующими факторами: YAML разметка легко читаема человеком; YAML более компактен и лаконичен по сравнению с XML, это важно при программной обработке данных, а так-же передачи данных по сети; широко-используемый в настоящее время в интернете формат представления данных JSON является подмножеством языка YAML; существуют большое множество программных библиотек разбора YAML- и JSON- разметки во всех распространенных на сегодняшний день программных технологиях: C/C++, .NET, Perl, PHP, Python, Ruby, Java, JavaScript, Delphy.

Еще один принцип, который был использован при проектировании и создании Университетской информационной системы и который авторы считают важным, это тиражируемость программного обеспечения. Несмотря на его очевидность, он далеко не всегда применяется при создании такого рода систем. Легко заметить, что тиражируемость тесно связана с другими перечисленными подходами.

Резюмируя, перечислим описанные выше подходы к проектированию и разработке автоматизированных систем для вузов:

  • Использование открытых и бесплатных технологий;
  • Доступность системы 24x7 через Интернет в любой момент по зашифрованному соединению, предоставление сервиса как Rich internet application;
  • Совместимость с другими информационными системами построенная на открытых стандартах;
  • Совместная работа с клиентами над развитием системы (поставка исходного кода УИС, техническая поддержка);
  • Тиражируемость программного обеспечения.

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

 

[1] Адаманский А.В. Архитектура контейнера программных компонент Jaxion. Вестник НГУ. Серия: Информационные технологии. Том 2, выпуск 1, 2005г.

[2] Адаманский А.В., Денисов А.Л., Кочеев А.А. Опыт автоматизации вуза. Система УИС. Вестник НГУ. Серия: Информационные технологии. Том 4, выпуск 1, 2006г.

[3] С.А. Середа Свободны ли в России «свободные лицензии»? Патенты и лицензии, вып. 4, 2009г. ISSN 0869-5466

[4] Принципы построения и описания профилей стандартов и спецификаций информационно-образовательных сред. Метаданные для информационно-образовательных ресурсов сферы образования. ФГУ ГНИИ ИТТ Информика. 2009г.

 

Статьи