Сосонкин_Системы_ЧПУ (1087166), страница 34
Текст из файла (страница 34)
Таковыми могут быть данные, привязанные кнаступлению какого-либо события, на которое модуль должен определенным образом отреагировать. В этом случае модуль запрашивает данныеасинхронным способом, формируя соответствующую заявку. Запросив их,он не прекращает своей работы, а поступающий ответ обрабатывается такназываемой callback-функцией.Данные визуализации (выводимые на экран) нуждаются в постоянномциклическом опросе (они отнесены к третьей категории). Для минимизации объема транзакций используют асинхронный запрос по событию. Событием в этом случае служит изменение отслеживаемых данных. Посленаступления события они передаются для обновления визуализации.
Запрашивающий модуль регистрируется при этом как получатель («подписчик»).Таким образом, категория данных устанавливает способ их запроса повиртуальной шине [38]. Вспомогательные категории определяют специальные способы запроса при отладке системы и ее программного обеспечения. Однако категория - не единственная характеристика данных абстрактной модели системы PCNC. Другими характеристиками являются их формат, размерность, корректность (как результат верификации), тип (char, integer,long, double, pointer,...), объем занимаемой памяти и текущие значения.Процессы абстрактной модели системы PCNC определены своими состояниями (активное, неактивное, приостановленное, состояние ошибкии т.д.), списком предшествующих операций, набором предусмотренныхакций (инициализация, запуск, останов, завершение, выход из ошибочного состояния).
Состояниями и акциями можно управлять. Управление акциями осуществляется синхронным или асинхронным способом (подобнотранзакциям передачи данных). Понятие «процесс» близко к понятию «режим» системы ЧПУ (автоматический, ручной, толчковый, запуска строкиручного ввода и т.д.). Поскольку практически все модули системы ЧПУзависимы от режимов, они естественным образом связаны с процессами.Глава 4. Технологии разработки программного обеспечения систем управления•) g -|Принцип построения системы PCNC по типу языкового процессора [2]предполагает, что в качестве команд выступают G-функции кода ISO-7bit.В терминах команд осуществляются анализ, интерпретация и отработкакадров управляющей программы путем последовательного конвертирования информации в форматы интерполятора и приводов. Каждая командаимеет свой идентификатор, список параметров и приоритет. Предусмотренные акции команд состоят в проверке возможности выполнения команди их непосредственной реализации.
Команды входят в сложные отношения между собой для образования комплексных иерархических структур.Например, набор команд интерпретатора определяется как система командISO-процессора [51], причем для организации параллельной интерпретации в составе базового набора команд выделяют группы, так называемыегрупповые интерпретаторы.4.2.2. Объектно-ориентированная модельмодуля системы PCNCВыделение элементов абстрактной модели системы ЧПУ является базисом для построения объектно-ориентированных моделей механизмов системы PCNC. Иерархия классов системы PCNC построена с использованием основных принципов объектно-ориентированного подхода: инкапсуляции (возможности скрывать детали объекта от программиста),наследования (возможности создавать новые объекты на базе существующих), полиморфизма (возможности использовать различные варианты поведения объектов).
В основе иерархии лежат классы, реализующие элементы абстрактной модели: данные, процессы, команды. Выделение этихклассов поддерживает общие свойства и поведение производных (наследованных) классов и позволяет разработать с их помощью все основныемеханизмы системы PCNC.Модуль системы PCNC строят по принципу командного процессора,на вход которого поступают команды с параметрами. Объектно-ориентированная модель модуля Б нотации Буча [70] показана на рис. 118.
Классыпредставлены в виде «облачков Буча», связанных между собой определенными отношениями. Ядром модуля служит языковой процессор, предназначенный для выполнения функциональных задач модуля. Языковый процессор соответствует классу 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В.П. Сосонкин, Г.М.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
