Единое окно доступа к образовательным ресурсам

Десятая конференция разработчиков свободных программ: Тезисы докладов

Голосов: 0

В книге собраны тезисы докладов, одобренных Программным комитетом десятой конференции разработчиков свободных программ, которая прошла в городе Калуге 20-22 сентября 2013 года.

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
    Дневное заседание (15.30–18.40)                                           11


Выпуск намечен на конец 2013 года.
  В следующих версиях школьного комплекта планируется:
   • Централизованное управление рабочими станциями со школь-
     ными дистрибутивами (управление программным обеспечением,
     параметрами настройки и их принудительным обновлением).
   • Управление службами, разнесёнными на несколько серверов.
   • Доработка и локализация образовательного программного обес-
     печения.
   • Поиск и отбор лучшего свободного программного обеспечения
     для образовательных целей.
   • Расширение документации и руководств для пользователей и
     администраторов.
   • Сбор и включение в комплекты методических материалов в раз-
     личных видах (методички, видеоуроки, презентации).


Филипп Занько
Казань, Исследовательский центр проблем энергетики КазНЦ РАН
Проект:   Школа Python/Tk http://russianlutheran.org/python/python.html

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


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


12                                                     20 сентября


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

Третий лишний
   Монополизация коммерческими издательствами управления все-
ми научными публикациями привела к парадоксальной ситуации: да-
же опубликовав статью в престижном журнале, учёный не открывает
свои результаты urbi et orbi, а, скорее, закрывает их, по крайней
мере от коллег из слаборазвитых стран.
   Выход из создавшегося тупика очевиден: научные издательства,
ставшие огромным самостоятельным бизнесом, должны быть по воз-
можности лишены своих посреднических функций между учёным и
научным сообществом. В принципе, для подтверждения квалифика-
ции исследователя не нужно ничего кроме хороших научных резуль-
татов. Яркий пример тому Григорий Перельман. Опубликованные
на личном сайте под лицензией Creative Commons, научные материа-
лы, если они действительно ценны и интересны, найдут и своего чи-
тателя, и своего квалифицированного критика. Конечно, за это не
платят, но разве лучше тратить свою жизнь на статьи, которые не
читает никто, кроме рецензента и редактора?

Выбор формата научной документации
   В век компьютеров перед каждым исследователем встает пробле-
ма выбора формата для его документов [1]. Разнообразие существую-


Дневное заседание (15.30–18.40)                                 13


щих форматов свидетельствует скорее о нерешённых проблемах, чем
о богатстве выбора.

 Формат                Преимущества           Недостатки
 Визуальные    фор-    Простота освоения,     Нечитаемый       код
 маты    WYSIWYG       широкое      распро-   разметки,      слож-
 (OpenOffice и др.)      странение, лёгкость    ность    работы    с
                       получения     печат-   большими        фай-
                       ного      документа    лами,     различные
                       среднего качества      сбои;     генерируе-
                                              мый HTML-код не
                                              читаем
 TEX/PDF               Простой, читаемый,     Трудоёмкий в освое-
                       мощный язык мате-      нии и использовании
                       матической размет-     из-за концентрации
                       ки, отличное каче-     на печатном пред-
                       ство печатного до-     ставлении докумен-
                       кумента; легко кон-    та
                       вертируется в читае-
                       мый HTML-код; удо-
                       бен для работы с
                       большими файлами
 DocBook               Универсальный          Сложный и громозд-
                       формат, легко кон-     кий, код плохо чита-
                       вертируется во все     ем
                       остальные основные
                       форматы докумен-
                       тации
 Облегчённые языки     Очень легко читает-    Облегчённый язык
 разметки (Markdown    ся исходный текст,     разметки          это
 и т.п.)               легко конвертирует-    посредник,       ещё
                       ся во все осталь-      один язык, который
                       ные основные фор-      нужно      осваивать
                       маты документации      пользователю


   Мне кажутся наиболее важными следующие требования к форма-
там научной документации:
   • формат должен быть открытым и свободным;


14                                                        20 сентября


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

Вариации на тему        литературного     программирования
   Инструменты, о которых здесь пойдет речь, обязаны свои появле-
нием желанию публиковать в Интернете не только научные статьи,
но и тексты программ обработки данных. При этом хотелось, чтобы
код легко понимался и не только его автором.
   Предлагаются простые инструменты для работы с файлами, в ко-
