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

• ВВЕДЕНИЕ
• 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. Почтовый адрес: Россия, 355 029, г. Ставрополь, проспект Кулакова, дом 2.

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

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

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

Рисунок 1.1 — Схема организационной структуры ВУЗа Конкретная функциональная структура управления определяется в зависимости от сочетания двух основных типов руководства — линейного (ректор, проректора) и функционального (специализация глав отделов).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для интерактивного сервиса был использован сервер компании 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 — Сущности базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 — Функциональное назначение интерактивных сервисов

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 увеличивается до одного часа.