aitest/workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
workspace/analysis_report_content.md

6.3 KiB
Raw Permalink Blame History

前后端项目功能与开源组件可修改性分析报告

1. 分析范围与目标

  • 前端项目：F:/ips/node-test-mod
  • 后端项目：F:/ips/java_test_back
  • 目标：
    1. 分析前后端主要功能定位与模块职责
    2. 重点分析前端关键页面涉及的核心组件是否开源、是否可修改

本次分析在 glm47 模型下完成。

2. 前端项目（node-test-mod）分析

2.1 技术栈与架构特征

  • 框架：Vue 3 + Vue Router + Pinia
  • UI：Element Plus
  • 图编辑/流程建模：LogicFlow（含官方包与定制命名空间包）
  • 构建：Vite（并保留 Vue CLI 启动脚本）
  • 通信：Axios

项目路由显示目前核心入口页面为：

  • / -> plan-simulation-modeling/index.vue

这说明该前端的主业务是“工艺/产线/计划仿真建模与生产控制配置”的单页主工作台。

2.2 页面功能拆解（核心页面）

根据目录结构，核心页面由以下子能力组成：

  1. Diagram 图形建模区

    • 文件：components/Diagram.vue 与大量 components/node/*
    • 功能：节点、连线、箭头、图元、图标、路径图形的绘制与编排
    • 特征：包含大量自定义 Node/Edge，实现行业场景图元（仓储、工艺段、生产单元等）

  2. 左侧建模工具/资源面板

    • 文件：left-sidebar-config/*
    • 功能：不同建模域（如 PHMM / PRCM）的图元选择与配置入口

  3. 顶部工具栏

    • 文件：top-sidebar-config/DiagramToolbar.vue
    • 功能：缩放、回退、前进等画布操作，流程编辑辅助

  4. 属性面板（设备/连接/工艺属性）

    • 文件：equ-attribute-config/*
    • 功能：不同实体（设备、线段、仓库、关系链接等）属性编辑
    • 特征：按类型拆分细粒度组件，适合扩展复杂业务属性

  5. 生产控制配置（多维控制）

    • 文件：production-control/*
    • 功能：区域、线、段、单元、组合仓等控制策略配置

  6. TOB 生产相关页面

    • 文件：tob-production/*
    • 功能：切批、仓储生产、单元生产等业务规则配置

  7. API 分层清晰

    • 文件：src/api/*
    • 分类：生产控制、工艺路线、TOB 生产、仿真包配置等

2.3 前端项目总体判断

这是一个“行业仿真建模 + 生产控制配置”的复杂业务前端，强图形编辑能力 + 强配置能力并存，属于中大型业务平台前端。

3. 后端项目（java_test_back）分析

3.1 架构与技术栈

  • 多模块 Maven 聚合工程（packaging=pom）
  • Java 8 + Spring Boot 2.3.12 + Spring Cloud Hoxton + Spring Cloud Alibaba
  • 数据与中间件：MySQL、Redis、MyBatis-Plus、Druid
  • 安全与接口：Spring Security、JWT、Swagger

3.2 模块职责（按命名与控制器分布）

  • business-common：权限、字典、日志、监控、在线会话等通用能力
  • business-core：仿真主流程、仿真项目、任务、统计、结果分析、记录
  • business-support：基础主数据、工艺定义、日历、BOM、PHMM/PRCM 等业务支撑
  • business-mansch：排产/调度（FIFO/FEFO 等版本）
  • 其他：application/config-* 负责启动与配置

3.3 控制器规模（粗粒度）

  • business-common: 8
  • business-core: 15
  • business-support: 42
  • business-mansch: 2

说明后端侧重点是“业务支撑与配置域（support）+ 仿真核心域（core）”。

3.4 后端总体判断

后端是典型“仿真业务平台”的分层多模块实现：

  • 通用安全与治理能力完善
  • 业务实体与工艺模型 API 丰富
  • 可支撑前端图形建模页面的复杂配置与数据回写

4. 前端关键组件开源与可修改性分析（重点）

4.1 关键组件与许可证结论

  1. vue
  • 许可证：MIT
  • 是否开源：是
  • 可否修改：可以（可 fork/patch；注意保留许可证声明）
  1. element-plus
  • 许可证：MIT
  • 是否开源：是
  • 可否修改：可以（常见方式：主题变量定制、二次封装、必要时 fork）
  1. vue-router / pinia / axios / sortablejs / preact
  • 许可证：MIT
  • 是否开源：是
  • 可否修改：可以（通常建议“封装优先、fork 兜底”）
  1. @logicflow/core / @logicflow/extension
  • 许可证：Apache-2.0
  • 是否开源：是
  • 可否修改：可以（允许商用与修改，需遵守 Apache-2.0 的 NOTICE/License 要求）
  1. @helinda-test-logicflow/core / extension
  • registry 元信息显示：Apache-2.0，仓库指向 LogicFlow
  • 判断：大概率是对 LogicFlow 的“企业内镜像/定制包命名空间”
  • 可否修改：
    • 从许可证看可修改
    • 但若该包由公司私有源维护，实际发布与版本管理权限受组织流程约束

4.2 关键页面组件可改性结论

  • 页面中大部分“关键业务组件”（如 src/views/plan-simulation-modeling/components/**）是你方项目源码，可直接改。
  • 外部依赖组件（Element Plus / LogicFlow 等）可改，但建议优先级：
    1. 业务层封装扩展（首选）
    2. patch-package 定点补丁（次选）
    3. fork 并锁定版本（最后手段）

5. 风险与建议

5.1 主要风险

  1. 自定义图元代码量大，升级成本高
    • LogicFlow 主版本升级可能影响自定义节点/边行为
  2. 双命名空间 LogicFlow 依赖并存
    • @logicflow/* 与 @helinda-test-logicflow/* 并存，需防止能力重复或行为不一致
  3. 历史版本目录较多（an-old-version）
    • 维护与排查时容易引入混淆

5.2 建议动作（可执行）

  1. 建立“关键依赖白名单 + 许可证台账”（MIT/Apache-2.0）
  2. 对 LogicFlow 的自定义扩展抽一层 adapter，降低升级耦合
  3. 清理或冻结 old-version 目录，避免新旧逻辑交叉
  4. 针对生产控制与属性面板建立组件测试（快照 + 交互）

6. 最终结论

  • 前后端功能匹配度高：前端负责“图形化建模与配置”，后端负责“仿真核心与业务支撑 API”。
  • 前端关键组件从许可证层面看基本均为开源且可修改（MIT / Apache-2.0）。
  • 需要重点管理的是：
    1. LogicFlow 定制扩展的长期可维护性
    2. 私有命名空间包（@helinda-test-logicflow/*）的发布流程与版本控制策略

结论：可改、能改、建议以封装+补丁为主，fork 为兜底策略。