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. Словесное описание лучше блок-схем по следующим причинам:
1) оно располагается на одной странице, и его общая структура легко обозрима;
2) оно содержит больше информации, чем блок-схемы.
На рис. 5.54 приведено другое описание с гораздо большим числом комментариев.
PROC SESSION MANAGEMENT * THIS PROCEDURE MANAGES THE
TERMINAL INTERACTION WITH THE USER. LEGAL USER
COMMANDS ARE MOVE AND DELETE *
USE SESSION DATA
DO * PROCESS USER COMMANDS *
GET INPUT (COMMAND) * NEXT USER INPUT *
RUN INPUTCHECK (COMMAND, ERROR)
IF
ERROR = TRUE
THEN
PUT OUTPUT (ERROR)
ELSE * NO ERROR — PROCEED WITH PROCESSING *
IF * DETERMINE TYPE COMMAND *
COMMAND = MOVE
THEN * PROCESS MOVE COMMAND *
INCLUDE MOVE PROCESSING
ELSE * PROCESS DELETE COMMAND *
INCLUDE DELETE PROCESSING
Fl
Fl GET INPUT (SESSION ~ ON)
WHILE * KEEP PROCESSING INPUT COMMANDS AS LONG
AS SESSION ON INDICATOR IS ON (TRUE) *
SESSION ON = TRUE
OD
CORP
DATA SESSION DATA
*ABSTRACT DATA TYPES & COMMENTS *
ATAD
Рис. 5.54. Структурированное описание.
Служебные слова CORP, OD, FI и ATAD представляют собой «закрывающие скобки» для слов PROC, DO, IF и DATA. Если правила ясны, то документы такого типа читаются очень легко.
Строки типа «IF * ОПРЕДЕЛЕНИЕ ТИПА ПРИКАЗА *» необходимо еще будет переводить на язык, с которого можно осуществлять трансляцию, но уже на этом уровне совершенно ясно, что нужно делать. В совокупности с хорошим общим описанием проекта такого рода документация должна быть вполне достаточна для продолжающейся разработки. Документы этого уровня можно обрабатывать с помощью машин, но транслировать их в рабочую программу еще невозможно.
Знать, что происходит в программе, должны не только люди, занимающиеся сопровождением, но и многие другие.
— Оператору, человеку, нажимающему кнопки в машинном зале, нужно подробно рассказать, что, когда, при каких обстоятельствах делать.
— Пользователь, сидящий за терминалом, является одним из тех, для кого строилась система. Пользователь должен иметь достаточно информации о том, что, как, по чему, когда происходит в системе. Информация должна быть изложена на достаточно понятном уровне.
— Руководителям пользователей необходима документация нескольких разных уровней. Что система делает? Чего она не умеет делать? Что возможно? Легко? Трудно?
— Для управления ходом разработки руководители разработки должны регулярно получать отчеты о состоянии дел и результаты тестирования. Большая часть этих документов в конце концов выбрасывается, поскольку почти вся она подчинена текущему моменту.
— Руководство пользователей должно иметь возможность знакомиться и изучать планы реализации или ввода в эксплуатацию.
— Руководство пользователей должно периодически изучать планы с требованиями на исходные данные. Что нужно от пользователя, чтобы эти данные не устаревали и были правильными? Группа сопровождения должна иметь намного больше разной документации, чем первичные разработчики, ведь ей приходится и модифицировать, и исправлять систему.
Если взглянуть на заднюю панель любой очень большой вычислительной машины, станет очевидно, что нам совершенно необходима схема или хотя бы список, содержащий сведения о каждом проводке из точки XYZ в точку QLR. Это же относится и к программному обеспечению. Рассматривая каждый модуль как отдельную схему, можно сообразить, что нам потребуется отслеживать, кто, что и для кого делает. Но визуально представить себе программу труднее чем электронное устройство. Что такое модуль? В лучшем случае это наименьшая отдельно транслируемая часть программы, но такое толкование крайне изменчиво и в большой степени зависит от авторов. Один модуль может выполнять несколько функций. Для управления нашей большой программной системой нам нужно иметь таблицу привязки функций к модулям, и наоборот. Часто оказывается полезной схема вроде представленной в табл. 5.5 (см. также рис. 5.55)