Структурное программирование дает рекомендации о том, каким должен быть текст модуля, но остается вопрос «как построить такой текст?». В некоторых случаях программирование модуля начинают с построения блок-схемы, однако, их использование не рекомендуется. С одной стороны, блок-схема наглядно представляет логику работы модуля, но при кодировании возникают специфические ошибки. Причина этого состоит в том, что двухмерная блок-схема преобразуется к линейному тексту программы, что требует сохранения высокого уровня внимания при разработке модуля и его сравнения с блок-схемой. Исключением могут быть случаи, когда для построения блок-схем используется специализированный графический редактор и все операторы блок-схемы формализованы настолько, что текст генерируется автоматически.
На первом шаге описывается общая схема работы модуля в обозримой линейно-текстовой форме с использованием крупных понятий. На этом шаге формализация производится лишь частично и ориентирована на восприятие человеком, на каждом последующем шаге производится уточнение и детализация одного из понятий. В результате такого шага создается описание понятия в терминах базового языка программирования, либо в такой же неформализованной форме, но с более узкими понятиями. Процесс завершается лишь тогда, когда все понятия будут формализованы в терминах языка программирования (переведены в конкретные команды). Пошаговая детализация связана с использованием частично формализованного языка для представления указанных описаний и называется «псевдокод». Этот язык позволяет использовать все конструкции структурного программирования и оформляется формализовано вместе с неформальными фрагментами на естественном языке. В качестве обобщенного оператора могут использоваться фрагменты на базовом языке программирования.
Неформальное обозначение обобщенного оператора на псевдокоде производится произвольным предложением на естественном языке. Единственное обращение должно занимать целиком одно или несколько графических строк и завершаться точкой. Для каждого неформального обобщенного оператора должно быть создано отдельное описание, детализирующее его содержание.
Основные конструкции структурного программирования на псевдокоде выглядят следующим образом:
Следование
Обобщенный_оператор;
Обобщенный_оператор;
Развлетвление:
ЕСЛИ условие ТО
Обобщенный_оператор
ИНАЧЕ
Обощенный_оператор
ВСЕ ЕСЛИ
Повторение
ПОКА условие ДЕЛАТЬ
Обобщенный_оператор
ВСЕ ПОКА.
Применяются следующие методы программного контроля:
Статическая проверка текста модуля – здесь текст программы прочитывается от начала до конца с целью обнаружения ошибок. Обычно кроме разработчика модуля к проверке могут приобщать других программистов. Обнаруженные ошибки рекомендуется исправлять только лишь по завершению проверки модуля.
Представляет собой один из видов динамического контроля. Осуществляется с помощью ручного прокручивания всех команд модуля на некотором наборе тестов.
Доказательство свойств программного модуля – это математическое обоснование характеристик модуля. В настоящее время применяется крайне редко.
Отладка ПС – деятельность, направленная на обнаружение и исправление ошибок с использованием процессов выполнения его программ.
Тестирование ПС – процесс выполнения программ на некотором наборе данных, для которого заранее известен результат либо правило поведения программы. Набор соответствующих данных называется тестом или тестовым набором.
Таким образом отладку можно представить в виде многократного повторения 3х процессов:
Тестирование. В результате может быть констатирование наличие ошибки, также место ошибки.
Поиск ошибок. На предыдущем этапе можно локализовать ошибку исходя из того какой результат был получен.
Редактирование. Процесс исправления ошибок.
В большинстве литературных источников тестирование и отладка считается синонимом. Успех отладки. Проверяется рациональным организацией тестирование. При отладке отыскиваются и устраняются те ошибки, наличие которых было подтверждено тестированием. Как отличалось ранее тестирование не может доказать правильность ПС, поэтому нельзя гарантировать, что тестированием можно устранить все ошибки. Поэтому возникает 2 проблемы:
Подготовка такого набора тестов, чтобы можно было обнаружить максимальное количество ошибок.
Чем дольше продолжается тестирование, тем больше ошибок можно выявить, однако, это ведет к удорожанию программного средства, поэтому необходимо установить тот момент, когда необходимо прекратить тестирование.
Признаком окончания отладки является полнота охвата тестов, они должны охватить множество различных ситуаций возникающих при выполнении программ, при этом на последнем отрезке тестирования ошибки должны появляться крайне редко.
Проектирование тестов можно начинать после этапа внешнего описания ПС. При выработке стратегии подготовки тестов можно использовать разные подходы. Существует 2 крайних подхода: один из них заключается в том, что тесты проектируются только на основании изучения спецификации ПС (внешнее описание, архитектуры и т.д.), модули при этом рассматриваются как черные ящики. Такой подход требует полного перебора всех наборов входных данных, однако, такое тестирование практически неосуществимо. Второй подход заключается на основе изучения текстов программ с целью протестировать все пути выполнения каждой программы. Наличие в программах циклов с переменным числом повторений также усложняет тестирование, поскольку надо протестировать каждое прохождение цикла. Оптимальная стратегия заключается в компромиссе между двумя этими подходами, но ближе к первому подходу. Такая стратегия включает в себя проектирование тестов исходя из следующих принципов:
На каждую использованную функцию или возможность должен быть хотя бы один тест.
На каждую область и на каждую границу изменения какой-либо величины хотя бы один тест.
На каждую исключительную ситуацию, указанную в спецификации, хотя бы один тест.
Также требуется, чтобы проектирование тестов учитывало тексты программ, в частности должно выполниться следующее условие: каждая команда программного средства должна быть задействована хотя бы в одном тесте (все операторы должны быть задействованы) – это минимальные требования.
Оптимальную стратегию тестов можно конкретизировать с помощью следующего принципа, а именно, для каждого программного документа должны проектироваться свои тесты с целью выявления в нем ошибок. В российском стандарте различают 2 вида отладки:
Автономная отладка – это тестирование только одной части программы. Она включает в себя отдельную отладку каждого модуля, а также отладку с сопряжением модулей.
Комплексная отладка – это тестирование программного средства в целом, а также в сопровождающихся документах.
На практике выполняются оба вида отладки. Сначала выполняется автономная отладка каждого модуля, затем отладка всего программного средства после сборки.
На практике наблюдается следующий феномен, подтверждающий важность предупреждения ошибок на предыдущих этапах разработки, а именно что это за феномены:
По мере роста числа обнаруженных и исправленных ошибок растет относительная вероятность существования необнаруженных ошибок. Это связано с тем, что при росте числа ошибок, обнаруженных в ПС уточняется и наше представление об общем числе допущенных ошибок и следовательно о числе необнаруженных ошибок.
Существует 6 правил по организации отладки ПС.
Тестирование – ключевая задача разработки ПС, поэтому поручается наиболее квалифицированным программистам. Не желательно тестировать свою собственную программу.
Наиболее хорош тот тест, который обнаруживает ошибку, а не демонстрирует правильную работу программы.
Необходимо готовить тесты как для правильных, так и для неправильных данных.
Документируйте пропуск всех тестов через программу и детально изучайте результаты каждого теста.
Каждый модуль подключается к программе только один раз, именно так, как это необходимо для работы. Никогда не меняйте программу для облегчения тестирования.
Необходимо пропускать все тесты заново, если в программу были внесены изменения.
При автономной отладке каждый модуль на самом деле тестируется в некотором программном окружении. Это окружение состоит из других модулей, часть из которых это уже отлаженные модули, а другая часть – это модули, управляющие отладкой, в частности, отладочные модули. Таким образом, при автономной отладке всегда тестируется некоторая программа, специально построенная для отлаживаемого модуля. Это программа лишь частично совпадает с целевой программой.
По мере продвижения отладки все большую часть окружения отлаживаемого модуля будут составлять уже отлаженные модули. А при отладке последнего модуля, его окружение будет целиком состоять из целевой программы, без отладочных модулей. Такой процесс наращивания отлаживаемой программы называется «интеграция программы».
При восходящем тестировании окружение отлаживаемого модуля будет содержать только один отладочный модуль, который будет головным и называется ведущим модулем или драйвером. Отладочный модуль подготавливает информационную среду для отлаживаемого модуля и осуществляет обращение к этому модулю. При отладке одного модуля для разных тестов могут составляться разные ведущие отладочные модули.
При нисходящем тестировании окружение отлаживаемого модуля составляют имитаторы всех модулей, которые являются отладочными. Некоторые из этих имитаторов могут изменяться для разных тестов.
Восходящее и нисходящее тестирование имеет свои достоинства и недостатки.
Восходящее тестирование. Достоинства: простота подготовки текстов и возможность полной реализации планов тестирования модулей, это связано с тем, что тестовое задание готовится непосредственно перед обращением к отлаживаемому модулю. Недостатки: тестовое задание готовится не в той форме, которая рассчитана на реальную работу программы; большой объем отладочного программирования, т.е. проверяются все возможные варианты исходных данных, даже те, которые в принципе не могут появится в реальной программе; необходимость тестирования сопряжения модулей, т.е. сначала проверяется сам модуль, но сопряжение с другими модулями не тестируется, это возможно только лишь после отладки других модулей.
Нисходящее тестирование. Достоинства: большинство тестов готовится в форме, соответствующих реальному использованию программы; во многих случаях объем тестов небольшой, а имитаторы модулей очень просты и пригодны для большого числа тестов; отпадает необходимость тестирования сопряжения модулей. Недостатки: тестовое задание для модуля готовится косвенно, оно является результатом применения уже отлаженных модулей к тестовым данным, т.е. чтобы определить состояния информационной среды для проверяемого модуля нужно учитывать, как это состояние будет обработано другими модулями.
Автономное тестирование целесообразно осуществлять в 4 последовательных шага:
C#
Многострочный комментарий можно использовать в несколько строк только отдельно от других команд.
Встроенный комментарий нужно применять осторожно, он ухудшает читабельность кода, однако, удобен при отладке. Если символы комментариев будут включены внутри строковых литералов, то они комментарием не являются (например, string s = “ /* это простой текст */ “;)
При написании программного кода, все комментарии подсвечиваются зеленым цветом.
Каждый XML комментарий начинается с трех символов слеша (///). Первые два слеша указывают, что это комментарий и запрещает компилятору его обрабатывать. А третий слеш сообщает синтаксическому анализатору, что это XML комментарий. Когда разработчик набирает 3 символа слеша подряд, то интегрированная среда разработки (IDE) проверяет не предшествует ли она распознаваемому типу, если да, то IDE автоматически вставляет некоторые теги, после чего разработчик сам может теги убрать или добавить другие.
XML-теги бывают следующих видов
/// <remarks> - ремарка класса
/// текст
/// </remarks>
Рекомендуется применять тег для описания типа. Автоматически <remarks> не вставляется (его нужно вставлять вручную).
<summary> - он описывает элементы типа, включая методы свойства и поля. Как правильно он идет сразу за <remarks>
<remarks> описывает тип, а <summary> описывает элементы или экземпляры этого типа, а также структуру типа
<example> выделяет пример использования элемента. В качестве примера может быть фрагмент кода. Если используется пример программного кода, то используется дополнительный тег <code>.
<exception cref=”Sample Exception”> документирует исключения, которые генерирует документ (например, деление на 0). Для описания нескольких исключений используют несколько таких тегов (сколько исключений, столько и таких тегов). Тег имеет атрибут cref его значение – это имя исключения, хотя исключения можно необязательно писать латиницей.
<param name=”strFilePath”> описывает параметры метода или свойства (аргументы подпрограмм). Имеет параметр name, его значение должно совпадать с именем аргумента. Количество таких тегов должно быть равно количеству параметров.
<permission cref=”….”> разрешение на доступ к элементам (содержит описание разрешения). Это может быть информация о виде разрешения на доступ, например, открытый элемент/закрытый элемент/защищенный элемент), область видимости и т.д. Требований к значениям в этом теге нет. Описывается как ссылка на элемент или поле, доступный из текущей среды компиляции.
<returns> описывает возвращаемое значение метода или свойства. В случае методов, применяется только к функциям (например, sin).
<seealso cref=”….”/> указываются прочие ссылки по тематическому разделу. Содержит только атрибут cref со ссылкой на нужный символ.
<include file=’MyXML.xml’
path = ‘doc/members />