Реферат: «Проект создания системы автоматизированного учёта пользовательских заявок по функционированию факультетской компьютерной сети»

Курсовая работа

Студента 322й группы

кафедры АСВК

факультета ВМиК

научный руководитель

«Проект создания системы автоматизированного учёта пользовательских заявок по функционированию факультетской компьютерной сети»

Москва, 2007г.

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

Студенты и сотрудники Лаборатории Программного Оборудования (Курячий Георгий – руководитель и координатор, Павел Кл***в, Арсений Насокин, Цветков Тимофей, Алергант Дмитрий – в разное время) работали над проектом, поставив перед собой цель разработать и внедрить электронную информационную систему, которая автоматизирует приём и учёт заявок пользователей, тем самым облегчив работу службы поддержки, повысив её эффективность и удобство для пользователей.

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

Содержание

1. Введение. 4

2. Постановка задачи. 5

2.1 Цели работы. 5

2.2 Требования к системе. 5

2.3 Функциональность системы. 6

2.3.1 Роли в системе. 6

2.3.2 Функциональность на основе ролей. 7

3. Содержательная часть. 9

3.1 Анализ существующих решений. 9

3.2 Выбор платформы разработки. 10

3.3 Распределение обязанностей. 11

3.4 Этапы и сроки работы. 11

3.5 Организация командного взаимодействия. 12

3.6 Техническая сторона предложенного решения. 12

3.6.1 Постановка технической проблемы. 12

3.6.2 Обзор решений данной проблемы… 13

3.6.3 Описание выбранного решения. 14

3.6.4 Информационная безопасность системы. 16

4. Выводы… 17

4.1 Выводы по организации работы. 17

4.2 Выводы по технической части. 17

4.3 Текущее состояние проекта. 17

5. Приложения. 18

Приложение 1 – интерфейс “IssueClassWithInterface”. 18

6. Литература. 20

1. Введение

Перед службой технической поддержки компьютерной сети факультета ВМиК стоит задача обеспечения работоспособности сети, приёма обращений от пользователей сети по случаям сбоев в сети и на компьютерах пользователей, и разнообразным административным вопросам (заведение e-mail, регистрация нового компьютера, взятие в пользование материального ресурса), и оперативное реагирование на данные обращения. В настоящий момент приём, учёт и обработка обращений от пользователей осуществляется вручную сотрудницами службы и записывается в бумажные журналы. Такой метод работы обладает существенными недостатками:

— Неудобство сложившейся системы для пользователей: По любым вопросам необходимо личное обращение пользователя к сотрудникам Лаборатории Программного Оборудования в аудиторию 765. При этом нужные сотрудники работают обычно только в первой половине дня, либо вообще по сложному графику.

— Недостаточная эффективность работы сотрудников «Лаборатории Программного Оборудования» по приёму и учёту заявок.

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

— Очень низкая эффективность в случае, если по каким-то причинам необходимо обратиться к архиву (истории) поданных заявок.

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

Студентам 322й группы Алерганту Дмитрию (автору настоящей работы) и Цветкову Тимофею было предложено разработать и внедрить на факультете вышеупомянутую информационную систему приёма и учёта заявок пользователей (“Request-tracking system”).

После беглого анализа существующих решений (см. пункт 4.1) стало ясно, что ни одно существующее решение не подходит полностью под поставленные перед системой требования (см. п2.2). Но поскольку создание подобной системы «с нуля» задача достаточно громоздкая, и поскольку существует масса систем request-tracking с открытым исходным кодом, наиболее разумным представилось попытаться построить нашу систему именно как доработку над имеющейся системой с открытым кодом. В качестве такой базы была выбрана (см. пункт 4.2) система roundup.

2. Постановка задачи

2.1 Цели работы.

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

Для факультета:

1) Оптимизировать работу службы технической поддержки факультетской сети, повысить эффективность труда сотрудников.

2) Повысить качество обслуживание пользователей сети.

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

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

Для исполнителей :

5) Получить опыт реальной разработки распределённой компьютерной информационной системы, включая:

a. Опыт совместной разработки в команде.

b. Опыт проектирования системы.

Опыт руководства проектом по разработке системы

c. Опыт программирования на языке Python

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

6) Выполнить требования учебного плана по части реализации курсовой работы.

2.2 Требования к системе.

Перед создаваемой системой были обозначены следующие основные требования:

1) Доступность. Система должна являться клиент-серверной, реализуя основные пользовательские интерфейсы в виде Web-интерфейса и интеграции с e-mail.

2) Дружественность. Система должна быть максимально дружественный к конечному пользователю, предоставляя ему максимально простой и понятный интерфейс.

3) Простота. Конечный пользователь должен иметь возможность пользоваться системой без предварительной регистрации и авторизации.

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

5) Расширяемость. Система должна легко расширяться в плане появления новых типов заявок, расширения старых и появления новых сценариев прохождения заявок, появления новых сервисов.

6) Поддерживаемость. Система должна свободно поддерживаться и в определённых пределах расширяться силами имеющегося администраторского состава факультетской сети.

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

2.3 Функциональность системы.

2.3.1 Роли в системе.

Было решено, что работа с системой будет осуществляться со стороны трёх основных категорий людей (ролей), каждая из которых имеет в системе отдельный интерфейс:

Пользователи :

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

Исполнители :

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

Операторы :

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

Администраторы :

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

2.3.2 Функциональность на основе ролей.

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

Будущему Оператору (Валерии Евгеньевне) были заданы вопросы, позволившие по возможности полно выяснить, как происходит процесс учёта пользовательских заявок в настоящее время. Будущего Исполнителя (Роману Кондакова) попросили самого описать, какие возможности использования системы он хотел бы видеть.

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

Функциональность для пользователей:

1) Пользователь должен иметь возможность пользоваться системой через web-интерфейс без какой либо авторизации.

2) Пользователи должны иметь возможность составлять новые заявки. На этапе Первой Очереди Функциональности интерфейс будет предельно упрощённым, не иерархическим. Одна гиперссылка — одна html-страница с одной формой, предназначенной для отправки информации для создания заявки одной категории. Наполнение формы определяется конфигурацией Системы при внедрении. На форме должны присутствовать обязательные и необязательные поля, заполнение обязательных должно немедленно проверяться посредством javascript.

3) После отправки заявки пользователю должен сообщаться уникальный номер заявки. Должен существовать Web-интерфейс для проверки пользователем статуса заявки по её номеру.

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

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

6) Рассматривается возможность создания на этапе Второй Очереди Функциональности email-интерфейса пользователя, являющего собой альтернативу Web-интерфейсу.

Функциональность для операторов:

1) Оператор должен работать с системой через Web-интерфейс с авторизацией.

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

3) Оператор должен видеть все новопоступившие и уже имеющиеся в системе заявки и совершать с ними следующие действия:

— Отклонить и закрыть заявку (флуд, проблема не относится к сфере ответственности Лаборатории Программного Оборудования, известная проблема, ..)

— Отредактировать поля заявки

— Добавить к заявке комментарий

— Принять заявку в работу, назначить её выполнение одним/нескольким исполнителям.

— Переназначить выполнение заявки другим исполнителем.

— Зарыть заявку как выполненную, поместить в архив закрытых заявок.

— Видеть статус и историю существования заявки.

— Отослать комментарий по заявке на e-mail пользователю (если указан)

— Распечатать по данным заявки заявление для подписи ответственным лицом.

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

Функциональность для исполнителей:

1) Исполнители в основном работают с системой через Web-интерфейс, а также получают разнообразные уведомления от системы через e-mail.

2) Исполнители получают уведомления о назначенных им операторам заявках, а также, обособленно – обо всех поступивших в систему нераспределённых заявках.

3) Исполнитель может:

— Видеть список распределённых на него заявок, и общий список нераспределённых ни на кого заявок. По отдельной ссылке – видеть список заявок, распределённых на любого другого Исполнителя.

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

— Заявить о своей ответственности над не распределённой на него заявкой («забрать себе» заявку), причём это относится как к «ничейной» заявке, так и к назначенной другому администратору.

— Отказаться от ответственности за заявку («снять её с себя»), сделав её ничейной.

— Добавлять комментарии к заявкам, редактировать информацию в них.

— Изменять режим своей email-подписки на уведомления о новых заявках.

3. Содержательная часть

3.1 Анализ существующих решений.

Был произведён обзор существующих систем подобного рода (Request tracker, Issue tracker, Trouble ticketing systems) информацию о которых удалось найти в Интернете.

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

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

Кроме того, по ряду причин нами было принято решение не рассматривать системы, созданные на платформе Java.

В результате были подробно рассмотрены следующие системы:

— RT (http://freshmeat.net/projects/requesttracker/): Мощнейшая trouble-ticketing система с открытым исходным кодом. Широко применяется, часто обновляться. Стабильна, хорошо документирована.

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

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

— IssueTrackerProduct (http://www.issuetrackerproduct.com/): Достаточно интересная и удобная система, хотя и редко используемая. Гибкая внутренняя архитектура должна легко адаптироваться под наши нужды. Система написана на языке Python с использованием сервера приложений Zope. Однако код практически не документирован, и на момент проведения исследования система давно не обновлялась и неизвестно, являлась ли стабильной. Что и послужило главным аргументом против этого варианта.

— Trouble Ticket Express ( www.troubleticketexpress.com/):

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

— Roundup (http://roundup.sourceforge.net/): Issue tracker, написанный на чистом Python. Отличительная особенность в том, что эта система изначально позиционируется не как готовое решение, а скорее как SDK для построения решения на его основе (хотя система работает и может быть использована и без модификаций). Технически Roundup представляет собой ядро в виде модуля Python, которое может настраиваться на конкретные применения посредством набора шаблонов. Шаблоны состоят из собственно HTML-шаблонов по технологии TAL, и Python-скриптов, дополняющих необходимую функциональность ядра посредством механизма так называемых «реакторов». Достаточно стабильный код, изрядный объём документации.

3.2 Выбор платформы разработки.

По результатам первичного рассмотрения в качестве основных кандидатов остались системы Express Trouble Ticketing и Roundup. В пользу первой – значительно меньший объём требуемых доработок, в пользу второй – лучшая приспособленность к доработкам, отсутствие необходимости выделять деньги и переводить их за рубеж.

Было решено выбрать между двумя системами, бросив жребий. В качестве жребия мы решили использовать 5-рублёвую монету. В случае выпадения «орла» выбирался первый вариант, в случае «решки» – второй. Для обеспечения справедливости условий монету бросало незаинтересованное лицо – симпатичная девушка-второкурсница, брюнетка по имени Алёна. Выпала «решка» и нами была взята за основу система Roundup.

Наша работа будет заключаться в модификации ядра и шаблонов Roundup вплоть до построения системы, отвечающей поставленным требованиям.

3.3 Распределение обязанностей.

По соглашению между участниками работы были следующим образом распределены роли в команде:

Алергант Дмитрий – руководитель проекта и технический писатель.

Цветков Тимофей – ведущий разработчик.

Насокин Арсений – разработчик.

3.4 Этапы и сроки работы.

Естественным образом было определено следующее разделение системы на этапы:

1) Предварительный этап.

— Разработка требований к системе, составление Проектного Задания.

— Выработка технического дизайна системы, выбор платформы для разработки.

— Разработка пользовательских интерфейсов системы.

— Выработка технологии эффективного врунтрикомандного взаимодействия.

2) Этап пилотного проекта

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

3) Основной этап

— Разработка всей намеченной функциональности системы.

— Внедрение системы в эксплуатацию

4) Заключительный этап

— Поддержка внедрённой системы.

— Продуктизация системы, дополнение системы необходимой документацией, предоставление системы мировому Open-Source сообществу.

3.5 Организация командного взаимодействия.

Первое время работы над проектом постоянно изменялась и совершенствовалась организация командного взаимодействия, по мере того как старая организация показывала себя неэффективной.

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

Была установлена система контроля версий SVN. Среди множества существующих систем контроля версий она на данный момент признана оптимальной, так как:

— SVN широко распространена, и потому очень хорошо отлажена и документирована.

— SVN значительно удобнее в использовании классического CVS, и в то же время очень похожа на него используемыми командами.

— Для SVN существует масса клиентов, в том числе удобных графических, подо все платформы.

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

До членов команды были доведены правила, согласно которым каждый commit в svn должен сопровождаться подробным комментарием об изменениях на русском языке в кодировке UTF-8.

Кроме того, в репозитарии SVN был завёдён специальный текстовый файл, куда руководитель проекта (я) записываю текущие задачи участников проекта, а сами участники дописывают туда информацию о статусе выполнения ими задач. Было решено не применять для нашего проекта специализированную Bug Tracking System, так как все участники проекта не выразили желание ей пользоваться.

В начале работы команда производила встречи с отчётом о проделанной работе раз в неделю, но подобный подход оказался малоэффективным и впоследствии мы перешли на встречи два раза в неделю.

3.6 Техническая сторона предложенного решения.

3.6.1 Постановка технической проблемы.

Была поставлена задача разработать и реализовать архитектуру факультетской системы Issue tracking на базе системы Roundup.

Было необходимо изучить архитектуру данной системы с целью сделать вывод о ее гибкости и пригодности для написания необходимой системы, соответствующей требованиям к системе (2.2) и внести в нее, если необходимо, минимальные и максимально согласующиеся с ее архитектурой изменения. Архитектура системы должна отвечать свойству гибкости, а также требовать внесения минимальных изменений в логическую часть уже имеющихся в Roundup шаблонов.

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

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

3.6.2 Обзор решений данной проблемы

Было рассмотрено несколько вариантов решения данной проблемы.

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

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

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

Рассмотрим первое решение. Backend к базе данных в Roundup не позволяет хранить произвольные объекты языка Python, поэтому все поля приходиться перед инициализацией системы указывать в специальном конфигурационном файле schema.py, по которому далее создаются соответствующие таблицы в БД. При использовании же агрегатора (объекта, который будет хранить в себе все типы заявок) в данном файле придется указывать все необходимые типы заявок, что не позволит «на лету» без остановки системы и пересоздании всех таблиц (Roundup всегда пересоздает таблицы в БД, если они соответствуют какому-то уже имеющемуся типу) создавать новые типы из уже имеющихся в других типах полей. Так же придется адаптировать систему, ориентированную на работу с заявкой конкретного типа на работу с агрегатором заявок. По этим соображениям данное решение также было отвергнуто.

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

В первом случае мы имеем хорошую, но не достаточно гибкую и динамическую систему. По сути такой мета-тип является примитивным интерфейсом, в котором слишком много приходиться «делать руками». По сему предпочтительнее реализация второго подхода с интерфейсом.

Для реализации второго подхода было рассмотрено несколько frameworks реализующих интерфейсы на языке Python: система интерфейсов использующихся в системе Zope[1], модуль интерфейсов в библиотеке Twisted[2], модуль интерфейсов в библиотеке Pli[3], а также ряд frameworks предложенных на ASPN[4].

