WWW.LIB.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные материалы
 

«Проект «Гербарий» Методика разработки модулей ИПО на базе ИИПП Оглавление Общие положения Состав SDK ИИПП Состав и назначение ...»

Проект «Гербарий»

Методика разработки модулей ИПО на базе ИИПП

Оглавление

Общие положения

Состав SDK ИИПП

Состав и назначение компонентов ИИПП

Сессия ИИПП

Структура данных модели ИИПП

Элемент данных

Структурированные данные

Свойства

Объекты модели

Объекты 2D модели

Объекты 3D модели

Объекты инженерного анализа

Шаблоны

Стили

Документ

Организация объектов документа

Группы

Процедура редактирования данных документа

Задачи

Классификация задач

Зависимости

Параметризация

Пересчёт модели

Отслеживание изменений в модели

Сценарии

Дерево процессов

Решения

Средства визуализации модели ИИПП

Управление окнами документа

Управление сессиями редактирования документа

Разработка ИПО

Регистрация приложений

Идентификация приложений

Статическая регистрация модуля в файле регистрации приложений

Регистрация модуля через системные настройки

Регистрация модуля через пользовательские настройки

Управление приложениями через пользовательский интерфейс Демонстратора

Настройка и генерация проекта (TODO)

Инициализация приложения

Инициализация дополнительного модуля (плагина)

Инициализация ИИПП в составе отдельного приложения (TODO)

Добавление новых классов данных



Правила оформления классов

Добавление простых данных в класс

Методы доступа и модификации данных класса

Добавление составных данных

Добавление массивов данных

Добавление связей

Сохранение и чтение пользовательских данных

Интеграция внутрисистемных данных в модель платформы

Примеры реализации прикладных задач

Создание элементов пользовательского интерфейса

Сохранение и восстановление настроек приложения

Команда

Управление командами

Обработка уведомлений платформы

Оболочка пользовательского интерфейса

Главное окно системы

Управление вспомогательными окнами

Управление прикладными окнами документа

Диалоговые окна

Использование диалоговых окон в командах

Общие положения Данный документ описывает архитектуру интегрированной инженерной программной платформы (ИИПП) и методику разработки дополнительных модулей инженерного программного обеспечения (ИПО).

ИИПП предназначена для разработки приложений класса CAD/CAE/CAM. Платформа имеет модульную объектно-ориентированную архитектуру, которая обеспечивает эффективную реализацию базовой функциональности инженерных приложений.

ИИПП обеспечивает решение следующих задач:

Управление цифровой моделью данных инженерных приложений. Под управлением понимается наличие API по формированию модели данных, обеспечение целостности модели при различных модификациях, обеспечение контроля над взаимосвязями между различными объектами и т.д.;

Открытый программный интерфейс, обеспечивающий возможность расширения логики поведения объектов модели;

Хранение/восстановление данных цифровой модели. Обеспечивается сохранение и восстановление данных в открытом расширяемым форматом хранения;

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

Обмен данными в стандартных форматах;

Графическая подсистема обеспечивает реализацию функциональности 2D и 3D графики, необходимую для решения задач в приложениях CAD/CAM/CAE;

Подсистема поддержки пользовательского интерфейса обеспечивает базовый инструментарий для разработки пользовательского интерфейса различных инженерных приложений при помощи унифицированных объектно-ориентированных инструментов;

В состав ИИПП входят компоненты, отвечающие за формирование и отображение таких элементов управления, как дерево структуры модели, взаимосвязи объектов при построении объектов модели, состав составных объектов (например, инженерной задачи), а также других видов взаимосвязей объектов модели.

По сути ИИПП является «конструктором», обеспечивающим возможность быстрой разработки как отдельных программ инженерного назначения, так и комплексной интегрированной системы, состоящей из множества отдельных приложений различной сложности. При этом нельзя сказать, что платформа разработана для реализации конкретно задач CAD, CAE или CAM. Любое из направлений реализуется в виде прикладного модуля, имеющего конкретного назначение. В этом смысле, приложения различной направленности будут реализовываться как равноправные компоненты.

Программный код ИИПП соответствует требованиям, позволяющим использовать платформу при решении широкого круга задач:

Наличие открытого многоуровневого API. Классы платформы позволяют разрабатывать как компактные независимые приложения, так и сложные системы с высокой степенью интеграции.

SDK ИИПП включает в себя материалы, необходимые для обеспечения разработки таких приложений. В состав SDK входит: документация, набор примеров, материалы для сборки конечных приложений.

Платформа имеет открытую расширяемую объектную модель, обеспечивающую возможность внедрения в модель объектов приложений с новым поведением. Такие объекты могут полноценно взаимодействовать с другими объектами модели, сохраняться в файл, причём не исчезать даже в тех случаях, если данное приложение не запускается в составе конкретного АРМ.

Кроссплатформенность. Код ИИПП поддерживает работу на различных операционных системах разной разрядности, включая сертифицированные ОС для работы на отечественных предприятиях ОПК.

Ядро геометрического моделирования RGK, входящее в состав платформы обеспечивает возможности по формированию и анализу точного трёхмерного представления объектов моделирования.

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

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

Состав SDK ИИПП Набор инструментов разработчика ИИПП (SDK) обеспечивает возможность расширения функциональности платформы за счёт разработки приложений, предназначенных для решения инженерных и иных задач на основе единой модели данных. Приложения разрабатываются на языке программирования C++.

SDK ИИПП включает в себя следующие материалы:

Заголовочные файлы (.h), необходимые для компиляции программ на языке программирования C++ с использованием классов платформы Библиотечные файлы (.lib), необходимые для компоновки конечных модулей Исполняемые файлы платформы (.dll,.so) в отладочном (Debug) и рабочем (Release) вариантах для запуска и отладки собранных модулей совместно с файлами ИИПП Руководство разработчика в виде гипертекстовой справки (RGPlatform.chm) Набор примеров приложений ИПО в исходных кодах для помощи в разработки конечных приложений Набор файлов тестовых моделей в формате ИИПП (.RGP) SDK распаковывается в локальную папку на компьютере пользователя (разработчика).

Для использования SDK требуется наличие:

–  –  –

Состав и назначение компонентов ИИПП На схеме приведён перечень основных компонентов (модулей), входящих в состав SDK ИИПП.

Перечислены как модули, входящие непосредственно в ИИПП, так и модули основных и вспомогательных приложений ИПО.

Перечень, и назначение модулей ИИПП, а также вспомогательных модулей, входящих в состав

SDK и инсталляции приложения RGPDemo, приведён в таблице:

–  –  –

Сессия ИИПП Объект сессии предназначен для управления общесистемными данными ИИПП, поэтому существует в единственном экземпляре.

К таким данным относится:

Менеджер модулей ИПО Менеджер документов Менеджер подписки приложений на системные события Менеджер элементов управления пользовательского интерфейса (кнопки, команды, меню, вспомогательные окна и т.д.) Сессия геометрического ядра RGK, описание атрибутов для хранения топологических данных.





Менеджер данных, загруженных из внешних источников Менеджер внешних ссылок Системная информация: путь на папку платформы; имя текущей конфигурации Сессию ИИПП представляет собой класс RGPlatform::Model::Session. Инициализация ядра платформы выполняется с помощью однократного вызова статического метода RGPlatform::Model::Session::Create в начале загрузки приложения. Метод создаёт объект сессии и связанные с ним общесистемные данные. В качестве параметров метода задаются имя конфигурации системы (АРМ), имя текущего пользователя и путь к файлу, содержащему данные о зарегистрированных модулях ИПО — уникальные идентификаторы, их названия, типы данных и пути для загрузки программных компонентов приложений ИПО.

Завершение сессии платформы выполняется вызовом статического метода RGPlatform::Model::Session::Destroy непосредственно перед завершением приложения.

Работа с классами платформы после удаления сессии невозможна.

Структура данных модели ИИПП В данном разделе приводится общее описание организации данных в моделях платформы, освещаются вопросы классификации задач, параметризации модели с помощью зависимостей (функциональных связей) и собственно процедура пересчёта.

Предполагается, что в модулях ИПО, как правило, будут добавляться новые классы задач и зависимостей для связывания результатов решения этих задач с данными других объектов модели.

Например:

В модуле ИПО, реализующем функциональность CAD, будут добавляться новые типы генераторов тел, различные способы задания кривых, штриховок, точек;

В модуле ИПО, реализующем функциональность CAЕ, будет добавляться новые типы генераторов сеток и процессоров для выполнения инженерных расчётов;

Можно сделать отдельным модулем ИПО решение задачи вариационной параметризации объектов модели. В этом же модуле нужно описать связи параметров объектов модели с результатами решения задачи.

Элемент данных Основой представления информации в модели является понятие «элемента данных». Его представляет класс RGPlatform::Model::Data, являющийся базовым класс для всех типов данных платформы.

К таким типам относятся:

–  –  –

В классе Data декларируются виртуальные методы для описания типа и его чтения/сохранения:

Имя типа элемента данных;

Идентификатор типа элемента данных;

Классификационные признаки типа, необходимые для организации и управления моделью ИИПП;

Чтение/запись данных (сериализация).

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

Базовым для всех структурированных типов данных платформы является класс RGPlatform::Model::StructuredData.

Класс реализует унифицированный доступ к составным данным как к свойствам с помощью метода Properties, возвращающего список свойств, по которому можно итерировать с помощью стандартного однонаправленного итератора (методы begin, end или цикл for_each). Такой подход позволяет работать с данными любого класса, абстрагируясь от реализации класса.

Список свойств по запросу формируется с помощью виртуального метода CollectProperties, который в каждом порождённом классе, как правило, имеет свою реализацию. Добавление свойств выполняется с помощью макросов. Набор макросов и описание их параметров можно найти в заголовочном файле ядра “\Model\Properties\PropertyDeclaration.h”. Пример реализации метода CollectProperties с помощью макроса можно найти в описании процесса разработки классов данных ИПО ниже по тексту.

Главная идея, чтобы данные любого класса платформы декларировались привычным для объектно-ориентированного программирования образом: с помощью полей. Для получения доступа к полям экземпляра класса как к свойствам используются средства рефлексии (отражения) типов, реализованные в стандарте C11 набором шаблонов классов для работы с функциональными объектами.

СвойстваИИПП обеспечивает поддержку следующих типов свойств:

Доступ к полям класса. Поля могут быть фундаментального типа или типа, порождённого из класса Data Вызов методов класса, то есть свойство используется для получения производных (вычисляемых) данных Присоединённые свойства. Это необязательные элементы данных, которые можно удалять и добавлять. Хранение таких данных реализовано в базовом классе RGPlatform::Model::VariableDataStructure Для доступа к свойству используется класс Property, экземпляр которого возвращается итератором по списку свойств PropertySet.

Для каждого свойства доступна следующая информация:

Тип элемента данного свойства. Может быть указан базовый тип для всех типов данных, которые доступны с помощью этого свойства Доступ к значению. В целях упрощения для фундаментальных типов предусмотрены отдельные функции получения значения Идентификатор свойства. Идентификатор может использоваться как ключ для хранения ссылки на отдельные данные структурированного объекта. Это мощный и гибкий инструмент для построения ассоциативных (параметрических) моделей Имя поля. Может также использоваться как ключ для доступа. В некоторых случаях свойство может быть безымянным. Например, для элементов массивов, также доступных как свойства, для ссылки на отдельный элемент может использоваться только идентификатор свойства Атрибуты, используемые для управления свойством. Полный список атрибутов можно найти в перечислении RGPlatform::Model::PropertyAttributes. Допускается комбинация атрибутов, если не оговорены частные случаи взаимоисключающих или взаимосвязанных атрибутов Объекты модели Объекты – это самостоятельные элементы представления логической структуры модели.

По назначению объекты модели можно условно разделить на несколько групп:

«Основные» объекты формируют конечное изображение (чертёж, эскиз) или 3D модель Объекты – генераторы. Они обеспечивают управление геометрией, параметризацию, положением и формой основных объектов модели;

«Вспомогательные» объекты. Например, стили рисования, материалы, категории, переменные, сопряжения. Они обеспечивают управление стилем отображения основных объектов, а также решение вспомогательных задач по управлению моделью;

«Инженерные» объекты обеспечивают решение задач инженерного анализа: описание граничных условий, датчики, КЭ-сетки, решатели, результаты решения.

Все объекты модели порождены от класса RGPlatform::Model::Object, который в свою очередь порождён из класса структурированных данных.

Класс обеспечивает следующую базовую функциональность:

Хранение однотипных свойств объектов модели Управление присоединёнными свойствами Управление взаимосвязями между объектами модели, получение зависимостей Обновление (регенерация) данных объектов модели при изменении свойств или связанных объектов Хранение атрибутов Хранение уникального идентификатора объекта, назначаемого документом Управление состоянием объекта Связь объекта с родительским объектом и с документом Диагностика ошибок объекта Назначение категориями объектов Получение информации для реализации пользовательского интерфейса приложений, в частности, имени, отображаемого названия, иконки и т.д.

На рисунке представлена иерархия основных классов модели, реализованных в платформе. Все классы объявлены в пространстве имён RGPlatform::Model.

Объекты 2D модели Объекты 2D части модели используются для оформления эскизов и чертежей.

Основными объектами являются:

Node2D - точка (Узел). Объект представляет собой геометрическую точку с двумя координатами (X, Y), заданными в системе координат страницы, на которой она расположена. Это вспомогательный объект Curve2D - кривая. Двухмерная кривая, заданная в координатах страницы, на которой она расположена. Объект может быть как вспомогательным, так и элементом оформления Area2D - область (регион). 2D область, ограниченная набором кривых. Заливка, штриховка и т.д. Является одним из основных объектов для формирования геометрии 3D тел LineText - текст. Объект для представления текстовой информации Dimension - обозначение размера. Размер может быть также трёхмерным

Layout – страница. Страница может использоваться для решения разных задач:

o Хранение фрагментов картинок (блоков) для их последующего размещения на других страницах o Чертежные страницы o Рабочая поверхность. В частности, рабочая плоскость (эскиз) ObjectOnPage – размещение 2D объекта на странице. Один и тот же 2D объект может быть нарисован в нескольких экземплярах с разными преобразованиями на одной и той же или разных страницах. В частности, допускается рисование одной страницы на другой;

Object3DOnPage – проекция 3D объекта на странице.

Другие типы инженерных обозначений (PMI) Объекты 3D модели 3D модель, формируемая при помощи ИИПП, представляет собой совокупность объектов, различающихся по типу геометрии и её назначения. Базовые компоненты ИИПП и внешние модули ИПО могут реализовывать различные алгоритмы и логику формирования этой геометрии.

В общем случае, геометрия, полученная в результате этих алгоритмов, не связана напрямую с той логикой и алгоритмом, в соответствии с которой эта геометрия была получена.

Объекты 3D модели имеют следующие базовые типы:

BodyObject - тело. Данные объекты могут хранить множество тел различного типа:

