Инженеры, рассматривая сорванные планы программного обеспечения, удивляются вслух, почему программисты не могут работать так, как это делают аппаратчики. Это отчасти обосновано, мы это скоро увидим, но прежде мне хочется отметить, что для крупных программных разработок такой подход скорее неверен.
Аппаратуру можно пощупать, почувствовать, посмотреть. Программное обеспечение абстрактно. Никто и никогда не сможет физически увидеть или потрогать большую программу. Можно подержать в руках распечатку или магнитную ленту, но это всего лишь одно из представлений программы.
Программное обеспечение неосязаемо. Оно еще более неосязаемо, чем художественные фильмы. Представьте себе такой фильм, состоящий из миллионов отдельных кадров, движущихся на высокой скорости через световой луч и проектируемых на экран. Просмотр пленки, полоски шириной 35 или 70 мм или серии фотографий, не означает просмотра фильма. Оценить художественный фильм можно по конечному результату, а результат — это демонстрация на экране. Еще в большей степени подобные рассуждения применимы к программе или программному обеспечению. Статический просмотр написанных или напечатанных команд, хотя и может принести пользу, но не является конечным результатом программы. Конечным результатом можно считать только работающую программу, а не статические представления.
Мы не увидим программы, если она достаточно велика, даже если тысячу раз на нее взглянем. Миллион строк текста программы умещается на двух с половиной километрах бумажной ленты! Будь мы хоть семи пядей во лбу, мы увидим только статическое представление. До своего вступления в действие, до того как она начнет выполняться, ее потоки, взаимодействия, соединения, границы и т. д. невидимы.
Выполняемая программа, так же как и демонстрируемый фильм, непрочна и неуловима. Это серия событий, происходящих во времени. Для воспроизведения программ, изучения ее отдельных частей, их модификации нам необходимы ее статическое представление.
Если бы мы знали, что программа правильна, если бы мы знали, что нам не потребуется ее модифицировать, и, если бы у нас был способ по желанию воспроизводить программу по содержимому памяти, который давал бы нам гарантию не потерять программу, нам не были бы нужны никакие статические представления программ. Для того, чтобы сделать более наглядными большие работающие программные системы, нам нужны новые методы.
Для множества команд, находящихся в памяти машины, нет никаких ограничений на количество вариаций последовательностей или взаимосвязей. Я могу переключить все, что хочу, куда только захочу. Я имею абсолютно полные возможности по изменению взаимосвязей. А так как я еще могу считывать в память дополнительные команды с диска или ленты, у меня практически нет никаких ограничений на количество команд. Последовательности команд в миллион строк становятся в современном мире обычными.
Тирания физических ограничений на взаимосвязи исчезла. Вплоть до появления запоминаемых команд, машинам объясняли, что они должны будут делать, с помощью их собственной физической конструкции. Если у этих машин были возможности по организации условных переходов, их можно было называть специализированными вычислительными машинами. Джон фон Нейман в меморандуме 1946 года указал, что до появления универсальных вычислительных машин, их предшественники «получали инструкции для работы с помощью конструкции». (Курсив мой.)
Физические ограничения запрещали многие возможные ветви или последовательности. Рояль можно считать аппаратурой, у него имеется 88 клавиш. Ноты — это команды пианисту, следуя которым он производит музыкальные звуки, а число различных сочетаний нот неограниченно. А понятие «правильности» весьма субъективно. То, что приятно одному, режет слух другому. Но все это — музыка.
Можно привести и другую аналогию — со словарем (аппаратурой) и романом — представляющим собой взаимосвязанные слова. Словарь точен и ограничен, даже если он очень большой. Но с помощью ограниченного числа слов мы можем написать команды для выполнения любых действий или создать неограниченное число произведений художественной литературы (см. табл. 6.8)
Инженеры учатся строить сложные машины; программисты же не всегда обладают техническими знаниями и не знают множества передовых идей по управлению сложностью. Разработчики программного обеспечения часто передают разработку сложных систем в руки людей, не имеющих никакого опыта в данной области. Такое положение нужно исправлять. Для построения систем управления процессами, нам совершенно необходимы руководители, владеющие техническими дисциплинами.