Программное обеспечение и его разработка - [34]
Большие системы программного обеспечения логически очень сложны. Они содержат огромное число ветвлений. В своей книге «Мифический человеко-месяц» Брукс[8] утверждает, что системное программное обеспечение в девять раз труднее разрабатывать, чем прикладное обеспечение. Основной причиной этого является логическая сложность.
Если отдельно рассмотреть прикладные программы, они окажутся не такими уж сложными. Однако при первой же попытке объединить некоторое количество прикладных программ в цельную однородную систему мы сразу же столкнемся со сложными проблемами. Рис. 4.20 взят из книги Джеймса Мартина «Организация баз данных».
К сожалению, в настоящее время вопросу изучения логической сложности уделяется недостаточное внимание. По мере внедрения вычислительной техники в различные прикладные области, связанные с проведением большого числа сложных операций и управления процессами, мы лучше сможем представить себе эту важную отрасль.
Проблемы, связанные со сложностью. Сложность всегда доставляла и до сих пор доставляет людям множество неприятностей. И никого не должно удивлять то, что она мучает нас при разработке больших программных систем, — однако это удивляет. Ведь мы склонны всегда забывать, сколько мучений мы претерпели из-за сложности, где бы она ни проявлялась.
Очень долго у людей были сложности с мостами. За одно только десятилетие с 1870 по 1880 г. только в одних Соединенных Штатах разрушалось в среднем до 40 мостов в год. Граждане переходили через мост с риском для жизни. «Социология» того периода очень напоминает положение, сложившееся в настоящее время:
Катастрофы на крупных мостах случались гораздо чаще, чем на железной дороге. Многие мосты местного значения строились окружными властями, которые соединяли в себе техническое невежество и неумение решать экономические проблемы. Подрядчики и торговцы заключали самые дешевые контракты, что фактически вело к исключению других, возможно более хороших вариантов. Безответственные исполнители продавали все, что только было можно; при первой же возможности быстро наводили мост и тут же поспешно исчезали. Самые авторитетные фирмы были поставлены конкуренцией в весьма опасное положение[9].
Рис. 4.20. Взаимосвязанные функции (Мартин Дж. «Организация баз данных в вычислительных системах». Пер. с англ. — М… Мир, 1980) Печатается с любезного разрешения издательства Прентис Холл.
Как сильно все сказанное о том времени напоминает ситуацию, возникшую в программировании сегодня! А ведь семидесятые годы прошлого столетия не были первыми годами бедствий. Веками мосты разрушались из-за воздействия гармонических колебаний. Чего стоили только проходы через мосты солдат, марширующих в ногу. В 40-х гг. XX в. возникла проблема ветра. В 1940 г. упал мост через Такомский залив. В 1970-х гг. мост Бронкс Уайтстоун, «укрепленный» после Такомской катастрофы, начал раскачиваться так сильно, что люди бросали свои автомобили и в панике прыгали с пролетов моста.
Проблемы возникали не только с подвесными мостами. В 1944 г. двухфермовый мост через Миссисипи в Честере, шт. Иллинойс, был сброшен ветром со своих ненадежных опор. В 1905 г., когда был разрушен мост на кронштейнах через реку Св. Лаврентия в канадской провинции Квебек, было убито 87 рабочих. Физическая природа таких строений была тогда недостаточно понятна людям.
Новые явления приносят нам новые сложности. Моторы компании «Локхид Электра» (Lockheed Electra) разрушаются из-за дефектов проектирования. Самолеты DC-10 не летают!
Во второй половине семидесятых годов в здании Джона Хэнкока в Бостоне уже не было стеклянных окон. Были заменены 10 тыс. 400-фунтовых стекол.
Люди до сих пор не справились со сложностями, возникшими вместе с открытием ядерной энергии. Убытки от катастрофы, происшедшей на Острове третьей мили, продолжают расти и уже достигли 4 млрд. долларов!
После того как программа уже создана и работает, ее ясность зависит только от ее разработки и реализации. На стадии разработки нам часто доставляет неприятности неясность поставленных перед нами целей. Что должна делать программа? В каком-то смысле пять различных типов использования программ отражают атрибут ясности.
Работа вычислительной машины по типу I (коммерческие расчеты) совершенно ясна. Задачи по обработке данных в большинстве случаев уже полностью решены. Все, что нам надо сделать, это разобраться в используемых процедурах и запрограммировать их. На противоположной стороне шкалы находятся задачи по управлению процессами типа V.
Чаще всего при их программировании нам приходится сталкиваться с выполнявшими до сих пор все работы «старыми мастерами», т. е. какими-то умными, искусными, все понимающими людьми, которые способны держать в голове все параметры, варианты, возможные ловушки, несовместимости, несоответствия и разрывы. Эти люди «видят», как развиваются события, могут почувствовать, когда что-то не ладится, и «знают», что надо делать в этом случае.
Попробуйте записать все правила, алгоритмы, попробуйте повторить то, что эти люди могут проделать в своем уме, и вы столкнетесь с необходимостью уметь здраво рассуждать, распознавать сложные образы, обладать изрядной долей интуиции и «чувствовать». Все это с трудом поддается определению, и получить полезную систему можно только после нескольких неудач, напрасных разработок, после потери значительных денежных сумм.
