Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Лекции по САПР - файл Конспект лекций ПО САПР 2007.doc


Лекции по САПР
скачать (2994.4 kb.)

Доступные файлы (1):

Конспект лекций ПО САПР 2007.doc3785kb.17.04.2007 00:58скачать

содержание

Конспект лекций ПО САПР 2007.doc

  1   2   3   4   5   6
4. МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ

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

Создание ПО САПР - трудная научно-техническая задача, для решения которой требуются большие материальные затраты. Известны САПР, ПО которых насчитывает до 500 тыс. операторов языка программирования. Разработка такого ПО требует сотен и тысяч человеко-лет, причем требования к квалификации разработчиков таких систем очень высоки. Например, в разработке САПР морских судов, оцениваемой в 600 человеко-лет, принимало участие 15 организаций. Стоимость современных САПР определяется главным образом стоимостью ПО, которое в несколько раз превышает стоимость технического обеспечения.

Средняя производительность труда программистов в организациях, занимающихся промышленной разработкой ПО, составляет 1000-2000 операторов в год. В США цена одного оператора программы колеблется в зависимости от степени сложности ПО от 15 до 700 $ ; по данным на 1985 г. один час работы программиста стоит в 5 раз дороже одного часа работы ЭВМ быстродействием 300 тыс. операций/с. Приведенные данные касаются ПО, представляющего собой законченный программный продукт, поставляемый как промышленное изделие. В отличие от программ индивидуального пользования, предназначенных только для обслуживания их разработчика, программный продукт:

1) имеет универсальное назначение, ориентирован на применение многими пользователями и в ряде организаций;

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

3) имеет специальные средства модификации и расширения;

4) всесторонне отлажен;

5) описан в тщательно составленной документации.

Стоимость программного продукта приблизительно в 8-10 раз выше стоимости программы индивидуального назначения и с увеличением его сложности растет по квадратичному закону.

Для оценки сложности ПО используются два основных показателя:

1) количество операторов;

2) количество и типы взаимосвязей компонентов ПО между собой.

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

В САПР можно выделить, по крайней мере, три квалификационные категории пользователей.

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

^ Прикладные программисты имеют высокую квалификацию, знают методологию проектирования, алгоритмы прикладной области и могут разрабатывать специализированное ПО.

Проектировщики – специалисты в области проектирования, хорошо освоившие возможности САПР для выполнения автоматизированного проектирования.

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

7.2. Состав программного обеспечения САПР
Программное обеспечение подразделяют на базовое, общесистемное и специализированное.

^ Базовое ПО не является предметом разработки при создании ПО САПР.

Общесистемное ПО является инвариантным к объектам проектирования.

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

Состав и структура ПО САПР определяются как составом и структурой подсистем САПР, так и САПР в целом.

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



Программные

комплексы

САПР








Инструментальные Проектирующие Обслуживающие








Проблемно- Объектно-

ориентированные ориентированные


Рис. 4.1. Состав программных комплексов САПР


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

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

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

4.4. Основные принципы проектирования ПО САПР
Проектирование ПО САПР осуществляется на основе принципов системного единства, развития, совместимости и стандартизации.

^ Принцип системного единства. При создании, функционировании и развитии ПО САПР связи между компонентами должны обеспечивать ее целостность.

Принцип развития. ПО САПР должно создаваться и функционировать с учетом пополнения, совершенствования и обновления ее компонент.

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

^ Принцип стандартизации. При проектировании ПО САПР необходимо унифицировать, типизировать и стандартизовать ПО, инвариантное к проектируемым объектам.

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

4.5. Стадии разработки ПО
В соответствии с ГОСТ устанавливаются следующие стадии разработки: техническое задание, эскизный, технический проекты, рабочая документация, внедрение.

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

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

Эскизный проект. На стадии эскизного проектирования выполняются следующие виды работ:

внешнее проектирование программного изделия;

уточнение методов решения задачи;

предварительное проектирование внутренних структур данных;

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

Внешнее проектирование программного изделия представляет собой процесс описания ожидаемого поведения системы с точки зрения пользователя. Цель данного процесса – проектирование внешнего взаимодействия пользователя с программным изделием.

При разработке эскизного проекта определяются: способы взаимодействия пользователя с программным изделием; функции пользователей; тип языка взаимодействия; структура и содержание информационных кадров и шаблонов диалога; структура входных и выходных данных.

Технический проект. Этапы технического проектирования: проектирование архитектуры программного изделия; структур данных; модульной структуры изделия; модулей; разработка пояснительной записки.

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

На этапе проектирования структур данных определяют способы представления, хранения и преобразования входных, выходных и внутренних данных.

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

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

Рабочая документация. На данной стадии выполняются следующие виды работ: кодирование, тестирование и отладка программ; разработка программных документов в соответствии с ЕСПД; проведение различных видов приемо-сдаточных испытаний; корректировка программ и документации по результатам испытаний.

Стадия внедрения. На стадии внедрения осуществляется подготовка и передача программ и программной документации для сопровождения.
4.6. Общая характеристика методов проектирования программного

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

4.6.1. Методы проектирования программных систем
В 60-70-е годы эффективность применения компьютеров резко возросла. В результате стало выгодно создавать все больше прикладных программ повышенной сложности. В качестве основных инструментов создания программных продуктов начали применяться алгоритмические языки высокого уровня. Эти языки расширили возможности отдельных программистов и групп разработчиков, что в свою очередь привело к увеличению уровня сложности программных систем. В эти годы было разработано много методов, помогающих справиться с растущей сложностью программ. Наибольшее распространение получило структурное проектирование по методу сверху-вниз, или комбинированный метод. Он был непосредственно основан на топологии языков высокого уровня типа FORTRAN и COBOL. В этих языках основной базовой единицей является подпрограмма, и программа в целом принимает форму дерева, в котором одни подпрограммы в процессе работы вызывают другие подпрограммы. Структурное программирование использует именно такой подход: алгоритмическая декомпозиция применяется для разбиения большой задачи на маленькие.

Способ управления сложными системами был известен еще в древности: divide et impera (разделяй и властвуй). При проектировании сложной программной системы необходимо составлять ее из небольших подсистем, каждую из которых можно отладить независимо от других. В этом случае мы не выходим за пределы возможностей человека, отпущенных ему природой: при разработке любого уровня системы нам нужно будет одновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех!).

Начиная с 60-70-х годов стали появляться компьютеры еще больших возможностей. Значение структурного подхода осталось прежним, но оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100 000 строк. В последнее время появились десятки методов, в большинстве которых устранены очевидные недостатки структурного проектирования.

В настоящее время методы проектирования можно разделить на три основные группы:

  • метод структурного проектирования “сверху-вниз”;

  • метод организации потоков данных;

  • объектно-ориентированное проектирование.

Примеры методов структурного проектирования приведены в работах Йордана и Константина (Yourdon E. and Constantine), Вирта (Wirth N.), Даля, Дейкстры и Хоара (Dahl O., Dijkstra E.W., and Hoare C. A. R.) и др. В каждом из этих подходов присутствует алгоритмическая декомпозиция. Следует отметить, что большинство существующих программ написано в соответствии с одним из этих методов. Тем не менее структурный подход не позволяет выделять абстракции и обеспечивать защиту доступа к данным, не представляет он также достаточных средств для организации параллелизма. Структурный подход не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен при использовании объектно-ориен­тированных языков программирования.

Метод организации потоков данных полнее всего описан в работе Джексона (Jackson M.), а также Уорниера и Орра (Orr K.). В этом методе структура программной системы строится как организация преобразований входных потоков в выходные. Метод организации потоков данных, как и структурный метод, с успехом применялся при решении ряда сложных задач, в частности, в системах информационного обеспечения, где существуют прямые связи между входными и выходными потоками системы и где не требуется уделять много внимания быстродействию.

В основе объектно-ориентированного проектирования (OOD) лежит представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы при этом образуют иерархию. Объектно-ориентированный подход отражает топологию новых языков высокого уровня, таких, как Smalltalk, Object Pascal, C++ и Ada.


^ 4.6.2. Методы программирования ПО САПР
Материалы, полученные на стадии технического проекта программы, являются основой для выполнения последующих этапов программирования, а также отладки и испытаний программ САПР, которые составляют содержание стадии рабочего проекта ПО САПР.

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

Этап испытаний программ завершает стадию рабочего проекта программного обеспечения. На этом этапе продолжается проверка программ с целью получения официального подтверждения пригодности программы для использования в составе САПР.

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

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

  • программирование с защитой от ошибок (разработка программ, включающих дополнительные проверки входных и промежуточных данных на полноту, допустимость и правдоподобность получаемых значений);

  • структурное программирование;

  • программирование в стандартизованном стиле (разработка программ, оформление исходных текстов которых выполняются по единым для всех участников разработки правилам);

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



^ 4.6.3. Модульное и структурное программирование. Программирование

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

Концепция модульного программирования, выдвинутая еще в середине 50-х годов (ассемблеры, FORTRAN), подверглась сильным изменениям в 70-е годы. Первоначально ставилась задача выделения относительно независимых фрагментов программ с целью организации разделения работ, повторного использования этих фрагментов в программе, уменьшения затрат на повторную компиляцию и преодоление ограничений на размеры компилируемых программ.

Современная концепция модульного проектирования включает в себя следующие положения:

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

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

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

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

Преимущества модульного принципа программирования состоят в следующем.

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

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

- имеют модульную структуру;

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

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

- использование глобальных переменных ограничено.

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

И м я м о д у л я. Имя модуля используется другими модулями для обращения к нему.

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

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

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

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

В н е ш н и е э ф ф е к т ы. Дается описание внешних эффектов для программы или системы событий, происходящих при работе модуля.

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

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

Комментарии по своему назначению могут быть вводными и пояснительными. Вводные комментарии помогают понять назначение, интерфейсы и ограничения, накладываемые на программу. Они представляют собой внешнюю спецификацию, встроенную в исходный текст программы. Пример одной из возможных форм вводного комментария приведен ниже.
//****************************** C text file ************************

// Имя функции: in_hex

// Файл : in_hex.c

// Назначение: Модуль ввода табличных исходных данных для

// программ конструктивного расчета теплообменника

// Метод :

// Параметры:

// Входные данные:

// Выходные данные:

// Используемые функции:

// Автор :

// Дата :

// Модификации:

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

Большую роль при программировании имеет правильное присвоение имен данным, файлам, функциям. Имена должны отражать сущность описываемых с их помощью объектов. Рекомендуемая длина идентификаторов составляет 5-10 символов.

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

1. Использовать пробелы для выделения составных частей операторов.

2. Не следует располагать на одной строке программы более одного оператора. Это облегчает чтение текста, поиск и удаление ошибок, модификацию программы;

3. Необходимо использовать отступы для выявления составных и вложен­ных операторов.

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

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

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

В стандартах ЕСПД установлены требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что дает возможность унификации программных изделий для взаимного обмена программами; снижения трудоемкости и повышения эффективности разработки, сопровождения и эксплуатации программных изделий; автоматизации изготовления и хранения программной документации.

  1   2   3   4   5   6



Скачать файл (2994.4 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации