ТРЕБОВАНИЯ ПРЕДЪЯВЛЯЕМЫЕ К СИСТЕМЕ Основные требования:
· содержать электронные формы стандартных документов (личная медицинская карта, история болезни, результаты анализов / исследований);
· позволять заполнять имеющиеся стандартные формы используя устройства ввода;
· иметь возможность хранения электронных (отсканированных) копий документов;
· иметь возможность формирования различных типовых отчетов (по пациентам, по отделениям, по заболеваниям);
Обеспечивающие требования:
· иметь возможность внесения дополнительных форм документов и отчетов;
· обеспечивать защиту информации от несанкционированного доступа и изменения;
· иметь возможность резервного копирования данных;
· проверка на правильность ввода данных.
Вспомогательные требования:
· иметь удобную систему поиска и фильтрации по различным параметрам;
· возможность печати (на принтере) отчетов, форм и электронных копий документов;
· возможность сохранения данных, отчетов, форм в отдельный файл для отправки по факсу или электронной почтой.
Нефункциональные требования:
· работа в операционной системе Windows;
· наглядный пользовательский интерфейс для простоты и удобства работы пользователя;
· возможность хранения большого объема электронных документов.
КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Для разработки архитектуры ИС, целесообразно использовать шаблон трехслойной архитектуры.
Основные высказывания:
Слой представления – предоставляет услуги отображения данных, обработки событий пользовательского интерфейса (щелчки мыши, нажатия клавиш). В общем случае, охватывает все, что имеет отношение к общению пользователя с ИС.
Предметная область – выполняет вычисления на основе вводимых и хранимых данных, проверку всех элементов данных и обработка команд, поступающих от слоя представления, а так же передачу информации стою источника данных.
Выполняет обращение к БД, обмен сообщениями, мониторинг транзакций.
Назначение классов концептуальной модели.
№
| Наименование класса
| Назначение класса
| Слой представления
|
| E-UI-Registrator
| Граничный класс, отвечающий за отображение формы личной карты пациента, параметров и результатов поиска.
|
| E-UI-Doctor
| Граничный класс, отвечающий за отображение формы истории болезни пациента.
|
| E-UI-LDC
| Граничный класс, отвечающий за отображение формы сведений о прохождении исследовании / сдачи анализов пациентом.
|
| ControllerTreatment
| Управляющий класс, методы которого отвечают за управление приложением в целом
| Слой предметной области
|
| CallService
| Граничный класс, отвечающий за взаимодействие с классами слоя предметной области.
|
| PatientData
| Класс хранения, содержащий ключевые данные о пациенте
|
| eDiagnose
| Класс хранения, содержащий сведения о поставленном диагнозе
|
| eResult
| Класс хранения, содержащий данные результатов исследования.
|
| eNaprav
| Класс хранения, содержащий сведения о направлении пациента на исследования / сдачу анализов.
|
| eMedcard
| Класс хранения, содержащий медицинскую карточку.
|
| eOperator
| Класс хранения, содержащий сведения об операторах, работающих с ИС.
|
| AccessList
| Класс хранения, содержащий права доступа операторов ИС
| Слой источника данных
|
| Data
| Граничный класс, отвечающий за взаимодействие с БД
|
Диаграмма классов, моделирующая структуру ИС на концептуальном уровне:
Логическая модель информационной системы:
Модель поведения.
Диаграмма № 1. Последовательность, моделирующая функцию создания новой записи.
Диаграмма № 2. Последовательность, моделирующая функцию редактирования записи
Диаграмма № 3.Последовательность, моделирующая функцию поиска записи.
Диаграмма № 4. Последовательность, моделирующая функцию аутентификации оператора.
Диаграмма № 5. Последовательность, моделирующая функцию удаления записи.
Диаграмма № 6. Последовательность, моделирующая функцию создания отчета.
МОДЕЛЬ СТРУКТУРЫ
На рисунке ниже представлена диаграмма классов ПО ИС, на которой отражены все классы, составляющие ПО ИС постановки пациента на учет в поликлинике. Данная диаграмма представляет всю модель структуры ПО ИС и получена в результате решения задач первой итерации проектирования. При необходимости, получив целевую модель структуры, можно вернуться к уточнению требований, сформулированных в концепции и выполнить вторую итерацию проектирования, результатом которой может быть уточненные модели поведения и структуры, как на концептуальном, так и на логическом уровне.
|