UML建模实战：《Thinking in UML》光盘模型文件使用与工具选型全指南

简介：《大象-Thinking in UML》的配套光盘合集，专为正在研读原书、希望深入掌握UML建模与面向对象设计的读者准备，既能帮助对照书中黑白插图理解彩色原图，也能系统学习建模过程中的组织方式。整个压缩包共1903个文件，整体约9.25MB，主要包含html/htm网页页面、tif/png/jpg格式彩色插图、mdl模型文件、jar虚拟机组件及pdf文档，覆盖图例、建模示例、扩展阅读等完整结构。目前已有573人学习/下载。资源价值体现在四个方面：图例文件夹按插图编号命名，读者可根据需要迅速定位彩色原图；建模示例Rose版（mdl）完整保留建模全过程，适合使用Rational Rose 2002及以上版本逐段拆解；HTML版与Rose版内容一致，无需安装Rational Rose，用支持Java虚拟机的浏览器即可畅通阅读；另附作者《OO系统分析员之路》系列文章PDF，帮助读者深入理解面向对象分析思维，提升实际建模能力。整体布局清晰，适合作为研读原书时的案头参考。

1. 拿到《大象-Thinking in UML》配套光盘之后，先别急着装软件

很多人下载《大象-Thinking in UML》的配套光盘，是为了找书里那几张经典的图例，或者想省事直接看别人画好的模型。但真正打开之后往往会愣一下：里面不是一堆PPT，也不是PDF扫描件，而是各种后缀的模型文件、工具安装包和零散的说明文档。这份光盘的定位很明确——它是配合书中建模方法论使用的模型源文件集，不是电子书替代品。

换句话说，你想从书里学的不是UML图形怎么画得好看，而是怎么把业务诉求转成一套能被团队讨论、能被工具校验的模型。光盘里那几百个模型文件就是用来干这件事的：让你在阅读每个章节时，能直接打开对应的模型，看类怎么抽、关系怎么连、状态图怎么推演，而不是靠脑补。我不建议从头到尾按顺序读，更推荐的做法是：先确认自己的建模环境，再按章节索引一个一个打开模型，边读边改，最后落到一个自己动手画出来的案例上。这篇笔记就按这个路径来拆。

2. 光盘里的模型文件到底是什么：格式、打开方式与建模思维对照

2.1 模型文件不是图，是带语义的结构化数据

很多人第一次打开光盘里的模型文件，双击后系统弹窗让他选打开方式，就以为文件坏了。其实问题出在认知上：这些不是图片格式，而是UML模型工程的序列化文件。书里出现的每一张图，在光盘里基本都能找到对应的模型源文件，你可以把它理解成带着完整语义的“图纸源文件”，而不是渲染好的图片。

常见的光盘版本里会见到几类格式。最典型的是Rational Rose的.mdl文件，这是经典UML建模工具Rational Rose的工程文件格式；另一类是Enterprise Architect的.eap文件，它本质上是一个Access数据库，里面存了模型的所有元素、图和属性。还有一类是XMI格式的交换文件，这种格式跨工具通用性最好，理论上可以被StarUML、PlantUML等工具导入。

这几个格式之间的差别决定了你拿到文件之后能不能顺利打开。Rational Rose是早期UML建模的事实标准，书里的案例基本都能在Rose里复现，但Rose的安装包体积大，且对现代操作系统兼容性一般，很多人在这里翻车。.eap文件用EA打开很顺畅，但EA是商业软件。XMI文件最轻量，但它只是交换格式，没有图形布局信息——用XMI打开后，你会看到所有模型元素都在，但图的位置关系、连线布局全部丢失。

我的建议是：不要纠结于非要找某个指定版本的工具。先确认光盘里模型的真实格式，再决定用什么环境打开。这比自己盲猜重要得多。

2.2 从“看图”切换到“看模型”：一次典型的案例拆解路径

读这本书的理想姿势，不是把光盘里的模型当成“参考答案”直接抄，而是跟着书里的叙述，在模型文件里找到对应的设计决策点。我一般会挑一个贯穿全书的案例来做这件事，比如书中那个经典的业务建模案例。这个案例从业务用例建模一直推到系统用例、分析模型、设计模型，正好覆盖了整本书的主线方法论。

具体做法分三步。

第一步，先打开光盘里的业务用例模型，找到业务用例图。注意不要只看图上的椭圆和箭头，而是要点开每个用例的详细说明。书中反复强调“用例是目标，不是功能”，这句话直接看文字很容易飘，但当你看到光盘里同一个用例名字出现在不同层次的模型里、且职责描述完全不一样时，你才真正理解什么叫“用例的层次”。

第二步，对应到系统用例模型。这一步重点看的是系统边界——光盘模型里通常会有一个明显的边界框，框内是系统要承担的职责，框外是参与者。当你把业务用例和系统用例放在一起对比时，会发现很多业务动作被拆分、合并、甚至被舍弃了，这个处理过程就是建模中最值钱的判断力。

第三步，打开分析模型，看清楚实体类、控制类、边界类的分配关系。这三个类别的划分是整本书最具实操价值的内容之一。在光盘的分析模型里，每个类上都标注了构造型，你可以直接按构造型筛选，看看这个案例里作者是怎么分配职责的。

在这个过程中，不要开着模型文件就完事，我习惯同时开一个文本编辑器，随时记录“这个类为什么放在这里”“这个关系为什么用依赖而不是关联”这类问题。带着问题读模型，比从头到尾点一遍图有效得多。

2.3 用脚本快速摸底：一份XMI文件信息提取参考

如果你拿到的光盘版本里带XMI文件，想快速了解整个模型的规模、类数量、关系类型分布，不需要打开建模工具一个个数。用Python的标准库加一个小脚本就能完成摸底，效率高很多。

import xml.etree.ElementTree as ET import os def analyze_xmi(filepath): # 解析XMI文件，命名空间处理是XMI解析的关键 ns = { 'UML': 'http://www.omg.org/spec/UML/20090901', 'XMI': 'http://www.omg.org/spec/XMI/20131001' } tree = ET.parse(filepath) root = tree.getroot() class_count = 0 association_count = 0 dependency_count = 0 generalization_count = 0 package_names = set() # 遍历所有元素，按标签类型统计 for elem in root.iter(): tag = elem.tag.split('}')[-1] # 去掉命名空间前缀 if tag == 'packagedElement' or tag == 'ownedMember': xmi_type = elem.get('{http://www.omg.org/spec/XMI/20131001}type', '') if 'Class' in xmi_type: class_count += 1 elif 'Association' in xmi_type: association_count += 1 elif 'Dependency' in xmi_type: dependency_count += 1 elif 'Generalization' in xmi_type: generalization_count += 1 if tag == 'Package': name = elem.get('name', 'unnamed') package_names.add(name) # 输出统计结果 print(f'文件: {os.path.basename(filepath)}') print(f'包数量: {len(package_names)}') print(f'类数量: {class_count}') print(f'关联数量: {association_count}') print(f'依赖数量: {dependency_count}') print(f'泛化数量: {generalization_count}') return { 'packages': package_names, 'classes': class_count, 'associations': association_count, 'dependencies': dependency_count, 'generalizations': generalization_count } # 用法示例：统计当前目录下所有XMI文件 for f in os.listdir('.'): if f.endswith('.xmi'): analyze_xmi(f)

这段脚本的核心逻辑是遍历XMI文件的XML树，按元素的类型标签做统计。XMI文件里的元素标签都带命名空间前缀，所以解析时先按}分割取标签名，再用type属性判断元素类型。这样统计出来的结果能让你在打开工具之前就对整个模型的结构有个整体印象。

需要注意的是，XMI版本差异很大。不同工具导出的XMI文件，命名空间URI可能完全不同。上面代码里的命名空间是OMG规范的标准URI，但如果你手里的XMI文件是某个老工具导出的，命名空间可能是空定义或者自定义的，实测时需要先打印出根标签看一下实际的命名空间。我现在写脚本时一般会做一个自适应处理：动态识别根标签的命名空间，而不是硬编码。

3. 搭建建模环境：从光盘文件到能跑通的完整链路

3.1 环境选型：按文件格式决定工具，别按习惯决定工具

建模工具选型是这个环节最容易出问题的地方。很多人习惯用某个工具就直接用，完全不看光盘文件的格式，结果打不开之后怪文件有问题。正确顺序是先识别文件格式，再选工具。

如果光盘里是.mdl文件，那Rational Rose是兼容性最好的选择。注意，这不是让你去买正版或者折腾什么授权，而是说这个格式本身是Rose序列化出来的，用其它工具打开会存在各种细节丢失。比如StarUML理论上支持导入.mdl，但实测中图形布局错乱、角色信息丢失很常见。如果你只是看类图的结构，StarUML能将就；但如果你想打开的是状态图或时序图，建议直接用Rose。

如果光盘里是.eap文件，用Enterprise Architect打开最简单。EA对.eap文件的兼容性最好，而且EA自带免费的只读模式——双击.eap文件，EA没有授权也能浏览模型结构，只是不能保存修改。这其实很适合阅读场景：你只是来学模型的，不一定要改。

如果是XMI文件，我的建议是首选PlantUML或StarUML做快速预览，因为这两个工具轻量，启动快。但XMI导入后布局全乱是正常的，别因为这个怀疑文件损坏。

另一种常见情况是光盘里同时给了多种格式。这种情况优先用模型的原始工程格式，也就是创建者用来画图的那个格式；XMI格式只做交叉验证用，不要当主力格式用。

3.2 一个可复用的模型阅读工作流

不管最后选了什么工具，我建议你建立一个固定的工作流，不要今天用这个方法明天用那个方法。下面这个流程是我自己验证过多次的，步骤不多但每一步都有明确目的。

第一步，先把光盘里的模型文件复制到本地工作目录，注意路径上不要有中文和空格。这个看起来像玄学，但实际上老建模工具对中文路径的支持确实很差，遇到过不少次因为路径里有中文导致模型文件打不开的情况。

第二步，做一个文件格式清单。按目录递归列出所有模型文件，标注格式类型，然后对照目录结构判断这些文件是按章节组织的还是按案例组织的。这一步非常关键，因为很多人在这一步就能发现，光盘里的文件组织方式和书里的章节结构其实不是一一对应的——书是按方法论主线组织的，光盘是按下案例组织的，中间差着一个映射层。

第三步，打开第一个模型文件之前，先看看光盘里有没有README或者文件索引说明。有些版本的光盘里会附带一个Excel或文本索引，列出了每个模型的用途和对应章节。如果有，先把索引读一遍再做文件映射。

第四步，打开模型文件后，先看浏览窗口里的包结构，不要急着看图。包结构是这个模型创作者的分层逻辑——业务层在下，系统层在上，还是反过来，这直接反映了他的建模思维方式。先看包结构能帮你快速定位到想看的模型。

3.3 模型完整性校验：三个必查项

打开模型后，很多人就开始漫无目的地点来点去，一天下来什么也没学到。我建议做三个必查项，每打开一个模型都花两分钟检查一遍。

第一个必查项是检查用例是否都有描述。在建模工具里选中一个用例，看它的详细描述区域是否有文字说明，而不是只有一个名字。书中强调“用例的价值在于描述”，描述是用例的灵魂。如果光盘里的模型文件里用例描述缺失，说明这个模型文件可能是早期版本或者被简化过。

第二个必查项是检查类图里是否有职责说明。选中一个类，看它的属性区域和操作区域——属性对应数据职责，操作对应行为职责。注意看光盘模型里这两个区域的分配是否平衡。我见过很多新手画的类图，属性一大串，操作一个没有，这就是典型的“把类当数据结构画”。

第三个必查项是检查关系是否有角色名和多重性。选中一条关联线，在属性面板里看是否存在两端角色名和多重性约束。如果一条关联线只有连接没有角色名和多重性，那这条关联其实还没有被完整建模，只是画了一条线而已。这在建模评审中是很常见的挑错点。

这三个必查项做完，你基本就能判断这个模型文件的质量和你的理解水平了。如果发现自己的理解跟模型不符，不用急着否定自己，先回到书中对应章节重新读一遍，再回来看模型，往往会有新的发现。

4. 避坑：打开模型文件时最容易踩的五个坑

4.1 现象：双击.mdl文件，系统弹窗提示没有关联程序

这是最高频的问题。现在的新电脑上，.mdl文件没有默认打开程序，Windows只知道这是一个“未识别类型”的文件，就直接弹窗问你要用什么程序打开。很多人在这一步就放弃，以为文件有问题。

原因很简单，Rational Rose本身是一个停止更新很久的工具，它不会在系统里建立文件关联。环境里从来没有装过这个工具，系统自然不知道用什么打开。

解决方式有两种。第一种是装上Rational Rose之后，在工具里通过 Open 菜单手动找到文件路径打开，不要在系统层面纠结文件关联。第二种是用StarUML或其兼容工具导入，虽然布局会有问题，但能看结构。我个人建议装Rational Rose，因为这本书的模型文件本身就是基于Rose环境创作的，在Rose里打开才能最大程度还原原始效果。

4.2 现象：XMI文件导入后，类图上一片空白

XMI导入StarUML或PlantUML后，有时候模型浏览器里能看到类和关系，但图区域是空白的，或者元素全部堆在左上角。

原因是XMI文件在导出时保留了完整的语义信息，但不一定保留图形布局信息。不同工具对XMI的图形布局支持不一致，很多工具导出XMI时不写diagram信息，只写模型信息。导入方拿到模型但没有图布局数据，就只能把所有元素堆在一起。

