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

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ ГОУ ВПО "Северо-Кавказский Государственный Технический Университет". ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ
• 1.1 Результаты предпроектного обследования
• 1.1.1 Объекты и методы проведения предпроектного обследования
• 1.1.2 Программа проведения обследования
• 1.1.3 Результаты предпроектного обследования и их анализ
• 1.1.4 Анализ проблемных ситуаций и обоснование путей их решения
• 1.2 Формулировка задач проектирования
• 1.2.1 Общие сведения
• 1.2.2 Назначение, цели создания интерактивных сервисов
• 1.2.3 Характеристика объекта автоматизации
• 1.2.4 Требования к подсистеме
• 1.2.5 Состав и содержание работ по созданию подсистемы
• 1.2.6 Порядок контроля приемки подсистемы
• 1.2.7 Требования к составу и содержанию работ по подготовке объекта
• автоматизации к вводу интерактивного сервиса в действие
• 1.2.8 Требование к документированию
• 1.2.9 Источники разработки
• Выводы
• 2. РЕАЛИЗАЦИЯ ИНТЕРАКТИВНЫХ СЕРВИСОВ
• 2.1 Обоснование выбора среды реализации сервисов
• 2.3 Концептуальное проектирование интерактивных сервисов
• 2.4 Создание логической модели базы данных интерактивных сервисов
• 2.3.1 Определение сущностей модели базы данных
• 2.3.2 Определение атрибутов сущностей базы данных интерактивного сервиса
• 2.3.3 Определение связей между сущностями базы данных интерактивного сервиса
• 2.3.4 Задание первичных ключей сущностей
• 2.3.5 Логическа модель данных
• 2.4 Создание физической модели базы данных интерактивных сервисов
• 2.4.1 Генерирование SQL-сценария создания базы данныхинформационной подсистемы средствами Django ORM
• 2.5 Создание проекта и модулей
• 2.6 Реализация интерактивных сервисов
• 2.6.1 Разработка интерфейса сервисов
• 2.6.2 Создание модели данных
• 2.6.3 Создание представлений и привязок URL
• 2.6.4 Реализация формы обратной связи
• 2.6.5 Реализация формы поиска
• 2.6.6 Пользовательская проверка орфографии в сервисе
• 2.6.7 Настройка Web-сервера lighthttpd
• Выводы
• 3. ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
• 3.1 Общие сведения об интерактивных сервисах доступа к справочнику СевКавГТУ г. Ставрополь
• 3.2 Функциональное назначение интерактивных сервисов доступа к телефонному справочнику СевКавГТУ г. Ставрополь
• 3.3 Описание логической структуры интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г. Ставрополь
• 3.4 Требование к техническому обеспечению
• 3.4.1 Общие требования
• 3.4.2 Требования к центральному процессору
• 3.4.3 Требования к оперативному запоминающему устройству
• 3.4.4 Требования к наличию сводного места на жестком диске
• 3.4.5 Требования к монитору
• 3.4.6 Требования к принтеру
• 3.5 Установка и вызов интерактивных сервисов
• 3.6 Входные данные интерактивных сервисов
• 3.6.1 Входные данные сервиса вывода телефонных номеров
• 3.6.2 Входные данные интерактивного сервиса генерации текстовой версии телефонного справочника
• 3.7 Выходные данные
• 3.7.1 Выходные данные интерактивных сервисов вывода телефонных номеров
• 3.8 Результаты тестирования
• 3.9 Краткая инструкция пользователя по работе с интерактивными сервисами
• Выводы
• 4. Технико-экономическое обоснование проекта
• 4.1 Краткая характеристика проекта
• 4.2 Трудоёмкость выполняемых работ
• 4.3 Расчёт себестоимости интерактивных сервисов
• 4.4 Оценка экономической эффективности внедрения программного продукта
• 4.5 Основные технико-экономические показатели проекта
• Выводы
• ЗАКЛЮЧЕНИЕ
• БИБЛИОГРАФИЧЕСКИЙ СПИСОК
• ПРИЛОЖЕНИЕ
• ВВЕДЕНИЕ
• Актуальность разработки интерактивных сервисов доступа к расписанию занятий СевКавГТУ, г. Ставрополь обусловлена отсутствием быстрого и удобного доступа к контактным данным сотрудников и подразделений ГОУ ВПО "Северо-Кавказский Государственный Технический Университет" (далее ВУЗ).
• Целью разработки дипломного проекта является предоставление легкого доступа к контактным данным сотрудников и подразделений ВУЗа, а также к его реквизитам широкому кругу заинтересованных лиц.

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

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

Во втором разделе пояснительной записки рассматриваются вопросы реализации интерактивных сервисов доступа к телефонному справочнику ВУЗа. Обосновывается выбор среды разработки Eclipse, выбор СУБД и языка программирования Python. Описывается структура разработанной базы данных.

