Норенков И.П. Основы автоматизированного проектирования

Подождите немного. Документ загружается.

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

Помимо упрощения написания пользовательского интерфейса,

средах

RAD

предусматриваются средства

для

реализации

ряда

других

функций. Так,

наиболее развитой версии Visual Basic

к ним

относятся средства выполнения

следующих функций:

•

поддержка ODBC,

что

дает

возможность работы

различными СУБД;

•

разработка

баз

данных;

•

разработка

трехзвенных

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

•

интерактивная отладка процедур

на SQL

Server;

•

управление версиями

при

групповой разработке

ПО;

•

моделирование

анализ сценариев распределенных вычислений.

Для

создания сред

RAD

случае

сетевого

программирования требуется

решить

ряд

дополнительных проблем, обусловленных

многоплатформенностью

гетерогенных

сетях, обилием применяемых форматов данных, необходимос-

тью

защиты информации

т. п.

Решение этих проблем достигнуто

объектно-

ориентированных технологиях

на

базе

языка

сетевого программирования Java.

Кроме

того,

помощью Java удается решить

еще

одну актуальную

для

Internet

Intranet задачу

сделать Web-страницы интерактивными.

Хотя

ранее были известны технологии

на

базе промежуточных

/7-кодов,

именно

технология Java оказалась наилучшим образом приспособленной

для

использования

гетерогенной сетевой среде.

Она

последовательно отражает

принципы

объектно-ориентированного программирования

обеспечивает при-

емлемую эффективность (производительность) исполнения программ.

Эту эф-

фективность можно

еще

более повысить, если

браузерах заменить интерпре-

тацию компиляцией.

Для

разработки

ПО на

языке Java создан

ряд

инструментальных средств.

Основной

средой является

JDK

