Параллельное и распределенное программирование на С++ - Хьюз Камерон

Надежность программного обеспечения

Надежность программного обеспечения— это веро я тность безотказно г о функционирования компьютерной про г ра м мы в течение заданно г о времени в заданной среде. Видеале эта веро я тность приближаетс я к 100%. Если разработчики хотят создать систему, которая будет отличатьс я безотказной работой, ее ПО должно разрабатыватьс я c использова н ие м м етодов отказоустойчиво г о про г ра мм ирования. Отказоустойчивая система — это систе м а, которая сохраняет работоспособность в результате устранения последствий ошибок ПО. Под ошибкой (fault) понимается программный дефект, который может привести к отказу в работе некоторой части ПО. В понятие «сбоя в системе программного обеспечения» (failure) мы вкладываем выполнение некоторого компонента ПО, который отклоняется от системных спецификаций. Мы согласны страктовкой ошибок и сбоев, которую предложили Муса (Musa), Ианино (Iannino) и Оку м ото (Okumoto) в своей кни г е Software Reliability.

Ошибка — это дефект в программе, который при некоторых условиях приводит к ее отказу. К отказу могут привести различные совокупности условий, причем эти условия могут повторяться. Следовательно, ошибка может быть источником не одного, а нескольких отказов. Ошибка (дефект) — это свойство программы, а не результат (свойство) ее выполнения или поведения. Именно этот смысл мы вкладываем в понятие термина «bug». Ошибка ПО — это следствие оплошности, или недоработки (error), программиста.

Ошибки, которые допускает программист или разработчик ПО, могут возникнуть из-за неверной интерпретации требований к ПО или некачественного, некорректного или недостаточно полного перевода этих требований в код. Если программист совершает оплошности такого рода, он вносит в программу ошибки, или дефекты. При выполнении дефектного кода может произойти сбой программы. Ошибки ПО можно обнаружить только при выполнении кода. Очистить программу от ошибок, а следовательно, и не допустить возможность отказа, позволяет процесс тестирования и отладки ПО. Обратите внимание на то, что мы используем термины «дефект» и «ошибка» взаимозаменяемо. Термин «оплошность» мы относим к допускаемым программистом промахам, которые являются причиной дефектов ПО. Отказоустойчивость—это свойство, которое позволяет некоторой части ПО оставаться в исправном состоянии или восстанавливать работоспособность после программных сбоев, вызванных ошибками, внесенными в ПО в результате недоработки программистов.

Одни отказы ПО являются результатом наличия дефектов в программах, другие же— результатом исключительных условий (необязательно созданными оплошностью программиста), которые могут создаться в оборудовании или используемых программных пролуктах. Например, сетевая карта, поврежденная в результате всплеска напряжения, может привести соответствующую часть ПО к сбою. Вирус может нарушить процесс передачи данных, в результате чего может отказать программа, которая зависит от этого процесса. Пользователь может нечаянно удалить критические компоненты из системы, что неминуемо приведет к ее отказу. Перечисленные выше неприятности вызываются не из-за дефектов в программе, а создаются в результате условий, которые мы называем исключительными сигуациями. Исключительная ситуация, или исключение, — это ненор м альные условия, или исключительные обстоятельства, или экстраординарные явления (события), с которы м и сталкивается ПО, в результате че г о оно (или некоторая е г о часть) отказывает. И хотя какдефекты. так и и сключения приводят к отказа м ПО, важно пони м ать различие между ни м и, поскольку для «борьбы» с ни м и при м еняются, как правило, рааличные м етоды. Несмотря на то что конечным результатом при м енения этих методов является на д ежное и отказоусто й чивое ПО, для обработки исключени й и обработки ошибок (дефектов) используются различные способы проектирования и про г раммные конструкции.

Отказы в программных и аппаратных компонентах

При проектировании надежного и отказоустойчивого ПО мы должны поставить цель создать такое ПО, которое бы продолжало функционировать даже после отказа некоторых ero компонентов (аппаратных или программных). Если наше ПО претен-лует на то, чтобы называться отказоустойчивым, оно должно обладать средствами, которые могли бы прелусматривать последствия аппаратных или программных ошибок. По крайней мере наши отказоустойчивые проекты должны обеспечивать не мгновенное прекращение работы системы, а постепенное сокращение ее возможностей. Если наше ПО является отказоустойчивым, то в случае отказа отдельного его компонента (компонентов) оно должно продолжать функционирование, но на более низком уровне. Ошибки, которые наше ПО должно обрабатывать, можно разделить на две категории: программные и аппаратные. На рис. 7.1 показана схема некоторых аппаратных компонентов, а также уровни ПО, которые могут включать ошибки.

Рис.7.1. Схема аппаратных компонентов, а также уровней ПО, которые могут содержать ошибки

На рис. 7.1 мы отделили аппаратные компоненты от программных, поскольку методы обработки аппаратных сбоев часто отличаются от методов обработки программных ошибок. Здесь также выделены различные уровни ПО. Некоторые из них находятся вне «досягаемости» разработчика (т.е. он не может ими управлять напрямую) и требуют специального рассмотрения процесса обработки исключений и ошибок. На этапах проектирования, разработки и тестирования ПО обязательно следует принимать во внимание возможность аппаратных сбоев и наличия ошибок в различных «слоях» ПО. Для программ, которым присущ параллелизм или состоящих из распределенных компонентов, следует учитывать дополнительные обстоятельства, весьма «благоприятные» для возникновения аппаратных сбоев. Например, в распределенных программах используется взаимодействие аппаратных и программных средств. Ошибка, «закравшался» в компонент, отвечающий за это взаимодействие, может привести к отказу всей системы. Программы, разработанные для параллельной работы процессоров, могут сбоить, если ожидаемое количество процессоров окажется недос-гупным. Даже если средства связи и процессоры прекрасно отработали при загрузке системы, ее отказ возможен в любой момент после начала функционирования. Исключительная ситуация может возникнуть в любом из компонентов оборудования и на любом уровне ПО. Кроме того, каждый программный уровень может содержать дефекты, которые необходимо каким-то образом обрабатывать. На этапе проектирования ПО следует рассматривать возможные исключительные ситуации и ошибки в программах, присущие каждому уровню ПО в отдельности. Ведь варианты восстановления приложения после возникновения исключительных ситуаций и исправления ошибок, которые возможны на уровне 2, отличаются от вариантов, применимых к уровню 3. К сбоям, которые возможны на различных уровнях ПО и в аппаратных компонентах, следует добавить сбои, характеризующиеся архитектурной областью локализации, специфической для каждого приложения. Например, на рис. 7,2 показано, как по мере увеличения дистанции между задачами возрастает уровень сложности обработки ошибок и исключительных ситуаций.

Рис. 7.2. Зависимость увеличения уровня сложности обработки исключительных ситуаций и ошибок от увеличения дистанции между логическим местоположением задач