Сосонкин В.Л. 2005 Системы числового программного управления (841803), страница 34
Текст из файла (страница 34)
Ядром модуля служит языковой процессор, предназначенный для выполнения функциональных задач модуля. Языковый процессор соответствует классу CLanguageProcessor, производному от стандартного класса CObject библиотеки MFC. Класс наследует механизмыработы: с архивами - информацией на постоянных носителях, с RTTI (RunTimeType Information) - информацией о типе, известном только во время выполнения приложения, с дампа памяти, и верификации в режиме отладки.Прототип языкового процессора содержит систему команд, машинусостояний и конфигуратор.
Они соответствуют m-полям (member fields)192В.Л. Сосонкин, Г.М. Мартинов. Системы числового программного управления.'CObject \CStateMachinem_Stateld : longfуквHim_Commandld: longrn_Priority: long tРис. 118. Фрагмент диаграммы классов (в нотации Буча), реализующих абстрактный командный процессоркласса CLanguageProcessor: m_CommandSet, m_StateMachine иm_pConfigurator. Система команд реализована в виде набора классов,производных от CCommand, полученных в свою очередь от библиотечного класса CObject.Класс CCommand имеет общие для всех команд свойства: идентификатор команды (поле m_CommandId), предназначенный для распознаваниякоманды; приоритет команды (m_Priority).
Если на вход процессора поступает одновременно несколько команд, последовательность их выполнения соответствует приоритетам. Реализации конкретных команд и ихпараметры определены классами, производными от CCommand. При этомпереопределяются виртуальные функции CCommand::Check() - проверка на возможность выполнения, и CCommand::Run() - выполнение команды.Класс CStateMachine, производный от CObject, следит за состояниеммодуля.
Состояние сохраняется в поле mStatusId. В этом классе предусмотрены также функции проверки возможности перехода в новое состояние. Класс, производный от CConfigurator, предназначен для конфигурации, т.е. настройки на конкретный модуль. Конфигуратор включают в языковой процессор по указателю (т.е. поле m_pConfigurator содержит толькоссылку на конфигуратор), что позволяет заменять его, т.е. работать с разными системами конфигурации.Глава 4.
Технологии разработки программного обеспечения систем управления1934.2.3. Объектно-ориентированная модельотображения данныхДанные системы PCNC выделяют в классы, исходя из их неразрывности и функциональных характеристик. Объект, представляющий данныесистемы PCNC, включает в себя такие их характеристики, как тип, размер,текущие значения, а также функциональные возможности, позволяющиезапрашивать данные разными способами, форматировать их, конвертировать и верифицировать и т.д. Практически все типы данных системы PCNCподпадают под описание абстрактного объекта CAbstractData (рис.
119).Примерами могут послужить текущее положение координатных осей, подача, кадр управляющей программы, состояние модуля. Конкретизация(уточнение) данных осуществляется в классах, унаследованных отCAbstractData, а механизм обмена данными реализуется на основе обобщенных функциональных возможностей этого класса.Класс, поставляющий данные, служит сервером, а классы, получающие от него данные, являются его клиентами.
В принципе клиент можетбыть описан некоторым абстрактным классом CReceiver, имеющим все/CPtrArray ~ 4 t' ч (from MFC 5~6) ICAbstractData•SynchronRequestf)•ASynchronRequestQ*ASynchronRequesiEvent()%DeleteClient()\*GetData()\|*DispatchEvent{)к ^Remove() J1m_pAbs(lactDataCWrapReceiver£mJiWnd":HWNb =p DataServerld : long = }Рис 119. Фрагмент диаграммы классов (в нотации Буча),реализующих механизм отображения данных,*-'194В.Л. Сосонкин, Г.М. Мартинов. Системы числового программного управлениявсего одну виртуальную функцию CReceiver::UpdateValue(). Эта функциякласса и вызывается сервером для передачи данных. Клиенты, желающие получить данные от сервера асинхронным или циклическим способом, «подписываются» на них или их изменение.
Подписка требует специального механизма регистрации клиентов со стороны сервера данных(рис. 120 и 121).Класс AbstractData (см. рис. 119), поставляющий данные, имеет списокm_Clients для асинхронных клиентов и список m_Cycle Clients для циклических клиентов. При любых запросах, обращенных к серверу, проверяется наличие клиента в списке. Если клиент не обнаружен, то он добавляется всоответствующий список функцией CPtrArrayRegistr: Add (см. рис. 120). Приизменении данных клиент уведомляется посредством виртуальной функцииCReceiver:."UpdateValue(). После подтверждения достоверности данныхклиент запрашивает их с помощью функции CAbstractData: :GetData().
ПриDataClient:CReceiverDataServer:CAbstractDatam_pFormat:CFormatm_Clients:CPtrArrayRegistr1: ASynchronRequest2: Add (void*)3: UpbateValue (CAbstractData*)4: GetData (CTransfer&)ConvertData(Crrransfer&, DATA_EXCHANGE_t, UINT)«6: DeleteClient (CReceiver&) |7: Remdve (void*)Рис. 120. Диаграмма взаимодействия механизма отображенияГлава 4.
Технологии разработки программного обеспечения систем управления195'UpdateValue (CAbstractData*'4: GetData (CTransfer&)6: DeleteClient (CReceiver&)1: ASynchronRequest5: ConvertDj_t, UINT) 2: Add (void*): Remove (void*)Рис. 121. Диаграмма объектовэтом каждый клиент определяет формат запрашиваемых данных. К примеру, текущие позиции координатных осей необходимы как в числовомвиде для выполнения арифметических операций, так и в виде строк дляотображения на экране. Функция CFormat::ConvertData() осуществляет конвертирование и форматирование данных.
Асинхронные клиенты в спискеm_Clients удаляются автоматически со стороны сервера после уведомления клиентов.Циклический опрос прекращается со стороны клиента вызовом функции CAbstractData::DeleteClientO- Для описания сценария работы механизмов используют диаграммы взаимодействия и диаграммы объектов.
Семантическая близость диаграмм позволяет использовать инструментальные средства генерации одной диаграммы из другой с минимальнымипотерями информации. Диаграмма взаимодействия более наглядна. Онапохожа на таблицу, в верхней строке ее записывают имена объектов, подкаждым из которых рисуют вертикальную штриховую линию. Горизонтальные линии соответствуют посылкам сообщений, их проводят от вертикали клиента к вертикали сервера и располагают в хронологической последовательности сверху вниз. Асинхронные сообщения обозначаются половинками стрелок.Преимущества диаграммы объектов в том, что она более подходит длямногих объектов со сложными вызовами и допускает включение дополнительной информации, например поток данных (стрелка с кружочком в конце) и т.д.Опыт работы показывает, что диаграмма взаимодействия лучше передает семантику сценариев на ранних стадиях проектирования систем PCNC,когда протоколы взаимодействия отдельных классов не зафиксированы.-| ggВ.П.
Сосонкин, Г.М. Мартинов. Системы числового программного управленияПо мере того, как уточняется структура классов, вырисовываются подробности диаграммы объектов.Разработанная нами объектно-ориентированная модель механизма отображения данных имеет пока одно ограничение - сервер и клиент работают с прям ыми указателями друг на друга. Скорость такого обмена данными очень высока, но сам обмен возможен только в пределах единого адресного пространства, т.е. в пределах одного потока Windows NT. КлассCWrapReceiver, производный от CReceiver (см. рис. 119), решает проблему перехода границы потока путем разделения процедуры получения данных на две части:• посылка клиенту уведомления из другого потока о достоверностиданных;• прямой запрос данных со стороны клиента и приведение этих данных к стандартному типу CSaferyArray.Клиент подписывается на получение определенного типа данных асинхронным или циклическим способом, передавая при этом в качестве параметров идентификатор своего окна hWnd и идентификатор запроса данных.
В соответствии с этими параметрами объект класса CWrapReceiver(оболочка) создается в потоке класса сервера данных и регистрируется всоответствующей очереди клиентов. При обновлении данных вызываетсяпереопределенная виртуальная функция CWrapReceiver::UpdateValue().Эта функция уведомляет клиента через границу потока о достоверности данных посредством стандартных механизмов Windows SendMessageOили PostMessageO- Оконная функция обработки сообщения клиента получает данные посредством стандартного типа CSaferyArray. Диаграммаобъектов описанного механизма представлена на рис. 122. С помощью механизма отображения данных можно решать практически все задачи обмена данными в системе PCNC, в том числе слежение за возникновениемошибок.ЗаключениеОбъектно-ориентированная модель системы PCNC структурирует ееархитектуру, делает программное обеспечение прозрачным и повышает,следовательно, его надежность, а также упорядочивает процесс разработки, создавая предпосылки формирования среды разработки.
Рассмотренные элементы базовых абстракций, классы их объектной реализации,построенные на основе этих классов механизмы,-все это служит основой для создания элементов системы ЧПУ более высокого уровня. К числу таких элементов относятся каналы, оси, закрепленные за этими каналами, и т.д.Глава 4. Технологии разработки программного обеспечения систем управления1975: DeleteClient (CReceiver&)3: UpdateValue (CAbstractWrapClient:CWrapReceiver i2: ASynchronRequest6: GetData (CTi ansfer&)II1:lnit(HWND, long)4: PostMessage (UINT,RemoteClient: CWnd ,Рис. 122.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
