Автор: Пользователь скрыл имя, 17 Января 2011 в 23:59, курсовая работа
Появление первых программ для автоматизации проектирования за рубежом и в СССР относится к началу 60-х гг. Тогда были созданы программы для решения задач строительной механики, анализа электронных схем, проектирования печатных плат. Дальнейшее развитие САПР шло по пути создания аппаратных и программных средств машинной графики, повышения вычислительной эффективности программ моделирования и анализа, расширения областей применения САПР, упрощения пользовательского интерфейса, внедрения в САПР элементов искусственного интеллекта.
ВВЕДЕНИЕ 3
ГЛАВА I. Общие вопросы создания САПР
1. Общие сведения о проектировании 5
2. ПОНЯТИЕ САПР 6
3. Достоинства САПР 7
ГЛАВА II. КЛАССИФИКАЦИЯ И ОБОЗНАЧЕНИЕ
1. Структура САПР 9
2. РАЗНОВИДНОСТИ САПР 11
3. ФУНКЦИИ, ХАРАКТЕРИСТИКИ И ПРИМЕРЫ
CAE/CAD/CAM-СИСТЕМ 13
4. ПОНЯТИЕ О CALS-технологии 15
5. КОМПЛЕКСНЫЕ АВТОМАТИЗИРОВАННЫЕ
СИСТЕМЫ 16
ГЛАВА III. ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ САПР
1. СТРУКТУРА ТЕХНИЧЕСКОГО
ОБЕСПЕЧЕНИЯ САПР 18
2. АППАРАТУРА РАБОЧИХ МЕСТ В
АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ
ПРОЕКТИРОВАНИЯ И УПРАВЛЕНИЯ 22
ГЛАВА IV. СИСТЕМНЫЕ СРЕДЫ И ПРОГРАММНО-МЕТОДИЧЕСКИЕ КОМПЛЕКСЫ САПР.
1. ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММНОМ ОБЕСПЕЧЕНИИ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ 26
2. НАЧНАЧЕНИЕ И СОСТАВ СИСТЕМНЫХ СРЕД САПР 30
ЗАКЛЮЧЕНИЕ 39
ЛИТЕРАТУРА 40
4.
Транзакции могут быть
5. Иерархическая структура проектных данных и, следовательно, отражение наследования в целях сокращения объема базы данных.
В определенной мере названные особенности учитываются в СУБД третьего поколения, в которых стали применяться черты объектно-ориентированных (объектных) СУБД. В них наборы данных, характеризующих состояние предметной области (состояние проекта в случае САПР), помещаются в отдельные файлы. Интерпретация семантики данных осуществляется с помощью специальных процедур (методов), сопровождающих наборы. Наследование свойств объектов предметной области выражается с помощью введения категорий класса, надкласса, подкласса. Информационные модели приложений для таких СУБД разрабатываются на основе методик типа IDEF1X.
Объектные БД выгодны, во-первых, тем, что данные по конкретным объектам проектирования не разбросаны по множеству таблиц, как это имеет место в реляционных БД, а сосредоточены в определенных местах. Во-вторых, для каждого объекта могут быть назначены свои типы данных. В результате проще решаются задачи управления и удовлетворения запросов.
Наряду с чисто объектными СУБД (pure ODBMS), применяют СУБД объектно-реляционные. В последних происходит объединение свойств реляционных и объектно-ориентированных СУБД: объектно-ориентированная СУБД снабжается непроцедурным языком запросов или в реляционную СУБД вводятся наследование свойств и классы. Непроцедурность входного языка обеспечивается использованием языка SQL. Его операторы непосредственно включаются в программы на языке С. Возможно написание дополнительных программ, интерпретирующих SQL-запросы.
Отличительные особенности СУБД третьего поколения: расширенный набор возможных типов данных (это абстрактные типы, массивы, множества, записи, композиции разных типов, отображение величин с значениями разных типов), открытость (доступность из разных языков программирования, возможность обращения к прикладным системам из СУБД), непроцедурность языка (общепринятым становится язык запросов SQL), управление асинхронными параллельными процессами, состояние которых отражает БД. Последнее свойство позволяет говорить о тесной взаимосвязи СУБД и подсистемы управления проектами DesPM.
Названные особенности управления данными в САПР нашли свое выражение в современных подсистемах управления проектными данными PDM.
В PDM разнообразие типов проектных данных поддерживается их классификацией и соответствующим выделением групп с характерными множествами атрибутов. Такими группами данных являются описания изделий с различных точек зрения (аспекты). Для большинства САПР машиностроения характерными аспектами являются свойства компонентов и сборок (эти сведения называют Bill of materials — BOM), модели и их документальное выражение (основными примерами могут служить чертежи, 3D модели визуализации, сеточные представления для конечно-элементого анализа, текстовые описания), структура изделий, отражающая взаимосвязи между компонентами и сборками и их описаниями в разных группах.
Вследствие большого объема проектных данных и наличия ряда версий проектов PDM должна обладать развитой системой поиска нужных данных по различным критериям.
Рассмотренные
особенности банков данных в САПР
позволяют квалифицировать их как
системы Data Warehouse (DW), т.е. хранилища данных.
Для хранилищ данных характерен ряд
особенностей, совпадающих с названными
выше особенностями банков данных САПР:
1) длительное хранение информации, отражающей
историю разработок; 2) частота операций
чтения данных выше частоты операций обновления
данных; 3) использование единых форматов
для однотипных данных, полученных из
различных источников (например, от разных
программно-методических комплексов).
Эти особенности позволяют управлять
конфигурацией проектов, что, в частности,
означает хранение в САПР всех версий
проекта и, возможно, данных по проектам
предыдущих разработок, удовлетворение
сложных запросов, для ответа на которые
требуется извлечение и обработка данных
из различных частей хранилища (так называемая
многомерная обработка). Модели данных
в DW отличаются от реляционных моделей
(RM): в RM использованием нормальных форм
стремятся максимально уменьшить избыточность
данных, что приводит к увеличению числа
таблиц, но уменьшенных размеров, однако
многомерный поиск, требующийся в DW, в
множестве таблиц затруднен. Поэтому в
DW чаще используется модель данных “звезда”,
в которой имеется общая таблица фактов
(Fact Table) и каждому факту ставится в соответствие
несколько таблиц с необходимыми атрибутами.
Целостность данных в DW обеспечивается
проверкой и трансформацией данных (data
cleaning), вводимых из внешних источников,
наличием дисциплины обновления данных,
централизованным хранением основной
базы, при этом достаточное быстродействие
поддерживается передачей копий определенных
частей базы в локальные базы, называемые
киосками данных (Data Mart) и ориентированные
на отдельные группы пользователей.
Программные средства управления проектированием САПР. В системных средах САПР управления проектированием возлагается на подсистему CAPE, в некоторых системах обозначаемую как DesPM (Design Process Manager). DesPM должна включать в себя компоненты: комплексы базовых знаний по тем предметным областям, которые определяются объектом проектирования, а также знаний о языках представления характеристик и ограничений; средства для генерации плана (маршрута проектирования), определения наличия средств и ресурсов для реализации плана; средства выполнения плана; средства оценки результатов. DesPM позволяет выбирать объекты проектирования, производить декомпозицию моделей, для каждого компонента выбирать проектные процедуры из имеющегося набора.
По каждому объекту DesPM выдает сообщения, примерами которых могут быть: “объект проектируется другим разработчиком”, “проектирование преждевременно, не выполнены предшествующие процедуры”, “не подготовлены исходные данные”. Одной из важнейших функций DesPM является помощь в реализации параллельного проектирования. Желательно в DesPM предусмотреть возможности создания “суперпроцедур” — командных файлов для выполнения часто повторяющихся фрагментов маршрутов проектирования.
Расширение возможностей управления проектированием и адаптация системной среды к конкретным САПР связано с применением языков расширения. Язык расширения — это язык программирования, позволяющий адаптировать и настраивать системную среду САПР на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования и командного языка, включать средства процедурного программирования.
Управление процессом проектирования включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей над общим проектом. Управление выполняется на основе моделей вычислительных процессов. Используются спецификации моделей, принятые в CASE-системах, например, диаграммы потоков данных, ориентированные графы. Сначала модели составляют для задачного уровня, а затем система осуществляет их покрытие. Применяют также описания на языках расширения или 4GL. В системной среде Ulyses спецификации даны в виде набора модулей с указанием условий их активизации, что близко к представлению моделей в сис-
темах, управляемых знаниями. Так, каждый проектирующий программный модуль может быть активизирован только в том случае, если входные данные готовы. Для этого специальная программа управления модулями системной среды отслеживает соблюдение отношений следования между проектными операциями и процедурами, заданными в маршруте проектирования. На эту же программу возлагаются функции регулирования прав доступа к модулям, сбор статистики (протоколирование) по обращениям к модулям и некоторые другие.
Необходимо
обеспечение синхронизации
В общем случае полная формализация управления проектированием не может быть достигнута, поэтому полезную роль играют системы поддержки решений, принимаемых людьми, DSS (Decision Support Systems). В качестве таких систем часто используют хранилища данных и OLAP-средства (On-Line Analytical Processing).
Использование хранилищ данных имеет ряд преимуществ в управлении большими объемами данных: имеется единое ядро, что исключает чрезмерно разветвленные и длительные транзакции, легче синхронизировать внесение изменений, поддерживать единство форматов данных, хранить предыдущие версии и т.п.
OLAP-средства
должны обеспечивать
этому
производительность оказывается невысокой.
В специализированных OLAP-системах,
обеспечивающих более быстрый многомерный
анализ, но с более существенными
ограничениями на объем БД, данные хранятся
в виде гиперкубов или поликубов — многомерных
таблиц с постоянным или переменным числом
ячеек соответственно.
Примеры подсистем управления данным и проектированием. В ряде системных сред САПР (прежде всего САПР в машиностроении) в подсистемах PDM объединяются функции управления данными и проектированием. Пример такой PDM — подсистема Design Manager в САПР Euclid Quantum. Функциями этой PDM являются управление потоками проектных данных, версиями проекта, взаимодействием разработчиков, защита информации, конфигурирование и адаптация версий системы для конкретных пользователей.
В
системной среде NELSIS CAD Framework имеются
части: 1) DMS (Design Management Services) для поддержки
иерархии данных, управления версиями
и потоками задач; 2) DMI (Design Management Interface)
с функциями открытия и закрытия баз данных,
вызова и пересылки данных, доступа к DMS;
3) FUS (Framework User Services), включающая ряд браузеров
для визуализации информации.
ЗАКЛЮЧЕНИЕ
Для успешного функционирования и конкурентоспособности промышленных предприятий в современных условиях абсолютно необходимы передовые информационные технологий. Они позволяют не только решать широкий круг задач в сфере автоматизации финансово-хозяйственной и управленческой деятельности, но и осуществлять комплексную автоматизацию основных технологических и производственных бизнес-процессов.
Потребности
современного производства диктуют
необходимость глобального
Эти тенденции позволяют говорить, что уже в самом ближайшем будущем эффективность производства будет во многом определяться эффективностью использования на предприятиях промышленных САПР.
Но
на сегодняшний день уже во многих предприятиях
используется система автоматизированного
проектирования и инженерам, конструкторам,
проектировщикам, архитекторам, работающим
в САПР-программах, необходимо постоянно
повышать свою квалификацию; программы
развиваются, ежегодно появляются новые
версии – соответственно специалистам
необходимо уметь работать в современном
ПО. Иначе САПР используется не на полную
мощь.
Информация о работе Система Автоматизированного Проектирования