Что означает обеспечение устойчивости программы к ошибкам

Обновлено: 06.07.2024

Программа считается правильной, если она не содержит ошибок. Такая программа не дает неверных результатов, т.е. она абсолютно надежна. Этот факт породил ложное представление о том, что число ошибок в программе можно считать наиболее естественной мерой надежности. Было выполнено довольно много работ, в которых предлагались различные методы оценки числа оставшихся в программе ошибок по результатам ее тестирования, в том числе метод "засорения" известными ошибками, однако, как показывают приводимые ниже соображения, количество ошибок в программе не имеет никакого отношения к ее надежности:

1. Число ошибок в программе - величина "ненаблюдаемая", наблюдаются не сами ошибки, а результат их проявления.

2. Неверное срабатывание программы может быть следствием не одной, а сразу нескольких ошибок.

3. Ошибки могут компенсировать друг друга, так что после исправления какой-то одной ошибки программа может начать "работать хуже".

4. Надежность характеризует частоту проявления ошибок, но не их количество; в то же время хорошо известно, что ошибки проявляются с разной частотой: некоторые ошибки остаются невыявленными после многих месяцев и даже лет эксплуатации, но, с другой стороны, нетрудно привести примеры, когда одна единственная ошибка приводит к неверному срабатыванию программы при любых исходных данных, т.е. к нулевой надежности.

Согласно [ГОСТ 9126] качество программного обеспечения это весь объем признаков и характеристик программного обеспечения, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

Качество программного обеспечения оценивается следующими характеристиками:

Функциональные возможности (Functionality).Набор атрибутов,относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности.

Надежность (Reliability).Набор атрибутов относящихся к способности программногообеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени.

Практичность (Usability).Набор атрибутов,относящихся к объему работ,требуемых дляиспользования и индивидуальной оценки такого использования определенным и предполагаемым кругом пользователей.

Эффективность (Efficiencies).Набор атрибутов,относящихся к соотношению междууровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.

Сопровождаемость (Maintainability).Набор атрибутов,относящихся к объему работ,требуемых для проведения конкретных изменений (модификаций).

Мобильность (Portability).Набор атрибутов,относящихся к способности программногообеспечения быть перенесенным из одного окружения в другое.

В общем случае под ошибкой подразумевается неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании или применении программы. При этом предполагается, что известно правильное, эталонное состояние объекта или процесса по отношению к которому может быть определено наличие отклонения. Исходным эталоном для любого программного обеспечения являются спецификации требований заказчика или потенциального пользователя, предъявляемых к программам и ожидаемый пользователем или заказчиком эффект от использования программного обеспечения. Важной особенностью при этом является отсутствие полностью определенной программы – эталона, которой должны соответствовать текст и результаты функционирования разрабатываемой программы. Поэтому определить качество программного обеспечения и наличие ошибок в нем путем сравнения разрабатываемой программы с эталонной программой невозможно.

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

Исходя из определения ошибки в программном обеспечении, приведенном выше, можно сделать вывод, что ошибки, проявляющиеся в ходе функционирования программного обеспечения, могут влиять на все показатели качества. В работе рассматриваются ошибки, проявления которых влияют на надежность функционирования программного обеспечения.

По определению, установленному в программу, надежность – свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующим заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования.

Рис. 1. Надежность по ГОСТ 27.002 – 89

При этом надежность является комплексным свойством, которое в зависимости от назначения объекта и условий его применения может включать безотказность, долговечность, ремонтопригодность и сохраняемость или определенные сочетания этих свойств (рис. 1). Поскольку программное обеспечение в процессе эксплуатации не изнашивается, его поломка и ремонт в общепринятом смысле не производится, то надежность программного обеспечения имеет смысл характеризовать только с точки зрения безотказности его функционирования и возможности восстановления функционирования после отказов вызванных проявлениями ошибок.

В данном случаи надежность программного обеспечения предлагается характеризовать с помощью следующих характеристик (рис. 2): стабильность, устойчивость и восстанавливаемость.

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

В этом случае стабильность и устойчивость характеризуют безотказность программного обеспечения, а восстанавливаемость – возможность восстановления функционирования программного обеспечения после его отказа. Для количественной оценки надежности программного обеспечения необходимо определить показатели надежности для каждого свойства и методику их определения (оценки).

Для оценки стабильности программного обеспечения возможно использование показателей характеризующих безотказность технических устройств(рис. 3).

Рис. 3. Показатели безотказности

В большинстве случаев поток программных ошибок может быть описан негомогенным процессом Пуассона. Это означает, что программные ошибки происходят в статистически независимые моменты времени, наработки

