Глава 20. Программное обеспечение систем автоматизированного проектирования электроприводов

20.1. Программные характеристики сапр

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

При разработке ПО САПР используют результаты:

1. разработки математического обеспечения;

2. разработки лингвистического обеспечения;

3. разработки методического обеспечения.

Рис. 1. Фундамент для разработки ПО САПР

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

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

В отличие от программ индивидуального пользования, предназначенных только для обслуживания их разработчика, программный продукт САПР имеет универсальное назначение, ориентирован на применение многими пользователями и в ряде организаций и предназначен для работы в комплексе с другими компонентами программного обеспечения. Программное обеспечение САПР имеет специальные средства модификации и расширения, всесторонне отлажено и описано в тщательно составленной документации. Стоимость программного продукта (ПП) приблизительно в 8-10 раз выше стоимости программы индивидуального назначения и с увеличением его сложности растет по квадратичному закону в зависимости от объема (ПП).

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

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

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

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

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

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

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

20.2. Состав программного обеспечения САПР

Программное обеспечение САПР подразделяют на:

Базовое;

Общесистемное;

специализированное.

Рис. 2. Состав программного обеспечения САПР

Рис. 3. Классификация программного обеспечения САПР

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

Рис. 4. Состав прикладного программного обеспечения САПР

Рис. 5. Элементы прикладного программного обеспечения САПР

Рис. 6. Состав базового программного обеспечения САПР

Рис. 7. Составные части операционной системы базового программного обеспечения САПР

Рис. 8. Составные части «дружественного» интерфейса базового программного обеспечения САПР

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

программных компонент;

информационных компонент;

методических компонент;

математических компонент;

лингвистических компонент.

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

проектирующие;

обслуживающие;

инструментальные.

Рис. 9. Программные комплексы программного обеспечения САПР

Проектирующие ПК предназначены для получения законченного проектного решения и в свою очередь делятся:

на проблемно-ориентированные;

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

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

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

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

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

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

20.3. Основные принципы проектирования ПО САПР

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

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

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

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

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

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

20.4. Стадии разработки ПО САПР

В соответствии с ГОСТ устанавливаются следующие стадии разработки:

разработка технического задания;

эскизный проект;

технический проекты;

рабочая документация;

внедрение.

На стадии технического задания выполняются следующие виды работ:

постановка задачи;

сбор исходных материалов;

выбор и обоснование критериев эффективности и качества разрабатываемой программы;

обоснование целесообразности применения ранее разработанных программ,

оценка принципиальной возможности решения поставленной задачи;

предварительный выбор методов решения задач;

определение требований к техническим средствам;

определение требований и целей разработки программ;

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

согласование и утверждение ТЗ.

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

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

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

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

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

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

При разработке эскизного проекта определяются:

способы взаимодействия пользователя с программным изделием;

функции пользователей;

тип языка взаимодействия;

структура и содержание информационных кадров и шаблонов диалога;

структура входных и выходных данных.

Этапы технического проектирования состоят из:

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

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

проектирование модульной структуры ПО;

проектирование модулей ПО;

разработка пояснительной записки.

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

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

способы представления;

хранения;

преобразования;

входных, выходных и внутренних данных.

На этапе проектирования модульной структуры осуществляется:

разбиение компонент программного изделия на модули,

определение их функции и

способов взаимодействия.

На этапе проектирования модулей составляется:

описание всех модулей программного изделия, которое включает в себя:

имя модуля;

функции, выполняемые модулем;

описание входных и выходных параметров, диапазонов допустимых значений и т.п.;

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

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

описание формы обращения к модулю;

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

На данной стадии рабочей документации выполняются следующие виды работ:

кодирование, тестирование и отладка программ;

разработка программных документов в соответствии с ЕСПД;

проведение различных видов приемо-сдаточных испытаний;

корректировка программ и документации по результатам испытаний.

20.5. Проектирование программного обеспечения САПР

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

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

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

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

Значение структурного подхода осталось велико, но оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100 000 строк. Появились десятки методов, в большинстве которых устранены очевидные недостатки структурного проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20.6. Модульное программирование ПО САПР

Модульное программирование ПО САПР позволяет осуществить программирование в стандартизованном стиле. Многие системы программирования строятся в расчете на модульное программирование. Концепция модульного программирования, выдвинутая еще в середине 50-х годов (ассемблеры, FORTRAN), подверглась сильным изменениям в 70-е годы.

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

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

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

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

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

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

20.7. Виды связей модулей ПО САПР

Различают связи модулей:

1. по управлению;

2. по информации;

3. по размещению;

4. по по воздействию.

Рис. 11. Связи равноуровневых по иерархии модулей ПО САПР по управлению

Рис. 12. Связи модулей ПО САПР разного уровня иерархии по управлению

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

20.8. Структурное программирование ПО САПР

Программы, разработанные по правилам структурного программирования, обладают следующими свойствами:

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

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

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

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

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

Внешняя спецификация должна включать:

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

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

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

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

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

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

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

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

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

ГЛАВА 21. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ЭЛЕКТРОПРИВОДОВ