В первая часть учебник Я получил архитектуру системы контроля доступа.
Достигнутый результат уже имеет практическую пользу, но недостаточную, поскольку текущая архитектура не учитывает форматы и типы данных, а также природу компонентов.
В этой части урока я покажу, как проектировать потоки данных в системе и работать с компонентами различного характера.
Компонентные интерфейсы Давайте еще раз посмотрим на систему из первой части.
Мы видим, что компоненты соединены стрелками.
Эти связи пока еще абстрактны и представляют собой простые информационные связи.
Однако мы можем немного снизить уровень абстракции.
Рассмотрим вывод компонента ДБхандлер .
Этот компонент имеет вывод AccessStatus. Попробуем описать это.
Итак, AccessStatus — это связь, содержащая информацию о статусе доступа.
Доступ может быть предоставлен, а может и не быть предоставлен.
То есть это явно булева переменная! Уточним тип этого вывода.
Чтобы сделать это в System Composer, сначала необходимо создать соответствующий интерфейс : 
А затем указываем, что созданный интерфейс назначен порту AccessStatus: 
Данную операцию необходимо провести на всех необходимых портах.
Подведем итоги и выведем следующее утверждение: Создавая интерфейсы и назначая их портам, мы даем разработчикам, которые будут реализовывать систему, точные инструкции о том, какие данные будут использовать разрабатываемые компоненты и какие данные необходимы на выходе.
Еще одним преимуществом System Composer является возможность просмотра потока данных с использованием представлений пользовательской архитектуры.
Архитектурные виды .
Мы можем фильтровать нашу архитектуру по определенным критериям.
В качестве примера возьмем ранее созданный интерфейс.
Давайте создадим представление потока данных AccessStatus. Сначала нужно нажать Моделирование -> Представления архитектуры .
А затем создайте фильтр: 
Здесь указывается имя представления и создается фильтр: выбрать все компоненты, имеющие интерфейс с именем Статус доступа .
После нажатия кнопки Применить мы получим следующую картину: 
Таким образом, использование таких представлений полезно для разработки, так как можно быстро найти необходимые компоненты или ошибки в проекте или потоке данных.
Управление гетерогенными компонентами На этом можно было бы остановиться, потому что на данный момент у нас есть прекрасная системная архитектура, которая помогает в реализации.
Однако есть очень большая проблема — система состоит как из аппаратных средств, то есть физических компонентов, так и из программного обеспечения.
Что это значит? Это значит, что система неоднородна и нам нужно как-то отобразить эту неоднородность.
В System Composer есть специальные функции – это профили И стереотипы .
Для простоты понимания стереотип — это абстрактное описание класса компонентов со свойствами, а профиль — набор стереотипов.
Простой пример — допустим, у нас есть стереотип, описывающий микроконтроллер.
У любого микроконтроллера есть общие свойства: ядро, TDP, напряжение питания, частота и т. д. Именно эти свойства и должны отражаться в стереотипе.
Создадим профиль и необходимые стереотипы: 
Например, я создал стереотип GenericComponent. Вот как это выглядит: 
Здесь важны несколько настроек:
- Applies To - к чему применяется стереотип - к компоненту, интерфейсу, порту или соединению (да, сами соединения, эти стрелочки, тоже можно описать с помощью стереотипа)
- Базовый стереотип – родительский стереотип.
Стереотипы наследуют свойства родительских стереотипов.
- Таблица свойств – здесь задаются пользовательские свойства.
Например, у меня свойство называется Workload, то есть трудозатраты на внедрение.
После того, как мы создали профиль и стереотипы, мы импортируем их в архитектуру и можем начать распределять их по ее элементам: 
В результате у меня получилась вот такая картина: 
Для наглядности я сделал следующее представление: 
Давайте посмотрим на механизм наследования свойств компонентов в действии.
Выделим компонент DoorLock и посмотрим на его свойства: 
Свойство Workload было унаследовано от GenericComponent, но свойство Cost относится к стереотипу HardwareComponent.
Подведем итог этой части: Детализация архитектуры позволяет более полно описать разрабатываемую систему и избежать несогласованности интерфейсов и взаимодействия компонентов.
Использование стереотипов для детализации помогает понять природу компонентов и получить более полное представление о разрабатываемой системе.
В следующей части руководства я расскажу об интеграции System Composer с MATLAB, Simulink и инструментом управления требованиями Simulink Requierements. Теги: #matlab #simulink #simulink #Системная инженерия
-
Как Снизить Затраты На Мобильную Разработку
19 Oct, 24 -
Аудио Модификации Для Android-Смартфонов
19 Oct, 24 -
Виза -> Яндекс Деньги И Т.д.
19 Oct, 24 -
О Новых Успехах Противостояния (Ср Увч!*)
19 Oct, 24 -
Заметки По Нлп (Часть 5)
19 Oct, 24 -
Бюджетная Vds Для Обучения И Развития
19 Oct, 24
