Библиотека сайта rus-linux.net
Система VisTrails
Глава 23 из 1 тома книги "Архитектура приложений с открытым исходным кодом".
Оригинал: "VisTrails", глава из книги "The Architecture of Open Source Applications"Авторы: Juliana Freire, David Koop, Emanuele Santos, Carlos Scheidegger, Claudio Silva, and Huy T. Vo
Дата публикации: 2012 г.
Перевод: Н.Ромоданов
Дата перевода: март 2013 г.
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
23.4. Компоненты и возможности
Как уже говорилось выше, в системе VisTrails предоставляется набор функций и пользовательских интерфейсов, упрощающих создание и выполнение исследовательских задач, в которых требуются вычисления. Ниже мы опишем некоторые из них. Мы также кратко обсудим, как система VisTrails используется в качестве инфраструктуры, поддерживающей создание публикаций с большим объемом информации о происхождении данных. Более полное описание системы VisTrails и ее возможностей смотрите в документации, имеющейся в сети [6].
Рис.23.6: Таблица визуализации
23.4.1. Таблица визуализации
Система VisTrails позволяет пользователям с помощью таблицы визуализации исследовать и сравнить результаты, полученные в нескольких рабочих процессах (смотрите рис 23.6). Эта таблица (электронная таблица — прим.пер.) представляет собой пакет VisTrails со своим собственным интерфейсом, состоящий из листов и ячеек. Каждый лист содержит набор ячеек и обладает настраиваемым интерфейсом. Ячейка содержит визуальное представление результатов, созданных рабочим процессом, и ее можно настроить для отображения различных типов данных.
Чтобы отобразить ячейку таблицы, в рабочем процессе должен быть модуль, являющийся производным от базового модуля SpreadsheetCell. Каждый модуль SpreadsheetCell соответствует отдельной ячейке в таблице, так что в одном рабочем процессе можно создавать несколько ячеек. Метод compute модуля SpreadsheetCell осуществляет обработку взаимодействия между движком Execution Engine (рис. 23.3) и электронной таблицей. Во время выполнения таблица создает ячейку в соответствие с запрошенным ею типом при помощи динамического создания экземпляра класса Python. Таким образом, конкретные визуальные представления можно получить с помощью создания подкласса SpreadsheetCell, имеющего метод compute, который отправит в таблицу сообщение о конкретном типе ячейки. Например, в рабочем процессе на рис.23.1, MplFigureCell является модулем SpreadsheetCell, созданным для показа изображений, созданных с помощью matplotlib.
Поскольку в таблице в качестве основы графического пользовательского интерфейса применяется PyQt, виджеты конкретных ячеек должны быть подклассами класса QWidget из PyQt. В них также должен быть определен метод updateContents, который, когда поступают новые данные, вызывается таблицей для обновления виджета. В виджете каждой ячейки можно с помощью реализации метода toolbar дополнительно определить специальную инструментальную панель; когда ячейка выбирается, эта панель будет отображаться на месте инструментальной панели таблицы.
На рис 23.6 показана таблица для случая, когда выбрана ячейка VTK; в этом случае в инструментальной панели представлены конкретные виджеты, предназначенные для экспорта изображений PDF, возвращать обратно в рабочий процесс информацию о положении камеры и создавать анимации. В пакете электронной таблицы определен настраиваемый виджет QCellWidget, в которым предлагаются обычные функции, такие как воспроизведение истории (анимация) и отработка мульти-сенсорных событий. Его можно использовать вместо виджета QWidget для более быстрой разработки ячеек новых типов.
Даже хотя в таблице в качестве типов используются виджеты PyQt, можно интегрировать виджеты, написанные с помощью других инструментальных средств, предназначенных для создания графических пользовательских интерфейсов. Чтобы это сделать, виджет должен экспортировать свои элементы на нативную платформу, а затем можно воспользоваться PyQt с тем, чтобы их получить. Мы используем такой подход для виджета VTKCell, т. к. виджен фактически написан на языке C++. Во время выполнения, виджет VTKCell получает идентификатор обработчика окна Win32, X11 или Cocoa/Carbon в зависимости от используемой системы, и отображает его в канвас таблицы.
Листы могут настраиваться точно также, как и ячейки. По умолчанию, каждый лист имеет табличную компоновку и помещается в окно с закладками. Однако, любой лист можно отсоединить от окна электронной таблицы, чтобы можно было видеть одновременно несколько листов. Также можно с помощью подкласса класса StandardWidgetSheet, который является виджетом PyQt, создать другую компоновку листа. Подкласс StandardWidgetSheet управляет расположением ячеек, а также взаимодействует с ними в режиме редактирования. В режиме редактирования, пользователи могут манипулировать с расположением ячеек и выполнять дополнительные действия с самими ячейками, а не только с их содержимым. К числу таких действий относится применение аналогий (смотрите раздел 23.4) и создание новых версий рабочих процессов, работающих с исследуемыми параметрами.
23.4.2. Визуальные различия и аналогии
Когда мы разработали систему VisTrails, мы, в добавок, к возможности сбора данных, хотели использовать информацию о происхождении данных. Во-первых, мы хотели, чтобы пользователи видели точные различия между версиями, но потом мы поняли, что более полезной функцией была бы возможность определять различия в других рабочих процессах. Решение обеих этих задач, возможно, поскольку в системе VisTrails отслеживается эволюция рабочих процессов.
Поскольку в дереве версий собираются все изменения и мы можем инвертировать каждое действие, мы можем найти полную последовательность действий, с помощью которых одна версия преобразуется в другую. Обратите внимание, что некоторые изменения компенсируют друг друга, что делает возможным сократить эту последовательность. Например, нет необходимости при определении различий учитывать добавление модуля, который был позже удален. Наконец, у нас есть некоторые эвристики для дальнейшего упрощения последовательности: когда один и тот же модуль появился в обоих рабочих процессах, но был добавлен с помощью отдельных действий, мы, мы отменить его добавление и удаление.
Анализируя набор изменений, мы можем создать визуальное представление, в котором показаны похожие и различные модули, соединения и параметры. Это проиллюстрировано на рис.23.4. Модули и соединения, которые появляются в обоих рабочих процессах, показаны серым цветом, а те, которые появляются только в одном рабочем процессе, окрашены в тот цвет, который соответствует тому рабочему процессу, в котором они находятся. Совпадающие модули с различными параметрами оттеняются светло серым и пользователь может для каждого модуля проверить различия параметров по таблице, в которой показаны значения для каждого рабочего процесса.
Операция аналогии позволяет пользователям определить эти различия и применить их к другим рабочим процессам. Если пользователь внес ряд изменений в существующий рабочий процесс (например, изменяет разрешение и формат файла для выдаваемого изображения), он может с помощью аналогии применить те же самые изменения к другим рабочим процессам. Для этого пользователь выбирает исходный и целевой рабочие процессы, по которым определяется набор необходимых изменений, а также рабочий процесс, к которому по аналогии должны быть применены эти различия. Система VisTrails вычисляет различие между первыми двумя рабочими процессами, взятыми в качестве шаблона, а затем определяет, как нужно переопределить это различие с тем, чтобы применить его к третьему рабочему процессу. Поскольку различия можно применять к рабочим процессам, которые не совпадают с начальным рабочим процессом, нам нужно нестрогое соответствие (soft matching), которое позволяет считать соответствующими аналогичные модули. С помощью такого соответствия, мы можем переопределить различие таким образом, чтобы к выбранному рабочему процессу можно было применить последовательность изменений [SVK +07]. Метод не является абсолютно надежным, и могут создаваться такие новые рабочие процессы, которые будут не совсем такими, как нам хотелось. В таких случаях, пользователь может попытаться исправить любые возникшие ошибки, либо может вернуться к предыдущей версии и применить изменения вручную.
Чтобы вычислить нестрогое соответствие, используемое в аналогиях, мы потребуется соблюсти баланс между локальными соответствиями (одинаковых или очень похожих модулей) с общей структурой рабочего процесса. Отметим, что вычисление даже идентичного соответствия неэффективно из-за строгости изоморфизма подграфов, поэтому мы нам требуется использовать эвристику. Короче говоря, если в двух рабочих процессах два в некотором смысле похожих модуля находятся среди сходных соседей, мы можем сделать вывод, что эти два модуля функционируют аналогичным образом и должны также расцениваться как соответствующие друг другу. Более формально, мы строим продукционный граф, в котором каждый узел является возможным сопряжением модулей в исходных рабочих процессах, а ребра обозначают общие соединения. Затем, мы запускаем шаги рассеяния оценок в каждом узле по ребрам, идущим к соседних узлам. Это марковский процесс, аналогичный ранжированию страниц, используемому Google, который, в конце концов, сойдется, и, в сущности, останется набор оценок, в которых теперь будет некоторая глобальная информация. Исходя из этих оценок мы можем с помощью порога, определяющие очень разнородные модули как непарные, определить лучшее соответствие.
Далее: 23.4.3. Запрос информации о происхождении