Содержание к диссертации
Введение
Глава I. Анализ принпипов разработки и функционирования САПР 12
1.1. Основные концепции автоматизации проектирования 13
1.2. Анализ отечественных и зарубежных САПР 30
1.3. Совершенствование САПР в направлении разработки базы данных 53
Выводы по главе 73
Глава 2. Методологические вопросы разработки базы данных САПР 75
2.1. Формальное, описание модели 76
2.2. Синтез логических структур САПР . 93
2.3. Опенка структуры САПР 109
2.4. Выбор СУБД в качестве средства проектирования ЕД 124
Выводы по главе 137
Глава 3. Реализация принципов построения и особенности функционирования базы данных САПР 140
3.1. Основные концепции системы ТЕЛЕСИОД . 141
3.2. Построение САПР 157
3.3. Оптимизация технологии функционирования САПР 171
Выводы по главе 197
Заключение 200
Литература
- Анализ отечественных и зарубежных САПР
- Совершенствование САПР в направлении разработки базы данных
- Синтез логических структур САПР
- Оптимизация технологии функционирования САПР
Анализ отечественных и зарубежных САПР
Анализ отечественных и зарубежных САПР За последние годы у нас в стране и за рубежом получили интенсивное развитие работы по созданию методов и средств совершенствования процесса проектирования АСУ, повышению производительности труда проектировщиков. В основу систем проектирования положены раяличные архитектурные принципы построения, каждая из систем воплощает определенный подход к организации проектных работ, обладает разными эксплуатационными характеристиками. В приложении I приведены некоторые примеры современных САПР.
В условиях интенсификации работ по производственному применению САПР представляется актуальным анализ принципов разработки, построения, функциональных возможностей и других качественных свойств с целью выбора систем для заданной предметной области проектирования и определения путей их совершенствования.
Следуя классификации /106/, современные САПР делятся на два класса: системы, в основе которых лежат методы типового проектирования, и системы, основанные на модельных методах.
К первому классу можно отнести такие отечественные разработки, как ТПР /элементное проектирование/, САПИО и ИСУП /подсистемное проектирование/, АСУ "Сигма", САО, ШО "Проблема" /объектное проектирование/ и ряд других оистем.
Модельные методы базируются на некоторой модели, отображающей предметную область. Модель является основным источником информации для выполнения проектных работ. К настоящему моменту наиболее характерными представителями этого направления являются такие отечественные системы, как МАРС и АРИУС.
Технология функционирования системы ТПР /25, 109, НО/ заключается в разбиении проектируемой АСУ" на множество типовых элементов. Системный анализ объекта управления при данном подходе ограничивается уровнем номенклатуры входных параметров типовых программных модулей. Поэтому недостаточно учитываются индивидуальные свойства объекта, порождающие требования к системе обработки информации и технологии ее проектирования, нет системного накопления данных об изменяющихся условиях функционирования объекта управления, В связи с этим становится затруднительным перенесение реализованных проектных решений с уровней, предшествующих созданию программного обеспечения, что в свою очередь затрудняет использование накопленного опыта при проектировании АСУ для родственных предприятий.
Основным достоинством системы ТПР является возможность создания библиотеки типовых проектных решений и описание проектируемой системы в виде задания списков параметров ее подсистем,
К недостаткам системы, как впрочем и данного подхода, можно отнести следующие: - отсутствие единой информационной базы и вследствие этого информационной увязки по всей системе в целом ; - отсутствие комплексного решения по структурированию данных ; - необходимость разработки оригинальных решений по отдельным элементам и задачам ; - отсутствие единой идеологии построения программ по всем функциональным задачам ; - слабая информационная увязка типовых конструктивных элементов и др. ТПР - технология была использована как средство автоматизации проектировочных работ при разработке ИО для
АСУ ряда машиностроительных предприятий /105, 106/. Учитывая, однако, что Ир являетоя нестабильной системой с большим числом возмущений, все достоинства ТПР-технологии превратились в недостатки. Подобные разработки лишены необходимых, на наш взгляд, свойств адаптации к конкретным условиям функционирования. Отсутствие свойства самоорганизации, присущего системам с интегрированной ВД, как показывает опыт, требует доработка типовых элементов по всем подсистемам до 40$.
Совершенствование САПР в направлении разработки базы данных
Эффективность взаимодействия проектировщиков с САПР в значительной степени зависит от особенностей построения подсистемы ИО, т.е. от возможностей и способов накопления информации, обеспечивающей процесс проектирования, наличия средств ее обработки, возможности обслуживания разнообразных запросов разработчиков, реализации нескольких стратегий поиска необходимых данных и т.д.
При создании САПР важно определить, в систему какого рода объединить данные. Это могут быть файловые системы, либо данные организуются по принципу БнД. Рассмотрим оба подхода. При организации данных в виде файлов возникает три проблемы /140/.
Во-первых, налицо высокий уровень избыточности. Один и тот же тип элемента данных хранится во многих разных местах. Различные версии одинаковых элементов данных могут оказаться на разных стадиях обновления. Другими словами, они имеют различные значения. Пользователи могут воспринять это как несоответствие. При наличии многочисленных и отличающихся копий одного и того же элемента данных трудно поддерживать согласованность или обеспечить целостность элементов данных.
Во-вторых, система файлов является негибкой. Нельзя быстро ответить на запросы информации, для которой нужны элементы данных из многочисленных или по-разному структурированных файлов. Несмотря на то, что данные существуют, трудно представить взаимосвязанную с ними информацию. При введении новых способов обработки данных требуется переструктуризация.
В-третьих, внесение изменений в систему файлов может оказаться трудоемким и дорогостоящим делом. Очевидно, что незначительное изменение в файловой среде вызывает цепную реакцию других, подлежащих внесению изменений. Модификацию файловой системы трудно провести еще и потому, что данные каждого пользователя документированы неадекватно. Со временем эта проблема еще более обостряется из-за количественного роста создаваемых программ.
Требования общего управления, совместного использования многочисленными потребителями на основе широкой интеграции данных приводят к выводу о необходимости построения подсистемы ИО САПР на основе банка данных /БнД/.
Понятие "банк данных" появилось в литературе в середине 60-х годов и к настоящему времени стало широко использоваться в самых различных сферах, особенно в области обработки экономической информации. Завоевав право на существование, это понятие, однако из-за своей емкости и универсальности до сих пор еще не получило однозначного смыслового содержания, что, естественно, вносит известный разнобой в его толкование.
Такое положение объясняется тем, что основные компоненты банка данных - база данных и система управления базой данных - рассматривались изолированно друг от друга. Тем не менее, ряд авторов /18, 22, 45, 77. 84, 107/ единодушны в опрелелении банка данных и понимают под ним "систему организации, ведение и хранение интегрированной информации, расположенной на машинных носителях и предназначенной для комплексного многоцелевого использования, вместе со спепиальными программами, организационными и техническими средствами его ведения".
В 100, например, при определении БнД особый акцент делается на способ доступа к данным и реализацию диалога между базой данных и рядом независимых пользователей.
Анализ современной литературы, поовященной разработке и применению банков данных показывает, что в структурном отношении БнД состоит из следующих элементов: I/ базы данных ; 2/ системы управления базой данных ; 3/ программ пользователей для решения конкретных задач.
Рассмотрим существующие определения ВД и СУЩ.
Следуя терминологии, предложенной КОЛА CU/1 Ассоциацией по языкам систем обработки данных, - под ВД подразумевается "совокупность записей различного типа, содержащая перекрестные ссылки" /132/.
Развивая это понятие, авторы в /51, 56, 68, 76, 78,90/ определяют ВД как "взаимосвязанную совокупность данных определенным образом организованных, хранимых на устройствах прямого доступа и иопользуемых в качестве исходной информации для решения задач". Дж. Мартин в /77/, давая определение ВД, подчеркивает такой важный ее принцип как "минимальная избыточность хранящихся данных, которая допускает их использование оптимальным образом для одного или нескольких приложений". Автор далее отмечает независимость данных ВД от программ пользователей, использование единой для всех данных систем управления, а также необходимость структурирования данных таким образом, чтобы была обеспечена возможность их дальнейшего наращивания.
Синтез логических структур САПР
Синтез логических структур Щ САПР Разработка модели Щ САПР заканчивается определением состава показателей Щ, отвечающих требованиям сформулированным выше. На следующем этапе проектировщиками требуется решать такие вопросы: как информационные концепции инфологи-ческой модели будут преобразованы в конкретные элементы данных ; в структуру какого типа - сетевого, иерархического, реляционного - должны быть сформированы данные элементы ; как на выбранной структуре скажутся ограничения, накладываемые конкретной СУЩ. Наконец, необходимо оценить структуру с точки зрения выбранных критериев, и если эта оценка дала неудовлетворительные результаты, надо иметь возможность целенаправленно изменить структуру.
Реализация этапов описания предметной области приводит к установлению множества истинных значений элементов /множество F / и определению временной связи между элементами этого множества /установление т - элементов/.
Формальный подход к анализу свойств у -элвментов, отношений между ними на логическом уровне рассмотрен автором в /62, 63/. Проведенный анализ качественного их состава в моделе Щ позволил определить все возможные структуры организации массивов. Основными были выделены три, это: а/ однотипный массив информации ( I j , б/ одноименный массив информации ( I ) ї в/ однородный массив информации (I J 1 - представляет собой наиболее общую структуру ижгзорма тР тп ции на данном этапе проектирования Щ. 1 и 1 являют ся частными случаями 1
Согласно теории механизированной обработки экономической информации /68/ под понятием показатель понимается элементарное экономическое сообщение, состоящее из одного реквизита - основания и совокупности определяющих его реквизитов . - признаков. Рассматривая с точки зрения модели БД реквизит как элементарное экономическое данное, заметим, что ему идентичен 4 -элемент, а совокупность 4 -элемента и полного сообщения, образующие информационный элемент /ИЭ/ /64/, идентичны понятию показатель.
Для синтеза первоначального варианта структуры данных модели Щ установим все возможные типы связей между элементами и полными сообщениями.
Простая связь /тип Р / - указывает отношение между двумя / - элементами. Данная связь определяется только в одном направлении. Например, связь /номер детали, цена детали/ является простой связью, если данная деталь имеет только одну цену /см. рис. 2.2 /а/.
Сложная связь /тип С / - указывает отношение между элементами, когда один 4 -элемент может соотноситься с двумя и более f -элементами. Например, связь /номер детали, номер узла/ является сложной, если деталь может входить в несколько узлов /см. рис. 2.2 /б/.
Многозначная связь /тип - М/ - указывает, что между парой f -элементов существует более одной связи. Например: связь между первым 0 -элементом /номер детали/ и вторым jh -элементом /поставщик/ может быть описана с помощью указателя "назначение", который принимает следующие значения /см. рис. 2.2 /в/.
Необходимая связь /тип Ж / - обеспечивает единственный путь между двумя -элементами и является частным случаем связи типа Р. Например, дана запись
Если между двумя f -элементами существует траектория необходимых связей, то всегда можно указать подразумеваемую связь /тип & /. Так для записи А: /#—«#, Sl—I {, К і—-Pi есть траектория необходимых связей, то связь А//—-Р/ является подразумеваемой связью. Аналогично A/4- Ki, Si— /i есть примеры подразумеваемой СЕЯЗИ В записи А.
Для каждого типа связи /Р, С, М, N к / может быть определена противоположная связь. Однако, если прямая связь является простой /Р/, то противоположная связь может оказаться сложной /С/. Установленного соответствия не существует ; поэтому любая связь может быть названа прямой, а другая станет противоположной. Связь и ее противоположное значение -есть отношение и записывается в виде Д : У/, где X - вид прямой связи, а У - ЕИД противоположной.
Часто целесообразно определять взаимосвязи между данными с помощью односторонних связей, описанных выше, а иногда с помощью отображений , которые описывают двусторонние связи. Процесс структурирования данных должен учитывать эту особенность. Покажем описание двусторонних связей на примере полных сообщений.
Оптимизация технологии функционирования САПР
Необходимо отметить, что структура записи каталога не соответствует структуре печатаемой информации. Запиоь каталога содержит коды, по которым-из справочных таблиц выбирается необходимая информация и по запросу выдается пользователю. Отсутствие какой-либо информации в записи кодируется определенным образом, а при выдаче пользователю соответствующие графы заполнены пробелами.
Организация каталога рассчитана на пользователя как специалиста в области систем управления базами данных, так и пользователя, не знакомого с аппаратом СУЩ. Поэтому для последних в каталоге предусмотрены средства, позволяющие расширить круг сведений о тех или иных аспектах использования СУЩ. К таким сведениям относятся: - трудоемкость реализации основных программных комплексов проектирования Щ; - стоимостные затраты на ведение /обслуживание/ Щ; - технические характеристики и основные параметры периферийных уотройств ; - прогнозируемые временные опенки по основным видам обработки данных конкретной СУЩ; - трудоемкость обучения обслуживающего персонала ; - возможность совмещения рассматриваемой системы с уже сложившимися на объекте программными реализациями и ряд других.
Если В результате полученных оведений пользователь делает вывод о невозможности выбора ни одной СУЩ из каталога для конкретного приложения, то /в особых случаях/ рассматривается вопрос либо о создании новой СУЩ, ориентированной на решение данной проблемы, либо о доработке наиболее предпочтительной системы, т.е. о создании новой программной среды ее функционирования.
Основная трудность при создании каталога состоит в том, что большинство СУЩ разрабатывалось независимо друг от друга, в них используется уникальная терминология: в документации, как правило, для изложения даже идентичных концепций применяется разная методика. В результате этого сравнительно трудно увидеть общее у рассматриваемых СУЩ, оценить различия между ними, а следовательно, и отразить это в множестве граф записей каталога.
В отечественной и зарубежной литературе ряд работ /51, 92, 126, 132/ посвящен систематизации подхода к СУЩ, предложена терминология и описаны основные общие концепции систем. В основу состава граф каталога легли наборы факторов, по которым в настоящее время классифицируются современные СУЩ /приложения 2,3/.
Рассматривая организацию каталога в рамках М-П подхода к проектированию Щ, весьма актуальной становится задача автоматизации процессе выбора СУЩ в качестве средства проектирования или, в случав затруднений, выработке рекомендаций - Факторов, которые помогут пользователю решить дилемму: создания новой СУЩ или доработки одной из уже разработанных.
В работах /70, 115/ решается проблема рационального выбора СУШ на основе многошаговой процедуры, заключающейся в анализе множества альтернатив А /требований к СУЩ/, выделения подмножества В из множества СУЩ, предъявляемых к выбору, которые наиболее соответствуют заданным требованиям. Если такая система найдена, процесс выбора заканчивается, если нет - сужается число альтернатив на основе системы отношений предпочтения и процесс повторяется снова.
Определенное за некоторое число шагов подмножество В Есегда обеспечивает древовидную структуру процесса выбора СУЩ, и приводит к непустому выбору, т.е. исключает ситуация выбора несуществующей сиотемы.
Такой подход к выбору СУЩ, на наш взгляд, наиболее оптимальным споообом решает проблему анализа факторов, организованных в качестве основных. Однако, сужение /сокращение/ требований, укрупнение или выделение из них наиболее главных, значимых приводит к некоторому "обезличива, -нию" конкретных систем и даже ликвидации их характерных свойств.
В настоящее время разработано более тысячи СУЩ /143/ и каждая обладает совокупностью только ей присущих особенностей. Более эффективным, нам кажется, будет не усечение требований, а, наоборот, подробная детализация свойств систем и на их основе установление взаимно однозначного соот ЕЄТСТВИЯ между набором факторов /требований/ и развернутым списком параметров СУБД.
Проведению процедуры выбора должно предшествовать ознакомление пользователя-неспециалиста с наиболее общими характеристиками систем, что позволит ограничить введение совершенно неприемлемых требований. Данная задача решается на основе организации справочных таблиц, информация которых последовательно вводит в круг специфических проблем: терминология, сферу применения, примеры конкретных систем и т.д.
Для описания предлагаемой процедуры необходимо ЕЕЄСТИ некоторые обозначения. Пусть имеется множество объектов /СУЩ/ Р s Рр Р2, ..., Рп_х» Рп» хранящихся в каталоге, каждый из которых характеризуется несколькими наборами свойств /факторов/ У = JQ 7V, А Множество Q= {ch, ...,QK) представляет совокупность общих характеристик, множество V= ( ,...,} совокупность основных характеристик, а множество Д s сч,..., JJ- совокупность дополнительных /второстепенных/ характеристик СУШ каталога.