При изучении всех из них лишь библиотека Pli предоставляла наиболее динамичные и мощные интерфейсы. Интерфейсы Zope и Twisted не являются достаточно динамичными (например, отсутствует наследование конкретного атрибута, или property конкретного атрибута). Framework предложенные на ASPN не предоставляют возможности указать строго тип атрибута, права доступа к нему (разрешение на чтение, запись), выполнение handler-ф-ии при обращении к атрибуту интерфейса. В библиотеке же Pli все это реализовано. Так же помимо самих интерфейсов есть богатая библиотека для работы с ними, предоставляющая такие возможности, как автоматическая генерация интерфейса по описывающему его dict, генерация интерфейса по объекту, добавление в динамике новых атрибутов в уже имеющийся интерфейс и т.п. Так же данный framework был хорошо знаком ведущему разработчику, так как он уже применял их на практике и более того принимал участие в их разработке.

3.6.3 Описание выбранного решения

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

В качестве расширения для мета-типа был использован pli.interface.objects.ObjectWithInterface уже содержащий в себе интерфейс (в терминологии pli.interface.interface). Был создан класс IssueObjectWithInterface унаследованный от IssueClass (класс, реализующий интерфейс) и указанного выше расширения. К сожалению, из-за технических тонкостей наследоваться прямо от IssueClass нельзя. Это вызвано тем, что интерфейс внутри объекта ObjectWithInterface создается при помощи метода __new__ создающего объект instance object ObjectWithInterface, однако далее должен вызываться конструктор __init__ класса IssueClass, который первым параметром должен получать объект типа instance object IssueClass. Для решения этой проблемы пришлось создать промежуточный класс (ProxyToIssueClass) унаследованный от IssueClass и с определенным конструктором __init__ в котором вызывается конструктор __init__ класса IssueClass (к сожалению, так как в Roundup используются только old-style классы __init__, приходится вызывать от IssueClass явно, а не через super, хотя в данном случае это не очень принципиально). Соответственно IssueObjectWithInterface унаследован уже не от IssueClass, а от ProxyToIssueClass (см. схему)

Теперь рассмотрим подробнее устройство IssueClassWithInterface. ObjectWithInterface содержит в себе только один интерфейс, который и используется для доступа к атрибутам класса. В IssueClassWithInterface был разработан механизм для хранения и использования нескольких интерфейсов. При создании объекта IssueClassWithInterface (в переопределенном методе __new__) создается так называемый корневой интерфейс, который обеспечивает доступ только к методам класса IssueClass и методам самого класса IssueClassWithInterface. При добавлении нового интерфейса этот интерфейс автоматически наследуется от корневого интерфейса, если не указана специальная опция, пользоваться которой стоит только в специальных случаях, например, когда необходимо заблокировать доступ либо ко всем, либо к большинству методов классов IssueClass и ObjectWithInterface.

В Приложении 1 можно ознакомиться с краткой документацией класса ObjectWithOnterface.

Опишем особенности использования некоторых методов.

Метод filterInterfaceAyttrs рекомендуется использовать для получения атрибутов интерфейса определяющих тип заявки. Для этого keyword должен быть указан, как 'issue', а свойство predicate у соответствующего атрибута интерфейса должно быть выставлено в is_issue_predicate (подчеркну, что is_issue_predicate это не строка, а функция).

Тоже относится и к методу dump_interface наличие которого вызвано текущей архитектурой Roundup, о чем будет пояснено ниже.

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

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