(Java Developer's Kit).

В ней

имеются:

биб-

лиотеки классов,

в том

числе библиотеки элементов

языка,

часто используе-

мых

оболочек

(wrapper),

процедур ввода-вывода, компонентов оконного интер-

фейса

другие;

инструментальные средства, такие,

как

компилятор

байт-кодов,

интерпретатор,

просмотрщик

аплетов,

отладчик, формирователь

оконных

форм

т. п.

Развитую

RAD-среду

Power

предлагает фирма

Sybase.

Наряду

самостоятельными

RAD-системами

имеются

RAD-системы

составе

САПР.

Это

прежде

всего

упомянутая

выше

система

CAS.CADE

фирмы

Matra

Datavision.

Компонентно-ориентированные

технологии

Появление

компонентно-ориентированных технологий вызвано необходимо-

стью повышения эффективности разработки сложных программных систем,

являющихся

условиях использования корпоративных

глобальных вычисли-

тельных

сетей

распределенными системами. Компонентно-ориентированные

технологии основаны

на

использовании предварительно разработанных гото-

вых

программных компонентов.

Компиляция

программ

из

готовых компонентов

идея

не

новая.

Уже

пер-

вые

шаги

области автоматизации программирования были связаны

созда-

263

Методическое

программное обеспечение автоматизированных систем

нием

библиотек подпрограмм. Конечно,

для

объединения этих подпрограмм

конкретные

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

ной

части программного кода

на

языках

третьего

поколения. Упрощение

ускорение разработки прикладного

ПО

достигается

помощью языков чет-

вертого поколения

(4GL),

но

имеющиеся системы

на их

основе являются спе-

циализированными

и не

претендуют

на

взаимодействие

друг

другом.

Современные

системы

интеграции

ПО

построены

на

базе объектной мето-

дологии. Так, имеются библиотеки классов, применяя которые прикладные

программисты

могут

создавать субклассы

соответствии

возможностями

наследования, заложенными

используемые объектно-ориентированные язы-

ки

программирования.

При

этом

интероперабельность

компонентов

сетевых

технологиях достигается

помощью механизмов, подобных удаленному вызо-

ву

процедур

RPC.

библиотекам классов относятся MFC, библиотеки

для

доступа

реляционным базам данных (например,

для

встраивания

приклад-

ную

программу драйверов ODBC)

и др.

Преимущества использования

готовых

компонентов обусловлены тщатель-

ной

отработкой многократно применяемых компонентов,

их

соответствием стан-

дартам, выбором лучших

из

известных методов

алгоритмов.

В то же

время

компонентах библиотек классов спецификации интерфей-

сов

не

отделены

от

собственно кода, следовательно, использование библиотек

классов

не

профессиональными программистами проблематично. Именно

стремление устранить этот недостаток привело

появлению

CBD

компонен-

тно-ориентированных технологий разработки

ПО.

Составными частями таких

технологий являются

унифицированные

способы интеграции программного обес-

печения.

Возможны

два

способа включения компонентов (модулей)

прикладную

программу

модернизация

(reengineering)

или

инкапсуляция (encapsulation

или

wrapping).

Модернизация

требует

знания содержимого компонента, интероперабель-

ность достигается внесением изменений собственно

в сам

модуль.

Такой

спо-

соб

можно назвать способом «белого ящика». Очевидно,

что

модернизация

не

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

участие

профессио-

нального программиста.

Инкапсуляция

выполняется включением модуля

среду

помощью интер-

фейса

- его

внешнего окружения (оболочки

wrapper).

При

этом компонент

рассматривается

как

«черный

ящик»: спецификации, определяющие интерфейс,

выделены

из

модуля,

детали внутреннего содержимого скрыты

от

пользова-

теля. Обычно компоненты поставляются

готовом

для

использования виде

скомпилированного

двоичного кода. Обращения

модулю возможны только

через

его

интерфейс.

спецификации интерфейса включаются необходимые

для

интероперабельности сведения

характеристиках модуля

модульная

абстракция.

состав этих сведений могут входить описания всех входных

выходных

для

модуля данных

(в том

числе имеющихся

модуле

интерактив-

264

5.5.

Инструментальные

средства

концептуального

проектирования

ных

команд), структура командной строки

для

инициализации процедур, сведе-

ния

требуемых

ресурсах.

Компонентно-ориентированные системы построены

на

основе инкапсуля-

ции

компонентов.

архитектуре этих систем можно выделить следующие

ча-

сти:

прикладная программа (клиент), создаваемая

для

удовлетворения воз-

никшей

текущей потребности;

посредник (брокер

или

менеджер), служащий

для

установления связи между взаимодействующими компонентами

и для со-

гласования

их

интерфейсных данных;

множество компонентов, состоящих

каждый

из

программного модуля (объекта), реализующего некоторую полез-

ную

функцию,

оболочки (интерфейса).

спецификации интерфейса могут быть

указаны характеристики модуля, реализуемые методы

связанные

модулем

события (например, реакции

на

нажатие клавиш).

Собственно интерфейс представляет собой обращения

функциям модуля,

называемым

CBD-технологиях

методами.

Эти

обращения переводятся

двоичный код,

что

обеспечивает

при их

использовании независимость

от

язы-

ка

программирования. Один

и тот же

модуль может реализовывать несколько

разных функций,

поэтому

него

может

быть

несколько интерфейсов

или

мето-

дов. Каждый новый создаваемый интерфейс обеспечивает

доступ

новой функ-

ции

и не

отменяет прежние возможно

еще

используемые интерфейсы.

Схематично взаимодействие компонентов можно представить следующим

образом. Клиент обращается

запросом

на

выполнение некоторой процедуры.

Запрос

направляется

посреднику.

посреднике имеется предварительно сфор-

мированный каталог (реестр

или

репозиторий)

интерфейсов процедур

указа-

нием компонентов-исполнителей. Посредник перенаправляет запрос соответ-

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

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

При

этом пользователь оперирует удобными

для его

восприятия идентифи-

каторами

компонентов

интерфейсов,

а с

помощью каталога

эти

идентифика-

торы переводятся

указатели (ссылки), используемые аппаратно-программными

средствами,

которые однозначно определяют интерфейс

распределенной сети

из

многих компьютеров.

большинстве

случаев

реализуется синхронный режим

работы,

подразу-

мевающий приостановку процесса клиента после выдачи запроса

до

получения

ответа.

Наиболее популярными

настоящее время являются следующие CBD-тех-

нологии.

•

CORBA—технология,

основанная

на

спецификациях, разработанных спе-

циально созданным консорциумом OMG,

который вошли представители

ве-

дущих

компьютерных фирм.

CORBA

реализуются распределенные вычис-

ления

на

базе

программ-посредников ORB.

• COM

(Common Object Model)

технология, развиваемая корпорацией

Microsoft

на

базе механизма OLE. Сетевой вариант этой технологии (для сис-

тем

распределенных вычислений) известен

под

названием DCOM (Distributed

265

Методическое

программное обеспечение

автоматизированных

систем

СОМ). Объекты DCOM

(в

частности, объекты, которые можно вставлять

HTML-документы

или к

которым можно обращаться

из

Web-браузеров) изве-

стны

под

названием компонентов

ActiveX.

COM/DCOM,

как и в

CORBA,

можно

использовать компоненты, написанные

на

разных объектно-ориентиро-

ванных языках программирования.

Но в

отличие

от

CORBA

COM/DCOM

остается естественная

для

Microsoft

ориентация только

на

операционные сис-

темы Windows. Технология ActiveX (прежнее название

OLE

Automation) обес-

печивает интерфейс

для

управления объектами одного приложения

из

другого.

общем плане ActiveX

технология интеграции программного обеспечения

фирмы

Microsoft. Например, применяя

эту

технологию, можно

среде

VBA

организовать

доступ

объектам AutoCAD.

•

JavaBeans

сравнительно новая технология,

которой используются ком-

поненты, написанные

на

языке Java.

Рассмотрим подробнее основные CBD-технологии.

Организация связи клиента

серверными компонентами

и в

CORBA,

и в

DCOM

происходит

помощью разновидностей языка IDL. Язык

IDL в

CORBA

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

создаваемых

компонентов. Описание, назы-

ваемое метаданными, представляется

виде модуля, состоящего

из

заголов-

ка,

описаний типов данных, интерфейсов

операций.

заголовке указывается

идентификатор

модуля.

части типов данных перечисляются атрибуты, воз-

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

могут служить типы базовые (например,

float,

double, char, boolean,

struct),

кон-

струируемые пользователем (например, записи

массивы)

объектные ссыл-

ки,

указывающие

на

интерфейсы компонентов. Описание интерфейсов начина-

ется

ключевого слова interface,

за

которым следуют идентификаторы данного

интерфейса

и,

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

рации (методы)

виде идентификаторов операций

возможными перечисле-

ниями

параметров операций

указанием

их

принадлежности

входным

или

выходным данным.

Классы

объектов (программные модули) должны

быть

реализованы

CORBA-среде.

Для

этого компилятор

IDL

выполняет следующие действия.

Во-первых, метаданные

для

каждого класса объектов помещаются

специ-

альную базу данных, имеющуюся

ORB,

репозиторий

интерфейсов. Во-вто-

рых, компилятор создает

для

каждого определенного

на IDL

метода клиент-

ский

серверный

стабы

специальные программные модули, обеспечивающие

доступ

компонентам.

Основное назначение стабов

выполнение

маршалинга

организация пере-

дачи данных через сеть.

Маршалингом

называют упаковку параметров

стан-

дартный формат

для

пересылки. Маршалинг необходим

по той

причине,

что

представление данных

разных компьютерных средах может

быть

различ-

ным

(например, различия

кодировке символов,

изображении чисел

плава-

ющей запятой). Клиентский стаб будет использоваться

для

передачи вызовов

данных

от

клиента

сеть,

серверный стаб, называемый также скелетоном,

будет вызывать

метод

уже в

среде

сервера

возвращать результаты.

266

5.5. Инструментальные

средства

концептуального

проектирования

На

серверной стороне данные

каждом новом классе объектов, поддер-

живаемом конкретным сервером, заносятся

репозитарий

реализаций.

Эту

операцию выполняет объектный адаптер. Обычно

в ORB

имеется

несколько

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

можны объектные адаптеры, ориентированные

на

библиотеки,

на

базы дан-

ных,

на

группу

отдельных программ

и т.

п.).

Объектные адаптеры выполняют также

ряд

других функций, например,

таких,

как

интерпретация объектных ссылок, активация

дезактивация компо-

нентов, вызов

их

методов через скелетоны. Возможны разные способы акти-

вации

дезактивации компонентов.

первом

из них для

обслуживания каж-

дого

клиентского запроса создается своя

копия

компонента.

других

способах

копии

не

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

все

запросы

разделением

или

без

разделения

во

времени.

При

реализации запроса брокер через объектный адаптер активирует соот-

ветствующий

компонент. Далее взаимодействие клиент

сервер происходит

через

стабы.

Изложенную

схему

взаимодействия клиент

сервер называют статичес-

кой.

CORBA

предусмотрены также динамические вызовы.

Для их

осуще-

"ствления

не

требуется предварительного формирования стабов

помощью

компилятора

языка

IDL.

Вместо стабов, специфических

для

каждого вызыва-

емого метода,

CORBA

используются специальные программы динамичес-

кого

взаимодействия, инвариантные

вызываемым методам.

При

этом необ-

ходимые данные

для

обращения

компоненту должны быть представлены

клиентской

программе,

частности,

они

могут быть предварительно получены

из

репозитария

интерфейсов. Динамические вызовы обеспечивают большую

гибкость

при

программировании,