В третьем разделе дипломного проекта описываются информационное, программное и техническое обеспечение разработанных интерактивных сервисов. Производится обоснование требований к техническому обеспечению, гарантирующих нормальную работу интерактивных сервисов доступа к расписанию занятий СевКавГТУ.

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

В заключении рассматриваются основные итоги дипломного проектирования и намечены перспективные направления дальнейшего развития его темы.

В библиографическом списке указан перечень из 23 источников информации.

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

интерактивный программирование база данный

1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ ГОУ ВПО "Северо-Кавказский Государственный Технический Университет". ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

1.1 Результаты предпроектного обследования

1.1.1 Объекты и методы проведения предпроектного обследования

В рамках темы дипломного проекта объектами обследования являются:

а) Образовательно-информационный отдел ВУЗа;

б) организационно-функциональная структура ВУЗа;

в) организация документооборота ВУЗа.

Обследование предприятия производится путем опроса сотрудников ВУЗа.

Основными целями выполнения предпроектного обследования являются:

а) изучение предметной области;

б) анализ проблемных ситуаций, возникающих при функционировнии действующих интерактивных сервисов;

в) интеграция с IP-телефонией ВУЗа.

1.1.2 Программа проведения обследования

Программа обследования ВУЗа представлена в таблице 1.1.

Таблица 1.1 - Программа обследования предприятия

Наименование вопроса	Источник информации	Получатель информации
Общая характеристика	Устав СевКавГТУ	Проектировщик Сучков Р.Г.
Организационная структура	Аналогично	Аналогично
Цели деятельности	Аналогично	Аналогично
Наличие проблемных ситуаций в деятельности СевКавГТУ	Аналогично	Аналогично
Цели деятельности ОИЦ	Директор ОИЦ, положение о ОИЦ СевКавГТУ	Аналогично
Наличие проблемных ситуаций в деятельности ОИЦ	Директор ОИЦ	Аналогично
Наличие средств вычислительной техники и программного обеспечения в ОИЦ	Заместитель директора ОИЦ	Аналогично

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

1.1.3 Результаты предпроектного обследования и их анализ

Общая характеристика учреждения. Северо-Кавказский государственный технический университет создан в 1971 году постановлениями Совета Министров СССР на базе филиала Краснодарского политехнического института в г. Ставрополе под наименованием Ставропольский политехнический институт, переименованного в Ставропольский государственный технический университет приказом Государственного комитета Российской Федерации по высшему образованию. Ввиду того, что Ставропольский технический университет являлся одним из ведущих вузов региона, единственным по своему профилю на Северном Кавказе, приказом Министерства образования Российской Федерации он переименован в Северо-Кавказский государственный технический университет.

Полное наименование университета: государственное образовательное учреждение высшего профессионального образования "Северо-Кавказский государственный технический университет". Сокращенное наименование - СевКавГТУ.

Место нахождения СевКавГТУ: Россия, Ставропольский край, г. Ставрополь, проспект Кулакова, дом 2. Почтовый адрес: Россия, 355029, г. Ставрополь, проспект Кулакова, дом 2.

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

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

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

Рисунок 1.1 - Схема организационной структуры ВУЗа

Конкретная функциональная структура управления определяется в зависимости от сочетания двух основных типов руководства - линейного (ректор, проректора) и функционального (специализация глав отделов) [6].

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

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

Лучше всего делить систему на подсистемы по функциональному признаку, то есть на основе выполняемых системой функций, а также существующей линейной структуры управления. Функциональная иерархия предполагает специализацию по отдельным функциям управления на всех уровнях этой иерархии [7].

В составе учреждения целесообразно выделить четыре области управления:

1) управление планированием;

2) управление учебным процессом;

3) управление обеспечением;

4) управление научной деятельностью.

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

Таблица 1.2 - Функциональные области и процессы в них протекающие

Номер и название функциональной области	Функциональные процессы
1. Управление планированием	1.1 Прогнозирование спроса на выпускаемых специалистов
	1.2 Внесение изменений в сроки, периоды обучения, графики проведения экзаменов и зачетов
	1.3 Составление требований к подготовке специалистов
2. Управление учебным процессом	2.1 Составление расписания занятий
	2.2 Распределение нагрузки преподавателям
	2.3 Разработка учебно-методических пособий
	2.4 Организационно-воспитательная деятельность
	2.5 Организация учебного процесса
3. Управление обеспечением	3.1 Управление кадрами
	3.2 Управление материальными средствами
	3.3 Делопроизводство
4. Управление научной деятельностью	4.1 Организация и планирование научно-исследовательских работ по инновационной деятельности и проведения фундаментальных и поисковых исследований
	4.2 Организация семинаров, конференций
	4.3 Создание наиболее благоприятных условий при подготовке специалистов и создании кандидатских и докторских диссертаций

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

Х - полное участие в процессе;

/ - частичное участие в процессе;

0 - ответственность за выполнение процесса.

Таблица 1.3 - Организационно-управленческая модель ВУЗа

Функциональные области

Управление планированием

Управление учебным процессом

Управление обеспечением

Управление научной деятельностью

Ответственные лица

1.1

1.2

1.3

2.1

2.2

2.3

2.4

2.5

3.1

3.2

3.3

4.1

4.2

4.3

Проректор

?/

0

?/

?/

?/

?/

?/

?/

Бухгалтерия

?/

УМУ

?/

?/

?/

/

?/

Деканаты

/

/

?/

?/

0/

Отдел кадров

?/

Общий отдел

0

ОИЦ

/

?/

/

/

/

НТЦ

0/

Лаборатории

?/

Кафедры

/

/

?/

?/

/

?/

Диспетчерская

0?

/

Цели функционирования. В результате проведенного обследования ВУЗа были выделены основные цели, средства их достижения и сформулированы критерии эффективности применяемых мер. Главной целью функционирования является подготовка высококвалифицированных специалистов для удовлетворения потребности общества в высококвалифицированных кадрах, разработка и внедрение результатов научных исследований, проведение семинар и научных конференций. Правильно построенное дерево целей в дальнейшем легко может быть преобразовано в план-график или диаграмму Ганта [1].

Данные по целям приведены в таблице 1.4. В таблице указаны подцели основанные на главной цели. Результатом объединения указанных целей является дерево целей, представленное на рисунке 1.2.

Таблица 1.4 - Цели деятельности ВУЗа, средства достижения и критерии оценки уровня достижения цели

Цель	Средства достижения	Критерий эффективности
Ц1 - улучшение качества образования	Ц11 - совершенствование учебно-технологической базы Ц12 - совершенствование научно-методической базы Ц13 - совершенствование программ обучения Ц14 - внедрение новых и улучшение существующих средств контроля качества образования Ц15 - поощрение лучших студентов Ц16 - подбор профессорско-преподавательского состава Ц17 - проведение работ по повышению квалификации специалистов	Проведение и победы в региональных, федеральных и международных олимпиадах, участие в конференциях, хозяйственно-договорных тематиках Увеличение количества договоров о проведении производственной практики и договоров о сотрудничестве с университетом сторонних организаций на 20 %
Ц2 - выполнение научно-исследовательских и опытно-конструкторских работ, проведение фундаментальных научных исследований	Ц21 - привлечение студентов и сотрудников университета к НИР Ц22 - стимулирование проведения НИР Ц23 - обеспечение необходимым оборудованием Ц24 - финансирование НИР Ц25 - сотрудничество с НИИ, КБ и сторонними организациями	Увеличение числа завоеванных грантов, проводимых научных хозяйственно-договорных тематик, внедренных результатов НИР, количества публикаций и участий в научных конференциях
Ц3 - эффективная организация деятельности университета	Ц31 - обеспечение университета необходимыми ресурсами и средствами Ц32 - совершенствование структуры управления университетом	Уменьшение затрат университета, управление и согласование обеспечивающей образовательный процесс деятельности
Ц4 - развитие социальной и материальной инфраструктуры университета	Ц41 - развитие жилищно-коммунального хозяйства Ц42 - рациональная организация труда и отдыха Ц43 - повышение благосостояния коллектива	Снижение текучести кадров на 15 %

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

Рисунок 1.2 - Дерево целей ВУЗа

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

Задача служб организации заключается в том, чтобы документы во время своего движения не терялись и вовремя поступали в очередные пункты обработки. Эта задача решается с помощью многолетним опытом выверенной и системы организации документооборота, которая изложена в нормативных документах [4].

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

1. Составляется служебная записка с просьбой изменить или дать новый номер телефона от подразделения.

2. Затем директор ОИЦ отдает распоряжение о покупке нового номера телефона.

3. После покупки номера отдел закупок извещает директора ОИЦ о наличии свободного номера.

4. Директор ОИЦ дает задание сотрудникам внести изменения в телефонном справочнике.

5. После внесения изменений отправляется отчет.

Все внутренние документы регистрируются, размножаются секретарем (или в канцелярии) и направляются в структурные подразделения для исполнения.

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

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

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

Таблица 1.5 - Схема документооборота учреждения

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

3. Прикладное программное обеспечение (офисные программы, коммуникационные программы, предметно-ориентированные программы).

Основными операционными системами на ПК является Linux и Windows Vista. На серверах чаще всего используются операционные системы Linux дистрибутивов Debian и Suse.

Таблица 1.6 - Технические характеристики ПК

Техническая характеристика или периферийное устройство	Условное обозначение
	ПК1	ПК2	ПК3	ПК4	ПК5	ПК6	ПК7
Частота, процессора, ГГц	1,5	2,5	2,5	2,5	2,5	2,5	2,5
Оперативная память, ГБ	512	2	2	2	2	2	2
Видеокарта	Nvidia	Nvidia	Nvidia	Nvidia	Nvidia	Nvidia	Nvidia
Жёсткий диск, ГБ	60	320	320	320	320	320	320
Монитор	17? LCD	17? LCD	17? LCD	17? LCD	20? LCD	20? LCD	20? LCD
Принтер	HP	HP	Canon	Parser	HP	HP	HP
Сканер				Canon	Canon

Для интерактивного сервиса был использован сервер компании IBM. Так же в учреждении используются сервера Sun и HP.

1.1.4 Анализ проблемных ситуаций и обоснование путей их решения

После изучения информационной подсистемы ВУЗа были выявленные следующие недостатки:

а) отсутствие удобного доступа к контактным данным сотрудников и подразделений ВУЗа;

б) отсутствие быстрого доступа к реквизитам ВУЗа.

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

1.2 Формулировка задач проектирования

1.2.1 Общие сведения

Полное наименование сервисов - "Телефонный справочник СевКавГТУ".

Наименование организации разработчика - ГОУ ВПО "Северо-Кавказский государственный технический университет", факультет информационных технологий и телекоммуникаций, кафедра прикладной информатики, студент группы ПИ-061 Сучков Роман Геннадьевич.

Наименование организации заказчика - ГОУ ВПО "Северо-Кавказский государственный технический университет".

Перечень документов, на основе которых создается система:

1) отчет о преддипломной практике студента группы ПИ-061 Сучкова Р. Г.;

2) информация, предоставленная руководителем практики;

3) договор на предоставление услуг связи.

Источники финансирования - заработная плата техника ОИЦ СевКавГТУ

Порядок оформления и предъявления заказчику результатов работ по созданию системы - интерактивного сервиса, реализованного в виде интернет-портала в электронном формате.

1.2.2 Назначение, цели создания интерактивных сервисов

Сервисы предназначены для:

1) получения телефонных номеров сотрудников ВУЗа;

2) получения телефонных номеров подразделений ВУЗа;

3) получение контактной информации ВУЗа;

4) интеграции с IP-телефонией ВУЗа;

5) формирования версии для печати.

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

1.2.3 Характеристика объекта автоматизации

Краткие сведения об объекте автоматизации - рабочее место сотрудника ОИЦ СевКавГТУ.

Условия эксплуатации - стандартные.

1.2.4 Требования к подсистеме

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

а) добавление новых объектов в базу данных (БД);

б) изменение характеристик объектов базы данных;

в) удаление объектов из базы данных;

г) информирование о появлении новых элементов и технологий.

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

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

1.2.5 Состав и содержание работ по созданию подсистемы

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

Запланирован следующий состав и содержание работ по созданию информационной подсистемы:

а) изучение предметной области - с 18 февраля по 8 марта 2011 г.;

б) кодирование - с 12 марта по 01 мая 2011 г.;

в) отладка и тестирование - с 01 по 15 мая 2011 г.;

г) сдача проектной документации - с 15 по 20 мая 2011 г.

Наиболее ответственной работой, выполняемой на этом этапе, являются "Кодирование и составление программной документации", в состав которой входят следующие компоненты:

а) описание программ;

б) спецификация программ;

в) тексты программ;

г) контрольные примеры;

д) инструкции для системного программиста, оператора и пользователя.

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

Технологическая документация разрабатывается в соответствии с требованиями ГОСТ 3.11.09 - 82 "Система технологической документации. Термины и определения основных понятий", и составляет содержание технологического обеспечения информационной системы.

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

1.2.6 Порядок контроля приемки подсистемы

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

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

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

1.2.7 Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу интерактивного сервиса в действие

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

а) MySql;

б) Python;

в) Django;

г) LightHttpd.

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

1.2.8 Требование к документированию

Разработчиком предоставляется:

1) Исходные коды программы;

2) Инструкция для обучения персонала в формате PDF.

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

Исходные коды разработанных интерактивных сервисов хранятся на локальном сетевом хранилище, доступ к которым осуществляется через систему контроля версий Mercurial. А так же на CD-ROM вместе с результатами тестирования и краткой инструкцией оператору по установке и работе с интерактивными сервисами.

1.2.9 Источники разработки

Источниками разработки являются:

1) материалы отчета по преддипломной практике студента группы ПИ-061 Сучкова Р. Г;

2) договор на предоставление услуг связи;

3) заказ на разработку.

Выводы

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

Анализ проблемных ситуаций выявил, что действующая на предприятии информационная система не эффективно работает. Для разрешения проблемной ситуации снижения трудозатрат сотрудников учреждения, занимающихся оформлением и ведением документации, связанной с телефонным справочником невозможно использовать готовый программный продукт, так как на рынке лицензионного программного обеспечения отсутствуют программы для решения необходимых задач. По этой причине требуется разработать интерактивные сервисы, позволяющие осуществлять доступ к телефонному справочнику ВУЗа. Были сформированы требования для реализации интерактивных сервисов. Интерактивный сервис осуществляет интеграцию с IP-телефонией.

