Формализация процесса онтологически управляемой генерации архитектурных моделей - Towareesh/OntoC4Designer GitHub Wiki
1. Конвейер обработки входных данных
flowchart TD
A[Гетерогенные источники] --> B[Этап предобработки]
B --> C[Этап формализации]
C --> D[Онтологический движок]
D --> E[Визуализация графа]
subgraph A[Гетерогенные источники]
A1[Jira]
A2[GitLab]
A3[Notion]
A4[User Stories]
A5[Инженерные артефакты]
end
subgraph B[Этап предобработки]
B1[Структурация] -->|Вывод| B2["Корпус нормализованных предложений L = {s₁, s₂, ..., sₙ}"]
B3[Атрибутирование] -->|Метаданные| B4["SourceMap(sᵢ) → {Источник, Автор, Тип данных}"]
end
subgraph C[Этап формализации]
C1[ML-классификатор] -->|Таксономия| C2["τ: L → {FR, NFR-α, Constraint-β}"]
C3[Формализатор] --> C4["Формальная спецификация: FS = {FRᵢ, NFRⱼ(γ), Constraintₖ}"]
end
subgraph D[Онтологический движок]
D1[Загрузка онтологий] --> D2["O = O_meta ∪ O_domain ∪ O_sub"]
D3[Сопоставление] --> D4["Mapping: FS × O → G(V,E)"]
D5[Фильтрация] --> D6["G'(V',E') = FILTER(G, FS)"]
end
subgraph E[Визуализация]
E1["Рендеринг G'(V', E')"]
E2[C4-совместимая проекция]
end
2. Формальная спецификация этапов
Этап предобработки:
- Вход:
D_raw = {d | d ∈ Jira ∪ GitLab ∪ Notion ∪ UserHistory ∪ EngineeringArtifacts}
- Преобразование:
PREPROCESS: D_raw → L × M
L = {s | s - нормализованное предложение}
M: L → 2^{Источник × Автор × Timestamp}
Этап формализации:
- Классификация:
CLASSIFY: L → T
T = {FR, NFR_{Security}, NFR_{Performance}, Constraint_{Tech}, Constraint_{Biz}}
- Формализация:
FORMALIZE: L × T → FS
FS = ⟨FR_Set, NFR_Set, Constraint_Set⟩
Онтологическая система:
- Состав:
O = O_meta ∪ O_app ∪ O_sys ∪ O_tool ∪ O_shared
- Метаонтология:
O_meta = {Component, Container, Relation, Interface}
(C4-ядро)
Процесс фильтрации графа:
def generate_graph(FS: FormalSpec, O: Ontology) -> Graph:
G = initialize_graph(O) # Инициализация полного онтологического графа
# Правила деактивации вершин
for vertex in G.vertices:
if not satisfies(vertex, FS):
G.deactivate(vertex)
# Каскадная деактивация отношений
for edge in vertex.incident_edges:
if not satisfies(edge, FS):
G.deactivate(edge)
return G.prune() # Удаление неактивных элементов
def satisfies(entity, FS: FormalSpec) -> bool:
# Проверка соответствия требованиям и ограничениям
return all(rule(entity) for rule in FS.rules) and
not any(conflict(entity, c) for c in FS.constraints)
3. Свойства результирующего графа
Результирующий граф G' = (V', E')
обладает характеристиками:
-
C4-совместимость:
∃ проекция f: V' → {Context, Container, Component, Code}
сохраняющая отношенияE'
-
Семантическая полнота:
∀artifact ∈ FS ∃v ∈ V'
такое чтоv ⊨ artifact
-
Автоматическая редукция:
V' = {v ∈ V | SAT(v, FS)}
гдеSAT
- предикат выполнимости относительно формальной спецификации -
Контекстная релевантность:
Тип ПО определяет активные субонтологии:
active_ontologies = select_ontologies(FS.type)
4. Визуализация и вывод
Система генерирует два взаимосвязанных представления:
graph LR
A[Онтологический граф G'] --> B[Автоматическая проекция]
A --> C[Интерактивная визуализация]
B --> D[C4-диаграммы]
C --> E[Web-интерфейс]
D --> F[Structurizr/PlantUML]
E --> G[Анализ связности]
5. Преимущества подхода
- Адаптивность: Автоматическая адаптация онтологии под входные требования
- Семантическая целостность: Гарантии соответствия исходным ограничениям
- Двойное представление: Синхронизация между формальным графом и C4-диаграммами
- Контекстное фокусирование: Исключение нерелевантных элементов архитектуры
- Трассируемость: Прямая связь вершин графа с исходными артефактами
Данный формализм обеспечивает строгое преобразование гетерогенных требований в семантически согласованную архитектурную модель, сохраняя принципы C4 через метаонтологическое ядро, но расширяя их возможностями динамической адаптации на основе входных ограничений.