но

выполняются

они

значительно медленнее.

CORBA предусмотрен

ряд

унифицированных сервисов, работающих

под

управлением ORB.

частности,

это

сервисы:

•

именования

присваивает объектам уникальные имена,

результате

пользователь может искать объекты

сети

по

имени;

•

жизненного цикла

обеспечивает создание, перемещение, копирование

удаление

объектов (документов)

системе,

в том

числе составных объектов

вместе

со

всеми ссылками

ассоциированными объектами;

•

обработки транзакций

осуществляет управление транзакциями (блоки-

ровка,

фиксация

откат транзакций)

из

приложений

или из ОС, что

позволяет

многим

объектам

сети

использовать одни

и те же

серверы;

•

событий

обеспечивает асинхронное распространение

обработку сооб-

щений

событиях,

происшедших

при

реализации процессов,

что

позволяет

за-

интересованным объектам координировать свои действия;

•

обеспечения безопасности

поддерживает целостность данных.

технологии

COM/DCOM

все

объекты сгруппированы

классы

каждый

класс

имеет свой идентификатор CLSID,

каждый интерфейс

(метод)

класса

свой идентификатор.

Для

создания объекта (экземпляра класса) клиент

об-

ращается

серверу библиотеки

СОМ с

указанием

CLSID

идентификаторов

267

Методическое

программное

обеспечение

автоматизированных

систем

всех

требуемых

интерфейсов. Сервер библиотеки

СОМ

находит

таблице-

реестре

по

CLSID адрес удаленной машины,

на

которой размещен запрошен-

ный

компонент,

передает

ей

запрос клиента.

На

серверной стороне создается

объект

(копия компонента),

он

активируется

возвращает клиенту указатели-

ссылки

на

требуемые интерфейсы. Теперь клиент может многократно обра-

щаться

методам объекта, указывая

своих запросах имена интерфейса,

ме-

тодов

и их

параметров.

Обычно объект исполняется

на той

машине,

на

которой

размещен компонент,

но

можно выбрать

другую

машину, указав

запросе,

например,

ее

IP-адрес.

Появление

технологии

JavaBeans

обусловлено успехом

языка

программи-

рования

Java. Технологию JavaBeans отличают

от

COM/DCOM

две

особенно-

сти. Во-первых, Java

единственный

JavaBeans

язык

программирования.

Единственность

языка

притом объектно-ориентированного обусловливает

сравнительную легкость освоения

применения технологии JavaBeans. Во-вто-

рых,

технология

JavaBeans

является

платформенно-независимой.

Компоненты

JavaBeans являются классами Java.

Для их

создания, моди-

фикации

объединения

прикладные

программы

имеются

специальные

сред-

ства

составе инструментальной среды

JDK.

С их

помощью компоненты

JavaBeans

могут

быть встроены

Java-аплеты,

приложения

или

другие

более

крупные компоненты.

качестве

Java-аплетов

компоненты JavaBeans поддер-

живаются большинством имеющихся WWW-браузеров.

Развитие CBD-систем возможно

направлении дальнейшего упрощения

программирования

и,

следовательно, сокращения сроков разработки

ПО,

одна-

ко

это

происходит

за

счет

снижения степени универсальности соответствую-

щих

инструментальных

средств.

Такие более специализированные средства

представляют собой

группу

компонентов, взаимосвязанных некоторым зави-

сящим

от

приложения образом,

входят

системные среды

САПР.

общем

случае

компоненты системной среды объединены

несколько

сценариев (потоков процедур

или

маршрутов),

которых выделяются точки

входа

для

вставки специфичных пользовательских фрагментов

расширений.

Имеются возможности

не

только вставки новых фрагментов,

но и

замены

ис-

ходных компонентов

потоках процедур

на

оригинальные

сохранением

ин-

терфейса. Собственно многие системы, основанные

на

применении

языков

чет-

вертого поколения

(4GL),

относятся именно

таким системным средам,

которых

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

помо-

щью

операторов 4GL.

Пример

реализации

компонентно-ориентированной

технологии

САПР

Основные идеи компонентно-ориентированной (объектной) технологии

созданием расширенных специализированных библиотек компонентов реали-

зованы

системе CAS.CADE (Computer Aided Software

Computer Aided Design

Engineering) фирмы Matra Datavision.

268

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

Система

CAS.CADE

состоит

из

нескольких частей. Основными частями

являются

библиотеки классов

инструментальная среда

для

создания

ПО

технических

научных приложений.

Библиотеки (Object Libraries)

CAS.CADE представляют собой специали-

зированные наборы заранее разработанных компонентов

на

языке C++. Сово-

купность библиотек имеет иерархическую структуру. Базовые компоненты

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

яв-

ляются

строки, списки, точки, матрицы, линии, поверхности, деревья, решате-

ли

уравнений, операторы сортировки, поиска

на

графах

т. п.

Классы группиру-

ются

пакеты

(Packages),

пакеты

- в

наборы (Toolkits), наборы

- в

домены

(Resourse Domains).

CAS.CADE выделено несколько библиотек. Во-первых,

это

библиотеки

2D-

3£>-моделирования,

включающие компоненты

для

определения, создания

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

ряд

библиотек

предназначен

для

связи

с ОС и

управления данными,

для

обмена данными

внешними CAD-системами,

для

создания

сеточных

моделей

и др.

Так,

в со-

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

из

формата

CAS.CADE

Express-файл прикладного протокола

АР214

стандарта STEP

обратно. Аналогичные конверторы имеются

для

взаимного преобразования

данных

из

формата CAS.CADE

другие популярные

САПР форматы IGES

DXF/SAT.

Необходимо отметить,

что

основные приложения,

на

которые ориентирова-

на

CAS.CADE,

- это

приложения машинной графики

геометрического моде-

лирования,

поэтому

системе наиболее развиты библиотеки графических

геометрических компонентов.

Геометрическое моделирование

визуализация

CAS.CADE поддержива-

ются

соответствующим

ПО. В это ПО

входят библиотечные наборы

«Геомет-

рия»,

«Топология», «Визуализация»

и др. Для

тестирования

демонстрации ком-

понентов

перед

их

встраиванием

проектируемую

прикладную САПР

используются специальные

язык,

интерпретатор

просмотрщик,

составляю-

щие

подсистему «Тестирование».

Набор

«Геометрия»

содержит

пакеты

канонических

геометрических

элементов

массивов

(множеств)

этих

элементов.

Пакеты

gp,

geom2d

geom

включают

себя

ID-

З/Э-геометрические

элементы

(клас-

сы),

используемые

качестве

сущностей

вычислительных

процедурах,

в том

числе

таких

операциях,

как

поворот,

отражение,

масштабирование

и т. п.

Примерами

элемен-

тов

могут

служить

декартовы

координаты,

точки,

векторы,

линии,

окружности,

квадра-

тичные

кривые,

сферические,

тороидальные

конические

поверхности,

кривые

и по-

верхности

Безье,

В-сплайнов

и др.

Большое

число

пакетов

разработано

для

выполнения

геометрических

построений

метрических

расчетов.

Пакеты

gee,

GC,

GCE2d

включают

алгоритмы

построения

сущно-

стей

из

элементов

пакетов

gp,

Geom,

Geom2d,

например

построения

прямых,

дуг

окруж-

ностей,

кривых

по

заданным

параметрам,

таким,

как

инцидентные

точки,

центральные

точки

радиусы,

параллельные

или

нормальные

прямые

и т. п.

269

Методическое

программное

обеспечение

автоматизированных

систем

Набор «Топология» определяет структуры данных, описывающих связи (отношения)

между геометрическими сущностями

классами набора

«Геометрия».

структурам

топологических данных относятся вершины, ребра, линии

каркасных

моделей, участки

поверхности, оболочки

совокупности связанных

через

ребра участков поверхности,

тела

части пространства, ограниченные оболочкой, совокупности тел,

в том

числе

простые конструкции вида частей цилиндра, конуса, сферы,

тора.

наборе имеются

также

средства:

1) для

скругления

острых углов

