CC BY
14
алгебраические представления объектов и функций МП и МК [10,14]. Это дает возможность достаточно продуктивно создавать как непосредственно сами программы симуляции, так и их архитектурные каркасы [15].
Предлагаемый подход к построению САСФП позволяет существенно расширить спектр вовлекаемых в рассмотрение микропроцессорных архитектур. Более того, развитие техники программируемых схем за последние годы дает разработчикам возможность модифицировать функциональность микропроцессорных устройств вплоть до изменения состава команд. Предварительные оценки эффекта от различных модификаций такого плана достаточно легко достигаются в рамках рассмотренного в данной работе подхода.
СПИСОК ЛИТЕРАТУРЫ
1. Вермишев Ю.Х. Основы автоматизации проектирования. М.: Радио и связь, 1988.
2. Олссон Г., Пиани Д. Цифровые системы автоматизации и управления. СПб.: Невский диалект, 2001.
3. Домнян С.Б., Иванов Е.А., Муренко Л.Л. Средства комплексной отладки микропроцессорных устройств/Под ред. В.Г.Домрачева. М.:Энергоатомиздат, 1988.
4. Cook Т.А. Instruction Set Architecture Specification. Ph.D. thesis from North Carolina State University, 1993.
5. Гамма Э., Хелм P., Джонсон P., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2001.
6. Ларман К. Применение UML и шаблонов проектирования. М.: Изд. дом «Вильяме», 2001.
7. Negoda V.N. Simulation Programs Generation Based on Decision Tables Translation Technics. "Interactive Systems: The Problem of Iluman-Computer Interaction, Proceedings of the International Conference. Ulianovsk, 2001. P.92-93.
8. Cmelik R.F. Keppel D. Shade: A Fast Instruction-Set Simulator for Execution Profiling. Technical Report UWCSE 93-06-06, 1993.
9.' Негода B.H. Дистанционное обучение основам микропроцессорной техники. //Материалы выставки 2-й междунар. науч.-техн. конф. «Интерактивные системы:
• Проблемы человско-компьютерного взаимодействия». Ульяновск: УлГТУ, 1997. С. 29-31.
10. Иегода В.Н. Функции и структура моделей микропроцессоров в учебно-исследовательской САПР микропроцессорных систем // Вестник УлГТУ. Сер. Информационные технологии. 1999. № 2. С. 87-93.
И. Sozin В. Telecommunication Metha-Assembler and ins Adjustment. "Interactive Systems: The Problem of Human-Computer Interaction, Proceedings of the International Conference. Ulianovsk, 1999. P. 161-162 .
12. Negoda V.N., Skvortsov V.S. Increasing Perfomance of Multifunctional Cross-Assembler, Interactiv Systems: The Problems of Human - Computer Interaction. - Proceedings of the International Conference. Ulyanovsk: UISTU, 2001, p. 88-89.
13. Негода B.H. О построении учебно-исследовательской системы функционально-логического моделирования микропроцессорных систем // Вестник УлГТУ. Сер. Информационные технологии. 1998. №1. С. 63-67.
14. Негода В.Н. Об алгебраических описаниях моделей микропроцессорных устройств для учебно-исследовательской САПР // Труды международной конференции «Континуальные логико - алгебраические и нейросетевыс методы в пауке, технике и экономике». Ульяновск, 2000. Т.1. С. 86-87.
15. Негода В.Н. Архитектурные каркасы моделей микроконтроллеров и поддержка цифровой обработки сигналов // Электронная техника: Сборник научных трудов. Ульяновск: УлГТУ, 2001. С. 48-53.
Негода Виктор Николаевич, кандидат технических наук, окончил радиотехнический факультет Ульяновского политехнического института. Профессор кафедры «Вычислительная техника» УлГГУ. Имеет статьи и монографии в области проектирование микропроцессорных систем и автоматизации обучения.
УДК 658.512.22
А. Ф. ПОХИЛЬКО
• •
ПОСТРОЕНИЕ МОДЕЛИ КЛАССОВ ОБЪЕКТОВ И ТИПОВЫХ МЕТОДИК ПРОЕКТИРОВАНИЯ В ИНТЕГРИРОВАННОЙ ИНТЕРОПЕРАБЕЛЬНОЙ СРЕДЕ САПР
Рассматривается способ формализации проектной деятельности и механизм его реализации с целью накопления, модификации и обобщения типовых методик проектирования. ,
ВВЕДЕНИЕ
В [1] предложена общая модель целостного представления проектной деятельности в интегрированной среде САПР, структура информационных процессов и инструментальных средств для реализации рассмотренных механизмов. С позиций автоматизации большой интерес представляет сохранённая последовательность Рв(1,0, ТЬ, Тх,Ё). Сохраняя последовательность получения результата, мы имеем возможность при равных условиях повторить результат, вмешаться в процесс, а в идеале -совершенствовать сам процесс и, соответственно, результат. На практике это означает возможность динамического отображения проектной деятельности с целью накопления, модификации и обобщения типовых методик проектирования. В данной работе рассматриваются некоторые принципиальные аспекты развития этой возможности.
ТРЕБОВАНИЯ К ИНФОРМАЦИОННЫМ КОМПОНЕНТАМ ОПИСАНИЯ ПРОЕКТНОГО РЕШЕНИЯ
Развиваемый подход к представлению проектной деятельности предъявляет некоторые требования к информационным компонентам
интегрированной среды САПР с точки зрения отображения и хранения проектной процедуры.
Модульность. С использованием объектно-ориентированной технологии программирования (ООП) за различные аспекты представления объекта проектирования должны отвечать различные модули. В каждом из таких модулей должна инкапсулироваться функциональность, связанная с одним из аспектов представления, например, за графическое представление должен отвечать графический моделлер. Модульность построения создает предпосылки для выполнения следующего требования.
Интероперабельность. Это повторное использование существующей функциональности. Современные технологии позволяют использовать функциональность ядра существующих информационных систем. ИС твердотельного моделирования 8оП(1\Уогкз предоставляет свой программный интерфейс и позволяет использовать все свои функции как библиотечные при построении более сложных систем. Выполнение перечисленных требований позволяет создавать гибкие системы, поддерживающие реинжениринг проектной деятельности в ИС.
Процедурные \приложения формируются в такой системе как последовательность связанной совокупности операций по преобразованию описания объекта 0(8(Сг,ТЬ,Тх)) во всех его аспектах [2]. Для автоматизации проектной деятельности необходимо выделение этих последовательностей в технические решения и повторное их использование. Как показывает опыт, выделение некоторой, даже вполне тривиальной цепочки (в форме, например, протокола, макроса), без дополнительной информации приводит к неправильной интерпретации этой последовательности в дальнейшем. В геометрических моделлерах процесс проектирования представляется в последовательном виде и каждый следующий шаг наследует некоторые свойства предыдущих. Однако возможны ситуации, в которых внешне неразличимые решения получаются существенно разным путём (множественное наследование), что приводит к неразрешимым конфликтам при попытке использовать в одном проекте решения, созданные разными проектировщиками (тем более в разных средах проектирования). Ещё более остро подобные коллизии возникают при анализе учёта различных аспектов представления объекта проектирования (Сг,ТЪ,Тх). Выход из подобной ситуации - внедрять дополнительную информацию на стадии выделения проектной процедуры. Таким образом, проект (описание процедуры его получения) должен состоять из:
• связанного смешанного набора проектных процедур, содержащих последовательность получения описания состояния объекта проектирования. Последовательность должна быть описана на универсальном уровне, независимом от конкретного состава интегрированной среды САПР;
9
в дополнительной информации — условия применимости в текстовом виде для общего случая, содержать связанный список параметрических зависимостей для ряда конкретных случаев;
• дополнительных методов, позволяющих интерактивно разрешать неоднозначности на входе и на выходе проектной процедуры.
Каждая из типовых проектных процедур имеет смысл, если есть возможность её модифицировать, заменять и переносить. Эти свойства проектная процедура приобретает при определенной её организации в виде самостоятельного процесса, выполняемого параллельно, имеющего определённое состояние и способного взаимодействовать с другими подобными решениями посредством передачи сообщений. Такая организация должна обладать рядом свойств.
© Автономность: функционирование без прямого внешнего вмешательства и наличие определённой способности контролировать свои действия и внутреннее состояние.
• Коммуникативность: взаимодействие с другими процедурами и пользователем-проектантом.
® Реактивность: наличие способности воспринимать среду и адекватно реагировать в определённых временных рамках на происходящие изменения.
• Модальность: отражение целесоответствия текущего состояния и целесообразности перехода к следующему.
МОДЕЛЬ ПРОЕКТНОГО РЕШЕНИЯ В ПРОЦЕДУРНОЙ ФОРМЕ
Представим модель элементарной проектной процедуры (получение и фиксация элементарного проектного решения) в виде следующего кортежа:
О - множество данных проектной процедуры. Основная задача проектной процедуры - это оперирование данными описания проектного решения (представлением объекта проектирования), поэтому модель должна содержать данные
Второй элемент - выделенная последовательность, приводящая к текущему состоянию объекта.
Множество р1 предикатов, определяющих принципы построения объекта, с набором условий применимости:
4
л к . • . ч >-. -> •
Под ау понимается операнд простейшего построения (причём для различных аспектов представления объекта Сг,ТЬ,Тх) на языке макросов соответствующей С АО/САМ/СУ БД системы.
"</ "Ы^^ - - - И ^ Ко > - - >' • - 1У/Л <Л!-
Множество методов процедуры определяют реакцию последовательности на её изменение, удаление и перемещение, а также отвечают за взаимодействие цепочки с окружающей средой:
• ' I , . т| |( Г I I < ' ®нв » ? I 1 ' • I • А
Наконец последний элемент Т - цепи или процессы, протекающие в проектной процедуре, отражающие неучтённые состояния и отвечающие за реакцию на них.
\ МЕХАНИЗМ РЕАЛИЗАЦИИ И ЭКСПЕРИМЕНТ
Для решения вышепоставленной задачи разработан механизм (инструментальная среда), позволяющий создавать модели класса объектов и методов проектирования (МКОП и МКМП), используя для этого табличную, текстовую, графическую информацшо, описывающую типовую методику проектирования [3],
Под МКОП и МКМП понимаются структурно и параметрически подобные описания результата проектирования (МКОП) и последовательности шагов, образующих проектную процедуру его получения (МКМП) и составляющих, в сущности, типовую методику проектирования.
Задачей инструментальной среды является предоставление конструктору возможности создания МКОП и МКМП без использования операций, требующих специальных знаний программиста и понимания внутренних механизмов реализации (отображения в информационной среде) модели объекта проектирования. Для создания МКОП и МКМП конструктору в процессе реализации стандартных действий по проектированию типовых объектов предлагается выполнить ряд действий исключительно по фиксации последовательности и параметров проектных операций, соответствующих проектным процедурам создания элементов и объекта проектирования в целом. При сохранении параметров операции определяется соответствие операции описанию проектной операции в предметной области.
Эта модель исследовалась па примере структурного представления сборочного узла. Представление сборочного узла в инструментальной среде
позволяет создавать модели класса объекта проектирования (МКОП МКМП).
При описании проектной операции создаются пять типов объски таблица (позволяет хранить данные, определяющие допустимые значен проектной операции); текст (описывает условия, необходимые д выполнения проектной операции); формула (задает зависимость меж, переменными, используемыми в определении параметров проект! к операции); макрос создания графического элемента (сох рам in последовательность действий, выполняемых 3D моделлером для создам i модели объекта проектирования) и связь (устанавливает соответствие меж; табличными, текстовыми и графическими данными).
Сохранение последовательности действий, образующих проек nryi процедуру проектирования, создает возможность автоматизирование)) информационного описания сценарргя создания модели объек'г проектирования, его сохранения и модификации. В данно инструментальной среде возможно использование механизма выбор технического решения в соответствии с условиями технического задики (ТЗ). Последнее принципиально важно, так как единожды созданный проек' является обобщённой моделью, по которой будет проектирован,ei следующая ТС, что невозможно при отсутствии фиксации условий i механизма выбора вариантов технического решения.
. ЗАКЛЮЧЕНИЕ
Рассмотренный способ формализации проектной деятельности и механизм его реализации в интегрированной интероперабельной среде CAIII1 приводит к положительным эффектам по отношению к известным способам построения информационным технологий автоматизации конструкторского проектирования как с точки зрения повышения степени автоматизации, так и повышения гибкости представления проектной информации.
СПИСОК ЛИТЕРАТУРЫ
•
КПохилько А.Ф. Технология представления проектной деятельности и интегрированной среде САПР// Вестник УлГТУ. Сер. Информационные технологии. 2000» №3.
2. Pokhilko A. F. Technology of the Development of The User-Oriented Integrated CAD Applications Proceedings of CSIT2001 The 3 International Workshop on Computer Science and Informational Technologies, Ufa. 200!.
3. Похилько А.Ф. Использование процедурной и декларативной составляющих дли целостного отображения проектной деятельности в САПР// Труды МНТК. «Системный анализ в проектировании и управлении». С.-Петербург, 2001.
Похилько Александр Федорович, кандидат технических наук, профессор кафедры САПР, закончил Ленинградский политехнический институт по специальности «Инженер-электрик». Область научных интересов -инструментарий и технологии САПР, системный анализ, принятие решений.
УДК 658.512
С. А. СУХОВ
МОДЕЛИРОВАНИЕ ПРОЕКТНЫХ ПРОЦЕССОВ В КОНТЕКСТЕ ПРИОБРЕТЕННЫХ ПРОЕКТНЫХ РЕШЕНИЙ >
Рассмотрена реализация системы, поддерживающая процесс проектирования в контексте приобретённых ранее проектных решений и основанная на интерпретации их процедурных описаний.
Развитие технологий автоматизированного проектирования сопровождается повышением уровня интеллектуализации, расширения набора предоставляемых сервисов и улучшения степени поддержки пользователя. Однако уровень поддержки пользователя недостаточно соответствует возрастающим объёмам проектной информации и предъявляемым к качеству проработки проекта требованиям.
На данный момент проектировщик вынужден хранить в своей памяти большие объёмы относящейся к проекту информации: способы реализации различных подзадач проектирования, место нахождения этих решений, содержание и смысл решения, правила реализации решения в среде проектирования и т.д.
Одним из важных направлений развития САПР становится создание инструментальных средств, позволяющих проектировщику сосредоточиться в большей степени на творческих аспектах проектирования. Проблемой здесь выступает разработка механизма приобретения, сохранения и применения в другой ситуации проектных знаний, полученных при достижении некоторого проектного решения.
Предлагаемый подход в решении проблемы заключается в реализации системы, поддерживающей процесс проектирования в контексте приобретённых ранее проектных решений и основанной на интерпретации их процедурных описаний.
Проектное решение рассматривается как совокупность декларативных и процедурных описаний. Процедурные описания содержат ссылки на программные процедуры инструментальных средств САПР, использованных
ранее для достижения некоторой проектной цели. Такое описание проектного решения позволяет, с одной стороны, выделить в отдельную сущность последовательность проектных действий, и, с другой стороны, эффективно осуществлять процесс проектирования по существующему информационному описанию.
Предлагается следующая модель описания процесса проектирования:
1. Основу модели составляет множество 8= {5,, ¿?2 } проектных решений
где проектное решение рассматривается как совокупность описаний
8<Р,ОД,ОДУ>, где О - область применимости проектного решения;
И - функциональность решения (реализуемая функциональность);
№
Л,} - множество параметров проектного решения;
в ={С,} - множество границ значений параметров, обеспечиваемых
проектным решением; Е - недостатки проектного решения;
V - процедурное описание проектного решения, рассматриваемое как связанный список элементов V; <паше, т[], \й>,
где пате - наименование программного метода инструментария САПР; ш[] - массив входных ар1ументов;
- ссылка на объект программного метода.
2. Процесс проектирования Р(1) рассматривается в последовательности информационных состояний СА, получаемых как результат достижения
последовательности целей ик.
3. Информационное состояние Ск представляет множество значений параметров Яп Ск(Я[уЯ2>...,Я1\ определённых содержанием проектной цели 1\ <К,С,А>,
где {Я} - множество параметров, которые необходимо обеспечить в процессе деятельности по достижению цели;
{в} - множество границ значений параметров Я; А - описание цели.
4. Переход проекта из состояния Ск в состояние С'ки осуществляется на
основе деятельности проектировщика Оу(8), связанной с выбором направления изменения проекта, деятельности Ос(8), заключающейся в синтезе нового проектного решения в базисе отобранного
подмножества {8}, деятельности Ош(8), заключающейся в изменении атрибутов т[] элементов выбранного проектного решения .
5. Деятельность Эу(8) заключается в выборе решений <Р,0Д,0,Е5У>.
Выбор решений в каждой проектной ситуации осуществляется в контексте обеспечения требуемой функциональности проектируемого объекта и текущего состояния Ск проекта Рф в результате анализа
параметров <Р,ОД,С,Е> проектных решений образного представления
