Программное обеспечение и его разработка
Шрифт:
Наверное, самый понятный пример эффекта, проистекающего от возрастающего масштаба работ, был мною обнаружен при изучении одного интересного и удивительного факта, когда в 1968 г. я прибыл в отделение федеральных систем для того, чтобы стать помощником его президента Боба Эванса. Около десяти человек из Хьюстонской космической группы были направлены в Лондон, в один из банков. Для чего это было нужно? Специалисты по космосу помогали Лондонскому банку налаживать обработку данных?
Или,
Банкам понравились люди из Хьюстона. Несмотря на то что они ровным счетом ничего не понимали в банковском деле, они имели большой опыт по реализации систем именно таких масштабов, какие были нужны банкам, — в то время таких людей было немного. Способы управления крупномасштабными работами нельзя рассматривать как простую сумму усилий на управление мелкими проектами. Работы по созданию любого крупного объекта содержат в себе немало тонкостей.
Одним из позднейших фундаментальных открытий математики было открытие числа нуль. Оно появилось поздно, поскольку вначале его необходимость не была очевидна.
Так же обстоит дело и с понятием сложности. Сложность легко себе представить, но трудно описать. Еще мало разработано приемов для работы с понятием сложности. У нас нет метрики для измерения того, что одна работа вдвое сложнее другой. Нет прилагательных для определения степени сложности. Мы вынуждены говорить, что это «более сложное» или «очень сложное». Это, быть может, и верно, но не очень полезно, когда нам надо создать нечто «более сложное», чем что-то еще. Ведь стоимость наших работ достигает миллионов долларов, а их результаты имеют очень значительные последствия. Мы, однако, можем четко различать два «вида» сложности:
1) техническая сложность конкретного приложения.
2) логическая сложность приложения и/или системы программного обеспечения.
Техническая сложность. У меня в распоряжении две программы, по 50 тысяч команд каждая. Одна «делает» платежную ведомость, а другая «делает» вычисления, связанные с безопасностью летящей ракеты. Ракетная программа будет более сложной; в ней требуется решить некоторые сложные уравнения.
Предсказание погоды, уравнения ядерной физики, орбитальные расчеты, гравитационные эффекты, баллистика — все это требует специального математического аппарата, инженерного искусства, а также высокой научной квалификации и знаний. Эти знания нужно использовать во всех фазах разработки программного обеспечения. Получение таких знаний само по себе достаточно трудный процесс, использование же их трудно вдвойне.
Логическая сложность. Существует и другой вид сложности — логическая сложность, причем управляться с логической сложностью даже труднее, чем с математической или технической. Эта сложность проявляется в многообразии различных вариантов, выбор среди которых надо производить на каждом шаге решения. Каким образом можно проследить все возможные или подходящие нам пути, по которым проходит управление при выполнении больших программ? В программах может быть лишь несколько условных переходов, в других же программах их может оказаться огромное множество! Попробуем разобраться, почему же бывает трудно справиться с программой с большим количеством условных переходов.
Сколькими различными способами можно соединить с контактами пять проводков из семижильного жгута? Таких способов 2520.
Сколько различных порядков при ударе можно выстроить для 12 — всего лишь 12 — ребят, игроков бейсбольной команды младшей лиги? Подсчитали? 79 миллионов 833 тысячи 600! Только для 12 ребят!
Одной из самых логически сложных программ является программа диспетчеризации
Во время переговоров при заключении контракта на изготовление диспетчерской системы мы специально изучали 600 тысяч строк программы, подготовленной для работы на центральном вычислительном комплексе, и обнаружили в ней большое число условных переходов. Мы насчитали 39 203 таких перехода, т. е. в среднем по одному на каждые 15.3 строк текста В этой программе очень много внимания уделяется принятию различных решений, что связано с запутанной логической структурой управления, предсказания возможных конфликтных ситуаций, а также множества различных вариантов, возникающих при работе с 97 устройствами для ввода данных и запросов к системе, форматной выдаче данных на дисплеи. Сколько же вариантов возникает при выполнении этой программы? Это число равно 39 203! Это просто астрономическое число, оно примерно равно 1011 801, или десятке, за которой следует 11 800 нулей! Если бы мы могли проверять один вариант программы за одну секунду, то на тестирование всей программы в целом нам пришлось бы затратить несколько тысяч лет. Мы не можем создать специальную тестирующую систему, которая могла бы проверить нам все варианты, возникающие в окружающем нас мире.
Если кто-то начинает говорить о том, что он создал программу, в которой нет ни одной ошибки, значит, либо он говорит об очень маленькой программе, либо вообще не знает, о чем говорит.
Большие системы программного обеспечения логически очень сложны. Они содержат огромное число ветвлений. В своей книге «Мифический человеко-месяц» Брукс [8] утверждает, что системное программное обеспечение в девять раз труднее разрабатывать, чем прикладное обеспечение. Основной причиной этого является логическая сложность.
8
Frederick P. Broocks, Jr. Mythical Man-Month (Reading, Mass; Addison — Wesley, 1975). Есть русский перевод, см. примечание на стр.5.
Если отдельно рассмотреть прикладные программы, они окажутся не такими уж сложными. Однако при первой же попытке объединить некоторое количество прикладных программ в цельную однородную систему мы сразу же столкнемся со сложными проблемами. Рис. 4.20 взят из книги Джеймса Мартина «Организация баз данных».
К сожалению, в настоящее время вопросу изучения логической сложности уделяется недостаточное внимание. По мере внедрения вычислительной техники в различные прикладные области, связанные с проведением большого числа сложных операций и управления процессами, мы лучше сможем представить себе эту важную отрасль.
Проблемы, связанные со сложностью. Сложность всегда доставляла и до сих пор доставляет людям множество неприятностей. И никого не должно удивлять то, что она мучает нас при разработке больших программных систем, — однако это удивляет. Ведь мы склонны всегда забывать, сколько мучений мы претерпели из-за сложности, где бы она ни проявлялась.
Очень долго у людей были сложности с мостами. За одно только десятилетие с 1870 по 1880 г. только в одних Соединенных Штатах разрушалось в среднем до 40 мостов в год. Граждане переходили через мост с риском для жизни. «Социология» того периода очень напоминает положение, сложившееся в настоящее время: