Обеспечение этого примитива связано с действиями над значениями вещественных типов (точнее говоря, со значениями, представляемыми с некоторой погрешностью). Обеспечить требуемую точность при вычислении значения той или иной функции - значит получить это значение с погрешностью, не выходящей за рамки заданных границ. Видами погрешности, методами их оценки и методами достижения требуемой точности (так называемыми приближенными вычислениями) занимается вычислительная математика [11.1, 11.2]. Здесь мы лишь обратим внимание на некоторую структуру погрешности: погрешность вычисленного значения (полная погрешность) зависит
от погрешности используемого метода вычисления (в которую мы включаем и неточность используемой модели),
от погрешности представления используемых данных (от т.н. неустранимой погрешности),
от погрешности округления (неточности выполнения используемых в методе операций).
Есть программы для решения математических задач, которые помогут Вам сэкономить немало времени
Этот примитив качества обеспечивается на этапе спецификации качества принятием решения об использовании в разрабатываемом ПС какого-либо подходящего базового программного обеспечения или не использовании в нем никакого базового программного обеспечения. При этом приходится учитывать как его надежность, так и требуемые для его использования ресурсы. При повышенных требованиях к надежности разрабатываемого ПС надежность базового программного обеспечения, имеющегося в распоряжении разработчиков, может оказаться неудовлетворительной, поэтому от его использования приходиться отказываться, а реализацию его функций в требуемом объеме приходится включать в состав ПС. Аналогичные решения приходится принимать при жестких ограничениях на используемые ресурсы (по критерию эффективности ПС).
Этот примитив качества обеспечивается с помощью так называемого защитного программирования. Вообще говоря, защитное программирование применяется для повышения надежности ПС при программировании модуля в более широком смысле. Как утверждает Майерс [11.3], "защитное программирование основано на важной предпосылке: худшее, что может сделать модуль, - это принять неправильные входные данные и затем вернуть неверный, но правдоподобный результат". Для того, чтобы этого избежать, в текст модуля включают проверки его входных и выходных данных на их корректность в соответствии со спецификацией этого модуля, в частности, должны быть проверены выполнение ограничений на входные и выходные данные и соотношений между ними, указанные в спецификации модуля. В случае отрицательного результата проверки возбуждается соответствующая исключительная ситуация. В связи с этим в конец этого модуля включаются фрагменты второго рода - обработчики соответствующих исключительных ситуаций, которые помимо выдачи необходимой диагностической информации, могут принять меры либо по исключению ошибки в данных (например, потребовать их повторного ввода), либо по ослаблению влияния ошибки (например, мягкую остановку управляемых ПС устройств во избежание их поломки при аварийном прекращении выполнения программы).
Применение защитного программирования модулей приводит снижению эффективности ПС как по времени, так и по памяти. Поэтому необходимо разумно регулировать степень применения защитного программирования в зависимости от требований к надежности и эффективности ПС, сформулированным в спецификации качества разрабатываемого ПС. Входные данные разрабатываемого модуля могут поступать как непосредственно от пользователя, так и от других модулей. Наиболее употребительным случаем применения защитного программирования является применение его для первой группы данных, что и означает реализацию устойчивости ПС. Это нужно делать всегда, когда в спецификации качества ПС имеется требование об обеспечении устойчивости ПС. Применение защитного программирования для второй группы входных данных означает попытку обнаружить ошибку в других модулях во время выполнения разрабатываемого модуля, а для выходных данных разрабатываемого модуля - попытку обнаружить ошибку в самом этом модуле во время его выполнения. По-существу, это означает частичное воплощение подхода самообнаружения ошибок для обеспечения надежности ПС, о чем шла речь в лекции 3. Этот случай защитного программирования применяется крайне редко - только в том случае, когда требования к надежности ПС чрезвычайно высоки.
