Норенков И.П. Автоматизированное проектирование

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

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

ременным числом ячеек соответственно. Пример OLAP системы — Oracle Express, помогающей ме-

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

ты, обосновывать решения.

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

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

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

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

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

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

программа Clio в упомянутой выше подсистеме Minerva.

"8+/.81 345,+,-./ <38:9D.0+> 5:001/+ + 384.7-+849:0+./. В ряде системных сред

САПР (прежде всего САПР в машиностроении) в подсистемах PDM объединяются функции управле-

ния данными и про ектированием. Пример такой PDM — подсистема Design Manager в САПР Euclid

Quantum. Функциями этой PDM являются управление потоками проектных данных, версиями про ек-

та, взаимодействием разработчиков, защит а информации, конфигурирование и адаптация версий си-

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

Подсистема Design Manager в Euclid Quantum состоит из частей пользовательской, админиcтратора и управления

структурой продукта.

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

кретного разработчика, в частности, в его индивидуальной БД (User Area), либо в зоне работы рабочей группы (Workgroup

Area), в частности, в ее БД. Утвержденные данные пере сылаются в центральную БД (Repository). Пересылка данных из

User Area (UA) в Workgroup Area (WGA) происходит по инициативе разработчика командами check in или share. Первая из

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

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

правление их в репозиторий R, или неутверждение и отправка данных в UA на доработку. Разработчик может запрашивать

данные для начала нового проекта по команде copy out или для модификации существующего проекта по команде check

out (рис 5.6).

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

из любой БД (UA, WGA, R) выполняется командой retrieve, посылка в БД — командой store. При обращении к БД пользо-

ватель видит структуру данных (директорию — имена папок и их частей) и определенный аспект данных выделенного в

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

екта, 3D изображение.

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

вами доступа пользователей, связь с внешними системами (управление импортом/экспортом данных) и др.

В системной среде NELSIS CAD Framework имеются части: 1) DMS (Design Management

Services) для поддержки иерархии данных, управления версиями и потоками задач; 2) DMI (Design

Management Interface) с функциями открытия и закрытия баз данных, вызова и пересылки данных, до-

ступа к DMS; 3) FUS (Framework User Services), включающая ряд браузеров для визуализации инфор-

мации.

Базовая сущность в NELSIS CAD Framework – объект (ячейка). Объект состоит из нескольких примитивов и/или

ссылок. Объекты объединяются в модули. В модуле все объекты имеют одни и те же имена и тип представления (view-

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

вариантов. Объекты могут находиться в отношениях эквивалентности друг с другом или иерархии. Каждый модуль име-

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

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

141

%+,.5.6. Потоки данных в PDM Design Manager (САПР Euclid Quantum)

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

Предусмотрены следующие статусы: 1) ")2#1'; – объект находится в работе, его можно модифицировать, в моду-

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

рая версия сохраняется, получая, например, ст атус Backup; 2) принятый (аctual version) – именно эт а версия служит для

обмена между объектами, автоматически не стирается, ее модификации осуществляются через рабочий статус; 3) архив-

ный (Backup); 4) порождаемый (Derived version) – статус зарезервирован для вновь создаваемых объектов, например, при

синтезе проектных решений. Разработчик сам изменяет статус объектов.

Любое изменение должно отражаться в отношениях объекта. NELSIS CAD Framework не изменяет существующие

отношения, а создает новые. Например, если изменяется объект “топология”, то новая версия не наследует отношение со

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

одновременно работать и изменять один и тот же объект разным разработчикам, так как каждый из них будет работать со

своей рабочей версией.

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

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

Для интеграции программных компонентов в системную среду (т.е. для согласования по данным этих компонентов

с БД среды) используются обычные модификации компонента, если известен его код, или создается оболочка – модульная

абстракция.

В NELSIS CAD Framework имеется несколько браузеров для общения с пользователем. Для каждого браузера мо-

жет быть открыто свое окно.

1. Design flow browser – показывает взаимосвязь между проектными процедурами, историю получения объекта,

