Норенков И.П. - Автоматизированное производство (1054022), страница 50
Текст из файла (страница 50)
!"#$%!#&'&($"!))$*+($*,#&($"!)&*1335@!"! 5:&:#*%)K*:(*AK & +($5(!%%)$-%*#$A&F*:,&* ,$%+@*,:K:!+(M.604D4@++ +0-.@8:=++ "$ -+3: DDE + OLE. Современные ОС позволяют работать одновременно с несколькими задачами с выделением каждой задаче своего окна на экране дисплея. Межпрограммные взаимодействия осуществляются путем посылки сообщений, как это принято в объектно-ориентированном программировании. Используются специальные средства организации взаимодействий.Так, ОС Unix поддерживает взаимодействие асинхронных параллельных процессов, в том числе в разных узлах сети.
Каждый клиент должен предварительно зафиксировать свои потребности ввиде имен используемых сообщений. Сообщения имеют структуру фрейма. Получатель сообщенияопределяет, что сообщение относится к нему, вызывает обработчик сообщения и использует полученные данные в соответствии с своими функциями.В операционных системах Microsoft для организации межпрограммных взаимодействий былипредложены средства Clipboard, DDE, OLE и в дальнейшем технология ActiveX.Работа Clipboard основана на традиционном способе обменных зон — выделении кармана (некоторой области оперативной памяти, разделяемой взаимодействующими программами). При обменах одна программа посылает сообщение в карман, а другая извлекает, интерпретирует и используетэто сообщение. Аналогичный режим работы осуществляется с помощью технологии формированиясоставных документов OLE, но здесь расширены возможности комбинирования данных различныхтипов в передаваемых документах.Различают два способа взаимодействия: связь (linking) и внедрение (embedding).
При связи в создаваемый документ включается не сам текст из источника, а лишь ссылка на него. Очевидно, чтоздесь меньше затраты памяти, изменения в источнике автоматически переходят в документ. При внедрении текст из источника физически переносится в документ.
После чего документ можно редактировать независимо от источника. Оба этих способа реализованы в технологии OLE, что и зафиксировано в ее названии (OLE — Object Linking and Embedding).При обмене с помощью DDE (Dynamic Data Exchange) программа-клиент запрашивает режимдиалога с программой-сервером.
В сообщении указывается имя сервера, имя раздела (обычно раздел— это файл), имя элемента (обмениваемая порция информации). Предварительно такой элемент(атом) должен быть создан, его адрес зафиксирован в таблице атомов. В ответ на запрос создается канал, по которому сервер передает данные или, что реализуется чаще, пересылает адрес нужного атома. По этому адресу клиент дополнительной командой может получить данные.Подход к реализации интероперабельности, имеющийся в DDE и OLE, получил развитие в современных компонентно-ориентированных технологиях разработки ПО, рассматриваемых ниже.P38:9D.0+. 5:001/+ 9 *C"%.
В большинстве автоматизированных информационных системприменяют СУБД, поддерживающие реляционные модели данных.Среди общих требований к СУБД можно отметить: 1) обеспечение целостности данных (их полноты и достоверности); 2) защита данных от несанкционированного доступа и от искажений из-засбоев аппаратуры; 3) удобство пользовательского интерфейса; 4) в большинстве случаев важна возможность распределенной обработки в сетях ЭВМ.Первые два требования обеспечиваются ограничением прав доступа, запрещением одновременного использования одних и тех же обрабатываемых данных (при возможности их модификации), введением контрольных точек (checkpoints) для защиты от сбоев и т.п.C)*% -)**., в САПР является важной обслуживающей подсистемой, он выполняет функции информационного обеспечения и имеет ряд особенностей.
В нем хранятся как редко изменяемые данные (архивы, справочные данные, типовые проектные решения), так и сведения о текущем состоянииразличных версий выполняемых проектов. Как правило, БнД работает в многопользовательском режиме, с его помощью осуществляется информационный интерфейс (взаимодействие) различных подсистем САПР. Построение БнД САПР — сложная задача, что обусловлено следующими особенностями САПР:1.
Разнообразие проектных данных, фигурирующих в процессах обмена как по своей семантике (многоаспектность), так и по формам представления. В частности, значительна доля графических данных.2. Нередко обмены должны производиться с высокой частотой, что предъявляет жесткие требо&.+.)$(*),$" . !"#$%!#&'&($"!))$*+($*,#&($"!)&*1345@!"! 5:&:#*%)K*:(*AK & +($5(!%%)$-%*#$A&F*:,&* ,$%+@*,:K:!+(вания к быстродействию средств обмена (полагают, что СУБД должна работать со скоростью обработки тысяч сущностей в секунду).3. В САПР проблема целостности данных оказывается более трудной для решения, чем в большинстве других систем, поскольку проектирование является процессом взаимодействия многих проектировщиков, которые не только считывают данные, но и изменяют их, причем в значительной мереработают параллельно. Из этого факта вытекают следствия: во-первых, итерационный характер проектирования обычно приводит к наличию по каждой части проекта нескольких версий, любая из нихможет быть принята в дальнейшем в качестве основной, поэтому нужно хранить все версии с возможностью возврата к любой из них; во-вторых, нельзя допускать использования неутвержденных данных, поэтому проектировщики должны иметь свое рабочее пространство в памяти и работать в немавтономно, а моменты внесения изменений в общую БД должны быть согласованными и не порождать для других пользователей неопределенности данных.4.
Транзакции могут быть длительными и трудоемкими. ?")*6)%='$; называют последовательность операций по удовлетворению запроса. В САПР внесение изменений в некоторую часть проекта может вызвать довольно длинную и разветвленную сеть изменений в других его частях из-за существенной взаимозависимости компонентов проекта (многошаговость реализации запросов). В частности, транзакции могут включать в себя такие трудоемкие операции, как верификация проектного решения с помощью математического моделирования.
В результате транзакции могут длиться даже несколько часов и более. Одна из трудностей заключается в отображении взаимозависимости (ассоциативности) данных. При хранении компонентов проекта во внешней памяти затраты времени на обработку запросов оказываются значительно выше, чем в большинстве других автоматизированных систем, с менее выраженными взаимозависимостями данных.5.
Иерархическая структура проектных данных и, следовательно, отражение наследования в целях сокращения объема базы данных.В определенной мере названные особенности учитываются в СУБД третьего поколения, в которых стали применяться черты объектно-ориентированных (объектных) СУБД. В них наборы данных,характеризующих состояние предметной области (состояние проекта в случае САПР), помещаются вотдельные файлы. Интерпретация семантики данных осуществляется с помощью специальных процедур (методов), сопровождающих наборы. Наследование свойств объектов предметной области выражается с помощью введения категорий класса, надкласса, подкласса. Информационные модели приложений для таких СУБД разрабатываются на основе методик типа IDEF1X.Объектные БД выгодны, во-первых, тем, что данные по конкретным объектам проектированияне разбросаны по множеству таблиц, как это имеет место в реляционных БД, а сосредоточены в определенных местах.
Во-вторых, для каждого объекта могут быть назначены свои типы данных. В результате проще решаются задачи управления и удовлетворения запросов.Наряду с чисто объектными СУБД (pure ODBMS), применяют СУБД объектно-реляционные. Впоследних происходит объединение свойств реляционных и объектно-ориентированных СУБД: объектно-ориентированная СУБД снабжается непроцедурным языком запросов или в реляционнуюСУБД вводятся наследование свойств и классы.
Непроцедурность входного языка обеспечивается использованием языка SQL. Его операторы непосредственно включаются в программы на языке С. Возможно написание дополнительных программ, интерпретирующих SQL-запросы.Отличительные особенности СУБД третьего поколения: расширенный набор возможных типовданных (это абстрактные типы, массивы, множества, записи, композиции разных типов, отображениевеличин с значениями разных типов), открытость (доступность из разных языков программирования,возможность обращения к прикладным системам из СУБД), непроцедурность языка (общепринятымстановится язык запросов SQL), управление асинхронными параллельными процессами, состояниекоторых отражает БД.
Последнее свойство позволяет говорить о тесной взаимосвязи СУБД и подсистемы управления проектами DesPM.Названные особенности управления данными в САПР нашли свое выражение в современныхподсистемах управления проектными данными PDM.В PDM разнообразие типов проектных данных поддерживается их классификацией и соответст&.+.)$(*),$" .
!"#$%!#&'&($"!))$*+($*,#&($"!)&*1355@!"! 5:&:#*%)K*:(*AK & +($5(!%%)$-%*#$A&F*:,&* ,$%+@*,:K:!+(вующим выделением групп с характерными множествами атрибутов. Такими группами данных являются описания изделий с различных точек зрения (аспекты). Для большинства САПР машиностроения характерными аспектами являются свойства компонентов и сборок (эти сведения называют Billof materials — BOM), модели и их документальное выражение (основными примерами могут служитьчертежи, 3D модели визуализации, сеточные представления для конечно-элементого анализа, текстовые описания), структура изделий, отражающая взаимосвязи между компонентами и сборками и ихописаниями в разных группах.Вследствие большого объема проектных данных и наличия ряда версий проектов PDM должнаобладать развитой системой поиска нужных данных по различным критериям.Рассмотренные особенности банков данных в САПР позволяют квалифицировать их как системы Data Warehouse (DW), т.е.
хранилища данных. Для хранилищ данных характерен ряд особенностей, совпадающих с названными выше особенностями банков данных САПР: 1) длительное хранениеинформации, отражающей историю разработок; 2) частота операций чтения данных выше частотыопераций обновления данных; 3) использование единых форматов для однотипных данных, полученных из различных источников (например, от разных программно-методических комплексов). Эти особенности позволяют управлять конфигурацией проектов, что, в частности, означает хранение в САПРвсех версий проекта и, возможно, данных по проектам предыдущих разработок, удовлетворениесложных запросов, для ответа на которые требуется извлечение и обработка данных из различных частей хранилища (так называемая многомерная обработка).
Модели данных в DW отличаются от реляционных моделей (RM): в RM использованием нормальных форм стремятся максимально уменьшитьизбыточность данных, что приводит к увеличению числа таблиц, но уменьшенных размеров, однакомногомерный поиск, требующийся в DW, в множестве таблиц затруднен.
Поэтому в DW чаще используется модель данных “звезда”, в которой имеется общая таблица фактов (Fact Table) и каждому факту ставится в соответствие несколько таблиц с необходимыми атрибутами. Целостность данных в DWобеспечивается проверкой и трансформацией данных (data cleaning), вводимых из внешних источников, наличием дисциплины обновления данных, централизованным хранением основной базы, приэтом достаточное быстродействие поддерживается передачей копий определенных частей базы в локальные базы, называемые киосками данных (Data Mart) и ориентированные на отдельные группыпользователей.Примером СУБД, учитывающей требования, предъявляемые со стороны САПР, является система IMAN фирмыEDS Unigraphics.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
