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

Версия 1.0
Старых В.А., Башмаков А.И.
ФГУ ГНИИ ИТТ «Информика»

Назад Оглавление Вперёд

6 Источники формирования профиля

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

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

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

6.1 Ссылочная модель совместно используемых объектов контента

Ссылочная модель совместно используемых объектов контента (SCORM) [2] фактически представляет собой функциональный профиль стандартов и спецификаций для систем электронного обучения. SCORM определяет принципиальные технические решения для ИОС, в которой реализуются процессы электронного обучения на основе web-технологий.

SCORM базируется на концепции образовательных объектов (ОО –learning objects), предусматривающей декомпозицию учебного материала на относительно небольшие единицы контента, рассчитанные на многократное применение в разных самостоятельных и независимых контекстах. Под ОО понимается автономный в техническом и содержательном отношениях электронный ИР, представляющий часть учебного материала и предназначенный для динамического формирования агрегированных единиц контента, соответствующих урокам, разделам, модулям, курсам и т.п., в расчете на конкретные образовательные потребности. ОО компонуются в виде стандартных дистрибутивных пакетов, которые имеют унифицированное описание (манифест), включающее метаданные, и размещаются в Интернет-хранилищах (репозиториях ОО). Выбор ОО из репозиториев, построение из них агрегированных средств и предоставление последних для работы учащимся (доставку) обеспечивают системы управления учебным процессом (СУУП - Learning Management Systems).

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

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

В SCORM выделены семь основных сервисов в составе СУУП:

• администрирование учебной деятельностью (Course Administration);

• управление контентом (Content Management);

• доставка контента (Delivery);

• управление навигацией по контенту (Sequencing);

• тестирование и оценивание учащегося (Testing/Assessment);

• контроль за ходом и результатами работы учащегося (Tracking);

• ведение профиля учащегося (Learner Profile).

Наряду с ними СУУП реализует два интерфейса: с репозиторием ОО и с отдельным ОО, функционирующим в клиентской среде исполнения приложений (по умолчанию – web-браузере учащегося). Второй интерфейс обеспечивает передачу СУУП информации о ходе и результатах работы учащегося, которые заносятся в его профиль (в составе базы данных СУУП) и используются для оценивания выполнения каждого задания и приобретенной компетенции, управления навигацией по контенту, планирования и управления обучением.

Несмотря на то, что основной средой доставки контента является WWW, технологические решения SCORM позволяют осуществлять процессы электронного обучения в локальных вычислительных сетях и в локальном (off-line) режиме.

Спецификация SCORM имеет весьма прагматичный характер. В ней рассматриваются только ключевые аспекты технологий электронного обучения, являющиеся критическими для обеспечения интероперабельности систем и обладающие достаточной степенью готовности к унификации решений. К числу таких направлений[2] отнесены:

• компоновка дистрибутивных пакетов ИР (ОО);

• методы агрегации и дезагрегации контента;

• метаданные для ИР;

• модели навигации и методы управления навигацией по контенту;

• интерфейс между СУУП и ОО.

Соответствующие предметные области представлены базовыми НТД, разработанными AICC, IEEE и IMS. Для них в SCORM определены уточнения.

Прочие сегменты предметной области ИОС – системы управления образовательным учреждением и информационно-библиотечные технологии – в спецификации SCORM не рассматриваются.

Для иллюстрации структуры SCORM используется метафора книжного шкафа: полки представляют технологические направления, а книги – НТД. Формально структура профиля не описана. Связи между его разделами охарактеризованы вербально.

Тем не менее, технические решения, специфицируемые SCORM, в целом относятся к уровню прикладных сервисов. Текущая версия SCORM в явном виде не привязана к сервисно-ориентированной архитектуре. Распределение НТД и регламентируемых ими сущностей по уровням в ней не предусмотрено.

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

6.2 Абстрактная модель для систем электронного обучения

Абстрактная модель для систем электронного обучения (IMS Abstract Framework – IAF) [5] предложена IMS именно в качестве концептуальной схемы, описывающей общий контекст разрабатываемых консорциумом НТД. Она выделяет уровни программных компонентов ИОС, интерфейсы между которыми могут регламентироваться НТД (в том числе спецификациями IMS).

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