кромок,

т. е.

формирования галтелей

постоянного

или

переменного радиуса;

2) для

поддержания непрерывности

при

сопря-

жении

разных поверхностей;

3) для

метрических расчетов

определения длин

ребер,

площадей участков поверхности, объемов тел, центров масс

моментов инерции.

подсистему «Тестирование» входят

командный

язык

TCL

(Test Command

Language),

на

котором задается программа тестирования

просмотра библиотечных компонентов,

интерпретатор

TCL и

21)/З.О-визуализатор.

TCL

имеются обычные

для

языков про-

граммирования команды, такие,

как

присвоение

значения

переменной, организация цик-

ла,

условный переход,

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

базовые,

геометрические

топологические команды. Примеры базовых команд: задержка

при

исполнении программы (например,

при

презентациях), обращение

файлу,

вывод

на

экран

координат

других

параметров геометрических объектов, создание

окон

для

раз-

личных видов, масштабирование изображения,

его

поворот, установка цвета, выделение

на

экране

одного заданного объекта

т. п. С

помощью геометрических команд выполня-

ют

создание

модификацию кривых, поверхностей,

геометрические

преобразования

типа поворота

или

зеркального отражения, вычисления координат, кривизн, производ-

ных, нахождение точек пересечения линий

поверхностей. Аналогичные действия про-

изводят

по

отношению

топологическим объектам

помощью топологических команд.

Инструментальная среда

CAS.CADE

включает интегрированную оболочку, подсис-

тему

проектирования пользовательского интерфейса,

также

ряд

многократно исполь-

зуемых специализированных

программ,

таких,

как

2D-

3£>-моделлеры,

подсистема

управления данными, прикладные программы анализа

и т. п.

Интегрированная оболочка служит

для

управления версиями

параллельной рабо-

той

многих пользователей.

Для

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

CAS.CADE имеются специаль-

ные

языковые

программные

средства.

Язык проектирования диалога

состоит

из ко-

манд создания интерфейса

доступа

компонентам.

Создание интерфейса включает создание контейнеров

диалоговых элементов. Кон-

тейнер представляет собой

экранное

окно,

котором будут размещаться элементы. Эле-

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

воз-

никающих

событиях,

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

выбирать режим работы

и т. п.

Различают

ряд

видов

контейнеров. Среди

них

контейнеры

для

сообщений,

преду-

преждающих

об

ошибке, запрашивающих

от

пользователя ответы типа

«да/нет»,

задания

размеров

или

цвета,

выбора файла

т. п.

Примерами команд проектирования диалоговых элементов

могут

служить команды

определения позиции элемента

окне, выбора одного элемента

из

заданного множе-

ства,

конструирования текстовой строки

или

меню, фиксации событий, вызванных

вы-

бором мышью позиции

или

пункта меню,

и др.

структуре прикладной программы, создаваемой

среде

CAS.CADE, можно выде-

лить диалоговый модуль (модуль пользовательского интерфейса

GUI -

Graphic User

Interface), модуль связи

прикладной

частью

собственно прикладную часть, включаю-

щую

отобранные компоненты

и БД,

зависящую

от

приложения.

Объединение используемых

приложении компонентов

прикладную про-

грамму осуществляется

на

языке

C++ или

специальном языке описания интер-

фейсов, напоминающем

язык

IDL. Следовательно, реализуются присущие

C++

270

5.6.

Системные

среды

автоматизированных

систем

поддержка наследования

ограничение доступа (компоненты

могут

иметь ста-

тус

защиты

от

несанкционированного доступа).

помощью технологий

AS.

CADE создают специализированные прило-

жения

(прежде всего специализированные САПР)

со

сравнительно малыми зат-

ратами времени

средств.

5.6.

Системные

среды

автоматизированных

систем

Назначение

системных

сред

автоматизированных

систем

Системы автоматизированного проектирования относятся

числу наибо-

лее

сложных

наукоемких

АС.

Наряду

выполнением собственно проектных

процедур необходимо автоматизировать также управление проектированием,

поскольку

сам

процесс проектирования становится

все

более сложным

зача-

стую

приобретает распределенный характер.

На

крупных

средних предприя-

тиях заметна тенденция

интеграции САПР

АСУП

СДО.

Для

управления

столь сложными интегрированными системами

в их

составе имеется специ-

альное

ПО -

системная

среда

САПР