список процедур, которые могут быть выполнены над объектом, позволяет задавать маршруты проектирования, вызывать

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

2. Hierarchy Browser – показывает граф иерархии и место объекта в ней.

3. Version Browser – показывает все виды (viewtypes), статусы и номера версий выбранного объекта. Он может по-

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

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

4. Equivalence Browser показывает отношения эквивалентности для выбранного объекта.

5. Schema Browser показывает сущности и их отношения в виде схемы данных, в отдельном окне показываются за-

про сы к БД и ответы на них.

5.3. !0,-8</.0-:DF01. ,8.51 8:?8:B4-7+ 384@8://04@4 4B.,3.A.0+>

*8.

51 B1,-842 8:?8:B4

-7+ 38+D4L.0+2.

CASE-системы часто отождествляют с инструмен-

та льными средами разработки ПО, называемыми +"$-)/' 2.+&"#; ")6")2#&%' 0"'4#@$*'; (RAD —

Rapid Application Development). Примерами широко известных инструментальных сред RAD являют-

ся VB (Visual Basic), Delphi, PowerBuilder фирм Microsoft, Borland, PowerSoft соответственно. Приме-

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

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

Большое практическое значение имеют инструментальные среды для разработки ПП, предназ-

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

раненностью последних.

Простейшая система для написания Windows-программ на языке С++, позволяющая сократить

объем кода, создаваемого пользователем вручную, основана на библиотеке DLL (Dynamic Link

Library), которая содержит модули, реализующие функции API (Application Programming Interface) для

связи прикладных программ с ОС Windows.

Эта система получила развитие в MFC (Microsoft Foundation Classes), представляющей собой

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

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

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

зываемый 70")(4$*'$ / + # 2.&'9/'. При это м достигается ав т о м а тическое создание каркасов программ,

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

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

1. Окно меню с пунктами “file”, “edit”, “window” и т.п., реа лизующими функции, очевидные из

названия пунктов.

2. Окно формы, на котором собственно и создается прототип экрана будущей прикладной

программы.

3. Палитра инструментов — набор изображений объектов пользовательского интерфейса, из ко-

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

142

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

торых можно компоновать содержимое окна формы.

4. Окно свойств и событий, с помощью которого ставятся в соответствие друг другу объекты ок-

на формы, события и обработчики событий. : #2.&'$/ в прикладной программе является нажатие

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

событийная процедура (обработчик события), которая проверяет код клавиши и вызывает нужную ре-

акцию. В RAD имеются средства для удобства разработки обработчиков событий.

5. Окно редактора кода, в котором пользователь записывает создаваемую вручную часть кода.

6. Окно проекта — список модулей и форм в создаваемой программе.

Для написания событийных процедур в Visual Basic используется язык и текстовый редактор од-

ноименного языка, в Delphi — язык и редактор языка Object Pascal. В CASE-системе фирмы IBM,

включающей части VisualAge (для клиентских приложений) и VisualGen (для серверных приложе-

ний), базовым языком выбран SmallTalk. В среде разработки приложений клиент-сервер SQLWindows

оригинальные фрагменты программ пишутся на специальном языке SAL. Нужно заметить, что для ре-

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

обычная для 3GL технология программирования.

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

промежуточный "-код. Вместе с интерпретатором "-кода эта программа рассматривается, как ЕХЕ-

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

ции для своего исполнения.

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

ся средства для реализации и ряда других функций. Так, в наиболее развитой версии Visual Basic к

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

— поддержка ODBC, что дает возможность работы с различными СУБД;

— разработка баз данных;

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

— интерактивная отладка процедур на SQL Server;

— управление версиями при групповой разработке ПО;

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