В IAF выделены четыре базовых уровня программных компонентов ИОС (рис. 4). Каждый компонент предоставляет услуги компонентам вышележащего уровня и использует услуги компонентов нижележащего уровня. Соответствующее взаимодействие обеспечивают межуровневые интерфейсы. Наряду с ними модель предусматривает определение интерфейсов и протоколов для взаимодействия компонентов, расположенных на одном уровне. Описанная многоуровневая организация соответствует принципам эталонных моделей среды открытых систем [3, 4] и взаимодействия открытых систем [6], а также сервисно-ориентированной архитектуры [7].

Рис. 4. Многоуровневая структура IAF

Функциональность приложения ИОС определяется набором прикладных сервисов, которые оно предоставляет пользователям. Приложение может задействовать один или несколько прикладных сервисов, реализуя пользовательский интерфейс для доступа к ним.

Согласно IAF, приложения в общем случае являются предметно-ориентированными, отражающими специфику сферы применения. Для систем электронного обучения в первом приближении IMS выделяет три прикладных области: общее образование, профессиональное образование и корпоративное обучение. Условия для взаимодействия систем обеспечивает их построение на основе интероперабельных сервисов, реализующих унифицированные технические решения, адаптированные к сфере применения. Подобная адаптация соответствует уточнениям базовых НТД, вводимым в прикладных профилях.

Функциональную специфику ИОС, ассоциируемую с процессами электронного обучения, представляют прикладные сервисы. Например, к данной категории относятся сервисы управления навигацией по учебному материалу, тестирования и оценивания, управления репозиторием ОО и др.

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

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

• интерфейс прикладных сервисов (Application Services interface), определяющий правила взаимодействия прикладных сервисов, имеющих общее функциональное назначение;

• интерфейс общих сервисов (Common Services interface), обеспечивающий доступ к ним со стороны прикладных сервисов;

• интерфейс клиентской среды исполнения приложений (run-time interface), служащий механизмом взаимодействия клиентского приложения с удаленным сервисом.

Поскольку общие и инфраструктурные сервисы не привязаны к контексту электронного обучения, унификация технических решений для них выходит за рамки деятельности IMS. Данные уровни используются в IAF для представления компонентов, базирующихся на готовых НТД, предложенных другими организациями. На основе этих НТД IMS определяет ряд профилей, а также разрабатывает рекомендации по выбору и реализации соответствующих решений, направленные на достижение максимальной открытости ИОС и независимости приложений от вычислительной платформы [8–10].

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

Унификация технических решений предусматривает разработку стандартных определений прикладных сервисов. Интерфейс, называемый точкой доступа к сервису (Service Access Point – SAP), служит его абстрактным представлением и может быть реализован как интерфейс прикладного программирования (Application Program Interface – API). Каждый сервис имеет единственную такую точку доступа SAP. Его реализация скрыта от внешних сущностей, а взаимодействие с ним осуществляется только через SAP.

В IAF вводится абстрактное описание (модель) сервиса, основанное на методологии объектно-ориентированного моделирования и выражаемое с помощью языка UML [11]. Сервис представляет пакет классов (в терминологии UML). Его функциональность базируется на механизмах агрегации классов и наследования. Собственно SAP соответствуют интерфейсные классы. Для описания отношений между классами используются диаграммы классов и пакетов UML.

Определение сервиса включает информационный и функциональный разделы (рис. 5). В первом специфицируются структуры данных, представляемые атрибутами классов, во втором – способы изменения значений атрибутов, представляемые операторами классов, и схемы взаимодействия сервисов. Функциональный раздел отражает поведенческие аспекты сервиса, которые могут выражаться с помощью диаграмм состояний и диаграмм последовательности UML. Подобные описания фиксируют то, как сервис должен отвечать на различные воздействия (запросы других сервисов, те или иные события).

Рис. 5. Абстрактная модель сервиса

Абстрактная модель сервиса далее проецируется на технологии реализации (языки программирования, описания данных, разметки, механизмы обмена сообщения, транспортные протоколы). Такие отображения называются привязками (bindings). Спецификации IMS первого поколения, разработанные до появления IAF, в основном определяли структуры данных и не затрагивали поведенческих аспектов сервисов. Для представления структур данных использовался XML-синтаксис, поэтому в этих спецификациях вводились XML-привязки информационных моделей. Синтаксис описывался средствами языка XML Schema.

Необходимо подчеркнуть, что абстрактная модель сервиса не зависит от ее привязок к технологиям реализации. Очевидно, что одной и той же информационной структуре может соответствовать множество синтаксических представлений, а одна и та же функциональность может быть описана и воплощена с помощью разных механизмов. Одним из принципов IAF является поддержка различных привязок (XML, WSDL, Java и др.). Использование UML для спецификация моделей сервисов в ряде случаев позволяет автоматически формировать для них привязки.

В рамках IAF привязки абстрактных моделей сервисов служат соединительным звеном между уровнями сервисов и инфраструктуры (рис. 6). Инвариантность моделей к технологии реализации обеспечивает их неизменность при переходе от одной технологии к другой; для такого перехода необходимо определить только новые привязки. В свою очередь, реализации, основанные на разных привязках, остаются совместимыми на уровне абстрактных моделей.

Рис. 6. Роль привязок абстрактной модели сервиса в IAF

Рекомендации IMS по выбору технологии реализации сервисов и построению соответствующих привязок предусматривают использование:

• XML в качестве базового формата представления данных;

• WSDL для описания функциональности сервисов;

• SOAP with Attachments как общего механизма обмена сообщениями;

• HTTP и HTTPS в качестве базовых транспортных протоколов.

Поскольку сервисы обычно имеют комплексный характер, в спецификациях IMS описываются модели их составных частей, называемых компонентами (в терминологии UML). Компонент представляет собой полное или частичное воплощение функциональности сервиса. Таким образом, сервисы реализуются как комбинации компонентов.

Основным предметом рассмотрения в спецификациях IMS являются модели компонентов для систем электронного обучения. Некоторые спецификации затрагивают вопросы интероперабельности этих компонентов с системами управления образовательным учреждением. Информационно-библиотечные технологии для сферы образования оставлены за рамками работ IMS.

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

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

IAF фиксирует вертикальные, межуровневые связи компонентов ИОС и соответствующих им НТД. В то же время отношения между компонентами одного уровня она не отражает. В IAF не предусмотрены средства формального описания таких отношений. Они характеризуются вербально в спецификациях IMS.

Состав компонентов на каждом уровне IAF определяется исключительно эвристически. Подобный подход в сочетании с отсутствием уровня, который представляет БП, реализуемые на основе ИОС, и формальных описаний связей компонентов в рамках уровня не позволяют использовать IAF для выявления недостающих компонентов и НТД.

6.3 Архитектура образовательных технологических систем

Под образовательной технологической системой (Learning Technology System – LTS) понимается образовательная система, включающая средства ИТ-поддержки. Данное понятие введено Комитетом по стандартизации образовательных технологий (Learning Technology Standards Committee – LTSC) IEEE и покрывает множество ИТ и компьютерных систем, предназначенных для решения задач образования, обучения, тренажа, профессиональной подготовки, повышения квалификации, обеспечения учебной деятельности и т.п.

Концептуальной основой развиваемых LTSC решений в области унификации образовательных ИТ служит архитектура LTS (Learning Technology Systems Architecture – LTSA) [12]. Она инвариантна к предметной области обучения, вычислительной платформе, педагогическим методам, техническим и культурным особенностям. LTSA является обобщенной моделью, которая представляет как существующие, так и будущие классы LTS, и определяет ключевые принципы их построения, направленные на обеспечение переносимости и интероперабельности, путем выделения критических системных интерфейсов. Учитывая широту и обобщенный характер LTSA, более точно считать ее метаархитектурой, охватывающей множество возможных архитектур ИОС и входящих в них систем.

В LTSA предусмотрены 5 уровней описания LTS (рис. 7):

1) взаимодействие учащегося и среды (Learner and Environment Interactions);

2) потребности учащихся и особенности процессов обучения, учитываемые при проектировании LTS (Learner-Related Design Features);

3) системные компоненты (System Components);

4) варианты воплощения и бизнес-приоритеты (Implementation Perspectives and Priorities);

5) действующие компоненты и решения, обеспечивающие интероперабельность – способы представления данных, интерфейсы API, протоколы (Operational Components and Interoperability – codings, APIs, protocols).

Рис. 7. Уровни LTSA

Приведенная последовательность уровней соответствует постепенной конкретизации представления LTS. Иными словами, для данного уровня следующий по порядку уровень является реализацией, а предшествующий – абстракцией.

На первом уровне LTSA располагается единственная простая модель (рис. 8), в которой учебный процесс с точки зрения обеспечивающих его ИТ рассматривается как взаимодействие двух активных компонентов (процессов): среды (ИОС) и учащегося. Содержанием этого взаимодействия является передача информации от среды к учащемуся, в результате чего последний приобретает необходимую компетенцию. Компонент "Обобщенный учащийся" (Learner Entity) может соответствовать человеку, учебной группе или коллективу, члены которого выступают в разных ролях. Совместная работа в рамках учебной группы относится к внутренней структуре "обобщенного учащегося".

Данная модель детализируется в целях выявления потребностей учащихся и особенностей учебного процесса, которые необходимо учесть при проектировании LTS. Описания таких детализацией, выраженные вербально, приводятся на втором уровне LTSA.

Рис. 8. Уровень взаимодействия учащегося и среды

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

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

Уровень системных компонентов в LTSA является центральным. Только для него в [12] введено нормативное определение.

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

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

Схема обобщенной архитектуры LTS показана на рис. 9. Овалы обозначают процессы, прямоугольники – хранилища, сплошные стрелки – потоки данных, штриховые стрелки – потоки управляющей информации.

Рис. 9. Уровень системных компонентов (обобщенная архитектура LTS)

Процесс "Учащийся" представляет отдельного учащегося или группу учащихся, взаимодействующих между собой либо работающих автономно. Он получает мультимедийную информацию от процесса "Доставка", трансформирующего содержимое ИР в статические, динамические и интерактивные представления.

Процесс "Оценивание" осуществляет анализ действий учащегося, поступающих через поток "Поведение", с учетом сведений об их контексте, направляемых процессом "Доставка" через соответствующий поток. Результаты анализа заносятся в хранилище данных об учащихся, а оценка текущего состояния выполнения педагогических задач передается процессу "Преподаватель/инструктор".

Последний упомянутый компонент реализует функции управления учебным процессом. На основе информации о работе учащегося в текущем и предыдущих сеансах, его предпочтениях, стоящих перед ним педагогических задачах и оценках их выполнения он формулирует запрос, посылаемый репозиторию ИР для селекции релевантного учебного материала. Получив ответ на него в виде метаданных о выделенных ИР, "Преподаватель/инструктор" выбирает наиболее подходящий материал и направляет ссылку на него процессу "Доставка".

Системные компоненты LTS, показанные на рис. 9, имеют концептуальный, а не физический характер. LTSA не требует, чтобы реализация LTS охватывала всю обобщенную архитектуру и состояла из отдельных идентифицируемых модулей с именами и функциональностью, определенными для системных компонентов. Конкретная LTS в зависимости от ее назначения может воплощать как всю обобщенную архитектуру, так и ее часть. В свою очередь, концептуальный системный компонент может соответствовать одному или нескольким физическим модулям. И наоборот, физический модуль может реализовывать один или несколько концептуальных системных компонентов.

Обобщенная архитектура LTS детализируется применительно к различным видам образовательных ИТ и компьютерных средств обучения. Типовые варианты ее воплощения (детализации), представляющие точки зрения на LTSA и связанные с ней бизнес-приоритеты заинтересованных лиц (stakeholders), специфицируются на уровне 4. Под заинтересованными лицами в данном контексте понимаются персоны, организации, группы персон и организаций, специализирующиеся в различных областях образовательных ИТ – разработчики программных продуктов и ИР для сферы образования, дистрибьюторы и провайдеры контента, поставщики образовательных услуг, т.е. все, кто заинтересован в унификации технических решений для ИОС на основе LTSA.

Точка зрения заинтересованного лица отражает:

• системные компоненты LTS, принадлежащие области его интересов;

• относительную важность этих компонентов;

• критические интерфейсы, обеспечивающие интероперабельность LTS.

Точка зрения описывается с помощью диаграммы, снабженной структурированным текстовым комментарием. Диаграмма содержит схему обобщенной архитектуры LTS, на которой выделены системные компоненты, соответствующие бизнес-приоритетам первой и второй очереди. Компоненты без выделения имеют существенно меньшее значение или вообще не входят в рассматриваемую область интересов. Представительный набор описаний типовых точек зрения на LTSA приведен в приложении к [12].

Конкретные технические решения, создающие условия для интероперабельности LTS, специфицируются на 5-м уровне. Эти решения относятся к типовым вариантам воплощения обобщенной архитектуры LTSA, выделенным на уровне 4.

В [12] содержатся рекомендации по разработке стандартов и спецификаций для обеспечения интероперабельности ИТ. Данный процесс включает этапы определения требований, функциональности, концептуальной модели, семантики, а также набора привязок (интерфейсов API, форматов данных и протоколов).

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

Выступая в качестве метаархитектуры, LTSA создает эффективные возможности для:

• анализа предметной области профиля и декомпозиции ее на сегменты (технологические направления), для которых требуется унификация технических решений;

• определения ключевых интерфейсов между типовыми компонентами ИОС (подсистемами LTS);

• интеграции ИОС и их компонентов;

• анализа и проектирования архитектур конкретных интероперабельнных LTS;

• поиска компромиссов между точками зрения на LTSA заинтересованных лиц, представляющих различные области образовательных ИТ.

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

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

Недостатком LTSA является неоднородность ее уровней. Так, на уровнях 1 и 3 располагаются фиксированные метамодели, на уровнях 2 и 4 – варианты их детализации. Конкретные технические решения относятся к уровню 5.

На разных уровнях LTSA используются различные способы спецификации моделей: на уровнях 1 и 3 – системная нотация Йордана, на уровне 4 – эта нотация в сочетании с вербальными описаниями, на уровне 2 – только текстовые описания, на уровне 5 – разнообразные формы представления технических решений (API, форматов данных и протоколов).

Уровни LTSA существенно отличаются и по степени их методологической проработки, изложенной в [12]. Если метамодели уровней 1 и 3 рассмотрены весьма подробно, а для уровня 4 приведено большое число описаний типовых точек зрения на LTSA, то уровень 5 представлен краткими общими рекомендациями по созданию стандартов и спецификаций для обеспечения интероперабельности ИТ, а уровень 2 является фактически пустым (его детализация оставлена за рамками [12]).

Неоднородность касается и охвата уровнями предметной области профиля. Метамодель уровня 1 отражает исключительно процесс обучения (точнее, его ИТ-поддержку). Однако типовые точки зрения на LTSA, соответствующие вариантам воплощения обобщенной архитектуры LTS, наряду с данным сегментом представляют множество других технологических направлений ИОС, включая цифровые библиотеки и автоматизированные системы управления образовательным учреждением, а также ряд смежных областей ИТ. Получается, что метамодель, служащая отправной точкой для анализа и определения требований к архитектуре LTS, является более узкой по сравнению со множеством моделей, которые должны строиться с учетом этих требований, т.е. она покрывает только часть точек зрения на LTSA.

Еще один недостаток LTSA заключается в отсутствии в ней формальных средств описания межуровневых отношений, в первую очередь – связей между уровнями 2 и 3, 4 и 5.

Подводя черту под обзором проблемных сторон LTSA, можно сказать, что данная обобщенная модель определяет ряд важных принципов формирования профиля, но не предусматривает способов представления результатов их применения.

7 Принципы построения профиля

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

1. Профиль разрабатывается в соответствии с методологией открытых систем в целях обеспечения открытости ИОС: создания условий для переносимости и интероперабельности ИОС и их компонентов, а также мобильности пользователей ИОС [1, 3, 4]. Таким образом, в профиль могут включаться только открытые стандарты и спецификации, т.е. общедоступные НТД, не зависящие от конкретных аппаратно-программных средств и технологий, поддерживаемые открытым, гласным согласительным процессом, который направлен на постоянную адаптацию и развитие соответствующих решений.

2. В профиле фиксируются стандартные зрелые устойчивые решения, отвечающие установленным требованиям и рассчитанные на широкое применение. Они могут адаптироваться к прикладной области (образовательным задачам), что отражается в уточнениях базовых НТД. Необходимость разработки новых НТД возникает только в случае отсутствия подходящих готовых или потенциально адаптируемых решений.

3. Профиль отражает особенности сферы образования России (законодательные, организационно-методические, технологические, инфраструктурные и др.).

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

5. Профиль не привязан к конкретной архитектуре ИОС и покрывает широкий спектр возможных архитектур, основанных на современных технологических концепциях:

• распределенной реализации ИОС;

• стандартных решениях Интернет/интранет;

• платформно-независимых технологиях (XML, Java, WSDL и т.д.);

• сервисно-ориентированной архитектуре;

• многоагентных системах и др.

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

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

Назад Оглавление Вперёд