или АС,

называемая

настоящее время

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

или

системой управления жизнен-

ным

циклом изделий.

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

систем

PDM

непос-

редственно связана

развитием САПР. Появление системных сред

САПР

ознаменовало

переход

от

использования отдельных

не

связанных

друг

дру-

гом

программ, решающих частные проектные задачи,

применению интегри-

рованной совокупности таких программ.

Интегрирующим компонентом

1970-е годы стала единая

база

данных

САПР.

Однако попытки использовать имевшиеся

в то

время СУБД

не

приво-

дили

удовлетворительным результатам

силу разнообразия типов проектных

данных, распределенного

параллельного характера процессов проектирова-

ния,

одной стороны,

недостаточной развитости

баз

данных

- с

другой.

Специализированные СУБД, ориентированные

на

САПР, были созданы

80-е

годы.

Однако

они не

учитывали

или в

недостаточной степени удовлетво-

ряли

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

ектных работ, многоаспектного доступа пользователей

данным.

лишь

на

рубеже

80 —

90-х годов появились системы управления проект-

ными

данными, названные

в то

время Framework

или

системными средами,

сначала

САПР электронной промышленности,

позднее

и в

САПР машино-

строения,

где

они

получили наименование PDM.

На

протяжении 90-х годов роль системных сред неуклонно повышалась.

Во-первых, из-за роста сложности проектируемых объектов

необходимости

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

ин-

теграции систем проектирования

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

тех-

нологическими процессами. Благодаря развитию Internet, Web-

CALS-техно-

логий

такая интеграция стала возможной

глобальном масштабе.

271

Методическое

программное обеспечение автоматизированных систем

Современные системы управления проектными данными предназначены

дл^

информационного обеспечения проектирования

выполняют следующие

оя

новные

функции:

•

хранение проектных данных

доступ

ним,

в том

числе ведение распре-

деленных архивов документов,

их

поиск, редактирование, маршрутизация

визуализация;

•

управление конфигурацией изделия,

т. е.

ведение версий проекта, управле-

ние

внесением изменений;

•

создание спецификаций;

•

защита информации;

•

интеграция данных (поддержка типовых форматов, конвертирование дан-

ных).

Основной компонент систем

PDM -

банк

данных

(БнД).

Он

состоит

из

системы управления базами данных

и баз

данных. Межпрограммный интер-

фейс

значительной мере реализуется через информационный обмен

помо-

щью

БнД.

PDM

отличает легкость доступа

иерархически организованным

данным,

обслуживание запросов, выдача ответов

не

только

текстовой,

но и в

графической

форме, привязанной

конструкции изделия. Поскольку взаимо-

действие внутри группы проектировщиков

основном осуществляется путем

обмена

данными,

то в

системе

PDM

часто совмещают функции управления

данными

управления параллельным проектированием.

Системы

управления

базами

данных

большинстве автоматизированных информационных систем применяют

СУБД, поддерживающие реляционные модели данных. Среди общих требова-

ний

СУБД можно отметить:

обеспечение целостности данных

(их

полноты

достоверности);

защита данных

от

несанкционированного доступа

и от

искажений

вследствие возникающих сбоев аппаратуры;

удобство пользова-

тельского интерфейса;

4) в

большинстве случаев важна возможность распре-

деленной обработки

сетях ЭВМ.

Первые

два

требования обеспечиваются ограничением прав

доступа,

за-

прещением одновременного использования одних

и тех же

обрабатываемых

данных (при возможности

их

модификации), введением контрольных точек

(checkpoints)

для

защиты

от

сбоев

и т. п.

Банк

данных

САПР является важной обслуживающей подсистемой,

он

выполняет

функции информационного обеспечения

имеет

ряд

особенностей.

В нем

хранятся

как

редко изменяемые данные (архивы, справочные данные,

типовые проектные решения),

так и

сведения

текущем состоянии различных

версий

выполняемых проектов.

Как

правило,

БнД

работает

многопользова-

тельском

режиме,

с его

помощью осуществляется информационный интерфейс

(взаимодействие) различных подсистем

САПР.

Построение

БнД

САПР

слож-

ная

задача,

что

обусловлено следующими особенностями

САПР.

Разнообразие проектных данных, фигурирующих

процессах обмена

как

по

своей семантике (многоаспектность),

так и по

формам представления.

частности, значительна доля графических данных.

272