Программирование

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

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

 

 

 

 

ID	OrigID	Описание требования	Приоритет	Источник	Вопросы	Ответы
1.1	1	Ведение истории посещений пациента	должен	Врач	Как вести историю посещений пацента?	при выписке талоны на прием данные автоматически сохраняются в  базе данных,  должна быть  возможность  вывода в Excel для дальнейшей обработки  и печати
	2	Сохранение результатов проведенных  исследований.	мог бы	Врач	как сохранить результат проведеных исследований?	Результаты обследований передаются по локальной сети врачу, заказавшего  их, с последующим указанием готовности результатов обследований
1.2	1	Возможность получения данных о врачах, услугах	обязан	Регистратура	как получить необходимую информацию?	программа администратора - вывод информации по нажатию соотвествующей кнопки, есть возможность фильтрации по некоторым  критериям; программа пациента - имеются  владки, где отображается информация, есть возможность фильтрации по некоторым  критериям
	2	Ведение учета выписанных талонов	обязан	Регистратура	куда выводить информациюо выписаных  талонных	указываем промежуток времени когда  выписаны талоны и в окне программы  выводится информация об выданных талонах
	3	Возможность записи пациентов на прием  к врачу удаленно	обязан	Регистратура	как осуществляется запись пациента удаленно?	пользователь - пациент в своей  программе на вкладке "Услуги", указывает данные о враче,  о  дате и  времени приема, и резервирует  это время , это время автоматически  удаляется для всех остальных  пациентов

 

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

Описание требования	Возможное решение	Обоснование	Статус
тип хранения БД	MS Access	простота создания и работы с БД в MS Access,распространенность	утверждено
система должна иметь простой интерфейс	C#,C++,Delphi, VusualBasic	данные языки являются типовыми для  создания ПО	утверждено
расширяемость	C#,C++,Delphi, VusualBasic	добавлять функцинальные возможности  системы с помощью внесения программных  модулей	утверждено

 

 

Описание  программы

Проектирование  инфологической модели

Инфологическая модель для  базы данных «Больница» проектировалась, как модель «Сущность-связь».

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

имя_сущности(список_атрибутов).

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

• Авторизация (идентификационный номер пациента, пароль);
• Пациенты (идентификационный номер пациента, фамилия, имя, отчество, дата рождения, полис, адрес проживания);
• Доктора (идентификационный номер доктора, фамилия, имя, отчество, кабинет, профессия, статус):
• Талоны (идентификационный номер талона, идентификационный номер доктора, идентификационный номер пациента, время);
• Услуги (идентификационный номер услуги, услуга, стоимость);
• Обследования (идентификационный номер обследования, идентификационный номер услуги, идентификационный номер пациента, идентификационный номер доктора, дата обследования, готовность).

Набор атрибутов, однозначно идентифицирующих конкретный экземпляр  сущности, называется ключевым. В сущности Пациенты – идентификационный номер пациента,  в Доктора –  идентификационный номер доктора, в Талоны – идентификационный номер талона, в Услуги – идентификационный номер услуги, в Обследования – идентификационный номер обследования.

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

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

Даталогическое  проектирование

На этом этапе необходимо установить соответствие между сущностями и характеристиками предметной области  и отношениями и атрибутами. Для  этого нужно каждой сущности и  характеристикам поставить в  соответствие набор отношений (таблиц) и их атрибутов (полей).

База данных «Больница» состоит их шести таблиц, соответствующих шести сущностям: Autorization, Patients, Doctors, Талоны, Услуги, Обследования. В таблице Patients поле ID содержит уникальное значение, поэтому оно является ключевым. В таблице Doctors таковым полем является ID, в Талоны – ID, в Услуги – ID, в Обследования – ID.

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

Рис. 1.     Схема данных  и связей в базе данных «Больница»

Структура реляционных таблиц представлена в таблице 1.

Таблица 1.

Имя таблицы	Имя столбца	Домен (тип)	Null - значение	Первичный ключ	Внешний ключ
patients	ID	Счетчик	NOT NULL	да	нет
	Фамилия	Текстовый	NOT NULL	нет	нет
	Имя	Текстовый	NOT NULL	нет	нет
	Отчество	Текстовый	NOT NULL	нет	нет
	Дата Рождения	Дата/Время	NOT NULL	нет	нет
	Полис	Текстовый	NOT NULL	нет	нет
	Адрес	Текстовый	NOT NULL	нет	нет
