Разработка программного продукта для моделирования прибора магнитотерапии

Курсовая работа по дисциплине

«Технология программирования и создания программных продуктов»

на тему: «Разработка программного продукта для моделирования прибора магнитотерапии»

Введение

Магнитное поле обладает столь разносторонним лечебным действием, что может использоваться при огромном числе заболеваний. Благодаря значительному числу исследований и широкому использованию магнитотерапии сегодня уже известны многие направления лечебного воздействия магнитного поля на организм человека.

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

программа магнитотерапия информация

Раздел 1. Техническое задание на разработку программы «Моделирование аппарата магнитотерапии для обучающих целей»

1.1 Наименование программы, назначение и область применения

Область применения — медицинские учреждения, вузы с медицинским направлением.

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

Программа моделирования аппарата магнитотерапии имеет следующие возможности:

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

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

Частота импульсов магнитного поля в Гц;

1.2.2.2 величина индукции магнитного поля в мТл.

1.2.3 Графичиское изображение магнитного сигнала, генерируемое виртуальным прибором магнитотерапии.

1.2.4 Возможность просмотра результата лечения пациента.

1.2.5 Возможность осуществлять добавление нового пациента в базу данных.

1.2 Требования к программе

1.2.1 Требования к функциональным характеристикам

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

Предоставлять возможность пользователю производить настройку и выбор параметров прибора.

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

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

Требования к обеспечению надежного функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:

а) организацией бесперебойного питания технических средств;

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств";

г) регулярным выполнением требований ГОСТ 51 188–98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.

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

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

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

1.3 Условия эксплуатации

1.3.1 Климатические условия эксплуатации

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

1.3.2 Требования к квалификации и численности персонала

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

1.3.3 Требования к составу и параметрам технических средств

В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), включающий в себя:

Процессор Pentium-2.0Hz, не менее;

Оперативную память объемом, 1Гигабайт, не менее;

HDD, 40 Гигабайт, не менее;

Операционную систему Windows 2003/2007/Vista;

Среду разработки лабораторных виртуальных приборов NI LabVIEW 7.1.

1.3.4 Требования к информационной и программной совместимости

Требования к информационным структурам и методам решения

Программа работает под управлением системы NI LabVIEW 7.1.

Система должна содержать следующие дополнительные модули:

· LabVIEW ADO Toolkit.

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

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

Требования к программным средствам, используемым программой Программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2003/2007/Vista и NI LabVIEW 7.1.

Требования к защите информации и программ Требования к защите информации и программе не предъявляются.

1.3.5 Специальные требования

Специальные требования к программе не предъявляются.

1.4 Требования к программной документации

1.4.1 Предварительный состав программной документации

Состав программной документации должен включать в себя:

Титульный лист;

Оглавление;

Техническое задание;

Изображение схемы программы помодульно;

Схема иерархической структуры системы и расчет невязки системы;

Листинг (отчет по программному коду) основных модулей, сгенерированный в NI LabVIEW;

Расчет для основных модулей силы связности, силы сцепления, длины и объема модуля;

Схема иерархической структуры системы из NI LabVIEW и расчет невязки системы;

Руководство пользователя;

Диаграмму Use Case;

Диаграмму Ганта;

Выводы о разработанной системе.

1.5 Технико-экономические показатели

1.5.1 Экономические преимущества разработки

Ориентировочная экономическая эффективность не рассчитываются.

1.6 Стадии и этапы разработки

1.6.1 Стадии разработки

Разработка должна быть проведена в восемь стадий:

1. разработка технического задания;

2. предварительное проектирование;

3. проектирование;

4. оформление и сдача РГР;

5. кодирование;

6. тестирование и отладка работы программы;

7. подготовка документации;

8. оформление и сдача курсовой работы.

1.6.2 Этапы разработки

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

На стадии предварительного проектирования должны быть выполнены перечисленные ниже этапы работ:

o разработка UML-моделей (диаграммы Use Case);

o разработка структурной схемы программы;

o разработка диаграммы Ганта (по структуре WBS).

На стадии проектирования должны быть выполнены перечисленные ниже этапы работ:

· разработка общего интерфейса программы;

· разработка модулей программы в среде NI LabVIEW 7.1;

· реализация объединения модулей в одну программу.

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

На стадии разработки документации должны быть выполнены перечисленные ниже этапы работ:

1. произведен расчет для основных модулей силы связности, силы сцепления, длины и объема модуля;

2. произведен расчет невязки системы по схема иерархической структуры программы;

3. разработано руководство пользователя.

На стадии оформления РГР производится подитоживание и описание результатов всех выполненных работ.

На стадии кодирования должен быть реализован рабочий код программы и её интерфейс.

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

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

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

1.6.3 Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1. постановка задачи;

2. определение и уточнение требований к техническим средствам;

3. определение требований к программе;

4. определение стадий, этапов и сроков разработки программы и документации на неё;

5. согласование и утверждение технического задания.

На этапе предварительного проектирования должны быть выполнены перечисленные ниже работы:

1. разработка UML-моделей (диаграммы Use Case);

2. разработка структурной схемы программы;

3. разработка диаграммы Ганта (по структуре WBS).

На этапе проектирования программы должна быть выполнена работа по программированию (кодированию) программы.

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

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

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

1. сделаны выводы о разработке;

2. произведено оформление РГР.

На этапе кодирования должны быть выполнены перечисленные ниже работы:

1. реализация пользовательского интерфейса (первый прототип);

2. реализация второго прототипа (на 70−80% готовая функциональная часть программы);

3. реализация третьего прототипа (полностью готовая программа).

На этапе тестирования должна быть проверена работоспособность программа и проведено исправление ошибок.

На этапе разработки документации должны быть выполнены перечисленные ниже этапы работ:

1. произведен расчет для основных модулей силы связности, силы сцепления, длины и объема модуля;

2. произведен расчет невязки системы по схема иерархической структуры программы;

3. разработано руководство пользователя.

На этапе оформления курсовой по реализованной программе должны быть выполнены перечисленные ниже виды работ:

1. сделаны выводы о программе в целом;

2. произведено оформление курсовой работы.

1.7 Порядок контроля и приемки

1.7.1 Виды испытаний

Согласно требованиям к приему РГР в НТУУ «КПИ» .

1.7.2 Общие требования к приемке работы

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

1.8 Используемые источники

1. «Магнитотерапия — лечение заболеваний магнитными полями».

2. Бурмистров А. Л. «Общесистемная магнитотерапия — теория и практика». Магнитологический медицинский центр «МАДИН» г. Нижний Новгород.

Раздел 2. Результат этапа проектирования

2.1 Краткое описание идеи разработки

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

Магнитотерапия — это новое направление физиотерапии, основанное на воздействии переменного магнитного поля низкой частоты на весь организм или его часть. Ткани организма под влиянием магнитного поля не намагничиваются, однако многим составным элементам тканей (например, воде, форменным элементам крови) могут в магнитном поле сообщаться магнитные свойства.

Магнитное поле обладает столь разносторонним лечебным действием, что может использоваться при огромном числе заболеваний. Благодаря значительному числу исследований и широкому использованию магнитотерапии сегодня уже известны многие направления лечебного воздействия магнитного поля на организм человека.

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

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

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

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

2.2.1 Изображение иерархической структуры программы (схемы программы) по модульно

Рис 2. Схема модулей разработанной программы.

2.2.2 Алгоритм работы системы, входные и выходные данные

Рис. 3. Схема алгоритма работы моделируемого прибора магнитотерапии.

2.2.3 ERD, диаграмма «сущность-связь»

Рис. 4. Диаграмма «сущность-связь».

2.2.4 SADT, диаграмма функционального моделирования

Рис. 5. Диаграмма функционального моделирования.

2.2.5 DFD, диаграмма потока данных

Рис. 6. Диаграмма потока данных системы в целом.

Рис. 7. Диаграмма потока данных системы.

2.2.6 Use case, диаграмма прецедентов

Рис. 8. Диаграмма прецедентов системы.

2.2.7 Схема иерархической структуры системы и расчет невязки системы

Невязка рассчитывается по формуле 10, где n — количество вершин графа, а е — количество его ребер.

