27、医疗系统开发与现有代码架构管理：MDA与UML的应用

白露未晞593

于 2025-11-19 11:52:11 发布

阅读量4

点赞数

CC 4.0 BY-SA版权

分类专栏： UML建模：从理论到实践文章标签： MDA UML 医疗系统开发

本文链接：https://blog.youkuaiyun.com/bash7scripter/article/details/155268412

UML建模：从理论到实践专栏收录该内容

34 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

医疗系统开发与现有代码架构管理：MDA与UML的应用

在软件开发领域，无论是医疗系统的开发，还是对现有代码的架构管理，都面临着诸多挑战。本文将探讨如何运用MDA（Model-Driven Architecture）和UML（Unified Modeling Language）解决这些问题，包括医疗系统中访问控制组件的开发，以及现有代码向MDA的过渡。

医疗系统中MDA和UML的应用

在医疗系统开发中，MDA和UML发挥着重要作用，特别是在访问控制组件的设计与实现方面。

灵活的访问规则模型

通过“规范类”中的数据捕获访问规则，使模型具有高度灵活性，易于根据需求和法规变化配置不同的访问规则。该模型本质上是一种“领域特定语言”，输入的数据形式与问题领域紧密匹配，便于与现有的患者记录组件集成，必要时可通过构建小包装器来提供接口。

平台独立的UML动作语言

“访问控制”组件需在英国各种平台上运行，因此平台独立性至关重要。UML允许构建包含UML动作语言的平台独立领域模型，动作语言对实现平台独立性起着关键作用。以下是“访问控制”领域中“检查拒绝”操作的UML动作语言示例：

explicitDenial = TRUE

myAccessibleItem = this -> R15
myPIRAccessor = theAccessingPIR -> R2

# Is item explicitly denied to this PIR?
myDeniedAccess
=
myPIRAccessor
and
myAccessibleItem
->
R7.Denied_Item_Access
if myDeniedAccess = UNDEFINED then
  #  PIR ok, what about Role?
  myRoleAccessor = theAccessingPIR -> R4.Role -> R2
  myDeniedAccess
=
myRoleAccessor
and
myAccessibleItem
-> R7.Denied_Item_Access
  if myDeniedAccess = UNDEFINED then
    # Role ok, what about Person?
    myPersonAccessor = theAccessingPIR -> R4.Person -> R2
    myDeniedAccess
=
myPersonAccessor
and
myAccessibleItem
-> R7.Denied_Item_Access
    if myDeniedAccess = UNDEFINED then

      # Everything OK so far - no explicit denials
        explicitDenial = FALSE
     endif
  endif
   endif

此示例展示了使用UML抽象层次语言的优势，建模者可简单陈述关联链，而无需关注关联的具体实现方式。

模型集成

与不同现有系统集成 ：外部NHS组织在处理患者数据的代码等方面存在局部差异，通过单独的包装器域解决，其中超类代表通用服务，子类封装特定站点的代码，隔离“访问控制”域，便于引入新方案。
与COTS组件集成 ：引入“接口映射”域，将“访问控制”域使用的平台独立服务集映射到所选产品提供的特定平台服务集，如“PKI接口”和“注册表接口”，减少引入新产品的影响。以下是相关操作步骤：
1. 确定需要集成的COTS组件，如PKI和认证技术。
2. 引入“接口映射”域，定义平台独立服务集和平台特定服务集之间的映射关系。
3. 构建包装器，实现“访问控制”组件与目标环境的集成。

演示和模型验证

xUML允许对由单个或多个域模型组成的系统进行交互式或批量测试，用户在UML模型级别进行交互，可快速构建利益相关者演示器，并根据反馈迭代改进。下一步是将新设计的组件集成到HTML环境中，以展示更友好的用户界面。

现有代码向MDA的过渡

现有软件的维护和演进面临着诸多挑战，而MDA为解决这些问题提供了新的思路。

现有软件维护与演进的挑战

维护和演进现有软件占据软件系统整个生命周期的大部分时间，但当前方法和工具对这方面的支持存在不足。现有软件面临的挑战包括：
- 重新发现高层设计决策
- 变更对有用功能的影响（涟漪效应）
- 理解现有设计或变更影响所需的大量信息（程序理解）
- 关键开发人员离职导致专业知识流失
- 新人员培训需求
- 多站点协作环境带来的挑战
- 架构侵蚀导致的变更阻力

以下是不同年份程序员参与不同活动的分布情况：
| 年份 | 新项目 | 增强功能 | 修复 | 总计 |
| ---- | ---- | ---- | ---- | ---- |
| 1990 | 3 (43%) | 3 (43%) | 1 (14%) | 7 |
| 2000 | 4 (40%) | 4.5 (45%) | 1.5 (15%) | 10 |
| 2010 | 5 (35%) | 7 (50%) | 2 (14%) | 14 |

MDA的优势与挑战

MDA强调使用UML、MOF等进行建模，分离平台独立和平台相关的关注点，进行模型转换，并从代码维护转向模型和转换规范的维护。MDA可以解决程序理解和现代化挑战，但现有代码可能成为采用新开发方法的障碍，只有部分项目能受益于新方法和工具。

托管架构：向MDA过渡的实用方法

托管架构是一种实用的、借助工具的方法，用于在处理现有代码且无前期模型的项目中引入建模。其主要活动包括：
- 从现有代码中提取架构模型
- 对架构模型进行重构
- 使用架构模型进行影响分析和现代化规划
- 主动执行架构完整性

通过这些活动，托管架构可以解决程序理解挑战，减缓架构侵蚀，为现有代码向MDA的过渡提供基础。

从现有代码中提取模型

