Реклама:

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

Поскольку в этом случае операционная система считала бы, что с базой данных все в порядке, она позволила бы прикладным программам работать и обращаться к базе данных. Рано или поздно встретятся ошибки в данных, и если программы не рассчитаны на их обработку, то на пульте оператора появятся некоторые невразумительные ошибочные сообщения. Более поздние версии систем управления базами данных (СУБД) содержали встроенные подпрограммы обнаружения ошибок, способные «завернуть» программу обратно, чтобы она проследила свои шаги до того места, где были обработаны последние «хорошие» данные. Затем программа до своего повторного запуска должна ожидать ручной или автоматической «прочистки» данных.

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

1) Eugene Ionesco, Rhinoceros, act 2. 8-1068

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

В настоящей главе мы рассматриваем такие проблемы и предлагаем подход к логическому конструированию требуемого процесса «отмены» с применением методики Джексона.

5.1. Ситуация отката

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

Кинг Д. Создание эффективного программного обеспечения

Рис. 5.1. Контрольные итоги - входная структура.

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

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

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

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


⇐ Предыдущая страница| |Следующая страница ⇒