Очень краткое введение в SysML или «а куда кобылу запрягать?»

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

В современном ИТ-сообществе имеет место тенденция “к черту нотации!”. Начертили что-то на доске или бумажке, приляпали стикеры, нарисовали стрелочки и побежали скорее реализовывать. И довольно часто этот подход работает гораздо лучше, чем стандартные нотации. Ровно до тех пор, пока переделки делаются быстрее и обходятся дешевле, чем затраты на согласование нюансов.

А если стоимость ошибки высока, как это часто случается в корпоративных информационных системах? Связанные с большим количеством бизнес-процессов, они плохо приспособлены к непрерывному обновлению. Обычно каждое обновление долго проектируется, согласуется со всеми заинтересованными лицами и выкатывается в строго отведенное технологическое “окно”. И если что-то пойдет не так, то служба эксплуатации просто откатит изменение обратно и следующая попытка у вас будет не скоро.​

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

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

Говорят, что Visio поддерживает рисование SysML диаграмм, но надо понимать, что это будут просто картинки для презентаций или иллюстрации к документам, а не инструмент для инженерной работы, которым являются модели. Основное назначение диаграмм, на мой взгляд, это удобный визуальный навигатор по модели. Я пробовал делать модели без диаграмм - с ними практически невозможно работать людям, которые не участвовали в их создании, они не видят структуры и теряются в куче элементов.

Заметная польза от использования SysML появляется при моделировании чего-то более сложного и запутанного, чем один программный компонент, чего-то состоящего из набора программ, информационных систем, интеграционных решений, конфигурируемых платформ и сетевых взаимодействий. Неожиданная сложность, с которой пришлось столкнуться, это высокий уровень абстракции языка. В UML мы моделируем классы, используя Class Diagram, вычислительные узлы на Deployment Diagram. А в SysML основным элементом является блок (block). Что такое блок? Да что угодно. Команда сама должна решить, из каких блоков будет строиться ваша система. И это кажущаяся свобода - большая и глубокая ловушка для слонопотама. Когда речь идет о программной системе можно продолжать моделировать классы в виде блоков, подозреваю, что никаких особенных преимуществ перед UML при этом не возникнет. Но в сложных системах появляется сложность выбора правильного уровня абстракции - на какие логические части разделить систему, что выделить в качестве блоков, как выстроить архитектурные уровни из абстракций. Это сложность не связана непосредственно с языком моделирования, это скорее интеллектуальный барьер. Никакая нотация не избавит вас от необходимости выделения абстракций вашей системы. А попытка моделировать сложную систему сразу на уровне классов сродни попытке моделировать мост, описывая взаимодействие молекул стали.

Блочные диаграммы SysML понравились мне тем, что используемые в них элементы и отношения помогают выделить абстракции, задавая правильные вопросы и направляя мышление. Здесь я очень кратко опишу основные концепции, не вдаваясь в детали и нюансы (а их там немало).

Блок - это основной строительный элемент SysML модели. Блоки используются для описания структурных частей системы или её окружения, таких как стол, мост, компьютер, программа, информационная система и т.п. Блок акцентирует внимание на моделируемой сущности и её связях с другими сущностями, скрывая её внутреннее устройство. Важно - блок моделирует не конкретный экземпляр, а тип сущности, в этом он похож на класс. Для описания отношений между блоками используется Block Definition Diagram.

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

С точки зрения модели блок является составным элементом, он включает в себя набор специализированных элементов, например:

• Часть (part) - это какая-то часть, элемент экземпляра блока, в качестве типа части указывается другой блок

• Порт (port) - это часть блока, посредством которой он как-то взаимодействует с окружающей действительностью - передает или получает информацию/энергию/материю.

• Поведения (Operations Или Behaviors) - какие-то действия, поведения, которые блок может демонстрировать (например, лампочка может светить, машина может ездить, мотор вырабатывать энергию)

На bdd мы лишь описываем блоки, не указывая в деталях как именно они устроены, элементы блока отображаются в отдельных секциях (compartments) в виде текстовых описаний. Для удобства секции могут быть скрыты на диаграмме (при этом они останутся в модели и могут быть использованы в других диаграммах). Для моделирования устройства блоков и отношений между их частями предназначена internal block diagram (ibd), про неё (если в комментариях будет интерес к теме) поговорим в следующий раз.

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

1. Отношение включения означает, что в экземплярах блока присутствуют части, являющиеся экземплярами другого блока (как сиденье является частью стула)

2. Отношение ассоциации означает, что между блоками имеет место какое-то взаимодействие, передача информации/энергии или еще чего-то. Сама ассоциация тоже может иметь тип Блок, показывая каким образом, посредством чего происходит взаимодействие. Например, создавая связь лампочки с системой электроснабжения дома, мы показываем, откуда лампочка получает энергию. А указывая в качестве типа коннектора блок "Электрический провод марки Х", указываем как именно они должны быть связаны.

3. Отношение потока (flow) показывает что между блоками происходит обмен чем-то, в свойствах этого соединения указывается тип сущности (Да-да, опять блок, ну в крайнем случае ValueType), который передаётся между блоками. Мой моделер позволяет на одном коннекторе в диаграмме показать сразу и отношение ассоциации, и отношение потока. Но в модели это два разных отношения.

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

• Из каких частей состоит интересующая нас система?

• Какими отношениями связаны части системы? Какие части "встроены" друг в друга, а какие взаимодействуют друг с другом?

• Посредством чего выстроено взаимодействие? какие инфраструктурные элементы его обеспечивают?

• Чем обмениваются части посредством взаимодействия? откуда "это" берётся, не забыли ли мы какие-то важные отношения?

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