Реализация программной системы

Цель – создание информационной системы для автоматизации рабочего места сотрудников регистратуры поликлиники.
Актуальность – регистратура одно из «узких» мест в работе поликлиники, где часто возникают очереди, автоматизация процесса записи пациентов существенно повысит качество обслуживания.
Задачи – информационная система должна предоставить возможность:
̶ сформировать базу врачей поликлиники, содержащую данные о враче, его специализации, графике работы;
̶ ввести данные пациента при записи на прием;
̶ сформировать план приема больных на неделю;
̶ получить отчеты о работе регистратуры.
2. Анализ предметной области
Предметная область – информация о врачах и пациентах поликлиники.
Сотрудник регистратуры должен иметь возможность создать, отредактировать или удалить данные врача, содержащие фамилию, имя и отчество врача, его специализацию, номер кабинета, график работы.
При обращении пациента необходимо ввести его данные и записать на прием к конкретному врачу в желаемое время.
В результате формируется план приема пациентов поликлиники.
3. Реализация проекта
В результате анализа получена следующая схема работы регистратуры и связанных служб поликлиники.

Рис. 1. Схема работы АРМ сотрудника регистратуры.

Соответственно интерфейс можно описать следующей упрощенной диаграммой:

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

Рис. 3. Диаграмма компонентов
Для описания врача поликлиники вводится класс Doctor, основные его свойства – фамилия, имя, отчество, специализация, номер кабинета формируются с помощью стандартных примитивных типов данных.
План приема врача составляет на одну неделю.
Модуль составления плана приема должен обеспечивать:
˗ формирование расписания с фиксированным временем приема каждого пациента;
˗ формирование расписания следующую рабочего дня;
˗ ввод сведений о пациенте в расписание приема врача;
˗ автоматическое удаление просроченных записей;
˗ редактирование сведений о пациенте в расписание приема врача.
Для реализации требуемых функций вводятся два класса – класс DayShedule, инкапсулирующий расписание приема на один день, и класс Timetable, агрегирующий класс DayShedule и предоставляющий расписание приема на неделю.
Интерфейс пользователя содержит отдельные формы для ввода информации о врачах и пациентах. Отдельные формы предоставляют возможность формировать расписание работы врачей.
Следующая диаграмма демонстрирует структуру и связи разработанных классов:

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

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

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


Рис. 6. Диаграмма состояний класса Doctor

Выявленные на этапе анализа свойства класса Doctor имеют следующие типы данных и сигнатуру:
• + BirthDate: DateTime; дата рождения
• + CabinetNumber: Int; номер кабинета
• + Name: String; Ф.И.О.
• + Specialization: String; специализация
• + Timetable: Timetable; график приема
Данные свойства предоставляют публичный аксессор (get) и публичный мутатор (set) с добавлением к нему логики проверки значений на