Модели технических устройств и их динамическая отладка

В.В. Макаров,
с.н.с, к.т.н., makarov@ipu.ru
ИПУ РАН, г. Москва

В докладе рассматриваются модели несложных технических устройств разработанных на языке UML 2.2 по технологии MDD: модель автомата по приготовлению и продаже кофе, модель радиоприёмника, модель посудомоечной машины. Модели устройств имеют интуитивно понятный интерфейс (GUI), позволяющий пользователю (разработчику или заказчику системы) с одной стороны в реальном времени оценить возможности проектируемых устройств, соответствие техническому заданию, с другой стороны выполнить динамическую отладку проектируемых систем. Используя средства быстрого создания прототипов, визуальной отладки и выполнения модели, с помощью IBM Rational Rhapsody удалось получить конечные продукты, соответствующие заявленным требованиям. По визуальным UML-моделям был сгенерирован готовый к исполнению программный код на языке C++.

Models of simple technical devices developed on language UML 2.2 on technology MDD are considered: model of coffee machine, radio receiver model, dishwasher model. Models of devices have intuitively clear interface (GUI), allowing the user (to the developer or the customer of system) on the one hand in real time to estimate possibility of projected devices, conformity to the technical project, on the other hand to execute dynamic debugging of projected systems. Using means of fast creation of prototypes, visual debugging and model performance, by means of IBM Rational Rhapsody it was possible to receive the end-products corresponding to declared requirements. On visual UML-models the program code ready to execution in language C ++ has been generated.

Введение

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

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

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

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

Верификация модели технического устройства

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

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

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

В UML отсутствует отдельная сущность с названием «требование». Хотя варианты использования, диаграммы последовательности, конечные автоматы, диаграммы деятельности и ограничения разных видов могут использоваться для моделирования свойств требований, отдельная сущность с названием требование отсутствует. По этой причине данная сущность была добавлена в языке SysML (Systems Modeling Language – язык моделирования систем), а IBM Rational Rhapsody (использовалась версия 8.0) позволяет нам добавлять элементы требований в моделях.

Panel Diagram модели автомата по приготовлению и продажи кофе

Рассмотрим процесс динамической отладки системы управления автомата по приготовлению и продаже кофе с использованием человеко-машинного интерфейса – ЧМИ на упрощенной модели этого автомата (рис.1).

рис.1. Интерфейс модели кофе-машины. Состояние – включено.

Упрощение модели системы управления автомата заключается главным образом в том, что, во-первых, приготавливается только один вид напитка, и, во-вторых, не анализируется вид монет, вводимых в автомат. Представлен интерфейс, выполненный по технологии быстрой разработки, что позволяет продемонстрировать заказчику прототип системы буквально на следующий день после постановки задачи и согласования варианта технического задания к системе управления.

рис.2. Интерфейс модели кофемашины – Panel Diagram,одна из UML диаграмм

Ряд элементов интерфейса модели может отсутствовать на целевой системе, но они важны для функциональной отладки системы. Это представленные на рис.1 в первом ряду слева показания общего количества молока, кофе и емкости кружки, для которой приготавливается напиток; во втором ряду слева динамические индикаторы температуры и давления воды и ниже – счетчик количества проданных кружек напитка. Таким образом, вся левая панель, за исключением модели тумблера включения автомата, несет функциональную отладочную задачу. Правая панель в той или иной форме должна присутствовать на целевой системе. Для реализации функций интерфейса GUI важно, что практически все индикаторы дублированы: сообщения имитационной модели дисплея с бегущей строкой с функцией подсказки пользователю о его действиях и процессе приготовления кофе дублированы имитационными индикаторами процесса приготовления.

В терминах языка UMLGUI системы управления называют Panel Diagram. Рисунок 2 показывает место Panel Diagram в когерентном наборе UML-диаграмм, описывающих с разных сторон это техническое устройство и его систему управления. Любые изменения, которые потребуется сделать в проекте системы, будут учтены и отражены в интерфейсе пользователя – Panel Diagram.

Кратко рассмотрим, что разработчик может верифицировать с помощью анимационной модели интерфейса передней панели устройства. Во-первых, следует убедиться в том, что органы управления на передней панели работают – обратная связь через визуальный контроль органов управления. Во-вторых, следует верифицировать циклограмму органов управления, т.е. в какой последовательности могут быть запущены те или иные процессы. Например, если бросить монетку, не дождавшись соответствующего приглашения, то требуемый процесс приготовления кофе не запустится, аналогично, если не включить автомат тумблером для «Вкл/Выкл». В-третьих, верифицируется в реальном времени подготовка автомата к работе. Изменяются показания температуры и давления во времени для приготавливаемой дозы напитка. На зелёном имитаторе дисплея автомата покупателю выдаются сообщения о ходе процесса приготовления. Далее верифицируется в динамике приготовление напитка – процесс смешивания кофе и молока, формирование дозы напитка на левой инженерной панели с параллельным дублированием отражения хода процесса на модели светодиодных индикаторов. Последний этап динамической отладки системы управления автомата по приготовлению и продажи кофе – это имитация получения покупателем напитка. Затем система управления переводится в исходное состояние готовности, и счетчик приготовленных чашек кофе увеличивается на единицу (левое нижнее табло индикации рис.1). Здесь важно, что разработчик имеет возможность наблюдать развитие процессов во времени и их взаимосвязь.