подчиняются экспоненциальному распределению, а интенсивность проявления ошибок изменяется во времени. Обычно используют убывающую интенсивность проявления ошибок. Это означает, что ошибки, как только они выявлены, эффективно устраняются без введения новых ошибок. Главная цель анализа надежности программного обеспечения заключается в том, чтобы определить форму функции интенсивности проявления ошибок и оценить ее параметры по наблюдаемым данным. Как только функция интенсивности проявления ошибок определена, могут быть найдены такие показатели надежности как:

• общее количество ошибок;

• количество остающихся ошибок;

• время до проявления следующей ошибки;

• вероятность безошибочной работы;

• интенсивность проявления ошибок;

• остаточное время испытаний (до принятия решения);

• максимальное количество ошибок (относительно срока службы).

При этом следует различать понятия ошибка и отказ. Применительно к надежности программного обеспечения ошибка это погрешность или искажение кода программы, неумышленно внесенные в нее в процессе разработки, которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования. Под отказом в общем случае понимают событие, заключающееся в нарушении работоспособности объекта. Состояние объекта, при котором значения всех параметров характеризующих способность выполнять заданные функции, соответствуют требованиям нормативно – технической и (или) конструкторской (проектной) документации – называется работоспособным. При этом критерии отказов, как признаки или совокупность признаков нарушения работоспособного состояния программного обеспечения, должны определяться исходя из его предназначения в нормативно – технической и (или) конструкторской (проектной) документации.

В общем случае отказ программного обеспечения можно определить как:

прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) на время превышающее заданный порог;

прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание ) на время не превышающее заданный порог, но с потерей всех или части обрабатываемых данных;

прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание ) потребовавшее перезагрузки ЭВМ, на которой функционирует программное обеспечение.

При этом исходя из всего, все отказы в программном обеспечении следует трактовать как сбои (самоустраняющиеся отказы или однократные отказы, устраняемые незначительным вмешательством оператора), поскольку восстановление работоспособного состояния программного обеспечения может произойти без вмешательства оператора (перезагрузка ЭВМ не требуется), либо при участии оператора или эксплуатирующего персонала (перезагрузка ЭВМ необходима).

Приведенные выше критерии отказов приводят к необходимости анализа временных характеристик функционирования программы и динамических характеристик потребителей данных, полученных в ходе функционирования программного обеспечения. Временная зона перерыва нормальной выдачи информации и потери работоспособности, которую следует рассматривать как зону сбоя (отказа), тем шире, чем более инертный объект находится под воздействием данных, полученным в ходе работы программы. Пороговое время восстановления работоспособного состояния системы, при превышении которого следует фиксировать отказ, близко к периоду решения задач для подготовки информации (данных) соответствующему потребителю (абоненту).

Для любого потребителя данных существует допустимое время отсутствия данных от программы, при котором его характеристики находятся в допустимых пределах . Исходя из этого времени, можно установить границы временной зоны, которая разделяет работоспособное и неработоспособное состояние программного обеспечения и позволяет использовать данные критерии отказов.

Из приведенного выше определения программной ошибки с точки зрения надежности, можно сделать вывод о том , что ошибки, при их проявлении, не всегда вызывают отказ программного обеспечения и каждую ошибку можно характеризовать условной вероятностью возникновения отказа при проявлении этой ошибки. Следует также отметить, что само по себе наличие ошибки в исходном коде не определяет надежность программы до тех пор, пока не произойдет проявления этой ошибки, поэтому пользоваться для оценки надежности программного обеспечения только показателями характеризующие общее количество ошибок в программе, количество оставшихся ошибок и максимального количества ошибок нельзя.

В данном случаи стабильность предлагается оценивать вероятностью безотказной работы, которая оценивается исходя из модели относительной частоты, при этом применение ее ограничено периодом эксплуатации программного обеспечения, что не всегда приемлемо, поскольку надежность объекта, как правило, необходимо оценивать не только в процессе его эксплуатации, но и до начала эксплуатации этого объекта. Ограничение модели относительной частоты вызвано тем, что в этой модели не учитываются процессы тестирования и отладки, а конкретно то, что при возникновении отказа программного обеспечения, ошибка, вызвавшая этот отказ, исправляется.

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

Устойчивость, как свойство или совокупность свойств программного обеспечения, характеризующие его возможность поддерживать приемлемый уровень функционирования при проявлениях ошибок в нем , можно оценивать условной вероятностью безотказной работы при проявлении ошибки. Согласно правилу устойчивость оценивается с помощью трех метрик, включающих двадцать оценочных элементов.

Устойчивость программного обеспечения;

Средство восстановления при ошибках на входе;

Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных;

1. Возможность обработки ошибочных ситуаций;

2. Полнота обработки ошибочных ситуаций;

3. Наличие тестов для проверки допустимых значений входных данных;

4. Наличие системы контроля полноты входных данных;

5. Наличие средств контроля корректности входных данных;

6. Наличие проверки параметров и адресов по диапазону их знаний;

