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

Рис. 7.14. Структуры программ для разрешения граничного столкновения.

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

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

7.3. Разрешение перемешанного столкновения

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

Для отчета по ресторану существенно, чтобы каждая запись элемента заказа идентифицировалась как «принадлежащая» конкретному представителю обслуживающего персонала. Это требование легко соблюдается, потому что каждая запись фактически содержит идентификацию соответствующего официанта или официантки.

Поэтому структуру данных ЗАКАЗЫ можно изобразить по-другому, как показано на рис. 7.15.

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

Рис. 7.15. Измененная структура данных заказов.

Теперь входной файл можно рассматривать как повторение записей элементов заказов, каждый из которых исходит либо от официанта 1, либо от официанта 3, либо от официантки 4. (Мы ограничились только тремя представителями обслуживающего персонала, но, разумеется, их может быть и больше.) Если бы нам удалось извлечь, например, записи именно от официанта 1, эти записи находились бы в точно правильном порядке для получения относящейся к официанту 1 части выдаваемого отчета. На самом деле мы можем поступить даже лучше! Можно извлечь записи, относящиеся к каждому представителю обслуживающего персонала по отдельности, и поместить эти записи на отдельные файлы, по одному последовательному файлу на каждого представителя обслуживающего персонала.

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

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

Рис. 7.16. Блок-схема для программы составления отчета по ресторану.

Программа РА просто извлекает записи из входного потока заказов и помещает их в подходящие последовательные файлы и^З или иЧ. Затем по достижении Конца-файла заказов или требования прекратить обработку этих записей запускаются на счет программы РШ1, РШЗ и РиЧ. Каждая из этих программ подытоживает информацию соответственно в файлах иЧ, \№3 и Ш4 для получения итогового файла ШБ, который в свою очередь обрабатывается программой РБ для составления выдаваемого на выход отчета. Рассмотрим структуры данных, вовлеченные в эту систему (см. рис.7.17).

Мы уже обсуждали ранее входной файл ЗАКАЗЫ и поэтому нет необходимости объяснять его снова. Файл Ш1 структурно идентичен файлам \МЗ и \¥4 в том смысле, что каждый из этих файлов представляет собой просто записи из потока данных ЗАКАЗЫ, отобранные только для одного работника из обслуживающего персонала. Все элементы заказов от официанта 1, как только они появляются, помещаются в файл Ш1, от официантки 3 - в файл ШЗ, а от официанта 4 - в файл Ш4.


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