торых код Python совмещён с разметкой HTML [2]:
     • Процедура html2py()     это простой конвертер, способный пре-
       образовывать HTML-страницы, содержащие код Python, в сце-
       нарии Python с расширением .py и запускать их на выполнение.
       Всё, что не находится между тегами <CODE> и </CODE>, превра-
       щается в комментарии Python. А между этими тегами как раз
       и находятся кусочки кода Python. В целом они представля-
       ют собой законченную программу на Python, её можно редак-
       тировать с использованием подсветки синтаксиса и сохранять в
       обычном редакторе, например в IDLE.
     • Возможно и обратное преобразование: процедура py2html() уби-
       рает все добавленные комментарии, восстанавливая оформление
       исходного HTML-файла.
Подробное описание этих инструментов, их достоинств и недостат-
ков, правила оформления HTML-файлов со встроенным кодом Python
приведены в статье [2].


Дневное заседание (15.30–18.40)                                           15


   Совмещение программного кода и HTML-разметки в одном фла-
коне позволяет написать научную статью с традиционными описани-
ями, формулами, таблицами, рисунками, содержащую в себе готовую
программу обработки данных, и опубликовать её в Интернете в виде
одного текстового файла. Особенно привлекательна такая возмож-
ность, когда речь идет об учебных научных материалах.
   Исследование выполнено при финансовой поддержке РФФИ в
рамках научных проектов № 13-08-97063-р_поволжье_а, 13-08-97050-
р_поволжье_а, 13-08-00359-а, 13-08-00504-а.

Литература
[1] Реймонд, Э.С., Искусство программирования для Unix, М.: Издатель-
    ский дом Вильямс , 2005.– 544 с.
[2] Занько, Ф.С., Комментарии Python в стиле HTML, http://www.
    russianlutheran.org/python/literate/literate.html


Миронов Андрей Михайлович, Михеев Андрей Геннадьевич,
Пятецкий Валерий Ефимович
Москва, МГУ, Консалтинговая группа РУНА, НИТУ       МИСиС
Проект:   RunaWFE http://wf.runa.ru/rus

  Реализация алгоритма проверки ограниченности
 количества точек управления в свободной системе
         управления бизнес-процессами и
   административными регламентами RunaWFE


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


16                                                      20 сентября


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

Проблема взрывного роста количества точек
управления в экземпляре бизнес-процесса
   В 4.0 версии RunaWFE в соответствии со стандартом BPMN 2.0
элемент слияние работает следующим образом: для каждого входя-
щего перехода пришедшая в слияние точка управления ставится в
очередь. Если для всех входящих в слияние переходов их очереди
заполнены хотя бы одной точкой управления, то все точки управ-
ления, находящиеся на первой позиции очереди каждого перехода,
уничтожаются и на выходе из слияния генерируется одна точка
управления. Все остальные точки, находящиеся в очередях в слия-
ние , перемещаются на одну позицию вперед.
   При отсутствии ограничений на комбинации элементов на схе-
ме бизнес-процесса в случае такого определения поведения элемен-
та слияние возможно появление экземпляров бизнес-процессов, в
которых из-за ошибок проектирования количество точек управления
бесконечно возрастает с течением времени. Такие процессы могут со-
здать запредельную нагрузку на систему, что приведет к прекраще-
нию ее нормальной работы.


Дневное заседание (15.30–18.40)                                 17


   На рисунке 1 показан пример бизнес-процесса с бесконечно воз-
растающим количеством точек управления.




Рис. 1: Бизнес-процесс с бесконечно возрастающим количеством точек
                              управления




Описание алгоритма
   1. Нумерация узла Начало и всех переходов схемы
   Посчитаем количество линий (стрелок) на схеме бизнес-процесса.
Обозначим это количество n. Поставим в соответствие узлу Нача-
ло номер 1. Всем переходам (стрелкам) схемы поставим в соответ-
ствие числа от 2 до n+1 в произвольном порядке.
   2. Создание двух списков векторов и проверочного графа
векторов
   Создадим два списка векторов размерности n+1. Первая позиция
каждого вектора соответствует узлу-началу, остальные позиции пе-
реходу в соответствии с тем, как мы занумеровали переходы.
   В первом списке (обозначим его V) будут содержаться вектора воз-
можных изменений состояний. Все компоненты его могут принимать
значения только из множества {-1, 0, 1}. Этот список будет один раз
заполнен, и далее не будет изменяться.
   Второй список называется список векторов необработанных со-
стояний . Все его компоненты могут содержать только целые неотри-
цательные значения. Значение в каждой компоненте обозначает коли-


18                                                       20 сентября


чество точек управления на соответствующем переходе схемы. Этот
список будет динамически изменяться во время работы алгоритма.
   Проверочный граф представляет собой структуру из узлов, соот-
ветствующих векторам и направленных переходов (т.е. каждый пе-
реход направлен от одного узла-вектора к другому). Узлы являются
векторами состояний (размерности n+1). Все компоненты каждого
вектора могут содержать только целые неотрицательные значения.
Значение в каждой компоненте обозначает количество точек управ-
ления на соответствующем переходе схемы бизнес-процесса. Прове-
рочный граф тоже будет динамически изменяться во время работы
алгоритма.
   3. Заполнение списка V
   А. Рассмотрим стартовый узел. Для каждого выходящего из стар-
тового узла перехода добавим в список V вектор, в котором в позиции
стартового узла (то есть, в первой позиции) находится -1 , в позиции
выходящего перехода         +1 , а все остальные элементы нули.
   Б. Переберем в цикле все узлы Параллельный шлюз схемы
бизнес-процесса. Для каждого элемента добавим в список V вектор, в
котором для каждого входящего в узел перехода находится -1 , для
каждого выходящего перехода          +1 , а все остальные элементы
нули.
   В. Переберем в цикле все остальные узлы схемы бизнес-процесса.
Для каждого узла, для каждой пары возможных комбинаций входя-
щих и исходящих из этого узла переходов (входящий в узел переход,
исходящий из узла переход) добавим в список V вектор, в котором в
позиции входящего перехода находится -1 , в позиции выходящего
перехода     +1 , а все остальные элементы нули.
   Далее вектора из списка V будем обозначать v(j).
   4. Работа со списком векторов необработанных состояний
и проверочным графом (основной этап работы алгоритма)
   А. Поместим в проверочный граф вектор (1, 0, 0, ... , 0).
   (В первой позиции, соответствующей узлу-Началу          одна точка
управления, в остальных позициях нули)
   Б. Поместим в список список векторов необработанных состоя-
ний вектор (1, 0, 0, ... , 0).
   В. Будем выполнять следующую итерационную процедуру до мо-
мента ее окончания:
   Рассмотрим первый вектор из списка векторов необработанных
состояний. Назовем этот вектор текущим вектором u.


Дневное заседание (15.30–18.40)                               19


   Создадим для текущего вектора набор промежуточных векторов
следующим образом:
   Будем последовательно перебирать все вектора v(j) списка V:
   К текущему вектору u покомпонентно прибавим вектор v(j). Ес-
ли ни в одной позиции полученного вектора не будет отрицательных
чисел, то добавим этот вектор в набор промежуточных векторов.
   Найдем в наборе промежуточных векторов все вектора, которые
уже есть в проверочном графе. Для этих векторов создадим перехо-
ды из текущего вектора u в уже существующие вектора проверочного
графа, совпадающие с промежуточными векторами, а эти промежу-
точные вектора удалим из списка промежуточных векторов.
   Соединим текущий вектор u с оставшимися промежуточными век-
торами переходами и соответственно, удалим все оставшиеся проме-
жуточные вектора из списка промежуточных векторов, поместим их
в проверочный граф, а также добавим их в конец списка векторов
необработанных состояний.
   Удалим текущий вектор u из списка векторов необработанных со-
стояний.
   Рассмотрим список векторов необработанных состояний. Для каж-
дого вектора из этого списка:
   Построим множество векторов, из которых достижим данный узел
(алгоритм построения этого множества описан ниже). Проверим, есть
ли среди векторов, из которых достижим данный вектор, хотя бы
один вектор, котором в каком-то компоненте число строго меньше
числа из соответствующего компонента данного вектора, а в осталь-
ных меньше, или равно.
   Если хотя бы один такой вектор есть, то алгоритм останавлива-
ется, в редакторе процессов возникает сообщение результат работы
алгоритма: в бизнес-процессе может возникнуть ситуация с
бесконечно возрастающим количеством точек управления .
   Далее итерационная процедура повторяется.
   Если в какой-то момент времени список векторов необработанных
состояний оказался пустым, то алгоритм останавливается, в ре-
дакторе процессов возникает сообщение результат работы алгорит-
ма: в бизнес-процессе не может возникнуть ситуация с бес-
конечно возрастающим количеством точек управления .
   5. Построение множества векторов, из которых достижим
данный узел


20                                                    20 сентября


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

Результаты применения.

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



    
Яндекс цитирования Яндекс.Метрика