
Пояснительная записка / 3 ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ
.doc3 Технологический раздел
3.1 Технология разработки программы
3.1.1 Разработка структуры файлов модулей
В соответствии с техническим заданием программа удаления точечных шумов на изображении разработана под ОС Windows для использования в настольном (не сетевом) варианте.
Такие программы могут быть написаны на различных языках программирования, но в настоящее время считается наиболее целесообразным использование языков Object Pascal или C++. При этом, практически все достаточно сложные приложения создаются с использованием систем программирования. В качестве таких систем наиболее широкое применение находят системы программирования С++ Builder и Delphi.
Применение систем программирования существенно изменило технологию разработки программ. Это обусловлено внедрением «языков четвертого поколения» - 4GL (four generation languages), а также поддержка ими систем «быстрой разработки программного обеспечения» - RAD (rapid application development). В данном разделе дипломного проекта использовалась технология разработки программы с использованием системы программирования Delphi [15].
Delphi – одна из самых мощных систем программирования, позволяющих на современном уровне создавать как отдельные прикладные программы под Windows, так и разветвленные комплексы, предназначенные для работы в корпоративных сетях и Internet.
C одной стороны Delphi, совмещая все прогрессивные возможности визуального проектирования и методологии объектно-ориентированного программирования, представляет собой по существу средство автоматизации программирования, позволяющее существенно упростить и ускорить процесс создания проекта [2], с другой – требует от разработчика знаний основных концепций и средств ОС Windows.
Проект Delphi состоит из форм, модулей, установок параметров проекта, ресурсов и т.д. Вся эта информация размещается в файлах. Многие из этих файлов автоматически создаются Delphi при построении приложения. Ресурсы, такие как битовые матрицы, пиктограммы и т.д., находятся в файлах, которые можно получить из других источников или создавать при помощи многочисленных инструментов и редакторов ресурсов, имеющихся в распоряжении. Кроме того, некоторые файлы создаются самим компилятором.
При проектировании приложения, были созданы следующие файлы [19].
1. Файл проекта (.dpr). Этот текстовый файл используется для хранения информации о формах и модулях. В нем содержатся операторы инициализации и запуска программы на выполнение.
2. Файл модуля (.pas). Каждой создаваемой форме соответствует текстовый файл модуля, используемый для хранения кода. Иногда можно создавать модули, не связанные с формами. Многие из функций и процедур Delphi хранятся в модулях.
3. Файл формы (.dfm). Это двоичный или текстовый файл, который создаётся Delphi для хранения информации о формах. Каждому файлу формы соответствует файл модуля (.pas).
4. Файл ресурсов (.res). Этот бинарный файл содержит используемую проектом пиктограмму и прочие ресурсы.
Следующие файлы были созданы непосредственно самим компилятором [19].
1. Исполняемый файл (.exe). Это исполняемый файл приложения. Он является автономным исполняемым файлом, для которого больше ничего не требуется, если только не используются библиотеки, содержащиеся в DLL, OCX и т.д., а также если не используется поддержка пакетов времени выполнения.
2. Объектный файл модуля (.dcu). Это откомпилированный файл модуля (.pas), который компонуется в окончательный исполняемый файл.
Главной частью приложения является файл проекта (.dpr), содержащий код на языке Object Pascal, с которого начинается выполнение программы и который обеспечивает инициализацию других модулей. Этот файл создаётся и модифицируется Delphi автоматически в процессе разработки приложения.
Технология разработки программного обеспечения в дипломном проекте сведена к пошаговому выполнению следующей последовательности действий [15]:
1) составление списка действий, которые должны быть доступны будущему пользователю через разделы меню, инструментальные панели, кнопки и другие элементы управления;
2) составление списка пиктограмм на кнопках в компоненте ImageList для тех действий, которые должны быть доступны из быстрых кнопок инструментальной панели;
3) создание главной формы проекта и перенос на нее компонентов, необходимых для функционирования программы и для реализации интерфейса пользователя;
4) задание свойств каждого компонента на форме: Name (имя), Caption (надпись), Hint (тексты подсказок) и других. При этом для стандартных действий эти характеристики записываются автоматически (при необходимости их необходимо перевести на русский язык или исправить ссылки на не устраивающие стандартные изображения и комбинации горячих клавиш), а для нестандартных – заносятся программистом в процессе разработки программы;
5) написание обработчиков событий для всех нестандартных действий.
3.1.2 Технология разработки интерфейса пользователя
Под графическим интерфейсом пользователя (Graphical User Interface – GUI) понимается тип экранного представления, при котором пользователь может выбирать команды, запускать задачи и просматривать списки файлов, указывая на пиктограммы или пункты в списках меню, показанных на экране. Существует множество рекомендаций по разработке графического интерфейса пользователя, но все они сводятся к реализации двух основных понятий [2]:
- интерфейс должен быть «дружественным» для пользователя (обеспечение необходимой достаточности);
- дизайн используемых окон должен соответствовать психофизиологичес-ким возможностям человека.
В дипломном проекте разработка графического интерфейса осуществлена на основе этой методики. В соответствии с этой методикой графический интерфейс включает следующие элементы:
1) главное меню, реализуемое компонентом MainMenu;
2) инструментальную панель быстрых кнопок, дублирующих основные разделы меню, которая реализуется через компонент ToolBar;
3) контекстное меню, реализуемое компонентом PopupMenu, всплывающее при щелчке пользователя правой кнопкой мыши на том или ином компоненте;
4) последовательность переключения фокуса управляющих элементов;
5) клавиши быстрого доступа ко всем разделам меню и ко всем управляющим элементам, «горячие» клавиши для доступа к основным командам;
6) ярлычки подсказок, всплывающие при перемещении курсора мыши над быстрыми кнопками и иными компонентами;
7) полосу состояния, реализуемую компонентом StatusBar и используемую для развернутых подсказок и выдачи различной информации пользователю;
8) файл справки, темы которого отображаются при нажатии клавиши F1 или при выборе пользователем соответствующего раздела меню;
9) информацию о версии, доступную пользователю при щелчке на пиктограмме приложения правой кнопкой мыши;
10) возможность настройки приложения и запоминания настроек, чтобы при очередном сеансе работы восстанавливались настройки, установленные в предыдущем сеансе;
11) средства установки приложения, регистрации его в Windows и удаления из Windows (для приложений, содержащих не один, а несколько файлов). Для простых программ установка, регистрация и удаление не требует специальных средств.
Разработанная в дипломном проекте программа не относится к сложным и значительная часть пунктов данной методики опущена, но вместе с тем общая последовательность действий при реализации методики сохраняется.
3.1.3 Реализация используемой технологии при создании проекта
Создание проекта осуществлено в интегрированной среде разработки Delphi 7 (IDE – Integrated Development Environment) в следующей последовательности.
1. Запуск Delphi выбором пиктограммы Delphi в разделе меню Windows Пуск/Программы. При этом открывается основное меню IDE (рисунок 3.1). В верхней части окна размещается полоса главного меню, ниже которой – две инструментальные панели: левая содержит два ряда быстрых кнопок, правая – палитру компонентов библиотеки визуальных компонентов. В основном поле окна слева расположены два окна: сверху – Дерево Объектов, под ним - Инспектор Объектов. Правее этих окон располагается окно новой пустой формы, а под ним – окно Редактора Кода.
2. Открытие нового приложения. Выполнить команду (в главном меню IDE выбрать) File/New и в открывшемся каскадном меню выбрать раздел Application.
3. Нанесение на пустую форму всех требуемых компонент управления и отображения информации. В программе использованы такие компоненты Delphi как MainMenu, OpenPictureDialog, SavePictureDialog и другие;
4. Создание названия формы. Выбрать в столбце Properties свойство Caption и ввести название формы, сохранив по умолчанию шрифт и его цвет.
5. Создание панели изображения с помощью компонента ScrollBox (панель с полосами прокрутки) и компонента Image, размещённых на главной форме (рисунок 3.2).
Рисунок 3.1- Основное окно IDE
Рисунок.3.2 – Главная форма приложения
6. Создание панели управления фильтрацией в правой части главной формы (рисунок 3.3) и разместить на ней различные компоненты, такие как списки, поля ввода, кнопки и т.д.
Рисунок.3.3 – Панель управления фильтрацией
7. Создание главного меню.
8. Написание обработчиков событий для различных компонентов. Выделить необходимый компонент на форме, перейти в Инспектор Объектов, открыть в нем страницу событий (Events), найти нужное событие и сделать двойной щелчок в окне справа от имени этого события. Произойдет переход в окно Редактора Кода, представленное на рисунке 3.4. Заголовок этой функции складывается из имени класса формы, имени компонента и имени события без префикса On. Для того, чтобы окно исследователя классов, встроенное в окно Редактора Кода, не мешало дальнейшей работе, его необходимо закрыть, щелкнув на кнопке в его правом верхнем углу. Написать в обработчике между строками begin и end операторы, необходимые для отображения результатной информации.
Рисунок 3.4 - Окно редактора кода
9. Компиляция и выполнение проекта. Компиляция проекта может выполняться несколькими способами. Компиляция с последующим выполнением приложения осуществляется командой меню Run/Run, соответствующей быстрой кнопкой (зеленый треугольник обращенный вправо), или «горячей» клавишей F9. Компиляция и создание модуля .exe осуществляется только в том случае, если при компиляции и компоновке не обнаружены неисправимые ошибки.
Таким образом, технология создания проекта в Delphi включает выполнение следующей последовательности:
1) организация проекта;
2) создание и сохранение проекта;
3) активизация менеджера проектов;
4) планирование работ;
5) создание формы приложения и нанесение на неё необходимых компонентов;
6) написание программных кодов для компонентов;
7) компиляция и отладка приложения;
8) завершение проекта и задание учетной информации.
3.2. Технология тестирования программы
Индустрия программного обеспечения постоянно пытается решить вопрос качества, но насколько значимы ее успехи, на данный момент сказать довольно сложно. В дипломном проекте идет речь о новом поколении инструментов тестирования, которые призваны повысить качество программ. Однако инструменты, даже автоматические, не в состоянии помочь, если их используют неправильно. Поэтому обсуждение инструментов предваряет изложение общих положений «правильного» тестирования.
Качество разрабатываемой программы можно повысить следующим путём: cобрать команду хороших программистов с опытом участия в аналогичных проектах, дать им хорошо поставленную задачу, хорошие инструменты, создать хорошие условия работы. С большой вероятностью можно ожидать, что удастся разработать программную систему с хорошим качеством.
Наиболее дорогие ошибки совершаются на первых фазах жизненного цикла — это ошибки в определении требований, выборе архитектуры, высокоуровневом проектировании. Поэтому надо концентрироваться на поиске ошибок на всех фазах, включая самые ранние, не дожидаясь, пока они обнаружатся при тестировании уже готовой реализации.
Модульному тестированию подвергаются небольшие модули (процедуры, классы и т.п.). При тестировании относительно небольшого модуля размером 100 – 1000 строк есть возможность проверить, если не все, то, по крайней мере, многие логические ветви в реализации, разные пути в графе зависимости данных, граничные значения параметров. В соответствии с этим строятся критерии тестового покрытия (покрыты все операторы, все логические ветви, все граничные точки и т.п.).
Полностью реализованный программный продукт подвергается системному тестированию. На данном этапе тестировщика интересует не корректность реализации отдельных процедур и методов, а вся программа в целом, как ее видит конечный пользователь. Основой для тестов служат общие требования к программе, включая не только корректность реализации функций, но и производительность, время отклика, устойчивость к сбоям, ошибкам пользователя и т.д. Для системного и компонентного тестирования используются специфические виды критериев тестового покрытия (например, покрыты ли все типовые сценарии работы, все сценарии с нештатными ситуациями, попарные композиции сценариев и прочее).
Итак, качество ПС – совокупность наиболее существенных качественных показателей (факторов) в достаточной степени характеризующих ПС. К общим факторам относят [15]:
-
функциональность – как набор функций, реализующих установленные или предполагаемые потребности пользователей;
-
корректность – соответствие реализации системы ее спецификации и непротиворечивости;
-
интерфейс – как средство общения с пользователями системы;
-
открытость – характеризующая модифицируемость системы;
-
комфортность – характеризующая удобность использования ПС;
-
современность – характеризующая степень использования современных информационных технологий представления информации и систем связи на текущий момент времени.
Необходимо также отметить, что проверка достоверности ПС – процесс проведения комплекса мероприятий, исследующих пригодность программы для успешной её эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика.
На основе информации, полученной во время испытаний программы, прежде всего должно быть установлено, что она выполняет декларированные функции, а также должно быть установлено, в какой степени она обладает декларированными примитивами и критериями качества. Таким образом, оценка качества программы является основным содержанием процесса аттестации.
Необходимость и важность тестирования программного обеспечения трудно переоценить. Вместе с тем следует отметить, что тестирование является сложной и трудоемкой деятельностью. Далее рассмотрены особенности тестирования объектно-ориентированного программного обеспечения.
Разработка объектно-ориентированного ПО начинается с создания визуальных моделей, отражающих статические и динамические характеристики будущей системы. Вначале эти модели фиксируют исходные требования заказчика, затем формализуют реализацию этих требований путем выделения объектов, которые взаимодействуют друг с другом посредством передачи сообщений. На конструирование моделей приходится большая часть затрат объектно-ориентированного процесса разработки. Если к этому добавить, что цена устранения ошибки стремительно растет с каждой итерацией разработки, то совершенно логично требование тестировать объектно-ориентированные модели анализа и проектирования.
Критерии тестирования моделей: правильность, полнота, согласованность. О синтаксической правильности судят по правильности использования языка моделирования. О семантической правильности судят по соответствию модели реальным проблемам. Для определения того, отражает ли модель реальный мир, она оценивается экспертами, имеющими знания и опыт в конкретной проблемной области.
О согласованности судят путем рассмотрения противоречий между элементами в модели. Несогласованная модель имеет в одной части представления, которые противоречат представлениям в других частях модели.
При рассмотрении объектно-ориентированного тестирования наименьшим тестируемым элементом является объект (класс). В данном случае нельзя тестировать отдельную операцию изолированно, как это принято в стандартном подходе к тестированию модулей. Любую операцию приходится рассматривать как часть класса. Объектно-ориентированное программное обеспечение не имеет иерархической управляющей структуры, поэтому здесь неприменимы методики как восходящего, так и нисходящего тестирования.
Предлагается две методики тестирования объектно-ориентированных систем:
-
тестирование, основанное на потоках;
-
тестирование, основанное на использовании.
В первой методике объектом тестирования является набор классов, обслуживающих единичный ввод данных в систему. Иными словами, средства обслуживания каждого потока интегрируются и тестируются отдельно. По второй методике вначале тестируются независимые классы. Далее работают с первым слоем зависимых классов, со вторым слоем и т.д.
При проверке правильности исчезают подробности отношений классов. Как и традиционное подтверждение правильности, подтверждение правильности объектно-ориентированного программного обеспечения ориентировано на видимые действия пользователя и распознаваемые пользователем выводы из системы.
После запуска программы на экране отображается главное окно приложения, представленное на рисунке 3.5.
Далее выбирается изображение для восстановления (пункт меню Файл/Открыть). Зашумлённое изображение в этом окне представлено на рисунке 3.6.
Для начала проводится фильтрация всего изображения. Для этого необходимо нажать кнопку «Выделить всё», расположенную в правой панели. Также выбирается размер окна (в данном случае 3х3) и задаются пороговые значения по трём каналам. В данном случае 100 для каждого из трёх каналов RGB.
Рисунок 3.5 – Главное окно приложения
Рисунок 3.6 – Зашумлённое изображение
Для начала фильтрации нужно нажать кнопку «Пуск», расположенную в нижней части панели фильтрации. В случае, если пороговые значения превышают максимально допустимые значения (255), то на экране появляется сообщение «Неверное значение порога». Результат фильтрации представлен на рисунке 3.7.
Рисунок 3.7 – Результат первой фильтрации
Как видно из результата первой фильтрации, некоторые участки были обработаны некорректно, поэтому их нужно фильтровать отдельно с помощью выделения конкретной области изображения. Размер окна остаётся тот же, а пороговые значения задаются поменьше, в данном случае 50 для трёх каналов. Результат конечной фильтрации представлен на рисунке 3.8, из которого следует, что фильтрация изображения прошла успешно. Отсюда следует, что данная программа с поставленной задачей справилась
Рисунок 3.8 – Результат конечной фильтрации