Программные продукты и системы

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

К числу поддерживающих программных средств можно отнести редакторы Microsoft PowerPoint и Adobe Flash, позволяющие пользователю конструировать мультимедийные документы в интерактивном визуальном режиме WYSIWYG (What you see is what you get), при котором документ в процессе его создания и редактирования максимально соответствует конечному результату. Поскольку подобный режим особо важен для мультимедийных документов, создаваемых для наглядной визуализации содержащейся в них информации, для просмотра данных документа пользователю также обычно предоставляются интерактивные возможности, к примеру, возможность увеличить фотографию, построить график по табличным данным, просмотреть видеофрагмент к тексту.

К другим программным средствам, поддерживающим разработку мультимедийных документов, относятся CMS (Content Management Systems) – системы управления контентом интернет-сайтов, например Drupal [2]. Важной особенностью многих CMS, позволяющей расширять функциональность создаваемых на их базе сайтов, является возможность подключения к системе дополнительных программных модулей, часто реализованных сторонними разработчиками уже после создания самой системы и предназначенных для визуализации и редактирования новых (как правило, более сложных) видов данных, помещаемых на сайт. Таким новым видом может быть, к примеру, глава видеокурса, состоящая из видео и текстового описания.

Будем называть программные системы, предназначенные для создания, редактирования, хранения и визуализации мультимедийных документов, системами управления мультимедийными документами. Среди пользователей этих систем можно выделить две группы согласно их функциям и потребностям: конечные пользователи и пользователи-редакторы.

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

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

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

В целом можно выделить два основных подхода к созданию модели мультимедийного документа. В первом из них, который можно назвать «вложенные объекты», модель допускает неограниченное вложение друг в друга объектов-элемен­тов данных согласно определенным правилам. Кроме уже упомянутой HTML-модели, к этому подходу относятся модель документов Adobe Flash и модель, определяемая MXML-языком проектирования программных интерфейсов в IDE Adobe Flex Builder [3].

Указанный подход допускает комбинирование визуализируемых элементов-объектов разного вида в рамках одной страницы документа, и потому пользователь-редактор имеет потенциальную возможность изменять композицию страницы в ходе построения документа. В то же время количество разных видов объектов ограничено: в HTML-модели – набором тегов, а в модели документов Adobe Flash, допускающей группировку базовых фигур и символов, – набором возможных группировок. Введение в модель новых видов объектов (с помощью модулей сторонних разработчиков) изначально не предусмотрено, и при добавлении нового вида потребуется программирование средств для интерактивного просмотра и редактирования таких объектов (для этого обычно применяются языки программирования JavaScript для HTML-документов или ActionScript для Flash).

Другой подход к построению модели мультимедийного документа, который можно назвать «данные – визуализация» (от англ. «model – view»), используется в CMS-системах и основан на отделении хранимых в документе данных и их внешнего вида (визуализации). В рамках этого подхода для визуализации и редактирования данных определенного вида применяется свой программный модуль. К примеру, во многих CMS есть модуль для визуализации текстовых страниц, модуль визуализации объектов типа «новость», модуль показа ленты новостей (в последнем случае модуль визуализирует список объектов типа «новость»). Как правило, такой программный модуль обеспечивает также специальный пользовательский интерфейс, позволяющий редактировать в интерактивном режиме предназначенные для визуализации данные.

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

В данной работе предлагается модель мультимедийного документа, соединяющая два важных преимущества описанных подходов: расширение доступных видов объектов (подход «данные – визуализация») и комбинирование в рамках страницы документа нескольких объектов разных видов (подход «вложенные объекты»). В итоге это позволяет пользователю-редактору документа конструировать в интерактивном визуальном режиме страницу документа из объектов разного вида путем их свободного расположения в едином пространстве страницы, но без вложения друг в друга.

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

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

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

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

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

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

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

7.     Для визуализации и редактирования каждой страницы документа служит набор специальных компонент ядра системы управления документами, которые в ходе обработки страницы вызывают нужные программные модули для визуализации и редактирования объектов страницы согласно их виду. Указанный компонент поддерживает настройку параметров расположения объектов на странице, а также настройку их универсальных визуальных свойств.

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

Для представления визуализируемых данных в рамках описанной модели выбран язык XML благодаря его широкой распространенности и удобству в обработке. Основной XML-тег модели block помечает каждый объект страницы, его атрибутами являются универсальные характеристики объекта, такие как его идентификатор id, вид type, координаты на странице x и y, ширина width и высота height. Данные объекта записываются внутри этого тега, визуализируются и редактируются подключаемым модулем этого вида данных. Для корректности XML-документа, описывающего всю страницу (page – тег страницы), данные любого объекта страницы должны быть записаны по правилам языка XML. Приведем пример XML-описа­ния страницы документа в предложенной модели, где в качестве названий видов объектов используются имена соответствующих подключаемых модулей:

x="90" y="401" width="195" height="211">

"Hello World!"

x="500" y="401" width="195" height="211">

http://yandex.ru/logo.png

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

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

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

Получающаяся с учетом всех требований архитектура системы управления мультимедийными документами показана на рисунке. Ядро системы включает библиотеку визуализации и редактирования страниц документа, в которую входят компоненты различной обработки страниц документа. К ядру отнесены также сервисные компоненты для упрощения разработки подключаемых модулей визуализации и редактирования объектов новых видов. При обработке страниц документа компоненты ядра вызывают нужные модули визуализации и редактирования объектов разных видов, встретившихся в документе. Прокси-клас­сы при этом служат для изоляции программного кода модулей от ядра и упрощают тем самым реализацию его обратной совместимости. В хранилище XML-документов собраны описания мультимедийных документов (организация хранилища зависит от используемого программно-аппаратно­го комплекса).

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

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

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

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

В соответствии с описанной архитектурой была разработана и реализована программная система управления мультимедийными интернет-сайтами Fuzzle CMS [4]. Ядро системы и прокси-классы реализованы на языке программирования Action Script 3 для исполнения внутри виртуальной машины Flash. Этот выбор был обусловлен еще и тем, что виртуальная машина Flash доступна для многих программно-аппаратных комплексов.

Система Fuzzle CMS представляет собой клиент-серверное приложение. Ее клиентская часть включает библиотеку визуализации и редактирования страниц мультимедийного сайта, платформонезависимые компоненты и платформозависимые компоненты для веб-сервера, поддерживающего технологии PHP и MySQL. К клиентской части относится также библиотека подключаемых программных модулей визуализации и редактирования объектов для стандартных мультимедийных данных (например, форматированный текст, изображение). Серверная часть системы Fuzzle CMS является вспомогательной и предназначена для хранения авторизационных данных пользователей системы, содержимого интернет-сайтов, файлов с программным кодом подключаемых модулей и др.

Поясним работу одного из основных программных компонентов ядра системы, точнее, компонента библиотеки визуализации и редактирования, который отвечает за визуализацию страницы документа. Этот компонент загружает и последовательно обрабатывает XML-описание визуализируемой страницы документа. Для каждого встреченного тега block в соответствии с его атрибутом type создается объект данного вида, он размещается на странице согласно его атрибутам x, y, width, height, после чего вызывается компонент визуализации соответствующего подключаемого модуля, и в качестве параметра ему передаются данные объекта (расположенные между обрабатываемыми тегами block). Таким образом описываемый компонент реализует для пользователя режим просмотра страницы документа.

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

Если пользователь хочет отредактировать данные конкретного объекта или изменить параметры его визуализации, он должен войти в режим редактирования объекта (в системе Fuzzle CMS это реализовано как двойной клик мышью на объекте). При этом вызывается компонент редактирования из подключаемого программного модуля, соответствующего виду редактируемого объекта, и ему в качестве параметра передаются данные этого объекта (их XML-описание). По окончании редактирования данный компонент строит XML-описание измененного объекта.

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

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

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

В системе Fuzzle CMS реализована также возможность создания текстового описания мультимедийного документа для индексации его поисковыми машинами. Текстовое описание документа строится из текстовых описаний объектов, включенных в страницы документа (похожий подход описан в [5]). Текстовое описание каждого объекта складывается из строки-указания вида объекта (например, график или таблица), фразы на естественном языке, вводимой пользователем и характеризующей данные объекта, и, возможно, текста, извлеченного из этих данных (если они текстовые).

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

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

Как и система Fuzzle CMS, редактор FLAscheme представляет собой клиент-серверное приложение, существенным отличием которого от Fuzzle CMS является ограниченный набор типов визуализируемых объектов. Поскольку серверная часть FLAscheme зависит от CMS, в которую встраивается этот редактор (так как каждая система управления контентом по-своему хранит данные внутри страниц), были реализованы варианты серверной части для нескольких разных CMS, в том числе для систем WackoWiki, MediaWiki, WikkaWiki.

Реализация и использование программных систем Fuzzle CMS и FLAscheme показали гибкость и удобство рассмотренной модели мультимедийного документа, в которой удалось объединить два существенных свойства – расширяемость по видам визуализируемых объектов и ориентацию на интерактивный визуальный режим редактирования документов.

Литература

1.     Осин А.В. Мультимедиа в образовании: контекст информатизации. М.: Издательский сервис, 2004.

2.     Вандюк Дж. CMS Drupal 6: система для создания сайтов и управления ими. М.: Издат. дом «Вильямс», 2009.

3.     Кейзоун Ч., Лотт Дж. Программирование c использованием Adobe Flex. СПб: Питер, 2009.

4.     Описание и документация Fuzzle CMS. URL: http://fuzzle-cms.ru/ (дата обращения: 15.07.2011).

5.     Matellanes A. [et al.]. An architecture for multimedia content management // The 2nd European Workshop on the Integration of Knowledge, Semantics and Digital Media Technology, EWIMT, 2005.