Для создания сред RAD в случае +$&$(#8# 0"#8")//'"#()*'9 требуется решить ряд дополни-

тельных проблем, обусловливаемых многоплатформенностью в гетерогенных сетях, обилием приме-

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

нуто в объектно-ориентированных технологиях на базе языка сетевого программирования Java. Кро-

ме того, с помощью Java удается решить еще одну актуальную для Internet и Intranet задачу — сделать

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

Платформенная инвариантность в Java достигается, благодаря введению виртуальной метамаши-

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

Любой Web-сервер при наличии запроса на Java-программу со стороны клиента транслиру ет (компи-

лирует) эту программу на язык метамашины. Скомпилированный модуль, называемый байт-кодом, пе-

ресылается клиенту. Клиент должен выполнить интерпретацию байт-кода. Соответствующие интер-

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

Java используется двояким образом. Во-первых, как средство “оживления” Web-страниц. В этом

случае программный Java-компонент называют )04$&#/, аплет встраивается в ст раницу с помощью

специального тега, имеющегося в языке HTML. Во-вторых, Java — универсальный язык программи-

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

к Web-технологии.

Хотя и ранее были известны технологии на базе промежуточных "-кодов, именно технология

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

де. Она последовательно отражает принципы объектно-ориентированного программирования и обес-

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

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

Для разработки ПО на языке Java создан ряд инструментальных средств. Основной средой явля-

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

143

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

ется JDK (Java Developer’s Kit). В ней имеются: 1) библиотеки классов, в том числе библиотеки ос-

новных элементов языка, часто используемых оболочек (wrapper), процедур ввода-вывода, компонен-

тов оконного интерфейса и др. 2) инструментальные средства такие, как компилятор байт-кодов, ин-

терпретатор, просмотрщик аплетов, отладчик, формирователь оконных форм и т.п . Развитую RAD-

среду — PowerJ — предлагает фирма Sybase.

Значительное внимание уделяется разработке инструментальных сред для создания Web-узлов, примером такой

среды может служить HAHTSite фирмы HAHTSoftware. Для разработки Java-программ из готовых компонентов можно

использовать среду IBM Visual Age for Java, в которой имеются (как и в среде VB) версии учебная, профессиональная и

общецелевая (Enterprise), и др.

Наряду с самостоятельными RAD-системами имеются и RAD-системы в составе САПР. Это прежде всего упомяну-

тая выше система CAS.CADE фирмы Matra Datavision.

4/340.0-04-48+.0-+849:001. -.604D4@++.

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

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

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

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

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

Компиляция программ из готовых компонентов — идея не новая. Уже первые шаги в области ав-

тома тизации программирования были связаны с созданием библиотек по дпрограмм. Конечно, для объ-

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

чительной части программного кода на языках третьего поколения. Упрощение и ускорение разработ-

ки прикладного ПО достигается с помощью языков четвертог о поколения (4GL), но имеющиеся систе-

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

Современные системы интеграции ПО построены на базе объектной методологии.

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

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

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

нентов в сетевых технологиях достигает ся с помощью механизмов, подобных удаленному вызову

процедур RPC. К библиотекам классов относятся MFC, библиотеки для доступа к реляционным БД

(например, для встраивания в прикладную программу драйверов ODBC) и др.

Преимущества использования готовых компонентов обусловлены тщательной отработкой мно-

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

стных методов и алгоритмов.

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

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

тами проблематично. Именно стремление устранить этот недостаток привело к появлению CBD —

компонентно-ориентированных технологий разработки ПО. Составными частями таких технологий

являются унифицированные способы интеграции программного обеспечения.

Возможны два способа включения компонентов (модулей) в прикладную программу — модер-

низация (reenginering) или инкапсуляция (encapsulation или wrapping).

L#-$"*'6)='9 требует знания содержимого компонента, интероперабельность достигается вне-

сением изменений собственно в сам модуль. Так ой способ можно назвать способом “белого ящика”.

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

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

D*%)0+749='9 выполняется включением модуля в среду с помощью интерфейса — его внешне-

го окружения (оболочки — wrapper). При этом компонент рассматривается как “черный ящик”: спе-

цификации, определяющие интерфейс, выделены из модуля, а детали внутреннего содержимого скры-

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

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

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