2. РЕАЛИЗАЦИЯ ИНТЕРАКТИВНЫХ СЕРВИСОВ

2.1 Обоснование выбора среды реализации сервисов

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

Eclipse вместе с плагином PyDev. Основные преимущества среды Eclipse:

1) бесплатность;

2) легкость в установке и настройке;

3) поддержка большого числа языков программирования;

4) кроссплатформенность;

5) поддержка всех популярных систем контроля версий;

6) возможность установки дополнительных плагинов;

7) расширенная документация;

8) удобный графический интерфейс.

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

Проект был разработан на языке программирования Python с использования Web-фреймворка Django. Данный фреймверк является open-source продуктом и распространяется под лицензией BSD. Этот фреймверк был выбран из-за ряда причин:

а) модульная разработка;

б) использование объектно-реляционных проекций (Object-Relation Mapping, ORM);

в) гибкая система шаблонов;

г) кроссплатформенность;

д) приложение для административного интерфейса;

е) множество библиотек от сторонних разработчиков;

ж) быстрота разработки.

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

2.3 Концептуальное проектирование интерактивных сервисов

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

Таблица 2.1 - Названия и назначения страниц

Страница	Назначение
Главная	Содержит реквизиты университета и контактную информацию, а также меню навигации по сервисам
Руководство	Содержит контактную информацию руководства ВУЗа
Подразделения	Содержит контактную информацию о подразделениях ВУЗа и о его сотрудниках
Научные подразделения	Содержит контактную информацию о научных подразделениях ВУЗа и о его сотрудниках
Филиалы	Содержит контактную информацию о филиалах ВУЗа
Факультеты	Содержит контактную информацию факультетов ВУЗа. Включает в себя подраздел "Кафедры"
Инструкция по работе с внутренними телефонами	Содержит инструкции по работе с внутренними телефонами
Форма обратной связи	Служит для связи пользователей с администраторами сервиса

Kонцептуальная схема предоставлена на рисунке 2.1.



Рисунок 2.1 - Концептуальная схема интерактивных сервисов

2.4 Создание логической модели базы данных интерактивных сервисов

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

а) из каких отношений должна состоять база данных;

б) какие атрибуты должны быть у этих отношений;

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

Требования к выбранному набору отношений и составу их атрибутов должны удовлетворять следующим условиям:

а) отношения должны отличаться минимальной избыточностью атрибутов;

б) выбранные для отношения первичные ключи должны быть минимальными;

в) между атрибутами не должно быть нежелательных функциональных зависимостей.

2.3.1 Определение сущностей модели базы данных

Создание базы данных осуществлялось при помощи Web-фреймворка Django. Данный фреймворк при создании таблиц использует следующее правило: имя таблицы начинается с названия приложения, после идет нижнее подчёркивание и название таблицы (класса). В таблице 2.2 приведены все сущности, используемые в интерактивном сервисе.

Таблица 2.2 - Сущности базы данных

Сущность	Назначение
group	Информация о группах
group_permissions	Права групп
message	Сообщения пользователям
permission	Права доступа
user	Данные пользователей
user_groups	Группы пользователей
admin_log	Содержит историю действий пользователей
content_type	Хранит названия всех моделей
session	Хранит сессии
body	Содержит названия корпусов, их сокращения и описание
category	Содержит категории телефонных номеров
country	Содержит коды стран
department	Содержит информацию о подразделениях ВУЗа
page_text	Содержит текст отображаемый на информационных страницах Справочника
persone	Содержит информацию о работниках ВУЗа
phone	Содержит номера телефонов
prefix	Содержит префиксы телефонных номеров
tag	Содержит теги

2.3.2 Определение атрибутов сущностей базы данных интерактивного сервиса

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

Таблица 2.3 - Атрибуты сущностей базы данных

Сущность	Атрибут	Тип	Назначение
body	id	Целое число	Идентификатор
	title	Строка	Имя корпуса
	name_body	Строка	Короткое имя корпуса
	description	Строка	Описание
category	id	Целое число	Идентификатор
	name_category	Строка	Название категории
	description	Строка	Описание
	css_class	Строка	CSS класс категории
country	id	Целое число	Идентификатор
	country	Строка	Название страны
	code_country	Целое число	Код страны
	description	Строка	Описание
department	id	Целое число	Идентификатор
	name	Строка	Имя подразделения
	shortname	Строка	Короткое имя
	description	Строка	Описание
department	tag	Целое число	Код тега
	body	Целое число	Код корпуса
	town	Целое число	Код город
	room	Строка	Кабинет
	email	Строка	Email
page_text	id	Целое число	Идентификатор
	page	Строка	Страница
	title	Строка	Заголовок
	text	Строка	Текст страницы
	section	Строка	Раздел
persone	id	Целое число	Идентификатор
	first_name	Строка	Имя
	second_name	Строка	Фамилия
	last_name	Строка	Отчество
	post	Строка	Пост
	is_manager	Логический	Директор
	tag	Целое число	Код тега
	town	Целое число	Код города
	room	Строка	Кабинет
	email	Строка	Email
	body	Целое число	Корпус
