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

Актуальность темы

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

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

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

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

Во втором разделе пояснительной записки рассмотрены вопросы реализации информационной системы «Medic». При разработке базы данных этой информационной системы использовалось PostgreSQL, а сама информационная система была реализована в Perl с использованием HTML-шаблонов.

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

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

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

Библиографический список содержит перечень из 22 источников информации.

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

1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ МЕДИЦИНСКОГО ЦЕНТРА СЕВЕРО-КАВКАЗСКОГО ГОСУДАРСТВЕННОГО ТЕХНИЧЕСКОГО УНИВЕРСИТЕТА. ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

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

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

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

— медицинский центр Северо-Кавказского государственного технического университета (СевКавГТУ);

— функциональная структура медицинского центра;

— состав процессов, протекающих в медицинском центре;

— процедуры, входящие в состав процессов.

Выбранные методы проведения обследования медицинского центра СевКавГТУ приведены в таблице 1.1.

Таблица 1.1 — Методы организации проведения обследования

Характеристика методов сбора информации, использованной в ходе прохождения преддипломной практики в медицинском центре СевКаГТУ, представлена в таблице 1.2.

Таблица 1.2 — Характеристика методов сбора материалов обследования

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

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

Программа обследования медицинского центра СевКавГТУ представлена в таблице 1.3.

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

План-график выполнения работ на стадии сбора материалов обследования представлен в таблице 1.4. Он разделен на девять этапов. Работы проводились в срок прохождения преддипломной практики. Дата начала обследования — 10.01.11 г., дата завершения обследования — 20.03.11 г.

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

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

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

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

В начале 1992 года разработана программа перехода института в ранг технического университета, а в 1994 году приказом Комитета Российской Федерации по высшему образованию № 524 от 26.05.94 Ставропольский политехнический институт преобразован в Ставропольский технический университет. Ввиду того, что Ставропольский технический университет являлся одним из ведущих вузов региона, единственным по своему профилю на Северном Кавказе, приказом Министерства высшего и профессионального образования Российской Федерации от 29.04.99 № 1180 он переименован в Северо-Кавказский государственный технический университет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональные задачи и подзадачи предприятия представлены в виде таблицы (таблица 1.5).

Таблица 1.5 — Функциональные задачи и подзадачи СевКавГТУ

Организационно-управленческая модель.

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

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

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

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

Таблица 1.6 — Организационно-управленческая модель СевКавГТУ

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

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

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

Унифицированной формы графика документооборота нет. Каждое предприятие составляет график самостоятельно, исходя из особенностей деятельности[11].

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

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

Схема движения документов в медицинском центре отражена в таблице 1.7.

Таблица 1.7 — Схема документооборота медицинского центра СевКавГТУ

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

1. Системный блок Intel Celeron D 2.66ГГц /512Мбайт /80Гбайт /HDD /CDRW /Video /Sound /Lan /ATX 250 Вт.

2. Системный блок Intel Pentium 4 2.4 ГГц /512 Мбайт /320 Гбайт /DVD+CDRW /Video /Sound /Lan /ATX 400 Вт.

3. Маршрутизатор D-Link.

4. Принтер HP Laser Jet 1300.

5. Принтер HP Laser Jet 1200.

6. Копир Canon FC 228.

Так же имеется сеть топологии звезда, показанная на рисунке 1.2. Где связующим звеном является маршрутизатор D-Link, к которому подключены все компьютеры подразделения. Это дает возможность реализовать программный продукт в клиент-серверной технологии, что избавит от ряда проблем, крупнейшими из которых является разрозненность и актуальность данных.

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

— операционная система — Windows XP;

— офисный пакет приложений, в стандартной комплектации — Microsoft Office 2003;

? архиватор WinRARv3.62;

— антивирусные средства NOD32.

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

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

Таблица 1.8 — Проблемные ситуации и способы их разрешения

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

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

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

Полное наименование проекта — «Система управления данными медицинского центра».

Код системы — «Medic».

Наименование организации-разработчика — Северо-Кавказский государственный технический университет, факультет ИТТ, кафедра прикладной информатики, студент группы ПИ-061 Прохоров Константин Дмитриевич

Наименование организации-заказчика — медицинский центр Северо-Кавказского государственного технического университета.

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

Источники финансирования — работы проводятся без оплаты.

1.2.2 Назначение и цели создания информационной системы

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

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

— время на доступ к требуемой информации уменьшается до минимума;

— снижается вероятность ошибки при вводе информации и формировании отчетности;

— вводимая информация проверяется на уникальность.

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

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

— прием студентов или сотрудников;

— уточнение данных медицинских карт;

— прием справок о прохождении флюорографии;

— составление отчетности.

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

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

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

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

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

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

— изучение предметной области и составление технического задания с 10 января по 8 февраля 2011 г.;

— кодирование с 8 по 20 февраля 2011 г.;

— отладка и тестирование с 20 по 28 февраля 2011 г.;

— подготовка технической документации с 28 февраля по 4 марта 2011 г.;

— сдача проекта заказчику с 4 по 6 марта 2011 г.

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

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

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

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