o Твёрдые тел, используемые для описания формы реальных изделий o Листовые тела используются для поверхностного моделирования и вспомогательных построений в твердотельном моделировании o Проволочные тела (траектории) CoordinateSystem - координатные системы с обобщёнными координатами OrthogonalCoordinateSystem – ортогональные координатные системы CartesianCoordinateSystem – декартова система координат ThreeDimensionalCartesianCoordinateSystem - локальная система координат. Объект, представляющий нормированную ортогональную правостороннюю систему координат.

Вспомогательный объект, предназначенный для задания расположения других объектов модели и других функций Node3D - 3D узел. Объект, представляющий собой трёхмерную точку в системе координат модели Component - компонент. Детали и агрегаты в сборочных моделях представлены компонентами Picture3D - 3D картинка. Как правило, это часть специфичных для САПР данных для работы с трёхмерной графикой: сетки; текстуры.

Кроме основных типов, модель может расширена вспомогательными объектами, не участвующими в формировании геометрии тел.

К таким объектам можно отнести:

–  –  –

Для представления документации на модель в соответствии с требованиями стандартов, а также в целях оформления модели, она может содержать элементы оформления, ассоциированные с телами и другими элементам модели:

Обозначения размеров Инженерные надписи Обозначения допусков формы и взаимного расположения поверхностей Обозначения сварных и других типов соединений Другие инженерные обозначения Тексты Объекты инженерного анализа

В платформе реализованы базовые классы описания задачи инженерного анализа:

Condition - Базовый класс условия задачи инженерного анализа BoundaryCondition - базовый класс граничного условия задачи инженерного анализа Connector - коннектор DisplacementRestraints - ограничение положения FixedGeometry - закрепление геометрического элемента Load - нагрузки StructuralForce - сила, приложенная к геометрическому элементу StructuralLoad - распределённые нагрузки StructuralPressure - давление на геометрический элемент MeshGenerator - базовый класс генератора сеток MeshObject - класс хранения результатов расчёта сетки в унифицированном для платформы виде CAE сетки Study - базовый класс расчётной задачи StrengthStudy - расчёт на прочность StudyProcessor - решатель задачи Данный список граничных условий может быть расширен за счёт классов, реализованных в дополнительных модулях ИПО (приложениях). Также отдельными модулями могут быть оформлены один или несколько решателей этой задачи от разных разработчиков. Дальнейшее описание реализации классов данных ИПО рассматривается как раз на примере данных для задач инженерного анализа.

Шаблоны Шаблоны используются для хранения наборов свойств из других типов объектов.

Примеры использования шаблона:

Хранение параметров объектов по умолчанию в отдельном документе или пользовательской сессии;

Задание общих параметров для группы объектов;

Обмен наборами свойств между объектами;

Протоколирование изменений свойств объектов;

Хранение результатов сравнения двух объектов;

Особенности текущей реализации шаблонов:

Хранение составных типов данных;

Для доступа к свойствам в шаблонах используются идентификаторы свойств тех типов объектов, свойства которых хранятся в шаблоне;

Возможны три типа действий со свойствами:

o добавить свойство в шаблон;

o удалить свойство из шаблона;

o получить свойство из шаблона;

В целях упрощения использования шаблонов для основных часто используемых фундаментальных типов данных (double, int и т.д.) сделан свой набор функций;

Шаблоны поддерживают свойства типа ассоциативные связи, то есть могут быть параметризуемы.

Замечания по использованию шаблонов:

В настоящей версии шаблонов не поддерживается доступ к свойствам по имени;

Хотя хранение и доступ к свойствам в шаблоне были оптимизированы, они более медленные и берут больше памяти на единицу хранимой информации по сравнению с прямым доступом к данным в объектах, свойства которых хранятся в шаблонах;

Есть два типа шаблонов:

o Шаблоны для хранения свойств любых типов структурированных данных;

o Шаблоны для хранения свойств объектов модели. Эти шаблоны могут храниться как самостоятельные объекты модели. Ссылки на них разделяемы.

Шаблоны не являются функциональными объектами, такими как 2D и 3D объекты. Это всего лишь хранилище свойств других объектов;

Указанные замечания нужно учитывать при выборе способа использования шаблонов в системе.

Шаблон для объектов реализован классом ObjectTemplate Стили Ещё одним примером использования шаблонов являются стили. Стили используются для хранения визуальных свойств объекта. Базовый класс для всех типов стилей Style.

Примеры использования стилей в платформе:

Curve2DStyle – хранение параметров рисования 2D кривой Area2DStyle – хранение параметров рисования 2D областей (штриховки) Node2DStyle – хранение параметров рисования 2D узлов Node3DStyle – хранение параметров рисования 3D узлов TextStyle – хранение параметров рисования текстов Material - материалы тел VisualizationQuality - параметры визуализации тел LCSStyle – стиль рисования системы координат LayoutStyle – стиль страницы MarkStyle – стили маркирования объектов. Маркирование может использоваться для подсветки выбранных объектов, а также для подсветки операндов команд.

Особенности текущей реализации стилей:

–  –  –

Все параметры стилей являются необязательными свойствами. Например, в стиле рисования 2D кривой может быть не задана толщина или цвет;

Ссылка на стиль может храниться в объекте модели, в группе, в документе, в другом стиле.

В последнем случае стиль является родительским по отношению к стилю, который хранит на него ссылку;

Параметры стилей допускают каскадное наследование.

Используются следующее порядок получения параметров рисования объекта:

o По цепочке стилей объекта. Если у стиля нет свойства, то свойство ищется в родительском стиле и так до конца цепочки родительских стилей;

o По цепочке стилей всех групп. От группы, непосредственно содержащей объект модели, вверх по иерархии до документа.

Помимо предопределённых стилей допускается добавление стилей, реализованных в сторонних приложениях. В этом случае интерпретация параметров стиля реализуется в функциях рисования этого модуля;

Как и любые другие объекты модели, стили хранятся в отдельном контейнере;

Параметры стилей могут быть параметризуемы.

Замечания по использованию стилей:

Как правило, стили разделяются между несколькими объектами.

Имеет смысл организовывать работу со стилями следующим образом:

o Хранить стили в общем контейнере стилей;

o В объектах и группах хранить разделяемые ссылки на стили;

Каскадное наследование имеет смысл использовать для группирования объектов по различным параметрам рисования;

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

В некоторых случаях целесообразно иметь механизм множественности стилей для обеспечения «многослойной» прорисовки объекта. Например, многослойная прорисовка удобна при рисовании областей штриховки/заливки. Отдельным слоем может рисоваться заполнение области, отдельным рисование контура обводки. Для каждого из слоёв может задаваться цвет, прозрачность, толщина линии, угол штриховки и т.д. Последовательность прорисовки задаётся порядковым номером слоя.

Документ Документ модели данных ИИПП является объектом класса RGPlatform::Model::Document.

Данный класс также порождён от базового класса объекта RGPlatform::Model::Object, так как документ может быть частью другой модели и включаться в неё как объект.

Документ представляет собой логически целостный набор объектов модели ИИПП.

Этот набор данных обладает следующими признаками:

Документ имеет единое пространство идентификации. Каждый объект документа имеет уникальный идентификатор.

Изменения объектов в составе документов протоколируются при помощи единой очереди протоколирования, необходимой для выполнения действий по отмене/возврату изменений (undo/redo).

Документ может быть сохранён в один файл, содержащий информацию о всех своих объектах.

При удалении любого подмножества объектов документа, менеджер удаления отслеживает взаимосвязи удаляемых объектов со всеми другими объектами документа.

Соответственно, при выполнении удаления сохраняется целостность документа.

Помимо хранения объектов модели, содержащихся в типизированных контейнерах, документ содержит ряд других данных, обеспечивающий его целостность и реализацию процедуры редактирования:

Протокол изменений. Обеспечивает реализацию функций протоколирования изменений документа, а также реализацию функций по их отмене/возврату. Протокол изменений можно получить при помощи метода GetUndoManager().

Менеджер идентификации объектов документа. Обеспечивает реализацию функций по назначению уникальных идентификаторов объектам, создаваемых в документе. Доступен при помощи метода GetIDManager() Список сессий редактирования документа. Обеспечивает хранение и доступ к истории изменения документа. Доступен при помощи метода GetEditSessions().

Контейнер выбранных объектов документа. Обеспечивает хранение и доступ к списку выбранных объектов документа. Доступен при помощи метода GetSelectionContainer().

Контейнер помеченных объектов документа. Обеспечивает управление пометкой объектов документа. Доступен при помощи метода GetMarkContainer().

Загрузчик данных документа. Обеспечивает доступ к объекту, обеспечивающему сериализацию/десериализацию данных документа. Доступен при помощи метода GetLoader() Дерево выполняемых процессов документа. Обеспечивает итерацию по текущему дереву выполняемых процессов для данного документа. Доступен при помощи метода GetProcessTree() Установки документа. Обеспечивает получение установок (параметров по умолчанию), используемых для создания новых объектов документа. Доступен при помощи метода GetSettings(). Дополнительный метод EditSettings() позволяет получить набор установок для их программного изменения.

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

Организация объектов документа Хранение объектов в документе организовано иерархически.

Корневые объекты иерархии хранятся в типизированных контейнерах документа:

–  –  –

Группы В принципе, любой объект может хранить другие объекты как вложения, тем самым обеспечивая иерархическую организацию модели. В платформе для этих целей уже реализован базовый класс контейнерных объектов Group. Все остальные групповые объектные классы ядра порождаются из этого класса.

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

Примеры возникновения иерархических моделей – это массивы, в том числе многомерные, многоуровневый сборочные модели, чертежи.

Процедура редактирования данных документа ИИПП принципиально не запрещает прямое редактирование данных модели. Например, прямое редактирование данных документа допустимо в случае конвертации модели из другой системы, когда создаётся новый документ. Однако набор таких сценариев является ограниченным.

Большинство стандартных сценариев по внесению изменений в документ предполагает протоколирование этих изменений с целью возможности их последующего отката.

С этой точки зрения, базовые механизмы ИИПП обеспечивают реализацию следующей функциональности:

Протоколирование действий по изменению модели Откат и восстановление изменений Автоматический откат изменений в случае возникновения ошибок Уведомление приложений об изменении модели с передачей соответствующего протокола изменений.

Платформа поддерживает транзакционную модель редактирования, и удовлетворяет основному набору требований:

Атомарность набора действий Целостность и согласованность данных, полученных в результате редактирования Изолированность. Так как платформа поддерживает многопоточность, то параллельные транзакции не оказывают влияние друг на друга Надёжность. В данном случае имеется ввиду обратимость действий, выполняемых в транзакции.

Процедура внесения изменений в документ разбивается на следующие этапы:

Открытие транзакции. Для этого необходимо создать экземпляр класса редактирования RGPlatform::Model::EditDocument, обычно это делает объявлением автоматической переменной в начале функции редактирования. Конструктор принимает указатель на редактируемый документ и имя транзакции. Данное имя будет отображаться в списке отмены действий.

Изменение модели. Данный этап не требует каких-то специальных действий. Достаточно пользоваться методами-модификаторами редактируемого объекта модели: изменение свойств объектов, добавление новых объектов в контейнеры, удаление объектов.

Поддержка транзакций реализуется в самих методах-модификаторах. Для этого в платформе есть класс RGPlatform::Model::EditObject. Достаточно в начале методамодификатора создать экземпляр этого класса и передать ему в конструкторе указатель на редактируемый объект. При этом создаётся копия объекта и добавляется в транзакцию. На транзакцию создаётся только одна копия объекта при первом вызове. При добавлении новых классов данных во внешних модулях ИПО нужно не забывать, в методахмодификаторах этих классов добавлять создание экземпляра класса RGPlatform::Model::EditObject в начале метода. Все классы объектов платформы уже поддерживают транзакции при изменении их свойств. Контейнеры модели также поддерживают транзакции при добавлении и удалении объектов.

Завершение транзакции. Можно у созданного экземпляра класса редактирования RGPlatform::Model::EditDocument вызвать метод End. Если этого на сделать, то метод End будет вызван при деструкции объекта редактирования.

Некоторые замечания по методике использования указанных выше методов:

Допускается вложенное открытие транзакций. В этом случае транзакция создаётся при вызове последней функции закрытия транзакций Экземпляр класса редактирования RGPlatform::Model::EditObject может быть использован повторно. То есть можно закрыть раннее открытую транзакцию явным вызовом метода End, а затем открыть новую транзакцию явным вызовом метода Begin;

В протокол изменений открытой транзакции можно добавлять собственные действия. Для этого в классе редактирования есть метод AddAction. UndoAction - базовый класс для всех типов действий. Протоколирование собственных действий может быть удобно, если объект, в который вносятся изменения, занимает много места в памяти и копировать его нецелесообразно. Другой вариант, когда выполняется модификация специальных данных внешнего приложения, о которых платформа может не знать;

Класс редактирования поддерживает откат и восстановление ранее созданных транзакций. Для этого есть методы Undo/Redo, принимающие в качестве параметра количество откатываемых транзакций;

Можно отменить действия по редактированию. Для этого нужно использовать метод Cancel;

Использование класса редактирования позволяет получать подписчикам уведомление об изменении модели с протоколом внесённых изменений. Механизм подписки на уведомления описан в соответствующем разделе данного документа.

Получить историю редактирования документа в данной сессии можно при помощи метода документа GetUndoManager(), возвращающего объект класса RGPlatform::Model::UndoManager.

Для выполнения действий по отмене и возврату изменений в документе необходимо использовать методы Undo и Redo класса RGPlatform::Model::EditDocument.

Задачи Понятие задачи обеспечивает управление взаимодействием между объектами модели, и поддержку модели в актуальном состоянии:

Задание функциональных зависимостей между элементами модели;

Задание ограничений на модель;

Параметризация модели;

Расширение модели физическими свойствами;

Оптимизация модели;

Выполнение вычислений по модели. Например, генерация отчётов (в том числе и представлений), выполнение инженерные расчёты.

К основным особенностям использования задач в модели можно отнести следующие:

Возможность описания динамически изменяемой модели;

Описание всех этапов работы с моделью и структуры взаимодействия между этими этапами:

o Процессы моделирования формы изделия: генераторы геометрии, параметрические зависимости;

o Инженерные расчёты;

o Генерация отчётности;

Задание зависимостей между результатами расчётов задач и свойствами объектов модели;

Выполнение пересчёта модели;

Отслеживание изменений в модели. В том числе для оптимизации процедуры пересчёта;

Распараллеливание пересчёта.

Задачи являются объектами модели. Базовый класс для всех типов задач RGPlatform::Model::Task.

Классификация задач

В платформе принята следующая иерархия классов задач:

–  –  –

Для большинства типов задач не указаны классы в ядре платформы, так как предполагается их реализация в модулях ИПО.

Например:

Генераторы геометрии реализуются в модулях расширения платформы функциональностью CAD системы;

Задачи генерации конечно-элементной сетки реализуются в модулях инженерных расчётов;

Задачи копирования элементов по определённым законам;

Генераторы временных исполнений для компонент.

В самой платформе реализована работа с переменными, выражениями, базовые средства фильтрации и собственно пересчёт модели.

Основные средства моделирования геометрии, как правило, реализуются в CAD-системах.

Для платформы должен быть разработан внешний модуль, расширяющий функциональность платформы инструментами CAD-систем:

