4.3.5. Использование стандартных инструментальных средств поддержания открытой архитектуры

По оценкам специалистов, создание продвинутой системы ЧПУ на базе одного компьютера занимает порядка двухсот человеко-лет. Возникают проблемы методики создания системы PCNC на стадиях проектирования, отладки и внедрения, поддержки проекта релизами, сопровождения эво­люции проекта. Для построения открытой архитектуры объединяют стан­дартные инструментальные средства.

Опыт показал, что интеграция инструментальных средств возможна на основе технологии Microsoft-OLE-Automation. В качестве базы был исполь­зован Visual С++, который входит в состав наиболее мощного пакета средств разработки программного обеспечения под Windows-MSDN (Microsoft Developer Network) [77]. Организации, выпускающие инструментальное программное обеспечение, встраивают свои системы в MSDN, используя такие готовые компоненты пакета разработки, как текстовый редактор, си­стема поддержки проекта Source Safe и т.д.

На рис. 127 показан проект системы PCNC в среде Visual С++, где каж­дый модуль оформлен в виде подпроекта. Подпроекты состоят в некото­рой зависимости друг от друга, которая определяет очередность компиля­ции. Суть в том, что во время компиляции модуль PCNC должен уже иметь те скомпилированные модули, от которых он зависит.

С уществует и основной проект (Master Project), компиляция которого обеспечивает перекомпиляцию всех остальных модулей. На рис. 128 в ка­честве примера приведена схема зависимости модулей объектно-ориенти­рованной магистрали (ООС, object oriented channel), которая показана стрел­

ками. Каждый модуль проекта оформлен в виде динамической библиоте­ки и имеет свое назначение:

• модуль, независимый от конкретной реализации системы PCNC (IndNcsCl);

• модуль работы с файловыми потоками (NcsStdio);

• галерея управляющих элементов (Ctrl Gall);

• галерея элементов визуализации (ViewGall);

• базовый модуль (BasNcsCL), в котором осуществляется открытие-закрытие объектно-ориентированной магистрали, а также ее начальная ини­циализация;

• коммуникационный модуль (ComNcsCL) геометрического канала;

• модуль языка УП высокого уровня (CplNcsCL);

• модуль диагностики программируемого контроллера (DgnNcsCL);

• модуль работы с сообщениями (WeaNcsCL);

• модуль диагностики следящих приводов по типу осциллографа (OscNcsCL);

• модуль прикладного уровня (AppNcsCL), поддерживающий реали­зацию приложений, взаимодействующих через объектно-ориентированный канал, и т.д.

Visual С++ обладает мощным механизмом настройки средств разра­ботки, утилитами, обслуживающими проект, и механизмами встраива­ния внешних приложений. Системы поддержки проекта Source Safe и проектирования Rational Rose встраиваются в Visual С++ как внешние

приложения. Определим функции перечисленных систем и общую схе­му интеграции.

В проект создания системы PCNC вовлечены десятки человек, в него постоянно вносятся изменения и коррекции. Конечные пользователи сис­темы нуждаются в поддержке релизов и обновлении версий, что опреде­ляет направление развития проекта. Поэтому проект нельзя начинать без системы поддержки проекта Source Safe (Microsoft). Как компонент MSDN она наилучшим образом интегрируется с Visual С++ и реализует про­стую концепцию работы с исходными кодами: в любой момент времени файл доступен для изменения только одному разработчику с помощью функций CheckOut и Checkln. Во время работы с файлом другие разра­ботчики, как правило, пользуются его копией. Пример проекта системы PCNC приведен на рис. 129. Использование Source Safe предполагает выделение администратора, который распределял бы права пользовате­лей, маркировал релизы и архивировал версии, отслеживал корректность базы данных.

А рхитектор проекта не в состоянии отследить взаимосвязь между ис­пользуемыми классами и довести до программиста детали их реализации. Проблемы подобного рода решаются с помощью систем CASE. Одной из наиболее удачных среди них является Rational Rose [78]. Система позволя­ет вести итеративное проектирование, осуществлять генерацию каркаса исходного кода, а также предусматривает интеграцию с Visual С++ и ис­пользование Source Safe.

