|
| |
 |
Главная » Мануалы 1 ... 12 13 14 15 16 17 18 ... 32 4.5.1. Поток данных для редактирования Следуя руководящим принципам разд. 4.3, можно разработать информационный потоковый граф для рассматриваемой системы по схеме от границ - внутрь . На рис. 4.19 показано первое представление ИПГ: от границ внутрь системы направлены потоки сигналов, снимаемых с клавиатуры, информация о структуре и характеристиках документа из таблицы описания текущей формы, а также символы или строки страницы, пересылаемые из памяти дисплея для печати. Потоки изнутри Сигналы нажатия клавиш  Строки страницы из памяти видео дисплея  Структура и характеристики формы о- Отображение введенной команды, наводящих сообщений и ответов  О Символы для \ заполнен форм! Симвопы для заполнения формь1 или строк страниць!  и 2; поле 4 не освобождает ни одной строки страницы; поле 5 освобождает строки 3 и 4; поле 6 - страничную строку 5 и т. д. Подобные перечни освобождаемых строк по каждому полю отражают неотъемлемые, неизменяемые свойства каждой конкретной формы и могут поэтому быть частью таблиц описания форм. системы к ее границам - это запросы звонка, символы, которые подлежат занесению в память дисплея (заметим, что к их числу относятся данные, обеспечивающие отображение курсора), и строки страницы для подсистемы построчной печати, Р1знутри системы исходят также запросы на печать строк страницы. Здесь предполагается, что фактические строки страницы для печати поступают непосредственно из памяти дисплея под управлением блока, отличного от механизма выдачи запросов на печать строк страницы; это предположение вполне логично, если принять во внимание способ освобождения строк страницы для печати путем последовательного просмотра полей. Теперь остается разработать внутренние элементы ИПГ для средней части системы. Однако в отличие от системы LIFE в данном случае ИПГ не является однолинейным. Поскольку параллельно выполняется несколько функций, в системе имеется несколько параллельных потоков. В качестве общей стратегии представляется разумным первоначальное рассмотрение таких параллельных ветвей по отдельности. В данном случае логично начать с рассмотрения той ветви, которая соответстзуст выполняемой на переднем плане функции редактирования формы. На рис. 4.20 показан расширенный ИПГ для выполняемой на переднем плане функции редактирования и вывода формы документа. Основной принцип, на основе которого строится этот граф,- раздельное управление логическим и физическим дисплеем. Управление логическим дисплеем связано только с обработкой и редактированием форм. На этом уровне формы рассматриваются как логические объекты независимо от того, каким образом они физически выводятся на экран. Управление физическим дисплеем, наоборот, связано лишь с такими элементами, как положение курсора на экране, занесение символов по абсолютному адресу местоположения на экране, поиск физических строк для печати и т. д. Управление физическим дисплеем не затрагивает логической интерпретации того, что выводится. Если положить в основу указанное разделение функций управления, то ИПГ получается естественным образом путем добавления модуля- дешифратора событий между потоком сигналов от клавиш и запросами на обращение к логическому дисплею, модуля управления выводом между потоком обращений к логическому дисплею и запросами доступа к физическому дисплею; на конце ветви должен быть помещен модуль управления физическим дисплеем. Мы используем здесь термин дешифратор событий , а не дешифратор команд потому, что хотим обеспечить возможность взаимодей-  Сигналы нажатия клавиш Q Запросы доступа к логическом/ дисплею  р Запросы доступа к физическому дисплею  Рис. 4.20. Расширенный ИПГ для функции редактирования и вывода формы, выполняемой на переднем плане. ствия этого модуля и с фоновой функцией печати. В таком виде он в результате будет связан не только с командами оператора, но и с событиями в системе печати. 4.5.2. Представление структуры для функции редактирования Весьма просто преобразовать полученный ИПГ в соответствующий структурный граф. Следуя принципам, изложенным в подразд. 4.4.3, мы сделаем модуль дешифратора событий задачей. Модуль управления логическим дисплеем нет необходимости оформлять как задачу, поскольку он используется дешифратором событий исключительно для выполняемой на переднем плане функции редактирования. Между функцией управления логическим дисплеем и фоновой функцией печати никогда не возникает никакого взаимодействия, поэтому можно сразу принять решение, что управление логическим дисплеем будет реализовано как пассивный пакет. При условии, что задача дешифратора событий осуществляет всю координацию между функциями переднего плана и фоновыми, относящимися к печати строк, отсутствует возможность конфликта между операциями доступа к управлению физическим дисплеем для целей редактирования и доступа к нему для поиска строк, подлежащих выводу на печать. Только в таком случае на данном этапе проектирования можно принять решение о том, что управление физическим дисплеем будет также реализовано пассивным пакетом. В противном случае могут возникать неприемлемые конфликты. Пока что мы будем считать модуль управления физическим дисплеем пассивным пакетом, а к вопросу о том, может ли возникнуть конфликтная ситуация, вернемся позже. На рис. 4.21 показаны внешние связи и внутренняя структура пакета управления логическим дисплеем. Он включает три интерфейсные процедуры, а именно NEW FORM (НОВАЯ ФОРМА), NEXT-FIELD (СЛЕДУЮЩЕЕ-ПОЛЕ) и EDIT-FIELD (РЕДАКТИРОВАНИЕ-ПОЛЯ). Обращение к процедуре NEW FORM должно предусматривать в качестве параметра номер формы. Внутри себя процедура NEW-FORM осуществляет доступ к той таблице описания формы, которая определяется номером этой формы, чтобы вывести на экран ее бланк (если номер формы не равен ООО), и устанавливает курсор в левый верхний угол первого поля этой формы (исходное положение). Ошибка в номере формы приводит к возврату из процедуры с указанием неверного параметра. Процедура NEXT-FIELD не требует передачи входных параметров, поскольку очередное поле определяется таблицей описания формы. Информация о требуемом положений курсора поступает в тело процедуры NEXT-FIELD из таблицы описания формы, после чего курсор переводится в указанное положение. Из тела процедуры NEXT-FIELD нужный номер поля пересылается внутреннему пакету редакти- БукЕенно-цифроаой символ или пробел  LOG!CAL DISPLAY MANAGEMENT Выбрать из памяти табпиау Определить требуемое положение Ввести символ в Идентифицировать Проверить Переместить описания формы, высветить курсора по таблице описания физический физическое по таблице курсор на экране пустой бланк формы и переместить курсор дисплей (если номер) ООО) и установить курсор в начальное положение )Изическое положение курсора по таблице курсор описания формы, не вышел ли курсор после перемещенив за границь! поля Рис. 4.21. Внешнее и внутреннее представления пакета управления логическимдасалссм. рования, который будет осуществлять детальное редактирование внутри данного поля. Процедура EDIT FIELD получает в качестве входного параметра код символа (любой буквенно-цифровой символ или символ возврата) и выдает в качестве результата код ошибки, когда неверен входной символ или выполнение функции редактирования приводит к нарушению границ поля. Телом процедуры EDIT FIELD просто передается конкретный символ ТОтноситепьное Абсолютное i положение положение
Рис. 4.22. Внешнее представление пакета управления физическим дисплеем. интерфейсной процедуре ENTER CHAR внутреннего пакета редактирования поля. Внутренний пакет FIELD EDIT получает информацию о том, какое поле является текущим, с помощью процедуры SET FIELD (УСТАНОВИТЬ-ПОЛЕ) и поэтому может реали-вать контроль таблицы описания текущей формы в отношении нарушения границ с помощью внутренней процедуры их проверки. Для установления текущего физического положения курсора, вывода символа на физический экран и перемещения курсора этот пакет обращается к пакету управления физическим дисплеем. На рис. 4.22 дано минимальное внешнее представление этого пакета, предусматривающее необходимый для управления логическим дисплеем сервис. Эти служебные функции обеспечиваются интерфейсными процедурами ENTER-CHARACTER (ВВЕСТИ-СИМВОЛ), CLEAR-DISPLAY (ОЧИСТИТЬ-ЭКРАН), MOVE-CURSOR (ПЕРЕВЕСТИ-КУРСОР) и CHECK-CURSOR (ПРОВЕРИТЬ-КУРСОР). 4.5.3. Поток данных для вывода на печать в фоновом режиме На рис. 4.23 дано детальное представление ИПГ в соответствии с требованиями к выполнению печати в фоновом режиме, Из рисунка видно, что для реализации этих операций не нужны никакие новые модули, но необходимы некоторые дополнительные потоки данных. На рис. 4.23 опущены все потоки данных, которые связаны исключительно с функцией редактирования. Проследим за формированием запроса NEXT-FIELD. Сначала прерывание, вызываемое набором символов NEXT-FIELD, воспринимается интерфейсом клавиатуры, и код этого набора символов пересылается дешифратору событий, который в свою очередь адресует запрос NEXT-FIELD модулю управления логическим дисплеем. На основании информации, полученной из таблицы описания текущей формы, этот модуль сообщает дешифратору событий диапазон (N...M) номеров строк страницы для печати. Дешифратор событий пересылает этот диапазон номеров строк построчно-печатающему устройству, которое принимает очередную строку страницы от пакета управления физическим дисплеем, печатает ее и затем посылает обратно дешифратору событий уведомление MORE-LINES (СЛЕ-ДУЮЩИЕ-СТРОКИ). Теперь становится ясным отличие дешифратора событий от дешифратора команд; назначение дешифратора событий состоит в обработке двух типов событий, а именно сигналов, поступающих от интерфейса клавиатуры, и уведомлений MORE-LINES ~ от построчно-печатающего устройства. Что же касается дешифратора команд, то его функции не столь сложны: он должен выполнять распознавание команд и их обработку; каждая из этих функций предполагает правильное управление формированием различных последовательностей событий. Поэтому представляется желательной дальнейшая детализация модуля дешифратора событий. Более подробно этот модуль представлен на рис. 4.23, б. Указанные выше функции выполняются здесь раздельными модулями: распознавателем команд и процессором команд с единым управляющим модулем, играющим роль координатора. Управляющий модуль пересылает сигналы нажатия клавиш распознавателю команд, который в свою очередь в процессе печатания сообщает коды команд процессору команд. Последний передает управляющему модулю диапазон (N ... М) строк, которые подлежат выводу на печать по окончании работы с конкретным полем. Управляющий модуль связан с модулями интерфейса клавиатуры и построчно-печатающего устройства, а процессор команд - с модулем управления логическим дисплеем. Заметим Попутно, что управляющий модуль должен обязательно получать сигнал о том, что строк для печати больше нет. На рис. 4.24 представлены конечные автоматы, реализующие функции модулей распознавателя команд и процессора команд. Команды редактирования формируются при нажатии одиночных клавиш и поэтому распознаются сразу. Команды START-EDIT требуют нажатия нескольких клавиш и, следовательно, нескольких стадий распознавания. Конечный автомат процессора команд необходим для того, чтобы предотвратить редактирование новой формы, пока не будет завершено печатание предыдущей. Событиями, вызывающими изменение состояния конечного автомата, являются получение команды START-EDIT, прием команды NEXT-FIELD, когда заполнено последнее поле формы, и поступление сигнала уведомления об окончании печати. Казалось бы, уведомление о новом диапазоне номеров строк страницы для печати должно тоже считаться отдельным событием. Однако на самом деле оно является прямым результатом набора команды NEXT-FIELD и потому обрабатывается как часть этого события. Назначение пунктирных линий на схеме конечного автомата процессора команд поясняется ниже. Одно из наиболее неприятных обстоятельств, которое может возникнуть при функционировании интеллектуальной рабочей станции,- это отсутствие реакции устройства на нажатие кла- Редактирование  (а) Схема взаимрд?йС1Ви.в при п?ч8ТИ строк страницы, Нажатие клавиш (к1 Запрос очередных строк  Диапазон номеров строк страницы N, N 1 \{б) Внутренний потокданных дешифратора событий Рис. 4.23. Детальное представление ИПГ. виш клавиатуры. Такое может случиться, если не предусмотреть связи, отмеченные на рис. 4.24 в схеме конечного автомата процессора команд пунктирными линиями. Эти связи обеспечивают в явной форме отклонение (а не игнорирование) команд редактирования в состоянии ожидания и выход из этого состояния, если печатающее устройство не проявляет никакой реакции. Соответствующие связи изображены пунктиром по той причине, что ранее мы не включили рассмотренную возможность в спецификацию команд (типичный пример ошибки в технических требованиях, выявляемой в процессе проектирования). Здесь следует обратить внимание на то, что нам удалось детализировать функциональное назначение основных модулей системы и их взаимодействий без принятия каких-либо решений отиосительно представления конкретных модулей в виде пакетов или задач, и без ответов на вопросы, какой модуль каким вызывается и сколько вызовов необходимо, чтобы реализовать нужный поток данных. Таким образом, подход к проектированию, основанный на рассмотрении в первую оче- 154 Глаза 4  (3} Состояния распознаватвля команд ,  Команда С'вдзктирования Выходнан форма к . Конец Команда интервала Продолжения ожмданил  Команда освобождения (б) Состояния процессора команд, Рис. 4.24. Схема конечного автомата для дешифратора событий. редь потока данных, позволяет отложить принятие решений по этим существенным организационным деталям. Поэтому решения, уже принятые ранее в разд. 4.5.2, вполне можно было бы отложить до завершения построения схемы потока данных. 4.5.4. Структурная схема взаимодействий при фоновой печати Теперь мы в состоянии приступить к определению общей структуры взаимодействий задач при фоновой печати. Рассмотрим сначала взаимодействие между задачей интерфейса клавиатуры и задачей дешифратора событий. Один из подходов мог бы состоять в том, чтобы в задаче дешифратора событий организовать обращение к входу GET-KEYSTROKE задачи обработки прерываний от клавиатуры, переводя ее тем самым в режим ожидания сигнала нажатия клавиши. Такой подход 1 ... 12 13 14 15 16 17 18 ... 32 |