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