В этой связи вполне естественно появление языка SysML — клона UML, позволяющего проектировать программно-аппаратные комплексы.

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

Изменения были специфицированы в виде профиля UML 2.0 и названы новым именем — SysML (System Modeling Language). В спецификацию этого языка вошли новые диаграммы — требований, внешних и внутренних блоков, времени, параметрическая. Сохранены следующие диаграммы UML: вариантов использования, конечных автоматов (в прежних версиях ее называли «диаграммой состояний»), деятельности и последовательности.

Формализация требований к проектируемой системе

Для описания требований к проектируемой системе и определения взаимосвязей между ними в SysML используют классическую UML-диаграмму вариантов использования, собственную диаграмму требований и различные параметрические ограничения. Для диаграммы требований в SysML определено несколько стереотипов (см. таблицу).

Теперь посмотрим, как выглядит диаграмма требований на языке SysML. На рис. 1 диаграмма определяет требования к известному предмету — светофору. Мы видим здесь базовое требование (ID 1.0), которое можно разбить на два подтребования: «У светофора должны быть три лампочки — красная, желтая и зеленая» и «Светофор должен управляться извне». Требование 1.2 обуславливает еще два требования: «Светофор должен быть способен получать с внешнего устройство команды переключения светового сигнала» и «Светофор должен извещать внешнее устройства о всех неисправностях в своей работе». Кроме того, требование 1.1 верифицируется контрольным примером, реализованным с помощью функции work(), которая возвращает значение типа Boolean. А требования 1.2.1 и 1.2.2 выполняются с помощью интерфейсов ITrafficLight и ITrafficLightObserver соответственно.

При разработке модели на языке SysML важно отслеживать ее соответствие требованиям к разрабатываемому продукту — обеспечивать трассировку требований. Эта задача осложняется тем, что на протяжении жизненного цикла проекта для описания требований используют разнообразные форматы, инструменты разной сложности и функциональности (Excel, Adobe FrameMaker, Telelogic DOORS, IBM Rational RequisitePro и др.). Небольшое число требований еще поддается управлению вручную, но когда они исчисляются сотнями или тысячами, нужны специальные инструменты. При выборе инструмента управления следует обратить внимание на то, позволяет ли он организовывать сложные наборы требований из нескольких источников (формировать из них единую связанную среду управления) и создавать предназначенные для наглядного анализа отчеты о влиянии требований на модель. Впрочем, вопрос трассировки требований относится не столько к языку SysML, сколько к поддерживающим его инструментам.

Описание структуры системы

После того как требования к разрабатываемой системе специфицированы, моделируется ее структура. Для этой цели в SysML вместо классических UML-диаграмм (классов, объектов и др.) используются диаграммы внутренних и внешних блоков — модульных единиц, инкапсулирующих атрибуты, операции и ограничения. Можно сказать, что блок является своего рода расширением объекта. Диаграмма внешних блоков (рис. 2) напоминает UML-диаграмму классов.

Из рис. 2 видно, что блок TrafficLight, реализующий уже известные нам по диаграмме требований (см. рис.) интерфейсы ITrafficLight и ITrafficLightObserver, имеет композитную связь с блоком управления светофором (TrafficLightControl) и тремя лампочками разного цвета (блоком LightBulb). Стоит обратить внимание на маленький квадрат с надписью «ext». Он обозначает порт, а надпись — его имя. Портом называют именованную точку соединения, которая позволяет некоему модулю (назовем его «сервером») предоставлять интерфейс за пределами своего класса без необходимости показывать клиенту внутреннюю структуру этого класса. Внешний модуль («клиент») может «общаться» с «сервером» через порт, ничего не зная о «сервере». Действительно, для подключения клавиатуры («клиента») к компьютеру («серверу») ей не надо знать структуру компьютера.

Обратите внимание: на рис. 2 интерфейсы, доступные через порт «ext», изображены разными значками. При этом значок интерфейса ITrafficLight показывает, что блок реализует данный интерфейс и что к порту можно подключаться для доступа к соответствующим сервисам. Значок интерфейса ITrafficLightObserver свидетельствует, что подключающееся к порту устройство должно реализовывать данный интерфейс. Такие обозначения имеют аналогию с разъемами, соответственно, «вилка» и «розетка». Главное достоинство порта состоит в том, что с его помощью очень удобно специфицировать взаимодействие между подсистемами.

Диаграммы блоков и расширяющие их параметрические диаграммы обеспечивают SysML-модели четкость структуры, необходимую для моделирования аппаратных и программно-аппаратных средств. А поскольку SysML устанавливает строгие правила, которым должна соответствовать модель, появляется возможность эффективного статического анализа моделей — их проверки для обнаружения семантических и синтаксических ошибок, противоречий и конфликтов. Среди проблем, выявление которых обеспечивает статический анализ, можно указать следующие: неразрешенные, циклические и пустые ссылки, неподходящие интерфейсы или параметры, передаваемые одним элементом другому, отсутствие сопроводительной информации (например, описания блока), ссылки на несуществующие элементы или не имеющие ссылок элементы.

Некоторые из проблем могут иметь катастрофические последствия на этапе реализации модели, но обнаружить их удается лишь при исчерпывающей проверке либо после завершения реализации. Инструменты, обеспечивающие полномасштабный статический анализ, дают пользователю возможность поддерживать корректность и целостность модели, выполнять одну или несколько проверок в любой момент. Кроме того, необходимо, чтобы пользователи могли сами определять методы проверки модели, например на основе отраслевых стандартов (ОСТ) или стандартов предприятия (СТП).

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

Описание и имитация поведения системы

Для описания поведенческих аспектов проектируемой системы в SysML используются обычные диаграммы UML, такие как диаграммы конечных автоматов (рис. 3). Так в UML 2.0 называют то, что в UML 1.x именовали диаграммой состояний.

Увы, поведенческие диаграммы сами по себе не гарантируют правильного поведения системы. Правильность реакции системы на события можно проверить на этапе внедрения (что, по понятным причинам, нежелательно) или с помощью имитации. Второй вариант назван динамическим анализом. Разумеется, возможность динамического анализа модели проектируемой системы зависит исключительно от инструмента, реализующего поддержку языка моделирования.

Весьма интересную, по нашему мнению, поддержку UML и SysML обеспечивает Rhapsody Systems Designer компании I-Logix. С помощью Rhapsody разработчики могут «оживлять» модели и имитировать их поведение. Удается создавать из модели имитационные макеты и запускать их в разных сценариях вручную либо с помощью специального средства — Rhapsody Test Conductor. Разумеется, имитация может служить и для оценки влияния внесенных изменений — с целью сравнения моделей или возврата к более ранним версиям.

Чтобы представить себе возможности исполнения моделей SysML, обеспечиваемые Rhapsody, достаточно обратить внимание на элементы панели управления исполнением (рис. 3).

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

Напомним, что SysML, как и UML, — это язык моделирования, а не методология. Порядок применения SysML на практике определяет процесс, например RUP (Rational Unified Process), MSF (Microsoft Solutions Framework) или XP (Extreme Programming). В области встраиваемых систем «жесткого» реального времени более всего распространен Harmony. Согласно ему, «процесс — это спецификация серии последовательных действий, выполняемых группой взаимодействующих специалистов, в результате которой создается когерентное множество артефактов, и одним из них является требуемая система». Harmony включает в себя макроцикл и цикл инкрементной разработки (так называемый «микроцикл» — рис. 4).

Как видно из рис. 4, в микроцикл Harmony входят несколько фаз разработки:

  • анализ — выявление и описание характерных свойств системы;
  • дизайн (или проектирование) — оптимизация модели с целью приведения ее в соответствие с необходимыми QoS;
  • трансляция — реализация корректно работающих элементов системы (автоматически или вручную);
  • тестирование — проверка полученного на предыдущих фазах прототипа системы;
  • Party! — оценка достигнутого, планирование следующего прототипа и дальнейших действий в ходе проекта (например, конфигурационного менеджмента).

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

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

Соответственно, на каждом последующем витке спирали строятся диаграммы, описывающие модель с разных точек зрения. Напомним, что все представления описывают одну модель.

***

Поддержка SysML обычно является дополнительной возможностью инструментов UML. Используя строгость и точность SysML, инструментальные средства реализуют трассировку заданных в разных форматах требований, интегрированный контроль над версиями произвольных модулей проекта, статический анализ логической структуры моделей. А самое замечательное, они проводят динамический анализ моделей путем их исполнения. Все это позволяет достичь главной цели моделирования: проверить правильность технических решений задолго до создания системы, то есть того этапа, на котором исправление ошибок обойдется уже очень дорого.

Сергей Зыль (s.zyl@swd.ru) — преподаватель учебного центра, Андрей Николаев (a.nikolaev@swd.ru) — руководитель отдела развития компании SWD Software (Санкт-Петербург).