Определения и отношения
В движке EdgeNode геометрия сама по себе не определяет архитектуру. Плоская сеть из узлов и линий становится значимым цифровым двойником только тогда, когда элементам задаётся семантический контекст. Этот контекст формируется с помощью двух механизмов структурного маппинга: Определений (Definitions) и Связей (Relations).
Оба механизма напрямую зависят от активных Контуров (Contours) вашего рабочего пространства — структурных периметров, которые определяют, какие правила применяются к конкретному операционному слою.
Определения узлов: полиморфная типизация
Определение связывает строгий семантический архитектурный тип с базовым ID узла внутри целевых границ контура. Это позволяет одному и тому же узлу менять свою идентичность в зависимости от текущего ракурса, выбранного аналитиком.
Платформа интерпретирует идентификатор как один из четырёх доменных архетипов:
- Процесс (Process):Отражает функциональное выполнение, задачи или вычисления, которые переводят состояния артефактов в потоке.
- Структурная единица (Structural Unit):Отражает корпоративные подразделения, аппаратные границы, команды или организационные отделы.
- Локация (Location):Отображает физические регионы, дата-центры, зоны доступности облака или пространственные ограничения.
- Определение артефакта (Artifact Definition):Связывает узел со специфическим шаблоном структуры данных, моделью ресурса или схемой спецификации.
Связи: многомерные архитектурные соединения
Традиционные рёбра показывают лишь базовую топологию. Связь (Relation) описывает логические зависимости, которые определяют, как именно узлы взаимодействуют внутри конкретных областей периметра.
Связи требуют указания валидной строки идентификации контура. Это гарантирует, что если вы отключите контур или скроете его из области видимости, соответствующие зависимости валидации будут полностью исключены из симуляций движка.
Каждый объект Связи оценивает три бинарных архитектурных флага для анализа соединения узлов:
| Архитектурный флаг | Условие логической оценки | Влияние на движок симуляции |
|---|---|---|
| is_required_by | Строгая проверка жестких блокирующих зависимостей. | Целевой узел не может выполнять внутренние циклы, если исходный узел дал сбой или исчерпал емкость ресурса. |
| is_extension_of | Маршрутизация наследования и композиции. | Исходный узел автоматически наследует базовые свойства задержки и параметры обработки своего родительского определения. |
| is_alternative_to | Резервные пути (failover) и разделение маршрутов. | Указывает движку поиска путей рассчитать альтернативные варианты маршрутизации, если на основных узлах возникают узкие места. |
Благодаря отслеживанию связей в виде отдельных записей сущностей, а не жестко зашитых в компоненты линий, макет вашего интерфейса остается легковесным. Он оценивает сложные правила по запросу, основываясь исключительно на активных представлениях контуров.