1. Установить следующее программное обеспечение на сервер:

— PostgreSQL версии 8.4.2 или выше;

— Apache не ниже 2.0;

— Perl версии 5.8.9 и модули Template, CGI, DBI, Spreadsheet: WriteExcel, utf8, Encode, POSIX, CGI: Session, DBI: PgPP.

2. Произвести обучение системного администратора.

3. Произвести обучение пользователей работе с разработанной системой.

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

Разработчик предоставляет файлы информационной системы «Medic» в электронном формате на CD-ROM вместе с результатами тестирования и краткими инструкциями для администратора и врачей.

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

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

заказ на разработку информационной системы;

материалы и отчеты по преддипломной практике;

медицинские карты студентов;

отчеты по флюорографии студентов;

прививочные журналы.

Выводы

1. Медицинский центр СевКавГТУ является подразделением Северо-Кавказского государственного технического университета и его основная задача оказание необходимой медицинской помощи студентам и сотрудникам университета.

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

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

2. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ «MEDIC»

2.1 Обоснование выбора среды разработки

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

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

1. О разработке базы данных на основе PostgreSQL, что обусловлено ее современностью, бесплатностью и конкурентоспобностью, в сравнении с аналогичными продуктами. В PostgreSQL реализованы многие возможности, обычно присутствующие только в коммерческих СУБД, таких как DB2 и Oracle. Простота расширения — в PostgreSQL поддерживаются пользовательские операторы, функции, методы доступа и типы данных. Процедурные языки — предусмотрена поддержка внутренних процедурных языков, в том числе специализированного языка PL/pgSQL, являющегося аналогом PL/SQL, процедурного языка Oracle. Одним из преимуществ PostgreSQL является возможность использования Perl, Python и TCL в качестве внутренних процедурных языков.

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

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

2.2 Реализация информационной системы «Medic»

2.2.1 Концептуальное проектирование системы «Medic»

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

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

Таблица 2.1 — Страницы и их описание

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

Рисунок 2.1 — Концептуальная схема расположения страниц системы «Medic»

Концептуальная схема позволяет наглядно показать расположение всех страниц системы «Medic».

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

Определение сущностей модели. В процессе проектирования базы данных вся требуемая информация была разделена на 28 сущностей (таблиц):

— area (далее как район) — содержит в себе список район, из которых прибыли студенты на обучение в университете;

— card (далее как карта) — содержит в себе информацию о медицинской карте;

— comments (далее как комментарии) — комментарии к диагнозу;

— diagnosis (далее как диагнозы) — история диагнозов студента ;

— employees (далее как информация_сотруднике) — информация о сотрудниках;

— faculty (далее как факультет) — список факультетов;

— fluorography (далее как флюорография) — история прохождения флюорографии студентом ;

— func (далее как функции) — список функций работы с системой;

— group_fac (далее как группа_факультета) — список групп в факультете;

— grp (далее как группа) — список групп для работы с правами доступа к системе;

— grp_func (далее как группа_функция) — служит для реализации связи М: М между таблицами группа и функция;

— history_connections (далее как история_соединений) — история всех соединений к базе данных, служит для мониторинга;

— history_session (далее как история_сессий) — история всех сессий, служит для мониторинга всех посещений сотрудника;

— jornal_diagnosis (далее как журнал_диагнозов) — журнал диагнозов;

— jornal_vaccin (далее как журнал_прививок) — журнал прививок;

— post (далее как должность) — должность сотрудников;

— region (далее как регион) — список регионов;

— sesion (далее как сессия) — список последних сессий сотрудников;

— sot (далее как сотрудник) — список сотрудников;

— sot_func (далее как сотрудник_функции) — служит для реализации связи М: М между таблицами сотрудник и функции;

— sot_grp (далее как сотрудник_группа) — служит для реализации связи М: М между таблицами сотрудник и группа;

— students (далее как студенты) — список студентов;

— town (далее как город) — список городов;

— transaction_history (далее как история_транзакций) — история транзакций, служит для мониторинга действий пользователя по вносимым изменениям;

— treatment (далее как лечение) — назначенное лечение к диагнозу;

— type_diagnosis (далее как тип_диагноза) — список диагнозов;

— vaccine (далее как прививки) — история всех прививок студента;

— wnd (далее как окна) — список окон приложения для управления;

Инфологическое проектирование. Цель инфологического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в созданной БД. Поэтому инфологическую модель пытаются строить по аналогии с естественным языком. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства. Модель «сущность — связь» спроектированной базы данных приведена на рисунке 2.2.

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

Таблица 2.2 — Отношения между сущностями

Инфологическая модель представлена на рисунке 2.2

Рисунок 2.2 — Инфологическая модель БД Как видно из рисунка 2.2 и таблицы 2.2 между таблицами связи 1, 2, 3, 4, 5 являются связями «многие ко многим», а все остальные «один ко многим».

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

Ниже, в таблице 2.3, приведены ключи для каждой сущности.

Таблица 2.3 — Ключи

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

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

Для даталогических моделей определена методология построения диаграмм, IDEF.

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными[19].

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

IDEF1X (IDEF1 Extended) — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе[19].

Рисунок 2.3 — Даталогическая модель БД Из рисунка 2.2 видны все реализованные сущности в таблицы и атрибуты сущностей в поля таблицы с заданными типами данных.

2.2.3 Реализация серверной части приложения

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

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

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

Разработанная система содержит в себе модули:

— index. cgi — выполняет все проверки и подключает необходимый модуль окна и шаблон этого окна;

— Templete. pm — отвечает за генерацию меню;

— ConnectDB. pm — отвечает за соединение с базой данных;

— exel. pm — модуль генерации отчетов по флюорографии и привочному журналу;

— exel_card.pm — модуль генерации титульного листа медицинской карты;

— kernel. pm — отвечает за проверку логина и пароля, получения сессии, получения номера последнего окна;

— ses. pm — отвечает за проверку номера сессии;

— и модули окон с шаблонами, отвечающие за поведение окон клиентской части описанных в таблице 2.4.

Таблица 2.4 — Файлы модулей и шаблоны окон

В корне директории cgi-bin располагаются файлы index. cgi и Templete. pm и директория modules, в которой хранятся модули ConnectDB. pm, exel. pm, exel_card.pm, kernel. pm и ses.pm. Модули окон хранятся в директории wnd, а шаблоны в директории tt, которые расположены в корне директории cgi-bin. Листинг модулей приведен в приложении Б.

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

2.4 Реализация клиентской части приложения

Клиентские страницы генерируются динамически с помощью шаблонов template toolkit.

Template toolkit (TT) — это мощная система обработки шаблонов, написана на perl. Использование шаблонов для генерации web-страниц позволяет убрать из cgi-скрипта весь html код в отдельный файл (шаблон), где его сможет редактировать дизайнер. Скрипт при этом становится более читабельным.

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

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

Код cgi-скрипта index. cgi, который занимается определением какой модуль системы необходимо подключить и какие данные передать ему:

#!C:wwwPerl5.8.9binperl

print «Content-Type: Text/HTML; charset=UTF-8nn» ;

use strict;

use warnings;

use CGI;

use Template

use Templete;

use modules: kernel;

my $co = CGI->new ();

my $login = $co->param ('login') || '';

my $pass = $co->param ('pass') || '0';

my $wnd = $co->param ('wnd') || modules: kernel->read_last_page ($login, $pass);

my $ses = $co->param ('ses') || '0';

my $id_s = modules: kernel->user_id ($login, $pass, $ses);

my $CGISESSID = $ses || '0';

my $title ='Добро пожаловать!';

if ($CGISESSID eq «Error» or $id_s eq «0»){

# вывод шаблона index #

$title = 'Не правильно введено имя или пароль!';

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process ('index.tt', {'title' => $title,

'login' => $login});

}

else {

if (!$ses){

($CGISESSID, $title, $id_s) = modules: kernel->check_login ($login, $pass, $wnd);

}

else {

$CGISESSID = modules: kernel->get_session ($wnd, $id_s);

}

$ses = $CGISESSID;

if ($CGISESSID eq «Error» or $id_s eq «0»){

# вывод шаблона index #

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process ('index.tt', {'title' => $title,

'login' => $login});

}

else {

my $r_ses = modules: ses->check_ses ($CGISESSID, $id_s);

if ($r_ses == 1){

my $helper = $co->param ('hlp') || '-1';

my $hlp_lst;

if ($helper ne '-1'){

my $query = qq" SELECT helper FROM wnd WHERE id_button = '$wnd'" ;

$hlp_lst = modules: ConnectDB->SelectFromDB ($query);

}

my $menu = Templete->gen_menu ($id_s);

my $name_wnd = Templete->name_wnd ($wnd);

my $file = modules: kernel->query_file ($wnd);

$ENV{'ses'} = $ses;

require «wnds/» .$file." .pm" ;

my @page;

@page= $file->print_page ($CGISESSID);

my $query = qq" SELECT * FROM sot_func a

WHERE a. sot_id = (SELECT id_sot FROM sesion WHERE sesion = '$ses') AND a. wnd_id = '$wnd'" ;

my $rules = modules: ConnectDB->SelectFromDB ($query);

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process ('start_page.tt', {'CGISESSID' => $CGISESSID,

'wnd' => $wnd,

'menu' => $menu,

'rules' => $rules,

'namewnd' => $name_wnd,

'ses' => $ses,

'id' => $id_s,

'helper' => $helper,

'hlp_lst' => $hlp_lst,

'file' => $file.'.tt',

'page' => @page});

}

elsif ($r_ses == 0) {

$title = «У вас закончилась сессия.

Авторизуйтесь еще раз." ;

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process ('index.tt', {'title' => $title,

'login' => $login});

}

elsif ($r_ses == -1) {

print «По не понятным причинам произошел сбой. Сообщите об этом системному администратору.» ;

}

}

}

Код шаблона index. tt, который предоставляет форму для ввода пароля:

" http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >