Разработка подсистемы учета гематологических анализов для КДЛ ГБСМП-2 (стр. 4 из 12)

Рисунок 2.3 – Универсальная архитектура доступа к данным.

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

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

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

Пользовательский интерфейс представляет собой совокупность программных и аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером. Основу такого взаимодействия составляют диалоги. Под диалогом в данном случае понимают регламентированный обмен информацией между человеком и компьютером, осуществляемый в реальном масштабе времени и направленный на совместное решение конкретной задачи: обмен информацией и координация действий. Каждый диалог состоит из отдельных процессов ввода-вывода, которые физически обеспечивают связь пользователя и компьютера. Обмен информацией осуществляется передачей сообщений и управляющих сигналов /23/.

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

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

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

Графическое изображение интерфейса главного меню представлено на рисунке 2.4.

Рисунок 2.4- Графическое изображение интерфейса главного окна программы.

Графическое изображение окна для подсчета лейкоцитарной формулы представлено на рисунке 2.5.

Рисунок 2.5- Графическое изображение окна для подсчета лейкоцитарной формулы.

Графическое изображение окна для подсчета миелограммы представлено на рисунке 2.6.

Рисунок 2.6- Графическое изображение окна для подсчета миелограммы.

2.3 Проектирование базы данных

Системы, имеющие архитектуру «клиент-сервер», строятся на основе реляционных баз данных. Качество таких информационных систем зависит от того, насколько успешно спроектирована база данных.

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

Разработка концептуальной модели данных была осуществлена с использованием Case-средства Erwin 4.0. Данное программное средство использовалось в связи с тем, что Rational Rose Enterprise Edition 2002 не поддерживает взаимосвязи с Microsoft SQL Server 2005.

Разработка модели базы данных состоит из двух этапов:

- создание логической модели;

- создание физической модели.

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

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

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

Для описания гематологических исследований такими сущностями являются: «Лейкоформула», «Тромбоциты», «Миелограмма», «Ед. измерения», «Показатели числовые». Доработанная логическая модель данных системы лабораторных исследований представлена на рисунке 2.4.

Рисунок 2.4 – Логическая модель данных

Внесенные изменения в структуру БД Laboratory, реализованную в MS SQL Server 2005 представлены на рисунке 2.5.

Рисунок 2.6 – Структура данных подсистемы учета гематологических анализов

2.4 Обоснование выбора платформы создания информационной системы

Платформой для создания программного продукта по учету гематологических анализов является Visual Studio 2005. Приложение реализуется на языке C++. Этот выбор обусловлен тем, что существующая версия ПО и все подключаемые модули системы реализованы на C++ для Visual Studio 2005 [39]. В качестве базовой библиотеки классов для основного управляющего компонента ПО используется библиотека MFC, обеспечивающая реализацию архитектуры Document/View. Настройка данной библиотеки под шаблон реализации комплекса реализованы в используемой динамически подключаемой библиотеке MFC_Lab.dll. Эта библиотека обеспечивает реализацию программного интерфейса взаимодействия с компонентами прорисовки графиков в основном окне управляющего компонента, а также интерфейсы межпрограммного взаимодействия.

2.5 Проектирование модулей

Основная задача проектирования заключается в том, чтобы превратить модели анализа в документы детализированного проектирования, на основе которых реализуется система. Логическая модель проектируемой подсистемы строится на основе технологии Rational [30], используя основные объектно-ориентированные подходы языка UML [33, 34].

Начальный этап проектирования подсистемы учета гематологических анализов, как указывалось, связан с разработкой основных ActiveX-элементов, обеспечивающих ввод и модификацию основных сущностей предметной области разрабатываемой подсистемы. Разработка логической модели системы этих компонентов обеспечивает в дальнейшем возможность эффективного построения ряда систем, связанных с ведением учета гематологических анализов и, таким образом, может рассматриваться как этап проектирования горизонтальной предметной области [16].

Основными функциями, реализуемыми над этими сущностями, являются функции ввода нового элемента, удаления и модификации существующих элементов.

Каждый ActiveX-элемент с одной стороны является сервером для модуля, осуществляющего управление вызовами используемых элементов. С другой стороны данные элементы являются клиентами, осуществляющими запросы соответствующих данных из хранилища и их модификацию. Взаимодействие ActiveX-элементов с СУБД, как указывалось, осуществляется с использованием технологии OLE DB.

Для реализации функциональности сервера, взаимодействующего с клиентом, реализованном на произвольном языке программирования, данные элементы наследуются от интерфейса IDispatch. Для взаимодействия с сервером БД используются модуль стандартной динамической библиотеки stdole.dll. Диаграмма классов данного модуля, обеспечивающего функциональность COM, представлена на рисунке 2.7.

Рисунок 2.7 – Диаграмма классов, модулем гематологического счетчика

Выводы к разделу

Во втором разделе выполнено проектирование подсистемы учета гематологических анализов для КДЛ.