В первой части туториала я получил архитектуру системы контроля доступа. Достигнутый результат уже имеет практическую пользу, но недостаточен, так как сейчас архитектура не учитывает форматы и типы данных и природу компонентов. В этой части туториала я покажу, как проектировать потоки данных в системе и работать с компонентами различной природы.
Посмотрим на систему из первой части еще раз. Мы видим, что компоненты соединены стрелочками. Эти соединения пока абстрактны и представляют простые информационные связи. Однако, мы можем немного снизить уровень абстракции. Рассмотрим выход компонента DBHandler.
У этого компонента есть выход AccessStatus. Попробуем описать его. Итак, AccessStatus — это связь, содержащая информацию о статусе доступа. Доступ может быть предоставлен или не предоставлен. То есть, это в явном виде булева переменная! Давайте укажем тип этого выхода. Чтобы сделать это в System Composer, сначала надо создать соответствующий интерфейс:
А затем укажем, что порту AccessStatus назначен созданный интерфейс:
Эту операцию надо провести над всеми нужными портами. Можно подытожить и вывести такое утверждение:
Создавая интерфейсы и назначая их портам, мы даем разработчикам, которые будут реализовывать систему, точные указания о том, какие данные будут использовать разрабатываемые компоненты и какие данные требуются на выходе.
Еще одно преимущество System Composer – это просмотр потока данных с помощью пользовательских представлений архитектур, Architecture Views. Мы можем отфильтровать нашу архитектуру по определенным признакам. В качестве примера возьмем ранее созданный интерфейс. Создадим представление AccessStatus Dataflow.
Сначала надо нажать Modeling -> Architecture Views. А затем создать фильтр:
Здесь задано имя представления, а также создан фильтр: выбрать все компоненты, у которых есть интерфейс с именем AccessStatus. После нажатия кнопки Apply получим такую картинку:
Таким образом, использование таких представлений полезно для разработки, так как можно быстро найти нужные компоненты или ошибки в проекте или потоке данных.
Можно было бы и остановиться на достигнутом, ведь на текущий момент у нас есть красивая архитектура системы, которая помогает в реализации. Однако, есть очень большая проблема – система состоит как из железа, то есть физических компонентов, так и из софта. Что это означает? Это означает, что система неоднородна и нам надо каким-то образом отобразить данную неоднородность. В System Composer есть специальные функции – это профили и стереотипы. Для простоты понимания — стереотип — это абстрактное описание класса компонентов со свойствами, а профиль – это коллекция стереотипов. Простой пример — допустим, у нас есть стереотип, описывающий микроконтроллер. У любого микроконтроллера есть общие свойства: ядро, TDP, напряжение питания, частота и т.д. Именно эти свойства и должны быть отражены в стереотипе.
Создадим профиль и нужные стереотипы:
Например, я создал стереотип GenericComponent. Вот как он выглядит:
Здесь важно несколько настроек:
На этом стереотипе базируются 2 других стереотипа HardwareComponent – для железа, и SoftwareComponent – для софта.
После того как мы создали профиль и стереотипы, мы импортируем их в архитектуру и можем начать раскидывать по ее элементам:
В итоге я получил такую картинку:
Для ясности я сделал следующее представление:
Посмотрим на механизм наследования свойств компонентов в действии. Выберем компонент DoorLock и посмотрим на его свойства:
Свойство Workload было унаследовано из GenericComponent, а вот свойство Cost специфично для стереотипа HardwareComponent.
Подведем итоги данной части:
Детализация архитектуры позволяет более полно описать разрабатываемую систему и избежать несогласованности интерфейсов и взаимодействия компонентов. Применение стереотипов для детализации помогает понять природу компонентов и получить более полное представление о разрабатываемой системе.
В следующей части туториала я расскажу об интеграции System Composer с MATLAB, Simulink и инструментом управления требованиями, Simulink Requierements.
Интерфейсы компонентов
Посмотрим на систему из первой части еще раз. Мы видим, что компоненты соединены стрелочками. Эти соединения пока абстрактны и представляют простые информационные связи. Однако, мы можем немного снизить уровень абстракции. Рассмотрим выход компонента DBHandler.
У этого компонента есть выход AccessStatus. Попробуем описать его. Итак, AccessStatus — это связь, содержащая информацию о статусе доступа. Доступ может быть предоставлен или не предоставлен. То есть, это в явном виде булева переменная! Давайте укажем тип этого выхода. Чтобы сделать это в System Composer, сначала надо создать соответствующий интерфейс:
А затем укажем, что порту AccessStatus назначен созданный интерфейс:
Эту операцию надо провести над всеми нужными портами. Можно подытожить и вывести такое утверждение:
Создавая интерфейсы и назначая их портам, мы даем разработчикам, которые будут реализовывать систему, точные указания о том, какие данные будут использовать разрабатываемые компоненты и какие данные требуются на выходе.
Еще одно преимущество System Composer – это просмотр потока данных с помощью пользовательских представлений архитектур, Architecture Views. Мы можем отфильтровать нашу архитектуру по определенным признакам. В качестве примера возьмем ранее созданный интерфейс. Создадим представление AccessStatus Dataflow.
Сначала надо нажать Modeling -> Architecture Views. А затем создать фильтр:
Здесь задано имя представления, а также создан фильтр: выбрать все компоненты, у которых есть интерфейс с именем AccessStatus. После нажатия кнопки Apply получим такую картинку:
Таким образом, использование таких представлений полезно для разработки, так как можно быстро найти нужные компоненты или ошибки в проекте или потоке данных.
Управление разнородными компонентами
Можно было бы и остановиться на достигнутом, ведь на текущий момент у нас есть красивая архитектура системы, которая помогает в реализации. Однако, есть очень большая проблема – система состоит как из железа, то есть физических компонентов, так и из софта. Что это означает? Это означает, что система неоднородна и нам надо каким-то образом отобразить данную неоднородность. В System Composer есть специальные функции – это профили и стереотипы. Для простоты понимания — стереотип — это абстрактное описание класса компонентов со свойствами, а профиль – это коллекция стереотипов. Простой пример — допустим, у нас есть стереотип, описывающий микроконтроллер. У любого микроконтроллера есть общие свойства: ядро, TDP, напряжение питания, частота и т.д. Именно эти свойства и должны быть отражены в стереотипе.
Создадим профиль и нужные стереотипы:
Например, я создал стереотип GenericComponent. Вот как он выглядит:
Здесь важно несколько настроек:
- Applies To – то, к чему применяется стереотип — к компоненту, интерфейсу, порту или соединению (да-да, сами соединения, эти стрелочки, тоже можно описать с помощью стереотипа)
- Base Stereotype — родительский стереотип. Стереотипы наследуют свойства родительских стереотипов
- Таблица свойств – здесь задаются пользовательские свойства. Например, мое свойство называется Workload, то есть трудозатраты на реализацию
На этом стереотипе базируются 2 других стереотипа HardwareComponent – для железа, и SoftwareComponent – для софта.
После того как мы создали профиль и стереотипы, мы импортируем их в архитектуру и можем начать раскидывать по ее элементам:
В итоге я получил такую картинку:
Для ясности я сделал следующее представление:
Посмотрим на механизм наследования свойств компонентов в действии. Выберем компонент DoorLock и посмотрим на его свойства:
Свойство Workload было унаследовано из GenericComponent, а вот свойство Cost специфично для стереотипа HardwareComponent.
Подведем итоги данной части:
Детализация архитектуры позволяет более полно описать разрабатываемую систему и избежать несогласованности интерфейсов и взаимодействия компонентов. Применение стереотипов для детализации помогает понять природу компонентов и получить более полное представление о разрабатываемой системе.
В следующей части туториала я расскажу об интеграции System Composer с MATLAB, Simulink и инструментом управления требованиями, Simulink Requierements.