Средства 2D редактирования. В частности, в модели должны быть реализованы задачи для различных способов задания кривых, 2D узлов;

Средства 3D редактирования. В модели должны быть реализованы генераторы тел:

o Выталкивание – операция формирования твёрдого тела выталкиванием исходного контура в заданном направлении.

o Вращение – операция формирования твёрдого тела вращением исходного контура вокруг заданной оси.

o Булева операция – формирование твёрдого тела методом композиции (объединение, вычитание, пересечение) из других твёрдых тел.

o По траектории – операция формирования твёрдого тела перемещением исходного контура по заданной траектории.

o По сечениям – операция формирования твёрдого тела методом аппроксимации набора исходных контуров;

o Различные способы задания систем координат, 2D узлов;

o Новые способы задания ориентации 3D объектов в пространстве;

o И т.д. Список является неполным.

Зависимости Для задания ассоциативных связей между объектами модели введено понятие зависимости.

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

Примеры зависимостей:

Связь тела с генератором тел;

Цепочка генераторов локальных модификаций тела, когда выходные параметры одного генератора являются входными параметрами другого;

Вариационная задача, когда рассчитываются параметры нескольких взаимосвязанных объектов. Например, расчёт сопряжений;

Оптимизационная задача, когда выполняется оптимизация результатов расчёта другой задачи как целевая функция. Переменные модели могут использоваться как управляющие параметры.

Зависимости можно разделить на несколько типов:

Декларативные. Например, прямая связь между свойствами двух объектов;

Процедурные. В данном случае, возможно изменение структуры модели. Например, при изменении количества копий в массиве объектов модели, состав компонентов группы изменяется.

Объекты модели могут поддерживать несколько зависимостей отдельно по каждому свойству.

Нужно учитывать тот факт, что задание нескольких зависимостей для одного свойства может приводить к неопределённости состояния свойства, так как будет зависеть от порядка применения зависимостей.

Допускается расширение видов зависимостей из внешних приложений.

Базовый класс для всех зависимостей RGPlatfrom::Model::Dependency. Зависимости хранятся в контейнере зависимостей объекта модели. В процессе пересчёта объекта вызывается виртуальная функция обновления зависимостей RGPlatfrom::Model::Dependency::Update.

Добавление новых типов зависимостей– это частая ситуация при разработке модулей ИПО.

Параметризация Под параметризацией понимается зависимость одних параметров модели от других.

Такая широкая трактовка позволяет охватить все часто встречающиеся типы параметризации:

Иерархическая параметризация;

Геометрическая параметризация;

Вариационная (размерная) параметризация;

Ассоциативное конструирование;

Объектно-ориентированное конструирование;

Табличная параметризация.

При проектировании структуры классов параметризации и их взаимосвязей решались следующие принципиальные задачи:

Разделение модели на несколько компонент:

o Описание структуры модели;

o Описание зависимостей (в частности, функциональных) между объектами модели;

o Описание различных вариантов моделей;

Такое разделение на компоненты имеет ряд преимуществ:

o Декомпозиция задачи проектирования на отдельные подзадачи;

o Оптимизация готовой модели путём наложения параметрических зависимостей;

o Различные схемы параметризации для одной и той же модели;

o Получение серии результатов для различных постановок задач.

Возможность реализации всех способов параметризации.

В ИИПП параметризация модели обеспечивается следующими средствами:

–  –  –

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

Процедура пересчёта выполняется от родителей к потомкам.

К реализации процедуры пересчёта предъявляются следующие требования:

Возможность распараллеливания задач;

Оптимизация пересчёта. Если данные объекта или задачи не менялись, то их пересчитывать ненужно;

Обработка ошибок. В процессе пересчёта могут возникать ошибки, которые нужно уметь обрабатывать при дальнейшем пересчёте.

Процесс пересчёта может быть частичным. Например, ресурсоёмкие инженерные расчёты могут выполняться отдельно от основной процедуры регенерации модели.

Отслеживание изменений в модели

Как правило, изменения модели носят локальный характер:

–  –  –

Сценарии Сценарии (базовый класс RGPlatform::Model::Scenario) – это задачи, которые выполняются явным вызовом.

Возможны следующие варианты использования сценариев:

Выполнение трудоёмких инженерных расчётов отдельно от общего процесса пересчёта модели;

Сценарии анимации;

Верификация модели.

Сценарии не участвуют в процессе пересчёта модели, так как сами могут вызывать такой пересчёт.

Например, сценарий генерации различных исполнений модели.

С другой стороны, у сценариев могут быть параметры, которые нужно пересчитывать в общей процедуре регенерации модели. Например, для сценария анимации параметры преобразований могут зависеть от элементов модели. В этом случае у сценария может быть процедура пересчёта, которая не совпадает с процедурой проигрывания сценария.

В ядре платформы объявлен только базовый класс сценария. Прикладные сценарии реализуются в отдельных модулях ИПО.

Дерево процессов Процесс – это одноразовое действие. Каждый процесс может быть процедурой, в которой в частности выполняются задачи и сценарии. Порядок выполнения процессов определяется деревом процессов. Независимые ветки дерева можно распараллеливать.

Решения Если рассматривать параметрическую модель как многомерную функцию, то под решениями понимается модель, пересчитанная с подставленными конкретными значениями параметров модели:

Значение управляющих переменных;

Параметры решаемой задачи. Например, точность или метод решения;

Параметры сессии. Например, параметры пользователя и средств редактирования;

Управляющие параметры адаптивных компонентов.

Данные модели можно разделить на две части:

Постоянная, описательная часть модели;

Данные изменяющиеся при пересчёте. Например, геометрические данные.

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

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

Частый пример использования решений – это компоненты, в которых значения параметров передаются из сборочной модели.

Средства визуализации модели ИИПП Для отображения графической информации о модели вводится понятие «представления».

Базовый класс для всех типов представлений RGlatfrom::Model::Representation. Модель может иметь набор разнотипных представлений для визуализации различных аспектов модели.

В настоящей версии платформы реализована поддержка следующих типов представлений:

RGlatfrom::Model::Layout - 2D– страницы, эскизы. Класс реализует интерфейс взаимодействия с двумерной графической подсистемой

RGPlatfrom::Graphics::IGraphicsDatabase:

o Получение множества картинок (метафайлов). Базовый класс для всех типов метафайлов RGPlatfrom::Graphics::Metafile. Каждый класс метафайла реализует виртуальный метод Draw, который выполняет собственно рисование последовательным вызовом базовых команд 2D рисования. Допускается организация иерархий метафайлов для рисования составных картинок с повторяющимися фрагментами o Подписка на уведомления о событиях изменения страницы RGlatfrom::Model::ModelScene - 3D сцена.

Класс реализует интерфейс взаимодействия с трёхмерной графической подсистемой RGPlatfrom::

Scene::ISceneDatabasePtr:

o Опрос графических примитивов (сетки, источники света, текстуры, точки), рисование которых выполняется средствами 3D графики o Подписка на уведомления о событиях изменения сцены Платформа поддерживает также рисование одних страниц на других с произвольной глубиной вложенности. Например, данный механизм может использоваться для рисования чертёжных видов. Информация о связи видов и расположении вложенного вида хранится в экземпляре класса RGlatform::Model::ObjectOnPage.

Также на странице могут отображаться 3D объекты. Для этого используется класс RGlatfrom::Model::Object3DOnPage.

Возможно добавление новых типов представлений:

Деревья для представления структурной информации;

Таблицы для представления отчётов.

Окно связано с представлением. С помощью интерфейса взаимодействия с 2D или 3D графической подсистемой окно получает метафайлы или 3D примитивы и рисует и. Из окна через те же интерфейсы могут приходить уведомления о событиях выбора объектов. В свою очередь представления через механизм подписок уведомляют об изменениях представлений, требующих их перерисовки.

Представления являются модельными объектами. Также, как и другие объекты, они хранятся в документе, их данные сериализуются во внешние физические хранилища. Представления участвуют в пересчёте модели, и могут в процессе пересчёта изменять своё визуальное представление.

Классы представлений ядра платформы RGlatfrom::Model::Layout и RGlatfrom::Model::ModelScene умеют определённым образом визуализировать объекты модели. Для рисования пользовательских данных или переопределения процедуры рисования можно к представлению подключить интерфейсы генерации метафайлов и 3D примитивов.

Описание интерфейса и средств подключения можно найти в документации по платформе.

Другой способ - реализация в модулях ИИПП своих классов представлений и полное перекрытие интерфейса взаимодействия с окнами или частичное переопределение виртуальных методов классов представлений ядра платформы. Новые классы представлений регистрируются так же, как и другие классы объектов и данных, реализованных в модулях ИПО.

Ещё один вариант управления визуальным представлением данных модели – это реализация в модуле ИПО своих прикладных окон. Плюсы такого способы в его гибкости. Из недостатков, большая трудоёмкость и слабая интеграция с платформой, так как другие модули ИПО не могут получить информацию о данном способе визуализации и на машинах, где модуль не установлен, визуализировать эту информацию не получится.

Управление окнами документа Реализация отображения документа и пользовательского интерфейса обеспечивается при помощи оконного механизма. С этой целью в модели данных ИИПП предусмотрен абстрактный класс RGPlatform::Model::View. Для обеспечения унифицированного механизма взаимодействия между моделью и окнами документа, все рабочие окна модели должны быть порождены от данного класса. В классе документа предусмотрен ряд методов, обеспечивающих взаимодействие с его окнами. В свою очередь, механизм уведомления ИИПП обеспечивает взаимодействие с приложениями ИПО, передавая уведомления о таких событиях, как добавление новых окон, закрытие окон, активация окон и т.д.

В классе документа реализованы следующие методы, обеспечивающие работу с окнами:

AddView. Добавить новое окно документ. Данный метод вызывается автоматически в конструкторе базового класса View GetViewCount. Получить общее число окон документа GetView. Получить окно документа по указанному индексу RemoveView. Удалить окно документа. Данный метод вызывается автоматически в деструкторе класса View UpdateView. Обновить содержимое окон документа (перерисовать окна) Класс ISessionNotify, который можно использовать для подписки на уведомление о системных событиях, содержит ряд виртуальных методов, переопределение которых позволяет приложениям получать уведомления о событиях, связанных с оконной системой: ViewCreated, ViewActivated, BeforeViewClosed, ViewClosed.

Управление сессиями редактирования документа Документ хранит информацию о сессиях его редактирования. Сессии редактирования соответствуют последовательности пользовательских сеансов редактирования документа.

Последовательность сессий редактирования документа может отображаться в соответствующем диалоге. В частности, приложение RGPDemo реализует диалог «История документа…».

Объект «Сессия редактирования» информация содержит следующие данные, доступные для опроса:

Время начала сессии Время подтверждения (завершения) сессии Информация о пользователе, выполнявшего редактирование документа в рамках данной сессии Информация о приложении (название конфигурации конфигурация), которое выполнялось в данной сессии Информация о сессии (данные приложения, имя пользователя) определяются приложением, которое было запущено. Эта информация передаётся приложением при инициализации ИИПП.

Сессии редактирования хранят в отдельном разделе файла модели с тем, чтобы данная информация была доступна без чтения другой части информации о модели. Сессии редактирования сохраняются в составе документа только в том случае, если в ней были произведены какие-либо изменения документа. Т.е. были созданы, изменены или удалены какиелибо объекты модели.

Ссылка на сессию редактирования документа хранится в каждом из объектов модели.

Сохраняется ссылка на сессию, в которой был создан объект, и ссылка на сессию, в которой был изменён (отредактирован) объект. Таким образом, ИИПП обеспечивает возможность получения истории создания и редактирования объектов модели.

В процессе работы приложение должно вызывать методы документа StartNewEditSession и CommitCurrentEditSession для начала и завершения (подтверждения) очередной сессии редактирования. Для получения истории редактирования документа предназначен метод GetEditSessions, возвращающий набор объектов класса RGPlatform::Model::DocumentEditSession.

Разработка ИПО Регистрация приложений Модули ИПО (приложения к ИИПП) регистрируются тремя различными способами.

1. Статическая регистрация модуля в файле регистрации приложений

2. Регистрация модуля в системном разделе реестра

3. Регистрация модуля в пользовательском разделе реестра Идентификация приложений С целью обеспечения однозначной идентификации приложений ИПО, каждому идентификатору назначается идентификатор. Идентификатор приложения должен быть уникальным среди всех приложений, разрабатываемых для ИИПП. Он не должен изменяться в процессе доработки и обновления приложения, так как с данным идентификатором связаны все зарегистрированные классы объектов документа, которые могут создаваться данным приложением.

Статическая регистрация модуля в файле регистрации приложений Данный способ регистрации предполагает добавление информации о приложении в текстовый настроечный файл, имя которого соответствует конфигурации ИИПП. В случае конфигурации «RGPDemo» (демонстратора ИИПП), файл имеет название «RGPDemo.Applications.ini».

Информация о каждом приложении добавляется в файл в виде набора записей следующего формата (пример):

[RGPFEMesher] path=RGPFEMesher.dll description=Генератор конечно-элементных сеток

Где название в квадратных скобках соответствует идентификатору приложения.

Параметр «path» задаёт имя загружаемого модуля приложения. Приложение может быть размещено в системной папке ИИПП. В таком случае имя загружаемого модуля задаётся без имени папки. В случае если приложение размещено в другой папке, в качестве имени модуля приложения задаётся его полный путь с указанием адреса расположения.

Параметр «description» задаёт отображаемое название приложения в пользовательском интерфейсе (например, в диалоге управления приложениями). Данный параметр является информационным. Он выводится в списке приложений с целью краткого описания функциональности, реализуемой данным приложением. Параметр нигде не сохраняется, соответственно, может быть изменён по желанию разработчика или переведён на другой язык.

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

Регистрация модуля через системные настройки Данный метод предполагает добавление информации о приложении в системный раздел реестра HKEY_LOCAL_MACHINE/Software или соответствующие системные настроечные файлы Linux.

Данный метод является наиболее подходящим в случае добавления нового приложения ИПО в конфигурацию ИИПП при помощи отдельной процедуры развёртывания (инсталляции).

Процедура регистрации через системный реестр предполагает возможность деинсталляции (отмены регистрации) без какого-либо влияния на другие компоненты системы. Добавление информации о модуле в системный раздел реестра обеспечивает его регистрацию для всех пользователей данного компьютера.

Использование данного метода регистрации приложения предполагает запуск процедуры регистрации с правами администратора Для регистрации модуля данным способом, в системный реестр, в раздел реестра, соответствующий данной конфигурации ИИПП в раздел «Applications» должны быть добавлены папки с именами, соответствующими уникальному идентификатору приложения. В папке должны присутствовать параметры приложения, соответствующего данному идентификатору.

Параметр «Path» задаёт имя модуля приложения, параметр «Description» задаёт отображаемое название приложения, аналогично параметрам, задаваемым при использовании метода статической регистрации.

Регистрация модуля через пользовательские настройки Данный метод предполагает добавление информации о локально зарегистрированных приложениях, добавляемых пользователем в диалоге «Управление приложениями». По структуре данных формат данных о регистрации соответствует формату регистрации в системном разделе реестра. Информация хранится в разделе реестра HKEY_CURRENT_USER/Software для Windows или в соответствующих локальных файлах для Linux.

