Статьи → AutomatiCS 2011 3.2 → Реализация распределенного проектирования в САПР AutomatiCS на базе технологии XML

Для современных технологий САПР характерны две магистральные тенденции. Первая — обеспечение сквозной автоматизации проектирования изделия, охватывающей все этапы его жизненного цикла: от возникновения потребности в нем до утилизации. Эта тенденция направлена на решение проблемы повышения качества проектных решений за счет интегрированного представления концептуальной информации об изделии. В САПР AutomatiCS, ориентированной на проектирование технической структуры систем управления тепловых электростанций, эта тенденция реализована единой моделью проекта, которая представляет собой иерархическое описание процесса проектирования. Вторая тенденция — к распределенной реализации проектных процедур — отражает специфику организации команды субъектов проектирования, которая зачастую является виртуальной в том смысле, что ее участники, объединенные общей задачей в рамках единой модели проекта, организационно и территориально разобщены. На пересечении этих двух тенденций возникает естественная проблема управления сотрудничеством (Collaboration Management, CM), которая заключается в организации удаленного доступа к разделяемой концептуальной информации на ролевой основе. Решение здесь осложняется тем, что САПР AutomatiCS, как и большинство систем такого класса, поддерживает уникальный формат единой модели проекта, оптимизированный для хранения и локальной обработки и не предназначенный для исполнения удаленных запросов по сети.

Излагаемый ниже подход к решению этой проблемы основан на использовании технологии XML. Ядром XML-технологий является расширяемый язык разметки (eXtensible Markup Language), претендующий на статус фактического стандарта обмена в Web (сейчас таким статусом обладает HTML). В отличие от своего предшественника XML позволяет определять структуру и семантику документа в терминах собственных элементов разметки. Технология XML опирается на платформо-независимые мировые стандарты представления и обмена информации в Web и обладает рядом существенных преимуществ, среди которых следует выделить неограниченные возможности специализации (обусловленные тем, что XML — это технология описания структуры произвольных документов), а также наличие непроцедурных средств построения запросов к этим документам.

Эти уникальные возможности XML-технологии позволили использовать расширяемый язык разметки для спецификации протокола обмена фрагментами виртуального XML-документа «Единая модель проекта» AutomatiCS (участники проекта извлекают эти фрагменты по запросу в соответствии с определенными для каждого из них правами доступа). В качестве средства построения запросов использован язык XPath, который является предпочтительным стандартом формирования XML-запросов. Его синтаксис, предполагающий иерархическую адресацию элементов документа и их фильтрацию при помощи предикатных выражений, позволяет выделить произвольный фрагмент иерархической структуры проекта. Например, запрос

ProjectElementsEl[@Name="Bтopuчный-Пpuбop" or ParentsParent=ProjectElementsEl[@Name= "Bтopuчный-Пpuбop"]@Number]

позволяет выбрать из проекта элемент «Bтopuчный-Пpuбop» и все его подчиненные элементы.

Запрос вида

ProjectElementsEl[@Name="Пuтaнue-Caпфupa" and TrebovaniaTr[@NamPar="Мощн" and @ZnPar="Equal" and @BelPar>"0.8"]]

выбирает из проекта те элементы «Пuтaнue-Caпфupa», в списке требований которых есть требование равенства мощности значению, большему 0,8.

На рисунке показана архитектура XML-сервера, обеспечивающего возможность однорангового обмена проектной информацией (B2B, Business to Business). Его компоненты — ядро, обеспечивающее лексико-синтаксический разбор строки поступившего от клиента запроса, интерпретацию запроса, его исполнение в контексте виртуального XML-документа «Единая модель проекта», формирование результирующего документа XML, разбор полученного документа и «перекачку» данных из него в объектную модель. Драйвер обеспечивает представление объектной модели в виде виртуального XML-документа, а также «девиртуализацию» на стороне клиента. Такое архитектурное решение является симметричным, то есть может быть реализовано на сервере и на клиенте, и открытым. Последнее означает, что так как специфика виртуального источника данных инкапсулирована его драйвером, взаимодействие с которым осуществляется по стандартному интерфейсу, для функционального масштабирования сервера, которое вызвано появлением нового источника, достаточно написания нового драйвера.