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

На данном этапе были построены модели логического и физического представления подсистемы. Разработана база данных подсистемы.

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

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

Реализация программного обеспечения – это процесс перевода системной спецификации в работоспособную систему.

Разработка модулей приложения производится при помощи следующих программных средств: Microsoft SQL Server 2005, MS Visual Studio 2005. С помощью этих средств был разработан модуль «Гематологический счетчик».

Добавление обработки вкладки команды основного меню представлено на рисунке 3.1

Рисунок 3.1- Обработка вкладки команды основного меню

Метод, который описывает вход во вкладку команд основного меню и выбор одной из команд, представлен на рисунке 3.2.

Рисунок 3.2-Медот описывающий вход в команды основного меню

Метод, который заменяет внутренности вкладки «Параметры», добавляет соответствующие акселераторы и вставляет на главную форму меню с элементами выбранного компонента программы, представлен на рисунке 3.3.

Рисунок 3.3- Метод по загрузке выбранных компонентов

Были созданы классы Leikoformula, Mielogramma, Trombocity. Базовым классом для создания выше перечисленных классов является Data. Представление класса Data представлено на рисунке 3.4.

Рисунок 3.4- Представление класса Data

Представление класса Leikoformula представлено на рисунке 3.5.

Рисунок 3.5- Представление класса Leikoformula

Представление класса Mielogramma представлено на рисунке 3.6.

Рисунок 3.6- Представление класса Mielogramma

3.2 Взаимодействие приложения с источниками данных

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

Представление класса CLeikoformulaSetAccessor представлено на рисунке 3.7.

Рисунок 3.7 – Представление класса CLeikoformulaSetAccessor

Карата событий, в которой происходит привязка объекта LEIKOFORMULA к соответствующим полям таблицы «Лейкоформула» в базе данных представлена на рисунке 3.8.

Рисунок 3.8 – Карта событий

Представление класса CMielogrammaSetAccessor представлено на рисунке 3.9.

Рисунок 3.9 – Представление класса CMielogrammaSetAccessor

Карата событий, в которой происходит привязка объекта MIELOGRAMMA к соответствующим полям таблицы «Миелограмма» в базе данных представлена на рисунке 3.10.

Рисунок 3.10 – Карта событий

3.3 Тестирование приложения

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

Тестирование приложения «Гематологический счетчик» производилось в среде разработки MS Visual Studio 2005, удобство этого средства тестирования заключается в возможности его использования в режиме отладки приложения под управлением встроенного отладчика Visual Studio.

В случае неверного обращения к базе данных, при загрузке компонента появляется сообщение об ошибке.

Рисунок 3.11 – «Сообщение об ошибке».

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

Рисунок 3.12 – «Ошибка в приложении».

Пример распознавания ошибки показан на рисунке 3.12. В файле Hematology_CounterView.cpp была задана функция в которую было передано неправильное значение параметра. Можно сделать следующий вывод о том что был задан неправильный идентификатор на этапе разработке.

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

Рисунок 3.12 – «Работающее приложение».

3.4 Методика развертывания приложения

Разрабатываемый программный продукт будет поставляться на предприятие в комплекте с другими подсистемами ЛИС.

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

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

На сервере должна быть установлена программа SQL Server 2005. Заведующему КДЛ и врачу-лаборанту должны быть предоставлены права на внесение изменений в базу данных.

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

В третьем разделе дипломного проекта рассмотрен пример реализации, тестирования и развертывания компонента из предметной области проектируемой подсистемы. В разделе приведено описание разработки компонента в среде Visual Studio и основных методов его тестирования и отладки.

Продемонстрирована реализация взаимодействия компонента с СУБД и с клиентским приложением.

4. Управление информационным проектом

4.1 Выбор жизненного цикла разработки

В соответствии с определением, приведенным в [18], модель жизненного цикла разработки ПО (software life cycle model, SLCM) схематически объясняет, в каком порядке будут выполняться действия по разработке программного продукта. Такая последовательность может быть не линейной, так как фазы могут следовать последовательно, повторяться, или происходить одновременно.

Жизненный цикл – непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.

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

Таблица 4.1- Определение оптимальной модели жизненного цикла в баллах

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	5	5	2	2	5	4
Участники команды разработчиков	4	5	5	2	6	5
Коллектив пользователей	3	6	5	8	4	6
Типы проектов и рисков	1	1	3	1	8	3
Итого	13	17	15	13	23	18

Из данных приведенных в таблице можно сделать следующие выводы. Для разрабатываемой ЛИС для лабораторного отделения БСМП-2,наиболее подходящей моделью ЖЦ является метод быстрой разработки приложений «RAD».

Характерной чертой «RAD» является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций эволюционной системы или прототипов, критический анализ которых обсуждается с заказчиком. В процессе такого анализа формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени, который, как правило, составляет 60 дней и называется временным блоком.

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

При выполнении нашего проекта, для которого модель «RAD» подходит в достаточной мере, появляются следующие преимущества:

- благодаря использованию мощных инструментальных средств можно сократить время цикла разработки для всего проекта;

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

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

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