Rational Rose поддерживает практически все распространенные нота­ции представления моделей, в том числе и UML (Unified Modeling Language) [71]. Фрагмент диаграммы классов в нотации Booch для модуля интерпре­татора системы PCNC, разработанного в Rational Rose, представлен на рис. 130. Прикладные компоненты описываются системой Rational Rose с по­мощью четырех представлений объектно-ориентированного подхода [70] (рис. 131). Логическое представление задает ключевые абстракции и ме­ханизмы, формирующие предметную область и архитектуру системы PCNC. Физическое представление определяет конкретную программно-аппаратную платформу. Все это описывается диаграммами классов, объек­тов, модулей, процессов.

Е сли рассматривать систему со стороны статики-динамики, то здесь интерес представляют диа1рамма переходов из одного состояния в другое и диаграмма взаимодействия и обмена сообщениями, определяющая по­рядок их передачи.

4 .3.6. Использование оригинальных инструментальных средств поддержания открытой архитектуры системы ЧПУ

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

Создание скелета модуля системы PCNC с помощью мастера при­ложения NcsAppWizard. В общем случае AppWizard представляет собой средство создания и конфигурирования нового проекта в среде Microsoft Visual С++. NCsAppWizard, в частности определяет в интерактивной фор­ме свойства и функциональные возможности будущего модуля системы PCNC. Скелет модуля создается на базе классов коммуникационной сре­ды, при этом осуществляется генерация большей части необходимых про­граммных кодов. Сведения о создаваемом приложении запрашиваются в диалоге с пользователем, а в результате генерируется исходный код. Та­ким образом, разработчик избавляется от одной из самых трудоемких ра­бот по созданию скелета нового приложения.

Установка NcsAppWizard в систему разработки состоит в копировании файла с расширением «.AWX» в директорию Template Microsoft Visual С++. После этого NcsApp Wizard становится доступным в качестве одного из ма­стеров создания приложений. Создание нового приложения при помощи NcsAppWizard представляет собой обработку последовательно сменяющихся диалогов. На первом шаге вводят информацию о типе приложения и целесо­образности генерации примера. На втором шаге осуществляют ввод расши­ренных свойств приложения (например, для генерации обработчиков исклю­чений), а также информацию для начального конфигурирования тулбара (ко­личество кнопок и их расположение). На третьем шаге определяют стиль и обозначают права на приложения. Четвертый шаг задает размеры главного окна (при его наличии), возможности изменения размеров, автоматического центрирования и коррекции размеров окна при изменении разрешения эк­рана. Далее настраивают статусбар, параметры подключения к коммуника­ционной среде и т.д. В заключительном диалоге описывают те параметры проекта в текстовом виде, которые будут сгенерированы. В случае необхо­димости можно вернуться к предыдущим шагам и внести исправления.

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

Создание скелета машины состояния с помощью State Machine Builder. Под машиной состояния в системе управления понимают конеч­ный автомат, реагирующий на управляющие воздействия и инициирую­щий необходимые действия [79]. Управляющими могут быть действия со стороны оператора (нажатие кнопки), события (например, поступление сигнала отдатчика), возникновение ошибки. В результате управляющего воздействия машина состояния переходит в новое состояние, при этом вы­полняются функции, предусмотренные при переходе. Машину состояния описывают с помощью графа. Графы были использованы при разработке State Machine Builder (генератора машины состояния) - визуального инст­рументария разработки машины состояния. При этом были предложены новые понятия. Сложное состояние - логически обособленный фрагмент графа с иерархическими вложениями. Порты входа и выхода из сложного состояния - узлы, определяющие связь уровней сложного состояния. Эти понятия лежат в основе иерархических графовых структур, причем в вер­шине иерархии находится единственное сложное состояние. На каждой следующей ступени иерархии сложные состояния раскрываются в виде совокупности простых и сложных состояний.

Инструмент State Machine Builder позволяет не только визуально пред­ставить машину состояния в виде иерархического графа, но и задать име­на классов, реализующих состояния и переходы, а также определить фай­лы их расположения. В результате инструментарий генерирует С++ код для машины состояния и встраивает его в Visual С++ проект системы PCNC. Инструментарий маркирует в генерируемом коде защищенные секции, в которых программисты реализуют функциональные наполнения переходов.