phone	id	Целое число	Идентификатор
	category	Целое число	Категория
	prefix	Целое число	Префикс
	country	Целое число	Страна
	phone	Строка	Телефон
	description	Строка	Описание
	long_distance	Логический	Разрешить междугородние звонки
	view_phone	Логический	Показывать номер
	priority	Целое число	Приоритет
prefix	id	Целое число	Идентификатор
	region	Строка	Регион
	code_region	Целое число	Код региона
prefix	description	Строка	Описание
	town	Логический	Если город
tag	id	Целое число	Идентификатор
	tagname	Строка	Имя

2.3.3 Определение связей между сущностями базы данных интерактивного сервиса

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

Таблица 2.4 - Данные о взаимодействии сущностей базы данных

Зависимая сущность	Наследуемый (внешний) ключ	Независимая сущность	Тип связи	Кратность связи
Persone	tag	Tag	Неидентифицирущая	1:N
	town	Prefix	Аналогично	1:N
	body	Body	Аналогично	1:N
Department	tag	Tag	Аналогично	1:N
	town	Prefix	Аналогично	1:N
	body	Body	Аналогично	1:N
Phone	category	Category	Аналогично	1:N
	prefix	Prefix	Аналогично	1:N
	country	Country	Аналогично	1:N

2.3.4 Задание первичных ключей сущностей

Аппарат нормализации отношений обеспечивает удовлетворение следующих требований:

а) выбор отношений и атрибутов должен обеспечивать минимальное дублирование данных;

б) не должно быть трудностей при выполнении операций включения, удаления и модификации данных;

в) время выполнения запросов на выборку данных должно удовлетворять предъявляемым требованиям;

г) перестройка набора отношений при введении новых типов должна быть минимальной.

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

В таблице 2.5 приведены ключи для сущностей, имеющих типы ключей первичный и внешний. Сущности, не указанные в таблице, имеют тип ключа первичный с названием id.

Таблица 2.5 - Характеристика ключевых атрибутов сущностей

Таблица	Ключ	Тип ключа
group_permissions	id	первичный
	group_id	внешний
	permission_id	внешний
message	id	первичный
	user_id	внешний
permission	id	первичный
	content_type_id	внешний
user_groups	id	первичный
	user_id	внешний
	group_id	внешний
admin_log	id	первичный
	user_id	внешний
	content_type_id	внешний
department	id	первичный
	content_type_id	внешний
department	object_id	внешний
person	id	первичный
	content_type_id	внешний
	object_id	внешний
phone	id	первичный
	object_id	внешний
	category_id	внешний
	prefix_id	внешний
	country_id	внешний

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

2.3.5 Логическа модель данных

Логическая модель является основой для всех пользователей информационной системы. На рисунке 2.2 представлена логическая модель данных интерактивных сервисов.

2.4 Создание физической модели базы данных интерактивных сервисов

При использовании платформы Django для каждого приложения определяется своя собственная схема. В каталоге каждого приложения присутствует файл с именем models.py содержащий определения таблиц и столбцов, которые будут использоваться приложением. В Django, как и в других платформах разработки веб-приложений, опирающихся на использование объектно- реляционных проекций (Object-Relation Mapping, ORM), вполне возможно создавать и использовать базы данных, не написав ни одного SQL-выражения.

Механизм ORM платформы Django превращает классы в таблицы, а атрибуты классов в столбцы этих таблиц. Созданные классы необходимо насле довать от класса Model платформы Django. Это означает, что класс относится к типу Model и обладает соответствующим поведением.

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



Рисунок 2.2 - Логическая модель данных

2.4.1 Генерирование SQL-сценария создания базы данных информационной подсистемы средствами Django ORM

При необходимости можно увидеть сгенерированный код на языке SQL, который платформа использует для создания базы данных, для этого достаточно будет запустить в каталоге проекта команду python manage.py sql appname, где аргумент appname соответствует имени приложения. Сгенерированный код в приложении А.

2.5 Создание проекта и модулей

Проект в django может быть самостоятельным приложением, но в большой степени это просто структура директорий и настройки общие для всех приложений внутри. А приложение - это как раз код, который выполняется. Ждя создания приложения используется команда django-admin.py startproject project. Другой вариант создание проекта Django с помощью среды Eclipse.

Создать приложение можно с помощью команды: python manage.py startapp newapp.

Создаётся структура указанная на рисунке 2.3.

Рисунок 2.3 - Структура созданного проекта

Создаётся структура указанная на рисунке 2.4.

Перед запуском надо записать изменения в базу данных (если она используется): python manage.py syncdb

Рисунок 2.4 - Структура созданного приложения

Запустить тестовый сервер можно с помощью команды: python manage.py runserver.

2.6 Реализация интерактивных сервисов

