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

Интерфейсы компонентов

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



У этого компонента есть выход AccessStatus. Попробуем описать его. Итак, AccessStatus — это связь, содержащая информацию о статусе доступа. Доступ может быть либо предоставлен или не предоставлен. То есть, это в явном виде булева переменная! Давайте укажем тип этого выхода. Чтобы сделать это в System Composer, сначала надо создать соответствующий интерфейс:



А затем укажем что порту AccessStatus назначен созданный интерфейс:



Эту операцию надо провести над всеми нужными портами. Можно подытожить и вывести такое утверждение:

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

Еще одно преимущество System Composer — это просмотр потока данных с помощью пользовательских представлений архитектур, Architecture Views. Мы можем отфильтровать нашу архитектуру по определенным признакам. В качестве примера возьмем ранее созданный интерфейс. Создадим представление AccessStatus Dataflow.

Сначала надо нажать Modeling -> Architecture Views. А затем создать фильтр:



Здесь задано имя представления, а также создан фильтр: выбрать все компоненты у которых есть интерфейс с именем AccessStatus. После нажатия кнопки Apply получим такую картинку:


Таким образом, использование таких представлений полезно для разработки, так как можно быстро найти нужные компоненты или ошибки в проекте или потоке данных.

Управление разнородными компонентами

Можно было бы и остановится на достигнутом, ведь на текущий момент у нас есть красивая архитектура системы которая помогает в реализации. Однако, есть очень большая проблема — система состоит из железа, то есть физических компонентов, так и из софта. Что это означает? Это означает, что система неоднородна и нам надо каким-то образом отобразить данную неоднородность. В System Composer есть специальные функции — это профили и стереотипы. Для простоты понимания — стереотип — это абстрактное описание класса компонентов со свойствами, а профиль — это коллекция стереотипов. Простой пример — допустим, у нас есть стереотип, описывающий микроконтроллер. У любого микроконтроллера есть общие свойства — ядро, TDP, напряжение питания, частота и т.д. Именно эти свойства и должны быть отражены в стереотипе.

Создадим профиль и нужные стереотипы:


Например, я создал стереотип GenericComponent. Вот как он выглядит:



Здесь важно несколько настроек:

1. Applies To — то, к чему применяется стереотип — к компоненту, интерфейсу, порту или соединению (да-да, сами соединения, эти стрелочки, тоже можно описать с помощью стереотипа)
2. Base Stereotype — родительский стереотип. Стереотипы наследуют свойства родительских стереотипов
3. Таблица свойств — здесь задаются пользовательские свойства. Например, мое свойство называется Workload, то есть трудозатраты на реализацию

На этом стереотипе базируются 2 других стереотипа HardwareComponent — для железа, и SoftwareComponent, для софта.

После того как мы создали профиль и стереотипы мы импортируем их в архитектуру и можем начать раскидывать по ее элементам:



В итоге я получил такую картинку:


Для ясности, я сделал следующее представление:


Посмотрим на механизм наследования свойств компонентов в действии. Выберем компонент DoorLock и посмотрим на его свойства:


Свойство Workload было унаследовано из GenericComponent, а вот свойство Cost — специфично для стереотипа HardwareComponent.

Подведем итоги данной части:

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

В следующей части туториала я расскажу об интеграции System Composer с MATLAB, Simulink и инструментом управления требованиями, Simulink Requierements.