Программное обеспечение и его разработка - [82]
Если пытаться извлечь из тестирования большой системы типа V хотя бы минимальную пользу, оно становится весьма дорогостоящим. С помощью тестирования нельзя плохую программу превратить в хорошую, ее можно только улучшить.
При тестировании следует обращать внимание на граничные случаи, это необходимо, чтобы убедиться, что система работоспособна во всем диапазоне, для которого она проектировалась. При тестировании необходимо вводить в систему неправильные данные, исследуя затем полученные результаты.
Медленно развивающиеся процессы следует тестировать с помощью длительных прогонов (24 ч.).
Люди не очень-то любят составлять документацию на созданную ими продукцию. В то же время документация — это самое важное из того, что они должны сделать! Некий превосходный программист спроектировал и написал программу определения орбитальных характеристик спутника. Он первым закончил программирование, все работало правильно, память попусту не тратилась. Программа была написана на Фортране и занимала около 4 страниц плотного фортрановского текста. Он знал свою программу вдоль и поперек. Через 3 мес. его попросили добавить к своей программе несколько функций. Он достал документацию и принялся ее изучать. Три или четыре дня он пытался понять, что же происходит в его программе! А ведь он ее сам написал! Сколько бы сил он потратил, если бы это была чужая программа! А теперь представьте, что документации не было.
С такой проблемой часто приходится сталкиваться тем, кто занимается продолжающейся разработкой программ. Вместо того чтобы начинать с изучения требований к программе и ее проекта, им слишком часто достается участь детективов и археологов. «Какая была форма — структура — план — путь?» Почему «они» сделали «это»? После этого начинаются исправления, исключения, добавления. Понятно, что чем более четкий оставлен след, тем проще задача, тем лучше результаты.
Наверное, наиболее распространенная в мире история о программировании — это рассказ о том, что программа работает, но ни один человек не знает, как это происходит, поскольку программист давно ушел, а документации нет. Эту историю часто рассказывают, потому что это весьма обычная ситуация.
Документация нам нужна для того, чтобы:
1) напомнить тем, кто создал эту программу, о том, как она устроена;
2) показать тем, кто придет после нас, как устроена программа, каков ее алгоритм.
Многие новые технологии программирования позволяют получать самодокументированные программы, значительно снижая усилия, необходимые для документирования.
Под документацией мы подразумеваем не тексты рабочей (машинной) программы. Недостаточно также и текстов исходной программы. Документация, подготавливаемая для фазы продолжающейся разработки, должна содержать:
1) хорошо прокомментированный текст программы;
2) схемы, иллюстрирующие проект, и словесное их описание;
3) структурированные словесные описания или схемы процессов, причем первое более предпочтительно;
4) описания данных.
Без всего этого программисту, которому предстоит модифицировать существующую программу, придется решать сложнейшую задачу по определению того, что было сделано до него.
Такие описания и читать и понимать легче, чем блок-схемы. Снабженный подробными приложениями, грамотно оформленный, разделенный на модули текст описания усваивается особенно легко, ведь и общая структура текста, и используемые в нем термины вполне понятны любому. Структурированное словесное описание это не программа, но эти понятия близки.
>PROCEDURE: PWARN $ display warning message
>INPUTS:
>LOTMP — time to retry after overtemp condition
>LEMI — time to retry after EMI condition
>LACT — printer queue overflow flag
>OUTPUTS:
>none
>IF LACT set THEN
>IF NOR less than TQR (space unavailable) THEN
>clear LACT
>set LCODE to 134
>call procedure POPMG to display operator message
>ENDIF
>ENDIF
>DO-WHILE LACTX is 0 thru 1
>IF EMI is set and CSRTC is greater than or equal to LEMI(LACTX) THEN
>set LCODE to 321
>call procedure POPMG to display warning message
>store the new retry time in LEMI
>increment retry counter LRCTR
>IF LRCTR greater than or equal 3 THEN
>clear the FM! flan
>ENDIF
>ENDIF
>IF OVRTMP is set and CSRTC greater than or equal LOTMP(LACTX) THEN
>set LCODE to 320
>call procedure POPMG to display warning message
>store new retry time in LOTMP
>increment retry counter LRCTR
>IF LRCTR greater than or equal to 3 THEN
>clear OVRTMP flag
>ENDIF
>ENDIF
>END-WHILE
>END PROCEDURE-OUTPUT INTERRUPT
Рис. 5.52. Структурированное описание на языке проектирования программ.
На рис. 5.52 приведено структурированное словесное описание, для которого использован язык проектирования программ PDL. Это описание эквивалентно нескольким блок-схемам, которые изображены на рис. 5.53. Словесное описание лучше блок-схем по следующим причинам:
