Программно-аппаратная система генерации сигналов с заданными параметрами

Разработка программно-аппаратного комплекса на базе ПЭВМ типа Pentium IV, включающего в себя периферийное устройство для генерации сигнала в виде напряжения, меняющегося во времени, и программного обеспечения для управления процессом генерации.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 30.06.2012
Размер файла 3,0 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

  • ВВЕДЕНИЕ
  • 1 ПОСТАНОВКА ЗАДАЧИ
    • 1.1 Основание для создания
    • 1.2 Характеристика объектов проектирования
    • 1.3 Цель и назначение
    • 1.4 Требования к модулю интерфейсной части системы
    • 1.5 Требования к аппаратной части комплекса
  • 2 ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ ПО ТЕМЕ ПРОЕКТА
    • 2.1 USB-генераторы
    • 2.2 ArbExpress
    • 2.3 Среда разработки LabVIEW
    • 2.4 Intel High Definition Audio
    • 2.5 Simulink
    • 2.6 Заключение
  • 3 СИСТЕМНЫЙ АНАЛИЗ ПРОЕКТА
  • 4 ВАРИАНТНЫЙ АНАЛИЗ ПРОЕКТА
    • 4.1 Выбор звуковой карты
    • 4.2 Выбор библиотеки для создания графического интерфейса
  • 5 ОПИСАНИЕ ПРОГРАММНОЙ ЧАСТИ СИСТЕМЫ
    • 5.1 Общие сведения
    • 5.2 Функциональное назначение
    • 5.3 Описание логической структуры
    • 5.4 Используемые технические средства
    • 5.5 Вызов и загрузка
    • 5.6 Входные данные
    • 5.7 Выходные данные
    • 5.8 Текст программы
  • 6 МЕТОДИКА ОТЛАДКИ И ТЕСТИРОВАНИЯ
    • 6.1 Объект испытаний 45
    • 6.2 Цель испытаний 45
    • 6.3 Требования к программе 45
    • 6.4 Требования к программной документации 45
    • 6.5 Средства и порядок испытаний 45
    • 6.6 Методы испытаний 45
  • 7 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ 51
    • 7.1 Назначение программы 51
    • 7.2 Условия выполнения программы 51
    • 7.3 Выполнение программы 51
    • 7.4 Сообщения оператору 54
  • 8 ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ 55
    • 8.1 Маркетинговые исследования 55
    • 8.2 Определение затрат на проектирование продукта 61
    • 8.3 Заключение 84
  • 9 ОХРАНА ТРУДА 85
    • 9.1 Анализ условий труда разработчика проектируемого продукта 85
    • 9.2 Расчет защитного заземления 93
    • 9.3 Заключение 98
  • 10 БЕЗОПАСНОСТЬ В ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЯХ 99
    • 10.1 Вводная часть 99
    • 10.2 Расчетная часть 102
    • 10.3 Мероприятия по защите сотрудников лаборатории 104
    • 10.4 Заключение 105
  • ЗАКЛЮЧЕНИЕ 106
  • СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 108
  • ПРИЛОЖЕНИЕ А 110
    • Приложение А1 110
    • Приложение А2 112
    • Приложение А3 113
    • Приложение А4
    • Приложение А5
    • Приложение А6
    • Приложение А7
    • Приложение А8
    • Приложение А9
    • Приложение А10
    • Приложение А11
  • ПРИЛОЖЕНИЕ Б
  • ПРИЛОЖЕНИЕ В

ВВЕДЕНИЕ

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

Актуальность разработки генератора сигналов заданной формы заключается в том, что в настоящее время ощущается острый дефицит программно-аппаратных систем, способных генерировать сигнал с заданными параметрами. Приборы иностранного производства стоят чрезвычайно дорого. Как показал анализ предметной области, для большинства приложений в научной, учебной и производственной сфере достаточно простейшего генератора, способного синтезировать сигналы в диапазоне частот от 0 до 44 кГц. Этот генератор можно реализовать на основе «встроенной» звуковой карты, входящей в состав любой современной ЭВМ. Существуют приложения с существенно ограниченными параметрами генерации сигнала. Как показала практика, просто синусоидального не достаточно, поэтому целесообразно добавить возможность генерировать сигналы разной формы в данный проект.

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

  • 1 ПОСТАНОВКА ЗАДАЧИ

1.1 Основание для создания

Основанием для проведения работ по созданию системы является приказ об утверждении тем дипломного проектирования № 178-П от 06 апреля 2012 года по Севастопольскому Национальному техническому университету. Финансирование работ не осуществляется.

1.2 Характеристика объектов проектирования

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

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

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

Параметрами сигнала являются: форма (прямоугольник, синусоида, треугольник), частота, амплитуда, скважность для прямоугольных импульсов. Диапазон частот 100 Гц - 40 кГц. Амплитуда - ±5В. Количество уровней квантования - 256. Шаг дискретизации по частоте - 100 Гц. ПЭВМ Pentium IV или совместимая (рисунок 1.1).

Рисунок 1.1 - Сигнал и его параметры

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

1.3 Цель и назначение

Целью создания системы является разработка программно-аппаратного комплекса на базе ПЭВМ типа Pentium IV, способного формировать сигнал с заданными параметрами. Данный комплекс может быть использован для тестирования работоспособности радиоэлектронных и акустических устройств, управления промышленными системами (например, системой промывки инжекторов в автомобильных мастерских), а также в учебном процессе СевНТУ.

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

1.4 Требования к модулю интерфейсной части системы

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

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

Программный комплекс должен быть реализован на персональной ЭВМ типа IBM PC.

Требования к программному обеспечению

В качестве операционной системы должна использоваться Windows XP и выше с установленным Microsoft .NET Framework 4 и выше.

Требования к аппаратной части комплекса

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

Персональная ЭВМ должна быть оснащена звуковой картой.

Требования к надежности

Требования к надёжности не были заданы.

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

Необходимо соблюдать правила эксплуатации ПЭВМ. В частности не допускать её перегрева.

2. ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ ПО ТЕМЕ ПРОЕКТА

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

Вопросы проектирования подобных программно-аппаратных систем рассмотрен в ряде литературных источников. В частности в [6] рассматриваются различные генераторы сигналов. В [16] проведен обзор USB-генераторов и их программного обеспечения.

Далее рассмотрим аналоги проектируемой системы.

2.1 USB-генераторы

Прежде всего, следует отметить ступенчатость в работе приложения «AWG-Navigator» при моделировании форм сигналов. Это следует из назначения генератора АКИП-3405 - формирование сложных сигналов произвольной формы с переменной частотой дискретизации. Здесь имеет смысл разъяснить основное различие при формировании выходного сигнала между "классическими" генераторами произвольной формы и генераторами АКИП-3403, АКИП-3404 и АКИП-3405. Для примера рассмотрим, как будут формировать несложный сигнал, состоящий из трех периодов синусоидального сигнала, двух периодов прямоугольного сигнала и одного периода треугольного сигнала два разных типа генераторов.

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

Генераторы АКИП-3403, АКИП-3404 и АКИП-3405 эту форму сигнала будут формировать по другому принципу. Форму сигнала, приведенную на рисунке 2, можно разложить на три элементарные формы сигнала - один период синусоиды, один период прямоугольника и один период треугольной формы сигнала. Далее необходимо воспроизвести один период синусоиды три раза, далее перейти к воспроизведению одного периода прямоугольного сигнала два раза, далее воспроизвести один период треугольного сигнала и начать заново цикл воспроизведения по "большому" кругу.

Очевидно, что для формирования этого не очень сложного сигнала генератор АКИП расходует в два раза меньше памяти, чем "классический" генератор сигналов произвольной формы. Если предположить, что сигнал, приведенный на рисунке 2, будет иметь не три периода синусоидального сигнала, а 96, то "классический" будет вынужден держать в памяти уже 99 периодов формы сигнала, а генератор АКИП все те же три, только синусоидальная форма сигнала будет воспроизведена по кругу 96 раз. Выигрыш в использовании памяти в этом случае уже составит 33 раза. Если предположить, что сигнал, приведенный на рисунке 2, будет иметь миллион периодов синусоидального сигнала, то может оказаться, что "классический" генератор из-за ограниченной длины памяти уже будет не в состоянии воспроизвести этот сигнал. А ресурсы памяти генератора АКИП останутся на прежнем уровне - три элементарные формы сигнала и воспроизвести сигнал по кругу миллион раз для первой формы, два раза для второй и один раз для третьей не составит никакого труда. При этом генератор АКИП будет иметь еще достаточно большой объем свободной памяти, в который могут быть записаны и воспроизведены и другие формы сигнала. Такой принцип использования памяти при формировании сигнала называется "сегментированной памятью". Он позволяет наиболее рационально использовать память генератора произвольной формы и даже при небольшом объеме памяти формировать достаточно сложные сигналы с большим периодом повторения.

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

2.2 ArbExpress

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

В позиции Math меню есть команды математических операций и нормализации кривых. Команда Waveform Math позволяет выполнять ряд

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

2.3 Среда разработки LabVIEW

Среда разработки лабораторных виртуальных приборов LabVIEW (Laboratory Virtual Instrument Engineering Workbench) представляет собой среду прикладного графического программирования, используемую в качестве стандартного инструмента для проведения измерений, анализа их данных и последующего управления приборами и исследуемыми объектами. LabVIEW может использоваться на компьютерах с операционными системами Windows, MacOS, Linux, Solaris и HP-UX. Компьютер, оснащенный измерительно-управляющей аппаратной частью и LabVIEW, позволяет полностью автоматизировать процесс физических исследований. Создание любой программы для достижения этих целей (виртуального прибора) в графической среде LabVIEW отличается большой простотой, поскольку исключает множество синтаксических деталей.

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

2/4 Intel High Definition Audio

История возникновения спецификации High Definition Audio такова. С забвением DOS и приходом Windows закончилась эпоха разношерстных архитектур и прямого программирования звуковых карт. ОС Windows привела к появлению единых стандартов и единых API. В данном случае API (Application Programming Interface) -- это единый стандартный интерфейс, служащий для высокоуровневого обращения к похожим функциям различных устройств, вместо низкоуровневого программирования под каждое устройство. В применении к звуку ОС Windows 3.11 содержала MME (Multi Media Extensions) в составе Windows API, с несколькими простейшими функциями по инициализации устройства, задания параметров работы, воспроизведения и записи звука. В 1996 году компания Microsoft выпустила довольно мощный DirectSound API с поддержкой многоканального звука, софтовой эмуляцией и возможностью аппаратного ускорения аудио функций, так что все звуковые карты начали обзаводиться DirectSound драйверами.

High Definition Audio (HD Audio) является преемником и эволюционным продолжением спецификации AC`97. Новые кодеки имеют тот же форм-фактор и совместимы с HD Audio контроллерами снизу вверх. Вероятно, следуя принципу "пользователь покупает мегагерцы", в Intel выбрали название по основному отличительному признаку -- поддержке звуковых форматов высокого разрешения, что совпадает с дословным переводом названия стандарта.

High Definition Audio кодек ALC880 поддерживает UAA (Universal Audio Architecture), имеет 4 стерео 24 бит ЦАП (SNR >100 дБA), три стерео 20 бит АЦП (SNR >85 дБA) предназначен для высококачественных мультимедиа-компьютеров. ЦАПы имеют интегрированную защиту контента от Realtek для поддержки DVD-Audio. Три стерео микрофонных входа поддерживают микрофонный массив с технологиями Acoustic Echo Cancellation (AEC), Beam Forming (BF) и Noise Suppression (NS). Входы и выходы поддерживают авто-распознавание благодаря impedance sensing и jack detect. Усилители на наушники интегрированы в каждом аналоговом выходе. Все аналоговые входы/выходы переназначаемы или автоматически подстраиваются в зависимости от подключенного устройства (Universal Audio Jack). ALC880 поддерживает 32 бит 96 кГц S/PDIF вход и выход. ALC880 поддерживает host/soft контроллер чипсета Intel ICH6, а также любой HDA совместимый контроллер. Драйверами поддерживается EAX/Direct Sound 3D/I3DL2/A3D для поддержки в играх. Интересно, что опционально заявлено кодирование в Dolby® AC-3 для вывода цифрового звука на акустику с декодером или бытовой ресивер.

И по измерениям, и по слуховым тестам High Definition Audio кодек ALC880 оказался ощутимо лучше (RMAA "Очень хорошо"), чем АС'97 кодеки Sigmatel 9721 и ALC650 (RMAA "Хорошо"). Интегрированный звук на базе High Definition Audio играет лучше современного интегрированного АС'97-звука и звуковых карт 5-летней давности, и по качеству находится приблизительно на уровне карты Creative Audigy 3-летней давности, но пока не может приблизиться к современным звуковым картам класса Audigy2 и выше. Таким образом, мы становимся свидетелями эволюционного развития стандарта АС'97 с обновлённым названием High Definition Audio, чуть улучшенным звучанием в аппаратной части и поддержкой высоких форматов звука 24 бит 96-192 кГц, Правда, они не очень нужны пользователям low-end решений, поэтому мы намеренно не заостряем внимание читателей на такой поддержке. Из полезных возможностей остаются стандартные драйвера Universal Audio Architecture от Microsoft, а также Sensaura при установке драйверов от Realtek.

2.5 Simulink

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

2.6 Заключение

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

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

Имеется техническая возможность на базе стандартных решений, имеющихся в составе абсолютного большинства ПЭВМ, решить поставленную задачу. Ограничения: максимальная частота, амплитуда, уровень шума.

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

3. СИСТЕМНЫЙ АНАЛИЗ ПРОЕКТА

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

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

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

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

Методика проведения системного анализа описана в методических указаниях [8].

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

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

Модели помогают:

- проверить работоспособность разрабатываемой системы на ранних этапах ее разработки;

- общаться с заказчиком системы, уточняя его требования к системе;

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

В основе метода системного анализа лежит принцип «черного ящика» (рисунок 3.1). Его выходы определяются входами и внутренним строением (состянием). В этом смысле говорят, что выход есть функция от входа и самого «черного ящика» Y=F(X,Z).

Рисунок 3.1 -- Модель системы при использовании принципа конечной цели

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

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

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

На основании функций проектируемой системы, представленных выше, в ней можно выделить следующие подсистемы:

- подсистема, обеспечивающая доступ к компонентам;

- дизайнер схем;

- подсистема интерпретации;

- подсистема взаимодействия с аппаратурой;

- подсистема, обеспечивающая взаимодействие пользователем.

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

Для обеспечения этой функциональности используется шаблон Model-View-ViewModel (рисунок 3.2).

Рисунок 3.2 -- Шаблон Model-View-ViewModel

Модульность - обязательный атрибут всех успешно работающих крупных систем.

С увеличением объема программы становится невозможным удерживать в памяти все детали. Естественным способом борьбы со сложностью любой задачи является ее разбиение на более простые и обозримые части. Результатом применения принципа модульности является декомпозиция подсистем и системы в целом на главную программу, модули, библиотеки. Программная система достаточно децентрализована. Выделяются две автономные части -- компоненты и интерфейс, которые полностью независимы. Это позволяет расширять функциональность программы без перекомпиляции программной системы.

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

Рисунок 3.3 -- Диаграмма классов

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

Рисунок 3.4 -- Диаграмма вариантов использования

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

4. ВАРИАНТНЫЙ АНАЛИЗ ПРОЕКТА

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

Методика проведения вариантного анализа с использованием МАИ описана в методических указаниях [13].

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

4.1 Выбор звуковой карты

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

З1. ASUS Xonar D2;

З2. Creative SB Audigy SE;

З3. HD Audio.

Определим существенные для данного проекта характеристики, то есть критерии, на основании которых будет делаться выбор:

А1. Цена;

А2. Разрядность и максимальная частота;

А3. Уровень шума.

Представим иерархическое представление поставленной задачи (рисунок 4.1):

Рисунок 4.1 -- Иерархичное представление поставленной задачи

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

Таблица 4.1 -- Шкала относительной важности

Интенсивность относительной важности

Определение

1

Равная важность

3

Незначительно важнее

5

Значительно важнее

7

Явно важнее

9

Абсолютное превосходство

2, 4, 6, 8

Промежуточные решения между двумя соседними суждениями.

Обратные величины

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

Таблица 4.2 -- Матрица парных сравнений

А1

А2

А3

А1

1

4

5

А2

1

2

А3

1

Расчет коэффициентов критерием для матрицы второго уровня приведен в приложении А1.

В результате расчетов получено, что ОС=2.16%. Так как ОС < 10%, то матрица считается согласованной.

Построим матрицы парных сравнений третьего уровня.

Критерий А1 - Цена

Таблица 4.3 -- Матрица парных сравнений альтернатив по критерию «Цена»

Цена

ASUS Xonar D2

Creative SB Audigy SE

HD Audio

ASUS Xonar D2

1

Цена

ASUS Xonar D2

Creative SB Audigy SE

HD Audio

Creative SB Audigy SE

1

HD Audio

1

Расчет коэффициентов по критерию приведен в приложении A2.

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

1.1.1 Критерий А2 - Разрядность и максимальная частота

Таблица 4.4 -- Матрица парных сравнений альтернатив по критерию «Разрядность и максимальная частота»

Разрядность и максимальная частота

ASUS Xonar D2

Creative SB Audigy SE

HD Audio

ASUS Xonar D2

1

Creative SB Audigy SE

1

HD Audio

1

Расчет коэффициентов по критерию приведен в приложении A3

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

Критерий А3 - Уровень шума

Таблица 4.5 -- Матрица парных сравнений альтернатив по критерию «Уровень шума»

ASUS Xonar D2

1

Creative SB Audigy SE

1

HD Audio

1

Уровень шума

ASUS Xonar D2

Creative SB Audigy SE

HD Audio

Расчет коэффициентов по критерию приведен в приложении A4

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

Синтез глобальных приоритетов

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

Таблица 4.6 -- Сводная таблица результатов вычислений локальных приоритетов

x1

(0,6833)

x2

(0,1998)

x3

(0,1169)

З1

0,0914

0,6483

0,5396

З2

0,2176

0,2297

0,297

З3

0,6909

0,122

0,1634

Расчет глобальных приоритетов приведен в приложении A5

В результате расчетов получено, что ОС=%.

Так как полученное отношение согласованности менее 10%, можно сделать вывод, что иерархия согласована.

Из глобальных приоритетов следует, что наиболее предпочтительной является альтернатива А3, то есть встроенная звуковая карта на основе HD Audio.

4.2 Выбор библиотеки для создания графического интерфейса

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

Б1. Window Presentation Foundation (WPF);

Б2. Windows Forms;

Б3. Gtk#.

Определим существенные для данного проекта характеристики, то есть критерии, на основании которых будет делаться выбор:

А1. Производительность;

А2. Эффективность;

А3. Количество компонент;

А4. Кроссплатформенность.

Представим иерархическое представление поставленной задачи (рисунок 4.2):

Рисунок 4.2 -- Иерархическое представление поставленной задачи

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

Таблица 4.7 -- Матрица парных сравнений

А1

А2

А3

А4

А1

1

5

5

5

А2

1

3

1

А3

1

А4

3

1

Расчет коэффициентов критерием для матрицы второго уровня приведен в приложении А6.

В результате расчетов получено, что ОС=6.27%. Так как ОС < 10%, то матрица считается согласованной.

Построим матрицы парных сравнений третьего уровня.

Критерий А1 - Производительность

Таблица 4.8 -- Матрица парных сравнений альтернатив по критерию «Производительность»

Производительность

WPF

Windows Forms

Gtk#

WPF

1

3

5

Windows Forms

1

3

Gtk#

1

Расчет коэффициентов по критерию приведен в приложении А7.

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

1.1.2 Критерий А2 - Эффективность

Таблица 4.9 -- Матрица парных сравнений альтернатив по критерию «Эффективность»

Эффективность

WPF

Windows Forms

Gtk#

WPF

1

5

5

Windows Forms

1

2

Gtk#

1

Расчет коэффициентов по критерию приведен в приложении А8.

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

Критерий А3 - Количество компонент

Таблица 4.10 -- Матрица парных сравнений альтернатив по критерию «Количество компонент»

Количество компонент

WPF

Windows Forms

Gtk#

WPF

1

2

5

Windows Forms

1

4

Gtk#

1

Расчет коэффициентов по критерию А3 приведен в приложении А9.

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

Критерий А4 - Кроссплатформенность

Таблица 4.11 -- Матрица парных сравнений альтернатив по критерию «Кроссплатформенность»

Кроссплатформенность

WPF

Windows Forms

Gtk#

WPF

1

Windows Forms

1

Gtk#

1

Расчет коэффициентов по критерию А3 приведен в приложении А10.

В результате расчетов получено, что ОС=%. Так как ОС < 10%, то матрица считается согласованной.

Синтез глобальных приоритетов

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

Таблица 4.12 -- Сводная таблица результатов вычислений локальных приоритетов

x1

(0,6091)

x2

(0,1603)

x3

(0,0703)

x4

(0,1603)

Б1

0,637

0,7088

0,5695

0,0905

Б2

0,2583

0,1786

0,3331

0,1512

Б3

0,1047

0,1125

0,0974

0,7583

Расчет глобальных приоритетов приведен в приложении A11

В результате расчетов получено, что ОС=%.

Так как полученное отношение согласованности менее 10%, можно сделать вывод, что иерархия согласована.

Из глобальных приоритетов следует, что наиболее предпочтительной является альтернатива А1, то есть использование библиотеки Windows Foundation Presentation.

5. ОПИСАНИЕ ПРОГРАММНОЙ ЧАСТИ СИСТЕМЫ

5.1 Общие сведения

Объектом проектирования является программно-аппаратный комплекс генерации сигналов с заданными параметрами, реализованный на платформе .NET Framework на языке C#.

5.2 Функциональное назначение

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

5.3 Описание логической структуры

Архитектура программной системы основа на шаблоне MVVM.

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

Шаблон MVVM делится на три части:

- модель (Model), так же, как в классической MVC, Модель представляет собой фундаментальные данные, необходимые для работы приложения;

- вид/Представление (View) так же, как в классической модели MVC, Вид -- это графический интерфейс, то есть окно, кнопки и.т.п.;

- модель вида (ViewModel, что означает «Model of View»http://ru.wikipedia.org/wiki/Model-View-ViewModel - cite_note-introduction-0) является с одной стороны абстракцией Вида, а с другой предоставляет обертку данных из Модели, которые подлежат связыванию. То есть она содержит Модель, которая преобразована к Виду, а также содержит в себе команды, которыми может пользоваться Вид, чтобы влиять на Модель.

В процессе проектирования была реализована структурная схема (рисунок 5.1).

Рисунок 5.1 -- Структурная схема

С точки зрения разработчика, система разделена на такие проекты:

Базовый элемент. Содержит описание основных интерфейсов взаимодействия и реализацию базового класса для всех компонентов.

- Редактор. Реализация редактора схем.

- Интерфейс. Содержит WPF логику ввода/вывода.

- Интерпретатор. Интерпретация схемы.

- Утилиты. Содержит часто используемых реализацию классов-помощников.

Ниже приведено детальное описание проектов.

Проект «Базовый элемент»

1.1.2.1 Описание

Реализация базового элемента для всех элементов схемы генератора. Также содержит описание портов, сигналов. Проект находится в папке «\Plugin\».

1.1.2.2 Спецификация процедур и функций

1.1.2.2.1 Класс «Plugin.cs»
Список портов.
public List<Port> Ports;
Имя.
public string Name
Тип.
public string Library.
Версия элемента.
public string Version.
Описание элемента.
public string Description.
Настройки элемента.
public XElement Settings
Показывает окно настроек.
public abstract void ShowConfigureWindow(Window owner);
Получает значение сигнала с выходного порта portName.
public Signal GetOutputSignal(string portName, IDictionary<Port, Signal> data)
Получает значение сигнала с входного порта portName.
public Signal GetInputSignal(string portName, IDictionary<Port, Signal> data)
В этом методе описывается логика интерпретации элемента.
public abstract void Emulate(IDictionary<Port, Signal> data);
В этом методе описывается логика при завершении интерпретации схемы.
public virtual void Stop();

1.1.3 Проект «Редактор»

1.1.3.1 Описание

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

1.1.3.2 Спецификация процедур и функций

1.1.3.2.1 Класс «UndoRedoService.cs»
Стек действий для отмены.
private readonly Stack<IDesignerCommand> undoCommands
Стек действия для повторения.
private readonly Stack<IDesignerCommand> redoCommands
Выполняет команду command.
public void Execute(IDesignerCommand command)
Отменяет последнюю команду
public void Undo()
Повторяет последнюю команду
public void Redo()

1.1.4 Проект «Интерфейс»

1.1.4.1 Описание

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

Вся визуальная часть интерфейса описывается декларативно в «XAML» файлах. Модуль описан в файле «\Main\MainWindow.xaml».

1.1.4.2 Структура

1.1.4.2.1 Меню и панель управления

Рисунок 5.2 -- Меню и панель управления

Основными функциями являются:

- открытие схемы генератора;

- сохранение схемы генератора;

- вырезать выделенные объекты из схемы и поместить в буфер обмена;

- копировать выделенные объекты в буфер обмена;

- вставить объекты из буфера обмена;

- удалить объекты из схемы генератора;

- отменить последнее действие пользователя;

- повторить отмененное действие пользователя;

- интерпретация схемы.

1.1.4.2.2 Библиотека элементов

Рисунок 5.3 -- Библиотека элементов

Содержит доступные элементы для создания схемы генератора. Добавление элемента осуществляется путём перетаскивания выбранного элемента в редактор.

1.1.4.2.3 Редактор

Рисунок 5.4 -- Окно редактора схемы генератора

Редактор позволяет собирать схемы генератора путём соединения элементов схемы определённым образом. Основными возможностями являются:

- выделение элементов;

- удаление элементов;

- перемещение элементов;

- добавление и удаление связей;

- открытие окна настроек выбранного элемента.

1.1.4.2.4 Панель состояния

Рисунок 5.5 -- Панель состояния

Панель состояния отображает текущее состояние приложения и дополнительно содержит функцию изменения масштаба.

1.1.5 Проект «Интерпретатор»

1.1.5.1 Описание

Интерпретирует схему генератора. В процессе интерпретации редактирование схемы невозможно. Расположение --«\Emulator\».

1.1.5.2 Спецификация процедур и функций

Список элементов для интерпретации.

private readonly IEnumerable<DesignerItem> designerItems

Запускает интерпретацию схемы.

public void Emulate()

Останавливает интерпретацию схемы.

public void Stop()

Возвращает номер элемента в очереди интерпретации.

private static int GetItemLevel(DesignerItem designerItem)

1.1.6 Проект «Утилиты»

1.1.6.1 Описание

Основные вспомогательные классы, которые используются в нескольких проектах. Расположение --«\Common\».

1.1.6.2 Спецификация методов и функций

1.1.6.2.1 Класс «LinqExtension.cs»
Преобразует последовательность в очередь.
public static Queue<T> ToQueue<T>(this IEnumerable<T> source)
Вспомогательный метод для работы с древовидными структурами.
public static TResult With<TInput, TResult>(this TInput o, Func<TInput, TResult> evaluator)

5.4 Используемые технические средства

Программная система была реализована на языке высокого уровня C# на платформе Microsoft .NET Framework для Windows.

Среда разработки - Microsoft Visual Studio 2010.

Дополнительно используется аудио-библиотека NAudio по средством которой осуществляется взаимодействие с DirectSound API.

Все необходимое программное обеспечение для разработки такой ПС можно скачать с сайта Майкрософт (http://microsoft.com).

5.5 Вызов и загрузка

Вызов приложения осуществляется запуском исполняемого файла «Siglab.exe» в корневом каталоге программы. В процессе загрузки приложения отображается окно загрузки с названием приложения (рисунок 5.3).

Рисунок 5.6 -- Окно загрузки

5.6 Входные данные

Входными данными является схема генератора представленная в формате XML.

Формат хранения элемента схемы:

<DesignerItem>

<Id>{Идентификационный номер}</Id>

<Left>{Позиция по X}</Left>

<Top>{Позиция по Y}</Top>

<Width>{Ширина}</Width>

<Height>{Высота}</Height>

<Plugin>

<Name>{Имя элемента}</Name>

<Version>{Версия}</Version>

<Settings />

</Plugin>

</DesignerItem>

</Items>

Формат хранения связи:

<Connections>

<Connection>

<Path>

<Point>

<X>{Координата X}</X>

<Y>{Координата Y}</Y>

</Point>

</Path>

<Source>

<Id>{Идентификационный номер источника}</Id>

<Name>{Имя порта}</Name>

</Source>

<Sink>

<Id>{Идентификационный номер приёмника}</Id>

<Name>{Имя порта}</Name>

</Sink>

</Connection>

</Connections>

5.7 Выходные данные

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

5.8 Текст программы

Для разработки данной программной системы использовались [7, 17].

Исходный текст основных модулей программы приведен в приложении Б.

6. МЕТОДИКА ОТЛАДКИ И ТЕСТИРОВАНИЯ

6.1 Объект испытаний

Объектом испытаний является программно-аппаратная система генерации сигналов с заданными параметрами.

6.2 Цель испытаний

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

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

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

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

Требования к программной документации заданы не были.

6.5 Средства и порядок испытаний

На первом этапе тестируются основные модули программной системы. Для этого используется платформа Microsoft Unit Testing Framework, которая входит в состав среды разработки Visual Studio.

На втором этапе тестируется правильность работы программно-аппаратной системы. Средством тестирования является следующее программное обеспечение: Virtual Audio Cable и Audacity.

6.6 Методы испытаний

Модульное тестирование

Описание

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

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

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

При этом в ходе модульного тестирования решаются следующие основные задачи:

- поиск и документирование несоответствий требованиям;

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

- поддержка рефакторинга модулей;

- поддержка устранения дефектов и отладки.

Тестирование

Протестируем подсистему загрузки схемы из файла. Для этого воспользуемся модульным тестом «\Tests\SchemeTest\», который приведен в приложении В. Откроем проект в среде разработки Visual Studio. Переходим на проект «Tests», выделяем модульный тест и выполняем «Run All Tests».

Рисунок 6.1 -- Окно сессии тестирования

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

Тестирование методом «черного ящика»

Описание

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

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

Virtual Audio Cable - виртуальный звуковой кабель (VAC) представляет собой звуковой драйвер Windows, создающий в системе два звуковых порта: Virtual Cable In и Virtual Cable Out. К каждому из портов может быть присоединено любое количество приложений. Звуковые сигналы, выводимые приложениями в порт Out, смешиваются в единый сигнал, который затем передается всем приложениям, извлекающим звук из порта In. От приложений требуется лишь умение работать со стандартными Wave-устройствами Windows .

Audacity -- свободный, простой в использовании звуковой редактор для Windows, Mac OS X, GNU/Linux и других операционных систем. Audacity можно использовать для:

- записи звука;

- оцифровки аналоговых записей (кассет, грампластинок);

- редактирования файлов в форматах Ogg Vorbis, MP3 и WAV;

- физического редактирования нескольких файлов (вырезание, склейка, сведение);

- изменения скорости и высоты тона записи.

Тестирование

Проверим правильность работы правильности работы программно-аппаратной системы. Для этого соберем простейшую схему генератора (рисунок 6.2).

Рисунок 6.2 -- Простейшая схема генератора с настройками

Параметры элемента: «Waveform Generator»:

- частота дискретизации: 44100 Гц;

- амплитуда: 50%;

- частота: 2500 Гц;

- форма сигнала: синусоидальный.

Параметры элемента «Audio Output»:

- устройства вывода: Line 1 (Virtual Audio Cable).

Запускаем интерпретацию. Затем запускаем Audacity и начинаем запись с порта Line 1 (Virtual Audio Cable). По полученными данным строим спектрограмму.

Рисунок 6.3 -- Частотный анализ

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

7. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

7.1 Назначение программы

Программно-аппаратная система генерации сигналов с заданными параметрами может быть использована для тестирования работоспособности радиоэлектронных и акустических устройств, управления промышленными системами (например, системой промывки инжекторов в автомобильных мастерских), а также в учебном процессе СевНТУ.

7.2 Условия выполнения программы

Минимальные системные требования:

- операционная система Windows XP;

- .NET Framework 4;

- видеокарта c поддержкой DirectX;

- процессор 1 ГГц;

- ОЗУ 512 МБ;

- звуковая карта.

7.3 Выполнение программы

Главное окно приложения

После запуска приложения пользователю отображается пустое приложение (рисунок 7.1). После чего ему предоставляются следующие возможные операции:

- создать файл со схемой генератора;

- открыть файл со схемой генератора;

- выход.

Рисунок 7.1 -- Главное окно программы

Начало работы с приложением

Сразу после старта приложения пользователь может разместить элементы схемы генератора. Элемент можно добавить непосредственным перетаскиванием (Drag&Drop) на видимую зону редактора.

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

Рисунок 7.2 -- Окно настроек элемента «Audio Output»

Открытие ранее созданной схемы

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

Рисунок 7.3 -- Простейшая схема генератора

Дополнительные функции

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

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

7.4 Сообщения оператору

При открытии файла с некорректным файлом схемы пользователь увидит сообщение:

Рисунок 7.4 -- Некорректный формат схемы

Если пользователь выходит из программы, но при этом он не сохранил изменения, то увидит следующее сообщение:

Рисунок 7.5 -- Изменения не были сохранены

8. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ

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


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.