Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Сетевая технология публикации и обработки данных в муниципальном учреждении Д/С №176

Сетевая технология публикации и обработки данных в муниципальном учреждении Д/С №176

Анализ существующих технологий создания web-приложений. Разработка сетевой технологии публикации и обработки информации о детях в детском саде №176 "Белочка" с помощью JSP-страниц и сервлетов с использованием JDBC-драйвера для доступа к базе данных.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 18.12.2011
Размер файла 3,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

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

Министерство образования РФ

Самарский государственный аэрокосмический университет

им. С.П. Королева

Тольяттинский филиал

Кафедра радиоэлектроники и системотехники.

Сетевая технология публикации и обработки данных в муниципальном учреждении Д/С №176

Пояснительная записка к курсовому проекту по курсу «Сети ЭВМ и телекоммуникаций»

Тольятти 2011

Реферат

WEB-ПРИЛОЖЕНИЕ, SQL-СЕРВЕР, МНОГОЗВЕННАЯ АРХИТЕКТУРА, ТЕХНОЛОГИЯ, HTML-СТРАНИЦА, СЕРВЛЕТ, КОНТЕЙНЕР СЕРВЛЕТОВ, JSP-СТРАНИЦА, JDBC-ДРАЙВЕР, СЕРВЕР ПРИЛОЖЕНИЙ, WEB-СЕРВЕР, ИНТЕРФЕЙС.

Объектом исследования является муниципальное учреждение детского воспитания Д/С №176 «Белочка».

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

В процессе работы будет создано web-приложение, доступное разработаны основные интерфейсные формы.

Введение

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

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

Новизна заключается в том, что данная технология еще не использовалась в рамках рассматриваемой организации «ЛАДА», в частности у дет/сада №176.

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

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

1) Изучить ведущие web-технологии на сегодняшний день;

2) Провести проектирование разрабатываемого ПП для Заказчика;

3) Определить основной функционал разрабатываемого ПП;

4) Разработать технологию в соответствии с определенными к нему требованиям;

5) Провести анализ полученного результата;

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

1. Анализ поставленной задачи и постановка задачи на проектирование

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

1.1 Анализ существующей технологии обработки информации

Учреждение Д/С №176 «Белочка», именуемом далее как Заказчик, является одним из представителей организации «ЛАДА», занимающейся образовательным воспитанием детей дошкольного возраста в Самарской области.

Рассмотрим структурную схему рассматриваемой организации, отраженную на рисунке 1.

Рисунок 1- организационно-структурная схема организации ОАО «ЛАДА»

В ходе исследования организационной деятельности предприятия были выявлены следующие механизмы работы с данными информационной системы:

1) Имеется БД по всем структурным единицам организации (детским садам) на главном сервере. У Заказчика отсутствует онлайн режим по работе с БД, так как обслуживание детского сада в вопросах, связанных с ЭВМ (обслуживание, работа с потоками информации) осуществляется отдельной структурной единицей - IT-поддержкой;

2) Для получения информации (например, по ребенку) необходимо делать запрос в соответствующий IT-отдел, отвечающий за работу с БД;

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

4) Ввод локальной информации происходит вручную.

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

Рисунок 2 - жизненный цикл запроса в действующей ИС

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

Преимуществами данного подхода являются:

1) Высокий уровень дифференциации обязанностей;

2) Заказчик не участвует в процессе генерации необходимой информации, а только предъявляет параметры запроса;

Но кроме положительных моментов сразу можно отметить и недостатки использования данного подхода:

1) Данный ЖЦ запроса приводит к увеличению времени предоставления информации требующему лицу. Это время включает в себя не только оборот запроса внутри предприятия; большая часть этого времени состоит из формирования отчета на стороне IT-поддержке;

2) Из первого недостатка вытекает и следующий: в связи с большим временем отклика на сформированный запрос падает актуальность требуемой информации (а порой эта информация требуется немедленно);

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

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

Рисунок 3- процесс локального обновления информации

В большинстве случаев именно этот механизм используется на предприятии, поскольку получение требуемой информации ведется за более быстрый период, ее актуальность сохраняется. Кроме того, чаще всего к числу требуемой информации относятся общераспространенные данные (ФИО, адрес, телефон), которые в полной мере описаны в рамках локального репозитория. Опишем ЖЦ запроса при использовании локального подхода:

