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

Рисунок 1.8 – Диаграммы вариантов использования для основных категорий пользователей подсистемы гематологических исследований

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

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

1.6 Аттестация требований

Аттестация требований определяет степень соответствия программного продукта (ПП) установленным требованиям [18, 21].

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

1. Обзор требований – процесс просмотра системной спецификации на предмет неточных описаний и ошибок.

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

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

4. Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных автоматическим анализатором требований, который, в свою очередь, готовит отчет обо всех обнаруженных противоречиях.

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

Рассмотрим диаграмму состояний подсистемы учета гематологических анализов, разработанную на основе предъявляемых требований к системе (см. рисунок 1.9).

Рисунок 1.9 – Диаграмма состояний проектируемой подсистемы

Гематологическая подсистема должна предоставлять специфические функции для каждой из категорий пользователей подсистемы. Ввод и изменение данных должны быть доступны только врачу-лаборанту и лаборанту. Остальные категории сотрудников имеют лишь возможность просматривать информацию в соответствии со своим запроса.

Выводы

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

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

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

2. Проектирование информационной системы

2.1 Архитектурное проектирование

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

Как указывалось ранее, данная ЛИС должна включать подсистему учета гематологических анализов, обеспечивающую функционирование гематологического отдела лаборатории и клинической-экспресс лаборатории. Поэтому в минимальную конфигурацию ЛИС должны включаться рабочие места заведующего лабораторией, врачей-лаборантов и лаборантов соответствующих отделов КДЛ, а также лечащих врачей отделений больницы. Функции пользователей в подсистеме учета гематологических анализов зависят от занимаемой должности. Примерная архитектура ЛИС была расписана на предыдущем этапе. А для подсистемы учета гематологических анализов она будет иметь вид, представлена на рисунке. 2.1.

Основной сервер ЛИС, поддерживающий функционирование базы данных системы, совмещается либо с автоматизированным рабочим местом (АРМ) заведующего лабораторией или старшего лаборанта, что было определено на предыдущем этапе проектирования ЛИС. Рабочие места сотрудников гематологического отдела и клинической экспресс-лаборатории оборудуются мини ноутбуками с установленной Windows XP.

На основании разработок предыдущего этапа проектирования ЛИС в качестве программной архитектуры используется многоуровневая архитектура. В проекте ЛИС используются модули, выполненные на основе технологии COM инкапсулирующие бизнес-логику разноплановых подсистем ЛИС.

Рисунок 2.1 – Примерная архитектура ЛИС для учета гематологических анализов.

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

Данное приложение связывается с сервером БД на основании реализации клиент-серверной архитектуры. Запуск приложения производится из диспетчерской программы ЛИС. Компонентная модель гематологической подсистемы представлена на рисунке 2.2.

Рисунок 2.2 – Компонентная модель для учета гематологических анализов