Постановка задачи проектирования

СОДЕРЖАНИЕ

НОРМАТИВНЫЕ ССЫЛКИ.. 7

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ. 8

ВВЕДЕНИЕ. 9

1. КОНСТРУКТОРСКАЯ ЧАСТЬ. 10

1.1. ВНЕШНЕЕ ПРОЕКТИРОВАНИЕ. 11

1.1.1. Постановка задачи проектирования. 11

1.1.2. Описание предметной области. 11

1.1.2.1. Естественно-языковая модель предметной области. 11

1.1.2.2. Перечень функций, подлежащих автоматизации. 12

1.1.2.3. Уменьшение времени обслуживания пациентов за счёт автоматизации. 13

1.1.2.4. Сущности и отношения между ними. 19

1.1.3. Сравнение с аналогами. 21

1.1.4. Перечень задач, подлежащих решению в процессе проектирования. 25

1.1.5. Разработка структуры.. 25

1.2. ВНУТРЕННЕЕ ПРОЕКТИРОВАНИЕ. 27

1.2.1. Проектирование баз данных. 27

1.2.2. Описание инфологической модели. 27

1.2.3. Связи между сущностями. 32

1.2.4. Выбор СУБД.. 34

1.2.5. Разработка даталогической модели. 35

1.2.6. Разработка архитектуры АСОИУ. 41

1.2.6.1. Выбор архитектуры.. 41

1.2.6.1.1. Архитектура «Файл-сервер». 41

1.2.6.1.2. Архитектура «Клиент-сервер». 42

1.2.6.1.3.Трёхуровневая архитектура. 43

1.2.6.2. Выбор языка сценариев. 44

2. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ. 46

2.1. Задание входных/выходных данных. 47

2.2. Разработка графа диалога. 48

2.3. Разработка экранных форм. 51

2.4. Руководство пользователю.. 57

2.4.3. Создание нового пациента, изменение его данных, удаление пациента. 58

2.4.4. Работа с системой пользователем «Пациент». 59

2.4.5. Работа с системой пользователем «Медсестра кабинета приёма анализов» и «Работник лаборатории» 60

2.4.6. Работа с системой пользователем «Медсестра процедурного кабинета». 61

2.4.7. Работа с системой пользователем «Работник аптеки». 61

3. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ. 62

3.1. Оптимизация логической схемы БД.. 63

3.1.1. Понятие «хорошей» схемы БД.. 63

3.1.2. Алгоритм построения «хорошей» схемы БД.. 64

3.2. Доказательство «хорошей» схемы БД.. 64

4. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКИЙ РАЗДЕЛ.. 76

4.1. Экономическое обоснование внедрения АСДО клиентов поликлиник. 77

4.1.1. Обоснование сметы затрат на разработку программного продукта АСДО клиентов поликлиник 77

4.1.1.1. Расчет затрат на расходные материалы.. 77

4.1.1.2. Расчет затрат на оборудование. 78

4.1.1.3. Расчет затрат на оплату труда. 78

4.1.1.4 Расчет затрат на единый социальный налог. 79

4.1.1.5 Расчет затрат на услуги сторонних организаций. 80

4.1.1.6 Расчет затрат на накладные расходы.. 80

4.1.1.7 Расчет прочих расходов. 80

4.1.1.8. Расчет себестоимости. 81

4.1.1.9. Расчет прибыли. 81

4.1.1.10 Расчет цены (без НДС). 81

4.1.1.11. Расчет отпускной цены (с учетом НДС). 81

4.2 Расчет стоимости оборудования, которое следует закупить для создания АСДО клиентов поликлиник 82

4.3. Расчет стоимости программного обеспечения, которое следует закупить для создания АСДО клиентов поликлиник. 83

4.4. Расчет стоимости установки и монтажа АСДО клиентов поликлиник. 83

4.5. Расчет экономии стоимости затрат на содержание и эксплуатацию АСДО после ее внедрения за месяц 83

