Добавить в цитаты Настройки чтения

Страница 4 из 5



Базовые ПМК предназначены для проектирования объектов определенного класса (например, редактирование топологии БИС, проектирование маршрута обработки деталей) и делятся на два класса: объектно-ориентированные и проблемно-ориентированные.

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

Объектно-ориентированные базовые ПМК являются наиболее многочисленным типом продукции при разработке САПР. Они обеспечивают проектирование классов (видов) объектов. Потенциально для каждого вида деталей и сборочных единиц классификатора ЕСКД можно разработать объектно-ориентированный базовый ПМК. В табл. 1.1 приведён примерный состав ПМК САПР БИС.

Таблица 1.1

1.8. Организация разработки программного обеспечения САПР

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

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

Углублённая специализация труда разработчиков ПИО дает положительный эффект только при её умелом использовании. Известна зависимость (рис. 1.8) эффективности Э умственного труда от глубины его разделения Р.

Рис. 1.8. Зависимость эффективности умственного труда от глубины его разделения

Из графика видно, что очень узкая специализация (мелкое разделение работ), приводит к дополнительным затратам и снижению её эффективности.

Эффективность труда без специализации исполнителей определяется величиной Эmin. С ростом разделения труда эта величина растет до Эmax при оптимальном разделении Ро, после чего при дальнейшем углублении специализации падает.

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

• алгоритмисты – обеспечение принципиальной реализуемости и концептуальной целостности системы, а также разработка алгоритмов математического обеспечения;

• программисты – разработка и отладка программ;

• отладчики – генерация тестов и проверка системы;



• технологи – изготовление и обеспечение эффективной работы инструментального программного обеспечения;

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

• документологи – контроль документирования системы, редактирование и выпуск программной документации;

• интерологи – обеспечение проведения опытной эксплуатации и тиражирования системы.

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

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

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

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

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

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

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

Аналогично проектированию ПИО кодирование и отладка также реализуются по методу «сверху–вниз». При этом кодируются и отлаживаются программные модули от высшего уровня иерархии до низшего уровня. В этом случае пользователь может заранее оценить результат их работы и ввести необходимые коррективы. Кроме того, этот метод с самого начала позволяет гарантировать работоспособность наиболее ответственной части ПИО.

Следует иметь в виду, что в процессе разработки программы отладка занимает обычно (50–90)% времени. Это зависит от сложности алгоритма, используемого языка программирования, ЭВМ и операционной системы с имеющимися средствами отладки. После завершения отладки программ формируется эксплуатационная документация и документация сопровождения. Правила оформления программной документации регламентируются государственными стандартами, входящими в состав Единой системы программной документации.

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