7. Наличие обработки граничных результатов;

8. Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа).

Средства восстановления при сбоях в оборудовании;

1. Наличие требований к программе по восстановлению результатов при отказах процессора, операционной системы;

2. Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств;

3. Наличие средств восстановления процесса в случае сбоев оборудования;

4. Наличие возможности разделения по времени выполнения отдельных функций программ;

5. Наличие возможности повторного старта с точки остановки.

Реализация управления средствами восстановления;

1. Наличие централизованного управления процессами, конкурирующими между ресурсами;

2. Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления;

3. Наличие средств, обеспечения завершения процесса в случае помех;

4. Наличие средств, обеспечивающих выполнение программы в сокращенном объёме в случае ошибок и помех;

5. Показатель устойчивости к искажающим воздействиям.

Метрики и оценочные элементы устойчивости программного обеспечения по ГОСТ 28195 – 89

Результаты оценки каждой метрики определяются результатами оценки определяющих ее оценочных элементов, а результат оценки устойчивости определяются результатами соответствующих ему метрик. Программное обеспечение по каждому из оценочных элементов оценивается группой экспертов – специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Для оценочных элементов принимается единая шкала оценки от 0 до 1.

Недостатком такого подхода является одинаковая оценка устойчивости для всех возможных ошибок. Поскольку вероятность возникновения отказа при проявлении разных ошибок может быть разной, возникает необходимость разделения ошибок на несколько категорий. Признаком, по которому в этом случае можно относить ошибки к той или иной категории, можно считать тяжесть ошибки. Под тяжестью ошибки в этом случае следует понимать количественную или качественную оценку вероятного ущерба при проявлении

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

Устойчивость к ошибкам— это мера способности системы программного обеспечения продолжать функционирование при наличии ошибок.

Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту — правильному или неправильному). А, во-вторых, добавление в программу дополнительных средств приводит к её усложнению (иногда — значительному), что в какой-то мере мешает методам предупреждения ошибок.

59. Раскрыть понятие динамической избыточности

Истоки концепции динамической избыточности лежат в проектировании аппаратного обеспечения. Один из подходов к динамической избыточности — метод голосования. Данные обрабатываются независимо несколькими идентичными устройствами, и результаты сравниваются. Если большинство устройств выработало одинаковый результат, этот результат и считается правильным. И опять, вследствие особой природы ошибок в программном обеспечении ошибка, имеющаяся в копии программного модуля, будет также присутствовать во всех других его копиях, поэтому идея голосования здесь, видимо, неприемлема. Предлагаемый иногда подход к решению этой проблемы состоит в том, чтобы иметь несколько неидентичных копий модуля. Это значит, что все копии выполняют одну и ту же функцию, но либо реализуют различные алгоритмы, либо созданы разными разработчиками. Этот подход бесперспективен по следующим причинам. Часто трудно получить существенно разные версии модуля, выполняющие одинаковые функции. Кроме того, возникает необходимость в дополнительном программном обеспечении для организации выполнения этих версий параллельно или последовательно и сравнения результатов. Это дополнительное программное обеспечение повышает уровень сложности системы, что, конечно, противоречит основной идее предупреждения ошибок — стремиться в первую очередь минимизировать сложность.

Второй подход к динамической избыточности — выполнять эти запасные копии только тогда, когда результаты, полученные с помощью основной копии, признаны неправильными. Если это происходит, система автоматически вызывает запасную копию. Если и ее результаты неправильны, вызывается другая запасная копия и т. д.

60. Аналитические модели надежности

Модели надежности программных средств (МНПС) подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели).

Аналитическое моделирование надежности ПС включает четыре шага:

1) определение предположений, связанных с процедурой тестирования ПС;

2) разработка или выбор аналитической модели, базирующейся на предположениях о процедуре тестирования;

3) выбор параметров моделей с использованием полученных данных;

4) применение модели — расчет количественных показателей надежности по модели.

Проект к данной лекции Вы можете скачать здесь.

Корректность и устойчивость

Корректность и устойчивость - два основных качества программной системы, без которых все остальные ее достоинства не имеют особого смысла.

Корректность - это способность программной системы работать в строгом соответствии со своей спецификацией. Отладка - процесс, направленный на достижение корректности.

Понятие корректности программной системы имеет смысл только тогда, когда задана ее спецификация. В зависимости от того, как формализуется спецификация, уточняется понятие корректности.

Во время работы системы могут возникать ситуации, которые выходят за пределы, предусмотренные спецификацией. Такие ситуации называются исключительными.

Устойчивость - это способность программной системы должным образом реагировать на исключительные ситуации. Обработка исключительных ситуаций - процесс, направленный на достижение устойчивости.

