Проверка валидности данных

Где и как осуществлять ее?
(по материалам форума electronix.ru)

1. Проверка данных может производится как:

* по каждой переменной, например, переменная (параметр, установка, уставка и т.д.) укладывается в допустимые пределы.
(Пример из электроники — допустимый ток коллектора транзистора не может превышать 10А).

* так и на предмет того, что переменные, находясь каждая в своем диапазоне допустимых значениях, в совокупности тоже не нарушают какие-то правила.
(Пример из электроники, Ток коллектора транзистора не превышает 10А, напряжение на коллекторе — тоже не превышает заданных 60В. Но в совокупности эти два параметра задают рассеиваемую на коллекторе мощность (10А * 60В = 600Вт), которая превышает допустимую мощность транзистора (100Вт))

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

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

3. Определитесь с тем, откуда ожидаете «приход помехи». Я имею ввиду следующее:

— это будет человеческий фактор:

3.1. Оператор, конечный пользователь ввел не то значение

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

— либо это будет аппаратный сбой:

3.3. На вход поступили данные, которые явно не укладываются в заданные рамки. (Например, измеряем напряжение и ожидаем получить от 0 и максимум до +5.5 В, а придурок Вася сунул наш вольтметр в розетку. Ничего не сдохло, но на вход АЦП пришли та-а-акие данные, что непонятно что с ними дальше делать.)

3.4. Через МК прошла космическая частица с высокой энергией и изменила ячейку в памяти. Данные исказились.

Рассмотрим по порядку:

В первом случае, проверка нужна обязательно. Нужно производить проверки при каждом вводе пользователя.

Во втором случае, нужно тоже производить всяческие проверки. Но когда отработка программы закончится, то в release-версии нужно удалить все проверки.

Третий случай — тут проверка нужна обязательно. Причем только в этом месте (бороться с помехой в месте ее возникновения).

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

В своих изделиях я руководствуюсь изложенными выше принципами. Но это совсем необязательно, что я поступаю только так, а не иначе. Жизнь очень сложная, и заранее сказать что и как правильно следует делать — очень сложно. Чтобы советовать что-то дельное, нужно «быть в теме».

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s