Рисунок 4- жизненный цикл запроса в локальной системе обработки данных

Положительными моментами такой организации работы являются:

1) Малое время ожидания получения конечного ответа на запрос работника;

2) Сохранение актуальности полученных данных.

Результатом данной организации обработки данных являются следующие недостатки:

1) Бумажное ведение локальной информации также ведет к увеличению времени ее получения;

2) Оформление имеющихся данных происходит ручным способом, соответственно велика вероятность человеческого фактора - ошибка при заполнении, неразборчивость почерка и т. д.;

3) Бумажное хранение информации весьма небезопасно - любая ЧС (пожар) может привести к необратимой потере всей информации, т. к. не имеется ее копии.

4) Для централизованного хранения всего объема информации в рамках Заказчика выделяется специальное место, что также делает очень уязвимым хранение… Кроме того, данное место можно было бы использовать более рационально;

5) Ограниченность информации - при переводе ребенка в другую структурную единицу «ЛАДА» необходимо:

а) Найти локальную информацию о ребенке;

б) Передать в соответствующий дет/сад;

в) Согласовать изменение данных с центральным сервером;

г) Удалить эту информацию из местного локального хранения.

Это приводит к затруднениям при переводе ребенка в другую структурную единицу, например, при переезде на другое место жительство;

6) В связи с тем, что работу с репозиторием ведет один человек, то в случае его увольнения время на получение нужной информации резко возрастет, так как новому лицу потребуется много больший период на ее поиск;

7) Недостаточная полнота хранимых данных в отличии от центрального репозитория.

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

Существует два основных подхода для получения этой информации:

1) Создание специализированного запроса в IT-отдел по обработке и выдаче информации.

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

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

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

1.2 Разработка новой технологии обработки информации

1.2.1 Выбор методологии проектирования

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

Для описания функционирования разрабатываемой мною технологии будет выбрана методология DFD, основанная на графическом представлении систем. Она является одной из составляющих более общей IDEF методологии. DFD - диаграмма потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Другой составляющей является IDEF0 и IDEF3 методологии. Они являются методологиями функционального моделирования и графической нотации, предназначенной для формализации и описания бизнес-процессов. Поэтому данные методология не позволит нам описать функциональную часть системы.

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

1.2.2 Описание текущей модели обработки информации

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

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

Модель призвана ответить на следующий ряд вопросов:

- Что необходимо для выполнения отчетности сотрудником дет/сада?

- Какие необходимы первоначальные данные?

- Как осуществляется метод доступа к требуемым данным?

- Как происходит документооборот при данном процессе?

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

Рассматриваемая модель создается из списка позиций:

- Заведующая дет/садом;

- Мед/персонал;

- Работник по кадрам;

- Родители;

- Воспитатели.

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

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

Рисунок 5 - описание цели и точки зрения модели

Следующим шагом является определение основных функций системы, а так же описание основных входных данных системы:

- Данные по детям;

- Данные по кадрам;

- Мед/информация;

- Стандарт и тип отчета.

Функциями системы являются:

- Ввод информации в центральную БД;

- Актуализация данных БД;

- Доступ к информации в БД;

- Оформление отчетности.

Отразим эти параметры на рисунке 6.

Рисунок 6 - определение функций модели

После определения основных понятий можно переходить к непосредственной контекстной модели. Для этого сначала опишем уровень А-0, где определяются основные процессы, подсистемы ИС, управляющие элементы, а также входные и выходные элементы.

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

Рисунок 7 - описание работы текущей технологии обработки информации

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

Для нормального функционирования системы обработки информации в текущей системе используются следующие этапы:

- Занесение новых входных данных бумажном виде;

- Актуализация имеющихся данных отдельным работником;

- Создание отчетов на основе имеющихся данных по категориям: «Отчетность по ребенку», «Отчетность по кадрам»; «История болезней»;

- Выполнение дополнительных видов отчетности по требованию.

Отразим данный подход в модели А0 на рисунке 8.

Рисунок 8 - декомпозиция текущего процесса обработки информации

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