Почему так трудно создавать корректные и устойчивые программные системы? Все дело в сложности разрабатываемых систем. Когда в 60-х годах прошлого века фирмой IBM создавалась операционная система OS-360 , то на ее создание потребовалось 5000 человеко-лет, и проект по сложности сравнивался с проектом высадки первого человека на Луну. Сложность нынешних сетевых операционных систем, систем управления хранилищами данных, прикладных систем программирования на порядок превосходит сложность OS-360 , так что, несмотря на прогресс, достигнутый в области технологии программирования, проблемы, стоящие перед разработчиками, не стали проще.

Жизненный цикл программной системы

Под " жизненным циклом " понимается период от замысла программного продукта до его "кончины". Обычно рассматриваются следующие фазы этого процесса:

Проектирование Разработка Развертывание и Сопровождение

Все это называется циклом, поскольку после каждой фазы возможен возврат к предыдущим этапам. В объектной технологии этот процесс является бесшовным, все этапы которого тесно переплетены. Не следует рассматривать его как однонаправленный - от проектирования к сопровождению. Чаще всего, ситуация обратная: уже существующая реализация системы, прошедшая сопровождение, и существующие библиотеки компонентов оказывают решающее влияние на то, какой будет новая система, каковы будут ее спецификации.

Вот некоторые типовые правила, характерные для процесса разработки ПО .

Уделяйте этапу проектирования самое пристальное внимание. Успех дела во многом определяется первым этапом. Нет смысла торопиться с переходом на последующие этапы, пока не составлены ясные и четкие спецификации. Ошибки этого этапа- самые дорогие и трудно исправляемые.
Помните о тех, для кого разрабатывается программный продукт. Идите "в люди", чтобы понять, что нужно делать. Вместе с тем не следует полностью полагаться на пользователей - их опыт консервативен, новые идеи могут часто приходить от разработчиков, а не от пользователей.
Разработка не начинается "с нуля". Только используя уже готовые компоненты, можно своевременно создать новую систему. Работая над проектом, думайте о будущем создавайте компоненты, допускающие их повторное использование в других проектах.
Создавайте как можно раньше прототип своей системы и передавайте его пользователям в опытную эксплуатацию. Это поможет устранить множество недостатков и ошибок в заключительной версии программного продукта.
Какие бы хорошие спецификации не были написаны, какими бы хорошими технологиями и инструментами не пользовались разработчики, какими бы профессионалами они ни были - этого еще не достаточно для успеха дела. Необходимым условием является управление проектом, наличие специальных средств управления. Но и этого не достаточно. Третьим важным фактором является существование команды. Коллектив разработчиков должен представлять собой единый коллектив. Умение работать в команде так же важно, как и профессиональные навыки разработчика.

Три закона программотехники

Первый закон (закон для разработчика)

Корректность системы - недостижима. Каждая последняя найденная ошибка является предпоследней.

Этот закон отражает сложность нетривиальных систем. Разработчик всегда должен быть готов к тому, что в работающей системе имеются ситуации, в которых система работает не в точном соответствии со своей спецификацией, так что от него может требоваться очередное изменение либо системы, либо ее спецификации. Как следствие, отсюда вытекает важность обеспечения устойчивости системы .

Второй закон (закон для пользователя)

Не бывает некорректных систем. Каждая появляющаяся ошибка при эксплуатации системы - это следствие незнания спецификации системы.

Есть два объяснения справедливости второго закона. Несерьезное объяснение состоит в том, что любая система, что бы она ни делала, при любом постусловии корректна по отношению к предусловию False , поскольку невозможно подобрать ни один набор входных данных, удовлетворяющих этому предусловию. Так что все системы корректны, если задать False в качестве их предусловия. Если вам пришлось столкнуться с системой, предусловие которой близко к False , то лучшее, что можно сделать, это отложить ее в сторону и найти другую.

Более поучительна реальная ситуация, подтверждающая второй закон и рассказанная мне в былые годы Виталием Кауфманом - специалистом по тестированию трансляторов. В одной серьезной организации была разработана серьезная прикладная система, имеющая для них большое значение. К сожалению, при ее эксплуатации сплошь и рядом возникали ошибки, из-за которых организация вынуждена была отказаться от использования системы. Разработчики обратились к нему за помощью. Он, исследуя систему, не внес в нее ни строчки кода. Единственное, что он сделал, это вместе с разработчиками описал точную спецификацию системы, благодаря чему стала возможной нормальная эксплуатация.

Обратите внимание на философию, характерную для этих законов: при возникновении ошибки разработчик и пользователь должны винить себя, а не кивать друг на друга. Так что часто встречающиеся фразы: "Ох, уж эта фирма Чейтософт, вечно у них ошибки!" характеризует, мягко говоря, непрофессионализм пользователя.

Третий закон (закон чечако)

Если спецификацию можно нарушить, она будет нарушена. Новичок (чечако) способен "подвесить" любую систему.