4.6. Расчет срока окупаемости АСДО после ее внедрения. 85

5. ПРОМЫШЛЕННАЯ ЭКОЛОГИЯ И БЕЗОПАСНОСТЬ. 87

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

5.2. Характеристика условий труда. 91

5.3. Эргономические требования к рабочему месту. 96

5.4. Расчёт освещённости. 101

5.4.1. Комната 1 (два программиста). 102

5.4.2. Комната 2 (руководителя). 105

ЗАКЛЮЧЕНИЕ. 109

Список использованных источников. 110

Приложение А. Графические листы.. 111

Приложение Б. Техническое задание. 122

НОРМАТИВНЫЕ ССЫЛКИ

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

1. ГОСТ 19.502-78. Единая система программной документации. Описание применения. Требования к содержанию и оформлению.

2. ГОСТ 19.404-79. Единая система программной документации. Поясительная записка. Требования к содержанию и оформлению.

3. ГОСТ 19.104-78. Единая система программной документации. Основные надписи.

4. ГОСТ 19.001-77. Единая система программной документации. Общие положения.

5. ГОСТ 19.101-77. Единая система программной документации. Виды программ и программных документов.

6. ГОСТ 19.106-78. Единая система программной документации. Требования к программным документам, выполненным печатным способом.

7. ГОСТ 34.320-96. Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы.

8. ГОСТ 12.2.032-78. Система стандартов безопасности труда. Рабочее место при выполнении работ сидя. Общие эргономические требования.

9. ГОСТ 19.506-79. Единая система программной документации. Описание языка. Требования к содержанию и оформлению.

10. ГОСТ 22269-76. Система “Человек - машина”. Рабочее место оператора. Взаимное расположение элементов рабочего места. Общие эргономические требования.

11. СНиП 23-05-95 Естественное и искусственное освещение.

12. СанПин 2.2.1./2.1.1. 1278-03 Гигиенические требования к естественному, искусственному и совмещенному освещению жилых и общественных зданий.

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ.

Клиент – физическое или юридическое лицо, пользующееся услугами компании.

Заказ – перечень товаров, которые хочет приобрести клиент. Также включает информацию о клиенте.

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

Пользователь – лицо, работающее с системой.

БД – база данных.

СУБД – система управления базами данных.

ПК – персональный компьютер.

ПЭВМ – персональная электронно-вычислительная машины.

SQL – Structured Query Language, структурированный язык запросов.

ПО – программное обеспечение.

ОС – операционная система.

НДС – налог на добавленную стоимость.

URL –Universal Resource Locator, адрес страницы в сети интернет.

СНиП – Строительные нормы и правила.

СанПин – Санитарные правила и нормы.

ГОСТ – Государственный стандарт.

3НФ – третья нормальная форма

SQL – Structured Query Language, структурированный язык запросов

ВВЕДЕНИЕ

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

Главной целью создания АС является не упрощение, но категоризация и стандартизация автоматизируемого процесса, что позволяет обеспечивать стабильность работы системы, прозрачность её контроля и анализа слабых мест и основания для её развития либо свёртывания (списания, замены).

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

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

КОНСТРУКТОРСКАЯ ЧАСТЬ

ВНЕШНЕЕ ПРОЕКТИРОВАНИЕ

Описание предметной области

Описание сущностей

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

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

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

Сравнение с аналогами

На данный момент существует два типа систем медицинского обслуживания:

1) Системы типа «Электронная история болезни» (пример - http: //www.med-soft.net/). Данные системы предназначены для врачей различных поликлиник, которые работают с ними непосредственно при приёме пациента. Они обладают широким функционалом для персонала, в них существуют отдельные модули для различных врачей и других работников поликлиник. Модулей для пациентов в таких системах не предусмотрено, запись к врачу осуществляет работник поликлиники (модуль регистратора) при обращении пациента;

2) Системы типа «Электронная регистратура» (пример - https: //www.medkirov.ru/e-reg/docid/kgb2pk1). Данные системы предназначены для записи пациентов к врачам. Пациент может удалённо, со своего домашнего компьютера записаться к врачу на приём. Для врачей в таких системах функционала не предусмотрено, они только могут получить информацию о том, кто и когда к ним записался на приём.

Проведём сравнительный анализ этих двух типов систем и разрабатываемой нами АСДО клиентов поликлиник по следующим критериям (используемые сокращения: ЭБ – системы типа «Электронная история болезни», ЭР – системы типа «Электронная регистратура»):

1. Возможности для персонала.

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

· В ЭР представлена только возможность просмотра врачами пациентов, записавшихся к ним. По данному показателю системе ставим 0.5 балла;

· В АСДО существуют основные функции для персонала поликлиники, которых меньше по сравнению с ЭБ. По данному показателю системе ставим 3 балла.

2. Возможности для пациентов.

· В ЭБ пациент может только записаться на приём к врачу через специального регистратора. Это единственное возможное действие пациента в этой системе. По данному показателю системе ставим 0.5 балла;

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

· В АСДО пациент может не только записаться к врачу через Internet, но и просмотреть все записи врачей в своей карте, увидеть направления на процедуры, на анализы, просмотреть результаты своих анализов. По данному показателю системе ставим 5 баллов.

3. Простота будущего внедрения.

· При внедрении ЭБ в ту или иную поликлинику возникнут большие трудности, поскольку в системе нет возможностей для «плавного» перехода от неавтоматизированного процесса, связанного с заполнением бумажных карт и иных документов, к автоматизированному. По данному показателю системе ставим 0 баллов;

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

· В АСДО предусмотрены возможности печати бумажных версий записей в карту, различного рода направлений и рецептов, что поможет более плавно перейти от «бумажной» организации процесса к автоматизированной. По данному показателю системе ставим 5 баллов.

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

· В ЭБ предполагается, что все процедуры, анализы и пр. будут происходить в одной и той же больнице, где установлена система (выписка направлений в другие диагностические центры не предусмотрена), однако это не всегда так – зачастую, пациентов посылают на обследование в другие места. По данному показателю системе ставим 0 баллов;

· В ЭР такая связь не очень важна, т.к. врачи ей не пользуются. Поскольку пациент может записаться в любую поликлинику, данные о врачах которой присутствуют в системе, ставим по данному показателю 5 баллов;

· В АСДО у врачей имеется возможность направить пациента в другой диагностический центр на прохождение определённой процедуры. По данному показателю системе ставим 5 баллов.

5. Простота интерфейса.

· В ЭБ интерфейс довольно сложен за счёт большого функционала системы. Это осложнит работу с системой на начальном этапе, потребуется много времени, пока сотрудники поликлиники научатся с ней работать. По данному показателю системе ставим 3 баллов;

· В ЭР интерфейс довольно прост, запись к врачу не должна вызвать сильные затруднения у пациента. По данному показателю системе ставим 5 баллов;

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

Таблица 1.1.

Итоговая таблица с поставленными оценками:

Показатель	ЭБ	ЭР	АСДО
1. Возможности для персонала		0.5
2. Возможности для пациентов	0.5
3. Простота будущего внедрения
4. Связь с другими поликлиниками
5. Простота интерфейса

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

1. Возможности для персонала:

· ЭБ: претензий нет (+5 баллов);

· ЭР: просмотр записавшихся пациентов (+0.5 балла);

· АСДО: просмотр записавшихся пациентов (0.5), выписка направлений на анализы и процедуры (1), выписка рецептов (0.5), проведение процедур (0.5), исследование анализов (0.5). Итого: 3 балла.

2. Возможности для пациентов:

· ЭБ: запись на приём к врачу через специального регистратора (+0.5 балла);

· ЭР: запись на приём к врачу через Internet (+2 балла);

· АСДО: запись на приём к врачу через Internet (+2 балла), просмотр результатов анализов (+1 балл), просмотр выписанных рецептов (+1 балл), просмотр принимаемых процедур (+1 балл). Итого: 5 баллов.

3. Простота будущего внедрения:

· ЭБ: нет возможностей для «плавного» перехода к автоматизации (0 баллов);

· ЭР: проблемы при взаимодействии с модулем, предназначенным для врачей (-3 балла). Итого: 2 балла;

· АСДО: модуль врачей является составной частью системы (+ 3 балла), имеется возможность печати бумажных направлений (+2 балла). Итого: 5 баллов.

4. Связь с другими поликлиниками:

· ЭБ: таких возможностей нет (0 баллов);

· ЭР: пациент может записаться в любую доступную поликлинику (+5 баллов);

· АСДО: имеется возможность выписать направление на обследование в другую поликлинику (+5 баллов).

5. Простота интерфейса:

· ЭБ: интерфейс довольно сложен, очень много полей для заполнения (+3 балла);

· ЭР: претензий нет (+5 баллов);

· АСДО: претензий нет (+5 баллов).

Разработка структуры

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

Разрабатываемая система имеет модульную структуру. Количество и состав модулей зависит от требований к системе. В составе системы присутствуют следующие модули:

· Модуль пациента;

· Модуль врача;

· Модуль администратора системы;

· Модуль кабинета приёма анализов;

· Модуль процедурного кабинета;

· Модуль лаборатории.

1. Модуль пациента.

Данный модуль позволяет пациенту:

· Записаться к врачу;

· Просматривать все записи к различным врачам;

· Просматривать записи в своей карте;

· Просматривать направления на анализы и результаты сданных анализов;

· Просматривать направления на процедуры и количество пройдённых процедур.

2. Модуль врача.

Данный модуль позволяет врачу:

· Просматривать всех записавшихся к нему пациентов;

· Проводить приём пациентов:

o Осуществлять запись в карте;

o Выписывать направления на анализы и процедуры;

o Выписывать направления к другим врачам и в другие диагностические центры;

o Выписывать рецепты;

· Просматривать своё расписание.

3. Модуль администратора системы.

Данный модуль позволяет администратору:

· Добавлять в базу новые поликлиники и диагностические центры;

· Добавлять в базу новых врачей поликлиники и пациентов, прикреплённых к данной поликлинике;

· Изменять, в случае необходимости, данные врачей и пациентов;

· Составлять расписание работы врачей.

4. Модуль кабинета приёма анализов.

Данный модуль позволяет санитарному врачу:

· Производить отметки о приёме анализов;

· Передавать данные о сданном анализе в лабораторию.

5. Модуль процедурного кабинета.

Данный модуль позволяет медсестре:

· Производить отметки о прохождении пациентом процедуры;

· Заносить данные о результатах проведённой процедуры.

6. Модуль лаборатории.

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

· Заносить данные об исследованном анализе соответствующего пациента.

ВНУТРЕННЕЕ ПРОЕКТИРОВАНИЕ

Проектирование баз данных

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

На этапе инфологического проектирования используется неформальная модель предметной области типа «сущность-связь». Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Основное назначение неформальной модели «сущность-связь» является семантическое описание предметной области и представление информации для обоснования выбора видов и моделей и структур данных, которые в дальнейшем будут использоваться в системе. Для построения модели типа «сущность-связь» используются три основных конструктивных элемента для представления составляющих предметную область – сущность, атрибут и связь.

Выбор СУБД

Для интернет-приложений используются множество различных баз данных: MySQL, PostgreSQL, MS SQL Server и другие. Для анализа воспользуемся некоторыми из них.

Таблица 1.18.

Сравнение аналогов СУБД

Аналоги Критерии сравнения	Весовой коэффициент	PostgreSQL	MySQL	MS SQL Server
Скорость работы	0, 25
Настройка	0, 15
Простота БД	0, 2
Поддержка хостинг-провайдерами	0, 2
Максимальный размер БД	0, 1
Платформа	0, 1	Unix	Unix, Windows	Windows
Итого		4, 2	4, 75	4, 25

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

Помимо Windows (поддерживаются версии от Windows95 до Windows Vista) и Unix ОС MySQL портирована на большое количество платформ, таких как Mac OS X, OpenBSD и др.

В 5 версии поддерживаются вложенные запросы и производные таблицы, триггеры, обработчики ошибок, представления.

Учитывая результаты сравнения с аналогами и поддержку множества ОС, для реализации проекта была выбрана СУБД MySQL.

Выбор архитектуры

Архитектура «Файл-сервер».

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

Рисунок 1.12. - Архитектура «Файл-сервер»

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

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

Трёхуровневая архитектура

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

Трёхуровневая архитектура представляет собой:

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

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

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

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

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

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

Учитывая вышеизложенное, в качестве архитектуры для разработки интернет-магазина была выбрана трёхуровневая архитектура.

Выбор языка сценариев

Необходимо выбрать язык сценариев для реализации проекта. Язык сценариев (скриптовый язык) - язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере.

Самыми распространёнными языками сценариев являются PHP и Perl, поэтому они и будут сравниваться для нахождения оптимального варианта реализации проекта интернет-магазина.

Таблица 1.34. Сравнительный анализ языков сценария

Аналоги Критерии сравнения	Весовой коэффициент	Perl (Practical Extraction and Report Language)	PHP (Personal Home Pages)
Простота и удобство в использовании	0, 2
Поддержка хостинг-провайдерами	0, 2
Решение административных задача в ОС Windows	0, 2
Быстрота	0, 2
Для работы с MySQL	0, 2	Модули DBI, Msql-Mysql-modules, Data-Dumper, Data-ShowTable	Модуль php5-mysql
Итого		4, 2	4, 8

PHP - язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. Входит в LAMP — «стандартный» набор для создания веб-сайтов (Linux, Apache, MySQL, PHP).

Область применения PHP сфокусирована на написании скриптов, работающих на стороне сервера; таким образом, PHP способен выполнять то, что выполняет любая другая программа CGI, например, обрабатывать данные форм, генерировать динамические страницы или отсылать и принимать cookies.

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

ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

Задание входных/выходных данных

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

Информация, вводимая администратором:

· Логин и пароль;

· Личные данные врача:

o ФИО;

o Должность;

o Расписание работы;

o Год рождения;

· Личные данные пациента:

o ФИО;

o Год рождения;

o Данные полиса.

Информация, вводимая врачом:

· Логин и пароль;

· Запись в карте пациента (данные о приёме);

· Соответствующие поля направлений на анализы и процедуры;

· Соответствующие поля направлений к другим врачам и в другие реабилитационные центры;

· Выписка рецепта на лекарства.

Информация, вводимая пациентом:

· Логин и пароль;

· Дата и время записи к врачу на приём.

Информация, вводимая медсестрой кабинета приёма анализов:

· Логин и пароль;

· Отметка о приёме анализа;

· Выбор лаборатории, в которую направляется анализ для исследований.

Информация, вводимая медсестрой процедурного кабинета:

· Логин и пароль;

· Отметка о прохождении процедуры.

Информация, вводимая работником лаборатории:

· Логин и пароль;

· Данные о результате анализа.

Разработка графа диалога

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

В состав основного меню для пользователя «Врач» входят следующие пункты:

1. Пациенты. В этом окне врач просматривает всех пациентов, записавшихся к нему на выбранную им дату. Когда определённый пациент приходит на приём, врач обращается к диалоговому окну «Приём».

1.1. Приём. Данное окно предоставляет врачу следующие возможности:

1.1.1. Запись в карте. Врач производит запись данных о приёме в карте пациента.

1.1.2. Направление на анализ. Врач выдаёт пациенту направления на анализы.

1.1.3. Направление на процедуру. Врач выдаёт пациенту направления на процедуры.

1.1.4. Направление к другому врачу. Врач выдаёт пациенту направления к другому врачу (к которому пациент не имеет возможности записаться самостоятельно).

1.1.5. Выписка рецептов. Врач выписывает пациенту рецепт на лекарство.

2. Расписание. Врач может просматривать своё расписание на текущее время.

В состав основного меню для пользователя «Пациент» входят следующие пункты:

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

1.1. Запись в карте. Пациент имеет возможность просмотреть записи врачей в своей карте.

1.2. Запись к врачу. Пациент может записаться к нужному ему врачу на определённую дату и время.

2. Процедуры. Пациент может просмотреть все назначенные ему процедуры.

1.1. Процедурный лист. Пациент имеет возможность посмотреть, какое количество процедур он посетил и сколько ему ещё осталось.

3. Анализы. Пациент может просмотреть все назначенные ему анализы.

1.1. Результат. Пациент имеет возможность посмотреть результат сданного анализа.

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

1. Врачи. Администратор видит всех врачей, зарегистрированных в данной системе.

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

1.2. Сгенерировать логин и пароль. Логин и пароль автоматически генерируется для выбранного врача.

1.3. Составить расписание. Администратор вводит расписание врача, дни и часы его работы.

2. Пациенты. Администратор видит всех пациентов, зарегистрированных в данной системе.

2.1. Добавить врача. Администратор может добавить нового пациента, заполнив соответствующие поля формы добавления.

2.2. Сгенерировать логин и пароль. Логин и пароль автоматически генерируется для выбранного пациента.

В состав основного меню пользователя «Медсестра кабинета анализов» входят следующие пункты:

1. Приём анализа. Пользователь вводит данные приёма анализов и сохраняет их. Дальнейшие действия производят сотрудники лаборатории.

В состав основного меню пользователя «Сотрудник лаборатории» входят следующие пункты:

1. Результат анализа. Пользователь вводит данные о результате сданного анализа.

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

1. Процедура. Пользователь ставит отметку о прохождении или пропуске пациентом процедуры.

Рис 2.1. Граф диалога

Разработка экранных форм.

При открытии сайта, пользователь попадает на страничку авторизации:

Рис. 2.2. Экранная форма авторизации

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

1. Пользователь «Врач»

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

Рис. 2.3. Список записавшихся пациентов

Когда пациент приходит на приём, врач нажимает на соответствующую пиктограмму и делает запись в карте пациента:

Рис. 2.4. Запись в карте на приёме

Помимо этого, врач может давать различные направления пациенту:

Рис. 2.5. Выписка направления на процедуру

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

Рис. 2.6. Расписание врача

2. Пользователь «Пациент»

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

Рис. 2.7. Записи к врачам

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

Рис. 2.8. Просмотр записи в карте

Для записи к определённому врачу пациент открывает соответствующую ссылку, после чего появляется окно записи:

Рис. 2.9. Запись к врачу

После перехода по ссылке «Процедуры», пациент попадает в форму, где отображаются все прописанные ему процедуры:

Рис. 2.10. Назначенные процедуры

По каждой процедуре пациент имеет возможность просматривать процедурную карточку, где отображаются пройденные и непройденные им процедуры:

Рис. 2.11. Процедурная карточка

После перехода по ссылке «Анализы», пациент попадает в форму, где отображаются все выписанные ему анализы:

Рис. 2.12. Назначенные анализы

3. Пользователь «Администратор»

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

Рис. 2.13. Врачи поликлиники

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

После перехода по ссылке «Пациенты» администратор попадает в форму для редактирования всех пациентов поликлиники:

12 3 4 5 6