CC BY
19
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 681.32 В. Н. НЕГОДА
ШАБЛОНЫ ПРОЕКТИРОВАНИЯ В УЧЕБНОЙ СИСТЕМЕ МОДЕЛИРОВАНИЯ МИКРОПРОЦЕССОРНЫХ СИСТЕМ
В учебной системе моделирования микропроцессорных систем на очень коротком отрезке времени в условиях острой нехватки квалификации исполнителей требуется решать такие проектные задачи, в которых должен быть задействован достаточно широкий спектр знаний и умений. Для повышения продуктивности учебно-проектной работы предлагается использовать шаблоны проектирования. Предлагаются классификация шаблонов, их структурно-функциональные модели и примеры.
ВВЕДЕНИЕ
Проектирование программно-аппаратных средств при изучении микропроцессорной техники (МПТ) выполняется в более жестких условиях, нежели реальное проектирование средств МПТ в проектных организациях и конструкторских подразделениях предприятий. Учебная деятельность по одной-двум дисциплинам, связанным с изучением
микропроцессорной техники, занимает у студента или слушателя курсов повышения квалификации время, во много раз меньшее, чем время проектирования даже относительно несложной реальной микропроцессорной системы (МПС). В то же время цели обучения заставляют формулировать постановки задач таким образом, чтобы процесс решения охватывал достаточно широкий спектр знаний и умений. Дефицит времени на выполнение проекта усугубляется еще и острым недостатком квалификации у обучаемого, из-за чего большая часть его действий низкопродуктивна.
Повышение продуктивности учебно-проектной работы обучаемого может быть достигнуто использованием учебно-исследовательской системы моделирования (УИСМ) МПС, в которой поддерживается эффективное управление
деятельностью и активное применение шаблонов проектирования [1,2]. Исследования шаблонов проектирования активно проводятся в рамках работ по развитию технологий объектно-ориентированного анализа и проектирования (ООАП), где шаблоны иногда называют образцами или паттернами [3,4,5]. Шаблон описывает общее решение некоей общей проблемы в определенном контексте [3].
Рассмотрим подходы к использованию концепции шаблонов проектирования при разработке программного и аппаратного обеспечения МПС в учебном процессе, опираясь на аналогии и различия технологий, осуществляемых в УИСМ, с технологиями ООАП. Первоочередными задачами определения подходов будем считать поиск ответов на следующие вопросы: Какие вида шаблонов
целесообразнее всего использовать в тех или иных учебно-проектных работах? Какова структурно-функциональная организация шаблонов? Какой эффект дают шаблоны в реальной практике учебного проектирования средств МПТ?
КЛАССИФИКАЦИЯ ШАБЛОНОВ ПРОЕКТИРОВАНИЯ
В зависимости от видов проектных работ будем разделять шаблоны машинно-ориентированного программирования (МОП), шаблоны проектирования аппаратуры (ПА), шаблоны аппаратно-программной реализации функций (АПР), шаблоны моделей объектов и процессов МПС (ММПС).
Шаблоны МОП дают нам модели и образцы реализации таких видов обработки данных в МПС, которые целесообразнее всего осуществлять программно. Шаблоны ПА представляют собой схемы с различной степенью абстракции - от концептуальных системотехнических решений до конкретных принципиальных схем. Шаблоны АПР представляют такие методы реализации функций и технические решения, в которых можно варьировать быстродействие и аппаратурные затраты за счет перераспределения участия аппаратуры и программы. Шаблоны ММПС позволяют с большей эффективностью развивать УИСМ и вовлекать обучаемых в процесс создания моделей.
Технологии перечисленных видов проектных работ содержат в себе много эффективных решений, реализуемых без применения ООМ. С другой стороны, многие решения ООМ, полученные в расчете на их реализацию через объектно-ориентированное программирование, могут быть успешно использованы и в проектах, реализуемых на обычных процедурных и даже машинно-ориентированных языках программирования. В этой связи классификацию шаблонов по механизмам их применения в проектных решениях будем строить как расширение классификаций шаблонов и образцов проектирования, приведенных в литературе по
ООМ [3,4]. В результате такого расширения получаем следующие виды шаблонов.
Прототипы. Это программы и схемы, которые извлекаются из библиотеки шаблонов и могут быть отредактированы соответствующими средствами: редакторами текстов, графическими редакторами. Прототипы целесообразны там, где использование типовых проектных решений тесно увязано с их изучением. Изменяя объемы модификации прототипов, мы можем влиять на спектр вовлекаемых в учебную работу знаний и степень контролируемости деятельности обучаемого [1,2].
Макроопределения. В случае шаблонов МОП -это традиционные макробиблиотеки, которые можно параметрически настраивать в точках макровызова. Шаблоны ПА также можно настраивать через макрогенерацию, если используются открытые форматы векторной графики. Для изучения технических решений макроопределения открыты в меньшей степени, чем прототипы. Правда, изучение структуры макробиблиотеки полезно для получения представления о типовых операциях обработки данных, а при изучении макропрограммирования полезно проводить анализ самих текстов макроопределений.
Параметрически настраиваемые компоненты и библиотеки классов. Целесообразно использовать в двух случаях: когда изучается программирование МПС на объектно-ориентированных языках (обычно Си++) и при создании шаблонов поддержки создания программных моделей УИСМ МПС.
Немодифицируемые компоненты. К таким компонентам относятся библиотеки программ в объектном виде и конкретные схемотехнические решения. Название этого вида компонентов отражает факг невозможности модифицировать исходные представления компонентов, хотя возможность настройки в фазе выполнения для библиотек программ естественно имеется. Эта настройка осуществляется через передачу параметров между вызывающим и вызываемым модулями. Главное назначение библиотек немодифицируемых компонентов в УИСМ МПС - обеспечение применения изучаемых технических решений в достаточно сложном проекте, где большая часть функций покрывается готовыми решениями, не требующими времени на модификацию при их встраивании в проект.
Архитектурные каркасы. Архитектурный каркас представляет собой связанную совокупность параметрически настраиваемых компонентов, предназначенных для создания программной либо программно-аппаратной системы или достаточно сложной подсистемы. К основным задачам, которые могут быть эффективно решены с помощью архитектурных каркасов, в УИСМ МПС относятся: разработка программных моделей отдельных средств МПТ и конкретных МПС, разработка моделей рабочей нагрузки и моделей поведения объектов контроля и * управления, разработка МПС определенного назначения.
Механизмы. Шаблон этого типа представляет собой связанную совокупность компонентов, предназначенных для реализации связанного набора функций. Например, механизмы организации ввода-вывода для МП, содержащие средства поддержки операций ввода-вывода и преобразования между внешним и внутренним представлением данных. В отличие от архитектурного каркаса механизм имеет более общее назначение и может использоваться значительно шире, в том числе при формировании архитектурного каркаса.
СТРУКТУРНО-ФУНКЦИОНАЛЬНАЯ ОРГАНИЗАЦИЯ ШАБЛОНОВ
В реальной практике шаблоны объединяются в • некоторые совокупности. Совокупность должна сопровождаться общим описанием, информацией о связях и зависимостях между шаблонами, и каждый ее элемент должен быть представлен множеством артефактов собственно шаблона и описанием его применения. Из этого вытекает следующая общая логико-алгебраическая модель совокупности шаблонов:
PG « <dPG, rPGf Ph...,Pn>9 (1)
где dPG - описание совокупности шаблонов; rPG -множество отношений, связывающих шаблоны внутри совокупности; Pj,...,Pn - множество шаблонов.
Каждый из шаблонов P¿ в общем случае представляется его описанием dP¡, реализуется через совокупность компонентов C})...tCmy между которыми устанавливаются отношения из множества гРх . Применение шаблона базируется на некотором механизме его встраивания в проект, который обозначим как cP¡ . Таким образом, общее логико-алгебраическое представление шаблона P¡ имеет вид
ñ = <dPh гРь■ сР, Си, ^,C¡m>. (2)
Компонент Ср кроме своего описания dCjf обладает множеством параметров pCjy через которые модифицируются свойства компонента, • и множеством функций /Су, через которые потребляются функциональные возможности компонента:
Cj = <dCjtPCj,JCj>. (3)
Обязательными составляющими описаний dPG, dP¿> dC в выражениях (1-3) являются наименования библиотек, шаблонов и компонентов, информация о их размещении (имена файлов, директор™) и правила использования. Кроме того, важными составляющими считаются примеры применения и описание задач, при решении которых целесообразно применять тот или иной шаблон [4].
Отношения между компонентами шаблонов rP¡ в общем случае более разнообразны отношений из множества rPGy поэтому ограничимся только их рассмотрением. Хорошую классификацию отношений дает нам технология объектно-ориентированного моделирования (ООМ),
базирующаяся на применении языка моделирования UML (Unified Modeling Language) [3]. Основными
пидами отношений в ООМ являются обобщения, зависимости, реализации и ассоциации.
Обобщение - это отношение между общей сущностью (родителем) и ее конкретным воплощением (потомком). В ООЛП обобщение порождает наследование классов и объектов. В шаблонах типа параметрически настраиваемых компонентов, архитектурных каркасов и механизмов отношение обобщения лежит в основе их формирования и использования. Применительно к прототипам обобщение может рассматриваться как отношение базовых модулей и модулей, полученных из них через расширение. Обобщение, построенное над библиотекой макроопределений, дает нам варианты макровызовов и модификации тех макроопределений, что выступают в качестве прототипов. Отношение обобщения является хорошей основой для порождения формулировок задач на проектирование в среде УИСМ. При этом обучаемому выдается ряд шаблонов, относительно которых необходимо создать конкретные реализации.
Зависимость представляет такую связь между компонентами, при которой один
компонент (зависимый) использует
другой (независимый) и изменение в спецификации независимого элемента может повлиять на другой, его использующий. Примерами зависимости могут служить отношение между вызывающим модулем и вызываемой процедурой, отношение «быть независимой копией», отношение «быть очередной версией модуля», отношение «быть источником сигнала между двумя процессами» и т.п.
Реализация - это отношение, которое устанавливает связь между компонентом, определяющим соглашения о некоторых функциях, и одним или более компонентами, обеспечивающими выполнение этих соглашений. Например: декларация абстрактного класса в программе на С-ьь и его реализация, описание функциональной возможности
и реализующая ее кооперация компонентов. В УИСМ реализацию удобно использовать в моделях управления инженерно-проектной деятельностью для представления связей между артефактами постановок задач и шаблонами, предоставляемыми для поддержки реализации.
Ассоциация представляет широкий спектр структурных взаимосвязей между объектами различных типов [5]. Например: «Л' является физической частью У» - «Блок регистров общего назначения - процессор», «Л*" является логической частью У» - «Последовательность состояний автомата - Диаграмма переходов автомата», «X физически содержится в/на У» - «Учитываемая деталь - Чашка электронных весов», «X логически содеро\сится в/на У» - «Постановка учебной задачи Перечень заданий и упражнений», «X является описанием У» - «Описание шаблона - Шаблон», «X является элементом транзакции или отчета У» -«Оценка за учебную работу - Учебный журнал», «.X является организационной единицей У» - «Группа консультантов по проекту - Исполнитель проекта», «X является членом У» - Студент - Учебная группа», «А' использует или управляет У» - «Управляющий автомат - Операционный автомат», «X взаимодействует с У» - «Арифметико-логическое устройство - Регистровая память», «X следует за У» -«Состояние автомата - Следующее состояние автомата 52». Большой размер этого списка примеров призван показать разнообразие проявлений отношения ассоциации и пересечение его смысла со смыслом других отношений. Это означает, что там, где трудно выделить отношения обобщения, зависимости и реализации, выгодно использовать ассоциацию. Кроме того, связь одних объектов с другими при тщательном анализе может разлагаться на несколько отношений.
Дешифратор кода операции
| / / у
| //
1 10
Рис. 1. Диаграмма объектов прототипа симулятора 18086 для типового задания
ПРИМЕРЫ ПРИМЕНЕНИЯ ШАБЛОНОВ
1. На кафедре ВТ УлГТУ с 1986 года в различных дисциплинах используются шаблоны проектирования программных моделей архитектур ЭВМ и МП. Рассмотрим версию шаблона проектирования модели МП Intel 8086, которая применяется с 1997 года как прототип для курсового проектирования.
Шаблон представляет собой исходный текст ассемблер-программы, которая моделирует все способы адресации 18086 и три команды: HLT, OR, JCXZ. Работа с префиксами замены сегментного регистра и префиксами повторения не моделируется. Общий объем программы - 725 строк, 588 из них операторные, а остальные являются описаниями внутренних компонентов. Диаграмма объектов на языке UML для этого шаблона представлена на рис.1.
На основе этого прототипа студент должен реализовать программу моделирования набора из 7 команд, в каждый из которых входят команды ввода-вывода. Вариации заданий выполняются следующими средствами:
® индивидуальным для каждого задания набором команд;
® распределением функций между частями, одна из которых должна быть реализована на ассемблере, а другая - на Си;
* индивидуальным для каждого задания набором объектов ввода-вывода; в проекте исиользуются созданные в ходе выполнения одной из лабораторных работ модели микропроцессорных БИС и/или комплектов ИС;
® назначением различных механизмов связи МП с объектами ввода-вывода.
Анализ 10 случайным образом выбранных курсовых проектов 1999 года показывает, что средний объем студенческого проекта равен 1828 операторным строкам на языке ассемблера и 489 операторным строкам на языке Си. Применение прототипа позволило выполнять разработку программ с затратами времени в 10 с лишним раз меньшими, нежели среднестатистические затраты на аналогичную работу согласно оценочным функциям Боэма [6].
2. В 1999-2001 годах на кафедре ВТ был поставлен эксперимент по программированию полнофункциональных симуляторов на языке Java при использовании в качестве прототипов доступных исходных кодов на языке Си. Моделировались архитектуры Intel 8086 (сквозное курсовое проектирование одного студента по двум дисциплинам), Motorola 68000 (выпускная работа бакалавра) и PDP-11 (диплом инженера). В качестве прототипов выступали недиалоговые модели с частичной реализацией аппаратно-программной среды ЭВМ. Требовалось создать диалоговые симуляторы по общей схеме, представленной на рис.2.
Симулятор 18086 строился с использованием программных преобразователей части кода Си-программы в Java-код. Общий объем симулятора составил 4556 операторных строк, в том числе 1842 строки собственно модели микропроцессора и 394 строки дизассемблера. Т. е. примерно половину объема составляет диалоговая среда, в которую погружается модель. Очевидно, что такого вида среды для разных симуляторов могут строится на основе некоторого архитектурного каркаса.
1
L.
Рис. 2. Обобщенная схема диалогового симулятора
*
«subsystem» Управление созданием и выполнением программ
«subsystem» Моделирование машинных команд
«subsystem» Редактор объектов МП
«subsystem» Интерфейс с внешней
средой
Оценка эффективности создания архитектурного каркаса была проведена при создании симуляторов Motorola 68000 и PDP-11. В результате разработки общая часть симуляторов составила 4000 операторных строк. Специфичная часть симулятора М68000 составила 4354 операторных строк, а симулятора PDP-11 - 3320. Таким образом архитектурный каркас в симуляторе М68000 составил около 48% от общего кода, а в симуляторе PDP-11 -около 55%. Motorola 68000 и PDP-11 относятся к так называемым ортогональным архитектурам и имеют существенно пересекающиеся множества операций над 8-битными и 16-битными данными. Оценка возможностей использования этого факта показала, что включение программных функций по реализации этих операций в архитектурный каркас увеличило бы степень повторного использования кода еще примерно на 5-7%, однако при этом существенно ухудшились бы параметры быстродействия и читабельности программы. Таким образом, ортогональность и близость операций не сыграли существенной роли в расширении архитектурного каркаса, хотя ее значение в повышении производительности труда программиста все же заметно, т. к. многие программно-технические решения по реализации командного цикла для М68000 были впоследствии использованы с соответствующими модификациями в симуляторе PDP-11.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Негода В. Н. О построении учебно-исследовательской системы функционально-логического моделирования микропроцессорных систем //Вестник УлГТУ. Сер. Информационные технологии. - 1998. - №3.
2. Негода В. Н. О контроле деятельности обучаемого в учебной САПР микропроцессорных систем //Вестник УлГТУ. Сер. Информационные технологии. - 2000. - №3.
3. Буч Г. Язык иМЬ. Руководство пользователя / Г.Буч, Д.Рамбо, А. Джекобсон. - М.: ДМК, 2000.
4. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. -СПб.: Питер, 2001.
5. Ларман К. Применение 1)МЬ и шаблонов проектирования / К. Ларман. - М.: Изд. дом «Вильяме», 2001.
6. Боэм Б. У. Инженерное проектирование программного обеспечения / Б.У.Боэм.- М.: Радио и связь, 1985.
Негода Виктор Николаевич, доктор технических наук, окончил радиотехнический факультет Ульяновского политехнического института. Профессор кафедры «Вычислительная техника» (ВТ) УлГТУ. Имеет статьи и монографии в области проектирования микропроцессорных систем, автоматизации обучения и сетевых технологий.
УДК 658.512.22
А. Ф. ПОХИЛЬКО, А. А. МАСЛЯНЦЫН
МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ПРОЦЕССОВ ПРОЕКТИРОВАНИЯ ТЕХНИЧЕСКИХ ОБЪЕКТОВ
Описывается модель, позволяющая хранить, модифицировать и обобщать процессы проектирования технических объектов.
ВВЕДЕНИЕ
Ранее, в работе [1] показаны недостатки современных информационных систем поддержки конструкторского проектирования (САПР, РОМ), заключающиеся в отсутствии представлений процессов проектирования технических объектов. В работах [2, 3] описаны общие принципы представления процессов проектирования и концепции построения . информационных систем, реализующих эти задачи. В этой работе рассматриваются вопросы архитектуры
программного средства поддержки работы с процессами проектирования технического объекта на основе концепции многоагентной системы, его место в информационной среде автоматизированного
рабочего места конструктора, описана графовая модель, позволяющая накапливать и модифицировать методики проектирования отдельно взятого технического объекта.
СИСТЕМНОЕ ПРЕДСТАВЛЕНИЕ О ПРОЦЕССЕ ПРОЕКТИРОВАНИЯ ТЕХНИЧЕСКОГО ОБЪЕКТА
Для системного представления о процессе проектирования технического объекта необходимо
рассматривать совокупность (0,11 [1], где О-
объект; I) - субъект; Р - процесс и £ -информационная среда проектирования.
Результат проектирования - представление
ооъекта проектирования в форме
комплекта технической документации, оговоренной