Исходя из описанных проблем, определим последовательность действий, выполняемых сотрудником для внесения изменений в базе данных. Эту последовательность отразим на рисунке 9, получив следующий тип модели А2.

Рисунок 9 - декомпозиция этапа актуализации данных в текущей системе

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

- Заведующая дет/садом;

- Работник по кадрам;

- Мед/персонал;

- Ответственное лицо по актуализации данных.

Подведем итог, описав полный функционал текущей системы и выделив его отрицательные стороны:

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

- Хранение БД в бумажном виде приводит к большим временным затратам на поиск необходимой информации, что снижает актуальность информации до момента ее получения;

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

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

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

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

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

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

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

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

Рисунок 10 - описание работы разрабатываемой ИС обработки информации

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

- Ввод новой информации в реляционную БД;

- Актуализация существующих данных БД;

- Работа с БД и получение разного рода информации;

- Подготовка отчетности.

Исходя из этой декомпозиции, отразим основной этап функционирования системы на рисунке 11.

Рисунок 11 - декомпозиция процесса ведения отчетности дет/сада

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

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

Для начала рассмотрим этап занесения данных в БД. Сотрудник, получая новую информацию, соответствующую его области ответственности, получает доступ к БД с помощью средств доступа и взаимодействия с БД. После соединения с центральным хранилищем происходит непосредственный ввод информации с помощью пользовательского интерфейса. Отразим данные операции на рисунке 12.

Рисунок 12 - декомпозиция этапа занесения данных в БД

Описанную выше декомпозицию процесса ввода данных отразим на рисунке 13.

Рисунок 13 - элементарные операции работника на этапе занесения данных

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

Данную декомпозицию отразим на рисунке 14.

Рисунок 14 - декомпозиция этапа работы с БД конечного пользователя

Вышеописанную декомпозицию процесса доступа к БД опишем на рисунке 15.

Рисунок 15 - элементарные операции работника на этапе доступа к БД

Наконец, последним рассматриваемым этапом является актуализация БД. На данном этапе, в отличии от текущей технологии, актуализация осуществляется не отдельным лицом, а ответственным в своей области человеком (заведующая, мед/персонал, работник по кадрам). Данное лицо, получив новую информацию об уже описанном объекте в БД, с помощью специальных средств проверяет новизну вводимых данных. Если полученная информация действительно является актуальной, то происходит ее корректировка, после доступа работника к пользовательскому интерфейсу. Опишем данный этап на рисунке 16.

Рисунок 16 - декомпозиция этапа актуализации данных в центральной БД

Результирующий отчет должен содержать следующую информацию:

- ФИО человека, сгенерировавшего запрос;

- ФИО человека, обработавшего запрос;

- Время получение информации из БД (с целью анализа и последующего улучшения метода доступа к БД);

- Непосредственно сами запрашиваемые данные.

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

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

2) Вероятность искажения данных в результате человеческого фактора уменьшится в несколько раз, а значит, достоверность информации повысится;

3) Доступ к информации будет доступен не только локально, а так же посредством сети Интернет путем публикации этих данных через web-интерфейс (после аутенфикации и идентификации) при соответствующем запросе.

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

5) Мобильность системы позволит не только быстро и легко заменять компоненты всей системы (СУБД, контейнеры сервлетов), но и переносить ее на разные платформы, что расширит круг возможного применения.

6) Этап актуализации будет выполняться не отдельным лицом, а непосредственно ответственным по категориям:

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

- Кадровый работник - ведет отчетность по сотрудникам текущего предприятия.

- Мед/персонал - занимается описанием мед/обследований ребенка, его состояние здоровья, историю болезней и т. д.

7) Хранения данных в электронном виде позволит значительно расширить список хранимых атрибутов объектов по сравнению с бумажным. Кроме того, станет возможным избежать повторяемости данных в одной таблице. Наконец, станет незатруднительным хранение данных указанный период после ухода ребенка в общей БД.

Итак, в данной главе были описаны основные направления, по которым будет вестись работа. Но для начала необходимо определиться с выбором архитектуры технологии и используемого ПО.

Необходимо реализовать следующие программные модули в разрабатываемой технологии:

- Модуль ввода данных в БД;

