Механизм работы онтологической системы построения архитектуры ПО: от требований до C4‐модели - Towareesh/OntoC4Designer GitHub Wiki

Ядро системы: Интеграция ML-классификатора с онтологическими воронками через семантический процессор.

Последовательность работы:

graph TD
    A[Текстовое требование] --> B(ML-классификатор)
    B --> C{Определение типа}
    C -->|FR| D[Привязка к функциональному компоненту]
    C -->|NFR| E[Активация онтологической воронки]
    E --> F[Семантическая обработка]
    F --> G[Сужение архитектурных вариантов]
    G --> H[Генерация C4-элементов]
    H --> I[Сборка C4-модели]

Детализация ключевых этапов:

1. Классификация требования

  • ML-модель определяет:
    • Тип: FR/NFR
    • Подтип: Security, Performance и т.д.
  • Пример:

    "Система должна шифровать данные в REST API" → Security (SE)

2. Активация онтологической воронки

  • Для NFR Security: 
    activate_voronka(
    type: 'Прикладное ПО', 
    ontology: 'Security',
    rules: [
        conflict('HighEncryption', 'LowLatency'),
        requires('DataInTransit', 'TLS'),
        component('CryptoService')
    ]
)

3. Семантическая обработка

  • Извлечение сущностей из текста:
    • "шифровать" → Операция: encrypt
    • "REST API" → Компонент: Gateway
  • Связь с онтологией: 
    INSERT { 
    :req1 a :SecurityRequirement ;
          :hasAction :encrypt ;
          :appliesTo :Gateway .
}

4. Сужение архитектурных вариантов

  • Воронка применяет правила:
    • Добавляет обязательные элементы: API Gateway → TLS
    • Исключает конфликтующие решения: HTTP без шифрования
    • Предлагает шаблоны: 
      {
  "component": "CryptoService",
  "technology": ["AWS KMS", "Hashicorp Vault"],
  "interfaces": ["encrypt(data)", "decrypt(data)"]
}

5. Генерация C4-элементов

Уровень C4 Генерация на основе онтологии
Контекст Внешние системы, взаимодействующие с CryptoService
Контейнеры API Gateway, Сервис шифрования, БД ключей
Компоненты CryptoEngine, KeyManager, AuditLogger
Код Аннотации: @SecurityLevel(HSM)

6. Сборка C4-модели

Автоматическая генерация в Structurizr:

@startuml
!include C4_Context.puml

System_Ext(Банк, "Платежная система")
System(Шифрование, "CryptoService")

Rel(Банк, Шифрование, "REST API (HTTPS)")
@enduml

Пример сквозного сценария

Ввод требования:

"Приложение должно обслуживать 10К пользователей с откликом <100мс"

Шаги системы:

  1. ML-классификация: Performance (PE)
  2. Активация воронки для Performance: 
    rules: [
  requires('HighLoad', 'HorizontalScaling'),
  excludes('VerticalScaling', 'BudgetLimit'),
  component('LoadBalancer')
]
  3. Семантическое извлечение:
    • 10К пользователей → нагрузка: high_load
    • <100мс → SLO: latency_critical
  4. Сужение вариантов:
    • Добавляет: Kubernetes, Redis Cache
    • Удаляет: Монолитную архитектуру
  5. Генерация C4:
    • Контейнеры: [API Gateway, AuthService, Redis, PostgreSQL]
    • Компоненты: [RateLimiter, CacheManager]
  6. Выход:
{
  "containers": [
    {
      "name": "RedisCache",
      "technology": "Redis",
      "purpose": "Кеширование ответов для соблюдения SLO"
    }
  ],
  "relationships": [
    {
      "source": "API_Gateway",
      "target": "RedisCache",
      "protocol": "RESP"
    }
  ]
}

Гарантии корректности C4-модели:

  1. Конфликт-анализ: Онтологический движок проверяет: 
    check_conflicts(
     current_model, 
     [latency < 100ms, encryption=aes256]
) → Разрешает/блокирует решения
  2. Проверка полноты:
    • Автоматическое обнаружение неуказанных компонентов (например, нет Load Balancer для требований масштабируемости)
  3. Согласованность уровней:
    • Связь контейнеров с компонентами через онтологические отношения contains