Неквалифицированный пользователь в любом контексте всегда способен выбрать наименее подходящее действие, явно не удовлетворяющее спецификации, которая ориентирована на "разумное" поведение пользователей. Полезным практическим следствием этого закона является привлечение к этапу тестирования системы неквалифицированного пользователя - "человека с улицы".

Надежный код

Что должно делать для создания корректного и устойчивого программного продукта? Как минимум , необходимо:

создавать код, корректность которого предусматривается с самого начала;
отладить этот код;
предусмотреть в нем обработку исключительных ситуаций.

Создание надежного кода

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

Для повышения надежности нужно уменьшить сложность системы, и главное в этом процессе - это повторное использование. В идеале большая часть системы должна быть собрана из уже готовых компонентов. Объектная технология проектирования вносит свой вклад в повышение надежности кода. Наследование и универсализация позволяют, не изменяя уже существующие классы, создать новые классы, новые типы данных, придающие проектируемой системе новые свойства при минимальных добавлениях нового кода. Статический контроль типов дает возможность выявить многие ошибки еще на этапе компиляции. Динамическое связывание и полиморфизм позволяют автоматически включать объекты классов-потомков в уже существующие схемы работы - методы родителя могут вызывать методы потомков, не зная о появлении этих новых потомков. Автоматическая сборка мусора дает возможность снять с разработчика обязанности управления освобождением памяти и предотвратить появление крайне неприятных и опасных ошибок, связанных с некорректным удалением объектов.

Крайне важную роль в создании надежного кода играют спецификации методов класса, класса в целом, системы классов. Спецификации являются частью документации, встроенной в проект, и вообще важной его частью. Их существование облегчает не только создание корректного кода, соответствующего спецификации, но и создание системы тестов, проверяющих корректность кода. Существуют специальные инструментальные средства, поддерживающие автоматическое создание тестов на основе спецификаций. Незаменима роль спецификаций на этапе сопровождения и повторного использования компонентов. Невозможно повторно использовать компонент , если у него нет ясной и полной спецификации.

Написать программную систему нетрудно. Это может сделать каждый. Значительно сложнее написать ее так, чтобы она корректно решала задачи пользователя. Корректность системы - это не внутреннее понятие, подлежащее определению в терминах самой системы. Корректность определяется по отношению к внешним спецификациям системы. Если нет спецификаций, то говорить о корректности "некорректно".

Корректность методов

Спецификации метода можно задавать по -разному. Определим их здесь через понятия предусловий и постусловий метода, используя символику триад Xoара, введенных Чарльзом Энтони Хоаром - выдающимся программистом и ученым.

Пусть P(x,z) - метод P с входными аргументами x и выходными z . Пусть Q(y) - некоторое логическое условие ( предикат ) над переменными y . Предусловием метода P(x,z) будем называть предикат Pre(x) , заданный на входах метода. Постусловием метода P(x,z) будем называть предикат Post(x,z) , связывающий входы и выходы метода. Для простоты будем полагать, что метод P не изменяет своих входов x в процессе своей работы. Теперь несколько определений:

Определение 1 ( частичной корректности ). Метод P(x,z) корректен (частично, или условно) по отношению к предусловию Pre(x) и постусловию Post(x,z) , если из истинности предиката Pre(x) следует, что для метода P(x,z) , запущенного на входе x , гарантируется выполнение предиката Post(x,z) при условии завершения метода на этом входе.

Условие частичной корректности записывается в виде триады Хоара, связывающей метод с его предусловием и постусловием:

Определение 2 ( полной корректности ). Метод P(x,z) корректен (полностью, или тотально) по отношению к предусловию Pre(x) и постусловию Post(x,z) , если из истинности предиката Pre(x) следует, что для метода P(x,z) , запущенного на входе x , гарантируется его завершение и выполнение предиката Post(x,z) в точке завершения метода.

Условие полной корректности записывается в виде триады Хоара, связывающей программу с ее предусловием и постусловием:

Доказательство полной корректности обычно состоит из двух независимых этапов - доказательства частичной корректности и доказательства завершаемости программы. Заметьте, полностью корректная программа , которая запущена на входе, не удовлетворяющем ее предусловию, вправе зацикливаться, вправе возвращать любой результат. Любая программа корректна по отношению к предусловию, заданному тождественно ложным предикатом False . Любая завершающаяся программа корректна по отношению к постусловию, заданному тождественно истинным предикатом True .

Формальное доказательство корректности метода - задача ничуть не проще, чем написание корректной программы. Но вот парадокс. Чем сложнее метод, его алгоритм , а следовательно, и само доказательство , тем важнее использовать понятия предусловий и постусловий, понятия инвариантов циклов в процессе разработки метода. Рассмотрение этих понятий параллельно с разработкой метода может существенно облегчить построение корректного метода.