Архитектура разработанного сервиса похожа на "Модель-Вид-Контроллер" (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Вид, а презентационная логика Вида реализуется в Django уровнем Шаблонов . Из-за этого уровневую архитектуру Django часто называют "Модель-Шаблон-Вид" (MTV).

2.6.1 Разработка интерфейса сервисов

Разработанные сервисы построены на основе архитектуры клиент-сервер. Клиентом зачастую выступает браузер отображающий данные сгенерированные сервером. Данные отдаются сервером как html-страница с подключенными к ней каскадными таблицами стилей (css). HTML - стандартный язык разметки документов во Всемирной паутине. Большинство Web-страниц создаются при помощи языка HTML (или XHTML). При генерации html-страницы Django использует систему шаблонов. Шаблон Django - это строка текста, которая предназначена для разделения представления документа от его данных. Шаблон определяет места подстановки и различные виды основной логики, которая управляет отображением документа. Обычно, шаблоны используются для создания HTML, но шаблоны Django также способны участвовать в генерации любого текстового формата. На рисунке указан пример сгенерированной страницы.

2.6.2 Создание модели данных

При использовании платформы Django для каждого приложения определяется своя собственная схема. В каталоге каждого приложения присутствует файл с именем models.py содержащий определения таблиц и столбцов, которые будут использоваться приложением. В Django, как и в других платформах разработки веб-приложений, опирающихся на использование объектно-реляционных проекций (Object-Relation Mapping, ORM), вполне возможно создавать и использовать базы данных, не написав ни одного SQL-выражения. Механизм ORM платформы Django превращает классы в таблицы, а атрибуты классов в столбцы этих таблиц. Созданные классы необходимо наследовать от класса Model платформы Django.

Код скрипта отвечающий за создание сущности country:

class Country( models.Model ):

country = models.CharField( max_length=100, null=False, blank=False)

code_country = models.CharField(max_length=3, null=False, blank=False)

description = models.TextField(blank=True, null=False)

class Meta:

verbose_name = _(u'Страна')

verbose_name_plural = _(u'Cтраны')

def __unicode__(self):

return self.country

Данный скрипт указывает Django, что необходимо создать сущность country с атрибутами id, country, code_country, description . Класс Meta содержит настройки сортировки данных таблицы. SQL-запрос для данного класса генереруется автоматически и выглядит следующим образом:

Рисунок 2.5 - Главная страница

CREATE TABLE `phonesdb_country` (

`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,

`country` varchar(100) NOT NULL,

`code_country` varchar(3) NOT NULL,

`description` longtext NOT NULL

);

Для просмотра всех SQL-запросы, которые генерирует Django ORM существует команда python manage.py sqlall appname, где appname - имя приложения.

2.6.3 Создание представлений и привязок URL

Для генерации страниц Django использует представления( views ). Представление является функцией, которая в качестве первого параметра принимает переменную содержащую объект запроса, обычно переменная называется request и возвращает ответ(response). В теле представления происходит обращение к базе данных, генерация страницы из шаблонов и возвращение ответа клиенту. Типичная функция представления:

def main_page( request ):

main_page_obj = Page_text.objects.get(page="main")

title = main_page_obj.title

content_title = title

content = main_page_obj.text

context = { "title" : title,

"content_title": content_title,

"content" : content,

"ip":request.META['REMOTE_ADDR']

}

template_path = "pages.html"

return render_to_response( template_path, context,

context_instance=RequestContext(request) )

Для привязки функции представления к конкретному URL в Django используются файлы привязки URL. Файл привязки URL можно рассматривать как таблицу с содержанием сайта. Этот файл определяет соответствие между URL и функциями представления, которые должны быть вызваны для этих URL.

Файл urls.py:

from django.conf.urls.defaults import *

urlpatterns = patterns('',

(r'^$', views.main_page ),

)

(r'^$', views.main_page) - это обычный кортеж языка Python, в котором первый элемент является шаблоном регулярного выражения, а второй элемент -- функция представления, которая должна использоваться при совпадении данного шаблона.

Регулярные выражения - компактный метод определения шаблонов в тексте.

2.6.4 Реализация формы обратной связи

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

Библиотека Django Forms включена в состав фреймворка Django. Она использует конфигурацию моделей базы данных и формирует из них HTML формы. Также она содержит серверную функциональность для проверки допустимости введенных значений и помещения этих данных в базу данный. Работая с этой библиотекой, вы можете простым способом интегрировать модели данных в страницы сайта и использовать их для добавления информации в базу данных. После того, как данные будут помещены в базу данных, можно как обычно осуществлять к ним запросы, сформированные на языке SQL или при помощи Django ORM.

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

Форма обратной связи указана на рисунке 2.7

Листинг скрипта формы обратной связи:

class ContactForm(forms.Form):

author = forms.CharField(required=True, label=_(u'Ваше имя'), max_length=30)

email = forms.EmailField(required=False, label=_(u'Эл. почта'))

topic = forms.CharField(required=True, label=_(u'Тема'), max_length=30)

text = forms.CharField(required=True, max_length=400, widget=forms.Textarea(), label=_(u'Текст сообщения'))

2.6.5 Реализация формы поиска

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

Рисунок 2.6 - Форма поиска

Данные насервер отправляются методом POST. Это нужно в случае, если запрос пришёл из плагина. Присланный запрос обрабатывается и ищется на соответствие в базе данных. При успешном поиске результат отдается клиенту. Результат поиска по запросу "ОИЦ" показан на рисунке.

Рисунок 2.7 - Форма обратной связи

Рисунок 2.8 - Результат поиска по запросу "ОИЦ"



Рисунок 2.9 - Проверка орфографии

2.6.6 Пользовательская проверка орфографии в сервисе

Любой пользователь, увидев опечатку на сайте, может сообщить о ней администраторам сервиса, выделив её и нажав сочетание клавиш "Ctrl + Enter". После чего появится окно проверки орфографии (рисунок 2.9).

Форма содержит в себе поле, содержащее контекст ошибки, и поле для комментария.

2.6.7 Настройка Web-сервера lighthttpd

Lighttpd - Web-сервер, разрабатываемый с расчётом на быстроту и защищённость, а также соответствие стандартам. Это свободное программное обеспечение, распространяемое по лицензии BSD. lighttpd работает в Linux и других Unix-подобных операционных системах, а также в Microsoft Windows. Django взаимудействует с сервером через fastcgi протокол. Конфигурирация /etc/lighttpd/lighttpd.conf:

# lighttpd configuration file

server.modules= (

"mod_fastcgi",

)

server.document-root = "/var/www/lighttpd"

fastcgi.server = ( "/spravka.fcgi" =>

( "main" =>

(

"socket" => "/tmp/spravka.sock", "check-local" => "disable",

)

)

)

url.rewrite-once = (

"^(/media.*)$" => "$1",

"^/favicon\.ico$" => "/media/favicon.ico",

"^(/.*)$" => "/spravka.fcgi$1",

)

Выводы

Для реализации сервиса был выбран объектно-ориентированный Web-фреймвёрк Django. Django написан на языке программирования Python, что позволяет использовать все возможности этого языка при написании дипломного проекта.

Python - динамически развиваемый язык программирования. Существует множество дополнительных библиотек, благодаря которым разработка приложений значительно упрощается. Утилита Python Setup Tools позволяет устанавливать дополнительные библиотеки автоматически. Это позволяет программисту больше времени быть сконцентрированным на разработке приложений, вместо того, чтобы тратить его на ручную установку.

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

3. ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

3.1 Общие сведения об интерактивных сервисах доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

Интерактивные сервисы доступа к телефонному справочнику СевКавГТУ, г. Ставрополь имеют архитектуру клиент - сервер. Функционирование сервисов достигается благодаря следующему программному обеспечению:

1) операционная система Linux;

2) Web-сервер lighthttpd;

3) язык программирования Python;

4) фреймворк Django;

5) СУБД MySQL.

Клиентом интерактивных сервисов является любой web-браузер.

3.2 Функциональное назначение интерактивных сервисов доступа к телефонному справочнику СевКавГТУ г. Ставрополь

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

Таблица 3.1 - Функциональное назначение интерактивных сервисов

Наименование сведений	Содержание сведений
Назначение интерактивных сервисов	Обеспечение простого и удобного доступа к расписанию СевКавГТУ, г. Ставрополь для широкого круга пользователей
Цель создания интерактивных сервисов	Сокращение временных на доступ к контактным данным сотрудников и подразделений ВУЗа, а также к реквизитам университета
Функциональные ограничения на применение	Наличие на компьютере пользователя установленного web-браузера

3.3 Описание логической структуры интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

Логическую структуру интерактивных сервисов иллюстрирует диаграмма компонентов (рисунок 3.1).

Рисунок 3.1 - Диаграмма компонентов интерактивных сервисов доступа к телефонному справочнику СевКавГТУ, г. Ставрополь

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

3.4 Требование к техническому обеспечению

3.4.1 Общие требования

Интерактивные сервисы выполнены в виде web-приложения. Для работы сервисов на стороне клиента необходим установленный web-браузер и выхода в сеть ВУЗа.

Для работы сервисов на сервере необходимо установить:

1) операционную систему Linux или Windows;

2) систему управления базой данных MySQL;

3) язык программирования Python;

4) Web-фреймворк Django.

3.4.2 Требования к центральному процессору

В результате контрольных прогонов для работы с интерактивными сервисами достаточно сервера с тактовой частотой центрального процессор 100 МГц. Обоснование: при более низкой тактовой чистоте центрального процессора быcтродействие интерактивных сервисов является неудовлетворительным, например, время выполнения генерация версии для печати в формате pdf увеличивается до одного часа.