28、现有代码的管理架构：迈向MDA的实用过渡

现有代码的管理架构：迈向MDA的实用过渡

1. 管理架构概述

管理架构是一种专注于现有软件资产演进的新开发方法，它强调以下几点：
- 从代码中提取架构模型。
- 通过组合和架构重构实现足够的抽象级别。
- 主动执行架构完整性。

该方法的目标是为现有软件创建一个形式化的架构模型，这个模型要足够高级，以便进行推理并传达给开发团队。这样的模型可用于管理现有软件的架构、分析当前架构的问题，以及规划和协调清理工作。在现有设计和架构文档缺失、不准确或过时的情况下，这种方法尤为有益。

2. 架构能力成熟度模型（ACMM）

ACMM是著名的SEI CMM模型在软件架构领域的投影，涵盖了现有软件架构这一方面，它分为以下几个级别：
| 级别 | 描述 |
| ---- | ---- |
| 初始架构（Level 1） | 任何软件都有一定的结构，无论是否被定义或理解，它由一些组件组成，组件之间存在依赖关系，并以配置的形式交付。 |
| 可重复架构（Level 2） | 组织通常使用可重复的模式来构建和交付软件，如包装规则、库的使用和代码复用。大型软件资产组织会关注软件架构问题，以确定产品线的成功。 |
| 定义架构（Level 3） | 组件、其接口和配置与源代码一起被正式定义和维护，通常会使用建模工具，如Rational Rose和组件运行时框架。 |
| 管理架构（Level 4） | 组织需要了解组件、其依赖关系和配置的最新、精确和可量化的情况，这需要对现有软件架构进行可视化、获取“设计架构”与“构建架构”之间的反馈、使用现有架构的指标、利用架构模型理解变更的影响，以及在整个组织范围内执行软件架构的完整性。 |
| 优化架构（Level 5） | 软件的架构完整性得到加强和改进，持续的架构改进成为整体开发过程的一部分。 |

3. 管理架构与工具使用

管理架构级别更依赖于软件工具的使用。在定义架构级别，会使用建模工具（如UML）来定义、共享和维护模型。而用于管理架构的工具可分为逆向工程或软件质量保证工具，这些工具可以处理现有代码，实现对现有代码架构的可视化、量化和转换。

传统的架构管理角色往往是被动的，在发现架构问题时可能已经太晚且成本高昂，容易导致架构侵蚀。而软件架构管理工具可以缩短评估周期，更理想的做法是将完整性检查集成到构建过程中，例如在设计师提交更新模块到配置管理系统时实时检查架构规则。

4. 为何管理架构不使用UML

管理架构的架构模型不使用UML，主要有以下原因：
- 可扩展性：需要维护组合容器的连贯且可编辑的层次结构。
- 处理大型模型：在初始提取步骤中需要处理大型模型。
- 架构模型重构：在保持精度的同时对架构模型进行重构。
- 特定“现有代码”理解问题：如与代码的链接、导航等。

Klocwork容器模型基于UML包和对象图，但底层元模型更为复杂，以支持无限层次结构、符号之间原始关系到容器依赖的映射，以及与源代码的关联。不过，层次结构中的每个单独图表都可以轻松转换为UML。

5. 从管理架构启动基于UML的模型驱动开发

行业逐渐认识到，源代码本身并不适合用于维护和演进，因为它混合了平台无关和平台特定的问题。模型驱动架构（MDA）方法倡导从维护源代码转向使用模型和转换来为选定平台生成源代码。

MDA的关键概念是从维护代码过渡到建模，它主张分离平台无关模型（PIM）和平台特定模型（PSM），通过自动化代码生成从PIM派生选定平台的实现代码。然而，现有软件在向MDA过渡时存在“遗留障碍”，需要提取现有软件的PIM。

我们认为，支持无限组合、重构和与源代码链接的容器模型是创建现有软件架构重要模型的实用方法，这些模型可以逐步细化为现有模块的PIM，从而将现有模块集成到面向MDA的软件开发中。

以下是从架构模型（容器模型）到MDA模型的迁移流程：

graph LR
    A[现有代码] --> B[提取容器模型（CM）]
    B --> C[重构模型]
    C --> D[平台无关容器模型（PICM）]
    C --> E[平台特定容器模型（PSCM）]
    D --> F[生成UML组件模型]
    F --> G[导出到MDA工具]
    G --> H[集成到MDA模型]
    E --> H