Инварианты и варианты цикла

Циклы, как правило, являются наиболее сложной частью метода, большинство ошибок связано именно с ними. При написании корректно работающих циклов крайне важно понимать и использовать понятия инварианта и варианта цикла. Без этих понятий не обходится формальное доказательство корректности циклов. Но и неформальное понимание правильности работы программы основано на этих понятиях.

Рассмотрим цикл в форме, к которой можно привести все виды циклов:

Здесь B - условие цикла while , S - его тело, а Init - группа предшествующих операторов, задающая инициализацию цикла. Реально ни один цикл не обходится без инициализирующей части. Синтаксически было бы правильно, чтобы Init являлся бы формальной частью оператора цикла. В операторе for это частично сделано - инициализация счетчиков является частью цикла.

Определение 3 ( инварианта цикла ). Предикат Inv(x, z) называется инвариантом цикла while , если истинна следующая триада Хоара:

Содержательно это означает, что из истинности инварианта цикла до начала выполнения тела цикла и из истинности условия цикла, гарантирующего выполнение тела, следует истинность инварианта после выполнения тела цикла. Сколько бы раз ни выполнялось тело цикла, его инвариант остается истинным.

Для любого цикла можно написать сколь угодно много инвариантов. Любое тождественное условие (2*2 =4) является инвариантом любого цикла. Поэтому среди инвариантов выделяются так называемые подходящие инварианты цикла. Они называются подходящими, поскольку позволяют доказать корректность цикла по отношению к его пред- и постусловиям. Как доказать корректность цикла? Рассмотрим соответствующую триаду:

Доказательство разбивается на три этапа. Вначале доказываем истинность триады:

Содержательно это означает, что предикат RealInv становится истинным после выполнения инициализирующей части. Далее доказывается, что RealInv является инвариантом цикла :

На последнем шаге доказывается, что наш инвариант обеспечивает решение задачи после завершения цикла:

Это означает, что из истинности инварианта и условия завершения цикла следует требуемое постусловие.

Определение 4 ( подходящего инварианта ). Предикат RealInv , удовлетворяющий условиям (*), (**), (***) называется подходящим инвариантом цикла .

С циклом связано еще одно важное понятие - варианта цикла , используемое для доказательства завершаемости цикла.

Определение 5 ( варианта цикла ). Целочисленное неотрицательное выражение Var(x, z) называется вариантом цикла, если выполняется следующая триада:

Содержательно это означает, что каждое выполнение тела цикла приводит к уменьшению значения его варианта. После конечного числа шагов вариант достигает своей нижней границы, и цикл завершается. Простейшим примером варианта цикла является выражение n - i для цикла

Пользоваться инвариантами и вариантами цикла нужно не только и не столько для того, чтобы проводить формальное доказательство корректности циклов. Они способствуют написанию корректных циклов . Правило корректного программирования гласит: "При написании каждого цикла программист должен определить его походящий инвариант и вариант". Задание предусловий, постусловий, вариантов и инвариантов циклов является такой же частью процесса разработки корректного метода, как и написание самого кода.

Трудно ли строить инварианты и варианты цикла? Необходима некоторая практика, но обычно понимание алгоритма означает и понимание инвариантов, обеспечивающих корректность работы алгоритма. Рассмотрим простой пример класса, методы которого вычисляют различные суммы элементов массива .

Ограничимся рассмотрением метода Sum1 . В качестве предусловия выберем следующий предикат Pre(x) :

В качестве подходящего инварианта цикла выберем предикат Inv(x, S, i) :

$Inv(x,S,i): |left ( S = \sum\limits_<k=0></p> ^ \right ) & & (i \le x.Length)$

Содержательно инвариант говорит, что на каждом шаге цикла S представляет сумму элементов начального отрезка массива. В качестве постусловия метода Post(x, S) выберем предикат:

$S = \sum\limits_<k=0></p> ^$

Постусловие отражает требование к методу - по его завершению S должно представлять сумму элементов массива . Нетрудно строго доказать, что метод Sum1 корректен по отношению к заданным спецификациям - предусловию и постусловию. Другими словами, справедлива истинность триады Хоара:

Формального доказательства приводить не буду. Понятно, что инициализация обеспечивает истинность инварианта, поскольку по определению для пустого множества функция ? равна нулю. Выполнение тела цикла сохраняет истинность инварианта, а из условия завершаемости цикла и истинности инварианта следует предусловие. В момент завершения цикла счетчик цикла i принимает значение x.Length .

Очевидно, что имеет место завершаемость цикла, вариантом которого является выражение x.Length - i .

Что должен понимать начинающий программист, осваивающий азы программирования, в задачу которого входит написание программы вычисления суммы элементов масива? Он должен понимать, что на каждом шаге выполнения цикла переменная S представляет сумму начального отрезка массива. Вначале отрезок пуст и сумма равна нулю. Когда цикл завершается, начальный отрезок совпадает со всем массивом. В этом суть алгоритма, и инвариант отражает эту суть.

Метод Sum4 также корректен по отношению к тем же предикатам. Небольшое отличие существует в предусловии, требующем, чтобы массив был не пуст. Методы Sum2 и Sum3 вычисляют сумму части массива и не гарантируют корректности по отношению к заданным спецификациям. Хотя, конечно, можно изменить предусловие и постусловие так, чтобы методы были корректны по отношению к ним. Другое дело, устроит ли пользователя такая спецификация. Еще раз повторяю, без спецификации нельзя говорить о корректности.

Важной и неотъемлемой частью компьютера являются программные средства. Именно с помощью них и осуществляется вся работа с компьютером, выполнение на нем нужных задач. Разрабатываются самые различные программы, что существенно упрощает работу и жизнь многих людей. Функционирование современных компьютеров невозможно без установки необходимых программных средств.

Выбранная тема очень актуальна в нынешнее время, так как происходит всё более глобальная компьютеризация общества. Разрабатываются и совершенствуются программные средства.

В работе будут рассмотрены следующие вопросы: особенности современных программных средств; основные подходы к организации процесса создания и использования ПС; особенности разработки программных средств; критерии качества ПС; стадии и фазы жизненного цикла ПС.

В практической части курсовой работы решена задача – подведение итогов о результатах расчета стоимости по полученному заказу за октябрь 2006 года фирмы ООО «Стройдизайн» по каждому виду работ, которая решена с использованием MS Excel.

Курсовая работа выполнена и оформлена с использованием ПК с техническими характеристиками:

Процессор: AMD Turion 64 MT-32, оперативно запоминающее устройство (ОЗУ) объемом 384 Г, жесткий диск объемом 80 Г, видеочип: SiS M760.

Программные средства:

Операционная система Microsoft Windows XP Professional версия 2002 Service Pack 2, пакет офисных приложений Microsoft Office 2007: MS Word, MS Excel, MS Power Point.

«Общие принципы разработки программных средств»

Теоретическая часть

Вариант 32.

Введение

Объектом изучения в данной работе являются принципы разработки программных средств. Предметом изучения в данной работе является разработка программных средств.

Классификация программных средств

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

Среди программных средств можно выделить три класса: системное программное обеспечение; инструментарий технологии программирования; прикладное программное обеспечение.

Системное программное обеспечение подразделяется на базовое и сервисное. Базовое программное обеспечение делится на: базовые системы ввода-вывода (BIOS); операционные системы; операционные оболочки.

Инструментарий технологий программирования представляет собой совокупность программных систем, обеспечивающих процесс разработки программного обеспечения. Инструментальное ПО предназначено для разработки программ.

Прикладное программное обеспечение – ПО, предназначенное для эффективной разработки и выполнения конкретных комплексов задач пользователя. Основную часть прикладного ПО составляют пакеты прикладных программ (ППП). 1

1 Б.Е. Одинцов, А.Н. Романов Информатика в экономике.

Специфика разработки программных средств

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

На каждом этапе разработки создателю необходимо сделать выбор и принять какое-то решение. Поэтому разработка ПС не может быть выполнена строго по определенному шаблону .Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству.

Разработка программных средств требует учета особенностей структуры экономических систем. Прежде всего — это сложность организационного взаимодействия, которая вызывает необходимость создания многоуровневых иерархических систем со сложными информационными связями прямого и обратного направления. В основу новой информационной технологии закладывается широкое применение компьютеров и формирование на их базе вычислительных сетей. 2

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

Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов. Смысл этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы.

Разработка ПС имеет и другую специфическую особенность: программное средство при своей эксплуатации не расходуется и не расходует используемых ресурсов.

2 Г.А. Титоренко и др. Автоматизированные информационные технологии в экономике

Период разработки и эксплуатации программного средства

Под периодом разработки и эксплуатации понимают жизненный цикл ПС. Жизненный цикл охватывает довольно сложный процесс создания и использования ПС. Этот процесс может быть организован по-разному для разных классов ПС и в зависимости от особенностей разработки.

Различают следующие стадии жизненного цикла программного средства: разработку программного средства, производство программных изделий (ПИ) и эксплуатацию программного средства (приложение 1).

Стадия разработки программного средства состоит из этапа его внешнего описания, этапа конструирования программного средства, этапа кодирования (программирование в узком смысле) программного средства и этапа аттестации программного средства. Всем этим этапам сопутствуют процессы документирования и управление разработкой программного средства. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.

Внешнее описание программного средства является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание программного средства начинается с определения требований к программному средству со стороны пользователей (заказчика).

