П **°*
Обработка ошибок, исключительных ситуаций и надежность программного обеспечения
Всегда можно изобрести суперсложные модели, чтобы объяснить множество исследуемых фактов, но ученыи, если он не философ, скорее примет самую простую теорию, которая согласуется со всеми имеющимися у негоданными.
Одна из главных целей разработки и проектирования программного обеспечения— создать программу, которая бы отвечала требованиям пользователя и работала корректно и надежно. Пользователи требуют от ПО корректности и надежности, независимо от его конкретного назначения. Использование ненадежных программ в любой сфере — финансовой, промышленной, медицинской, научной или военной— может иметь разрушительные последствия. Зависимость людей и механизмов от ПО на всех уровнях нашего общества вынуждает его создателей сделать все возможное, чтобы их детище было надежным, робастным и отказоустойчивым. Эти требования налагают дополнительную ответственность на разработчиков и проектировщиков ПО, которые создают системы, содержащие параллелизм. Программы с параллелизмом или компоненты, которые выполняются в распределенных средах, содержат больше (по сравнению с ПО без параллелизма) программных уровней. Чем больше уровней, тем сложнее управлять таким ПО. Чем выше сложность системы, тем больше изъянов может остаться в ней невыявленными. А чем больше изъянов в ПО, тем выше вероятность того, что оно откажет, причем в самый неподходящий момент.
Для программ, разбиваемых на параллельно выполняемые или распределенные задачи, характерны дополнительные сложности, которые проявляются в процессе поиска правильного решения, связанного с декомпозицией работ (work breakdown stmcture-WBS). Кроме того, здесь необходимо учитывать проблемы, которые являются неотъемлемой частью именно сетевых коммуникаций. Помимо проблем коммуникации и декомпозиции, не следует забывать о таких «прелестях» синхронизации, как «гонка» данных и взаимоблокировка. Параллельное программирование «по определению» практически всегда сложнее последовательного, а следовательно, обработка ошибок и исключительных ситуаций для параллельных программ требует больше усилий (и умственных, и физических, и временных), т.е. «больше» программирования. Интересно отметить, что разработка ПО развивается в направлении приложений, которые требуют параллельного и распределенного программирования. В проектировании современного ПО распространены Internet- и Intranet-модели. Нынче становятся нормой (а не исключением) многопроцессорные компьютеры общего назначения. Встроенные и промышленные вычислительные устройства становятся все более высокоорганизованными и мощными. Для серверного развертывания «де- факто» становится стандартом понятие кластера. Мы считаем, что нынешним разработчикам и проектировщикам ПО не остается ничего другого, как разрабатывать и проектировать надежные приложения для многопроцессорных и распределенных сред. И, безусловно, излишне повторять, что требования, предъявляемы к ПО такого рода, постоянно возрастают как по сложности, так и организации.
Во многих примерах программ этой книги мы не приводим кода обработки ошибок и исключительных ситуаций, чтобы не отвлекать внимание читателя от основной идеи или концепции. Однако важно иметь в виду, что использованные здесь примеры имеют вводный характер. В действительности объем кода, посвященного обработке ошибок и исключительных ситуаций в программах, включающих параллелизм или рассчитанных на распределенную среду, довольно значителен. Обработка ошибок и исключительных ситуаций должна быть составной частью проекта ПО на каждом этапе его разработки. Мы — сторонники моделирования на основе раскрытия параллелизма в области проблемы и ее решения. И именно на этапе моделирования следует заниматься разработкой моделей подсистем обработки ошибок и исключительных ситуаций. В главе 10 показано, как можно использовать язык UML (Unified Modeling Language — унифицированный язык моделирования) для визуализации проектирования систем, требующих параллельных или распределенных методов программирования. Разработка подсистем обработки ошибок и исключительных ситуаций лишь выиграет от применения средств UML и самого процесса визуализации, который ничем другим заменить нельзя. Следовательно, в качестве исходной цели вам необходимо представить надежность разрабатываемого ПО с помощью таких инструментов, как UML, диаграммы событий, событийные выражения, диаграммы синхронизации и пр. В этой главе рассматриваются преимущества ряда методов проектирования, которые способствуют визуализации проекта подсистемы обработки ошибок и исключительных ситуаций. Кроме того, в качестве основы для разработки надежного и отказоустойчивого ПО используются встроенные средства языка С++, содержащие иерархию классов исключений.
Надежность программного обеспечения
Ошибка — это дефект в программе, который при некоторых условиях приводит к ее отказу. К отказу могут привести различные совокупности условий, причем эти условия могут повторяться. Следовательно, ошибка может быть источником не одного, а нескольких отказов. Ошибка (дефект) — это свойство программы, а не результат (свойство) ее выполнения или поведения. Именно этот смысл мы вкладываем в понятие термина «bug». Ошибка ПО — это следствие оплошности, или недоработки (error), программиста.
Ошибки, которые допускает программист или разработчик ПО, могут возникнуть из-за неверной интерпретации требований к ПО или некачественного, некорректного или недостаточно полного перевода этих требований в код. Если программист совершает оплошности такого рода, он вносит в программу ошибки, или дефекты. При выполнении дефектного кода может произойти сбой программы. Ошибки ПО можно обнаружить только при выполнении кода. Очистить программу от ошибок, а следовательно, и не допустить возможность отказа, позволяет процесс тестирования и отладки ПО. Обратите внимание на то, что мы используем термины «дефект» и «ошибка» взаимозаменяемо. Термин «оплошность» мы относим к