这种架构中心方法的优势在于可以利用工具支持来执行模型的完整性，但目前该模型并非完全支持MDA，因为它仅处理组件及其接口，而不涉及行为。现有组件仍需与MDA工具生成的新组件进行集成。

现有代码的管理架构：迈向MDA的实用过渡

6. 更广泛的背景

在行业中，存在大量的软件工具供应商和服务供应商致力于现有软件的现代化。为了实现不同供应商解决方案之间的集成和互操作性，标准化变得尤为迫切。标准化能够创建一个开放的框架，提高不同工具之间的互操作性，从而催生新一代的解决方案，造福整个行业。

Klocwork牵头了对象管理组织（OMG）的架构驱动现代化（ADM）任务组。该任务组的首个请求建议书（RFP）旨在征集一个知识发现元模型（KDM），用于交换与现有软件资产转换相关的信息。具体来说，RFP寻求一个通用的存储库结构，以表示关于现有软件及其运行环境的信息。

KDM的作用十分显著，它能够记录现有系统，发现现有软件中的可重用组件，支持向其他语言和MDA的移植，以及实现其他潜在的转换。同时，KDM还能使不同工具之间交换现有软件工件的信息，并针对特定的最终用户项目进行定制。这将使得专注于特定语言、平台或转换类型的供应商能够与其他供应商合作，为客户提供解决方案。

KDM需要表示现有软件的结构及其相关工件，包括实体（结构元素）、它们的关系和属性。从语言层面来看，实体包括方法、源文件、类等；关系包括“函数使用变量”“类继承自另一个类”等；属性包括名称、访问权限、版本等。在架构层面，存在物理结构（如文件、目录、构建依赖关系等）、运行时结构（如进程、线程和进程间通信通道等）和逻辑结构（如子系统、模块、层、组件及其依赖关系等）。

Klocwork贡献了他们的容器模型作为KDM的基础。为了实现互操作性，KDM将提供更专业的元类来表示物理、运行时和逻辑结构，并通过“汇总”容器之间的关系机制，将元素与语言层面结构、逻辑结构、运行时结构和物理结构相关联。

7. 总结

我们探讨了将建模引入“现有代码项目”的方法，目标是利用模型对现有软件的架构进行有效控制。这种方法带来了多方面的益处，短期来看，能够逐步改善现有软件的架构和维护健壮性；长期而言，有望实现基于模型的开发在企业范围内的统一应用。

容器模型在这一过程中发挥了重要作用，它具有以下特点：
1. 表示“容器”及其关系和接口 ：每个“容器”依赖于其他“容器”，并为其他“容器”提供API。
2. 可扩展性 ：“容器”的组合仍是“容器”，组合依赖于各个部分的依赖，且提供各个部分API的并集。
3. 可重构性 ：子容器可以在不同容器之间移动，模型能够显示依赖关系和API的变化。
4. 精确性 ：在聚合内容和API方面都具有精确性。
5. 有意义且有用 ：容器的层次结构对应架构视图，叶子“容器”可以是过程、变量、文件等，叶子关系（API）如过程调用过程等。
6. 可操作性 ：容器及其内容的重构可以映射到源文件的编辑。
7. 可维护性 ：模型可以随着软件的更改而自动更新，叶子容器及其关系从源中自动提取，模型仅存储容器的层次结构，关系实时重新计算。

整个过程分为两个明显的阶段：
| 阶段 | 操作内容 |
| ---- | ---- |
| 建立管理架构能力级别 | 使用管理架构技术和逆向工程工具，建立系统的整体视图，包括主要组件和结构及其关系；为系统的文档记录、开发和教育提供共同的上下文；创建与现有资产相关的所有架构和设计工件的公共存储库。 |
| 从容器模型生成UML模型并迁移到MDA | 使用MDA工具进行平台无关建模和验证、平台特定建模、自动代码生成；为系统的文档记录、开发和教育提供共同的上下文。 |

在这两个阶段中，管理架构技术都用于执行系统架构的完整性。通过这种方式，我们能够更好地应对现有软件向MDA过渡的挑战，实现软件的高效维护和演进。

graph LR
    A[建立管理架构能力级别] --> B[从容器模型生成UML模型并迁移到MDA]
    B --> C[实现系统架构完整性管理]

综上所述，通过管理架构和容器模型，我们为现有软件的现代化和向MDA的过渡提供了一条可行的路径，有望推动软件行业在架构管理和开发方法上的进一步发展。