Паттерны проектирования встроенных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ ВСТРОЕННЫХ СИСТЕМ

А.Н. Лукичев Научный руководитель - к.т.н., доцент А.Е. Платунов

В статье рассматриваются современные методики проектирования встроенных систем и понятие паттерна проектирования в их контексте. Анализируются проблемы применения паттернов для проектирования встроенных систем и предлагаются пути их решения.

Введение

За последние несколько лет в области встроенных систем (ВсС) существенно возрос интерес к различным подходам и методам высокоуровневого проектирования. Предлагаемые в результате исследований методики призваны решить такие проблемы, как стремительно возрастающая сложность ВсС, их распределенность, расширение номенклатуры элементной базы (в самом широком смысле - от проводников и дискретных электронных компонент печатных плат до технологий программирования и отладки и блоков 1Р/УС систем на кристалле), требования к надежности и работоспособности [4]. Такие методики [1, 2, 3, 6], в основном, имеют следующие тенденции [6]:

• повышение уровня абстракции, на котором осуществляется основной объем проектирования системы;

• повторное использование компонент;

• унификация внешних интерфейсов компонент, разработка масштабируемых архитектур;

• использование различных абстракций, таких как «модель вычислений» [2], позволяющих формализовать не только разработку отдельных компонент ВсС, но и способы их организации в систему.

Высокоуровневое проектирование требует наличия средств, позволяющих адекватно отражать и фиксировать определенные свойства системы на верхних уровнях абстракции. Одним из таких средств является паттерн проектирования [8] как способ решения некоторой технической задачи. Паттерны проектирования успешно применяются в объектно-ориентированном подходе к созданию прикладного ПО в течение как минимум последних 10 лет. Существуют попытки применения паттернов в области встроенных систем.

До сих пор, несмотря на все более частые заявления о необходимости абстрагироваться в проектировании ВсС от закрепления за компонентом системы статуса «программный» или «аппаратный», существует во многом искусственное разделение на «отрасли» разработки аппаратуры и программного обеспечения встроенных систем. В работе указывается на принципиальную близость аппаратных и программных решений и наличие общих механизмов, лежащих в их основе.

В рамках аспектной технологии проектирования ВсС [6, 16, 17] предлагается абстракция «вычислительный механизм». Понятие вычислительного механизма четко до сих пор, однако, не определено. В работе делается попытка конкретизировать это понятие. Указывается на сходство понятий «паттерн проектирования» и «вычислительный механизм» в контексте поведенческого аспекта ВсС.

Формализация паттернов проектирования в вычислительной технике в настоящее время в области ООП ограничена применением нотации ЦМЬ, а в области ВсС зачастую просто отсутствует. В лучшем случае применяются схематические структурные изображения (такие как принципиальная электрическая схема для иллюстрации аппаратного паттерна [5, 12]). В работе обсуждается способ решения этой проблемы для паттернов проектирования ВсС.

Паттерны проектирования

В области ВсС, как и в любой другой области вычислительной техники, не обходится без программирования интерактивных приложений, базирующихся на платформе общего назначения (ПК, пользовательские терминалы, PDA и т.п.). В рамках объектно-ориентированного подхода (ООП) к проектированию такого рода прикладного ПО в последние несколько лет распространилась технология применения так называемых паттернов проектирования [8]. С точки зрения ООП, паттерн представляет собой «описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте» [8]. Таким образом, паттерн представляет собой некий шаблон, по которому строится решение задачи. Задача проектирования при этом обладает в достаточной степени типичностью, т.е. может возникнуть при проектировании разных систем и в разное время. В то же время эта задача существует в контексте, ограничивающем возможность ее возникновения и, следовательно, возможность применения паттерна для ее решения. Согласно К. Александру, впервые употребившему понятие «паттерн» применительно к строительству зданий, «любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это решение можно потом использовать миллион раз, ничего не изобретая заново» [8]. Паттерн, таким образом, заключает в себе положительный опыт решения какой-либо задачи в процессе проектирования, которая потенциально может возникнуть при проектировании других систем.

В области ООП паттерны получили широкое распространение. В настоящее время существуют обширные каталоги паттернов («языки паттернов», например [9]), знание и умение применять наиболее часто используемые из них является требованием, характеризующим базовую подготовку специалиста при приеме на работу, ежегодно проводятся международные конференции PLoP (Pattern Languages of Programs) [10].

Несмотря на большую популярность паттернов проектирования в ООП, а может быть, и вследствие нее, работы по созданию паттернов в проектировании встроенного программного обеспечения ведутся многими группами исследователей, причем не только в рамках объектно-ориентированного подхода (см., например, [11, 12]). Во многих случаях, однако, это попытки адаптации существующих паттернов ООП.

Такие попытки также применяются и по отношению к проектированию аппаратуры, в частности, компонентов «систем на кристалле» (SoC). Дамашевичус и коллеги [7] дают хороший обзор попыткам применения объектно-ориентированных методик к разработке аппаратного обеспечения.

Многие работы в области разработки аппаратных компонент описывают способы решения задач в стиле, сходном с описанием паттерна проектирования [8]: описывается задача или класс задач, контекст, в котором она существует, способ ее решения, а также примеры применения описываемой технологии или методики. Например, Кишиневский и коллеги в [13] приводят методику решения задачи взаимодействия компонент в схеме с потенциально изменяемыми задержками передачи сигналов. Описывается контекст, задача («мотивация»), способ ее решения, а также обсуждаются достоинства, недостатки и перспективы, приводятся примеры применения.

Кроме того, существуют попытки систематизации паттернов проектирования встроенных систем [4] и разработки каталогов («языков паттернов» [8]). В таких каталогах (см., например, [5, 14]) собраны паттерны, решающие задачи разработки как программного, так и аппаратного обеспечения ВсС.

Сложность современных ВсС, их гетерогенность не позволяют проектировщикам создавать систему «с нуля», требуя от них применения ранее накопленного опыта в виде успешных в прошлом технических решений. Эти же особенности заставляют, по мнению многих исследователей [1, 2, 6, 7], повышать уровень абстракции, осуществляя

проектирование путем правильной композиции уже готовых (или в достаточной мере описанных на данном уровне абстракции) компонент. По такому принципу, например, в настоящее время строится проектирование БоС: основная масса компонент системы представляет собой готовые блоки 1Р, которые объединяются в разработанную проектировщиками структуру. Сами 1Р при этом могут подвергаться незначительной «адаптации» под систему. Очевидно, применение паттернов как элементов накопленного успешного опыта должно осуществляться на всех уровнях абстракции проектируемой системы, и в особенности там, где осуществляется основной объем проектирования -на самых верхних уровнях (системном [7], архитектурном [6]). Несмотря на это, практически все попытки разработки, спецификации и систематизации паттернов проектирования ВсС в настоящее время предполагают узкую специализацию под средства разработки (языки программирования, аппаратные платформы, элементную базу). Многими (в том числе и Дамашевичусом [7]), тем не менее, подчеркивается необходимость описания и применения паттернов высокоуровневого проектирования.

Программные и аппаратные решения

Встроенные системы в большинстве своем характеризуются тесным сопряжением программных и аппаратных решений. Проектирование ВсС практически всегда включает реализацию как программной, так и аппаратной части. Программное обеспечение встроенных систем взаимодействует с аппаратурой: датчиками и исполнительными устройствами. Встроенные системы создаются с целью взаимодействия с физическим миром - сбора информации и управления объектами посредством исполнительных устройств. Часть этого взаимодействия (отдельные его элементы) реализуется при проектировании аппаратным, а часть - программным обеспечением. Это разделение функциональности обычно может иметь при проектировании аппаратуры несколько вариантов, так что выбор конкретного из них зависит от решений проектировщика и доступной ему элементной базы. Современные методы (например, [1, 2, 6]) предлагают осуществлять основной объем проектирования на уровнях, не зависящих от программно-аппаратной дихотомии, проясняя во многих случаях вопрос разделения HW/SW и «отодвигая» это разделение на более поздние этапы проектирования, когда система почти готова в виде спецификаций.

Зачастую поведение компонента на системном уровне вообще не зависит от того, как он будет реализован - программно или аппаратно. Спецификацию его поведения можно отобразить как на «программную», так и на «аппаратную» платформу [2, 6], причем с одинаково устраивающими проектировщика выходными характеристиками. Кроме того, в последнее время становится все сложнее отличить программное обеспечение от аппаратного, особенно с развитием технологий реализации аппаратных проектов на ПЛИС. Применение языков описания аппаратуры, таких как УНОЬ, Уеп1о§ (в особенности Бу81ешУеп1о§), БуБ1ешС, ШБЬ, фактически стирает четкую грань между «программированием» поведения и созданием аппаратного блока из имеющихся в ПЛИС ресурсов. В случае применения средств высокоуровневого описания (например, при проектировании на Бв1еге1 или в САПР БСЛВБ [15]), спецификация компонента может быть автоматически синтезирована как в ПО, так и в аппаратуру. С точки зрения автора, при проектировании встроенных систем правильнее говорить не о «программности» или «аппаратности» компонента, а о степени последовательности либо параллельности реализуемых им вычислений.

Между тем большинство исследованных автором паттернов, относящихся к проектированию ВсС, четко формулируют свою принадлежность к «программному» или «аппаратному» контексту. Очевидно, такие паттерны найдут ограниченное применение

в методиках проектирования, делающих акцент на уровни абстракции, инвариантные к HW/SW дихотомии.

Аспектная технология. Вычислительный механизм

В рамках аспектной технологии проектирования ВсС [6, 16, 17] предложен взгляд на проектируемую систему с разных точек зрения (в рамках различных аспектов). Каждый такой аспект учитывает лишь определенный ряд взаимосвязанных свойств системы. Примерами аспектов могут служить: вычислительный или поведенческий [6] аспект, структурный, функциональный, конструктивный, надежностный, инструментальный, экономический аспекты. В каждом конкретном случае для проектировщиков может оказаться важным произвольный набор таких аспектов, причем суть любого из них (состав свойств системы в рамках аспекта) также может быть произвольной. Принципиальным является лишь «полнота» аспекта, т.е. самодостаточность получаемых в его рамках моделей системы [16]. При таком подходе возможна независимая разработка системы целиком в рамках одного из ее аспектов [16], например, полная спецификация поведения системы в терминах некоторой вычислительной платформы, т.е. ее реализация на выбранной платформе.

Процесс проектирования ВсС в рамках этой технологии, таким образом, охватывает и рассматривает различные сферы деятельности коллектива проектировщиков: не только разработку непосредственно вычислительной ее части, но и применение определенных инструментальных технологий, «процессуальное» обеспечение проектирования (спецификация требований, контроль версий, учет дефектов и изменений), другие виды деятельности. Зачастую такие виды деятельности, остающиеся как бы на втором плане по отношению к разработке поведения системы, являются важными не менее самой разработки и во многом определяют ее успех. В рамках этих «сопряженных» с проектированием поведения видов деятельности у каждого коллектива, очевидно, есть некоторый накопленный опыт, в том числе и положительный: применяемые технологии внутрисхемного программирования, отладки аппаратных проектов, удачные конструкторские решения, «любимая» система контроля версий, стратегия развития и продвижения на рынок продукта. Паттерны как средство спецификации и сохранения положительного опыта могли бы выступать еще одним инструментом проектирования (в дополнение к абстракциям, перечисленным в [17]) в рамках соответствующего аспекта. Применяя паттерны проектирования в рамках некоторого аспекта системы (например, удачный вариант размещения компонентов на печатной плате, который был применен ранее для платы с аналогичным составом компонентов), можно добиться эффекта, аналогичного эффекту от паттернов в области ООП [8, 9, 10]. Грамотное применение собственных паттернов для различных аспектов одной и той же системы позволит значительно повысить эффективность проектирования.

Основное внимание в проектировании все же уделяется поведенческому аспекту ВсС. В рамках этого аспекта решаются проблемы организации вычислительного процесса, взаимодействия различных компонент системы в части обмена инструкциями и данными. Аспектная технология проектирования ВсС предлагает термин вычислительный механизм, который, хотя и употребляется в [6, 16, 17], но не имеет четкого определения обозначаемого им понятия. В [18] вычислительные механизмы понимаются как «технические решения из различных областей в абстрактном представлении». Далее автор статьи проясняет смысл сказанного: «основываясь на приведенном выше определении механизма, данная абстракция играет роль основного «кирпичика» в организации вычислительного процесса. <...> вычислительный механизм решает частную задачу, например, буферизация данных, декодирование управляющего слова, выборка и

анализ команды, кэширование информационного потока». Вычислительный механизм, таким образом:

• решает некоторую частную техническую задачу;

• специфицирован в абстрактном виде, т. е. предназначен для отображения на конкретные случаи решения задач;

• является элементом организации вычислительного процесса в системе.

Исходя из вышесказанного, очевидна близость, если не идентичность, понятий паттерна проектирования и вычислительного механизма в контексте поведенческого аспекта ВсС. Предлагается рассматривать эти два термина в данном контексте как взаимозаменяемые.

Множество предлагаемых паттернов проектирования ВсС, в особенности попытки применения паттернов к проектированию аппаратуры, используют для спецификации задачи и ее решения нотацию ЦМЬ, которая широко используется при спецификации паттернов в ООП. Очевидно, семантика языка заставляет разработчика подстраивать элементы Н^ проекта под понятия ООП: класс, объект, наследование, интерфейс и т.д. Во многих случаях наблюдаются попытки расширить нотацию ЦМЬ там, где невозможно отождествить понятия аппаратного обеспечения и ООП (например, [7]). Существуют, однако, паттерны, в которых используются более адекватные языки [5]. Ас-пектная технология и некоторые другие методы проектирования [2] используют понятие модели вычислений [17] для отражения системы правил, понятий и средств, в рамках которых организуется вычислительный процесс. В рамках модели вычислений для формальной спецификации системы выбирается наиболее адекватный язык, в терминах которого отображается вычислительный процесс (например, известные графические диаграммы для представления конечных автоматов Мили или Мура или текстовый язык Бв1еге1 для спецификации синхронно-реактивной системы). Очевидно, и спецификация паттерна должна содержать описание технического решения в терминах выбранной модели вычислений. Это, в свою очередь, позволит напрямую применять паттерны в конкретных моделях, подвергая их формальное описание лишь незначительной адаптации под конкретную задачу. Язык, используемый для спецификации, при этом может быть любым подходящим для применения в рамках модели вычислений: преобразования описаний в другой синтаксис в этом случае не должны быть сложными и могут осуществляться как вручную проектировщиком, так и автоматически трансляторами (при условии формальности синтаксиса).

Спецификация вычислительного механизма

Request start / Start, Acknowledge

Request start / Deny

Request status / Report ready

Complete / Report ready

Request status / Report busy

Рис. Асинхронный интерфейс компонента, выполняющего максимум одну операцию одновременно

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

В соответствии с механизмом, компонент может находиться в двух состояниях: готов к выполнению операции («Ready») и выполняет операцию («Busy»). Переходы между этими состояниями осуществляются по следующим условиям:

• Request start - запрос начала операции от клиента;

