Программное обеспечение и его разработка - [83]
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)
Изучим теперь каждый столбец в табл. 5.5 и посмотрим, о чем же они нам рассказывают:
Столбец 1. Описание функции. Насколько это возможно, оно должно говорить само за себя.
Столбец 2. Номер модуля. Пользуясь этим номером, можно получать доступ к описанию модуля, тексту исходной программы и даже к рабочей программе, получающейся из модуля.
Столбец 3. Автор программы.
Таблица 5.5.
| Описание функции | Номер модуля | Автор | Данные поступают от | Данные готовятся для | Вызывает | Вызывается |
|---|---|---|---|---|---|---|
| Программа | 848А | Дэниэлс | 848А | 437 849 Печати | 849 ОС Планировщик | |
| Программа печати чеков | 852 | Шварц | 849 | Нет | Возврат | 831 |
| Расчет профвзносов | 857 | Трэверс | 839 | 858 | 858 | 852 |
| Калькуляция | 1612 | Уард | 442 857 | 894 1631 | 1614 | 1610 |
| Печать калькуляции | 1614 | Уард | 1612 | Нет | Возврат | 1612 |
Столбец 4. Какие модули или устройства формируют данные, используемые в данном модуле; имеются в виду непосредственные источники, а не вся их совокупность.
Столбец 5. Какие модули или устройства получают данные от данного модуля.
Столбец 6. Каким модулям может передаваться управление из данного модуля.
Столбец 7. Каким модулем вызывается данный.
Подобная автоматизированная система позволяет упорядочить и отрегулировать процесс обнаружения и устранения ошибок. Если размеры системы доходят до нескольких сотен тысяч строк текста программ и больше, число модулей и функций может достигать не одной тысячи. Автоматизированная система становится совершенно необходимой.
