Программное обеспечение и его разработка

ENDIF

ENDIF

END-WHILE

END PROCEDURE-OUTPUT INTERRUPT

Рис. 5.52. Структурированное описание на языке проектирования программ.

На рис. 5.52 приведено структурированное словесное описание, для которого использован язык проектирования программ PDL. Это описание эквивалентно нескольким блок-схемам, которые изображены на рис. 5.53. Словесное описание лучше блок-схем по следующим причинам:

1) оно располагается на одной странице, и его общая структура легко обозрима;

2) оно содержит больше информации, чем блок-схемы.

На рис. 5.54 приведено другое описание с гораздо большим числом комментариев.

Рис. 5.53. Блок-схемы.

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)