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

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

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