Можно провести некоторую аналогию с серией фотографий и художественным фильмом. Напечатанная программа столь же плохо отражает действительность, сколь фотография двигателя истребителя или список его составных частей плохо иллюстрирует сам самолет, а набор статичных фотографий плохо представляет художественный фильм.

Тот факт, что программа может одновременно находиться в нескольких формах, оказывается источником путаницы. И не только источником путаницы для новичков, но также источником ошибок в реальных системах, в которых одна форма может подвергаться модификациям, в то время, как другая не изменяется. Через некоторое время при этом путаница может достигнуть невероятных размеров, никто не будет в состоянии понять, какая же версия программы настоящая, (см. рис. 6.25).

Как же так получается, что мы научились создавать большие, невероятно мощные вычислительные машины, работающие очень надежно, но при этом испытываем огромные трудности всякий раз, когда пытаемся создать большую программную систему? Между разработкой программного обеспечения и разработкой аппаратуры имеются значительные различия. Основными среди них можно назвать такие:

1. Доходы от аппаратуры начинают возникать только на фазе производства. Этот длительный систематический процесс начинается сразу после завершения ее разработки. При разработке аппаратуры встречаются те же трудности, что и при разработке программного обеспечения. Разбогатеть на разработке аппаратуры нельзя.

2. Взаимосвязи программного обеспечения неограниченны. Ограничениями аппаратуры являются законы физики. Столько-то объектов могут иметь столько-то взаимосвязей. С программным обеспечением дело обстоит не так.

Фаза разработки продукции состоит именно в том, на что указывает ее название — чтобы достичь желаемого результата вносятся изменения. Это творческая деятельность, не подчиняющаяся дисциплине и предварительным прогнозам. Можно ожидать любых сюрпризов. Этот полный сюрпризов этап наблюдается и при разработке аппаратуры, и при разработке программного обеспечения.

Разработчики аппаратуры не могут предвидеть необходимое им время и требуемые финансовые затраты. Обычно на контрактах по разработке деньги теряются, возмещаясь затем после начала производства. У разработчиков программного обеспечения нет фазы производства.

Инженеры, рассматривая сорванные планы программного обеспечения, удивляются вслух, почему программисты не могут работать так, как это делают аппаратчики. Это отчасти обосновано, мы это скоро увидим, но прежде мне хочется отметить, что для крупных программных разработок такой подход скорее неверен.

Аппаратуру можно пощупать, почувствовать, посмотреть. Программное обеспечение абстрактно. Никто и никогда не сможет физически увидеть или потрогать большую программу. Можно подержать в руках распечатку или магнитную ленту, но это всего лишь одно из представлений программы.

Программное обеспечение неосязаемо. Оно еще более неосязаемо, чем художественные фильмы. Представьте себе такой фильм, состоящий из миллионов отдельных кадров, движущихся на высокой скорости через световой луч и проектируемых на экран. Просмотр пленки, полоски шириной 35 или 70 мм или серии фотографий, не означает просмотра фильма. Оценить художественный фильм можно по конечному результату, а результат — это демонстрация на экране. Еще в большей степени подобные рассуждения применимы к программе или программному обеспечению. Статический просмотр написанных или напечатанных команд, хотя и может принести пользу, но не является конечным результатом программы. Конечным результатом можно считать только работающую программу, а не статические представления.

Мы не увидим программы, если она достаточно велика, даже если тысячу раз на нее взглянем. Миллион строк текста программы умещается на двух с половиной километрах бумажной ленты! Будь мы хоть семи пядей во лбу, мы увидим только статическое представление. До своего вступления в действие, до того как она начнет выполняться, ее потоки, взаимодействия, соединения, границы и т. д. невидимы.

Выполняемая программа, так же как и демонстрируемый фильм, непрочна и неуловима. Это серия событий, происходящих во времени. Для воспроизведения программ, изучения ее отдельных частей, их модификации нам необходимы ее статическое представление.

Если бы мы знали, что программа правильна, если бы мы знали, что нам не потребуется ее модифицировать, и, если бы у нас был способ по желанию воспроизводить программу по содержимому памяти, который давал бы нам гарантию не потерять программу, нам не были бы нужны никакие статические представления программ. Для того, чтобы сделать более наглядными большие работающие программные системы, нам нужны новые методы.

Для множества команд, находящихся в памяти машины, нет никаких ограничений на количество вариаций последовательностей или взаимосвязей. Я могу переключить все, что хочу, куда только захочу. Я имею абсолютно полные возможности по изменению взаимосвязей. А так как я еще могу считывать в память дополнительные команды с диска или ленты, у меня практически нет никаких ограничений на количество команд. Последовательности команд в миллион строк становятся в современном мире обычными.

Тирания физических ограничений на взаимосвязи исчезла. Вплоть до появления запоминаемых команд, машинам объясняли, что они должны будут делать, с помощью их собственной физической конструкции. Если у этих машин были возможности по организации условных переходов, их можно было называть специализированными вычислительными машинами. Джон фон Нейман в меморандуме 1946 года указал, что до появления универсальных вычислительных машин, их предшественники «получали инструкции для работы с помощью конструкции». (Курсив мой.)

Физические ограничения запрещали многие возможные ветви или последовательности. Рояль можно считать аппаратурой, у него имеется 88 клавиш. Ноты — это команды пианисту, следуя которым он производит музыкальные звуки, а число различных сочетаний нот неограниченно. А понятие «правильности» весьма субъективно. То, что приятно одному, режет слух другому. Но все это — музыка.

Можно привести и другую аналогию — со словарем (аппаратурой) и романом — представляющим собой взаимосвязанные слова. Словарь точен и ограничен, даже если он очень большой. Но с помощью ограниченного числа слов мы можем написать команды для выполнения любых действий или создать неограниченное число произведений художественной литературы (см. табл. 6.8)

Инженеры учатся строить сложные машины; программисты же не всегда обладают техническими знаниями и не знают множества передовых идей по управлению сложностью. Разработчики программного обеспечения часто передают разработку сложных систем в руки людей, не имеющих никакого опыта в данной области. Такое положение нужно исправлять. Для построения систем управления процессами, нам совершенно необходимы руководители, владеющие техническими дисциплинами.

Программное обеспечение — это молодая область человеческой деятельности. Практический опыт накапливался не так уж долго, а люди, ведущие практические работы все еще продолжают учиться, как надо управлять этой областью. Терминология наша еще слишком скудна и запутана.

Таблица 6.8. Различия между аппаратурой и ее обеспечением