GraphMechanic - платформа визуальной работы с графовыми данными — SRS-сборка¶

Эта страница собирает разделы для спецификации требований к ПО: от контекста и проблемы до безопасности, качества и эксплуатации.

Содержание¶

Краткое описание
Контекст и проблема
Цели, требования и ограничения
Роль и обязанности
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация

Краткое описание¶

Статус¶

concept-stage project / paused project

Роль¶

автор концепции, системный проектировщик, prototype engineer

Стек¶

Тип: Graph visualization / GIS-aware graph editing / internal tooling platform; Происхождение: развитие идеи из PolylineMechanic - утилиты редактирования полилиний железнодорожного графа

Ценность проекта¶

GraphMechanic - концепция визуальной платформы для работы с прикладными графовыми данными: инфраструктурными сетями, транспортными графами, GIS-связанными объектами, логическими зависимостями и операционной топологией.

Контекст и проблема¶

Контекст¶

GraphMechanic вырос из PolylineMechanic - внутренней утилиты редактирования полилиний железнодорожного графа, созданной в контексте enterprise GIS-инициативы.

Изначальный инструмент PolylineMechanic решал узкую, но повторяющуюся задачу: геометрию железнодорожных путей нужно было подготовить и восстановить перед загрузкой в enterprise GIS-платформу. GraphMechanic обобщает этот опыт до более широкой платформенной концепции для визуальных graph operations в разных доменах.

Проект отражает переход от разовых внутренних инструментов подготовки данных к переиспользуемой продуктовой архитектуре для операционных графовых данных.

Проблема¶

Во многих организациях графовые данные хранятся в базах данных, GIS-системах, внутренних сервисах или операционных платформах, но для них нет удобного интерфейса визуальной проверки и управляемого редактирования.

Типовые проблемы:

графовые данные есть в БД, но их трудно визуально исследовать;
географически связанные объекты сложно валидировать только по таблицам;
параметры узлов и рёбер влияют на поведение системы, но плохо видны в интерфейсе;
нужно сравнивать несколько слоёв одного графа;
доменным специалистам нужен визуальный инструмент без прямого доступа к БД;
изменения состояния системы сложно наблюдать в привязке к топологии;
существующие инструменты часто слишком общие, слишком GIS-ориентированные, слишком привязанные к конкретной БД или слишком тяжёлые для внутреннего использования.

Цели, требования и ограничения¶

Цели и нецели¶

Требования¶

Ключевые возможности¶

1. Обобщённая доменная модель графа¶

GraphMechanic не ограничивается железнодорожной предметной областью.

Платформа опирается на обобщённые понятия:

узлы;
рёбра;
геометрия рёбер;
атрибуты узлов;
атрибуты рёбер;
слои;
статусы;
доменные метаданные;
внешние идентификаторы;
правила проверки топологии.

Это позволяет адаптировать инструмент к разным предметным областям без переписывания ядра приложения.

2. Настраиваемые коннекторы к данным¶

Платформа предполагает connector-oriented подход к доступу к данным.

Вместо жёсткой привязки к одной структуре БД GraphMechanic отделяет внутреннюю модель графа от исходной схемы данных.

Слой коннекторов отвечает за:

чтение узлов;
чтение рёбер;
чтение геометрии рёбер;
маппинг полей БД на атрибуты графа;
применение фильтров;
запись подтверждённых изменений обратно в источник;
поддержку разных исходных схем.

Потенциальные источники данных:

PostgreSQL / PostGIS;
реляционные БД с графоподобными таблицами;
CSV / JSON-выгрузки;
в перспективе - graph database connectors.

3. Отображение нескольких графовых слоёв¶

GraphMechanic позволяет отображать несколько графовых слоёв на одной карте.

Примеры слоёв:

физическая инфраструктура;
логическая маршрутизация;
слой доступности сервисов;
планируемые изменения;
слой ошибок и аномалий;
исторический снимок состояния.

У каждого слоя могут быть собственные правила видимости, стилизации и источник данных.

Это позволяет сравнивать разные представления одной сети и выявлять расхождения между физической, логической и операционной моделями.

4. Параметризация внешнего вида узлов и рёбер¶

Внешний вид узлов и рёбер может настраиваться динамически.

Визуальные параметры могут зависеть от атрибутов объектов:

цвет узла по статусу;
размер узла по важности или нагрузке;
толщина ребра по пропускной способности или трафику;
цвет ребра по доступности;
пунктирные линии для планируемых или неактивных сегментов;
иконки для разных типов объектов;
подписи на основе выбранных полей.

Так граф становится не просто геометрией, а операционной визуальной моделью.

5. Динамические параметры и наблюдение состояния¶

GraphMechanic предполагает возможность наблюдать изменения состояния графа во времени.

Одна и та же топология может дополняться динамическими данными:

доступность;
нагрузка;
состояние ошибки;
задержка;
статус обработки;
время последнего обновления;
операционные метрики.

Это превращает статический граф в лёгкую операционную консоль.

Цель не в том, чтобы заменить полноценные observability-платформы, а в том, чтобы показывать состояние системы в привязке к доменной топологии.

6. Логический вид графа¶

Помимо отображения на карте, GraphMechanic предполагает режим негеографического графа.

В этом режиме все узлы размещаются на одном экране с помощью force-directed или layout-based представления, близкого по смыслу к Obsidian-style graph visualization.

Такой режим полезен, когда география скрывает логическую структуру или когда граф вообще не имеет географической природы.

Примеры использования:

карты зависимостей;
логическая топология;
связи инфраструктурных объектов;
графы доменных сущностей;
процессные графы;
knowledge graphs;
data lineage-like представления.

7. Визуальное редактирование¶

GraphMechanic развивает функциональность PolylineMechanic:

редактирование узлов;
редактирование рёбер;
создание полилиний;
восстановление полилиний;
генерация геометрии через routing service;
редактирование атрибутов;
визуальная валидация;
управляемое сохранение или экспорт изменений.

Модель редактирования снижает потребность в прямой правке данных в БД и даёт доменным пользователям более безопасный визуальный workflow.

Примеры использования¶

Проверка железнодорожного графа перед загрузкой в enterprise GIS-платформу.
Сравнение физического и логического слоя сети.
Поиск несвязанных узлов и разорванных маршрутов.
Отображение операционного состояния поверх инфраструктурной топологии.
Редактирование атрибутов графа без прямого доступа к БД.
Построение визуальной консоли для доменно-специфичных сетевых данных.
Переключение между картографическим и логическим представлением графа.
Поиск расхождений между плановой и фактической топологией.

Ограничения¶

Роль и обязанности¶

Я выступал автором концепции, системным проектировщиком и prototype engineer.

Мой вклад включал:

формулирование продуктовой концепции и обобщение PolylineMechanic до более широкой платформенной идеи;
проектирование модульной архитектуры и connector-oriented модели доступа к данным;
спецификацию ключевых возможностей: многослойное отображение, параметризация стилей, двойной географический/логический режим и сценарии визуального редактирования;
позиционирование продукта относительно GIS-платформ, инструментов визуализации графов и monitoring-систем.

Модель системы¶

Доменная модель¶

Обобщённые понятия графа¶

узлы;
рёбра;
геометрия рёбер;
атрибуты узлов;
атрибуты рёбер;
слои;
статусы;
доменные метаданные;
внешние идентификаторы;
правила проверки топологии.

Целевые пользователи¶

GIS-аналитики;
системные аналитики, работающие с графовыми доменами;
data engineers в инфраструктурных проектах;
транспортные и логистические аналитики;
telecom / utility network teams;
команды внутренней автоматизации;
команды, сопровождающие кастомные операционные графовые данные.

Модель данных¶

API-контракты¶

Архитектура и интеграции¶

Архитектура¶

GraphMechanic проектируется как модульное веб-приложение.

Ключевые компоненты:

Web UI - визуализация графа, map view, logical graph view, инструменты редактирования;
Graph Model Layer - нормализованное внутреннее представление узлов, рёбер, геометрии, атрибутов и слоёв;
Connector Layer - адаптеры к внешним БД и источникам данных;
Style Engine - настраиваемое соответствие между атрибутами объектов и визуальным отображением;
Validation Engine - проверки топологии и доменно-специфичные правила консистентности;
State Update Layer - динамические обновления для live / near-real-time состояния графа;
Persistence Layer - хранение конфигураций, layout-настроек, пользовательских параметров и audit data.

Потоки интеграции¶

Потоки чтения и записи через коннекторы к данным¶

Слой коннекторов читает узлы, рёбра и геометрию рёбер из внешних источников, выполняет маппинг полей БД на атрибуты графа, применяет фильтры и записывает подтверждённые изменения обратно в источник.

Потенциальные источники данных включают PostgreSQL / PostGIS, реляционные БД с графоподобными таблицами и CSV / JSON-выгрузки.

Генерация геометрии через routing service¶

Визуальное редактирование развивает функциональность PolylineMechanic: генерация геометрии через routing service для создания и восстановления полилиний.

Управляемое сохранение и экспорт¶

Изменения проходят через управляемый workflow сохранения или экспорта, снижающий потребность в прямой правке данных в БД и дающий доменным пользователям более безопасный визуальный путь редактирования.