Рис. 2.4. Псевдокод программы управления стереоусилителем
Теория. Следующий шаг структурного проектирования - написание исходного текста программы на Си, в редких случаях на ассемблере. Причем под написанием программы понимается не только создание исходного текста программы, но и его поэтапная отладка. Отладка может производиться с использованием трех стратегий.
Первая стратегия соответствует методу проектирования сверху вниз. Сначала пишется и отлаживается основная функция (main.c) программы управления. При этом все вызываемые функции симулируются пустыми программными модулями. По мере продвижения сверху вниз, все большее число функций наполняется содержанием, и для них записывается исходный текст программы.
Вторая стратегия соответствует методу проектирования снизу вверх. В соответствие с этим методом сначала пишутся и отлаживаются пока несвязанные функции нижнего уровня. Постепенно разработчик переходит к функциям более высокого уровня, выстраивая иерархические связи в соответствие со структурной схемой.
Третья стратегия сочетает в себе две предыдущие. Попеременно пишутся и отлаживаются функции сверху и снизу структурной схемы. Объединение проекта в целом осуществляется на каком то из средних уровней.
До настоящего времени мы рассматривали все шаги метода структурного проектирования преимущественно в приложении к разработке программного обеспечения встраиваемой системы. Однако эти же этапы в полной мере применимы также к проектированию аппаратного обеспечения системы.
Применение. В проекте контроллера стереоусилителя мы специально разработали аппаратный симулятор, который использовался на этапе отладки программного обеспечения. Этот симулятор состоял из некоторого количества переключателей для имитации органов управления на передней панели стереоусилителя, и светодиодов, которые отображали состояние сгенерированных контроллером сигналов управления. Функциональная схема симулятора приведена на рис. 2.5. С помощью этого симулятора мы провели отладку, а затем поэтапно проверили функционирование разработанной программы. Доктор Парис Нил настоятельно попросил нас проверить программное обеспечение в автоматическом режиме, т.е. без применения программных средств отладки, по каждому из возможных сценариев работы. И только затем мы разместили контроллер в корпусе стереоусилителя и приступили к комплексным испытаниям законченного изделия.
Рис. 2.5. Функциональная схема имитатора для тестирования программы стереоусилителя
Теория. Заключительным этапом метода структурного проектирования является определение критериев, по которым можно будет сделать вывод, что устройство удовлетворяет поставленным техническим требованиям. Это предполагает разработку стратегии верификации, отладки и тестирования разработанного устройства. Программа верификации - это не одно и тоже, что программа тестирования. Тем не менее, тестирование - это значительная часть процесса верификации. Для того, чтобы правильно испытать систему, разрабатывается специальная программа тестирования, которая позволяет полностью проверить режимы работы прибора и их соответствие техническим требованиям. Основной задачей является выявить и зафиксировать имеющиеся ошибки, и очень важно убедиться, что проект соответствует планируемому поведению.
Ошибки в проекте могут быть различной породы. Мы кратко рассмотрим их в порядке возрастания неприятностей от них.
Самыми простыми для устранения являются синтаксические ошибки. Эти ошибки выявляет компилятор в процессе обработки исходного текста программы. Компилятор выдает сообщения двух типов: предупреждения ("Warning") и ошибки ("Error"). Предупреждения выдаются компилятором в тех случаях, когда компилятору "кажется", что некоторые конструкции программы неудачны. При этих ошибках код на выходе компилятора получается. Несмотря на то, что код будет образован, Вы должны будете принять решение по поводу исправления или нет этих мест в программе. Ошибки с сообщением "Error" не позволят Вам создать файл загрузочного модуля, поэтому Вам придется заняться их немедленным устранением. При этом следует знать, что всего лишь одна синтаксическая ошибка может вызвать генерацию сразу нескольких сообщений об ошибках.
Ошибки исполнения в реальном времени можно выявить только в процессе выполнения программы. Они обычно приводят к разрушению алгоритма управления. Например, если Вы при написании текста программы для выполнения задержки на 3 мс неправильно посчитали число отсчетов внутреннего генератора тактирования, то программа будет успешно исполняться, но задержка будет не соответствовать 3 мс. Ошибки исполнения в реальном времени достаточно сложно выявляются. Составление специальной методики тестирования поможет Вам выявить подобные неисправности.
Наиболее неприятный тип ошибок - это неправильные начальные условия для составления программы. В этом случае может получиться, что программа полностью удовлетворяет требованиям, но сами технические требования неправильные. Никакие маленькие коррекции не исправят положения дел. Вот почему мы обязательно должны затратить так много времени на разбор и выработку всех условий работы устройства.
Всеобъемлющее тестирование может использовать технику сверху вниз, когда сначала исследуется общее поведение системы, а затем детали поведения в отдельных режимах. А может наоборот, снизу вверх, когда тестирование начинается с проверки правильного функционирования драйверов периферии. Иногда используется смешанная техника. В любом случае, методика тестирования определяется конкретным проектом. Хороший тест проверяет также живучесть (робастность) программного обеспечения. Под живучестью понимают ситуацию. При которой на вход системы могут поступить не предполагаемые комбинации сигналов, и при этом программное обеспечение должно оставаться работоспособным и формировать сигналы управления, по крайней мере, не создающие аварийной ситуации для исполнительных устройств.
Применение. В процессе тестирования контроллера стереоусилителя были выявлены ситуации, которые не были предусмотрены начальными установками на проектирование программы. Например, если пользователь выбрал устройство для воспроизведения, то предыдущее устройство отключается от входа усилителя, а следующее выбранное подключается. При этом не подумали, а что следует делать контроллеру, если пользователь с пульта управления выбрал то же устройство, которое уже подключено. Контроллер в соответствие со сценарием сначала отсоединял устройство, а затем его же коммутировал опять. Это вызывало неприятные для слуха шумы. Только при тестировании устройства на реальном объекте мы смогли выявить эту неисправность и достаточно просто исправили программу.
Следует заметить, что процесс тестирования занимает много времени, поскольку он многоступенчатый. Если какие либо ошибки обнаружены, то вносятся исправления в исходный текст программы, и все тесты должны быть проведены заново.
Итак, мы закончили свое первое знакомство с методом структурного проектирования. В следующем разделе мы остановимся на вопросах документирования процесса разработки.
2.5.2. Документирование программ
Теория. Многие начинающие программисты уверены, что документирование программного обеспечения проекта - это добавление некоторого количества коротких комментариев к работающей версии программы. Однако хорошее документирование программы значительно важнее самого программного обеспечения. Хорошая документация содержит все разработанные на предыдущих этапах структуры, которые были обсуждены нами в предыдущем разделе. Все эти структуры помогают нам не только закодировать программу, но и содержат информацию о том, как программа работает.
Полная документация на программное обеспечение содержит комментарии, письменное описание принципов построения программы, технические условия на написание программы, исходный текст программы, руководство пользователя, историю разработки программы и ее модификаций. Весь этот набор документов может быть разделен на внешнюю и внутреннюю документацию. Внешняя документация состоит из специально написанного текста, который поясняет, как работает программа. Внутренняя документация включает полный набор читаемых и понимаемых документов, который необходим для легкого исправления кода. Внутренняя документация состоит из комментариев, исходного текста программы, структуры и специальных записей.
Комментарии помогают читателю определить, что программист хотел сделать в любой точке программы. В нашем контроллере стереоусилителя мы имели 4 страницы комментариев, предшествующих программе, которые со всей полнотой описывали работу системы. Мы также написали дополнительные комментарии по алгоритму работы программы, а также описание каждой отдельной функции. Более того, мы комментировали каждую строку исходного текста программы. Это может показаться избыточным. Но чем больше времени затрачено на составление комментариев, тем меньше времени понадобится для поддержания этого кода.
Самодокументирующий код означает, что имена переменных констант и функций выбираются такими, чтобы было интуитивно понятно ее назначение. Например, если функция называется "delay_3ms", то сразу понятно, что функция формирует задержку 3 мс.