− проверка на правильность ввода данных.

Вспомогательные требования

− иметь удобную систему поиска и фильтрации по различным параметрам;

− возможность печати (на принтере) отчетов, форм и электронных копий документов;

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

Нефункциональные требования

− работа в операционной системе Windows;

− наглядный пользовательский интерфейс для простоты и удобства работы пользователя;

− возможность хранения большого объема электронных документов.

4 Концептуальная модель информационной системы

Для разработки архитектуры ИС, целесообразно использовать шаблон трехслойной архитектуры.

Основные высказывания:

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

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

Выполняет обращение к БД, обмен сообщениями, мониторинг транзакций.

Результаты разработки представлены в виде диаграммы классов на рисунке 6, описание назначения классов по слоям – в таблице 1.

Таблица 1 – Назначение классов концептуальной модели

№	Наименование класса	Назначение класса
Слой представления
1.	E-UI-Registrator	Граничный класс, отвечающий за отображение формы личной карты пациента, параметров и результатов поиска.
2.	E-UI-Doctor	Граничный класс, отвечающий за отображение формы истории болезни пациента.
3.	E-UI-LDC	Граничный класс, отвечающий за отображение формы сведений о прохождении исследовании / сдачи анализов пациентом.
4.	ControllerTreatment	Управляющий класс, методы которого отвечают за управление приложением в целом
Слой предметной области
5.	CallService	Граничный класс, отвечающий за взаимодействие с классами слоя предметной области.
6.	PatientData	Класс хранения, содержащий ключевые данные о пациенте.
7.	eDiagnose	Класс хранения, содержащий сведения о поставленном диагнозе
8.	eResult	Класс хранения, содержащий данные результатов исследования.
9.	eNaprav	Класс хранения, содержащий сведения о направлении пациента на исследования / сдачу анализов.
10.	eMedcard	Класс хранения, содержащий медицинскую карточку.
11.	eOperator	Класс хранения, содержащий сведения об операторах, работающих с ИС.
12.	AccessList	Класс хранения, содержащий права доступа операторов ИС.
Слой источника данных
13.	Data	Граничный класс, отвечающий за взаимодействие с БД.

Рисунок 6 – Диаграмма классов, моделирующая структуру ИС на концептуальном уровне

5 Логическая модель информационной системы

5.1 Модель поведения

Рисунок 7 – Диаграмма последовательности, моделирующая функцию создания новой записи

Рисунок 8 – Диаграмма последовательности, моделирующая функцию редактирования записи

Рисунок 9– Диаграмма последовательности, моделирующая функцию поиска записи

Рисунок 10 – Диаграмма последовательности, моделирующая функцию
аутентификации оператора

Рисунок 11– Диаграмма последовательности, моделирующая функцию удаления

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

5.2 Модель структуры

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

Рисунок 13– Диаграмма классов, моделирующая структуру ПО ИС на логическом уровне

6 Реализация модели в среде CASE-средства

6.1 Начало работы над проектом

Запуститьпрограмму Rational Rose Enterprise Edition. Создать новый проект: FiIe→New.

После того, как проект будет создан и работа с ним будет завершена, необходимо сохранить полученные диаграммы. Для этого в меню File выбрать пункт Save или Save As, дать имя проекту и сохранить его в файл с расширением *.mdl.

6.2 Разработка диаграммы вариантов использования

Для создания главной диаграммы вариантов использования в программе Rational Rose необходимо выполнить следующие действия:

Дважды щелкнуть по пункту Main (Главная диаграмма) в разделе Use Case View (Представление прецедентов) в списке браузера, чтобы открыть диаграмму.

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

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

Чтобы создать коммуникативные ассоциации в программе Rational Rose необходимо:

1. На панели инструментов щелкнуть по кнопке Association (Ассоциативная связь) или по кнопке Unidirectional Association (Однонаправленная ассоциативная связь). Если нужная кнопка отсутствует нужно щелкнуть правой кнопкой мыши на панели инструментов, в появившемся контекстно-зависимом меню выбрать команду Customize (Настройка), чтобы добавить кнопку.

2. Щелкнуть по актеру – инициатору связи – и перетащить возникшую линию связи на нужный прецедент.

6.3 Разработка диаграммы действий

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

1. Щелкнуть правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в списке браузера.

2. В появившемся контекстно-зависимом меню выбрать команду New → Activity Diagram (Создать →Диаграмма действий). В список будет добавлена новая диаграмма, которой нужно дать имя.