Джозеф Фокс - Программное обеспечение и его разработка

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)

Изучим теперь каждый столбец в табл. 5.5 и посмотрим, о чем же они нам рассказывают:

Столбец 1. Описание функции. Насколько это возможно, оно должно говорить само за себя.

Столбец 2. Номер модуля. Пользуясь этим номером, можно получать доступ к описанию модуля, тексту исходной программы и даже к рабочей программе, получающейся из модуля.

Столбец 3. Автор программы.

Таблица 5.5.

Столбец 4. Какие модули или устройства формируют данные, используемые в данном модуле; имеются в виду непосредственные источники , а не вся их совокупность.

Столбец 5. Какие модули или устройства получают данные от данного модуля.