Активация онтологической воронки: механизм в деталях - Towareesh/OntoC4Designer GitHub Wiki

Активация — это процесс запуска специфичной обработки требования на основе его классификации. Это ключевой механизм, связывающий ML-классификацию с онтологиями и генерацией C4.

Процесс активации (шаги)

  1. Получение триггера от ML
    ML-классификатор передает:

    {
  "type": "NFR",
  "subtype": "Security",
  "domain": "ApplicationSoftware",
  "confidence": 0.92
}

  2. Выбор целевой воронки
    Система выбирает воронку по схеме:

    graph LR
    A[Domain: ApplicationSoftware] --> B[Type: NFR] --> C[Subtype: Security]
    C --> D[Активировать SecurityAppVoronka]

  3. Загрузка онтологий
    Загружаются связанные онтологии:

    • Метаонтология (ISO 21838): базовые концепты
    • Доменная онтология: ApplicationSoftware
    • Субдоменная: SecurityNFR
    load_ontology(core_iso)
load_ontology(domain_app)
load_ontology(subdomain_security)

  4. Инициализация рабочего контекста
    Создается семантический контекст обработки:

    context = {
     "requirement": original_text,
     "entities": NLP.extract_entities(original_text),
     "constraints": [],
     "components": [],
     "conflicts": []
}

  5. Применение правил сужения
    Последовательное выполнение онтологических правил:

    // Псевдокод обработки
voronka.applyRule("IF Security THEN require Encryption");
voronka.applyRule("IF Encryption THEN component CryptoService");
voronka.checkConflict("LowLatency vs AES-256");

Пример активации для Security-требования

Требование:
"Все данные в транзите должны шифроваться по TLS 1.3"

Процесс воронки:

graph TD
    A[Требование] --> B[Правило 1: Транзит → Шифрование]
    B --> C[Правило 2: Шифрование → TLS]
    C --> D[Правило 3: TLS → API Gateway]
    D --> E[Конфликт-чек: Поддержка TLS 1.3]
    E --> F[Генерация: Container=API-Gateway]

Рабочее состояние воронки:

{
  "active_rules": [12, 15, 88],
  "components": [
    {
      "type": "Container",
      "name": "API-Gateway",
      "properties": ["TLS_1.3", "HSTS"]
    }
  ],
  "constraints": ["encryption=always"],
  "banned_solutions": ["HTTP-only", "SSL-deprecated"]
}

Типы правил в воронке

  1. Обязательные правила
    REQUIRE(condition, action)
    Пример:
    REQUIRE("data_transit", "add_encryption")

  2. Исключающие правила
    EXCLUDE(solution, conflict_reason)
    Пример:
    EXCLUDE("nginx_1.18", "no_TLS1.3_support")

  3. Генерационные правила
    GENERATE(concept, c4_component)
    Пример:
    GENERATE("TLS", "Container:API-Gateway")

  4. Оптимизационные правила
    OPTIMIZE(metric, priority)
    Пример:
    OPTIMIZE("latency", "security > performance")

Механизм сужения вариантов

Воронка последовательно ограничивает пространство решений:

graph LR
    A[Все возможные решения] --> B[Применение доменных ограничений]
    B --> C[Применение субдоменных правил]
    C --> D[Разрешение конфликтов]
    D --> E[1-2 валидных варианта]

Пример для Security:

Начало: 50+ вариантов (Apache, Nginx, Envoy, HAProxy...)
После доменных правил: 15 вариантов (только с поддержкой TLS)
После субдоменных правил: 3 варианта (TLS 1.3+)
После конфликт-чека: 1 вариант (Envoy)

Интеграция с генерацией C4

Результат работы воронки напрямую конвертируется в C4:

# Псевдокод конвертации
def generate_c4(voronka_output):
    c4_model = C4Model()
    
    # Контейнеры
    for component in voronka_output['components']:
        if component.type == "Container":
            c4_model.add_container(
                name=component.name,
                tech=component.tech,
                properties=component.properties
            )
    
    # Связи
    for relation in voronka_output['relations']:
        c4_model.add_relation(
            source=relation.from,
            target=relation.to,
            protocol=relation.protocol
        )
    
    return c4_model

Итоговый вывод:

@startuml
!include C4_Container.puml

Container(api_gateway, "API Gateway", "Envoy", "TLS termination")
Container(app_service, "Application Service", "Spring Boot")

Rel(api_gateway, app_service, "HTTPS", "gRPC")
@enduml

Особенности для разных доменов

Системное ПО (RealtimeNFR):

voronka_rule('IF realtime THEN require preempt_rt');
voronka_rule('EXCLUDE non_rt_kernel');

Инструментальное ПО (CompatibilityNFR):

voronka_rule('IF cross_platform THEN component platform_abstraction');
voronka_rule('GENERATE win_support TO adapter_windows');

Прикладное ПО (ScalabilityNFR):

voronka_rule('IF high_load THEN require load_balancer');
voronka_rule('OPTIMIZE cost vs scalability');

Преимущества подхода

  1. Скорость: Автоматизация ручного проектирования
  2. Согласованность: Все решения соответствуют онтологическим правилам
  3. Трассируемость: Каждый элемент C4 связан с исходными требованиями
  4. Адаптивность: Легко добавлять новые домены через онтологии

Итог: Активация воронки превращает сырое требование в архитектурное решение через цепочку семантических преобразований, гарантируя корректность C4-модели.