Проектирование аудиометра
В процессе проектирования данной работы будет выбрана объектно-ориентированая парадигма программирования. Программную часть системы предполагается реализовать в среде LabVIEW 7.1. Выбор среды разработки LabVIEW объясняется возможностью использования модульного программирования, что значительно упрощает и проясняет процесс разработки ПП. Каждый модуль является сам по себе автономным и легко может… Читать ещё >
Проектирование аудиометра (реферат, курсовая, диплом, контрольная)
Министерство образования и науки Украины Национальный Технический Университет Украины «Киевский Политехнический Институт»
Межуниверситетский медико-инженерный факультет Кафедра лечебно-диагностических комплексов Курсовой проект с дисциплины:
«Технология программирования и создания программных продуктов»
на тему: «Аудиометрия»
Выполнила:
Хильченко К.Н.
Киев 2011
- 1. Системный анализ
- 1.1 Объект разработки
- 1.2 Назначение и область применения
- 2. Анализ требований
- 2.1 Требования к программе
- 2.1.1 Требования к функциональным характеристикам
- 2.2.1 Требования к обеспечению надежного функционирования программы
- 2.2.2 Время восстановления после отказа
- 2.2.3 Отказы из-за некорректных действий пользователей системы
- 3. Проектирование
- 3.1 Структурная схема разработки
- 3.3 Иерархическая структура разработки (модули)
- 3.4 Расчет невязки, силы связности и силы сцепления для каждого модуля
- 3.4.1 Расчет невязки
- 3.4.2 Расчет силы связности и силы сцепления для каждого модуля
- 3.4.2.1 Модуль генератора звука
- 3.4.2.2 Модуль заполнения массива
- 3.4.2.3 Модуль отображения данных массива на графике
- 3.4.2.4 Модуль записи в файл
- 3.4.2.5 Модуль вывода отчёта
- 3.5 Диаграмма Ганта
- 3.6 Диаграмма сущностьсвязь (ERD)
- 3.7 Диаграмма функционального моделирования (SADT)
- 3.8 Диаграмма потоков-данных (DFD)
- 3.10 Дополнительные инструментарии
- 3.11 Рекомендации по реализации процессов разработки и кодирования ПП
- 4. Диаграммы UML
- 4.1 Диаграмма прецедентов
- 4.2 Диаграмма деятельности
- 4.3 Диаграмма схем состояний
- 4.4 Диаграмма последовательности
- 4.5 Диаграмма сотрудничества
- 5. Описание программного продукта
- 5.1 Описание процесса разработки
- 5.1.1 Описание программного кода
- 5.1.2 Иерархическая структура
- 5.1.3 Метрика Чепина
- 5.2 Руководство пользователя
- Выводы
- Список литературы
1. Системный анализ
1.1 Объект разработки Аудиометр — прибор для исследования чувствительности слуха. Этот прибор позволяет строго дозировать интенсивность звуковых сигналов, осуществлять исследование на всех звуковых частот, функциональные пробы по диагностике пороговой дифференциальной — чувствительности, интенсивности, маскировки. Другим средством аудиометрии является регистрация слуховых вызванных потенциалов — по которым можно судить о степени снижения слуха и уровне нейропсихологического поражения.
1.2 Назначение и область применения Аудиометр представляет собой, генератор звуковой частоты, частоту и интенсивность звука которого можно регулировать с большой точностью. Применяется в медицине для исследования слуха. Цель исследования слуха — определить область слышимости и причины ее сужения. На основании этого можно решить, нуждается ли слух пациента в корректировке и можно ли ее осуществить с помощью слухового аппарата.
2. Анализ требований
2.1 Требования к программе
2.1.1 Требования к функциональным характеристикам
ВП «Аудиометр» даёт возможность выбора частот, амплитуды звучания, записи данных в файл и отображения данных графически.
2.2 Требования к надежности
2.2.1 Требования к обеспечению надежного функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже: а) организацией бесперебойного питания технических средств; б) использованием лицензионного программного обеспечения; в) регулярным выполнением требований ГОСТ 51 188–98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.
2.2.2 Время восстановления после отказа
Время восстановления после отказа, вызванного ошибками эксплуатации не должно превышать времени текущего сеанса. То есть при каждом следующем запуске программного обеспечения восстанавливаются стандартные установки.
Время восстановления после отказа, вызванного неисправностью технических средств, не должно превышать времени, требуемого на устранение неисправностей технических средств и перезапуска программных средств.
2.2.3 Отказы из-за некорректных действий пользователей системы
Отказы программы вследствие некорректных действий пользователя при взаимодействии с программой возможны, но автоматически устраняемы при повторном запуске программы.
3. Проектирование
3.1 Структурная схема разработки
Рис. 1. Схема входных данных системы, методов их обработки и выходных данных
3.2 Блок схема основного алгоритма
Рис. 2. Блок-схема алгоритма
3.3 Иерархическая структура разработки (модули)
Рис. 3. Иерархическая структура системы
1. Модуль генератора звука
2. Модуль заполнения массива
3. Модуль отображения данных массива на графике
4. Модуль записи в файл
5. Модуль вывода отчёта Ширина иерархической структуры = 3
Высота иерархической структуры = 3
3.4 Расчет невязки, силы связности и силы сцепления для каждого модуля
3.4.1 Расчет невязки
Невязка структуры — величина, характеризующая степень отличия реальной проектной структуры от дерева и полного графа. Расчет невязки:
где l = 4 — количество ребер структуры; n = 5 — количество вершин графа;
(1)
Невязка лежит в пределах 0? Nev? 1 и показывает степень отличия реальной проектной структуры от полного графа (Nev=1) и дерева (Nev=0). Чем ближе реальная проектная структура к дереву, тем она лучше. Невязка нашей иерархической структуры = 0, отсюда вывод: наша иерархическая структура — это дерево. А значит имеем дело с понятной и логически правильной структурой.
3.4.2 Расчет силы связности и силы сцепления для каждого модуля
3.4.2.1 Модуль генератора звука
Сила связности модуля СС = 10, так как он реализует 1 функцию и называется функциональная связность.
Сила сцепления модуля СЦ = 1, т.к. модуль передает только элементарные данные.
3.4.2.2 Модуль заполнения массива
Сила связности модуля СС = 10, так как он реализует 1 функцию и называется функциональная связность.
Сила сцепления модуля СЦ = 1, т.к. модуль передает только элементарные данные.
3.4.2.3 Модуль отображения данных массива на графике
Сила связности модуля СС = 10, так как он реализует 1 функцию и называется функциональная связность.
Сила сцепления модуля СЦ = 1, т.к. модуль передает только элементарные данные.
3.4.2.4 Модуль записи в файл
Сила связности модуля СС = 10, так как он реализует 1 функцию и называется функциональная связность.
Сила сцепления модуля СЦ = 1, т.к. модуль передает только элементарные данные.
3.4.2.5 Модуль вывода отчёта
Сила связности модуля СС = 10, так как он реализует 1 функцию и называется функциональная связность.
Сила сцепления модуля СЦ = 1, т.к. модуль передает только элементарные данные.
3.5 Диаграмма Ганта Рис. 4. Список задач диаграммы Ганта Рис. 5. Диаграмма Ганта
3.6 Диаграмма сущность-связь (ERD)
Рис. 6. ERD-диаграмма
3.7 Диаграмма функционального моделирования (SADT)
Рис. 7. SADT-диаграмма
3.8 Диаграмма потоков-данных (DFD)
Рис. 8. DFD-диаграмма
3.9 Жизненный цикл процесса разработки Для данной системы была выбрана каскадная модель жизненного цикла. Каскадная модель хорошо зарекомендовала себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчику свободу реализовать их как можно лучше с технической точки зрения. Также, она проста и удобна в применении, так как процесс разработки выполняется поэтапно. Ход выполнения проекта легко проследить с помощью диаграммы Ганта.
3.10 Дополнительные инструментарии
В процессе проектирования данной работы будет выбрана объектно-ориентированая парадигма программирования. Программную часть системы предполагается реализовать в среде LabVIEW 7.1. Выбор среды разработки LabVIEW объясняется возможностью использования модульного программирования, что значительно упрощает и проясняет процесс разработки ПП. Каждый модуль является сам по себе автономным и легко может быть заменен, изменен, модернизирован без последствий для остальных структурных элементов программы. Графический интерфейс позволяет яснее и логически правильнее провести разработку.
3.11 Рекомендации по реализации процессов разработки и кодирования ПП
Особое внимание стоит уделить интерфейсу программы. Так как, ее пользователями могут быть пациенты, не умеющие работать с ПК, поэтому интерфейс данной программы должен быть максимально прост и интуитивно понятен.
4. Диаграммы UML
4.1 Диаграмма Use Case (прецедентов)
Данная диаграмма создана в MS Visio 2007. Она отображает полное описание функций системы (рис. 9).
Рис. 9. Диаграмма Use Case
4.2 Диаграмма деятельности
Диаграмма деятельности создана в среде StarUML. Она описывает алгоритм который реализуется методами, действиями в каком-то классе (рис. 10).
аудиометр алгоритм программа
Рис. 10. Диаграмма деятельности
4.3 Диаграмма схем состояний
Диаграмма схем состояний создана в среде StarUML. Она описывает состояния, в которых пребывает система (рис. 11).
Рис. 11. Диаграмма схем состояний
4.4 Диаграмма последовательности
Данная диаграмма создана в среде MS Visio 2007. Она показывает взаимодействия между объектами во времени, то есть описывает последовательность сообщений во времени (рис. 12).
Рис. 12. Диаграмма последовательности
4.5 Диаграмма сотрудничества
Данная диаграмма создана в MS Visio 2007. Она показывает взаимодействие между элементами программного продукта (рис. 13).
Рис. 13. Диаграмма сотрудничества
5. Описание программного продукта
5.1 Описание процесса разработки
5.1.1 Описание программного кода
Логику работы программного продукта можно проследить по блок-диаграмме данной программы, представленной на рис. 14.
Рис. 14. Блок-диаграмма
В результате разработки данной программы использовалась готовая подпрограмма — непрерывный звуковой сигнал (рис. 15). Она генерирует звуковой сигнал, а также позволяет регулировать «чистоту» звука, с помощью «числа буферов»
Рис. 15. Генератор звукового сигнала
Основные составляющие блок-диаграммы:
Ш Значения амплитуды, частоты и числа буферов
Ш Создание массива данных Ш Вывод звукового сигнала на экран
Ш
Ш
Ш Заполнение массива данных и построение аудиограммы
Ш Сохранение результатов в формате хls
Ш Выключение прибора Результаты измерений сохранены в файле, представленном на рис. 16.
Рис. 16. Файл с результатами измерений
5.1.2 Иерархическая структура Рис. 17. Полученная иерархическая структура Для иерархической структуры (рис. 17):
Количество вершин: n = 49.
Количество ребер: e = 61.
Количество вершин полного графа: ec = n*(n-1)/2 = 49*(49−1)/2 = 1176.
Количество вершин дерева: et = n-1 = 49−1 = 48.
Невязка системы: Nev = (eet)/(ec— et) = (61−48)/(1176−48) = 0,012.(2)
Невязка лежит в пределах 0? Nev? 1 и показывает степень отличия нашей реальной проектной структуры от полного графа (Nev=1) и дерева (Nev=0). Так как посчитанное значение невязки равно Nev=0,012, что является очень маленьким значением близким к нулю, то сделаем вывод, что наша проектная иерархическая система более схожа с деревом, чем с полным графом, что является более простой и понятной иерархической структурой. Это мы можем видеть и наглядно на рис., где иерархическая структура схожа со структурой «дерева».
Проведем сравнительный анализ невязки полученной на этапе предварительного проектирования (0) и невязки, рассчитанной по созданной программе (0,012). Видим, что полученная структура более близка к структуре «дерева». Иерархическая структура на этапе предварительного проектирования полностью реализована.
5.1.3 Метрика Чепина
Метрикой сложности потока данных программ является метрика Чепина. Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Q = P + 2M + 3C + 0.5T.
Р — вводимые переменные для расчётов и обеспечения вывода. В нашей программе Р = 3.
М — переменные, модифицируемые или создаваемые внутри программы. В нашем случае М = 4.
С — переменные, участвующие в управлении работой программы. С = 4.
Т — неиспользуемые программные переменные. Т = 1.
Q = 3 + 2*4 + 3*4 + 0.5*1=23,5
5.2 Руководство пользователя
Активировать программу можно путём запуска файла Аудіометр.vi. Закрывается программа после закрытия главного окна LabVIEW.
Программа представляет собой имитацию проверки функционального состояния слухового анализатора человека путем определения порогов слышимости. Интерфейс программного продукта представлен двумя вкладками (рис. 18, рис. 19.), нажимая на которые можно переходить из одной области в другую.
Первая панель (рис. 18). Открыв вкладку «Вимірювання», пользователь может провести диагностику своего слуха. Изменение значений амплитуды, частоты и числа буферов, позволяет определять порог слышимости. Все значения заносятся в таблицу с помощью кнопки «Запис». Результаты измерений сохраняются. При нажатии на кнопку «Зберегти файл», появится окно в котором нужно указать путь размещения файла и его имя. Результаты будут сохранены в формате XLS в виде столбцов чисел, которые затем можно будет использовать при необходимости.
Вторая панель (рис. 18). Открыв вкладку «Результати вимірювань», пользователь наблюдает аудиограмму. Она является графическим изображением остроты слуха. Во время тестирования слух проверяется на различных частотах и амплитудах. Результаты представляются в виде характерной кривой. Кнопка «Вимкнути прилад» — прекращает работу программы.
Рис. 18. Вкладка № 1
Рис. 19. Вкладка № 2
Выводы
Аудиометрия — процедура по оценке состояния слуха.
Проводится при помощи специального оборудования и компьютерных программ, определяет степень потери слуха, и дает точные данные о том, на каких конкретно частотах слух человека отличается от нормы. Результатом обследования является аудиограмма, которая дает точное представление о степени потери слуха. На этапе проектирования определены входные и выходные данные системы, а так же алгоритм обработки данных (см. рис. 1), разработаны схемы и диаграммы необходимые для разработки программного продукта.
На рис. 2 представлена блок схема основного алгоритма. В работе по формуле (1) рассчитана невязка спроектированной системы (по иерархической структуре, изображенной на рис. 3) и ее значение указывает, что модульно система приближена к дереву, т. е. связи модулей довольно просты, нет сложной системы сцепки модулей. Также рассчитана невязка (формула (2)) реальной системы, представленной на рис. 17. Из приведенных схем проектной (рис. 3) и реальной системы (рис. 17) видно, что структуры практически одинаковые. То есть иерархическая структура разработанная на этапе предварительного проектирования реализована полностью. По расчетам видно, что значение невязки реальной системы (формула (2)) удовлетворяет требованиям, также как и невязка проектной системы (формула (1)). С помощью ERD-диаграммы определены данные и отношения между ними (рис. 6). Для построения модели предметной области программного продукта применена SADT-диаграмма. Она помогает лучше определить различные системные функции системы и показать как они влияют друг на друга (рис. 7). DFD-диаграмма, представленная на рис. 8, отображает потоки данных, которые переносят информацию от одной подсистемы к другой.
Программную часть системы предполагается реализовать в среде LabVIEW 7.1. Выбор среды разработки LabVIEW объясняется возможностью использования модульного программирования, что значительно упрощает и проясняет процесс разработки ПП. Каждый модуль является сам по себе автономным и легко может быть заменен, изменен, модернизирован без последствий для остальных структурных элементов программы. Графический интерфейс позволяет яснее и логически правильнее провести разработку. Ход выполнения проекта легко проследить с помощью разработки плана диаграммы Ганта (см. Рис. 4.), поскольку момент завершения каждой фазы используется в качестве стадии.
Для реализации программы были созданы диаграммы UML, такие как диаграмма Use Case (рис. 9), диаграмма последовательности (рис. 12), диаграмма сотрудничества (рис. 13) созданы в MS Visio, а диаграммы деятельности (рис. 10) и схем состояний (рис. 11) в среде StarUML.
В ходе работы было разработано руководство пользователя, которое поможет при работе с программой. Рассчитана метрика Чепина (формула (3)), которая является метрикой сложности потока данных программы.
1. http://uho.com.ua/ru/audiometry — Информационный сайт о проблемах слуха [1]
2. В. В. Богданов. Управление проектами в Microsoft Project 2002: Учебный курс./СПб.: Питер, 2003. — 640 стр. [2]
3. Бонни Бьяфоре. Microsoft Visio 2007. Библия пользователя. / Диалектика, Вильямс, 2009. — 800 стр. [3]
4. http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html — Леоненков А. Самоучитель UML.
5. LabVIEW для всех. Трэвис Дж., Кринг Дж. Москва, 2008.
6. Солоницын Ю. А. Microsoft Visio 2007. Создание деловой графики. Учебное пособие. Питер, 2009, 160 стр.