- Модуль резервирования текущей БД;

- Модуль редактирования данных;

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

1.3 Выбор и разработка архитектуры сетевой технологии

В источнике http://www.intuit.ru/department/database/databases/ в полной мере все основные существующие на сегодняшний день виды архитектур.

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

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

Архитектуру разрабатываемой технологии опишем на рисунке 17.

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

Архитектуру разрабатываемой технологии опишем на рисунке 17.

Рисунок 17 - представление многоуровневой архитектуры клиент-сервер

Как видно из рисунка 17, система предусматривает использование доступа к реляционной БД 3 пользователей в рамках одного детского сада:

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

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

- Работник по кадрам несет ответственность за актуализацию и своевременное изменение существующей информации по кадрам, работающим в детском саду №176. Поэтому он должен иметь доступ к внесению/изменению данных в реляционной БД.

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

Плюсами данной архитектуры являются:

- клиентское ПО не нуждается в администрировании;

- масштабируемость;

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

- высокая безопасность;

- высокая надежность;

- низкие требования к скорости канала (сети) между терминалами и сервером приложений;

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

К недостаткам многозвенной сетевой архитектуры относят следующие показатели:

- растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание;

- более высокая сложность создания приложений;

- сложнее в разворачивании и администрировании;

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

- высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

1.4 Выбор технологии и программного обеспечения для реализации новой сетевой технологии

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

1.4.1 Выбор технологии создания web-приложения

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

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

1) PHP - Personal Home Page tools

2) Java Servlets

3) JSP - Java Server Pages

4) JSF - Java Server Faces

5) ASP.NET - Active Server Pages

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

Таблица 1 - критическая оценка технологий разработки web-приложений

Критерий оценки

PHP

Java Servlet

JSP

JSF

ASP.NET

Кроссплатформенность

8

10

10

10

7

Возможности масштабируемости приложения

4

10

10

9

10

Простота в использовании

10

5

8

7

8

Наличие бесплатных библиотек

10

9

10

8

8

Производительность

6

10

8

9

10

Распространенность в использовании

8

10

8

5

8

ИТОГО

46

55

55

48

51

В ходе анализа были выбраны две технологии, набравшие наибольшие показатели:

1) Java Servlets

2) Java Server Pages

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

1.4.2 Выбор сервера базы данных

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

На основе анализа современных БД выбор будет осуществлен между следующими серверами:

1) FireBird;

2) MySQL;

3) Oracle;

4) MS SQL;

5) PostgreSQL.

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

Таблица 2 - критическая оценка серверов БД

Критерий оценки

FireBird

MySQL

Oracle Database 10g

MS SQL

PostgreSQL

Поддержка обслуживания большого числа пользователей (до тысячи)

8

10

10

10

8

Бесплатное распространение

10

10

0

0

10

Многоплатформенность

10

10

10

0

10

Защита от несанкционированного доступа

8

5

10

7

8

Возможности БД (view, procedure, backup)

6

10

10

10

6

Унификация используемого SQL-языка

10

9

10

10

8

Простота настройки, администрирования, отсутствие требования наличия специально обученного персонала

8

10

2

5

8

Перспективы развития БД, выпуск новых релизов, стабильность фирмы производителя

8

10

10

10

8

ИТОГО

68

74

62

52

66

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

1.4.3 Выбор метода доступа к базе данных

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

JDBC - платформенно-независимый стандарт взаимодействия Java приложений с различными СУБД. Данный стандарт позволяет создать соединение с БД по специально описанному URL. Данный драйвер загружается динамически во время работы программы. Кроме того, при использовании JDBC увеличивается переносимость приложения, так как не требуется регистрация драйвера, а так же запрос к БД осуществляется непосредственно в коде JAVA (в котором описывается SQL-запрос для отправки), что существенно увеличивает быстродействие обмена данными с центральным хранилищем.

1.4.4 Выбор сервера приложений

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

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

1) GlassFish;

2) JBoss;

3) WebLogic;

4) WebSphere.

Для оценки выбранных серверов проведем оценку по критериям, которую сведем в таблицу 3. Используемая 10-бальная шкала показывает, что наилучшее соответствие выбранному критерию описывается присвоение серверу 10 баллов.

