基于本体的架构模式识别三阶段流程

基于[[本体用于架构模式识别的可行性]]中分析的优势，作者团队实践的识别过程分三个阶段：概念层本体构建、实例层本体构建、推理与查询。概念层本体构建是”定义规则”——针对特定架构模式，用描述逻辑（一种用于精确刻画概念的形式化语言）把这个模式由哪些组件、每个组件又由哪些组件元素构成，逐条描述出来；不同架构模式之间的区别，本质上就是组成组件的组件元素构成方式不同。实例层本体构建是”提取事实”，分两步：先做信息提取，通过源代码解析工具得到抽象语法树（AST），再从AST上的依赖关系（继承、实现、组合、关联、调用、实例化、参数类型耦合、返回值类型耦合、变量声明类型耦合等）整理出程序关系依赖图；再做个体及关系构建，把这张依赖图转换成本体里的RDF三元组（每条三元组形如”主体-关系-客体”，例如某个类”包含”某个方法、某个方法”调用”另一个方法），本质上是把源代码里提取出来的一张图，转换成用本体语言描述的另一张等价的图。推理与查询是”匹配与提取”：把概念层描述的规则和实例层构建的事实一起交给本体推理机，推理机据此推导出新的知识——比如某个具体类满足了单例模式概念层描述的全部条件，就能推理出”这个类是一个单例类”这样的结论；推理完成后，再通过查询语句（如SPARQL）从扩充后的知识库里筛选出架构模式识别真正需要的那部分实例，因为推理会产生大量知识，并非全都是识别目标关心的内容。书中以单例（Singleton）模式为例贯穿演示了这条流程：一个符合单例模式的LoadBalancer类（内含私有静态成员变量存实例、私有构造函数、公有静态方法返回唯一实例）经过信息提取和个体构建后，被转换成十条左右的RDF三元组，再结合概念层对单例模式的描述逻辑定义，推理机就能推导出”LoadBalancer是一个单例类”这一新知识，最后通过SPARQL查询语句把这个结果提取出来。这套流程的价值在于把原本高度依赖架构师主观判断的”模式识别”，转化成了”规则定义（一次性）+ 事实提取（自动化）+ 机器推理（自动化）+ 结果查询（自动化）”的可复用管道，人工参与被压缩到概念层规则定义和最终结果甄别两个环节。

结构图：

flowchart TB
    subgraph 概念层["概念层本体构建（规则）"]
        A["用描述逻辑定义架构模式\n（模式 = 组件集合，组件 = 组件元素集合）"]
    end
    subgraph 实例层["实例层本体构建（事实）"]
        B["源代码解析 → AST"]
        C["AST依赖分析 → 程序关系依赖图"]
        D["图转换 → RDF三元组（个体及关系）"]
        B --> C --> D
    end
    subgraph 推理查询["推理与查询"]
        E["本体推理机（规则集+事实集）\n推导新知识"]
        F["SPARQL查询\n筛选出目标模式实例"]
        E --> F
    end
    A -->|规则集| E
    D -->|事实集| E
    F --> G["识别结果：\n组成该架构模式的组件元素"]

内容

参考来源