• Request status - запрос состояния выполнения операции от клиента;

• Complete - завершение выполнения операции.

При выполнении переходов компонент производит следующие действия:

• Start - начать выполнение запрошенной операции;

• Acknowledge/Deny - подтвердить/отклонить запрос;

• Report ready/busy - сообщить о готовности либо неготовности к выполнению.

Очевидно, паттерн не оговаривает особенности и количество выполняемых операций, способ передачи данных о запросе и о результате, состав этих данных, количество клиентов и возможность одновременного поступления запросов, а также многие другие особенности. Однако это и не требуется. Паттерн описывает абстрактный принцип построения внешнего интерфейса компонента, конкретное наполнение этого интерфейса осуществляется в результате применения паттерна при проектировании той или иной системы. Паттерн в достаточной степени абстрактен, так, что он может описывать интерфейс как компонента, потенциально реализованного программно, так и потенциально аппаратного компонента. В самом деле, Request start и Request status могут быть программными вызовами некоторого модуля, результатами которых могут являться коды возврата вызовов соответственно Acknowledge/Deny и Ready/Busy. Действие Report ready в результате окончания выполнения операции может являться программным callback-вызовом клиента, запросившего выполнение операции. В другом же случае действия Request start и Request status могут быть соответственно записью определенного значения и чтением из порта периферийного блока микропроцессора. При этом компонентом, к внешнему интерфейсу которого применяется паттерн, является периферийный блок, а клиентом является программный модуль-драйвер блока. Действие Report ready после завершения операции может быть запросом на прерывание к микропроцессору.

С другой стороны, паттерн в достаточной степени конкретен, чтобы зафиксировать отношения, которые могут возникнуть между компонентом и его клиентом. В частности, компонент не может выполнять одновременно более одной операции: после перехода в состояние «Busy» на любой новый запрос компонент выдает отказ. Также паттерн предусматривает применение в тех случаях, когда не предполагается возникновение ошибки при начале или в ходе выполнения операции: на запрос о начале в состоянии «Ready» компонент всегда подтверждает начало операции, а после начала операция всегда завершается. Кроме того, паттерн не предусматривает прерывание операции после начала ее выполнения. Таким образом, спецификация паттерна на рисунке накладывает некоторые довольно конкретные ограничения на отношения компонента и его клиентов, фиксируя способы взаимодействия с ним в системе. Применение паттерна, следовательно, представляет собой процесс фиксации определенных свойств вычислительного процесса, что, в свою очередь, является элементарным действием при проектировании поведенческого аспекта ВсС [16].

Заключение

Хотя аспектная технология проектирования ВсС находится в настоящее время на этапе своего формирования [1б], она уже может быть признана, по крайней мере, перспективной [б]. Многие вопросы, обсуждаемые в рамках данного метода проектирования, до сих пор не решены. В частности, нет четкого определения понятию «вычислительный механизм». В данной работе предлагается отождествить это понятие с паттерном проектирования в рамках поведенческого аспекта ВсС.

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

• четкое разделение задач (и, соответственно, решений) на «программные» и «аппаратные» на фоне развития методов проектирования ВсС, стирающих эту границу. Отсутствие спецификаций паттернов на системном, не зависящем от этого разделения, уровне, а потому, с развитием упомянутых методов, бесперспективность существующих паттернов;

• отсутствие способа формализации паттернов проектирования, обеспечивающего их применение в формальных спецификациях проектируемых систем. Существующие попытки адаптировать для этих нужд язык UML (объектно-ориентированный по природе) вынуждают разработчиков прибегать к различным ухищрениям: расширять язык, находить соответствие понятий из разных моделей вычислений и т.п. По мнению автора, для спецификации решений в области ВсС, пусть и абстрактных, доступно достаточное количество более адекватных формальных языков (см., например, [19]).

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

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

Литература

1. Alberto Sangiovanni-Vincentelli. Defining Platform-Based Design // EEDesign of EETimes, February, 2002, http://www.eedesign.com/features/exclusive/OEG20020204S00б2 (электронное издание).

2. Edward A. Lee, Stephen Neuendorffer, Michael J. Wirthlin. Actor-Oriented Design of Embedded Hardware and Software Systems // Journal of Circuits, Systems and Computers, No. 3, 2002, pp. 231-2б0.

3. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.-M. Loingtier, J. Irwin. Aspect-Oriented Programming // Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP 1997), 1997, pp. 327-353.

4. David Kalinsky. Design Patterns for High-Availability Embedded Systems // Embed-ded.com, 2002, http://www.embedded.com/story/QEG20020729S0030 (электронное издание).

5. Michael J. Pont, Royan H.L. Qng, Chinmay R. Parikh, Ridwan Kureemun, Chen Pang Wong, William Peasgood, Yuhua Li. A Selection of Patterns for Reliable Embedded Systems // Proceedings of EuroPlop '99, Kloster Irsee, 1999, http://www.le.ac.uk/engineering/mip9/europlop99mjp.pdf

6. Постников Н.П. Поведенческий и инструментальный аспекты проектирования встроенных вычислительных систем; дисс. канд. технических наук - СПбГИТМО (ТУ), 2004.

7. Robertas Damasevicius, Giedrius Majauskas, Vytautas Stuikys. Application of Design Patterns for Hardware Design // Proceedings of 40th Design Automation Conference, Anaheim, ACM Press, 2003, pp. 48 -53.

8. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software // Addison Wesley, 1995, 395 pages.

9. Ward Cunningham et al. Portland Pattern Repository, http://c2.com/cgi/wiki7PortlandPatternRepository

10. Hillside Group, http://hillside.net

11. A. Corsaro, D. Schmidt, R. Klefstad, C. O'Ryan. Virtual Component: A Design Pattern for Memory-Constrained Embedded Applications // Proceedings of 9th Conference on the Pattern Languages of Programs, 2002, http://doc.ece.uci.edu/publications/virtual_component.pdf

12. S. Key, M. Pont, S. Edwards. Implementing Low-Cost TTCS Systems Using Assembly Language // Proceedings of EuroPLoP, 2003, http://www.le.ac.uk/eg/mjp9/sakep03.pdf

13. Jordi Cortadella, Mike Kishinevsky, Bill Grundmann. Synthesis of Synchronous Elastic Architectures // Proceedings of 43rd Design Automation Conference, ACM Press, 2006, pp. 657 - 662.

14. Embedded Design Pattern Catalog, http://www.eventhelix.com/RealtimeMantra/PatternCatalog/

15. G. Berry. The Foundations of Esterel // Proof, Language and Interaction: Essays in Honour of Robin Milner, MIT Press, 2000, pp. 425-454.

16. Платунов А.Е., Постников Н.П. Единое проектное пространство плюс аспектная технология - перспективная парадигма проектирования встраиваемых систем // Научно-технический вестник СПбГУ ИТМО. Выпуск 11. Актуальные проблемы анализа и синтеза сложных технических систем. СПб: СПбГУ ИТМО, 2003ю

17. Платунов А. Е. Архитектурные абстракции в технологии сквозного проектирования встроенных вычислительных систем // Научно-технический вестник СПбГИТМО (ТУ). Выпуск 6. Информационные, вычислительные и управляющие системы. -СПб: СПбГИТМО (ТУ), 2002.

18. Платунов А.Е. Роль вычислительных моделей и механизмов в проектировании встроенных систем // Научно-технический вестник СПбГУ ИТМО. Выпуск 14. Информационные технологии, вычислительные и управляющие системы. СПб: СПбГУ ИТМО, 2004.

19. Stephen A. Edwards. Languages for Digital Embedded Systems - Kluwer Academic Publishers, Boston, 2000, 306 p.