И все же нам не устают повторять, что «проектирование завершено на 90 %».
Проектирование программного обеспечения фазы использования
Давайте на некоторое время предположим, что аппаратура настолько соответствует поставленной перед нами задаче, что меняться больше не будет. Что же в таком случае мы будем проектировать в программном обеспечении?
В первую очередь нам придется спроектировать, т. е. выбрать, главные составные части нашей программы. Нужно ли нам иметь отдельные системные программы? Нужна ли специальная операционная система? Система управления базой данных?
По каким признакам мы можем определить, стоит ли выделять эти подсистемы или включать их в состав прикладных программ? Мы судим об этом по двум вещам: по требованиям, определенным в формулировке требований (имеются в виду требования как к функциональным возможностям, так и к окружению), и по всем 12 характеристикам программ, распределенным по всем фазам жизни программ.
Проектирование должно учитывать все 12 характеристик программ и программного обеспечения и все три фазы полного цикла жизни программы, даже если некоторые характеристики при проектировании придется отбросить!
Для группы десантников, которую ночью направили через болото, любой путь, приводящий к цели, хорош. Это дорога? Она приведет нас туда, куда надо? Да? Тогда это то, что надо! Времени на изучение и поиски более коротких дорог нет. Надо бежать по этой!
Такие методы хороши только для программ типа «зубочисток» или в тех случаях, когда через это болото больше никому не придется переходить.
Если же проектируется долгоживущее программное обеспечение, то на фазе проектирования необходимо затрачивать некоторые усилия на то, чтобы максимально облегчить сопровождение программ в дальнейшем.
Иногда проблемы использования можно не принимать во внимание. Ведь программа может использоваться крайне редко. В некоторых случаях упор приходится делать на фазу разработки, в других случаях особую важность приобретает фаза сопровождения. Более подробно об этом будет сказано чуть позже.
Но если только та машина, которая будет применяться на фазе использования, обладает достаточной мощностью и памятью и мы можем себе позволить некоторые дополнительные расходы, обычно связанные с универсальностью уже готовых системных программ, нам обязательно надо выбирать готовые программы. Следующим нашим шагом должно быть определение наилучших среди всех доступных нам программ. В этом состоит проектирование, это выбор того, какие конкретные программы взять из имеющихся, и это действительно очень ответственное проектирование. При этом формируется система в полном смысле слова. Это расслоение на отдельные части сродни выделению сборочных узлов при проектировании аппаратуры.
Проектировщик соглашается на компромисс между стоимостью и скоростью, между простотой запросов данных и скоростью их поиска, между объемом занимаемой памяти, схемой упаковки и временем ответа, между средствами распределения ресурсов и богатством функций, между средствами управления окружением и выполняемыми функциями, а также между многими другими характеристиками системы.
Кто должен вести проектирование
Заниматься проектированием может не каждый. Дейкстра в статье «Структура мультипрограммной системы „THE“»[14] отмечает два момента:
Попытки избежать разного рода «патологий» отняли гораздо больше сил, чем мы ожидали, причем некоторые наши беды были прямо связаны с нашими изобретениями на первых этапах работ… Если бы мы больше уделяли внимания патологии на ранних стадиях проектирования, мы бы выработали гораздо менее утонченные правила управления работой
И
… по крайней мере в моей стране (имеются в виду Нидерланды) интеллектуальный уровень, необходимый для проектирования систем, чаще всего сильно недооценивается. Этот вид работ чрезвычайно труден, и любые попытки вести проектирование иначе как с помощью наилучших специалистов, обречены либо на провал, либо на весьма умеренный успех за огромную плату
Обратите внимание на слова: «наилучшие специалисты».
Выбирая проектировщика, прежде всего обращайтесь к тем, кто уже ранее выполнял такую работу! К тому, кто уже вел систему от самого начала до самого конца! Постарайтесь договориться с ним. Если в вашем распоряжении нет людей, проектировавших ранее программное обеспечение данного типа, нужно создать «группу проектирования». Последите за ее работой. Из этой группы выделятся один или два человека, которые и будут заниматься проектированием программного обеспечения.
Тот единственный человек, который является подлинным проектировщиком большой системы, обычно весьма умен, спокоен и упорен. Он достаточно спокоен, чтобы быть хорошим руководителем, достаточно умен, чтобы уметь усвоить множество конфликтующих целей, влияний, методов и противоречий между людьми и разобраться в них.
Если проектированием занимается слишком много людей, если при проектировании слишком увлеклись демократией или если проектировщики начинают сменять друг друга — все это очень сильно затрудняет разработку.
Конечная продукция — что же мы создаем?
Зрительно представить себе программное обеспечение очень трудно. Статические представления его весьма бледны, но зачастую это лучшее, что нам удается сделать. Рассмотрим пример программного обеспечения системы наземного контроля проекта «Аполлон», это обеспечение работало в Хьюстоне много лет, и оно поможет нам увидеть все, что мы намеревались создать.
У нас была большая (более 1 млн. команд) программная система, хорошо документированная и оттестированная. Все эти команды были распределены по программам, подпрограммам и модулям. Подразделы строились отдельно и включались во внешние структуры.
Наше программное обеспечение «приняло» несколько форм. У нас имелась распечатка (напечатанный на машине текст) всех команд по порядку. Имелись колода перфокарт и магнитная лента, на которой была записана программа. Ни одно из этих воплощений программы человеку увидеть не легко — даже распечатку. Ни одно из них не давало возможность увидеть структуру или последовательность выполнения команд программы. Чтобы понять идею системы, нам требовались такие схемы, как изображенные на рис. 5.19 и 5.20. Вся программная система была разделена на восемь основных частей, что и показано на рис. 5.19.
Назначение каждой подсистемы совершенно ясно из их наименований. Общее управление системой осуществлялось операционной системой реального времени, которая определяла, какую программу надо исполнять в данное время.
Рис. 5.19. Структура программного обеспечения системы наземного контроля «Аполлон»
Рис. 5.20. Структура программного обеспечения подсистемы запуска «Аполлон».
Теперь перейдем к более подробному изучению подсистемы запуска (рис. 5.20). Каждый квадратик обозначает очень большую программу, которая при необходимости будет выполнена. Операционная система определяет, когда наступает такая необходимость. Если мы продолжим разбиение этих блоков программного обеспечения на более мелкие детали, мы получим разветвленное дерево, подобное представленному на рис. 5.21. Каждому квадрату соответствует некоторый акт проектирования. Проектирование здесь заключается в выборе конкретной комбинации функций и распределении их между отдельными вполне определенными программами.
Когда мы смотрим на статическое представление программы, подобное дереву на рис. 5.21, мы должны помнить, что каждый квадрат — это программа, которая может быть выполнена в любое время и в самых разных комбинациях с другими программами.