Техническая реализация:

class OntologyPipeline:
    def __init__(self, ml_model, ontologies):
        self.classifier = ml_model
        self.voronkas = ontologies  # Словарь воронок по типам ПО

    def process(self, requirement: str):
        # Этап 1: Классификация
        req_type = self.classifier.predict(requirement)
        
        # Этап 2: Активация воронки
        voronka = self.voronkas.select(req_type.domain)  # e.g., "Прикладное ПО"
        context = voronka.activate(req_type)
        
        # Этап 3: Семантический анализ
        entities = NLPEngine.extract_entities(requirement)
        context.bind(entities)
        
        # Этап 4: Генерация C4
        c4_model = C4Generator.generate(context)
        
        # Этап 5: Валидация
        if not OntologyValidator.validate(c4_model, voronka):
            raise ArchitectureConflictError
        return c4_model

Механизм работы системы на основе следующей онтологической схемы

graph TD
    %% Пользовательский ввод
    A[Текстовое требование] --> B(ML-классификатор)
    
    %% Классификация
    B --> C{Определение типа}
    C -->|FR| D[Определение домена]
    C -->|NFR| E[Определение домена]
    
    %% Доменная маршрутизация
    D --> F[SystemSoftware<br>онтология]
    D --> G[ApplicationSoftware<br>онтология]
    D --> H[ToolingSoftware<br>онтология]
    E --> F
    E --> G
    E --> H
    
    %% Онтологическая обработка
    F --> I[Субдоменная<br>воронка:<br>• HWConstraint<br>• KernelFR<br>• RealtimeNFR]
    G --> J[Субдоменная<br>воронка:<br>• UXConstraint<br>• BusinessRuleFR<br>• ScalabilityNFR]
    H --> K[Субдоменная<br>воронка:<br>• IDEConstraint<br>• DebuggerFR<br>• CompatibilityNFR]
    
    %% Генерация C4
    I --> L[Генератор C4<br>контекста]
    J --> M[Генератор C4<br>контейнеров]
    K --> N[Генератор C4<br>компонентов]
    
    %% Сборка модели
    L --> O[C4-модель]
    M --> O
    N --> O

Пошаговый механизм работы

  1. Прием требования:
requirement = {
    "text": "Система должна обеспечивать обработку 100К сообщений/сек с задержкой <10мс",
    "source": "SRS-документ",
    "priority": "HIGH"
}
  1. ML-классификация:
# Результат классификации
classification = {
    "type": "NFR",          # Functional/Non-functional
    "subtype": "Performance",
    "domain": "SystemSoftware",
    "confidence": 0.92
}
  1. Активация онтологической воронки:
activate_voronka(
    domain: system_software,
    subtype: performance,
    rules: [
        requires(high_throughput, horizontal_scaling),
        excludes(vertical_scaling, cost_constraint),
        component(message_broker),
        constraint(latency < 10ms)
    ]
)
  1. Обработка в воронке:
graph LR
    A[100K msg/sec] --> B{Выбор технологии}
    B --> C[Kafka] --> D[Подходит]
    B --> E[RabbitMQ] --> F[Отклонено]
    F -->|Причина| G[Не обеспечивает latency <10ms]
    D --> H[Генерация C4-элементов]
  1. Генерация C4-элементов:
{
  "context": {
    "actors": ["ExternalProducer", "DataConsumer"],
    "systems": ["KafkaCluster"]
  },
  "containers": [
    {
      "name": "MessageProcessor",
      "technology": "Go",
      "scaling": "horizontal"
    }
  ],
  "components": [
    {
      "name": "LatencyMonitor",
      "responsibility": "Контроль времени обработки",
      "constraints": ["p99 < 10ms"]
    }
  ]
}
  1. Сборка полной модели:
@startuml
!include C4_Context.puml

System_Ext(ExternalProducer, "Внешний источник данных")
System_Boundary(kafka_cluster, "Обрабатывающий кластер") {
    Container(message_queue, "Kafka", "Брокер сообщений")
    Container(processor, "MessageProcessor", "Go-сервис")
    Component(latency_monitor, "LatencyMonitor", "Мониторинг")
}

Rel(ExternalProducer, message_queue, "Отправка сообщений")
Rel(message_queue, processor, "Обработка")
Rel(processor, latency_monitor, "Метрики производительности")
@enduml

Ключевые интеграционные точки

  1. Онтологический роутер:
def route_requirement(requirement, classification):
    domain_ontology = DOMAIN_ONTOLOGIES[classification['domain']]
    voronka = domain_ontology.select_voronka(
        type=classification['type'],
        subtype=classification['subtype']
    )
    return voronka.process(requirement)
  1. Генератор C4 на онтологических правилах:
class C4Generator:
    def generate(self, voronka_output):
        elements = {}
        
        # Контекст
        if voronka_output.get('external_actors'):
            elements['context'] = self._gen_context(voronka_output)
        
        # Контейнеры
        for component in voronka_output['required_components']:
            elements['containers'].append(self._map_to_container(component))
        
        # Компоненты
        for constraint in voronka_output['constraints']:
            elements['components'].append(self._constraint_to_component(constraint))
        
        return C4Model(elements)
  1. Валидатор корректности:
validate_c4_model(Model) :-
    check_conflicts(Model),
    verify_completeness(Model),
    assert_consistency(Model, domain_ontology).

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

  1. Автоматическая трассировка:

    graph LR
    Req[Требование] --> Ont[Онтология] --> C4[C4-элемент]
    C4 -->|trace| Req

  2. Консистентность между уровнями:

    • Метаонтология → Общие принципы генерации
    • Доменная онтология → Стиль диаграмм
    • Субдоменная → Детализация компонентов

  3. Адаптивность под тип ПО:

    • SystemSoftware: Акцент на ресурсы, ядро
    • ApplicationSoftware: Бизнес-логика, UX
    • ToolingSoftware: Интерфейсы расширения

Пример вывода для разных доменов

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

[Контейнер] RealTimeKernel:
  - Технология: PREEMPT_RT
  - Ограничения: гарантированное время отклика
  - Компоненты: Scheduler, IRQ_Manager

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

[Контейнер] CrossPlatformSDK:
  - Технология: Qt
  - Ограничения: поддержка Win/Linux/Mac
  - Компоненты: UI_Adapter, NativeBridge

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

[Контейнер] StatelessService:
  - Технология: Kubernetes Pod
  - Ограничения: автоскейлинг по CPU
  - Компоненты: RequestProcessor, CacheClient

Свойства результирующей C4-модели

Итоговые характеристики автоматически генерируемой архитектурной модели:

  1. Полная трассируемость требований

    • Прямая связь элементов модели с исходными FR/NFR
    • Сквозная видимость от бизнес-требований до компонентов реализации

  2. Семантическая согласованность

    • Гарантированное соответствие онтологическим правилам
    • Автоматическое разрешение конфликтов на этапе генерации
    • Валидация ограничений предметной области

  3. Контекстная адаптация

    • Автоматическая оптимизация под тип ПО (прикладное/системное/инструментальное)
    • Учет доменной специфики через ML-классификацию требований

  4. Техническая готовность

    • Поддержка экспорта в промышленные форматы (Structurizr/PlantUML)
    • Генерация документации со встроенной трассировкой
    • Непротиворечивость между уровнями абстракции (C4 Context → Containers → Components)

  5. Автоматизированная генерация

    • Сквозное преобразование требований в архитектурные артефакты
    • Минимизация ручной работы при сохранении семантической целостности

Визуализация ключевых свойств

[ Требования ] → [ Онтологическая обработка ] → [ C4-модель ]
       │               │ 1. Трассируемость                ├─▶ Structurizr
       ├─ML─▶ Классификация    │ 2. Согласованность       ├─▶ PlantUML
       │               │ 3. Контекстная адаптация          └─▶ Документация
       └─▶ Разрешение конфликтов