在传统的维护和演进方法中，将建模引入“现有代码项目”存在挑战。最有前景的方法是从现有代码中提取模型，并将其用于核心维护和演进活动。

模型在不同阶段的差异

模型在软件生命周期的不同阶段发挥着不同的作用，具体差异如下：
| 阶段 | 初始阶段 | 演进阶段 |
| ---- | ---- | ---- |
| 模型与代码关系 | 模型驱动代码开发 | 模型代表现有代码 |
| 模型与代码大小 | 模型比代码更紧凑 | 模型可能比代码更大 |
| 模型处理方式 | 模型被细化 | 模型从代码中抽象出来 |

提取模型的挑战

要从现有代码中提取足够抽象的模型，面临以下挑战：
- 模型应精确，可用于正式推理系统和源代码
- 模型应具有足够的范围，代表源代码的有趣方面
- 模型应可扩展，以便调整抽象级别
- 模型应便于程序理解
- 模型应允许随代码变化自动更新
- 模型应允许增量手动转换（重构）
- 模型应可操作，即模型中的变更应易于映射到代码中的变更

一些容易从源代码中提取的模型，如流程图、函数调用图和类图，虽然精确但抽象级别不足。其中，函数调用图和类图具有一定的可扩展性，但函数调用图难以将模型变更映射回代码，而类图等结构模型更具可操作性。

容器模型

Klocwork“容器模型”是一种满足上述要求的建模方法，专注于组件及其接口。

容器模型的特点

支持无限层次的容器，由子容器组成。
支持容器的转换，如移动子容器、拆分容器、创建更大容器、重命名容器等，并在转换过程中保持容器间接口的精度。

容器模型的操作

组成：将多个子组件合并为一个新容器，创建新的层次结构，并重新计算容器间的依赖关系。
分解：将一个容器分解为其子组件，移除该容器并重新计算依赖关系。
移动子组件 ：在容器间移动子组件，消除因文件级功能放置不当导致的高级组件间依赖关系。

以下是容器模型操作的流程图：

graph LR
    A[现有代码] --> B[自动提取初始容器模型]
    B --> C[手动转换模型]
    C --> D[架构分析和管理]
    C --> E[组成操作]
    C --> F[分解操作]
    C --> G[移动子组件操作]
    E --> H[创建新容器并移动子组件]
    F --> I[移除容器并移动子组件]
    G --> J[消除高级组件间依赖关系]
    H --> D
    I --> D
    J --> D

通过这些操作，容器模型可以捕获现有系统的架构视图，用于架构分析和管理。提取容器模型需要大量的程序理解，补充视图可以帮助简化复杂性，促进架构提取过程。

MDA和UML在医疗系统开发和现有代码架构管理中具有重要价值。在医疗系统中，它们确保了访问控制组件的灵活性、平台独立性和可集成性；在现有代码管理方面，托管架构和容器模型为向MDA的过渡提供了实用方法，有助于解决现有软件维护和演进中的诸多挑战。

医疗系统开发与现有代码架构管理：MDA与UML的应用

容器模型的实际应用与优势分析

在实际应用中，容器模型展现出了显著的优势。通过容器模型，可以清晰地呈现系统的架构结构，便于开发人员进行架构分析和管理。以下是容器模型在实际应用中的一些具体优势：

精确的接口表示

容器模型能够精确地表示容器之间的接口，每个关系都与源代码中的特定位置相关联。开发人员可以从高层容器图直接导航到源代码级别，深入了解关系存在的原因和责任。例如，在分析两个容器之间的依赖关系时，可以通过查看具体的关系列表，找到对应的源代码位置，从而更好地理解和修改代码。

便于架构优化

容器模型的操作，如组成、分解和移动子组件，为架构优化提供了有力的手段。通过合理地调整容器的结构和依赖关系，可以消除不必要的依赖，提高系统的可维护性和可扩展性。例如，将功能相关的子组件合并到一个容器中，可以减少容器之间的依赖，降低系统的耦合度。

支持多视角分析

容器模型可以提供多种视角来观察系统架构。除了整体的容器图，还可以通过补充视图来临时减少复杂性，帮助开发人员更好地理解系统的局部结构。例如，可以创建一个只显示特定功能模块的视图，以便更专注地分析该模块的架构。

案例分析：医疗系统中的容器模型应用

为了更直观地说明容器模型在实际项目中的应用，下面以一个医疗系统为例进行分析。

系统概述

该医疗系统包含多个子系统，如患者管理、病历记录、诊断辅助等。每个子系统又由多个模块组成，这些模块之间存在着复杂的依赖关系。

容器模型的构建

首先，从源代码中自动提取初始容器模型，将系统中的各个模块和文件映射到不同的容器中。然后，通过手动转换模型，对容器进行调整和优化。例如，将患者管理子系统中的患者信息查询模块和患者信息修改模块合并到一个容器中，以减少它们与其他子系统的依赖。

架构分析与优化

利用容器模型进行架构分析，发现系统中存在的问题。例如，某些容器之间的依赖关系过于复杂，导致代码的修改容易引发涟漪效应。通过移动子组件和调整容器结构，优化了这些依赖关系，提高了系统的稳定性和可维护性。

以下是该医疗系统容器模型的部分结构示例：
| 容器名称 | 子容器 | 依赖容器 |
| ---- | ---- | ---- |
| 患者管理系统 | 患者信息查询模块、患者信息修改模块 | 病历记录系统、诊断辅助系统 |
| 病历记录系统 | 病历录入模块、病历查询模块 | 患者管理系统 |
| 诊断辅助系统 | 疾病诊断模块、治疗建议模块 | 患者管理系统、病历记录系统 |