В будущем есть несколько решений данной проблемы. Например, можно сохранять dict (или dict'ы если интерфейс был от кого-то унаследован) описывающий данный интерфейс, по которому затем можно будет снова создавать интерфейс. Сложность реализации данного решения сопоставимо со сложностью уже имеющегося, однако его целесообразность пока не очевидна. Так же можно изменить backend Roundup на систему способную в динамике сохранять произвольные объекты языка Python. Надо сказать, что архитектурные решения в рамках проекта библиотеке Pli уже есть, однако написанный код еще не прошел стадию тестирования. Да и подобная задача может столкнуться с немалыми проблемами из-за архитектуры самого Roundup. Более того, необходимость такого решения не кажется целесообразным, так как вообще говоря в устоявшейся системе набор типов заявок изменяются крайне редко.

3.6.4 Информационная безопасность системы.

Поскольку создаваемая система рассчитана на достаточно массовое использование, и в том числе будет доступна из Интернет, особое внимание следует удалять информационной безопасности системы. Прежде всего, это касается авторизации и разграничения прав пользователей. В roundup есть достаточно мощная встроенная система авторизации и безопасности на основе ролей, её и предполагается использовать. Однако она будет иметь отношение лишь к «привилегированным» ролям в системе – операторам, исполнителям и администраторам. Конечные пользователи, согласно требованию простоты интерфейса и в виду отсутствия необходимости в авторизации будут пользоваться системой без неё. Вместо этого создаваемая система будет подразумевать возможность интеграции с различными системами защиты от спама. Такая интеграция будет произведена после первых признаков проблем в виде спама или флуда. Могут быть использованы различные средства, например ip black lists и/или human-test (просьба пользователя ввести число которое он видит на зашумлённой картинке для исключения использования системы роботами). Планируется отслеживать бюллетени информационной безопасности на предмет обнаружения возможных уязвимостей roundup. Кроме того, планируется инсталляция серверной части системы на машину, не несущую помимо этого иных критически важных функций.

4. Выводы

4.1 Выводы по организации работы.

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

4.2 Выводы по технической части.

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

4.3 Текущее состояние проекта.

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

5. Приложения

Приложение 1 – интерфейс “IssueClassWithInterface”

IssueClassWithInterface предоставляет (исключая внутренние служебные методы) следующие методы:

addInterface( self, name, interface_class, **flags):

Этот метод добавляет новый интерфейс с именем name в объект.

Флаги:

inherit По умолчанию True. Добавляемый интерфейс наследуется от корневого интерфейса (CoreInterface).

select По умолчанию False. Добавляемый интерфейс делается активным.

selectInterface ( self , name ):

Этот метод делает активным интерфейс с именем name сохраненный в объекте.

addDictInterface(self, inter_name, format, **flags):

Этот метод создает интерфейс по описывающему его dict и добавляет его в объект под именем name.

Флаги аналогичны флагам в методе addInterface.

addObjectInterface(obj, inter_name, **flags):

Этот метод создает интерфейс по указанному объекту obj и сохраняет его в объект под именем name.

Флаги аналогичны флагам в методе addInterface.

filterInterfaceAttrs(self, keyword=None, interface_name=None):

Этот метод возвращает все атрибуты интерфейса сохраненного в объекте под именем interface_name с keyword. Если interface_name не указан берется интерфейс активный в данный момент интерфейс.

getAttrName(self, attr=None, interface_name=None, keyword=None):

Этот метод возвращает строковое описание атрибута attr интерфейса сохраненного в объекте под именем interface_name.

Если attr не указан возвращается dict вида имя_аттрибута: строковое_описание.

Если interface_name не указан используется текущий актиывный интерфейс.

keyword аналогичен keyword в методе filerInterface. Если указан attr и не указан keyword, то фильтрация не происходит, если не указан attr и не указан keyword, то используется keyword='issue'

keys(self), values(self), items(self)

Этот метод возвращают список имен сохраненных в объекте интерфесов, список сохраненных интерфейсов в объекте (внимание, это могут быть не сами интерфейса, а тюпли наследуемых интерфейсов, аналогично mro), пары имя_интерфейса: интерфейс (тюпль интерфейсов) соответственно.

dump_interface(self, keyword=None, predicate=None, interface_name=None):

Этот метод сохраняет атрибуты интерфейса сохраненный в объекте с именем interface_name в специальный атрибут.

Если указан keyword сохраняются только атрибуты соответствующие данному keyword.

Этот метод написан для автоматического его вызова при сохранении заявки базу.