модуля — /#-745*)9 )2+&")%='9. В со став этих сведений могут входить описания всех входных и вы-

ходных для модуля данных (в том числе имеющихся в модуле интерактивных команд), структура ко-

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

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

144

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

Компонентно-ориентированные системы построены на основе инкапсуляции компонентов. В

архитектуре этих систем можно выделить следующие части: 1) прикладная программа (клиент), со-

здаваемая для удовлетворения возникшей текущей потребности; 2) посредник (брокер или менеджер),

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

интерфейсных данных; 3) множество компонентов , состоящих каждый из программного модуля, реа-

лизующего некоторую полезную функцию, и оболочки (интерфейса). В спецификации интерфейса

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

пример, реакции на нажатие клавиш).

Собственно интерфейс представляет собой обращения к функциям модуля, называемым в СВD-

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

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

сколько разных функций, поэтому у него может быть несколько интерфейсов или методов. Каждый

новый создаваемый интерфейс обеспечивает доступ к новой функции и не отменяет прежние возмож-

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

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

ращается с запросом на выполнение некоторой процедуры. Запрос направляется к посреднику. В по-

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

репозиторий) интерфейсов

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

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

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

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

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

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

распределенной сети из многих компьютеров.

В большинстве случаев реализуется синхронный режим работы, подразумевающий приостанов-

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

Наиболее популярными в настоящее время являются следующие CBD-технологии.

— OpenDoc — технология, основанная на спецификациях CORBA, разработанных в начале 90-

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

терных фирм. В OpenDoc реализуется технология распределенных вычислений на базе программ-по-

средников ORB.

— COM (Common Object Model) — технология, развиваемая корпорацией Microsoft на базе ме-

ханизма OLE. С етевой вариант этой технологии (для систем распределенных вычислений) известен

под названием DCOM (Distributed COM). Объекты DCOM (в частности, объекты, которые можно

вставлять в HTML-документы или к которым можно обращаться из Web-браузеров) известны под на-

званием компонентов ActiveX. В СОМ/DCOM, как и в OpenDoc, можно использовать компоненты, на-

писанные на разных объектно-ориентированных языках программирования. Но в отличие от OpenDoc

в СОМ/DCOM остается естественная для Microsoft ориентация только на операционные системы

Windows (реализация DCOM предусмотрена в ОС Windows NT 4.0). Технология ActiveX (прежнее на-

звание OLE Automation) обеспечивает интерфейс для управления объектами одного приложения из

другого. В общем плане ActiveX — технология интеграции программного обеспечения фирмы

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

AutoCAD.

— JavaBeans — сравнительно новая технология, в которой используются компоненты, написан-

ные на языке Java.

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

Организация связи клиента с серверными компонентами и в CORBA, и в DCOM происходит с помощью разновид-

ностей языка IDL (Interface Definution Language). Язык IDL в CORBA позволяет описывать интерфейсы создаваемых ком-

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

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

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

(например, float, double, char, boolean, struct), конструируемые пользователем (например, записи и массивы) и объектные

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

145

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

ссылки, указывающие на интерфейсы компонентов. Описание интерфейсов начинается с ключевого слова interface, за ко-

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

ции (методы) в виде идентификаторов операций с возможными перечислениями параметров операций и указанием их

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

Далее классы объектов (программные модули) должны быть реализованы в CORBA-среде. Для этого компилятор

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

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

ного на IDL метода клиентский и серверный стабы – специальные программные модули, обеспечивающие доступ к ком-

понентам.

Основное назначение стабов – выполнение маршалинга и организация передачи данных через сеть. Маршалин-

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

представление данных в разных компьютерных средах может быть различным (например, различия в кодировке симво-

лов, в изображении чис ел с плавающей запятой). Клиент ский стаб будет использоваться для передачи вызовов и дан-

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

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

На серверной стороне данные о каждом новом классе объектов, поддерживаемом конкретным сервером, заносятся