Panel Diagram моделей радиоприёмника и посудомоечной машины

В модели радиоприёмника также рассмотрим вызов тех или иных функций высокоуровневого API через ЧМИ (рис.3).

Изменение состояния модели наблюдаем на мониторе радиоприёмника – диапазон и значение частоты в мегагерцах.

Модель системы управления радиоприемника позволяет выполнить еще один тип проверки соответствия спецификации – аудио контроль, в дополнении к видео валидации. Для этого на этапе создания модели для частот, хранящихся в памяти радиоприемника, приписываем аудио файлы (*.wav).

Рисунок 4GUIмодели посудомоечной машины еще раз доказывает, что Panel Diagram это одно из описаний взаимосвязанных UML-диаграмм (в верхней части рисунка присутствуют закладки с именами UML-диаграмм других видов). Следующий рисунок 5 показывает основные классы модели посудомоечной машины и связь между ними. Классы Jet, Tankи Heater содержат лишь операции, а класс Dishwasher содержит еще и атрибуты. Класс Dishwasher содержит объект Dishwasher[0]. Если в Навигаторе модели выбрать этот объект, то можно открыть анимированную диаграмму конечного автомата этого объекта. Из анимированной диаграммы конечного автомата можно наблюдать, в каком состоянии находится автомат, а Panel Diagram (рис.4) позволяет контролировать это состояние по GUI.

рис.5. Ключевые абстракции модели посудомоечной машины.

Заключение

Изучать поведение системы позволяет динамический анализ и верификация системы [1-3]. Механизм анимации для UML-диаграмм реализуется следующим образом. При генерации кода указывается необходимость создания анимированной версии приложения, а так же параметры для связи с инструментальной средой разработки по TCP/IP. В этом случае поведенческий код, реализующий диаграммы конечных автоматов (State Machine Diagram), диаграммы последовательностей (Sequence Diagram) и интерфейс передней панели (Panel Diagram), вставляются соответствующие инструкции. При запуске программы она устанавливает TCP-соединение с Rhapsody и во время выполнения сообщает среде разработки своё текущее состояние. Среда разработки отражает изменение состояния приложения на соответствующей диаграмме. Исполнение UML-моделей в режиме анимации называют динамической отладкой.

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

Анимационная модель передней панели устройства существенно проще для восприятия для заказчика системы и верификации для разработчика.

Анимационные модели этих трех видов являются еще одним средством, облегчающим процесс создания качественного и надёжного ПО. Код с анимацией разработчик использует только на этапе отладки и верификации программного обеспечения, а не для использования в целевой системе. В ряде случаев создание имитационной модели Panel Diagram оказывается весьма трудоемкой задачей. Так например, для имитационной модели адаптивной системы управления контроллера, управляющего движением транспортных средств и пешеходов, создание визуальной модели возможных ситуаций движения транспортных средств и пешеходов, т.е. обстановки на перекрестке, вместе с достаточно простыми показаниями светофора и панелью настройки светофора, оказывается сравнимой по сложности с самой системой управления [2, 5].Поэтому в указанном проекте имитационная модель интерфейса системы управления не была построена.

На основе построенных моделей технических устройств созданных средствами визуального моделирования на языке UML 2.2 был сгенерирован работоспособный C++ код.

Литература

1. Грушин А.И. Верификация в вычислительной технике. (Электронный ресурс). – Режим доступа:

http://www.ipmce.ru/about/press/popular/potencial4-2007.

2. Douglass B. P. Real-Time UML Workshop for Embedded Systems. – Oxford, UK, ElsevierInc. 2007.p.408.

3. Новичков А., Костиков А. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational. (Электронный ресурс)/Новичков А., Костиков А. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational.- Режим доступа:

http://citforum.ru/SE/testing/automation_1/index.shtml ,свободный.

4. Зыль С.Н. Проектирование, разработка и анализ программного обеспечения систем реального времени. – СПб.: БХВ - Петербург, 2010. 336с.

5. Макаров В.В. Анализ и проектирование программного обеспечения адаптивной системы управления движением на перекрестке. «Системный анализ и информационные технологии»: труды Пятой международной конференция САИТ 2013 (19-25 сентября 2013, г. Красноярск, Россия):с.129-136, в 2т.Т.2. Красноярск: ИВМ СО РАН, 2013. 435с..