Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Билет №14.docx
Скачиваний:
4
Добавлен:
04.08.2019
Размер:
297.07 Кб
Скачать

Билет 14

1) Объектно-ориентированная модель отображения данных (диаграмма классов механизма отображения данных, диаграмма взаимодействия механизма отображения, диаграмма объектов).

Данные системы PCNC выделяют в классы, исходя из их неразрывности и функциональных характеристик. Объект, представляющий данные системы PCNC, включает в себя такие их характеристики, как тип, размер, текущие значения, а также функциональные возможности, позволяющие запрашивать данные разными способами, форматировать их, конвертировать и верифицировать и т.д. Практически все типы данных системы PCNC подпадают под описание абстрактного объекта CAbstractData. Примерами могут послужить текущее положение координатных осей, подача, кадр управляющей программы, состояние модуля. Конкретизация (уточнение) данных осуществляется в классах, унаследованных от CAbstractData, а механизм обмена данными реализуется на основе обобщенных функциональных возможностей этого класса. Класс, поставляющий данные, служит сервером, а классы, получающие от него данные, являются его клиентами. В принципе клиент может быть описан некоторым абстрактным классом CReceiver, имеющим всевсего одну виртуальную функцию CReceiver::UpdateValue(). Эта функция класса и вызывается сервером для передачи данных. Клиенты, желающие получить данные от сервера асинхронным или циклическим способом, ≪подписываются≫ на них или их изменение. Подписка требует специального механизма регистрации клиентов со стороны сервера данных(рис. 4, 5)

Класс AbstractData (рис 3), поставляющий данные, имеет список

m_Clients для асинхронных клиентов и список m_Cycle Clients для циклических клиентов. При любых запросах, обращенных к серверу, проверяется наличие клиента в списке. Если клиент не обнаружен, то он добавляется в соответствующий список функцией CPtrArrayRegistr: Add (см. рис. 120). При изменении данных клиент уведомляется посредством виртуальной функции CReceiver:."UpdateValue(). После подтверждения достоверности данных клиент запрашивает их с помощью функции CAbstractData: :GetData(). При

этом каждый клиент определяет формат запрашиваемых данных. К примеру, текущие позиции координатных осей необходимы как в числовом виде для выполнения арифметических операций, так и в виде строк для отображения на экране. Функция CFormat::ConvertData() осуществляет конвертирование и форматирование данных. Асинхронные клиенты в списке m_Clients удаляются автоматически со стороны сервера после уведомления клиентов.

Циклический опрос прекращается со стороны клиента вызовом функции CAbstractData::DeleteClientO- Для описания сценария работы механизмов используют диаграммы взаимодействия и диаграммы объектов. Семантическая близость диаграмм позволяет использовать инструментальные средства генерации одной диаграммы из другой с минимальными потерями информации. Диаграмма взаимодействия более наглядна. Она похожа на таблицу, в верхней строке ее записывают имена объектов, под каждым из которых рисуют вертикальную штриховую линию. Горизонтальные линии соответствуют посылкам сообщений, их проводят от вертикали клиента к вертикали сервера и располагают в хронологической последовательности сверху вниз. Асинхронные сообщения обозначаются половинками стрелок. Преимущества диаграммы объектов в том, что она более подходит для многих объектов со сложными вызовами и допускает включение дополнительной информации, например поток данных (стрелка с кружочком в конце) и т.д.

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

когда протоколы взаимодействия отдельных классов не зафиксированы.

По мере того, как уточняется структура классов, вырисовываются подробности диаграммы объектов. Разработанная нами объектно-ориентированная модель механизма отображения данных имеет пока одно ограничение - сервер и клиент работают с прямыми указателями друг на друга. Скорость такого обмена данными очень высока, но сам обмен возможен только в пределах единого адресного пространства, т.е. в пределах одного потока Windows NT. Класс CWrapReceiver, производный от CReceiver (см. рис. 119), решает проблему перехода границы потока путем разделения процедуры получения данных на две части:

• посылка клиенту уведомления из другого потока о достоверности

данных;

• прямой запрос данных со стороны клиента и приведение этих дан-

ных к стандартному типу CSaferyArray.

Клиент подписывается на получение определенного типа данных асинхронным или циклическим способом, передавая при этом в качестве параметров идентификатор своего окна hWnd и идентификатор запроса данных. В соответствии с этими параметрами объект класса CWrapReceiver

(оболочка) создается в потоке класса сервера данных и регистрируется в

соответствующей очереди клиентов. При обновлении данных вызывается

переопределенная виртуальная функция CWrapReceiver::UpdateValue().

Эта функция уведомляет клиента через границу потока о достоверности данных посредством стандартных механизмов Windows SendMessageO

или PostMessageO- Оконная функция обработки сообщения клиента получает данные посредством стандартного типа CSaferyArray. Диаграмма

объектов описанного механизма представлена на рис. 6. С помощью механизма отображения данных можно решать практически все задачи обмена данными в системе PCNC, в том числе слежение за возникновением

ошибок.