Реклама:

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

Нам следует обсудить еще один тип несоответствия. Проиллюстрируем его на следующем примере. (Этот пример подсказан автору описанием сходной проблемы в книге М. Джексона [5].)

Рассмотрим ситуацию в ресторане, пользующемся популярностью. Его владелец, стремясь повысить производительность своего персонала, приобрел автоматизированную систему приема заказов. Каждый официант располагает терминалом, в который вводятся заказы на блюда по мере их поступления от клиентов, сидящих за столами. После того, как заказ подтвержден официантом нажатием клавиши «ПРИНЯТЬ», он печатается на кухне, и шеф-повар со свои-ми помощниками приступают к приготовлению указанных блюд. Кухонному персоналу фактически незачем знать, кто заказал то или идее блюдо, но официанту нужно разбираться, от кого он принял заказ, а также на какой стол и какому посетителю нужно доставить эти блюда, когда они будут готовы. Данная система оказывается очень эффективной, поскольку она, во-первых, экономит время, а во-вторых, • качественно повышает точность и надежность передачи информации из зала на кухню.

Например, поток записей на кухню мог бы оказаться таким:

ОФИЦИАНТ 1 :СТ0Л 1: ЗАКАЗ 1: ЗАКУСКА: САЛАТ ИЗ КРЕВЕТОК ОФИЦИАНТКА 3 : СТОЛ 4: ЗАКАЗ 2: ГОРЯЧЕЕ: ГРИБНОЙ СУП ОФИЦИАНТ 4 : СТОЛ 7: ЗАКАЗ 5: ГОРЯЧЕЕ: ЖАРЕНАЯ ГРУДИНКА ОФИЦИАНТ 1 :СТ0Л 1: ЗАКАЗ 1: ЗАКУСКА: КЕТА ОФИЦИАНТ 4 : СТОЛ 7: ЗАКАЗ 5: ГОРЯЧЕЕ: ТУШЕНОЕ МЯСО ОФИЦИАНТКА 3 : СТОЛ 4: ЗАКАЗ 2: ЗАКУСКА: ШПИНАТ и так далее.

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

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

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

Рис. 7.6. Отчет по ресторану.

Рассмотрим структуры данных, относящиеся к этой проблеме. Они показаны на рис. 7.7.

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

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

Рис. 7.7. Структуры данных для отчета по ресторану.

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


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