Программное обеспечение и его разработка
Шрифт:
Тот единственный человек, который является подлинным проектировщиком большой системы, обычно весьма умен, спокоен и упорен. Он достаточно спокоен, чтобы быть хорошим руководителем, достаточно умен, чтобы уметь усвоить множество конфликтующих целей, влияний, методов и противоречий между людьми и разобраться в них.
Если проектированием занимается слишком много людей, если при проектировании слишком увлеклись демократией или если проектировщики начинают сменять друг друга — все это очень сильно затрудняет разработку.
Зрительно представить себе программное обеспечение очень трудно. Статические представления его весьма бледны, но зачастую это лучшее, что нам удается сделать. Рассмотрим пример программного обеспечения системы наземного контроля проекта «Аполлон», это обеспечение работало в Хьюстоне много лет, и оно поможет нам увидеть все, что мы намеревались создать.
У нас была большая (более 1 млн. команд) программная система, хорошо документированная и оттестированная. Все эти команды были распределены по программам, подпрограммам и модулям. Подразделы строились отдельно и включались во внешние структуры.
Наше программное обеспечение «приняло» несколько форм. У нас имелась распечатка (напечатанный на машине текст) всех команд по порядку. Имелись колода перфокарт и магнитная лента, на которой была записана программа. Ни одно из этих воплощений программы человеку увидеть не легко — даже распечатку. Ни одно из них не давало возможность увидеть структуру или последовательность выполнения команд программы. Чтобы понять идею системы, нам требовались такие схемы, как изображенные на рис. 5.19 и 5.20. Вся программная система была разделена на восемь основных частей, что и показано на рис. 5.19.
Назначение каждой подсистемы совершенно ясно из их наименований. Общее управление системой осуществлялось операционной системой реального времени, которая определяла, какую программу надо исполнять в данное время.
Теперь перейдем к более подробному изучению подсистемы запуска (рис. 5.20). Каждый квадратик обозначает очень большую программу, которая при необходимости будет выполнена. Операционная система определяет, когда наступает такая необходимость. Если мы продолжим разбиение этих блоков программного обеспечения на более мелкие детали, мы получим разветвленное дерево, подобное представленному на рис. 5.21. Каждому квадрату соответствует некоторый акт проектирования. Проектирование здесь заключается в выборе конкретной комбинации функций и распределении их между отдельными вполне определенными программами.
Когда мы смотрим на статическое представление программы, подобное дереву на рис. 5.21, мы должны помнить, что каждый квадрат — это программа, которая может быть выполнена в любое время и в самых разных комбинациях с другими программами.
Для наземного контроля системы «Аполлон» было создано более 400 программных модулей. Но все же «познать» программу мы не могли. Диаграмма давала нам лишь безжизненную иллюстрацию. Работающая программа — это нечто совсем другое.
Это все равно что сравнить художественный фильм с пленкой, на которой снят этот фильм. Увидеть пленку без использования кинопроектора не означает еще увидеть фильм! Мы имеем здесь два совершенно разных явления! Слово «пленка» обозначает понятие носителя, на котором заснят фильм; а слово «фильм» связано с самим результатом — объектами, о которых идет речь в фильме. К счастью, в области программного обеспечения такого рода путаница не возникает.
В проектировании можно выделить три части. Принятие решения, структуризацию и представление (описание) (см. рис. 5.22).
ПРИНЯТИЕ РЕШЕНИЯ
Собираемся ли мы организовывать поиск последовательным просмотра файла или хотим применить метод двоичного поиска — настраиваясь сразу на середину файла, определяя нужную нам половину, верхнюю или нижнюю, и затем переходя в середину выбранной части, многократно повторяя данный процесс?
Это и есть принятие решения, выбор алгоритма, процесса. Обычно это творческий акт, в результате которого возникает новый метод, особенно в новых, сложных или очень крупномасштабных разработках.
Выбрав некоторый метод, мы «детализируем» его, превращая в некоторую «структуру». В любой значительной работе к одному и тому же результату могут привести десятки различных структур. Различия в структурах могут быть значительными, результат же будет одинаковым.
Например, выбрав метод двоичного поиска, я могу писать программу либо на Фортране, либо на Коболе. В Коболе затруднено индексирование, а в Фортране очень неудобны манипуляции с данными. Программы на этих языках будут сильно отличаться друг от друга; в результате две разные программы будут осуществлять один и тот же двоичный поиск.
Оценивать структуру можно разными способами. Двумя мерами оценки могут служить модульность и четкость интерфейса.
Описание, или представление, программы может принимать различные формы. Это могут быть блок-схемы, снабженные некоторыми примечаниями; это могут быть иерархические схемы ввода, обработки, вывода (HIPO), схемы Вернера — Орра и т. д.
Целью описания является объяснение новичкам и продолжателям разработки назначения программы и методов, которыми она решает задачу. Следовательно, оценивать описание нужно по тому, насколько хорошо оно отражает эти сведения. «Хорошо» означает понятно, однозначно и немногословно.