11.5. Обеспечение устойчивости программного средства.
Этот примитив качества обеспечивается с помощью так называемого защитного программирования. Вообще говоря, защитное программирование применяется для повышения надежности ПС при программировании модуля в более широком смысле. Как утверждает Майерс [11.3], "защитное программирование основано на важной предпосылке: худшее, что может сделать модуль, - это принять неправильные входные данные и затем вернуть неверный, но правдоподобный результат". Для того, чтобы этого избежать, в текст модуля включают проверки его входных и выходных данных на их корректность в соответствии со спецификацией этого модуля, в частности, должны быть проверены выполнение ограничений на входные и выходные данные и соотношений между ними, указанные в спецификации модуля. В случае отрицательного результата проверки возбуждается соответствующая исключительная ситуация. В связи с этим в конец этого модуля включаются фрагменты второго рода - обработчики соответствующих исключительных ситуаций, которые помимо выдачи необходимой диагностической информации, могут принять меры либо по исключению ошибки в данных (например, потребовать их повторного ввода), либо по ослаблению влияния ошибки (например, мягкую остановку управляемых ПС устройств во избежание их поломки при аварийном прекращении выполнения программы).
Применение защитного программирования модулей приводит снижению эффективности ПС как по времени, так и по памяти. Поэтому необходимо разумно регулировать степень применения защитного программирования в зависимости от требований к надежности и эффективности ПС, сформулированным в спецификации качества разрабатываемого ПС. Входные данные разрабатываемого модуля могут поступать как непосредственно от пользователя, так и от других модулей. Наиболее употребительным случаем применения защитного программирования является применение его для первой группы данных, что и означает реализацию устойчивости ПС. Это нужно делать всегда, когда в спецификации качества ПС имеется требование об обеспечении устойчивости ПС. Применение защитного программирования для второй группы входных данных означает попытку обнаружить ошибку в других модулях во время выполнения разрабатываемого модуля, а для выходных данных разрабатываемого модуля - попытку обнаружить ошибку в самом этом модуле во время его выполнения. По-существу, это означает частичное воплощение подхода самообнаружения ошибок для обеспечения надежности ПС, о чем шла речь в лекции 3. Этот случай защитного программирования применяется крайне редко - только в том случае, когда требования к надежности ПС чрезвычайно высоки.
- 1. Программное средство как продукт технологии программирования
- 1.1. Программа как формализованное описание процесса обработки данных. Программное средство.
- 1.2. Неконструктивность понятия правильной программы.
- 1.3. Надежность программного средства.
- 1.4. Технология программирования как технология разработки надежных программных средств
- 1.5. Технология программирования и информатизация общества.
- 2. Источники ошибок в программных средствах
- 2.1. Интеллектуальные возможности человека.
- 2.2. Неправильный перевод как причина ошибок в программных средствах.
- 2.3. Модель перевода.
- 2.4. Основные пути борьбы с ошибками.
- 3. Общие принципы разработки программных средств
- 3.1. Специфика разработки программных средств.
- 3.2. Жизненный цикл программного средства.
- 3.3. Понятие качества программного средства.
- 3.4. Обеспечение надежности - основной мотив разработки программных средств.
- 3.5. Методы борьбы со сложностью.
- 3.6. Обеспечение точности перевода.
- 3.7. Преодоление барьера между пользователем и разработчиком.
- 3.8. Контроль принимаемых решений.
- 4. Внешнее описание программного средства
- 4.1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства.
- 4.2. Определение требований к программному средству.
- 4.3. Спецификация качества программного средства.
- 4.4. Функциональная спецификация программного средства.
- 4.5. Методы контроля внешнего описания программного средства.
- 5. Методы спецификации семантики функций
- 5.1. Основные подходы к спецификации семантики функций.
- 5.2. Метод таблиц решений.
- 5.3. Операционная семантика.
- 5.4. Денотационная семантика.
- 5.5. Аксиоматическая семантика.
- 5.6. Языки спецификаций.
- 6. Архитектура программного средства
- 6.1. Понятие архитектуры программного средства.
- 6.2. Основные классы архитектур программных средств.
- 6.3. Архитектурные функции.
- 6.4. Контроль архитектуры программных средств.
- 7. Разработка структуры программы и модульное программирование
- 7.1. Цель модульного программирования.
- 7.2. Основные характеристики программного модуля.
- 7.3. Методы разработки структуры программы.
- 7.4. Контроль структуры программы.
- 8. Разработка программного модуля
- 8.1. Порядок разработки программного модуля.
- 8.2. Структурное программирование.
- 8.3. Пошаговая детализация и понятие о псевдокоде.
- 8.4. Контроль программного модуля.
- 9. Доказательство свойств программ
- 9.1. Обоснования программ. Формализация свойств программ.
- 9.2. Свойства простых операторов.
- 9.3. Свойства основных конструкций структурного программирования.
- 9.4. Завершимость выполнения программы.
- 9.5. Пример доказательства свойства программы.
- 10. Тестирование и отладка программного средства
- 10.1. Основные понятия.
- 10.2. Принципы и виды отладки.
- 10.3. Заповеди отладки.
- 10.4. Автономная отладка модуля.
- 10.5. Комплексная отладка программного средства.
- 11. Обеспечение функциональности и надежности программного средства
- 11.1. Функциональность и надежность как обязательные критерии качества программного средства.
- 11.2. Обеспечение завершенности программного средства.
- 11.3. Обеспечение точности программного средства.
- 11.4. Обеспечение автономности программного средства.
- 11.5. Обеспечение устойчивости программного средства.
- 11.6. Обеспечение защищенности программных средств.
- 12. Обеспечение качества программного средства
- 12.1. Общая характеристика процесса обеспечения качества программного средства.
- 12.2. Обеспечение легкости применения программного средства.
- 12.3. Обеспечение эффективности программного средства.
- 12.4. Обеспечение сопровождаемости.
- 13. Документирование программных средств
- 13.1. Документация, создаваемая в процессе разработки программных средств.
- 13.2. Пользовательская документация программных средств.
- 13.3. Документация по сопровождению программных средств.
- 14. Аттестация программного средства
- 14.1. Назначение аттестации программного средства.
- 14.2. Виды испытаний программного средства.
- 14.3. Методы оценки качества программного средства.
- 15. Оъектный подход к разработке программных средств
- 15.1. Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.
- 15.2. Объектный и субъектный подходы к разработке программных средств.
- 15.3. Объектный подход к разработке внешнего описания и архитектуры программного средства.
- 16. Компьютерная поддержка разработки и сопровождения программных средств
- 16.1. Инструменты разработки программных средств.
- 16.2. Инструментальные среды разработки и сопровождения программных средств.
- 16.3. Инструментальные среды программирования.
- 16.4. Понятие компьютерной технологии разработки программных средств и ее рабочие места.
- 16.5. Инструментальные системы технологии программирования.