Профиль стандартов и спецификаций информационно-образовательных сред
Архитектура образовательных технологических систем
Под образовательной технологической системой (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, можно сказать, что данная обобщенная модель определяет ряд важных принципов формирования профиля, но не предусматривает способов представления результатов их применения.