в репозитарий реализаций. Эту операцию выполняет объектный адаптер. Обычно в ORB имеется несколько объектных

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

лиотеки, на базы данных, на группу отдельных программ и т.п.).

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

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

. Возможны разные спо собы активации

и дезактивации компонентов. В первом из них для обслуживания каждого клиентского запрос а создается своя копия

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

ления во времени.

При реализации запроса брокер через объектный адаптер активирует соответствующий компонент. Далее клиент-

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

Изложенную схему клиент-серверного взаимодействия называют статиче ской. В CORBA предусмотрены также ди-

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

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

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

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

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

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

В CORBA предусмотрен ряд унифицированных сервисов, работающих под управлением ORB. В частности, это

сервисы:

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

ти по имени;

— жизненного цикла – обеспечивает создание, перемещение, копирование и удаление объектов (документов) в си-

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

— обработки транзакций — осуществляет управление транзакциями (блокировка, фиксация и откат транзакций)

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

— событий — обеспечивает асинхронное распространение и обработку сообщений о событиях, происшедших при

реализации процессов, что позволяет заинтересованным объектам координировать свои действия;

— обеспечения безопасности — поддерживает целостность данных.

В СОМ/DCOM все объекты сгруппированы в классы и каждый класс имеет свой идентификатор CLSID, а каждый

интерфейс (метод) класса – свой идентификатор. Для создания объекта (экземпляра класса) клиент обращается к серверу

библиотеки СОМ с указанием CLSID и идентификаторов всех требуемых интерфейсов. Сервер библиотеки СОМ находит

в таблице-реестре по CLSID адрес удаленной машины, на которой размещен запрошенный компонент, и передает ей за-

про с клиента. На серверной стороне создается объект (копия компонента), он активируется и возвращает клиенту указа-

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

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

щен компонент, но можно выбрать и другую машину, указав в запросе, например, ее IP- адрес.

Появление технологии JavaBeans обусловлено успехом языка программирования Java. Технологию JavaBeans отли-

чают от СОМ/DCOM две особенности. Во-первых, Java — единственный в JavaBeans язык программирования. Единст-

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

нологии JavaBeans. Во-вторых, технология JavaBeans является платформенно-независимой.

Компоненты в JavaBeans являются классами Java. Для их создания, модификации и объединения в прикладные про-

граммы имеются специальные средства в составе инструментальной среды JDK (Java Development Kit). С их помощью

компоненты JavaBeans могут быть встроены в Java-аплеты, приложения или другие более крупные компоненты. В качест-

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

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

146

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

Развитие CBD-систем возможно в направлении дальнейшего упрощения программирования и,

следовательно, сокращения сроков разработки ПО, однако это происходит за счет снижения степени

универсальности соответствующих инструментальных средств. Такие более специализированные

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

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

В общем случае компоненты системной среды объединены в несколько сценариев (потоков про-

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

ских фрагментов и расширений. Имеются возможности не только вставки новых фрагментов, но и за-

мены исходных компонентов в потоках процедур на оригинальные с сохранением интерфейса. Собст-

венно многие системы, основанные на применении языков четвертого поколения (4GL), относятся

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

разуются с помощью операторов 4GL.

"8+/.8 8.:

D+?:=++ 7

4/340.0-04-48+.0-+849:0042 -.604D4@++ 9 *C"%.

Основные идеи

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

ных библиотек компонентов реализованы в системе CAS.CADE (Computer Aided Software/ Computer

Aided Design Engineering) фирмы Matra Datavision.

Система CAS.CADE состоит из нескольких частей. Основными частями являются библиотеки классов и инструмен-

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

Библиотеки (Object Libraries) в CAS.CADE представляют собой специализированные наборы заранее разработан-

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

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

верхности, деревья, решатели уравнений, операторы сортировки, поиска на графах и т.п. Классы группируются в пакеты

(Packages), пакеты – в наборы (Toolkits), наборы – в домены (Resourse Domains).

В CAS.CADE выделено несколько библиотек. Во-первых, это библиотеки 2D и 3D моделирования, включающие

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

назначен для связи с ОС и управления данными, для обмена данными с внешними CAD системами, для создания сеточ-

ных моделей и др. Так, в состав библиотеки обмена данными входят конверторы данных из формата CAS.CADE в Express-

файл прикладного протокола АР214 стандарта STEP и обратно. Аналогичные конверторы имеются для взаимного преоб-

разования данных из формата CAS.CADE в другие популярные в САПР форматы IGES и DXF/SAT.

Необходимо отметить, что основные приложения, на которые ориентирована CAS.CADE, — это приложения ма-

шинной графики и геометрического моделирования, поэтому в системе наиболее развиты библиотеки графических и гео-

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

Геометрическое моделирование и визуализация в CAS.CADE поддерживаются соответствующим ПО. В это ПО

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

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

просмотрщик, составляющие подсистему “Тестирование”.

Набор “Геометрия” включает пак еты канонических геометрических элементов и массивов (множеств) этих элемент ов.

Пакеты gp, geom2d и geom включают 2D и 3D геометрические элементы (классы), используемые в качестве сущно-

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

мерами элементов могут служить декартовы координаты, точки, векторы, линии, окружности, квадратичные кривые, сфе-

рические, тороидальные и конические поверхности, кривые и поверхности Безье, В-сплайнов и др.

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

gce, GC, GCE2d включают алгоритмы построения сущностей из элементов пакетов gp, Geom, Geom2d, например, постро-

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

диусы, параллельные или нормальные прямые и т.п.

Набор “Топология” определяет структуры данных, описывающих связи (отношения) между геометрическими сущ-

ностями – классами предыдущего набора “Геометрия”. К структурам топологических данных относятся вершины, ребра,

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

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

линдра, конуса, сферы, тора. В наборе имеются также средства: 1) для скругления острых углов и кромок, т.е. формиро-

вания галтелей постоянного или переменного радиуса; 2) для поддержания непрерывности при сопряжении разных по-

верхностей; 3) для метрических расчетов – определения длин ребер, площадей участков поверхности, объемов тел, цент-

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

В подсистему “Тестирование” входят командный язык TCL (Test Command Language), на котором задается програм-

ма тестирования и просмотра библиотечных компонентов, интерпретатор TCL и 2D/3D визуализатор. В TCL имеются

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

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

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

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

147

:&:#*%)K* :(*AK & +($5(!%%)$

-%*#$A&F*:,&* ,$%+@*,:K :!+(

5@!"! 5

вывод на экран координат и других параметров геометрических объектов, создание окон для различных видов, масштаби-

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

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

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

ний и поверхностей. Ана логичные действия производят по отношению к топологическим объектам с помощью топологи-

ческих команд.

Инструментальная среда CAS.CADE включает интегрированную оболочку, подсистему проектирования пользова-

тельского интерфейса, а также ряд многократно используемых специализированных программ, таких как 2D и 3D моде-

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

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

Для проектирования пользовательского интерфейса в CAS.CADE имеются специальные языковые и программные

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

Создание интерфейса включает создание контейнеров и диалоговых элементов. Контейнер представляет собой эк-

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

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

жим работы и т.п.

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

вающих от пользователя ответы типа “да/нет”, задания размеров или цвета, выбора файла и т.п.

Примерами команд проектирования диалоговых элементов могут служить команды определения позиции элемента

в окне, выбора одного элемента из заданного множества, конст руирования текстовой ст роки или меню, фиксации собы-

тий, вызванных выбором мышью позиции или пункта меню, и др.

В структуре прикладной программы, создаваемой в среде CAS.CADE, можно выделить диалоговый модуль (модуль

пользовательского интерфейса GUI – Graphic User Interface), модуль связи с прикладной частью и собственно прикладную

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

Объединение используемых в приложении компонентов в прикладную программу осуществляется на языке С++ или

специальном языке описания интерфейсов, напоминающем язык IDL.. Следовательно, реализуются присущие С++ под-

держка наследования и ограничение доступа (компоненты могут иметь ста тус защиты от несанкционированного доступа).

С помощью CAS.CADE создают специализированные приложения (прежде всего специа лизиро-

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

P38:L0.0+> + 94384,1 5D> ,: /474 0 -84D >

1. Какие функции выполняет сетевое ПО?

2. Что понимают под менеджером и агентом в ПО управления сетью?

3. Что такое “эмуляция терминала”?

4. Охарактеризуйте различия между телеконференцией и видеоконференцией.

5. Назовите основные функции браузера.

6. Какие средства имеются в языке HTML для реа лизации гипертекста?

7. Что такое “электронная подпись”?

8. Перечислите основные особенности БнД в САПР.

9. Что такое “транзакция” в системах обработки данных?

10. Что понимают под системой PDM? Чем отличается система PDM от обычного БнД?

11. Назовите основные о собенности хранилищ данных. Почему они используются в PDM?

12. Поясните механизм двухфазной фиксации транзакций в БнД.

13. В чем заключают ся специфиче ские о собенно сти компонентно-ориентированных технологий раз-

работки ПО?

14. Поясните назначение брокера ORB в технологии CORBA.

15. Что такое язык описания интерфейсов IDL?

16. Каковы назначение и ст руктура системы CAS.CADE? Приведите примеры компонентов CAS.CADE.

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

148

%.=3/0<0 ;-3.<=0-34690N

64=3B6=0C0-34699?G 101=.B

6.). $,4B.004,-+ 384.7-+849:0+> :9-4/:-+?+849:0016 ,+,-./

Q-:31 384.7-+849:0+> C*. К проектированию АС непо средственное отношение имеют два

направления деятельности: 1) собственно 0"#$%&'"#()*'$ K: конкретных предприятий (отраслей) на

базе готовых программных и аппаратных компонентов с помощью специальных инструментальных

средств разработки; 2) проектирование упомянутых %#/0#*$*&#( K: и инструментальных средств,

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

ных систем.

Сущность первого направления можно охарактеризовать словами “+'+&$/*)9 '*&$8")='9”

(другое близкое понятие имеет название — %#*+)4&'*8). Разработчик АС должен быть специалистом

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

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

та льными средствами разработки приложений (CASE-cредствами) и быть готовым к восприятию и

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

Существует ряд фирм, специализирующихся на разработке проектов АС (например, Price Waterhouse, Jet Info,

Consistent Software, Interface и др.)

Второе направление в большей мере относится к области разработки математического и про-

граммного обеспечений для реализации функций АС — моделей, методов, алгоритмов, программ на

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

рования, операционных систем и т.п. Существует ряд общеизвестных технологий (методик) проекти-

рования ПО АС, среди которых прежде всего следует назвать %#/0#*$*&*#-#"'$*&'"#()**7< ")6")-

2#&%7 — технологию индустриальной разработки программных систем СВD, поясненную в гл. 5.

Для каждого класса АС (САПР, АСУ, геоинформационные системы и т.д.) можно указать фирмы,

специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Мно-

гие из них на основе одной из базовых технологий ре ализуют свой подход к созданию АС и придер-

живаются стратегии либо тотального поставщика, либо открытости и расширения системы приложе-

ниями и дополнениями третьих фирм.

В России действует государственный стандарт на стадии создания автоматизированных систем

ГОСТ 34.601-90. Существует и международный стандарт на стадии жизненного цикла программной

продукции (ISO 12207:1995). Как собственно АС, так и компоненты АС являются сложными система-

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

— *'+,#-9A$$ (Top-of-Design); четкая реализация нисходящего проектирования приводит к +0'-

")45*#; /#-$4' разработки ПО, на каждом витке спирали блоки предыдущего уровня детализируют-

ся, используются обратные связи (альтернативой является так называемая %)+%)-*)9 /#-$45, относя-

щаяся к поочередной реализации частей системы);

— (#+,#-9A$$ (Bottom-of-Design);

— B(#4<='#**#$ (Middle-of-Design).

Чаще всего используется нисходящий стиль блочно-иерархического проектирования.

Рассмотрим этапы нисходящего проектирования АС.

Верхний уровень проектирования АС часто называют %#*=$0&7)45*./ проектированием. Кон-

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

разработки эскизного проекта и прототипирования (согласно ГОСТ 34.601-90, эти ст адии называют

формированием требований к АС, разработкой концепции АС и эскизным проектом).

!"$-0"#$%&*.$ '++4$-#()*'9 проводят путем анализа (обследования) деятельности предприя-

тия (компании, учреждения, офиса), на котором создается или модернизируется АС. При этом нужно

получить ответы на вопросы: что не устраивает в существующей технологии? Что можно улучшить?

Кому это нужно и, следовательно, как ов будет эффект? Перед обследованием формируются и в про-

цессе его проведения уточняются цели обследования — определение возможностей и ресурсов для

повышения эффективности функционирования предприятия на основе автоматизации процессов уп-

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

149

5@!"! 6

%*#$A&,& +($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%5@!"! 6

равления, проектирования, документооборота и т.п. Содержание обследования — выявление структу-

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

томатизации. Обследование проводят системные аналитики (системные интеграторы) совместно с

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

На основе анализа результатов обследования строят модель, отражающую деятельность пред-

приятия на данный момент (до реорганизации). Такую модель называют “As Is”. Далее разрабатыва-

ют исходную концепцию АС. Эта концепция включает в себя предложения по изменению структуры

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

“To Be” (как должно быть).

Результаты анализа конкретизируются в ТЗ на создание АС. В ТЗ указывают потоки входной ин-

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

бования к производительности (пропускной способности) и т.п. ТЗ направляют заказчику для обсуж-

дения и окончательного согласования.

F+%'6*.; 0"#$%& (техническое предложение) представляют в виде проектной документации,

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

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

гноз развития предприятия.

В отношении аппаратных средств и особенно ПО такой выбор чаще всего есть выбор фирмы-по-

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

работа программ разных фирм достигается с большим трудом. В проекте может быть предложено не-

сколько вариантов выбора. При анализе выясняются возможности покрытия автоматизируемых функ-

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

нального ПО. Подобный анализ необходим для предварительной оценки временных и материальных

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

автоматизации, подразделить проектирование АС на работы первой, второй и т.д. очереди.

После принятия эскизного проекта разрабатывают 0"#&#&'0 АС, представляющий собой набор

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

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

но, заблаговременно внести коррективы в проект.

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

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

иной методике формализации спецификаций. Формализация нужна для однозначного понимания ис-

полнителями и заказчиком требований, ограничений и принимаемых решений.

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

ное место занимают /#-$4' преобразования, хранения и передачи информации. Модели, полученные

в проце ссе обследования предприятия, являются моделями его функционирования. В процессе разра-

ботки АС модели, как правило, претерпевают существенные изменения (переход от “As Is” к “To Be”)

и в окончательном виде модель “To Be” рассматривают в качестве модели проектируемой АС.

Различают функциональные, информационные, поведенческие и структурные модели. H7*%='-

#*)45*)9 модель системы описывает совокупность выполняемых системой функций. D*E#"/)='#*-

*.$ модели отражают структуры данных — их состав и взаимосвязи. !#($-$*1$+%'$ модели описы-

вают информационные процессы (динамику функционирования), в них фигурируют такие категории,

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

тельность событий, осуществляется привязка ко времени. :&"7%&7"*.$ модели характеризуют мор-

фологию системы (ее построение) — состав подсистем, их взаимосвязи.

Содержанием последующих этапов нисходящего проектирования (согласно ГОСТ 34.601-90, это

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

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

ной среды, детальное инфологическое проектирование БД и их первоначального наполнения, разра-

ботка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего

проектирования. Эти работы составляют содержание ")2#1$8# 0"#$%&'"#()*'9. После этого следуют

&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*

150