Таблица 3 - критическая оценка серверов приложений

Критерий оценки

GlassFish

JBoss

WebLogic

WebSphere

Многоплатформенность

10

10

9

7

Бесплатное распространение

10

10

2

4

Перспективы развития БД, выпуск новых релизов, стабильность фирмы производителя

10

8

10

8

Поддержка обслуживания большого числа пользователей (до тысячи)

7

9

10

10

Независимость от параметров ЭВМ (RAM, многопроцессорность)

9

10

5

8

Встроенные web-сервер и контейнер сервлетов

10

10

8

5

ИТОГО

56

57

44

42

Исходя из проведенного анализа мною был выбран сервер приложений JBoss Application Server, ввиду своих производительных показателей, бесплатного распространения и хорошей поддержке и сопровождению со стороны разработчиков.

1.4.5 Выбор WEB-сервера

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

Среди всех существующих на сегодняшний день WEB-серверов вне конкуренции остается Apache HTTP Server. Данное ПО является свободно распространяемым, а это является критическим критерием при выборе компонентов технологии. Кроме того, данный сервер является кроссплатформенным и гибким в конфигурации, поддерживает IPv6.

1.5 Обоснование требований к разрабатываемой сетевой технологии

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

Как уже было отражено в пункте 1.3 пользователями данной технологии будут:

- Заведующая (выполняет учет, обработку и актуализацию данных по ребенку, то есть информацией об самом ребенке: ФИО, адрес проживания, контактные данные родителей, посещаемость и т. д.);

- Мед/работник (выполняет учет, обработку и актуализацию данных по состоянию здоровья ребенка, возникающим отклонениям, истории болезней, сделанные прививки и т. д.);

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

1.5.1 Требования к защищенности системы

Опишем требования к защищенности системы:

- Система аутенфикации и идентификации пользователя;

- Ограничение одновременно передаваемого трафика по сети при выполнении запроса пользователем (web-страницы не должны быть грузоемкими).

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

Система авторизации будет заключаться в вводе пользователем уникального имени, выданного и зарегистрированного специально для него, а также пароля, подтверждающего личность пользователя. С целью устранения проблемы с утратой, забыванием личных идентификационных данных, будет организован подход, при котором именем пользователя будет являться фамилия пользователя на латинице с добавлением инициалов без пробела с заглавной буквы. Пример - Иванов Дмитрий Сергеевич будет иметь имя IvanovDS. В качестве пароля будет выбран код и номер паспорта пользователя. Например, 3605999999. Это позволит:

- В любой момент пользователю на основе ассоциативных данных при утере вспомнить параметры авторизации;

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

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

1.5.2 Требования к интерфейсу системы

Опишем требования к интерфейсу системы:

- Правильный выбор цветовой гаммы системы;

- Расположение и размеры компонентов системы;

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

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

Таблица 4 - определение цветовой схемы интерфейса

№

Цвет

Критерии

Итого

Цвет не раздражает глаз

Сочетание цветов

Читаемость шрифта

1

Передний план

Ш

1

3

3

7

Фон

Ш

2

Передний план

Ш

2

2

4

8

Фон

Ш

3

Передний план

Ш

5

4

5

14

Фон

Ш

4

Передний план

Ш

5

3

5

13

Фон

Ш

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

Рисунок 18 - цветовая схема разрабатываемой технологии

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

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

1.5.3 Требования к разграничению прав и действий пользователей системы

Опишем требования к разграничению прав пользователей:

- Каждому пользователю выделяется собственная учетная запись;

- Каждый пользователь имеет свою область ответственности, а значит и доступ только к определенной части БД;

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

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

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

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

1.5.4 Требования к производительности системы

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

- Возможность одновременной обработки запросов сразу от каждого из трех описанных пользователей системы при локальном доступе, а так же пропускную способность до 1000 человек при web-запросах через сеть Интернет;

- Время ответа не должно превышать 0,1 секунды, т. е. пользователь должен воспринимать работу системы как «мгновенную»;

- Система должна быть отказоустойчива при ошибочных действиях пользователя или сбоях аппаратных средств;

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

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

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

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

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

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

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