Информация о регистрации приложения данным методом сохраняется только для текущего пользователя, и не является основным методом регистрации приложений ИПО при их развёртывании (инсталляции).

Управление приложениями через пользовательский интерфейс Демонстратора Программа-демонстратор ИИПП (RGPDemo) обеспечивает вывод списка зарегистрированных приложений, а также управление этим списком и параметрами запуска приложений. С этой целью в интерфейсе Демонстратора реализован диалог «Управление приложениями». Диалог вызывается при помощи пункта контекстного меню «Файл/Управление приложениями…».

Основной список в диалоге содержит следующие колонки:

Наименование. Наименование приложения, соответствующее значению «Description», заданному при регистрации приложения ID. Уникальный идентификатор приложения Модуль. Полный или относительный путь на основной исполняемый модуль приложения Автозапуск. Параметр, задающий необходимость автоматического запуска приложения при запуске системы. Данный параметр может изменяться пользователь. Значение изменённого параметра сохраняется в пользовательских настройках системы (например, в пользовательском разделе реестра). При помощи данного параметра пользователь может блокировать запуск любого приложения, не выполняя отмены его регистрации.

Тип. Тип регистрации приложения. Может иметь следующие значения:

o Статическое. Приложение зарегистрировано через файл настройки. Такое приложение не может быть удалено при помощи данного диалога.

o Зарегистрированное. Приложение зарегистрировано через системные настройки (системный раздел реестра). Такое приложение не может быть удалено при помощи данного диалога.

o Локальное. Приложение, добавленное пользователем при помощи данного диалога, и зарегистрированное в пользовательских настройках (пользовательском разделе реестра). Такое приложение может быть удалено в данном диалоге при помощи кнопки «Удалить».

Состояние. Текущее состояние приложения. В случае, если приложение успешно запущено, выводится строка «Запущено». В случае ошибки запуска приложения, выводится строка ошибки, обнаруженной системой или зарегистрированной приложением, в менеджере приложений при его запуске.

Кнопка «Добавить…» позволяет пользователю добавить новое приложение, выбрав исполняемый модуль приложения в файловой системе. Приложение регистрируется локально. Идентификатор и описание приложения, в случае его успешного запуска, регистрируются самим добавленным приложением.

Любые изменения, выполненные пользователем в данном диалоге, применяются при перезапуске системы (программы-демонстратора).

Настройка и генерация проекта (TODO) Инициализация приложения Инициализация приложения ИПО зависит от того, является ли приложение дополнением (например, дополнительным модулем, плагином, для использования в программе-демонстраторе RGPDemo, или отдельным независимым исполняемым модулем.

Инициализация дополнительного модуля (плагина) Для обеспечения корректной инициализации дополнительного модуля (плагина), в приложении должна быть объявлена глобальная функция InitApplication, которая вызывается платформой непосредственно при запуске приложения. В функцию передаётся контекст инициализации (указатель на объект класса RGPlatform::Model::ApplicationInitContext. Посредством этого объекта, в функцию передаются параметры инициализации. В частности, передаётся указатель на сессию платформы, в которую загружается данное приложение, а также объект, содержащий данные самого приложения.

Простейший код инициализации приложения может выглядеть так:

RGP_APP bool InitApplication(RGPlatform::Model::ApplicationInitContext* context) { context-GetApplcation()-SetID("MyApplication");

return true;

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

Инициализация ИИПП в составе отдельного приложения (TODO) Добавление новых классов данных Платформа позволяет добавлять в модель новые классы элементов данных, реализованные в модуле ИПО.

Например:

Объекты модели. В частности, различные типы задач;

Зависимости;

Контейнеры-обёртки внутренних данных модуля ИПО для интеграции ранее разработанных классов данных в модель платформы;

Типизированные структуры данных для организации составных данных. В частности, типизированные массивы данных.

Правила оформления классов

К добавляемым классам предъявляются следующие требования:

Допустимо порождение из любого класса с корнем в RGPlatform::Model::Data.

Перечислим наиболее типовые случаи добавления новых классов:

o Наследование непосредственно из RGPlatform::Model::Data. Например, для добавления обёрток на внутренние данные модуля ИПО;

o Наследование из класса структурированных данных RGPlatform::Model::StructuredData для составных данных, к которым можно получить доступ через механизм управления свойствами;

o Наследование из класса RGPlatform::Model::Object для добавления новых типов модельных объектов. Это могут быть укрупнённые именованные объекты, на которые можно ссылаться. Эти объекты также могут состоять из данных, типы которых реализованы в модуле ИПО;

o Наследование из класса RGPlatform::Model::Task для добавления новой задачи. Для специализированных задач, как правило, выбирают соответствующие базовые классы.

Например:

Генератор геометрии тела тел RGPlatform::Model::BodyGenerator;

Решатель инженерной задачи RGPlatform::Model::StudyProcessor;

Генератор 2D геометрии RGPlatform::Model::Geometry2DGenerator;

o Наследование из класса RGPlatform::Model::Dependency для создания новых способов задания зависимостей между объектами модели. В платформе реализовано достаточно много типов связей для решения различных задач.

Вполне возможно, что в качестве базы лучше выбирать один из этих классов, расширяя или перекрывая часть его функциональности;

o В модуле ИПО может быть реализована собственная иерархия классов;

Классы не могут быть абстрактными. Данное требование связано с особенностями управления жизненным циклом объектов модели. В частности, платформа поддерживает возможностью чтения/записи данных, класс которых реализован в отсутствующем или отключённом модуле ИИПП, с последующим восстановлением этих данных;

Класс должен быть оформлен с помощью макросов, в которых декларируются и реализуются общесистемные функции:

o Макрос APP_DATA_DECLARATION() добавляется в декларацию класса;

o Макрос APP_DATA_IMPLEMENTATION(Имя класса, Имя родительского класса, Строковое имя класса) добавляется в cpp-файл реализации класса.

Классы должны быть зарегистрированы в платформе в момент инициализации модуля ИПО. Добавление выполняется с помощью шаблонного метода AddClassFactory класса RGPlatform::Model::Application, экземпляр которого передаётся через контекст инициализации приложения RGPlatform::Model::ApplicationInitContext глобальной функции InitApplication.

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

Ниже приводится образец минимально необходимой декларации новой задачи:

#include “Model/Tasks/Task.h” class MyTask:public RGPlatfrom::Model::Task {

public:

–  –  –

bool Calculate(const TaskContext& iTaskContext) override { return true; } };

В cpp-файл с реализацией класса добавляем следующий код:

APP_DATA_IMPLEMENTATION(MyTask, RGPlatfrom::Model::Task, “MyTask”)

Выполняем регистрацию класса в функции регистрации приложения:

RGP_APP bool InitApplication(ApplicationInitContext* context) { auto application=context-GetApplcation();

application-AddClassFactory MyTask();

}

Теперь мы можем создать экземпляр нового класса и добавить его в документ. Например:

void createMyTask(const RGPlatfrom::Model::DocumentPtr& iDocument) { RGPlatfrom::Model::EditDocument edit(iDocument);

auto task=std::make_sharedMyTask();

iDocument-Tasks().Add(task);

} В данной функции открывается транзакция по редактированию документа с помощью декларации автоматической переменной типа RGPlatfrom::Model::EditDocument. Подробностями использования данного метода описаны в разделе «Процедура редактирования данных документа». Затем объект создаётся и добавляется в типизированный контейнер задач.

Добавление простых данных в класс Для обеспечения функциональности, любой класс должен иметь какие-то данные.

Вот пример добавления нескольких простых типов данных:

class MyTask:public RGPlatfrom::Model::Task { …

private:

–  –  –

RGPlatform::Common::Color _colorParam;

bool _boolParam;

RGPlatform::Common::Time _timeParam;

protected:

void CollectProperties(CollectPropertiesContext& oProperties) override;

};

Чтобы обеспечить доступ к этим данным как к свойствам, переопределяем метод

CollectProperties:

#include "Model/Properties/PropertyDeclaration.h" void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

ADD_REAL_PROPERTY(oProperties, MyTask, _realParam, 0, "realParam", 0.0);

ADD_STRING_PROPERTY(oProperties, MyTask, _stringParam, 1, "stringParam");

ADD_INT_PROPERTY(oProperties, MyTask, _intParam, 2, "intParam", 0);

ADD_COLOR_PROPERTY(oProperties, MyTask, _colorParam, 3, "colorParam");

ADD_BOOL_PROPERTY(oProperties, MyTask, _boolParam, 4, "boolParam", true);

ADD_TIME_PROPERTY(oProperties, MyTask, _timeParam, 5, "timeParam");

} В методе с помощью макросов формируется список свойств этого класса. Макросы скрывают детали реализации свойств, которые могут изменяться в процессе развития функциональности платформы. Для разных типов данные названия макросов и их состав отличается. Подробное описание макросов и их параметров можно найти в заголовочном файле ядра “\Model\Properties\PropertyDeclaration.h”. В переопределённом методе нужно не забыть вызвать метод CollectProperties базового класса.

Реализация метода CollectProperties унифицирует доступ к составу данных класса и избавляет разработчика от выполнения многих рутинных функций по работе с данными, таких как:

Чтение/запись данных;

Чтение/запись данных отключённого модуля;

Обобщённая процедура итерации по модели;

Пакетное редактирование свойств;

Актуализация ссылок на другие объекты, геометрические данные, КЭ-сетки, картинки, сцены;

Замена и удаление данных;

Копирование и сравнение данных;

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

Следует сделать несколько замечаний по декларации свойств:

В декларацию свойств можно добавлять атрибуты, которые расширяют информацию об особенностях поведения свойств. Например, свойство может не сохраняться в файл, его нельзя редактировать в списке свойств, свойство может копироваться и т.д. Список атрибутов и их описание можно найти в перечислении RGPlatform::Model::PropertyAttributes;

Имена свойств должны быть уникальны на всю иерархию порождений, писаться слитно и только на английском языке;

Для языковой локализации имени предлагается в файл языковых ресурсов модуля ИПО добавить запись, в которой ключом будет имя свойства;

Номера свойств должны быть уникальны только в границах функции CollectProperties каждого класса.

Методы доступа и модификации данных класса Необязательно пользоваться только свойствами для доступа и модификации данных. В класс можно добавить привычные методы доступа и модификации. Их реализация, как правило, тривиальна.

Исключение составляют объекты модели по следующим причинам:

Редактирование модели выполняется транзакционно;

Изменения протоколируются, чтобы их можно откатывать и восстанавливать;

Модель поддерживает работу в многопоточном режиме. Поэтому необходимо синхронизировать доступ к данным из разных потоков;

Система отслеживает изменения для локальных обновлений модели.

Так как мы разрабатываем класс объекта модели, то реализация методов может выглядеть следующим образом:

void МyTask::SetRealProperty(const double iValue) { RGPlatform::Model::EditObject edit(this);

–  –  –

Декларация автоматических переменных типа RGPlatform::Model::EditObject или RGPlatform::Model::AskObject в начале метода выполняет необходимые действия для синхронизации доступа к данным и уведомления модели об изменении объекта.

Добавление составных данных Как правило, классы не ограничиваются хранением только простых данных.

Требуется добавление структурированных данных как полей. Базовый класс для всех составных данных это RGPlatfrom::Model::StructuredData.

Разработаем новую структуру:

#include “Model/Data/StructuredData.h” class MyStructure:public RGPlatfrom::Model::StructuredData {

public:

–  –  –

private:

double _realParam;

RGPlatform::Common::String _stringParam;

protected:

void CollectProperties(CollectPropertiesContext& oProperties) override;

};

В реализации структуры следует добавить следующий код:

#include "Model/Properties/PropertyDeclaration.h" APP_DATA_IMPLEMENTATION(MyStructure, RGPlatfrom::Model:: StructuredData, “MyStructure”) void MyStructure::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::StructuredData::CollectProperties(oProperties);

ADD_REAL_PROPERTY(oProperties, MyStructure, _realParam, 0, "realParam", 0.0);

ADD_STRING_PROPERTY(oProperties, MyStructure, _stringParam, 1, "stringParam");

}

При инициализации приложения ИПО выполняется регистрация класса:

RGP_APP bool InitApplication(ApplicationInitContext* context) { auto application=context-GetApplcation();

application-AddClassFactory MyTask ();

application-AddClassFactory MyStructure ();

} Процедура разработки и регистрации структуры аналогична используемой для класса задачи. В классе можно использовать структуры. Это можно сделать двумя способами: добавить как поле в классе или с помощью указателя. В примере используются оба способа:

Typedef shared_ptr MyStructure MyStructurePtr;

class MyTask:public RGPlatfrom::Model::Task { …

private:

MyStructure _structure;

MyStructurePtr _structurePtr;

};

Декларация свойств для новых полей:

void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

… ADD_STRUCTURED_PROPERTY_ATTRIBS(oProperties, MyTask, MyStructure, _stucture, 6, "stucture", Composite);

ADD_REFERENCE_PROPERTY(oProperties, MyTask, MyStructure, MyStructure::ClassID(), _structurePtr, 7, "structurePtr");

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

Для ссылок используются «умные» указатели std::shared_ptr. Такой подход гарантирует защиту от проблем, которые присущи простым указателям: не инициализированные указатели;

утечки памяти; указатели на удалённые данные; управление разделяемыми данными и т.д.

Если у составного свойства указать атрибут Composite, то его внутренние данные будут доступны в редакторе свойств объекта как часть данных объекта. Пример использования атрибута показан на картинке. Свойства стиля линии «Начало» и «Конец», задающие параметры рисования концов линии, редактируются вместе со стилем.

Данные структуры могут изменяться. Если структура в конечном счёте входит в состав объекта модели, то эти изменения должны синхронизироваться и протоколироваться, так же как в случае простых данных. В отличие от простых данных, доступ и изменение данных происходит не в методе самого объекта, а методах вложенной структуры. В платформе есть набор инструментальных шаблонов, которые выполняют отложенную синхронизацию и протоколирование изменений вложенных структур.

Например, методы доступа для ранее добавленной структуры могут выглядеть следующим образом:

class MyTask:public RGPlatfrom::Model::Task { …

public:

RGPlatfrom::Model::AskObjectReferenceMyStructure GetMyStructure() const { return RGPlatfrom::Model::AskObjectReferenceMyStructure (this, &_structure); } RGPlatfrom::Model::EditObjectReferenceMyStructure EditCategoryObjects() { return RGPlatfrom::Model::EditObjectReferenceMyStructure (this, &_structure); } } В своей реализации шаблоны вызывают методы RGPlatform::Model::EditObject и RGPlatform::Model::AskObject.

Есть и другие шаблоны доступа, например, поддерживающие проверку изменений. Описание других шаблонов находятся в файле “Model/Document/RGPEditModel.h” Добавление массивов данных Ещё один тип составных данных, которые может понадобиться добавить в класс - это массивы данных. Привычные решения, например, шаблоны STL, в данном случае не подходят, так как массив должен быть интегрирован в платформу, то есть быть унаследован из RGPlatfrom::Model::StructuredData, и уметь возвращать элементы массива как свойства.

