Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
САПР ТП_Лекции_2008.doc
Скачиваний:
58
Добавлен:
24.09.2019
Размер:
15.98 Mб
Скачать

8.2. Специальное программное обеспечение

Специальное ПО реализует алгоритмы для выполнения проектных операций и процедур. Программы специального ПО в САПР группируются в пакеты прикладных программ (ППП). Каждый ППП ориентирован на обслуживание задач отдельной подсистемы САПР и характеризуется определенной специализацией. Поэтому функции ППП конкретной подсистемы тесно связаны с перечнем задач, реализуемых на соответствующем уровне проектирования.

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

В специальное ПО наряду с ППП, разрабатываемым человеком при создании САПР, входят и рабочие программы, составляемые автоматически в ЭВМ для каждого нового объекта и маршрута его проектирования. Рабочие программы составляются из библиотечных и генерируемых модулей. Библиотечные модули реализуют математические модели элементов, типовые методы и алгоритмы, применяемые при решении задач проектирования многих объектов. Генерируемые модули реализуют математическую модель системы и являются результатом трансляции с входного языка.

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

Методом компиляции каждая арифметическая операция вычислительного процесса в рабочей программе преобразуется в ряд отдельных команд. При компиляции этапы трансляции и счета четко разделены и полученная рабочая программа линейна, т. е. состоит из команд, перерабатывающих информацию, без каких-либо служебных команд типа передач управления, организации циклов и т. д. Скомпилированные программы экономичны по затратам машинного времени (не имеют никаких дополнительных служебных команд), но требуют значительных затрат машинной памяти (каждой операции соответствует ряд команд, занимающих несколько ячеек памяти).Метод интерпретации подразумевает, что рабочая программа не создается в окончательном виде до начала этапа счета: она будет генерироваться по частям при переходе от исполнения предыдущей директивы входящего языка к последующей. При этом затраты машинного времени возрастают (в итерационном вычислительном процессе приходится многократно повторять выполнение одних и тех же вспомогательных команд, генерирующих часта рабочей программы), но сокращаются затраты машинной памяти (не нужно хранить всю скомпилированную рабочую программу). На практике чаще всего используют элементы обоих методов генерации рабочих программ. Чем выше частота использования программ (это характерно для программ самых низких уровней), тем более обоснованным будет применение метода компиляции. Метод интерпретации преобладает при генерировании программ более высоких уровней, он является основным при реализации диалогового режима САПР.

8.3. Модульный принцип построения ппп

Под модулем понимается генерируемая или библиотечная программа либо ее часть, способная входить в сочетания с другими модулями как самостоятельный элемент. Так, модулем может быть программа проектирования операции механической обработки. Но возможно оформление в качестве самостоятельных модулей отдельных фрагментов этой программы, например выбор станка, проектирование перехода, расчет оптимальных режимов резания. Модули могут быть расширены, заменены, изъяты. При создании САПР или ее подсистем невозможно точно указать строго определенное количество модулей и их функциональную роль. Состав модулей определяется рядом факторов: методикой разработки САПР; выбранным методом решения разработанных алгоритмов; типом ЭВМ и используемым периферийным оборудованием; возможностями операционной системы; базовым алгоритмическим языком, служащим для реализации алгоритмов. В целях упрощения согласования модулей в ППП целесообразно выполнять крупномодульное построение программ. В то же время следует отметить, что мелкомодульное построение открывает возможности получения большего числа их сочетаний - это расширяет возможности проблемного ППП. Кроме того, разработка и замена малого модуля осуществляется быстрее и дешевле, чем крупного. Поэтому целесообразно в каждом конкретном случае искать компромисс решения вопроса о размерах и количестве модулей, сопрягаемых друг с другом в различных сочетаниях. Важным направлением в разработке программного обеспечения является стандартизация правил оформления модулей, которая обеспечивает: единообразие оформления программной документации САПР разработчиков; информационную и программную совместимость модулей; унификацию и развитие программного обеспечения; обмен модулями между разработчиками.

В настоящее время разработаны правила составления документации на модуль, которая включает: название модуля; назначение и область применения; формулировку задачи; метод решения; алгоритм решения; паспорт модуля; текст программы; сведения о программе; контрольный (тестовый) пример; литературу.

Формулировка задачи определяет конструкторскую или технологическую сущность решаемой задачи с использованием чертежей, схем или графиков. В этот раздел включаются также математическая формулировка задачи (например, с применением теории графов и математической логики), описание входных и выходных данных, технические ограничения и целевые функции.

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

Построение ППП по модульному принципу имеет ряд преимуществ:

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

  • при более детальном расчленении можно сэкономить время трансляции;

  • в расчлененном виде сложные логические связи более наглядны;

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

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