解决方式是做逆向操作：不从XMI导入图，而是从XMI导入模型后，自行重新制图。这个方法确实要多花时间，但至少保证了模型的语义完整。另一种做法是提前用2.3节里的脚本检查XMI里是否包含Diagram相关标签，如果没有，就不要指望导入后能直接看到布局。

4.3 现象：Rational Rose安装后打开模型，提示找不到类库或框架

安装好Rose准备打开模型，弹出一个对话框说找不到某些类库或框架，问是否继续。很多人怕继续打开之后模型会坏，就取消打开了。

原因是这个模型文件在创建时关联了某些附加的类库或框架配置，通常是VC++或Java类库。你当前的Rose实例里没有配置对应的类库，Rose就提示无法完整加载。

解决方式很直接：点继续。这个提示不影响模型主体内容的加载，它影响的只是某些代码生成相关的语义细节。你读的是UML模型，不是做代码生成，所以忽略这个提示没有任何问题。

4.4 现象：打开.eap文件时提示“文件损坏”

.eap文件本质上是Access数据库文件，很多人遇到提示损坏后第一反应是重新下载。

原因多半不是文件真的损坏，而是文件被下载工具截断，或者下载时网络中断导致数据库文件不完整。其次，.eap文件是单文件数据库，如果被微信或某些网盘客户端“优化”过，文件内部结构也会被改变。

解决方式是用专业的文件校验工具对比原始MD5和下载后的MD5，不一致就重新下载。同时注意，不要把.eap文件放在由网盘客户端实时同步的目录里打开，有些网盘会在后台锁定文件，导致EA无法正常读取。把文件复制到本地独立目录再打开，问题基本消失。

4.5 现象：模型打开后图表显示正常，但无法导出为图片

很多人想把光盘里的模型图导出来放到自己的笔记里，但发现导出为图片的功能是灰色的，或者导出后图片分辨率极低。

原因是有些建模工具在未注册或受限模式下禁用了导出功能，又或者模型里的字体和图形设置使用了特定环境下的字体，导致导出时渲染有问题。

解决方式分情况。如果当前工具导出被禁用，就用系统截图来替代，截图虽然粗糙但能记录信息。如果导出分辨率低，在导出设置里调高DPI或分辨率选项，一般能从100调到300。另外，导出前全选模型图内容，统一修改字体为标准字体，比如微软雅黑或宋体，能在很大程度上避免字体渲染异常的问题。

5. 把光盘模型当成“阅后即焚”的教学素材太浪费：推荐一套进阶验证方法

模型文件的价值不在于打开看一遍，而在于把它当成验证自己理解的基准。我之前带过几个新人，做法很简单，但效果很好。

先用光盘里的模型做“盲画练习”。我让他们打开一个用例模型的描述文档，把模型图本身关掉，仅凭文字描述在工具里重画这个用例图。画完之后再打开光盘里的原始模型对比。对比时重点看三个位置：用例划分的边界是否一致、参与者的位置和数量是否一致、包含关系和扩展关系的使用是否一致。这三个位置对完之后，建模思维的分歧就一目了然了。

这个练习做完之后，可以尝试第二个进阶操作：对模型做一致性审查。光盘里的模型不是完美无缺的，它也存在一些常见的建模问题。比如有些类可能职责过重，有些用例可能描述模糊。用3.3节里的三个必查项逐一审查光盘模型，把发现的问题列出清单，然后尝试给出自己的修改方案。这个过程的意义不在于“证明光盘模型不好”，而在于训练自己的模型审查能力——你只有在别人的模型里找出问题，才能在自己的模型里避开同样的问题。

第三个进阶操作是把模型和代码关联起来。书里讲的是UML建模，但最终这些模型是要落到代码里的。光盘里的模型如果有对应的设计模型，可以尝试用建模工具的代码生成功能，生成一段骨架代码。注意，不要指望生成的代码能直接编译运行，它的价值在于让你看到类图上的关系如何映射为代码层面的关联、依赖和继承。这个“模型到代码”的映射感，是很多读了书但没做过完整项目的人最缺的一块。

在表格下面，我把这三个进阶验证操作整理成一个可直接执行的检查清单，方便你每完成一步就对照勾选：

这三步走完，光盘才真正发挥教学参考的作用。在那之后我每次带新人读建模相关的书，都会强制走一遍“先读模型、盲画对比、审查模型、生成代码”的完整流程，能明显看出建模思维提升速度比单纯翻书快得多。希望这套方法也能帮你在学习UML建模的路上少走弯路。

本文还有配套的精品资源，点击获取