Разработка концептуальной модели данных

Затем на основе информации, выявленной на этапах бизнес-моделирования, выполняется разработка концептуальной модели данных, которые будут использоваться в разрабатываемой системе. На рис. представлена в виде диаграммы классов модель данных для объекта "Клинические записи".

Рис. 8. Концептуальная модель данных

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

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

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

Этот этап завершает процедуры бизнес-моделирования. Разработанные диаграммы являются отправной точкой в процессах проектирования баз данных и приложений системы.

Разработка требований к системе

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

Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания (сценарии) прецедентов, содержащие определения используемых данных и точную последовательность их выполнения. Описание включает следующие разделы:

· заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);

· краткое описание прецедента;

· ограничения;

· предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);

· постусловия (возможные состояния системы после выполнения прецедента);

· предположения;

· основная последовательность действий;

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

· точки расширения и включения прецедентов.

В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в табл.

Таблица 12.1.
Элементы бизнес-модели	Элементы модели системных прецедентов
Бизнес-прецеденты	Подсистемы
Внешние исполнители	Исполнители
Внутренние исполнители	Исполнители или прецеденты
Процессы, выполняемые внутренними исполнителями	Прецеденты

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

Рис. 9. Модель системных прецедентов

Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС.

Внутренний исполнитель "Персонал центра" и выполняемый им ручной процесс преобразован в системный прецедент "Предоставление доступа к клиническим записям".

Внешние исполнители (например, "Производитель медицинского оборудования") непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей.

В модели отражены два специальных типа связи между прецедентами :

· "включает" — один прецедент в процессе своего исполнения обязательно выполняет некий блок действий, составляющих другой прецедент;

· "расширяет" — когда прецеденты подобны по своим действиям, но один несет несколько большую функциональную нагрузку.

Прецедент "Проверка прав доступа" впервые реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение. В результате в проектируемой ИС появляются два новых объекта – программный модуль "Менеджер защиты" и информационный блок "Набор прав".

Рис. 10. Диаграмма последовательностей для прецедента "Проверка прав"

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

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

Основные задачи этапа:

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

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

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

Диаграммы классов системы заполняются объектами из модели системных прецедентов. Они содержат описание этих объектов в виде классов и описание взаимодействия между классами.

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

Рис. 11. Диаграмма классов "Защита доступа"

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

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