Изучим теперь каждый столбец в табл. 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. Каким модулем вызывается данный.
Подобная автоматизированная система позволяет упорядочить и отрегулировать процесс обнаружения и устранения ошибок. Если размеры системы доходят до нескольких сотен тысяч строк текста программ и больше, число модулей и функций может достигать не одной тысячи. Автоматизированная система становится совершенно необходимой.
К счастью, в настоящее время уже существует множество инструментальных программ, помогающих нам проводить отслеживание требуемой информации, обеспечивающих легкий доступ к ней и возможности модификаций. И опять при разработке программ приходят на помощь вычислительные машины.
Документация должна в точности соответствовать тем целям, для которых создавалось программное обеспечение. Если программы будут работать на 500 машинах, на борту каждого корабля ВМФ США, их надо документировать более тщательно, чем программы, используемые лишь однажды и затем выбрасываемые. Документацию для этих последних программ можно составлять на оборотной стороне конверта.
Если пользователей у программы нет, составлять пользовательскую документацию не следует. Звучит это довольна глупо, но почему-то часто все-таки случается. В «Стандартах» отмечена необходимость пользовательской документации, т. е. документов, в которых говорится о том-то и том-то, поэтому руководство требует, чтобы эти документы составлялись. И вот создается двухметровая кипа документов, ни один из которых ни разу не будет использован.
Блок-схемы больше не считаются необходимыми при составлении документации, за исключением самых высоких уровней. Готовить их трудно: в клеточки блок-схем можно вписывать весьма ограниченные сведения, занимают блок-схемы много страниц, они редко поддерживаются на уровне самых новых версий. Блок-схемы могут оказать полезную помощь при проектировании, но не при документировании.
Занесение в документацию сведений о причинах принятия тех или иных решений при проектировании оказывается исключительно полезным, когда приходит время вносить в программы исправления. Почему они выбрали именно такое построение? Намеренно ли был выбран определенный путь решения определенных вещей? Почему? Если такие решения хорошо задокументировать, они помогут вносящим изменения избежать дорогостоящих ошибок. На этой стадии история проекта и заметки по решениям, принятым в проекте, могут быть очень полезными.