autorization	ID	Числовой	NOT NULL	нет	да
	Pass	Текстовый	NOT NULL	нет	нет
doctors	ID	Счетчик	NOT NULL	да	нет
	Фамилия	Текстовый	NOT NULL	нет	нет
	Имя	Текстовый	NOT NULL	нет	нет
	Отчество	Текстовый	NOT NULL	нет	нет
	Кабинет	Числовой	NOT NULL	нет	нет
	Профессия	Текстовый	NOT NULL	нет	нет
	Статус	Текстовый	NOT NULL	нет	нет
талоны	ID	Счетчик	NOT NULL	да	нет
	ID_doc	Числовой	NOT NULL	нет	да
	ID_patient	Числовой	NOT NULL	нет	да
	Время	Дата/Время	NOT NULL	нет	нет
услуги	ID	Счетчик	NOT NULL	нет	нет
	Услуга	Текстовый	NOT NULL	нет	нет
	Стоимость	Денежный	NOT NULL	нет	нет
	Результат	Числовой	NOT NULL	нет	нет
обследование	ID	Счетчик	NOT NULL	да	нет
	ID_услуга	Числовой	NOT NULL	нет	да
	ID_patient	Числовой	NOT NULL	нет	да
	ID_doc	Числовой	NOT NULL	нет	да
	Дата проведения	Дата/Время	NOT NULL	нет	нет
	Готовность	Логический	NOT NULL	нет	нет

 

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

Разграничение доступа

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

• установленное на компьютере пациента;
• установленное на компьютере доктора (регистратуры);

Каждое  из приложений будет обеспечивать свои функции

1. Функции доктора (администратора):

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

2. Функции пациента:

1. Просмотр информации об услугах, врачах;
2. Запись на прием к врачу;
3. Просмотр истории посещения врачей;

4. Просмотр обследований, которые пациент должен пройти или уже прошел

Администратор

(см. приложение 1)

При запуске приложения программа просит ввести пароль администратора (рис. 2). Пароль установлен заранее, зашифрован с помощью XOR-шифрования и записан в бинарный файл pass.bin, который находится в каталоге с exe-файлом программы.

Рис. 2. Авторизация

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

Рис. 3. Администратор

Поподробнее опишем возможности и функции администратора:

1. Просмотр данных о врачах.

При нажатии в главном окне «Администратор» на «Данные» – «Данные о врачах» открывается окно, в котором представлена таблица данных о докторах поликлиники, а также фильтр для поиска и вывода определенных специалистов (рис. 4). Фильтр можно осуществлять по следующим полям: по фамилии врача, по его статусу (работает/уволен) и его профессии.

Рис. 4. Доктора

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

• Добавление докторов. При нажатии на пункт меню «Правка» – «Добавить запись» открывается новая форма [Приложение 1], в которой необходимо ввести данные о новом враче (фамилию, имя, отчество, профессию и номер будущего кабинета). При нажатии на кнопку «Ок» выполняется проверка, существует ли доктор в базе данных, и если нет – происходит процедура добавления врача в базу.
• Редактирование данных о докторе (рис.5). Также, как и при добавлении записей в таблицу «Доктора», при нажатии на пункт меню «Правка» – «Редактировать запись» открывается новая форма [Приложение 1], в которую уже внесены данные о данном докторе. При нажатии на «Ок» проверяется корректность введенных данных, и при успешности проверки происходит изменение данных о докторе.

Рис. 5. Редактирование пользователя

• При удалении из базы удаляются все записи о данном докторе из таблицы «Доктора», а также из всех таблиц, связанных с ней.

2. Просмотр данных о пациентах.

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

Для обеспечения сохранности информации изменять или удалять данные о пациентах нельзя.

Рис. 6. Пациенты

3. Вывод списка услуг поликлиники.

При нажатии на «Данные» – «Список услуг поликлиники» открывается окно с выводом информации обо всех услугах (рис. 7), оказываемых пациентам (название исследования, его стоимость и время ожидания результата по данной операции).