3.2.8.Программные средства управления проектированием в сапр

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

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

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

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

4. проблемный; пользователь формулирует задания в форме "что нужно сделать", а не "как это сделать", т.е. не определяет маршрут проектирования, а ставит проектную проблему.

В системных средах САПР управление проектированием возлагается на подсистему САРЕ, в не­которых системах обозначаемую как DesPM (Design Process Manager). DesPM должна включать в себя компоненты: комплексы базовых знаний по тем предметным областям, которые определяются объ­ектом проектирования, а также знаний о языках представления характеристик и ограничений; средст­ва для генерации плана (маршрута проектирования), определения наличия средств и ресурсов для ре­ализации плана; средства выполнения плана; средства оценки результатов. DesPM позволяет выбирать объекты проектирования, производить декомпозицию моделей, для каждого компонента выби­рать проектные процедуры из имеющегося набора.

По каждому объекту DesPM выдает сообщения, примерами которых могут быть: "объект проек­тируется другим разработчиком", "проектирование преждевременно, не выполнены предшествующие процедуры", "не подготовлены исходные данные". Одной из важнейших функций DesPM является по­мощь в реализации параллельного проектирования. Желательно в DesPM предусмотреть возможнос­ти создания "суперпроцедур" – командных файлов для выполнения часто повторяющихся фрагмен­тов маршрутов проектирования.

Расширение возможностей управления проектированием и адаптация системной среды к кон­кретным САПР связано с применением языков расширения. Язык расширения – это язык програм­мирования, позволяющий адаптировать и настраивать системную среду САПР на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной сре­ды, объединять возможности базового языка программирования и командного языка, включать сред­ства процедурного программирования. Для большинства языков расширения базовыми являются ЛИСП или С.

Так, язык Skill из Design Framework-2 фирмы Cadence или язык CCL (CASE Comment Language) фирмы Matra Datavision являются ЛИСП-подобными, а язык AMPLE из Falcon Framework фирмы Mentor Graphics базируется на языках С и ПАСКАЛЬ.

Управление процессом проектирования включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей над общим проектом. Управление вы­полняется на основе моделей вычислительных процессов. Используются спецификации моделей, принятые в CASE-системах, например, диаграммы потоков данных, ориентированные графы. Снача­ла модели составляют для задачного уровня, а затем система осуществляет их покрытие. Применяют также описания на языках расширения или 4GL. В системной среде Ulyses спецификации даны в ви­де набора модулей с указанием условий их активизации, что близко к представлению моделей в сис­темах, управляемых знаниями. Так, каждый проектирующий программный модуль может быть акти­визирован только в том случае, если входные данные готовы. Для этого специальная программа уп­равления модулями системной среды отслеживает соблюдение отношений следования между проектными операциями и процедурами, заданными в маршруте проектирования. На эту же программу воз­лагаются функции регулирования прав доступа к модулям, сбор статистики (протоколирование) по обращениям к модулям и некоторые другие.

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

Примером подсистемы управления проектированием в САПР СБИС может служить Minerva, разработанная специ­алистами университета Карнеги-Меллона (США). В ней реализуется нисходящее проектирование на основе модели в ви­де И-ИЛИ-дерева. Дерево может быть не полностью определено к началу проектирования и его отдельные кусты дораба­тываются в процессе проектирования. На каждом ярусе дерева происходит выбор альтернатив, формирование ТЗ для сле­дующего иерархического уровня, возможны возвраты. В средствах пользовательского интерфейса предусмотрено высве­чивание на экране фрагментов дерева, по каждой ветви дерева сообщается о ее готовности к проработке, занимается ли ею кто-то другой из разработчиков и т.п.

В общем случае полная формализация управления проектированием не может быть достигнута, поэтому полезную роль играют системы поддержки решений, принимаемых людьми, DSS (Decision Support Systems). В качестве таких систем часто используют хранилища данных и OLAP-средства (On-Line Analytical Processing).

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

OLAP-средства должны обеспечивать оперативный доступ к данным, на основе которого выяв­ляются зависимости между параметрами (измерениями в многомерной модели приложения). В OLAP-системах на реляционных СУБД аналитическая обработка, или, другими словами, многомер­ный динамический анализ данных требует просмотра большого числа записей из разных таблиц. По­этому производительность оказывается невысокой. В специализированных OLAP-системах, обеспе­чивающих более быстрый многомерный анализ, но с более существенными ограничениями на объем БД, данные хранятся в виде гиперкубов или поликубов – многомерных таблиц с постоянным или переменным числом ячеек соответственно. Пример OLAP системы – Oracle Express, помогающей ме­неджерам и аналитикам получать данные в виде разрезов таких многомерных таблиц, готовить отче­ты, обосновывать решения.

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

Примером программы консультирования и прогнозирования результатов принимаемых решений может служить программа Clio в упомянутой выше подсистеме Minerva.