В платформе для этих целей реализован шаблон данных модели RGPlatfrom::Model::

BaseTypedDataSet.

Для приведённой выше структуры реализация множества будет выглядеть следующим образом:

class MyStructureSet: public RGPlatfrom::Model::BaseTypedDataSetMyStructure {

public:

–  –  –

RGPlatfrom::Model::DataType PropertyType() const override;

};

В реализации класса добавляется следующий код:

APP_DATA_IMPLEMENTATION(MyStructureSet, RGPlatfrom::Model::BaseTypedDataSetMyStructure, “MyStructureSet”) RGPlatfrom::Model::DataType MyStructureSet::PropertyType () const { return MyStructure::ClassID();

}

При регистрации приложения выполняется регистрация класса:

RGP_APP bool InitApplication(ApplicationInitContext* context) { auto application=context-GetApplcation();

application-AddClassFactory MyTask ();

application-AddClassFactory MyStructure ();

application-AddClassFactory MyStructureSet ();

} Класс MyStructureSet содержит массив указателей std::shared_ptr MyStructure. Базовый шаблон RGPlatfrom::Model::BaseTypedDataSet реализует те же методы, что и std::vector.

В том числе и однонаправленные итераторы по элементам массива. Таким образом, такое множество можно использовать в алгоритмах std.

Например, поиск элемента по массиву может выглядеть следующим образом:

MyStructureSet myset;

myset.push_back auto it=std::find_if(myset.begin(), myset.end(), [](const MyStructurePtr& iElement)-bool { return iElement&& iElement-_stringParam==”Key”;

});

if(it!= myset.end()) { auto value=*it-_realParam;

… }

Множество добавляется в класс MyTask:

class MyTask:public RGPlatfrom::Model::Task { …

private:

MyStructureSet _stuctureSet;

};

Декларация свойств для нового поля:

void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

… ADD_STRUCTURED_PROPERTY (oProperties, MyTask, MyStructureSet, _stuctureSet, 8, "stuctureSet");

} Свойство для массива описывается так же, как и свойство для структуры.

Так как элементы массива могут возвращаться как свойства, то в их описание можно добавить атрибуты, общие для всех элементов. Для этого в шаблоне RGPlatfrom::Model::BaseTypedDataSet есть метод Attributes.

Установка общих атрибутов свойств для всех элементов в конструкторе класса может выглядеть так:

MyStructureSet::MyStructureSet() { Attributes()[RGPlatfrom::Model::Hidden]=true;

}

Или:

MyStructureSet structureSet;

structureSet.Attributes()[RGPlatfrom::Model::Hidden]=true;

В данном случае помечаются элементы, которые будут скрытыми для редактирования в окне редактора свойств.

Добавление связей Между объектами модели могут существовать связи.

Типы связей, использование которых поддерживается в ИИПП:

Зависимости – связи типа «родитель-потомок»

Сильные связи – удаление одного объекта из модели приводит к удалению другого объекта Информационные связи – обычно используются для прямого указания одного объекта на другой, при это в общем случае не являются зависимостями Например, в случае задачи, связи могут обеспечивать задание входных данных на которых выполняется расчёт. В свою очередь, результаты расчёта задачи могут использоваться другими объектами модели, в том числе, как входные параметры других задач.

Ссылка на разделяемые данные

Самый простой способ задания связи – хранение ссылки на другой объект модели:

class MyTask:public RGPlatfrom::Model::Task { …

private:

RGPlatform::Model::ObjectPtr _parent;

};

Если устанавливается зависимость от этого объекта, то декларация свойства будет выглядеть следующим образом:

void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

… ADD_REFERENCE_PROPERTY_ATTRIBS(oProperties, MyTask, Object, Object::ClassID(), _parent, 8, "parent", RGPlatform::Model::Shared);

} Объявление свойства похоже на то, которое использовалось в примере для добавления указателя на структуру. Дополнительно здесь указывается атрибут RGPlatform::Model::Shared, так как это разделяемая ссылка на родительский объект, который хранится в другом месте модели. На данный момент в платформе поддерживается разделение указателей только для объектов модели. Для указателей на остальные классы данных использование атрибута RGPlatform::Model::Shared диагностируется как ошибка.

Если необходимо хранить ссылку на объект, который не является родителем, то в описание свойства нужно добавить атрибут RGPlatform::Model::NotAParent:

void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

… ADD_REFERENCE_PROPERTY_ATTRIBS(oProperties, MyTask, Object, Object::ClassID(), _parent, 8, "parent", RGPlatform::Model::Shared, RGPlatform::Model::NotAParent);

} Следует ещё обратить внимание на атрибуты свойств, которые могут понадобиться для описания правил управления отношениями между объектами в модели:

RGPlatform::Model::PropertyKillsOwner - при удалении объекта, на который ссылается свойство, должен быть удалён содержащий его объект RGPlatform::Model::OwnerKillsProperty - при удалении объекта должен быть удалён объект, на который он ссылается RGPlatform::Model::AlwaysBreakablePropertyOwnerLink - При удалении объекта, на который ссылается свойство, просто разрывается связь между объектами Добавление зависимостей Обычно, объект-потомок использует только часть данных родительского объекта. Для отслеживания изменений родителя используются зависимости, которые также являются классами данных. У одного объекта может быть произвольное число входных данных, которые хранятся в контейнере зависимостей в базовом классе объектов модели RGPlatform::Model::Object.

Зависимости можно добавлять, удалять и редактировать.

В платформе поддерживается достаточно много типов зависимостей. Все они порождены от класса RGPlatform::Model::Dependency. Описание классов зависимостей доступно в справочном руководстве.

Для связывания однотипных свойств родителя и потомка в RGPlatform::Model::Object есть группа одноименных методов SetRelatedData, которые добавляют в контейнер зависимостей объекта связи RGPlatform::Model::RelatedData.

Пример такого задания:

typedef std::shared_ptrMyTask MyTaskPtr;

void SetRelation(const MyTaskPtr& iParent, const MyTaskPtr& iChild) { RGPlatform::Model::PropertyID parentID(MyTask::ClassID(), 0);

RGPlatform::Model::PropertyIDs childID;

childID.push_back(RGPlatform::Model::PropertyID (MyTask::ClassID(), 6));

childID.push_back(RGPlatform::Model::PropertyID (MyStructure::ClassID(), 0));

iChild-SetRelatedData(iParent, parentID, childID, true);

} В данном примере устанавливается связь между полем MyTask._realParam родительского объекта и MyTask._structure._realParam объекта-потомка. Для этого в метод SetRelatedData передаётся указатель на родительский объект, идентификатор свойства родителя и путь к свойству в дочернем объекте. Последний параметр указывает, что это геометрическая связь, то есть при пересчёте модели, когда обновляются связи, если значение поля родительского объекта изменится, то в поле объекта потомка скопируется новое значение и у потомка установится флаг неактуальности его геометрических данных.

Идентификатор свойства задаётся идентификатором класса объекта, в котором свойство объявлено и номером свойства в списке свойств метода CollectProperties.

Создание новых типов зависимостей В некоторых случаях может потребоваться разработать свой класс зависимости.

В качестве примера создаётся класс геометрической зависимости, то есть связь между полем MyTask._realParam родительского объекта и MyTask._structure._realParam объектапотомка class MyRelatedData:public RGPlatform::Model::Dependency {

protected:

void CollectProperties(CollectPropertiesContext& oProperties) override;

public:

–  –  –

bool Update(DependencyContext* const iContext, StructuredData* iChild) override;

};

В реализации класса добавляется следующий код:

APP_DATA_IMPLEMENTATION(MyRelatedData, RGPlatform::Model::Dependency, “MyRelatedData”)

MyRelatedData::MyRelatedData (const MyTaskPtr& iParent):

RGPlatform::Model::Dependency(iParent) { } bool MyRelatedData::Update(DependencyContext* const iContext, StructuredData* iChild) { auto child=RGPlatform::Model::CastMyTask( iChild);

–  –  –

if(fabs(child-_structure._realParam!= parent-_realParam)1.0-8) { child-SetChanged(RGPlatform::Model::Object::GeometryChanged);

child-_structure._realParam= parent-_realParam;

} } Указатель на родителя хранится в базовом классе RGPlatform::Model::Dependency. В виртуальном методе выполняется копирование свойства из родителя в потомок. В данном примере код простой, так как родитель и потомок типизированы. Классы зависимостей яда платформы в этом смысле более универсальны, так как используют идентификаторы свойств для доступа к данным.

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

Зависимости от сложных геометрических данных используют для отслеживания изменений номер версии пересчёта геометрии родительского объекта RGPlatform::Model::Object::

GetGeometryVersion(). В зависимости запоминается и сравнивается не сама геометрия, а версия пересчёта геометрии родителя.

Нужно не забыть о регистрации нового класса в платформе:

RGP_APP bool InitApplication(ApplicationInitContext* context) { auto application=context-GetApplcation();

application-AddClassFactory MyTask ();

application-AddClassFactory MyStructure ();

application-AddClassFactory MyStructureSet ();

application-AddClassFactory MyRelatedData ();

}

Пример добавления связи может выглядеть следующим образом:

void SetRelation(const MyTaskPtr& iParent, const MyTaskPtr& iChild) { iChild - AddDependency(std::make_shared MyRelatedData ( iParent));

} Добавление размерных величин, связанных с переменными Если в классе данных нужно хранить физическую величину, значение которой может задаваться переменной или другой функциональной зависимостью, то рекомендуется воспользоваться готовым классом RGPlatform::Model::RealParameterData. Класс обеспечивает хранение значения вместе с его единицей измерения. Класс унаследован из RGPlatform::Model::Dependency, и поддерживает возможность связывания значения параметра с родительским объектом, в частности с переменной или с какой-то числовой характеристикой родителя: со свойством или геометрической характеристикой.

Добавление нового поля в класс:

class MyTask:public RGPlatfrom::Model::Task { …

private:

RGPlatform::Model::RealParameterData _valueParam;

};

Добавление поля в список свойств:

void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

… ADD_STRUCTURED_PROPERTY (oProperties, MyTask, RGPlatform::Model::RealParameterData, _valueParam, 9, " valueParam ");

} Теперь, если связать параметр с переменной, то после изменения значения переменной в процессе пересчёта модели значение параметра будет обновляться. Если нужно, чтобы при изменении значения потомок помечался как изменённый, то вместо класса RGPlatform::Model::RealParameterData нужно использовать класс RGPlatform::Model::RealGeometryParameterData.

Добавление 2D и 3D точек По аналогии со скалярной физической величиной для 2D и 3D точек в ядре платформы также есть классы, которые могут хранить координаты точек, единицы, в которых они заданы, а также различные типы зависимости от свойств других объектов модели. Это классы RGPlatform::Model::Point2DParameterData и RGPlatform::Model::Point3DParameterData, соответственно.

Сохранение и чтение пользовательских данных Если поля класса возвращаются как свойства, то чтение/запись таких данных обычно выполняется базовыми средствами платформы. Если в приложении необходимо обеспечить запись и чтение внутренних данных, структура которых неизвестна для платформы, то нужно переопределить виртуальные методы базового класса RGPlatform::Model::Data::ReadCustomData и RGPlatform::Model::Data::WriteCustomData. В параметры этих функций передаются экземпляры классов последовательного чтения и записи структурированных данных. При этом вся ответственность за формат этих данных и совместимость версий лежит на разработчике такого класса.

Если отключён или не установлен модуль ИПО, в котором был реализован класс, данные которого хранятся в модели, то вместо оригинального объекта создаётся proxy-объект, в котором сохраняется структура данных, возвращаемых как свойства, а пользовательские данные хранятся единым блоком. Proxy-объект сохраняет данные в исходном формате, чтобы они потом восстановились, если модуль ИПО снова включён.

Интеграция внутрисистемных данных в модель платформы Ещё один вариант интеграции данных модуля ИПО в платформу - это разработать объект-обёртку, который будет хранить внутри себя неизвестные платформе данные.

Например, реализация такого класса может выглядеть следующим образом:

#include “Model/Data/Data.h” class MyData:public RGPlatfrom::Model::Data {

public:

–  –  –

void ReadCustomData (Storage::ReadContext& ioContext, Storage::SAXReader& iNode) override;

void WriteCustomData(Storage::WriteContext& ioContext, Storage::SAXWriter& iNode) const override;

void CopyFrom (const RGPlatfrom::Model::Data& iData) override;

private:

–  –  –

};

В реализации класса добавляется следующий код:

APP_DATA_IMPLEMENTATION(MyData, RGPlatform::Model:: Data, “MyData”) void MyData::ReadCustomData (Storage::ReadContext& ioContext, Storage::SAXReader& iNode) { … } void MyData::WriteCustomData(Storage::WriteContext& ioContext, Storage::SAXWriter& iNode) const { … } void MyData::CopyFrom(const RGPlatfrom::Model::Data& iData) { RGPlatfrom::Model::Data::CopyFrom(iData);

if(iData.Type()==MyData::ClassID()) data=static_castconst MyData &(iData)._data;

} Для всех классов составных данных, унаследованных от RGPlaform::Model::StructuredData, копирование данных выполняется по базе через механизм копирования свойств. В случае если в классе есть данные, которые не возвращаются как свойства или класс унаследован непосредственно из RGPlatform::Model::Data, как в данном примере, то в классе должен быть переопределён метод CopyFrom для обеспечения копирования таких данных.

Теперь класс должен быть зарегистрирован:

RGP_APP bool InitApplication(ApplicationInitContext* context) { … application-AddClassFactoryMyData();

}

Добавим новые данные в задачу:

typedef std::hared_ptrMyData MyDataPtr;

class MyTask:public RGPlatfrom::Model::Task { …

private:

–  –  –

};

Добавление поля в список свойств:

void MyTask::CollectProperties(CollectPropertiesContext& oProperties) { RGPlatform::Model::Task::CollectProperties(oProperties);

… ADD_REFERENCE_PROPERTY (oProperties, MyTask, MyData, MyData::ClassID(), _dataParam, 10, "dataParam");

} Элемент данных добавляется как указатель. Если MyData унаследовать из RGPlatform::Model::StructuredData, то его можно использовать как поле. Выбор базы в данном случае не существенен, так как у такой структуры не будет свойств.

Примеры реализации прикладных задач

Объекты платформы можно условно разделить на две группы:

Объекты описания результатов моделирования. Это тела, системы координат, точки, линии, области заливки, размеры, тексты и т.д.;

Объекты описания средств моделирования. Это генераторы тел, кривых, различные способы здания точек, систем координат.

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

Ниже приведены примеры таких генераторов с описанием особенностей реализации порождённых классов в модулях ИПО.

Генератор тел В платформе хранение тел реализовано в классе объекта модели RGPlatform::Model::BodyObject. Данный класс не предполагает наследований.

Тела, которые хранятся в RGPlatform::Model::BodyObject, могут быть получены при импорте модели из обменного формата, например STEP. В таком случае они не хранят своей истории создания.

Другой вариант получения тел – это создание при помощи генераторов тел (операций). В этом случае тело получается в результате пересчёта операции.

Базовым классом для генераторов тел является RGPlatform::Model::BodyGenerator. В свою очередь генератор тела может быть связан с другим генератором тела, образуя цепочку модифицирующих операций.

В классе RGPlatform::Model::BodyObject есть метод SetGenerator() для задания связи с генератором. В классе генератора RGPlatform::Model::BodyGenerator есть метод SetTargetGenerator() для задания связи с другим генераторам тел.

На картинке представлена одна из возможных цепочек операций, описывающих процесс моделирования результирующего тела:

Реализация своего класса генератора тела может выглядеть следующим образом:

class MyBodyGenerator:public RGPlatform::Model::BodyGenerator { …

protected:

bool CalculateTools (const RGPlatform::Model::TaskContext& iTaskContext, RGK::Model::BodyArray& oBodies) override;

};

bool MyBodyGenerator:CalculateTools (const RGPlatform::Model::TaskContext& iTaskContext, RGK::Model::BodyArray& oBodies) {

–  –  –

RGK::Generators::PrimitiveGenerator generator(iTaskContext.GetRGKContext());

RGK::Math::LCS3D location;

RGK::Math::Vector3D sides(1.0, 1.0, 1.0);

RGK::Model::BodyPtr body;

auto result=generator.CreateBox(location, sides, body);

if(result!=RGK::Common::Success) { AddError (std::make_sharedRGPlatform::Model::ErrorMessage (RGPlatform::Model::Error::Serious, "Can’t create cube"));

–  –  –

В классе RGPlatform::Model::BodyGenerator можно также задавать булеву операцию с другим телом. То есть над результатом, полученным методом CalculateTools может быть затем выполнена булева операция, включающая другой операндом, передаваемый с помощью функции RGPlatform::Model::BodyGenerator::SetTargetGenerator().

Пример создания генератора и связывания его с телом:

void CreateBody(const RGPlatfrom::Model::DocumentPtr& iDocument) { RGPlatform::Model::EditDocument edit(iDocument);

auto generator=std::make_shared MyBodyGenerator();

iDocument-Tasks().Add(generator);

auto body=std::make_sharedRGPlatfrom::Model::Body();

body-SetGenerator(generator);

iDocument-Objects().Add(body);

} Генератор 2D геометрии Базовый класс генератора для всех типов 2D геометрии RGPlatform::Model::Geometry2DGenerator.

В порождённом классе переопределяется виртуальный метод Calculate. Результаты запоминаются в базовом классе генератора с помощью метода SetGeometry. Созданный генератор может быть использован в объекте RGPlatform::Model::LayoutObject с помощью метода SetGenerator.

Простой пример реализации генератора для 2D кривой:

class MyCurveGenerator:public RGPlatform::Model::Geometry2DGenerator { …

protected:

bool Calculate (const RGPlatform::Model::TaskContext& iTaskContext) override;

};

bool MyCurveGenerator: Calculate (const RGPlatform::Model::TaskContext& iTaskContext) {

–  –  –

Пример создания генератора и связывания его с 2D кривой:

void CreateLine(const RGPlatfrom::Model::DocumentPtr& iDocument, const RGPlatfrom::Model::LayoutPtr& iLayout) { RGPlatform::Model::EditDocument edit(iDocument);

auto generator=std::make_sharedMyCurveGenerator();

iDocument-Tasks().Add(generator);

auto curve=std::make_sharedRGPlatfrom::Model::Curve2D();

curve -SetGenerator(generator);

iLayout -Components().Add(curve);

} Созданная 2D кривая была добавлена на страницу документа. Как правило, 2D элементы рисования относятся к одной странице. В то же время, правила организации модели позволяют добавить 2D кривую, например, в универсальный контейнер объектов модели, а затем, а на несколько страниц добавить ссылки на эту кривую для рисования на этих страницах. Например, размеры могут быть трёхмерными и рисоваться в сцене и на нескольких проекционных видах.

Генератор КЭ-сетки

В платформе реализован набор классов для работы с КЭ-сеткой:

RGPlatform::VolumePartition::VolumeMesh – класс редактирования и хранения сетки RGPlatform::Model::MeshObject - объект модели, хранящий КЭ-сетки. В конечном счёте все данные хранятся в объектах модели RGPlatform::Model::MeshGenerator – базовый класс генератора сетки.

Также разработан обменный формат хранения сеток, реализованы средства отложенной загрузки сеток, модельная сцена обеспечивает средства визуализации сеток. Унификация формата позволяет использовать сетку в различных приложениях платформы. При этом сохраняется доступ к ранее построенной сетке, даже если модуль генератора отключён.

Пример кода по генерации сетки находится в приложении CAEPlugin, входящем в состав SDK ИИПП.

Если данные сетки хранятся в собственном формате, то рекомендуется воспользоваться средствами интеграции этих данных в платформу:

Классы-обёртки;

Ссылки на файлы, в том числе вложенные, которые хранят сетку в своём формате;

Переопределение средств визуализации сеток;

Генератор сетки при этом можно наследовать непосредственно из базового класса задачи RGPlatform::Model::Task.

Решатель инженерной задач Базовым классом решателя задачи является RGPlatform::Model::StudyProcessor.

Выполнение расчёта должно выполняться в методе Calculate.

Базовый класс является универсальным для любых типов решателей инженерных расчётов.

Особенностями инженерных расчётов являются поддержка отложенных вычислений и методы связывания с задачей, для которой выполняется расчёт.

Пример класса выполнения инженерных расчётов можно также найти в примере CAEPlugin из состава SDK ИИПП.

Создание элементов пользовательского интерфейса ИИПП предоставляет инструменты формального описания состава элементов пользовательского интерфейса, которые могут быть доступными при их реализации конечными приложениями. К элементам такого описания можно отнести различные действия и команды, которые станут доступными через панели кнопок, текстовое меню, контекстное меню, элемент управления «лента», всплывающие панели кнопок и т.д. Такие элементы пользовательского интерфейса, регистрируются без привязки к их физической реализации. При регистрации, кроме описания типа элемента, его поведения также регистрируются функции-обработчики приложения, которые будут вызываться в случае активации этих элементов. Такое формальное описание позволяет реализовать выполнение команд приложений без привязки к конкретной исполняющей оболочке, в том числе с использованием клиент-серверных реализаций взаимодействия платформы с пользователем.

Данный механизм позволяет описывать как «основные» элементы пользовательского интерфейса (панели кнопок, элементы ленточного интерфейса, текстовое меню и т.д.), так и контекстнозависимые элементы (команды контекстного меню, всплывающих панелей кнопок и т.д.).

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

С целью описания элемента пользовательского интерфейса в платформа предоставляет класс RGPlatform::UI::Tool. В простейшем случае он формально описывает кнопку или команду контекстного меню.

В классе имеется несколько конструкторов:

Tool(const ID& iId);

Tool(const ID& iId, const Common::String& iTitle, ToolHandler* iHandler);

Tool(const ID& iId, const Common::String& iTitle, ToolHandler* iHandler, ToolUpdater* iUpdater, bool iOnlyDocument = true, bool iCheckable = false);

Tool(const ID& iId, const Common::String & iTitle, const Common::String & iIcon, ToolHandler* iHandler, ToolUpdater* iUpdater, bool iOnlyDocument = true, bool iCheckable = false);

Параметры конструкторов:

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

iTitle – основной текст или описание элемента. Для управления дополнительными описаниями (полное или сокращённое) имеются дополнительные методы в данном классе.

iIcon – имя иконки, которая будет использоваться для отображения данного элемента в пользовательском интерфейсе. Правила поиска иконок и их формат регламентируются параметрами сессии.

iHandler – обработчик события от элемента при его активации iUpdater – обработчик события, используемого для обновления состояния элемента iOnlyDocument – признак доступности элемента только при наличии активного документа. При значении false данный элемент будет доступен даже в случае отсутствия документа.

iCheckable – признак действия элемента как кнопки, допускающей состояния «нажата/не нажата»

Сохранение и восстановление настроек приложения С целью реализации функций сохранения и восстановления локальных настроек приложений, ИИПП предоставляет специализированный инструмент. В платформе объявлен абстрактный класс RGPlatform::Model::OptionsSerializer. В нём объявлены методы, при помощи которых приложение может сохранять и восстанавливать свои параметры в локальных пользовательских настройках, не заботясь об их конкретной физической реализации.

Конкретная система переопределяет данный интерфейс, реализуя данные методы для того, чтобы обеспечить функциональность сохранения/восстановление таких данных при помощи конкретной библиотеки. В частности, приложение-демонстратор RGPDemo обеспечивает работу этих функций при помощи использования соответствующих функций библиотеки Qt. При инициализации сессии платформы создаётся объект класса, порождённого из RGPlatform::Model::OptionsSerializer, и регистрируется в сессии платформы при помощи метода RGPlatform::Model::Session::SetOptionsSerializer.

Пример кода, обеспечивающего реализацию сохранения/восстановления параметров типа bool, при помощи методов класса MyOptionsSerializer:

class MyOptionsSerializer : public RGPlatform::Model::OptionsSerializer {

public:

virtual bool GetValue(Common::String iSection,Common::String iName,bool iValue);

virtual void SetValue(Common::String iSection,Common::String iName,bool iValue);

virtual int GetValue(Common::String iSection,Common::String iName,int iValue);

virtual void SetValue(Common::String iSection,Common::String iName,int iValue);

virtual double GetValue(Common::String iSection,Common::String iName,double iValue);

virtual void SetValue(Common::String iSection,Common::String iName,double iValue);

virtual Common::String GetValue(Common::String iSection,Common::String iName,Common::String iValue);

virtual void SetValue(Common::String iSection,Common::String iName,Common::String iValue);

};

… RGPlatform::Model::Sesion* session = RGPlatform::Model::Sesion::GetSession();

if(session) { Session-SetOptionsSerializer(new MyOptionsSerializer());

} При работе приложение может пользоваться объектом данного класса, получаемых через сессию платформы для обеспечения сохранения своих настроек и последующего восстановления при повторном запуске.

Кроме перечисленных выше методов, класс SetOptionsSerializer имеет специализированные методы по работе со статическими опциями (StaticOptions). Список данных опций появляется в диалоге «Установки» в соответствии с их описанием для редактирования пользователем. Таким образом платформа предоставляет простой и открытый механизм, позволяющий пользователю управлять настройками приложений.

Команда Команда представляет собой объект, получающий события пользовательского интерфейса (например, перемещение или нажатие кнопки мыши, нажатие клавиши клавиатуры) в течение времени её выполнения. Команда является модальным обработчиком событий, реализующим прикладную логику по созданию или редактированию объектов модели определённого типа. В системе одновременно может выполняться только одна команда. При запуске другой команды в то время, как одна команда уже выполняется, текущая команда становится неактивной и перестаёт получать события от окон документа до завершения вложенной команды.

Каждая команда имеет уникальный текстовый идентификатор. Идентификатор используется для хранения настроек команды, получения текущей справки, сопоставления элементов пользовательского интерфейса (кнопок), используемых для запуска команд, с активной командой и т.д.

Базовым классом команды является RGPlatform::UI::Command. Уведомления о различных событиях передаются команде при помощи виртуальных методов, которые должны переопределяться в конкретном классе команды для выполнения соответствующей обработки.

Механизм выполнения команд в ИИПП является платформенно-независимым. В общем случае команды могут быть реализованы одинаково для выполнения в различных операционных системах, а также при клиент-серверной реализации пользовательского интерфейса.

С этой точки зрения для разработчиков ИПО рекомендуется отделять платформенно-зависимый код от платформенно-независимого. При такой реализации, переносимость команд на различные вычислительные платформы может быть достигнута наиболее простым образом.

В большинстве случаев команда реализует пользовательский интерфейс по созданию или редактированию объектов документа. Соответственно, команда создаётся с указанием на документ, в контексте которого она выполняется. При активации другого документа команда автоматически завершается.

Обычно команда имеет свою панель диалога, обеспечивающую реализацию ввода координат, управления опциями, управления списками выбранных объектов и т.д. С этой целью в платформе имеется механизм управления диалоговыми окнами, который описан в соответствующем разделе.

Ниже приведён список основных методов, которые можно переопределить в классе команды приложения для реализации собственного сценария пользовательского интерфейса:

GetID. Возвращает уникальный идентификатор команды. Метод является обязательным к переопределению Start. Вызывается при запуске команды. Возвращает true в случае успешной инициализации Finish. Вызывается перед завершением команды. Обычно выполняет очистку внутренних данных команды Release. Вызывается после завершения команды. В базовой реализации удаляет объект команды StartCommand. Выполняет запрос на выполнение другой вложенной команды.

Возвращает true в случае разрешения выполнения вложенной команды. По умолчанию возвращает false Suspend. Уведомление о приостановке работы команды в связи с запуском вложенной команды Resume. Уведомление о возобновлении работы команды в связи с завершением работы вложенной команды SelectObject. Уведомление о выборе объекта модели. Платформа вызывает данное уведомление при выборе объекта различными способами. Например, через окно навигатора модели или программным путём. Команда может вернуть переданный в метод объект (что подтверждает его выбор), вернуть другой объект (что обеспечивает выбор другого объекта вместо переданного), либо вернуть nullptr, что сообщит платформе о том, что переданный объект не может быть выбран.

KeyPressed. Уведомление о нажатии клавиши клавиатуры. Передачу кодов клавиш обеспечивает перечислители RGPlatform::UI::Key и RGPlatform::UI::KeyModifier.

MouseMove. Перемещение указателя мыши LButtonPress. Нажатие левой кнопки мыши LButtonRelease. Отпускание левой кнопки мыши LDblClick. Двойной щелчок левой кнопкой мыши RButtonPress. Нажатие правой кнопки мыши RButtonRelease. Отпускание правой кнопки мыши RDblClick. Двойной щелчок правой кнопкой мыши MButtonPress. Нажатие средней кнопки мыши MButtonRelease. Отпускание средней кнопки мыши MDblClick. Двойной щелчок средней кнопкой мыши GetFilter. Возвращает фильтр, обеспечивающий динамическую подсветку и выбор объектов модели. Фильтр реализуется классом RGPlatform::Model::SelectionFilter. Для реализации специфического поведения фильтра, необходимо использовать класс, порождённый от данного, и переопределить метод Select.

GetGraphics. Получить объект графического контекста для рисования в указанном окне.

GetDynamicGraphics. Получить объект графического контекста для рисования динамического курсора в указанном окне.

ReleaseDynamicGraphics. Завершить рисование динамического курсора. При выполнении данного метода, изображение, сформированное при вызове методов графического контекста, выводится на экран.

EmptyDynamicGraphics. Очистить слой динамического курсора.

Terminate. Вызов данного метода завершает выполнение команды.

SetPrompt. Вывести текст подсказки. Указанный текст выводится в интерфейсе системы для уведомления пользователя о состоянии команды или необходимых действиях.

GetView. Получить активное окно, в котором выполняется команда.

ViewActivated. Уведомление об активации окна документа.

OnFilterToolbarCommand. Уведомление об изменении состояния кнопок панели фильтров.

GetFilterToolbarDefinition. Получить описание списка опций панели фильтров GetCommandType. Получить тип выполняемой команды GetDialog. Получить диалог, используемый командой GetMarkContainer. Получить контейнер пометки, используемый командой. В общем случае, каждая команда имеет свой собственный контейнер помеченных объектов, что упрощает управление пометкой и стилем отображения помеченных объектов.

CollectCommandTools. Получение описания инструментов пользовательского интерфейса, используемых для формирования контекстного меню, динамической панели кнопок и т.д.

Управление командами С целью управления процедурой запуска и выполнения команд, в ИИПП реализован класс RGPlatform::UI::RGPUIData. Объект данного класса можно получить при помощи статического метода этого класса GetUIData. Создаётся и регистрируется объект данного класса при инициализации конкретного конечного приложения платформы в случае, если оно поддерживает инструменты пользовательского интерфейса. Например, поведение объекта, порождённого от класса RGPUIData, реализуется приложением RGPDemo.

Методы класса RGPUIData обеспечивают запуск и выполнение команд:

AddCommand. Добавить команду. Метод добавляет данную команду в стек выполняемых команд RemoveActiveCommand. Метод завершает выполнение активной команды (последней команды в стеке выполняемых команд) RemoveAllCommands. Завершить выполнение всех команд GetActiveCommand. Получить активную выполняемую команду. Возвращает nullptr в случае отсутствия выполняемых команд Ниже приведён пример кода, выполняющего запуск команды приложения ИПО. Команда реализуется классом MyCommand. Перед её запуском завершается выполнение всех других выполняемых команд.

RGP_APP void StartMyCommand (RGPlatform::UI::ToolContext *iContext) { if(RGPlatform::UI::RGPUIData* data = RGPlatform::UI::RGPUIData::GetUIData()) { data-RemoveAllCommands();

data-AddCommand(MyCommand(),iContext);

} } Обработка уведомлений платформы При начальной загрузке модули ИПО подписываются на получение системных уведомлений о различных событиях (сигналах), генерируемых текущей сессией ИИПП

RGPlatform::Model::Session. События различны по типу и моменту их возникновения:

Системные события: инициализация системы или приложения, завершение работы приложения.

События пользовательского интерфейса: перемещения мыши, нажатие клавиш клавиатуры, вызов команд, нажатие кнопок в диалогах и других элементах пользовательского интерфейса.

События на уровне модели: пересчёт модели, перерисовка изображения, открытие файла модели, сохранение файла модели.

События на уровне отдельных объектов модели: создание, изменение, удаление, перерисовка, сохранение. Модули и объекты ИПО получают такие события по согласованному унифицированному протоколу для реализации своей прикладной логики работы.

В функции-обработчики уведомлений о событиях передаётся информация о соответствующем событии — контекст события. Приложение выполняет анализ и обработку данных этого контекста.

Классы, обеспечивающие интерфейсы передачи приложению уведомлений о событиях, представлены в пространстве имён RGPlatform::Interfaces. Для подключения и отключения подписки на обработку уведомлений различных типов, в классах сессии ИИПП и документа имеются соответствующие методы.

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

–  –  –

Объявить класс, порождённый от соответствующего базового интерфейсного класса, переопределив в нём требуемые методы Создать объект этого класса при инициализации приложения или каком-либо другом действии Зарегистрировать объект данного класса вызовом соответствующего метода сессии, документа или объекта модели, вызвав соответствующий метод «Connect…»

Отменить регистрацию данного объекта, вызвав соответствующий метод «Disconnect…», при завершении работы приложения или окончания процесса подписки.

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

Неоправданное многократное добавление объектов подписки может снизить общую эффективность работы приложения, использующего данный механизм.

Также нужно иметь в виду, что на одно и то же уведомление могут подписываться несколько приложений. Некоторые из методов, вызываемых через интерфейсные классы, предполагают реакцию приложения, т.е. по сути, являются запросом. К примеру, вызов метода класса RGPlatform::Interfaces::ISessionNotify::MainWindowClosing является запросом разрешения у приложений на закрытие главного окна системы. В случае, если любое из приложений, подписанное на соответствующее уведомление, вернёт false, то другим приложениям данный запрос уже не придёт.

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

Оболочка пользовательского интерфейса ИИПП имеет в своём составе унифицированные механизмы управления элементами пользовательского интерфейса. Они позволяют быстро разрабатывать интерфейсные компоненты приложений, переносимые на различные вычислительные платформы.

Эти механизмы имеют различные уровни реализации. Базовый уровень обеспечивает формальное взаимодействие с элементами пользовательского интерфейса без привязки к какойлибо конкретной библиотеке, обеспечивающей взаимодействие с оконной системой ОС. Кроме базового уровня, ИИПП имеет в своём составе компоненты, реализующие функции пользовательского интерфейса при помощи популярной кроссплатформенной библиотеки Qt.

Данная функциональность обеспечивается оболочкой пользовательского интерфейса, состоящая из модулей RGPWidgets и RGPWidgets3D. Эти модули обеспечивают большинство функций пользовательского интерфейса программы-демонстратора RGPDemo, и могут использоваться для реализации пользовательского интерфейса других программ.

Главное окно системы Основным элементом, обеспечивающим «точку подключения» к функциям пользовательского интерфейса оболочки, является программный интерфейс главного окна. Главное окно имеет два уровня реализации – абстрактный уровень реализуется при помощи класса RGPlatform::UI::MainWindowBase. Он имеет виртуальные методы, обеспечивающие взаимодействие с главным окном вне зависимости от его реализации при помощи какой-либо конкретной библиотеки пользовательского интерфейса, используемой в системе. Статический метод этого класса RegisterMainWindow позволяет зарегистрировать в оболочке объект, реализующий функциональность главного окна. Статический метод GetMainWindow позволяет получить указатель на объект главного окна. В случае отсутствия главного окна системы данный метод возвращает nullptr.

В оболочке пользовательского интерфейса имеется реализация класса главного окна при помощи библиотеки Qt. Это класс RGPlatform::Widgets::MainWindow, порождённый от класса MainWindowBase. Все виртуальные методы базового класса переопределены в данном классе, и реализованы при помощи соответствующей функциональности Qt.

Перечень основных методов класса MainWindowBase:

OpenDocument. Данный метод обеспечивает открытие документа SetPrompt. Показать подсказку, соответствующую текущему состоянию пользовательского интерфейса системы CreateDocumentWindow. Открывает новое окно документа, соответствующее параметрам метода CloseDocumentWindow. Закрывает окно документа, соответствующее оконному объекту платформы класса RGPlatform::Model::View GetActiveView. Получить текущее активное окно документа SetActiveView. Установить текущее активное окно документа (активировать указанное окно) CreateControlLayout. Создать диалог, соответствующий формальному описанию набора элементов управления диалога RunProcess. Запустить процесс в параллельном потоке ShowMessageBox. Показать модальное окно сообщения с указанным текстом сообщения и набором кнопок, соответствующим вариантам ответа пользователя DeleteSelection. Удалить объекты, находящиеся в контейнере выбранных объектов документа DeleteObjects. Показать диалог с опциями удаления объектов, перечисленных в списке RequestCreateVariables. Показать диалог с подтверждением создания набора указанных переменных ShowContextMenu. Показать контекстное меню, соответствующее его описанию В порождённом классе RGPlatform::Widgets::MainWindow имеется ряд методов, обеспечивающих работу приложения с элементами управления, порождёнными от базовых классов библиотеки Qt (QWidget, QIcon и т.д.). Соответственно, модули, использующие данный класс, должны использовать модуль ИИПП RGPWidgets, а также саму библиотеку Qt.

Вот некоторые из методов этого класса:

GetWidget. Получить главное окно системы в виде объекта класса QWidget. В случае, если данный метод возвращает ненулевой указатель, с ним можно работать как с объектом данного класса – показывать, гасить, изменять размер, название окна и т.д.

GetClientRectangle. Получить размер клиентской области главного окна.

AddDockingWindow. Добавить плавающее/докируемое окно приложения в состав вспомогательных окон главного окна GetObjectIcon. Получить иконку объекта. Метод возвращает объект типа QIcon, соответствующий объекту модели. Главное окно при этом отвечает за эффективную работу с изображением (кэширование иконок) для обеспечения высокой производительности при работе с изображениями GetIconByName. Получить иконку по её идентификатору.

GetSelectionBrowser. Получить интерфейс по работе с окном, обеспечивающим работу с динамическим списком объектов под курсором.

GetToolAction. Получить объект пользовательского интерфейса, соответствующий описанию этого объекта. Данный метод реализует физическую реализацию формального механизма описания элементов управления пользовательского интерфейса, используемого платформой.

GetDocumentWidgets. Получить полный список окон документов для итерации в виде объектов класса QWidget.

CloseDocument. Закрыть все окна указанного документа.

Управление вспомогательными окнами Интерфейс главного окна ИИПП обеспечивает для приложений возможность управления вспомогательными окнами. Такие окна могут быть плавающими поверх главного окна или размещаться по его периметру. Для этого приложение должно использовать класс QWidget в качестве базового класса такого объекта, и использовать метод AddDockingWindow класса RGPlatform::Widgets::MainWindow для добавления такого окна.

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

Управление прикладными окнами документа Интерфейс главного окна ИИПП позволяет приложениям создавать собственные окна документа, встраиваемые в общий оконный интерфейс главного окна. Главное окно предполагает многооконный многодокументный интерфейс (MDI). Соответственно, окна приложений встраиваются в общую инфраструктуру используемого механизма MDI.

С целью обеспечения функций по созданию окон документа, реализованных в модуле ИПО, в составе классов оболочки пользовательского интерфейса имеется класс RGPlatform::Widgets::WidgetsCreator. Он реализует возможность регистрации классов приложений ИПО, обеспечивающих как управление прикладными окнами документа, так и возможность использования специализированных элементов управления в составе диалоговых окон. Для регистрации классов, реализованных в ИПО, он имеет метод RegisterWidgetClass. Метод обеспечивает регистрацию объекта, порождённого от класса WidgetsCreator для указанного имени класса окна.

Класс приложения обеспечивает создание окна, соответствующего зарегистрированному имени класса по запросу пользователя или при чтении файла модели с сохранённой информацией об активном окне документа.

Класс WidgetsCreator имеет набор виртуальных методов, которые должен переопределить соответствующий класс приложения:

Create. Данный метод вызывается платформой для создания окна указанного класса. При вызове данного метода приложение должно создать окно, порождённое от QWidget, и вернуть его платформе. Данное окно будет размещено в качестве одного из MDI окон документа, либо панели в случае использования разделения рабочего окна на панели.

Release. Вызывается при завершении использовании объекта класса WidgetsCreator. В базовой реализации удаляет объект.

GetTitle. Возвращает название класса окна, которое будет создано при указании имени класса. К примеру, данное название будет выводиться в списке доступных типов окон при использовании команды «Заменить панель» или «Создать окно».

GetIconName. Возвращает идентификатор иконки, которая будет использоваться совместно с названием класса окна.

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

Пример кода, создающего окно документа с поведением, определённом в приложении:

// Класс окна документа приложения class SampleAppView : public QWidget, public RGPlatform::Model::View { Q_OBJECT

public:

SampleAppView(RGPlatform::Model::DocumentPtr iDocument,QWidget* iParent);

: QWidget(iParent), RGPlatform::Model::View(iDocument) { } ~SampleAppView() { } // В классе должен быть переопределён метод GetType для идентификации класса окна virtual std::string GetType() const override { return "SampleAppView"; } // Для примера перекрываем метод перерисовки окна virtual void paintEvent(QPaintEvent *event) override;

{ QPainter p(this);

–  –  –

// Инициализация приложения RGP_APP bool InitApplication(RGPlatform::Model::ApplicationInitContext* context) { context-GetApplcation()-SetID("SampleWidgetsPlugin");

context-GetApplcation()-SetDescription(L"Пример по созданию окна приложения");

–  –  –

// Тип окна, выводимый в списке типов virtual QString GetTitle(std::string classname) override { return QString::fromStdWString(L"Пример окна документа"); } // Можно установить свою иконку типа окна. В данном случае пустая virtual QString GetIconName(std::string classname) override { return QString::fromStdWString(L"MyIcon"); }

–  –  –

// Регистрируем фабрику окон Widgets::WidgetCreator::RegisterWidgetClass("SampleAppView", &widgetCreator);

return true;

} После выполнения данного кода, окно с типом «Пример окна документа» появится в списке типов окон, доступных для создания для нового окна документа.

Диалоговые окна ИИПП имеет в своём составе механизм описания элементов пользовательского интерфейса, реализуемых в виде диалоговых окон. Это могут быть как различные модальные диалоги, так и диалоговые окна, используемые в сценариях выполнения команд. Данный механизм является двухуровневым.

Со стороны приложения ИПО описывается состав диалогового окна при помощи объекта класса RGPlatform::UI::ControlLayout. Данный класс содержит общее описание диалоговой формы. Основными элементами описания являются объекты-элементы управления. Классы этих объектов порождены от базового класса RGPlatform::UI::Control. Этот класс содержит данные описания элемента управления, входящего в состав диалоговой формы, а также методы управления этими данными.

Со стороны конечной программы реализуются классы, обеспечивающие физическую реализацию элементов управления и диалоговых форм на основе их формального описания. Для этого в платформе предусмотрены интерфейсы RGPlatform::UI:: IControlLayoutPresentation для диалоговых форм, и RGPlatform::UI::IControlPresentation для элементов управления этих диалоговых форм.

Такая двухуровневая схема позволяет приложениям ИПО не заботиться о конкретном методе реализации элементов управления при реализации пользовательского интерфейса команд создания и редактирования объектов модели и отдельных окон диалога. Приложения получают достаточно функциональные элементы пользовательского интерфейса, использующие на базовом уровне стандартизованные протоколы взаимодействия с классами ИИПП. Интерфейс при этом получается унифицированным и единообразным, что является объективным требованием при создании интегрированных систем класса CAD/CAE/CAM.

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

В общем случае модули, реализующие пользовательский интерфейс конкретных приложений ИПО вообще не имеют информации о способе реализации элементов управления пользовательского интерфейса. В случае приложения RGPDemo, элементы интерфейса реализуются при помощи библиотеки Qt. Однако, другое приложение, может использовать и другие средства реализации элементов управления, переопределив соответствующие методы программных интерфейсов RGPlatform::UI::IControlLayoutPresentation и RGPlatform::UI::IControlPresentation. Через эти интерфейсы происходит взаимодействие физических элементов управления с объектами формального описания.

С целью реализации метода создания диалогового окна на основе формального описания, в базовом классе главного окна приложения (RGPlatform::UI::MainWindow) объявлен виртуальный метод CreateControlLayout, который должен быть переопределён в классе главного окна приложения, реализуемом в конкретной программе.

Перечень основных методов класса RGPlatform::UI::ControlLayout, реализующего управление диалоговой формой:

Create. Создать физическую реализацию диалога через механизм регистрации создания диалоговой формы в классе главного окна. В случае отсутствия такого зарегистрированного объекта, возвращает ошибку создания.

AddControl. Добавить элемент управления в список элементов управления диалоговой формы AddOption. Добавить элемент управления в панель опций (стандартно – набор кнопок в верхней части диалоговой формы) AddOptionSeparator. Добавить разделитель в панель опций Show. Показать диалоговую форму в немодальном режиме ShowModal. Показать диалоговую форму в модальном режиме Hide. Погасить окно диалоговой формы Destroy. Удалить физическую реализацию диалога SetTitle. Установить заголовок диалоговой формы GetControlCount. Получить число элементов управления формы GetControl. Получить элемент управления по индексу GetOptionCount. Получить число элементов управления панели опций GetOption. Получить элемент управления панели опций ClearControls. Очистить список элементов управления ClearOptions.

Очистить список опций Список функций, доступных для подписки в приложении, с целью обработки событий диалоговой формы:

OnKeyPressedEvent. Обработчик события нажатия клавиши в диалоге OnCancelPressedEvent. Обработчик события нажатия клавиши Cancel OnCloseEvent. Обработчик события закрытия диалога В таблице приведён список классов описания элементов управления, реализованных в платформе.

–  –  –

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

В базовом классе элемента управления реализованы методы, обеспечивающие общую функциональность элементов управления:

GetID. Получить уникальный идентификатор элемента управления. Идентификатор задаётся в конструкторе элемента управления, и должен быть уникальным в пределах диалоговой формы.

GetControlType. Получить тип элемента управления в виде перечислителя.

SetActive. Сделать элемент управления активным в составе диалоговой SetTitle. Установить строку названия элемента управления. Строка названия выводится слева или сверху от элемента управления GetTitle. Получить строку названия SetTitleOnTop. Установить вывод строки названия над элементом управления.

IsTitleOnTop. Получить опцию вывода строки названия над элементом управления SetPresentation. Установить ссылку на физическое представления элемента управления. Данный метод вызывается приложением, реализующим работу оконной системы GetPresentation. Получить ссылку на физическое представление элемента управления SetDocument. Установить документ, в контексте которого инициализируется данный элемент управления.

GetDocument. Получить текущий документ SetEnabled. Установить статус доступности элемента управления IsEnabled. Получить статус доступности элемента управления SetFocus. Установить фокус ввода на данный элемент управления SetPlaceholderText. Установить замещающий текст, выводимый в случае если значение элемента управления не задано. Используется в качестве подсказки при использовании элементов управления для задания связи с объектами модели.

GetPlaceolderText. Получить замещающий текст SetReadOnly. Установить режим «только чтение»

IsReadOnly. Получить режим «только чтение»

SetHidden. Используется для скрытия или показа элемента управления IsHidden. Получить состояние «скрытый»

Использование диалоговых окон в командах Обычно диалоговые окна являются неотъемлемой частью интерфейса команд, выполняющих здание и редактирование элементов модели. В таком случае объект команды и объекты, реализующие логику управления элементами диалоговой формы, должны управляться как единое целое. Для решения данной задачи удобно объявлять элементы описания диалоговых форм непосредственно в классе команды. Там же рекомендуется объявлять методы, обрабатывающие сообщения от элементов диалога. Такая схема позволяет удобно обрабатывать все события пользовательского интерфейса – как события, приходящие от рабочего окна, так и события от диалоговой формы, имея все необходимые объекты и обработчики в одном классе.

Пример объявления класса команды вместе с элементами управления диалога:

class MyCommand : public RGPlatform::UI::Command {

public:

MyCommand();

~MyCommand();

// Инициализация команды void Init(RGPlatform::Model::View* iView);

// Начало выполнения команды virtual bool Start (RGPlatform::UI::StartCommandParameters& iParameters) override;

// Завершение выполнения команды virtual void Finish () override;

// Уникальный идентификатор команды virtual std::string GetID () override { return "MyCommand"; } // Указатель на диалоговую форму команды virtual RGPlatform::UI::ControlLayout* GetDialog() { return &_dialog; }

private:

// Инициализация диалога void InitDialog ();

// Обработчик события закрытия диалога bool OnCloseDialog ();

// Обработчик нажатия на кнопку подтверждения void OnOK (RGPlatform::UI::ButtonControl& iControl);

// Обработчик нажатия на кнопку отмены void OnCancel (RGPlatform::UI::ButtonControl& iControl);

// Обработчик события изменения _cxEdit void OnXChanged (RGPlatform::UI::EditControl& iControl);

// Обработчик события изменения _cyEdit void OnYChanged (RGPlatform::UI::EditControl& iControl);

private:

// Описание диалоговой формы RGPlatform::UI::ControlLayout _dialog;

// Элемент управления, отвечающий за задание координаты X RGPlatform::UI::EditControl _xEdit;

// Элемент управления, отвечающий за задание координаты Y RGPlatform::UI::EditControl _yEdit;

};

Код реализации класса команды:

MyCommand::MyCommand () :

_xEdit ("X", L"Координата X", true, true), _cyEdit ("Y", L"CenterY", true, true) { // Добавляем обработчик события закрытия окна диалога _dialog.OnCloseEvent = std::bind (&MyCommand::OnCloseDialog, this);

// Добавляем обработчик события нажатия на кнопку подтверждения _ok.PressEvent = std::bind (&MyCommand::OnOK, this, std::placeholders::_1);

// Добавляем обработчик события нажатия на кнопку отмены _cancel.PressEvent = std::bind (&MyCommand::OnCancel, this, std::placeholders::_1);

// Добавляем обработчики событий изменения элементов управления диалога _xEdit.TextEditedEvent = std::bind (&MyCommand::OnXChanged, this, std::placeholders::_1);

_cyEdit.TextEditedEvent = std::bind (&MyCommand::OnYChanged, this, std::placeholders::_1);

} void MyCommand::Init (RGPlatform::Model::View* iView) { _dialog.SetTitle (L"Мой объект"));

// Добавляем кнопки подтверждения и отмены _dialog.AddOption (_ok);

_dialog.AddOption (_cancel);

// Добавляем элементы управления в диалог _dialog.AddControl (_xEdit);

_dialog.AddControl (_yEdit);

Command::Init (iView);

// Устанавливаем текущее окно SetView (iView);

// Делаем активной кнопку подтверждения _ok.SetEnabled (true);

} bool MyCommand::Start (RGPlatform::UI::StartCommandParameters& iParameters) { // Инициализируем данную команду Init (iParameters.GetView ());

// Вызываем метод Start базового класса if (!Command::Start (iParameters)) return false;

_xEdit.SetParameter(0.);

_yEdit.SetParameter(0.);

return true;

} void MyCommand::Finish () { // Закрываем окно диалога _dialog.Destroy ();

// Очищаем описание элементов управления диалога _dialog.ClearControls();

_dialog.ClearOptions();

Command::Finish ();

} void MyCommand::OnOK (RGPlatform::UI::ButtonControl& iControl) { … // Выходим из команды Terminate ();

} void MyCommand::OnCancel (RGPlatform::UI::ButtonControl& iControl) { // Выходим из команды Terminate ();

} bool MyCommand::OnCloseDialog () { // Выходим из команды Terminate ();

return false;

} void MyCommand::OnXChanged (RGPlatform::UI::EditControl& iControl) { auto parameterX = _xEdit.GetParameter ();

… } void MyCommand::OnYChanged (RGPlatform::UI::EditControl& iControl) { auto parameterY = _xEdit.GetParameter ();



Похожие работы:

«Руководство по эксплуатации Электродный паровой увлажнитель воздуха CL.RUCL.RU Несколько слов о качестве воды Принцип действия всех электродных паровых увлажнителей воздуха основан на том, что в воде содержатся минералы, и поэтому она обладает электрической проводимостью. • "Нормальная" водопрово...»

«ОПИСАНИЕ ФУНКЦИОНАЛЬНОСТИ РЕШЕНИЯ "ЛОГИКА СЭД"НА ПЛАТФОРМЕ IBM NOTES/DOMINO Кирилл Соколов Руководитель отдела Москва, сентябрь 2014 СОДЕРЖАНИЕ 1. Когда хаос превращается в порядок 2. Для кого предназначена система "Логик...»

«http://vendgu.ru Модуль телеметрии для торговых автоматов EW-GSMTM3-LITE Инструкция по эксплуатации ПО версия 3.0 Благодарим Вас за приобретения оборудования компании "ЭмВай"! Мы постоянно работаем над усовершенствованием наших изделий, и всегда готовы ответить на вопросы, не изложенны...»

«Правила Программы лояльности "МТБанк-Корона" утверждены протоколом Правления ЗАО МТБанк" 20.07.2016 №39 новая редакция утверждена протоколом Правления ЗАО МТБанк" 26.10.2016 №66 Настоящ...»

«Слайд 1. Требования ФГОС как основа проектирования информационно-образовательной среды. 2 слайд: определение ИОС В соответствии с требованиями Федеральных государственных образовательных стандартов...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования "Нижневартовский государственный университет" Гуманитарный факультет Рабочая программа дисциплины ФТД1. Этические аспекты документационного обесп...»

«ЧТЕНИЯ ПАМЯТИ АЛЕКСЕЯ ИВАНОВИЧА КУРЕНЦОВА A.I. Kurentsov's Annual Memorial Meetings _ 2015 вып. XXVI УДК 595.762.12: 591.55 (571.642) НАСЕЛЕНИЕ ЖУЖЕЛИЦ (COLEOPTERA: CARABIDAE) ДОЛИНЫ РЕКИ ЛЮТОГА, ЮЖНЫЙ САХАЛИН А.В. Вертянкин Дальневосточное отделение РЭО, г. Южно-Сахалинск E-mail: neover...»

«SHO-ME Combo Slim РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ Благодарим Вас за приобретение SHO-ME Combo Slim – радар-детектора и видеорегистратора, скомбинированных в одно устройство. Главными особенностями SHO-ME Combo Slim является уникальная патч-антенна, которая по качеству прием...»

«"УТВЕРЖДАЮ" Заместитель Министра образования и науки РФ _ Каганов В.Ш. "СОГЛАСОВАНО" Генеральный директор ФДЦ "Смена" _ Нижник Е.А. "УТВЕРЖДАЮ" Руководитель проекта "Карта добра" в РФ Актуганов А.Н. ПОЛОЖЕНИЕ о Всероссийском конкурсе, реализуемом на Федеральном портале координации и учёта добровольческих усилий, а также активизации студентов и школ...»

«Правила оформления электронного варианта На первой странице – титульном листе – указываются название учреждения, 1. выпускающего брошюру (надзаглавие), автор, наименование (прописными буквами), город и год издания – по центру без красной строки.Вторая страница содержит следующую информац...»

«РЕСПУБЛИКА САХА (ЯКУТИЯ) САХА РЕСПУБЛИКА ГОРОДСКОГО ПОСЕЛЕНИЯ НЕРЮНГРИ ОРОЙУОНУНААЫ "ГОРОД НЕРЮНГРИ" "НЕРЮНГРИ КУОРАТ" НЕРЮНГРИНСКОГО РАЙОНА КУОРАТТААЫ ПОСЕЛЕНИЕ ГЛАВА ГОРОДА КУОРАТ БАhЫЛЫГА ПОСТАНОВЛЕНИЕ УУРААХ № 30 от "08"_07_20_09_г. О проведении реструктуризации задолженности населения за жилищно-коммунальн...»

«СЕВАСТОПОЛЬ 1942 Триумф фон Манштейна СОДЕРЖАНИЕ НАЧАЛО КАМПАНИИ 5 Начало осады, 30 октября-9 ноября 1941. Германский штурм 10-21 ноября 1941. Германский штурм 17 декабря 1941 ХРОНОЛОГИЯ 14 ПЛАНЫ ПРОТИВОБОРСТВУЮЩИХ СТОРОН 16 Германские планы. Советские планы ПРОТИВОСТОЯЩИЕ ЛИДЕРЫ 19 Германия. Р...»

«Сеть ОЭСР по борьбе с коррупцией в странах Восточной Европы и Центральной Азии Предотвращение коррупции в государственном секторе стран Восточной Европы и Центральной Азии ...»

«1 Цели освоения дисциплины Целями освоения дисциплины являются: достижения конструктивной подготовки студента в области нефтегазопромыслового оборудования;соблюдение связи с дисциплинами специальностями и непрерывность в использовании ЭВМ в учебном процессе;...»

«И.Б. Андиш Интенсификация эмоциональной и рациональной оценки Настоящее сообщение посвящено описанию некоторых результатов изучения семантики одного из разрядов интенсифицирующих лексических единиц – английских адвербиалов. В списке семантических ролей адвербиалов, насчитывающем 7 групп, Рэндолф Кверк и его соавто...»

«ПРОТОКОЛ, ДОПОЛНЯЮЩИЙ КОНВЕНЦИЮ О БОРЬБЕ С НЕЗАКОННЫМ ЗАХВАТОМ ВОЗДУШНЫХ СУДОВ ГОСУДАРСТВА – УЧАСТНИКИ НАСТОЯЩЕГО ПРОТОКОЛА, БУДУЧИ ГЛУБОКО ОБЕСПОКОЕННЫМИ эскалацией во всем мире актов незаконного вмешательства в деятельность гражданской авиации, ПРИЗНАВАЯ, что новые виды угроз против гражданской авиации тр...»

«2 I зона г. Новороссийск II зона г. Армавир III зона г. Белореченск г. Новороссийск г.Армавир Апшеронский район г-к.Анапа Гулькевичский район Белореченский район Темрюкский район Отрадненский район г.Горячий Ключ Крымский район Успенский район г-к.Сочи Абин...»

«Курс: Байесовские методы машинного обучения, 2011 Методы Монте Карло по схеме марковских цепей (Markov Chain Monte Carlo, MCMC) Дата: 19 ноября 2011 Методы Монте Карло в байесовском подходе Рассмотрим вероятностное распределение p(T ). Методы Монте Карло (методы статистических испыта...»

«УТВЕРЖДЕН приказом Министерства образования Республики Коми от "21" декабря 2015 г. № 887 СОСТАВ Государственной экзаменационной комиссии Республики Коми по организации и проведению государственной итоговой ат...»

«Информационный бюллетень Услуги по Cisco Connected Stadium Wi-Fi Повышение уровня обслуживания пользователей мобильных устройств на стадионах с помощью услуг по Cisco Connected Stadium Wi-Fi Обзор Решение Cisco Connected Stadium Wi-Fi разработано для решения проблемы перегрузк...»

«Система ротации БУРР-1, БИС-1 Руководство по монтажу и эксплуатации. Блок Управления Ротацией и Резервированием (БУРР-1) и Блок Исполнительный Специализированный (БИС-1) являются компонентами единой микропроцессорной Системы Ротации и Резервирования к...»

«УТВЕРЖДЕН ДУБН.50002-02 34 01-ЛУ Программное обеспечение "СмартИнтегратор" Руководство оператора ДУБН.50002-02 34 01 Листов 122 Литера ДУБН.50002-02 34 01 АННОТАЦИЯ Настоящий документ является руководством оператора и содержит основные...»

«Серия PT-7728/7828: руководство по установке Коммутатор PowerTrans Серия PT-7728/7828 Руководство по установке Первое издание, Февраль 2008 Комплект поставки Коммутатор MOXA PowerTrans имеет следующий комплект поставки. Если какой-либо из этих элементов отсутствует и...»










 
2017 www.lib.knigi-x.ru - «Бесплатная электронная библиотека - электронные материалы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.