МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Институт математики и компьютерных наук
Кафедра математики и информатики
Курсовая работа
По дисциплине: «Основыпрограммирования»
На тему:
Этапы разработки программ.Тестирование и отладка. Документирование программ
Тюмень,2010
Оглавление
Введение
Глава1. Этапы разработки программ
1.1Постановка задачи
1.1.1Формулировка и анализ физической задачи
1.1.2.Составление математической модели
1.1.3Составление алгоритма задачи
1.2Создание программы
1.2.1Составление текста программы
1.2.2Синтаксическая отладка программы
1.2.3Тестирование и семантическая отладка
1.3Документирование программы
1.3.1Пользовательская документация программы
1.3.2Документация по сопровождению программы
1.4Запуск готовой программы и анализ полученных результатов
Введение
Внедрениеэлектронно-вычислительных машин, современных средств переработки и передачиинформации послужило началом нового процесса, называемым информатизациейобщества. Широкое распространение получил научно-технический прогресс. Внастоящее время одним из направлений научно-технического прогресса являетсякомпьютеризация практически всех сфер человеческой деятельности.
Сейчас компьютерявляется неотъемлемой частью работы людей. Компьютеры используются в школах иуниверситетах. Они помогают систематизации полученные данных, как в рабочихцелях, так и в учебных. Но, ни один компьютер не обходится без программ ипрограммных обеспечений.
Целью данной курсовойработы является рассмотрение не маловажной, для начинающих программистов, темы- «Этапы создания программы». Практическое применение теоретических навыковбыло опробовано в процессе написания программного приложения — игра «Виселица».Что также стало целью данной курсовой.
Глава1. Этапы разработки программ
Разработка программы – это не только написаниепрограммы. Написание программы является одним из этапов. Для начала перечислимвсе этапы разработки программ, а затем подробно расскажем о них.
Этапы разработкипрограмм:
1. Постановказадачи
1. Формулировкаи анализ физической задачи
2. Составлениематематической модели
3. Составлениеалгоритма задачи
2. Созданиепрограммы
1. Составлениетекста программы
2. Вводтекста программы в компьютер
3. Синтаксическаяотладка программы
4. Тестированиеи семантическая отладка
5. Документированиепрограммы
3. Запускготовой программы и анализ полученных результатов
Рассмотрим подробнокаждый этап.1.1 Постановка задачи
Первый этап — это этап разбора задачи по кусочкам, дляупрощения написания программы. Его ещё называют математическим этапом./>1.1.1Формулировка и анализ физическойзадачи
Формулировка задачи– это само её объявление, её постановка.
Но просто формулировка ничем не поможет программистам.Для этого и существует второй подэтап – это анализ задачи.
Анализ задачи –это подробный просмотр задачи с определением и выявлением входной и выходнойинформации. (Входная информация по задаче — это данные, поступающие навход задачи и используемые для её решения. Выходная информация – эторезультат.)
После проведения анализа поставленнойзадачи программисту более или менее понятно, с какими проблемами ему придетсястолкнуться.1.1.2Составление математической модели
Начнем опять же с определения. Для более четкогопонимания рассмотрим определения математической модели, объявленные в разных(математических, физических, экономических и т.д.) источниках и попробуемсоздать собственное определение, подходящее для программирования.
«Математическаямодель — система уравнений и концепций, используемых для описания ипрогнозирования данного феномена или поведения объекта. Математические моделинаходят как практическое, так и теоретическое применение (иногда одновременно).Практические задачи, в которых используются математические модели, включаютсоздание новых материалов, предсказание погоды, проверку прочности мостов,самолетов и тому подобного» — это определение используется в физике, химии иматематической биологии.
«Математическаямодель — это упрощенное описание реальности с помощью математическихпонятий. Существует два основных класса задач, связанных с математическимимоделями: прямые и обратные. В первом случае все параметры модели считаютсяизвестными, и нам остается только исследовать её поведение. А во второмкакие-то параметры модели неизвестны, и требуется их найти, сопоставляяповедение реальной системы с её моделью.» — данное определение используется восновном в экономике.
«Математическаямодель — это математическое представление реальности» — это определениесозданное математиками.
Делаем выводы: математическаямодель в программировании – это система математических соотношений,приближенно отражающий сформулированную задачу. И она позволяет осуществитьпредварительный выбор оптимальных вариантов решений по определенным критериям.
Создание математическоймодели не займет у нас много времени, т.к. мы должны были подробно разобратьзадачу по предыдущему пункту./>1.1.3 Составление алгоритма задачи
Изначально появлениеалгоритма связывают с возникновением математики. Алгоритм – описаниепоследовательности действий (план), строгое исполнение которых приводит крешению поставленной задачи за конечное число шагов.
У алгоритма есть 2обязательных условия:
· Алгоритмдолжен быть представлен в форме, понятной человеку, который его разрабатывает.
· Алгоритмдолжен быть представлен в форме, понятной тому объекту (в том числе ичеловеку), который будет выполнять описанные в алгоритме действия.
Так же у алгоритмовесть свойства:
1. Дискретность,т. е. алгоритм должен состоять из конкретных действий, следующих в определенномпорядке.
2. Детерминированность,т. е. любое действие должно быть строго и недвусмысленно определено в каждомслучае.
3. Конечность,т. е. каждое действие и алгоритм в целом должны иметь возможность завершения.
4. Массовость,т. е. один и тот же алгоритм можно использовать с разными исходными данными.
5. Результативность,т. е. отсутствие ошибок, алгоритм должен приводить к правильному результату длявсех допустимых входных значениях.
В мире существует нескольковидов алгоритмов:
· Линейныйалгоритм (описание действий, которые выполняются однократно в заданномпорядке);
· Циклическийалгоритм (описание действий, которые должны повторятся указанное число раз илипока не выполнено условие);
· Разветвляющийалгоритм (алгоритм, в котором в зависимости от условия выполняется либо одна,либо другая последовательность действий); 1.2Создание программы
Процесс созданиепрограммы, а точнее разработка программного обеспечения – это второй этапсоздания программы.1.2.1 Составлениетекста программы
Это, наверное, самыйсложный из этапов, требующий наибольшего внимания. По сути, составление текстапрограммы – это запись алгоритма задачи при помощи одного из языков программирования.Чтобы этот текст был понятен пользователю и составителю, используютсякомментарии.1.2.2 Синтаксическаяотладка программы
Отладка программы— это специальный этап в разработке программы, состоящий в выявлении и устранениипрограммных ошибок, факт существования которых уже установлен.
Синтаксическая отладка– поиск синтаксических ошибок в тексте программы. Обнаружив ошибку, трансляторвыводит сообщение, указывая на место ошибки в программе и ее характер. Получивтакое сообщение, программист должен исправить ошибку и снова повторитьтрансляцию. Так продолжается до тех пор, пока не будут исправлены всесинтаксические ошибки.
Если вы сталкиваетесь ссинтаксической ошибкой, то чаще всего вы можете решить проблему с помощьюсправочной системы, из которой можно получить дополнительную информацию обошибке, и исправить эту ошибку, уделив дополнительное внимание точномусинтаксису используемых вами функций, объектов, методов и свойств./>1.2.3 Тестирование и семантическаяотладка
Тестирование – этодинамический контроль программы, т.е. проверка правильности программы при еевыполнении на компьютере.
Каждому программистуизвестно, сколько времени и сил уходит на отладку и тестирование программ. Наэтот этап приходится около 50% общей стоимости разработки программногообеспечения. Но не каждый из разработчиков программных средств может верно,определить цель тестирования. Нередко можно услышать, что тестирование — этопроцесс выполнения программы с целью обнаружения в ней ошибок. Но эта цельнедостижима: ни какое самое тщательное тестирование не дает гарантии, чтопрограмма не содержит ошибок. Другое определение: это процесс выполненияпрограммы с целью обнаружения в ней ошибок. Отсюда ясно, что “удачным” тестомявляется такой, на котором выполнение программы завершилось с ошибкой.Напротив, “неудачным” можно назвать тест, не позволивший выявить ошибку впрограмме. Определение также указывает на объективную трудность тестирования:это деструктивный ( т.е. обратный созидательному ) процесс. Посколькупрограммирование — процесс конструктивный, ясно, что большинству разработчиковпрограммных средств сложно “переключиться” при тестировании созданной имипродукции. Основные принципы организации тестирования:
1. необходимойчастью каждого теста должно являться описание ожидаемых результатов работыпрограммы, чтобы можно было быстро выяснить наличие или отсутствие ошибки вней;
2. следуетпо возможности избегать тестирования программы ее автором, т.к. кроме уже указаннойобъективной сложности тестирования для программистов здесь присутствует и тотфактор, что обнаружение недостатков в своей деятельности противоречитчеловеческой психологии (однако отладка программы эффективнее всего выполняетсяименно автором программы);
3. потем же соображениям организация — разработчик программного обеспечения недолжна “единолично ” его тестировать (должны существовать организации,специализирующиеся на тестировании программных средств);
4. должныявляться правилом доскональное изучение результатов каждого теста, чтобы непропустить малозаметную на поверхностный взгляд ошибку в программе;
5. необходимотщательно подбирать тест не только для правильных (предусмотренных ) входныхданных, но и для неправильных (непредусмотренных);
6. прианализе результатов каждого теста необходимо проверять, не делает ли программатого, что она не должна делать;
7. следуетсохранять использованные тесты (для повышения эффективности повторноготестирования программы после ее модификации или установки у заказчика);
8. тестированияне должно планироваться исходя из предположения, что в программе не будутобнаружены ошибки (в частности, следует выделять для тестирования достаточныевременные и материальные ресурсы);
9. следуетучитывать так называемый “принцип скопления ошибок”: вероятность наличия необнаруженных ошибок в некоторой части программы прямо пропорциональна числуошибок, уже обнаруженных в этой части;
10. следует всегдапомнить, что тестирование — творческий процесс, а не относиться к нему как крутинному занятию.
Существует два основныхвида тестирования: функциональное и структурное. При функциональномтестировании программа рассматривается как “черный ящик” (то есть ее текст неиспользуется). Происходит проверка соответствия поведения программы ее внешнейспецификации. Возможно ли при этом полное тестирование программы? Очевидно, чтокритерием полноты тестирования в этом случае являлся бы перебор всех возможныхзначений входных данных, что невыполнимо.
Поскольку исчерпывающеефункциональное тестирование невозможно, речь может идти о разработки методов,позволяющих подбирать тесты не “вслепую”, а с большой вероятностью обнаруженияошибок в программе. При структурном тестировании программа рассматривается как“белый ящик” (т.е. ее текст открыт для пользования). Происходит проверка логикипрограммы. Полным тестированием в этом случае будет такое, которое приведет кперебору всех возможных путей на графе передач управления программы (ееуправляющем графе). Даже для средних по сложности программ числом таких путейможет достигать десятков тысяч.
Таким образом, ниструктурное, ни функциональное тестирование не может быть исчерпывающим.Рассмотрим подробнее основные этапы тестирования программных комплексов. Втестирование многомодульных программных комплексов можно выделить четыре этапа:
1) тестированиеотдельных модулей;
2) совместноетестирование модулей;
3) тестированиефункций программного комплекса (т.е. поиск различий между разработаннойпрограммой и ее внешней спецификацией );
4) тестированиевсего комплекса в целом (т.е. поиск несоответствия созданного программногопродукта, сформулированным ранее целям проектирования, отраженным обычно втехническом задании).
На первых двух этапахиспользуются, прежде всего, методы структурного тестирования, т.к. напоследующих этапах тестирования эти методы использовать сложнее из-за большихразмеров проверяемого программного обеспечения; последующие этапы тестированияориентированы на обнаружение ошибок различного типа, которые не обязательно связаныс логикой программы.1.2.3.1 Структурноетестирование
Поскольку исчерпывающееструктурное тестирование невозможно, необходимо выбрать такие критерии егополноты, которые допускали бы их простую проверку и облегчали быцеленаправленный подбор тестов.
Наиболее слабым изкритериев полноты структурного тестирования является требование хотя быоднократного выполнения (покрытия) каждого оператора программы. Более сильнымкритерием является так называемый критерий С1: каждая ветвь алгоритма (каждыйпереход) должна быть пройдена (выполнена) хотя бы один раз.
Использование критерияпокрытия условий может вызвать подбор тестов, обеспечивающих переход впрограмме, который пропускается при использовании критерия С1 (например, впрограмме на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO…, применение критерия покрытия условий требует проверки обоих вариантов выходаиз цикла: NOT x и NOT y). С другой стороны покрытие условий может необеспечивать покрытия всех переходов.
Например, конструкцияIF A AND B THEN… требует по критерию покрытия условий двух тестов (например,A=true, B=false и A=false, B=true), при которых может не выполняться оператор,расположенный в then — ветви оператора if. Практически единственным средством,предоставляемым современными системами программирования, является возможностьопределения частоты выполнения различных операторов программы. Но с помощьюэтого инструмента поддержки тестирования можно проверить выполнение толькослабейшего из критериев полноты — покрытие всех операторов. Правда, с помощьюэтого же инструмента можно проверить и выполнение критерия С1. Но для этогопредварительно текст программы должен быть преобразован таким образом, чтобывсе конструкции условного выбора (IF, CASE или SWITCH) содержали ветви ELSE илиDEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиесяна данном тесте, будут “видимы” из таблицы частоты выполнения операторовпреобразованной программы.
Актуальной остаетсязадача создания инструментальных средств, позволяющих:
ü накапливатьинформации о покрытых и непокрытых ветвях для всех использованных тестов;
ü выделятьразработчику еще не покрытые при тестировании участки программы, облегчая выборследующих тестов;
ü поддерживатьболее мощные критерии полноты структурного тестирования.1.2.3.2 Совместимоетестирование модулей
Известны два подхода к совместному тестированиюмодулей: пошаговое и монолитное тестирование. При монолитном тестированиисначала по отдельности тестируются все модули программного комплекса, а затемвсе они объединяются в рабочую программу для комплексного тестирования. Припошаговом тестировании каждый модуль для своего тестирования подключается кнабору уже проверенных модулей.
В первом случае дляавтономного тестирования каждого модуля требуется модуль – драйвер (то естьвспомогательный модуль, имитирующий вызов тестируемого модуля и один илинесколько модулей — заглушек то есть вспомогательных модулей, имитирующихработу модулей, вызываемых из тестируемого). При пошаговом тестировании модули проверяютсяне изолированно друг от друга, поэтому требуются либо только драйверы, либотолько заглушки. При сравнении пошагового и монолитного тестирования можноотметить следующие преимущества первого подхода:
ü меньшаятрудоемкость (при монолитном тестировании требуются 5 драйверов и 5 заглушек;при пошаговом тестировании требуются или только 5 драйверов — если модулиподключаются “снизу вверх ”, — или только 5 заглушек — если модули подключаются“сверху вниз”);
ü болеераннее обнаружение ошибок в интерфейсах между модулями (их сборка начинаетсяраньше, чем при монолитном тестировании);
ü легчеотладка, то есть локализация ошибок (они в основном связаны с последним изподключенных модулей);
ü болеесовершенные результаты тестирования (более тщательная проверка совместногоиспользования модулей).
При использованиипошагового тестирования возможны две стратегии подключения модулей: нисходящаяи восходящая.
Нисходящее тестированиеначинается с главного (или верхнего) модуля программы, а выбор следующегоподключаемого модуля происходит из числа модулей, вызываемых из ужепротестированных.
Одна из основныхпроблем, возникающих при нисходящем тестировании, — создание заглушек. Другаяпроблема, которую необходимо решать при нисходящем тестировании, — форма представлениятестов в программе, так как, как правило, главный модуль получает входныеданные не непосредственно, а через специальные модули ввода, которые притестировании сначала заменяются заглушками. Для передачи в главный модульразных тестов нужно или иметь несколько разных заглушек, или записать эти тестыв файл во внешней памяти и с помощью заглушки считывать их. Поскольку послетестирования главного модуля процесс проверки может продолжаться по-разному,следует придерживаться следующих правил:
a) модули,содержащие операции ввода-вывода, должны подключаться к тестированию как можнораньше;
b) критические(т.е. наиболее важные) для программы в целом модули также должны тестироватьсяв первую очередь.
Основные достоинстванисходящего тестирования: уже на ранней стадии тестирования есть возможностьполучить работающий вариант разрабатываемой программы; быстро могут бытьвыявлены ошибки, связанные с организацией взаимодействия с пользователем.
Проблемы, которые могутвозникать при нисходящем тестировании: появляется соблазн совмещениянисходящего проектирования с тестированием, что, как правило, неразумно, т.к.проектирование — процесс итеративный и в нем неизбежен возврат на верхниеуровни и исправление принятых ранее решений, что обесценивает результаты ужепроведенного тестирования; может возникнуть желание перейти к тестированиюмодуля следующего уровня до завершения тестирования предыдущего по объективнымпричинам (необходимости создания нескольких версий заглушек, использованиямодулями верхнего уровня ресурсов модулей нижних уровней).
При восходящемтестировании проверка программы начинается с терминальных модулей (т.е. тех,которые не вызывают не каких других модулей программы). Эта стратегия во многомпротивоположна нисходящему тестированию (в частности, преимущества становятсянедостатками и наоборот). Нет проблемы выбора следующего подключаемого модуля — учитывается лишь то, чтобы он вызывал только уже протестированные модули. Вотличие от заглушек драйверы не должны иметь несколько версий, поэтому ихразработка в большинстве случаев проще.
Другие достоинствавосходящего тестирования: поскольку нет промежуточных модулей (тестируемыймодуль является для рабочего варианта программы модулем самого верхнегоуровня), нет проблем, связанных с возможностью или трудностью задания тестов;нет возможности совмещения проектирования с тестированием; нет трудностей,вызывающих желание перейти к тестированию следующего модуля, не завершивпроверки предыдущего. Основными недостатком восходящего тестирования являетсято, что проверка всей структуры разрабатываемого программного комплексавозможна только на завершающей стадии тестирования. Хотя однозначного вывода опреимущества той или иной стратегии пошагового тестирования сделать нельзя(нужно учитывать конкретные характеристики тестируемой программы), вбольшинстве случаев более предпочтительным является восходящее тестирование.1.2.3.3Семантическая отладка
Ошибки этапа выполнения илисемантические ошибки происходят, когда вы компилируете полную программу,которая при ее выполнении делает что-то недопустимое. То есть, программасодержит допустимые операторы, но при их выполнении что-то происходит неверно. Например,программа может пытаться открыть для ввода несуществующий файл или выполнитьделение на ноль.
Семантическая отладка — это процесс нахождения и исправления ошибок, связанных с неправильным указаниемлогических страниц данных.
Существует 3 способаотладки программы:
1. Пошаговаяотладка программ с заходом в подпрограммы;
2. Пошаговаяотладка программ с выполнением подпрограммы как одного оператора;
3. Выполнениепрограммы до точки остановки.
Пошаговая отладкапрограмм заключается в том, что выполняется один оператор программы и, затемконтролируются те переменные, на которые должен был воздействовать данныйоператор.
Если в программе имеются уже отлаженные подпрограммы,то подпрограмму можно рассматривать, как один оператор программы ивоспользоваться вторым способом отладки программ.
Если в программесуществует достаточно большой участок программы, уже отлаженный ранее, то егоможно выполнить, не контролируя переменные, на которые он воздействует.Использование точек остановки позволяет пропускать уже отлаженную частьпрограммы. Точка остановки устанавливается в местах, где необходимо проверитьсодержимое переменных или просто проконтролировать, передаётся ли управлениеданному оператору. 1.3Документирование программы
Последней составляющейпроцесса программирования является документирование. Оно включаетширокий спектр описаний, облегчающих процесс программирования и обогащающихрезультирующую программу. Постоянное документирование должно составлятьнеотъемлемую часть каждого шага программирования. Постановка задачи, проектныедокументы, алгоритмы и программы – все это документы. Внутренняя документация,включенная непосредственно в программу, облегчает чтение кода. Назначениеучебного пособия (еще одной формы документации) – научить пользователяприменять новую программу; справочное руководство позволяет ознакомиться с описаниемкоманд программного обеспечения.
При разработкепрограммы создается большой объем разнообразной документации. Она необходимакак средство передачи информации между разработчиками программы, как средствоуправления разработкой программы и как средство передачи пользователяминформации, необходимой для применения и сопровождения программы.1.3.1 Пользовательскаядокументация программы
Пользовательскаядокументация программы объясняет пользователям, как они должны действовать, чтобыиспользовать данную программу. Она необходима, если программа предполагаеткакое-либо взаимодействие с пользователями. К такой документации относятсядокументы, которыми руководствуется пользователь при установке программы.
Составпользовательской документации зависит от аудиторий, на которую ориентированоданное ПО, и от режима использования документов. Аудитория – это пользователи,у которых есть необходимость в определенной пользовательской документации.Хороший пользовательский документ зависит от правильного выбора аудитории, длякоторой он предназначен.
Качествопользовательской документации существенно определяет успех самой программы. Онадолжна быть достаточно просто, понятна и удобна для пользователя. Поэтому нередко к созданию конечного варианта документации не редко привлекаютсяпрофессиональные технические писатели. Кроме того, для обеспечения болеекачественной пользовательской документации разработан ряд стандартов, в которыхпредписывается порядок разработки этой документации.1.3.2Документация по сопровождению программы
Документацияпо сопровождению программы описывает программу с точки зрения её разработки.Эта документация необходима, если программа предполагает изучение того, как онасконструирована.
Сопровождение– это продолжающаяся разработка, поэтому если созданную программусовершенствуют и обновляют не сами её создатели, то чаще всего привлекаютспециальную команду разработчиков – сопроводители. Этой команде придется иметьдело с такой же документацией, с той лишь разницей, что им нужно будет подробнопросматривать и изучать документацию, созданную первоначальными (основными)разработчиками, с той целью, чтоб понять строение и процесс разработкиизменяемой программы, и внести в эту документацию необходимые изменения,повторяя в значительной степени технологический процессы, с помощью которыхсоздавалась первоначальная программа.
Документацияпо сопровождению программы можно разбить на две группы:
1. документация,определяющая строение программ и структур данных программы и технологию ихразработки;
2. документацию,помогающую вносить изменения в программу.
Документацияпервой группы содержит итоговые документы каждого технологического этапаразработки. Она включает следующие документы:
ü Внешнее описание;
ü Описание архитектуры программы,включая внешнюю спецификацию;
ü Описание модульной системы, включаявнешнюю спецификацию каждого включенного модуля;
ü Для каждого модуля — его спецификацияи описание его строения;
ü Тексты модулей на выбранном языкепрограммирования;
Документывторой группы содержат:
ü Руководство по сопровождениюпрограммы, которое описывает известные проблемы вместе с программой, описывает,какие части программы являются аппаратно и программно зависимыми. 1.4Запуск готовой программы и анализ полученных результатов
Послеполученного нами файла с *.exe(обычно) разрешением мы можем запустить его и ещё раз проверить(проанализировать) верно, ли работает программа. На этом этапы созданияпрограммы закончены.