Індивідуального завдання (стр. 1 из 4)
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ РАДІОЕЛЕКТРОНІКИ
Голодницький І.Є/б
87548, м.Маріуполь, пр.. Будівельників 107-66
ЗВІТ
З ПЕРЕДДИПЛОМНОЇ ПРАКТИКИ
м. Київ «(ЧП Рябець-Голодницька)»
у період з "3" 03 по "31" 03 2009 р.
Тема індивідуального завдання:
Програмна реалізація системи реєстрації звернень
громадян та відповідей посадових осіб
| Студ. ПЗАСз-03-4 Голодницький І.Є ____ _____ | Керівник практики стар.преп Харченко. С.Л. Робота захищена з оцінкою_ "___ "_____ |
Харків 2009
РЕФЕРАТ
Звіт з переддипломної практики містить 23 сторінок,29 рисунков.
Об’єктом формалізації є існуючі сервіси звернення громадян
Мета роботы – зробити автоматизацію системи звернення громадян і відповідей посадових осіб .
Метод розробки – розробка ведеться у сучасній середовищі розробки, яка дозволяє Intellisense, Refactoring, автоматичну генерацію UML структурних діаграмм.
Результатом э працююча в Інтернет веб-система, яка дає можливість оцінить якість роботи посадових осіб.
СОДЕРЖАНИЕ
1.2 Слой доступа к базе данных. 7
1.2.1 Особенности внедрения. 7
1.2.3 Авто заполнение сервисных колонок. 9
ПОСТАНОВКА ЗАДАЧИ
Исходя из анализа конкурентных систем в социальной области и веб-технологий, требуется выполнить формулировку решаемых задач на основании, ниже перечисленных требований:
а) Система должна быть готова к большим нагрузкам.
б) Обеспечивать широкую формализацию объектов, таким образом, чтобы производить поиск и улучшать seo системы, засчёт собирательных страниц со ссылками, для города, специалистов, профайлов и прочих параметров. Использовать url, содержащие в названии транслитные названия компаний и имён профайлов.
в) Сделать как можно более лёгкий интерфейс, с минимальным количеством действий выполняемых через Post. Редактировать, сохранять, удалять через ajax запросы.
г) Валидацию производить через ajax запросы. Выводя результаты, в списке проблемных вариантов, подсвечивая не прошедшие валидацию.
д) Параметры элементов при добавлении или поиске, выводить исходя из подхода, что если он списочный (выбираемый из группы вариантов), то в случае если вариантов меньше 30, показывать его select-списком, если же больше пользоваться autocomplete полем, с вспомогательным описанием возможных вариантов. Если же может существовать понятие короткого частого списка, показывать его в виде select, и в случае выбора пункта «Другие», показывать autocomplete поле.
е) Поиск должен позволять использовать каждый из параметров элементов. Использовать подход как в параметрах, только при каждом выборе сокращать количество возможных вариантов поиска, чтобы можно было видеть количество новых вариантов, исходя из выбранных. И имея возможность отменить любой из выборов.
ж) Производить широкую персонализацию исходя из локализованных данных по IP, или дополненных пользователем. Поощрять заполнение дополнительных параметров, но производя это редко, не нагружая пользователя этим занятием. Использовать возможности openid и подгружать специфическую информацию также оттуда.
з) Позволять добавлять жалобу с главной страницы, даже при несуществующем объекте жалобы, добавляя его по потребности через Popup.
Выполнить поэтапную реализацию задач с учётом вышеизложенных пунктов.
ВВЕДЕНИЕ
Демократию часто понимают, лишь как возможность выбирать, и это правда, но у неё есть и другие проявления. Например, как возможность корректирования системы через обращения. Текущая система жалоб подразумевает личное общение жалобщика с нарушающим права должностным лицом через почтовую переписку. Почтовая переписка, как известно медленный, ненадёжный и главное не публичный механизм. Это приводит к неэффективности системы, из-за её характера.
Поэтому, есть необходимость в создании системы, позволяющей пользователю товаров и услуг или любому гражданину Украины, перед вхождением в какие либо договорные отношения, иметь возможность проверить должностное лицо с точки зрения жалоб и отзывов. А должностное лицо, в свою очередь, имело бы возможность объяснить свои действия перед общественностью.
Несмотря на то, что уже сейчас предпринимаются попытки государства внедрить разрозненные элементы автоматизации в сферу контроля за соблюдением гражданских прав и обязанностей, данные попытки не приводят к успешным результатам. В Киеве, в центре города установлены информационные системы, которые кроме рекламы исторических мест города, и прочей информации для туристов обладает возможностью отсылки жалоб меру города. Однако, ни ответа от должностного лица, ни публикации в информационных системах, не предусмотрено.
Поэтому возникла потребность в создании системы автоматизации учёта обращений граждан и реакции должностных лиц. Система должна обеспечивать, документирование, юридическую поддержку, оценку выполняемых ответных действий, статистика жалоб на всевозможных должностных лиц и организаций.
1 МОДЕЛИ И АЛГОРИТМЫ
1.1 База данных
1.1.1 Архитектура
Архитектура базы данных, решает несколько основополагающих задач. Во-первых, это простой перенос. Рассмотрим несколько сценариев. Предположим, существует команда разработчиков с локальными базами данных, сервер для тестов новой функциональности и реальный сервер.
В данном случае, часто требуется многоразово переносить изменения и данные. И если изменения схемы можно прописывать как скрипты, или использовать миграционные вспомогательные утилиты, то данные переносить таким способом не так просто, особенно в случае использование числовых первичных ключей. Также это касается целостности данных, тобиш проблемы связанные с внешними ключами. Последовательные числовые ключи могут повторяться как у разработчиков и тестеров, так и на тестовом сервере. Что приводит к путанице и возможным сложно отлавливаемым проблемам связей. Конечно, можно использовать псевдослучайные числа, однако это приводит к ещё большим неожиданностям. Поэтому в случае использования числовых первичных ключей, приходиться производить перегенерирование ключей в каждой новой базе, что также приводит к сложностям выстраивания внешних ключей во внешние базы, как в случаях кластерных систем или просто вспомогательных баз.
В уникальных идентификаторах есть и другие преимущество, например их можно генерировать не из базы. Суть в том, что при использовании числовых идентификаторов, сгенерировать их может часто только сама база, следовательно, она должна возвращать идентификатор отдельным запросом, а это не очень удобно, если есть желание использовать возможности блоковой вставки.
Уникальные идентификаторы позволяют делать объединения нескольких таблиц, не указывая дополнительных параметров. Затем с объединением или отдельными таблицами можно производить join, что раскрывает широкие возможности при архитектировании систем. Может быть несколько таблиц, похожего типа и другая таблица, содержащая связи на любые из группы таблиц. Так можно создавать, например отдельную аудитную таблицу, ссылающуюся на любую другую. Данный подход является не плохим примером масштабирования или слабого связывания компонентов.
Пример с реализацией аудитных полей универсален, однако часто не удовлетворяет условиям производительности. Поэтому от ситуации аудитные поля устанавливаются внутри таблиц. Обычно их 2 поля для создания и 2 поля для изменения, указывающие на пользователя и время действия.
Также сервисными полями выступает IsDeleted. Этот подход позволяет виртуально удалять и восстанавливать объекты базы. Иногда существует поле IsModerated, указывающее на некое разрешение на показ объекта.
UrlName также используется повсеместно в системе. Это поле некоторым образом должно быть связано с названием данного элемента, обычно трансформация производиться функцией специального транслита. Главное что символы не должны противоречить спецификации символов, описывающего форму url. [24]. В дальнейшем это поле используется как уникальный идентификатор, повышающий SEO системы [23].
1.1.2 Модель
Корень системы, создаваемый для первой версии, есть область жалоб, и описание структур на которых производят жалобы – жалобные элементы.
Основными жалобными элементами выступают компании и люди. В будущем идёт расчёт на расширение жалобных элементов также до продуктов и групп компаний.
Рисунок 2.1 – Таблица компании и персоны
Как видно информационная часть состоит в основном из наименований. Остальные же параметры, которые являются фильтрами, соотносятся как многие-ко-многим.
Рисунок 2.2 – Связанные фильтры к компании
Как видно, каждая компания в системе позволяет указывать несколько типов компаний, например: клиника, сан. эпидем, ветеринарная, диспансер. Большая коммерческая организация может представлена быть в нескольких городах. И к каждой компании привязываются сотрудники.