(1)

Для данной проектной структуры (см. рис.11) n = 39, e = 61.

(2)

Данная проектная структура имеет невязку стремящуюся к 0, что означает — структура хорошая.

Рис. 9. Схема иерархической структуры системы из NI LabVIEW.

2.2.8 Расчет для основных модулей силы связности, силы сцепления, длины и объема модуля

Связность модулей — в данной программе коммуникативная СС=7, т.к. все части модуля связаны по данным.

Сила сцепления — в данной программе сцепление по данным СЦ=1, т.к. модули между собой передают только элементарные данные.

Раздел 3. Результат этапа реализации

3.1 Кодирование, тестирование и отладка системы

3.1.1 Реализация программы

Данная программа была реализована с использованием графической среды разработки LabVIEW 7.1, тулкита ADO-Toolkit, а сервера баз данных MySQL [3, 4]. Программа состоит из 4 модулей: модуль получения информации из базы данных, модуль обработки информации, модуль построения графиков, модуль записи информации в базу данных. На рис. 8 показан общий вид программного кода.

Рис. 10. Общий вид программного кода системы.

1. Модуль получения информации из базы данных.

Данный модуль предназначенный для подключения к серверу баз данных MySQL с помощью ADO-Toolkit. Информация считывается из БД `lv' из таблицы Patients. Для связи сервера баз данных с LabVIEW был использован ODBC-драйвер. ODBC драйвер является ключевым компонентом при соединении виртуального прибора спроектированного на LabVIEW 2009 с сервером БД MySQL. Этот драйвер необходим для реализации прикладного программного API-интерфейса, который используется для доступа к данным в реляционных базах данных. ODBC-технология позволяет работать с разными источниками данных, абстрагируясь от особенностей взаимодействия в каждом конкретном случае. Это достигается благодаря тому, что поставщики различных баз данных создают драйверы, реализующие конкретное наполнение стандартных функций из ODBC API с учётом особенностей их продукта. C помощью ODBC можно разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия между несколькими источниками.

Рис. 11. Модуль получения информации из базы данных.

2. Модуль обработки информации.

В данном модуле реализуются методы выбора пациента из БД для проведения лечения, моделирования сигнала магнитного импульса по заданным значениям частоты и величины индукции, а также отображение его на графике. Результатом работы модуля является вывод результатов проведения магнитотерапии над выбранным пациентом.

3. Модуль добавления анкеты нового пациента в базу данных.

Данный модуль реализует добавление анкеты нового пациента в базу данных «lv» в таблицу Patients. В данном модуле, так же как и в первом, использованы елементы ADO-Toolkit.

Рис. 12. Модуль обработки информации

Рис. 14. Модуль добавления анкеты нового пациента в базу данных.

3.1.2 Тестирование и отладка После окончания этапа кодирования программы было произведено её тестирование и проверка на правильность работы.

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

Рис. 15. Тестирование первого модуля программы.

На следующем этапе работы программы выбирается из списка пациент, в результате чего в поля «Диагноз» и «Лечение» автоматически поставляется значение из БД, соответствующее выбранному пациенту.

Рис. 16. Тестирование первой части второго модуля программы.

Проверим модуль построения графиков. Из предыдущего рисунка мы видим в графе «Лечение» нужные параметры для проведения сеанса магнитотерапии над данным пациентом. Введем эти значения в отведенные им поля и нажмем кнопку «Начать сеанс». Как видно, начал строится график, моделирующий сигнал магнитотерапевтического аппарата, что подтверждает график на рис. 17.

Рис. 17. Тестирование второй части второго модуля программы.

Из рис. 16 и рис. 17 можем сделать вывод, что второй модуль программы функционирует верно.

Проверим модуль добавления нового пациента в БД. Добавим пациента со следующими характеристиками:

Рис. 18. Тестирование первой части третьего модуля программы.

На следующем рисунке мы видим, что введенный нами пациент успешно добавился в БД. В данный момент его `id' = 138, что свидетельствует о правильной работе 3 модуля.

Рис. 18. Тестированиевторой части третьего модуля программы.

3.2 Руководство пользователя

Для работы программы необходимо установить LabVIEW 7.1 с ADO-Toolkit, а также сервер баз данных MySQL с ODBC-драйвером. После этого необходимо создать БД, код которой описан ниже:

CREATE TABLE IF NOT EXISTS `Patients` (

`id` int (5) NOT NULL AUTO_INCREMENT,

`name` varchar (255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

`diagnosis` varchar (255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

`treatment` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

PRIMARY KEY (`id`)

.

Рис. 18. Закладка 1- таблица пациентов.

Передняя панель (модуль 1- введение) Для начала работы нужно проверить, имеется ли в базе данных какие-либо пациенты. Для этого нужно нажать на кнопку «Показать БД всех пациентов». Если таблица пуста, то стоит сначала заполнить поля добавления нового пациента и нажать кнопку «Добавить пациента в БД». После этого снова посмотреть таблицу всех пациентов. Я приведу скриншот уже заполненной БД:

Передняя панель (модуль 2- моделирование лечение) Данная закладка моделирует сеанс магнитотерапии над выбранным пациентом. Для его начала нужно выбрать пациента из списка, ввести параметры прибора, которые нужно для лечение именно этого пациента и нажать кнопку «Начать сеанс».

Рис. 19. Закладка 2 — оценка систолической функции ЛЖ.

Выводы о разработанной системе

В данной работе была разработана программа, которая моделирует работу реального прибора магнитотерапии.

Для реализации данной системы была выбрана платформа LabVIEW 7.1, которая идеально подходит для разработки такого вида задач. Входные и выходные данные программы будут загружаться в программу из базы данных, для реализации этой задачи будет использован модуль ADO-Toolkit. Графический язык G, который применяется в LabVIEW 7.1, позволяет быстро и эффективно разрабатывать приложения, в частности и для медицинских задач и приборов. Данная программа была реализована с использованием сервера баз данных MySQL, который включал в себя ODBC-драйвер для связи с LabVIEW 7.1.

Программа состоит из 3 модулей: модуль получения информации из базы данных (см. рис. 11), модуль обработки информации (см. рис. 12), модуль добавления анкеты нового пациента в базу данных (см. рис. 13). На рис. 10 показан общий вид программного кода.

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

Программа состоит из определенных модулей, которые удобно расположить графически и наглядно увидеть иерархическую структуру системы. В нашем случае она очень схожа с самой простой иерархической структурой — деревом, поскольку значение невязки равно 0.033. Это означает, что спроектированная структура легка для понимания и для реализации, что является большим преимуществом. Так же было проведено проектирование данной программы с помощь диаграмм «сущность-связь» (см. рис. 4), функционального моделирования (см. рис. 5), потока данных (см. рис. 6 и рис.7) и диаграммы прецедентов (см. рис. 8).

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

На этапе предварительного проектирования для данного проекта была разработана диаграмма Ганта, которая отображает график работ на два семестра (см. рис.20).

Реализованная система может быть переделана и улучшена. Например, можно реализовать систему, которая будет иметь в себе еще и аппаратную часть. Для этих целей может быть применено такое программное обеспечении как «MultiSIM», а также прибор «NI ELVIS II». Такой комплекс может быть очень полезным как в научных целях, так и в лечебных.

1. К. Гленн Системное администрирование в школе, вузе, офисе. — М.: СОЛОН-ПРЕСС, 2008. — (Серия «Элективный курс. Профильное обучение»).

2. Н. В. Максимов, И. И. Попов Компьютерные сети: учебное пособие для студентов учреждений среднего профессионального образования. — М.: Форум, 2011.

3. В. Олифер, Н. Олифер Основы компьютерных сетей. — СПб.: ПИТЕР, 2009. — (Серия «Учебное пособие»).

4.

Введение

в Телекоммуникационные технологии / Под ред. В. И. Журавлева. — М., 2010. — 239 с.

5. Пилиповский В. Я. Требования к личности техника в условиях высокотехнологического общества // Наука и техника. — 2008. — № 5. — С. 97−103.

Приложение

Диаграмма Ганта

Рис. 20. Этапы разработки системы.

Рис 21. Диаграмма Ганта.