- Ведения отчетности по детям, их личной информации, контактной информации их родителей;

- Учет и актуализация кадровой информации внутри организации «ЛАДА»;

- Ведение отчетов по истории болезней детей, прививкам и т. д.

Были выявлены основные недостатки данной системы, которые отражены в пункте 1.1 и 1.2.1.

После определения основных этапов, из которых строится текущая технология обработки информации в пункте 1.2.1, было проведено описание того, как должна работать система учета и обработки информации в рамках рассматриваемого предприятия. Данное описание приведено в пункте 1.2.2. Для реализации описанной системы нужно было определить основных участников документооборота, основные модули системы, ПО и АО. Для разрабатываемой системы была выбрана многозвенная архитектура, позволяющая в полной мере создать сетевую технологию современного уровня. Описание компонентов данной архитектуры приведено на рисунке 17 пункта 1.3.

Ключевыми лицами в работе с разрабатываемой системой были выделены:

- Заведующая дет/садом №176 (выполняет учет, обработку и актуализацию данных по ребенку);

- Мед/работник (выполняет учет, обработку и актуализацию данных по состоянию здоровья ребенка);

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

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

- Бесплатное распространение;

- Многоплатформенность;

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

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

1) В качестве технологии разработки web-приложений были выбраны Java Servlet и Java Server Page (описание критериальной оценки в пункте 1.4.1);

2) В качестве сервера БД был выбран MYSQL (описание критериальной оценки в пункте 1.4.2);

3) В качестве метода доступа к серверу БД был выбран JDBC (описание критериальной оценки в пункте 1.4.3);

4) В качестве сервера приложений был выбран JBoss Application Server (описание критериальной оценки в пункте 1.4.4);

5) В качестве web-сервера был выбран Apache HTTP Server (описание критериальной оценки в пункте 1.4.5).

Наконец, были сформулированы основные требования, предъявляемые к разрабатываемой системе:

1. Требования к защищенности системы:

а) Система аутенфикации и идентификации пользователя;

б) Шифрование данных, передаваемых внутри системы;

в) Защита от копирования web-страниц пользователем на локальную машину;

г) Ограничение одновременно передаваемого трафика по сети при выполнении запроса пользователем (web-страницы не должны быть грузоемкими);

д) Выполнение резервирования данных (back-up системы).

2. Требования к интерфейсу системы:

а) Правильный выбор цветовой гаммы системы;

б) Расположение и размеры компонентов системы;

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

3. Требования к разграничению прав и действий пользователя системы:

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

б) Каждый пользователь имеет свою область ответственности, а значит и доступ только к определенной части БД;

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

4. Требования к производительности системы:

а) Возможность одновременной обработки запросов сразу от каждого из трех описанных пользователей системы при локальном доступе, а так же пропускную способность до 1000 человек при web-запросах через сеть Интернет;

б) Время ответа не должно превышать 0,1 секунды, т. е. пользователь должен воспринимать работу системы как «мгновенную»;

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

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

2. Разработка информационной технологии

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

2.1 Разработка логической модели БД

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

На основе ненормализованных данных, определенных в Приложении 1, можно реализовать построение логической модели создаваемой БД.

информация данные приложение публикация

Рисунок 19 - ненормализованная сущность таблицы «Информация о ребенке»

Рисунок 20 - ненормализованная сущность таблицы «Кадровая информация»

Рисунок 21 - ненормализованная сущность таблицы «Медицинская информация»

После определения ненормализованных сущностей необходимо выполнить их нормализацию.

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

Рисунок 22 - логическая модель разрабатываемой технологии

2.2 Разработка физической модели БД

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

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

Тип данных логической модели

Тип данных физической модели

string

varchar (30)

number

int

datetime

datetime

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

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

Рисунок 24 - физическая модель данных разрабатываемой технологии

2.3 Разработка основных форм и интерфейсов

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

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

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

Рисунок 25 - схема взаимодействия форм и интерфейсов системы

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

- Интерфейс для ввода новых данных;

- Интерфейс для актуализации БД;

- Интерфейс для получения отчета по запрашиваемым параметрам.

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

Страница:


Подобные документы

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

© 2000 — 2023, ООО «Олбест» Все права защищены