Лекция 22. Методическое обеспечение систем автоматизированного проектирования систем управления

Лекция 22. Методическое обеспечение систем автоматизированного проектирования систем управления.

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

 

Сейчас мы опишем самую общую (и, следовательно, довольно простую) модель " типичного" процесса проектирования. По терминологии работы [2] — это интуитивная концептуальная модель. На рис. 3.1 показан первый ва­риант такой модели, относительно которой делаются следующие основные предположения:

цель проектирования неизменна (по крайней мере, в течение какого-то времени);

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

То, что на рис. 3.1 обозначено словом " проект", еще не само изделие. Это модель изделия, на основании которой можно говорить об изделии до его появления.

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

Мы можем говорить о воспринимаемой реальности, давая имена объектам и атрибутам объектов. Один из этих объектов и является изделием, о кото­ром у нас сформировалось представление. Однако в общем случае нас не интересуют все аспекты воспринимаемой реальности, мы выбираем лишь те аспекты, которые существенны для некоторого практически осущест­вимого образа действий. Такой процесс выбора порождает " множеством выбора". Рассматриваемая модель не явля­ется формальной, это всего лишь " интуитивная концептуальная модель" в смысле определения, данного в работе [2].

УТОЧНЕННАЯ МОДЕЛЬ ПРОЦЕССА ПРОЕКТИРОВАНИЯ

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

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

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

2. В большинстве случаев процесс проектирования является итератив­ным. На ранней стадии проекта относительно конкретных характеристик изделия принимаются решения, основанные на эвристических соображениях с учетом неполных знаний об их влиянии на достижение конечной цели. Эту часть процесса проектирования мы назовем " синтезом". На последней стадии " проект" необходимо анализировать и оценивать в свете спецификаций проекта. Говоря о программном обеспечении, такие действия обозначают терминами «пророверка правильности» или " верификация". Если цель не достигается, то проектные решения должны быть соответствующим образом скорректированы.

 

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

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

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

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

Существует несколько аспектов процесса проектирования, не показанных на рис. 3.3.

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

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

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

Различные процессы должны быть синхронизированы и обеспечены ресурсами " процессом фирмы". Рассмотрим теперь знания. Знания представляют собой, главным образом, набор правил, таких как: если Вы поняли ситуацию А, сделайте попытку уточнения модели; если Вы поняли ситуацию Б, проанализируйте и оцените качество модели; если Вы поняли ситуацию В, скорректируйте часть модели. I Эти типы правил можно связать с главными этапами процесса проектиро­вания: синтезом, оценкой и анализом. Различие между ними ясно показано в работе [7]. Синтез и анализ не являются просто взаимно-обратными, этапами. Синтез является попыткой такого уточнения модели, которое с большей вероятностью привело бы к удовлетворительному результату при последующем анализе. Такие попытки могут оказаться неудачными, что становится очевидным на этапе оценки. В случае неудачи часть работы по уточнению модели должна быть выполнена заново. Для выяснения, какой шаг детали­зации несет ответственность за несоответствие спецификаций и результата, необходимо вернуться назад к началу процесса. Если в пределах ограничений на ресурсы (время, деньги и т.д.) не найдено удовлетворительного решения, процесс должен обратиться за помощью к процессу более высокого уровня.

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

Синтез:

если Вы поняли некоторую ситуацию, включите определенное подмно­жество множества известных правил в множество приложимых;

Анализ:

примените множество приложимых правил;

Оценка:

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

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