Конструирование программного средства охватывает процессы: разработку архитектуры программного средства, разработку структур программ программного средства и их детальную спецификацию, кодирование, создание текстов программ на языках программирования, их отладку с тестированием программного средства.

На этапе аттестации программного средства производится оценка качества программного средства, после успешного завершения которого, разработка программного средства считается законченной.

Программное изделие - экземпляр или копия, снятая с разработанного программного средства. Изготовление программного изделия - это процесс генерации или воспроизведения (снятия копии) программ и программных документов программного средства с целью их поставки пользователю для применения по назначению.

Производство программного изделия - это совокупность работ по обеспечению изготовления требуемого количества программных изделий в установленные сроки. Стадия производства программного средства в жизненном цикле программного средства является не существенной, так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники.

Стадия эксплуатации программного средства охватывает процессы хранения, внедрения и сопровождения программного средства, а также транспортировки и применения программного изделия по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения программного средства и фазы сопровождения программного средства.

Применение программного средства - это использование программного средства для решения практических задач на компьютере путем выполнения ее программ.

Сопровождение программного средства - это процесс сбора информации о качестве его в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях.

Понятие качества ПС

Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано.

Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством.

Качество ПС - Совокупность свойств программного средства, которые обусловливают его пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с его назначением. 3

Но это не значит, что ПС должны в высшей мере обладать этими свойствами. Этому препятствует тот факт, что повышение качества программного средства по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого программного средства по другим его свойствам

Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.

Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС.

Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПС.

В настоящее время критериями качества ПС принято считать:

3 ГОСТ 28806-90 Качество программных средств. Термины и определения.

Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.

Надежность - это характеристика ПС отвечать и полагаться заданным стандартам.

Легкость применения - это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

Сопровождаемость - это характеристики ПС, которые позволяют сократить усилия по внесению изменений для устранения в нем ошибок.

Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одного компьютера на другой.

Функциональность и надежность являются обязательными критериями качества ПС, причем обеспечение надежности будет красной нитью проходить по всем этапам и процессам разработки ПС.

Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС.

Общие принципы обеспечения надежности ПС

Общие принципы обеспечения надежности являются основным мотивом разработки программного средства. Они задают специфическую окраску всем технологическим процессам разработки программного средства.

В технике известны четыре подхода обеспечению надежности: предупреждение ошибок; самообнаружение ошибок; самоисправление ошибок; обеспечение устойчивости к ошибкам.

Целью подхода «предупреждения ошибок» является не допустить ошибки в программном средстве. Этот подход связан с технологией программирования. И хотя гарантировать отсутствие ошибок в программном средстве невозможно, в рамках этого подхода можно достигнуть приемлемого уровня надежности программного средства.

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

Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения.

Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства.

Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа.

Однако эти подходы используются весьма редко. Связано это с тем, что многие простые методы, используемые в технике, неприменимы в программировании.

Методы борьбы со сложностью и контроль принимаемых решений

Известны два общих метода борьбы со сложностью систем:

- обеспечение независимости компонент системы;

- использование в системах иерархических структур.

Обеспечение независимости компонент системы означает разбиение системы на такие части, между которыми должно остаться по возможности меньше связей. Одним из воплощений этого метода является модульное программирование.

Использование иерархических структур позволяет локализовать связи между компонентами, принадлежащими смежным уровням иерархии. Этот метод означает разбиение большой системы на подсистемы, образующие малую систему.

Обязательным шагом в каждом этапе разработки программного средства должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии.

С учетом специфики разработки программного средства необходимо применять везде, где это возможно:

- сочетание как статических, так и динамических методов контроля.

Смежный контроль означает проверку полученного документа лицами, не участвующими в его разработке. Такой контроль позволяет обеспечивать однозначность интерпретации полученного документа.

Сочетание статических и динамических методов контроля означает, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Это отражает одну из специфических особенностей программного средства (статическая форма, динамическое содержание).

Заключение

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

Принципы разработки программных средств будут изменяться и совершенствоваться с каждым днем, так как технический прогресс не стоит на месте. С помощью программных средств решается всё больше задач разного типа. Разрабатываются узко профильные программные средства и средства общего пользования.

Из всего этого следует, что разработка программных средств занимает важное место в технической сфере.

Сегодня российская отрасль разработки программных средств занимает очень скромное место в отечественной экономике (0,15% ВВП). Но инициатива поддержки российской индустрии разработки ПС уже в настоящий момент находится в стадии развертывания. 4

4 Аналитический сайт. Роль Microsoft в развитии инновационного потенциала России.

Практическая часть

Вариант 7

Общая характеристика задачи

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

Фирма ООО «Стройдизайн» осуществляет деятельность, связанную с выполнением работ по ремонту помещений. Прайс-лист на выполнение работы приведен на рис.1. Данные о заказанных работах указаны на рис.2.

Читайте также: