Опыт автоматизации процессов проектирования, тестирования и документирования программного обеспечения технических систем реального времени

А.М. Денисов,
студ.,
МИФИ, г. Москва,
 В.В. Макаров,
с.н.с, к.т.н., доц., makarov@ipu.ru,
ИПУ РАН, г. Москва

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

 

Experience of application of software product family IBM Rational Rhapsody, focused creation of the software for the market of real time systems and built in systems is considered. This product family on the basis of the unified modeling language (specification UML 2.2) realizes the approach of model driven development (MDD). Researching this system on test examples, models of a stop watch, a dishwasher, the radio receiver, we have received practical experience on generation of the completed applications in C ++ and Java languages. Rather curious there was a mechanism of model animation when at code generation it is possible to specify that it is necessary to create the animated version of the application. In this case in the behavioral code realizing of finite state machine (FSM) diagrams and the diagram of sequences, corresponding instructions are inserted. The development framework reflects, at performance of the program, change of a condition of the application in the corresponding diagram.

Введение

За рубежом наблюдается широкое применение концепции разработки программного обеспечения по управляемым моделям (Model Driven Development – MDD) с использованием нотации унифицированного языка моделирования UML и методов объектно-ориентированного программирования [1,2]. Такой интерес к концепции MDD, вызван тем, что процесс разработки на основе проектной документации не способен более обеспечить предсказуемое создание ПО для встраиваемых устройств и своевременный вывод на рынок новых продуктов.

Пакет Rhapsody является визуальной средой разработки приложений реального времени для встраиваемых систем. В основу положена концепция разработки управляемой моделью – MDD. Rhapsody решает глобальные задачи разработки ПО. Основная - это свести этапы анализа, проектирования, кодирования и тестирования ПО в один технологический процесс на основе модели проектируемой системы. Отсюда и название технологии. На этапе анализа образ модели зарождается, к этапу тестирования модель принимает окончательную форму. Все участники разработки: аналитик, проектировщик, кодировщик и тестер работают с единой документированной моделью, это облегчает их взаимодействие, снижает количество ошибок, автоматизирует кодирование, ускоряет тестирование, повышает общую производительность труда.

Стоит особо отметить наличие в пакете Rhapsody автоматического тестового генератора для полученного исходного кода – ATG(Automatic Test Generator) и подсистемы генерации документации для разрабатываемого ПО (ReporterPlus) по различным шаблонам, в том числе и отвечающей стандартам. Функционирование всех названых компонентов было проверено на моделях ряда устройств [3].

Разработка приложений с генерацией кода на Java

В среде разработки Rational Rhapsody (использовались версии 7.1 и 7.5.1) были реализованы модели таких технических устройства, как секундомер и радиоприемник. При установке пакета Rhapsody требуется, чтобы в системе была установлена среда для визуальной разработки ПО на языке Java – Eclipse или NetBeans.  Устанавливая пакет Rhapsody, можно выбрать лишь часть необходимых компонентов вместо полной установки.

После установки компилятора необходимо прописать путь к нему в системной переменной Path. Также необходимо подключить библиотеки Rhapsody, без которых невозможно запустить никакое приложение, созданное в нем. Для подключения библиотек надо в операционной системе изменить системную переменную Classpath, ее содержимое надо пополнить путями к библиотекам Rhapsody.

В процессе разработки и анализа модели секундомера были выявлены три класса, для которых построена диаграмма классов. В процессе проектирования модели происходит автоматическое генерирование исходного кода. Так при добавлении нового состояния в диаграмму состояний автоматически система Rhapsody производит редактирование исходного кода. При удалении какого-либо состояния также производится автоматическое редактирование исходного кода.

В Rhapsody можно редактировать вручную сгенерированный код. Например, можно изменить описание какого-либо класса в исходном коде. Те изменения, которые были произведены в исходном коде, автоматически будут отражены на самой модели. Однако, в таком направлении изменения не всегда возможны.

В своем арсенале Rhapsody имеет так называемый «Активный редактор кода». С его помощью можно быстро находить участки сгенерированного кода, соответствующие тому или иному элементу модели. Нажатием на какую-либо связь в диаграмме классов в активном редакторе кода сразу отображается часть кода, где описывается эта связь. При нажатии на какой-либо метод из обозревателя модели активный редактор кода автоматически отображает реализацию выбранного метода. Здесь же, в исходном коде, можно отредактировать реализацию этого метода. Соответствующие изменения происходят в свойствах метода, если открыть его через модель. Соответственно, можно насчитать уже два метода, с помощью которых можно добавить реализацию для метода класса. Третьим способом является использование блок-схем. Блок-схема это специальная диаграмма для описания алгоритмов и процессов. При создании блок-схемы для выбранного метода происходит генерирование соответствующего кода, который мы можем видеть в активном редакторе кода. По результатам работы выяснилось, что в Rhapsody in Java данная функция блок-схемы не производит генерацию кода, в отличие от Rhapsody in C++.

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

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

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

Разработанная модель простого секундомера включает в себя 4 класса, 2 диаграммы классов, 2 диаграммы состояний, 2 диаграммы последовательностей, простой веб-интерфейс. При относительной простоте модели, наличию нескольких диаграмм объем сгенерированного кода имеет внушительные размеры – 2900 строк. Очевидно, что код очень избыточен.

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

Основными были следующие задачи:

В качестве исходных данных имелось описание модели устройства и описание прототипа устройства Radio. В процессе разработки ПО были пройдены все основные этапы разработки:

·         определение требований к системе;

·         проектирование;

·         кодирование;

·         тестирование и отладка.

Этап кодирования в данном случае можно объединить с этапом проектирования, т.к. кодирование выполнялось только для описания основных методов классов. Рассмотрим определение и создание классов, диаграмм. Создание проекта начинается с определения требований к системе. Соответственно, была построена диаграмма прецедентов «Use case diagram» (рис.1). Пользователь может:

1)производить настройку вручную или автоматически (Manual tune и Automatic tune);

2)сохранять частоты (Save frequency);

3)выбирать диапазон частот (Select waveband);

4)выбирать сохраненные частоты (Recall frequency);

Прецедент «Tune to frequency» связан «обобщением» с прецедентами «Manual tune», «Automatic tune» и «Recall frequency» («Tune to frequency»-предок). Прецеденты-потомки используют и дополняют «Tune to frequency» (настройку на частоту).

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

В данной системе были выделены следующие классы: «Waveband», «Radio», «Frequency», «Tuner» , «Display». Первые 3 класса отвечают за программную часть системы, а последние 2 для реализации аппаратной части системы и пользовательского интерфейса.

Класс Radio здесь является композитным классом, включающим экземпляры классов Waveband и Frequency. Каждая часть композитного класса (Radio.theFrequency:Frequency и Radio.theWaveband:Waveband) изображается с числом в верхнем левом углу, обозначающее число входящих экземпляров этого класса в класс Radio. В данном случае, Radio имеет одну собственную частоту и 4 диапазона волн. Radio связано с theWaveband отношением агрегирования. Это позволяет Radio указывать на один уникальный экземпляр Waveband посредством «itsCurrentWaveband» как на текущий диапазон волн (Waveband).

 

рис.1 «Use case diagram» - диаграмма прецедентов

Ниже изображен класс Waveband,он тоже является композитным классом. Этот класс включает 5 экземпляров класса Frequency. Здесь так же используется отношение агрегирования, чтобы связать Waveband с одним индивидуальным экземпляром Frequency (одной частотой), которая будет являться текущей (itsCurrentFrequency).

 

рис.2 «Class diagram» - диаграммы классов Radio и Waveband

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

Следующим этапом разработки является тестирование. Необходимо было работать с автоматическим генератором тестов Rational Rhapsody - ATG (Automatic Test Generator). «Открытием» для нас была ситуация, когда мы обнаружили, что ATG не поддерживает язык программирования Java, хотя в рекламных материалах, в общих руководствах утверждалось все четыре языка (С, С++, Java и Ada) равноправны, т.е. все средства Rhapsody функционируют с проектами, реализованными на этих языках. Выход из данной ситуации был только один – необходимо изначально создавать и тестировать проект с генерацией кода на С, а затем выполнять генерацию кода для Java, что мы и выполнили. Практически при автоматическом тестировании можно получить 100% покрытие проекта:

§  покрытие модели: состояний, переходов, операций, генерации событий;

§  покрытие кода: генерация всех возможных комбинаций входных данных для MC/DC (покрытие условий и ветвей).

Единственное ограничение – время тестирования, его можно как задавать, так и прерывать тестирование в реальном времени.

Следующим этапом работы являлось автоматическое генерирование документации для разрабатываемого ПО. Rhapsody позволяет генерировать документацию в нескольких форматах: HTML, PowerPoint, RTF, DOC. В нашем случае была сгенерирована документация в формате DOC. Генерация документации была произведена на английском языке. Выбрать другой язык для генерации Rhapsody не предоставил.

Документация является полной, что соответствует выбранному шаблону при генерации документации – full documentation. На рис.3 приведен фрагмент результата генерации полной документации для проекта Radio и фрагмент для класса Waveband. Далее шаблон документа должен быть заполнен контекстом, объясняющем на естественном языке значении используемых имен.

 

рис.3 Фрагмент сгенерированной документации для проекта Radio и  класса Waveband

В процессе разработки «Радиоприемника» была создана 1 диаграмма прецедентов, 1 диаграмма классов, 6 диаграмм последовательностей, 1 диаграмма состояний.

Данной системе соответствует сгенерированный исходный код 1230 строк, что в 2,5 раза меньше, чем код более простой системы секундомера. Это результат того, что в системе радиоприемника немного меньше диаграмм. Для диаграммы всегда генерируется значительная часть кода, составляющая каркас. Объем сгенерированного кода секундомера значительно больше радиоприемника. Объём документации для проекта Radio 118 страниц – это вариант полной документации для проекта. Можно задавать и выборочные шаблоны генерации для определенного типа UML диаграмм. Генерация документации – весьма сильная сторона рассматриваемой CASE системы. Известно, как не любят разработчики ПО писать документацию на реализуемый проект. Здесь документ создаётся автоматически по выбираемому стандарту или создается шаблон генерации для нужного стандарта документации на любой стадии проекта, в любой момент. Это с одной стороны позволяет обмениваться информацией между разработчиками, с другой – проводить дополнительную верификацию проекта людьми. В отчете, в частности, приводятся анимационные диаграммы последовательностей – Sequence Diagram, для различных режимов работы/настройки «Радиоприемника».

Заключение

В 1975 г. вышла книга Фредерика Брукса «Мифический человеко-месяц», ставшая своего рода библией разработчиков программного обеспечения во всём мире. Спустя 35 лет после выхода книги, она переиздаётся вновь [4] практически в неизменном виде. Это говорит о том, что многие вопросы инженерии программного обеспечения, поднятые Ф.Бруксом, не решены до настоящего времени. Не один soft по современным оценкам зарубежных специалистов не тестируется более, чем на 60%. Несмотря на долгое использование PLM имеется множество примеров ошибок в проектах. 60-70% IT проектов заканчивается неудачно из-за неудачных требований. В среднем IT проекты на 220% продолжаются дольше, т.е. проект длится в 2-3 раза дольше. Автор книги «как создаются программные системы» начинает анализ с описания «смоляной ямы» программирования, в которой продолжают увязать разработчики программных комплексов, программных продуктов и системных программных продуктов. В 1975 году и спустя 20 лет автор пессимистически смотрел на возможность создания «серебряной пули», которая могла бы произвести революцию в технологии разработки программных систем. Наши опыты по тестированию системы разработки Rhapsody позволяют говорить о том, современные программные продукты, особенно программы, использующиеся в системах управления, в критических системах, должны разрабатываться с использованием таких, как Rhapsody программных средств. Эти средства действительно работоспособны, они существенно повышают надёжность разрабатываемой системы, с их помощью можно получить работоспособный исходный код, пользуясь средствами визуальной разработки. Язык UML и технологии MDA и MDD проникают в практику использования отечественных разработчиков. В ряде московских вузов стали читаться курсы по UML, где студенты знакомятся и c модельно ориентированной разработкой архитектуры (MDA) систем и проектированием систем по моделям (MDD). Конечно, основным камнем преткновения по использованию таких систем является их высокая стоимость. Но если требуется создать не просто программу, а именно программный продукт, то к настоящему времени нет других кандидатов на «серебряную пулю». Создавать свои российские CASE-системы подобного уровня поздно. Мы и так уже сильно отстаем от Запада в области инженерии программного обеспечения. Есть трудности освоения – в основном с помощью метода проб и ошибок. Возможности таких систем весьма обширны, что требует обучения работы с ними.

Литература

1.   Douglass B. P. Real-Time UML Workshop for Embedded Systems. – Oxford, UK, Elsevier Inc., 2007. p.408.

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

3.   Rhapsody Automatic Test Generation (Rhapsody ATG). User Guide. Release 3.2. Telelogic, Massachusetts, 95p.

4.   Брукс Ф. Мифический человеко-месяц или как создаются программные системы. Пер. с англ. – СПб.: Символ-Плюс, 2007. 304с.