第一次把一段两千字的需求描述粘进文本分析面板、点下分析按钮的时候我盯着右边跳出来的一堆候选词有点发懵——大部分确实是我写进文档里的名词但有一半根本不该成为类。后来连着几个项目反复用下来才想明白这个功能最值钱的地方并不在于自动生成而在于它把一段混着业务口语和半正式术语的文字强行拆成一张带类型标签的候选清单逼着你去回答这个词到底是实体、是动作还是只是个修饰语。这件事人工做起来极其枯燥工具做起来又快又一致但判断题还得你自己做。这篇内容围绕 Visual Paradigm 里的文本分析Textual Analysis功能展开讲清楚它是怎么把自然语言需求转成 UML 候选元素的、操作链路长什么样、什么样的文本喂进去效果最好、以及哪些地方最容易翻车。适合两类人看一类是刚接手需求、准备画第一版领域模型或用例图的同学另一类是已经画了几年图、但一直在靠脑子硬啃需求文档、还没系统用过这个功能的老手。不需要你熟到什么程度知道类图和用例图长什么样就能跟上。1. 文本分析在需求建模里到底在解决什么问题1.1 从一段业务描述到一张候选清单的转化过程日常拿到手的原始需求绝大多数是这个样子一段话里混着角色、动作、业务对象、约束条件句子还经常缺主语。比如运营人员在后台创建促销活动系统根据活动规则自动计算折扣活动结束后需要归档历史记录。人读完能理解但你要从这句话里抽出类、抽用例、抽参与者就得在脑子里做一次拆解。文本分析干的就是这次拆解的机械化版本。它的底层逻辑可以拆成三步先对文本做分词和词性标注把句子切成一个一个词并判断词性再按预设的规则把不同词性的词归到不同类型下面——名词性成分归到类候选动词性成分结合宾语归到用例候选指人或指系统的名词归到参与者候选最后按出现频次和上下文给你排个序形成一张可勾选的列表。用生活化的说法这就像你请了个实习生帮你把一份会议纪要里的人名要做的事要用的东西分开抄在三张纸上。实习生不懂你的业务抄得可能不准但他抄得快、不漏项而且抄完你一眼就能看出哪条抄错了改起来比你从头自己分拣省事得多。文本分析就是这个实习生它的价值建立在人工复核成本低于人工从头分拣成本这个前提上。这里有个容易被忽略的点候选清单里的每一类并不是平级的。类候选给的是静态结构用例候选给的是行为参与者候选给的是边界。这三样凑在一起恰好是一张用例图和一张初步类图的最小素材集。所以文本分析天然适合放在需求梳理的最开头而不是等到模型画了一半再回头补。1.2 名词-动词分析法到今天还没有被淘汰的原因有人会问现在都讲究领域驱动设计、事件风暴、用户故事地图了这种老派的名词-动词分析法是不是过时了。我的看法是方法论在演进但从语言里提取结构这件事没变。事件风暴贴便利贴本质上也是在把句子里的名词和动词拆出来分类只是把工具从软件换成了墙面和纸片。名词-动词法能活这么久原因很实际它不依赖任何前置资产。你不需要先有一份术语表不需要先跟业务方对齐分层架构甚至不需要团队里有领域专家坐镇。给它一段文字它就能吐出一张初稿。对于那种需求刚到手、什么模型都没有、连边界在哪都模糊的阶段这种从零启动的能力非常关键。另一个原因是它的产物可追溯。从候选清单里勾出来的每一个类都能对应回原文里的某句话某个词。这在评审时特别好用——业务方质疑这个类为什么要建你可以直接把原文那句高亮指给他看。相比之下凭经验拍脑袋建的类事后很难解释来源。当然它也有明确的短板。它处理不了隐含语义也处理不了跨句的指代关系。一句该对象在提交后进入待审状态里的该对象指代什么工具判断不出来只能靠人。所以我的习惯是把文本分析定位成初稿生成器而不是需求理解器。1.3 工具能替你做的那部分和不能替你做的那部分把边界划清楚用起来才不别扭。以下是我总结的能力对照按我实际用下来的感受整理环节工具能做的必须人来做的分词与词性判断英文文本基本可靠能识别名词、动词、形容词中文长句、专业术语、缩略语的判断需要人工兜底候选归类按名词/动词/指人名词自动分组判断某个名词到底是实体、值对象还是属性频次统计统计词出现次数辅助判断重要性判断出现多是否等于重要高亮回溯在原文中定位候选词的出处判断上下文语义是否被误读模型落地一键生成类、用例、参与者到图上决定继承关系、聚合关系、用例粒度冗余合并同词合并判断订单和订单信息是否应该合并这张表最关键的一行是最后一行。工具做的是词语级别的合并而模型需要的是概念级别的合并。一个项目里用户客户会员三个词工具会给你三个候选类但它们可能指同一个东西也可能确实要分开——这完全取决于业务语境工具无从判断。理解了这条边界你就不会对它抱有不切实际的期待也不会因为它偶尔犯蠢就彻底弃用。它是个筛子不是个厨师。2. 把文本伺候好进入分析之前的预处理2.1 按场景切段而不是把整篇文档一次性倒进去我见过最常见的用法失误就是把一份几十页的需求文档整篇粘贴进去点分析。结果就是候选列表里几百个词光滚动就要滑半天最后只能凭感觉瞎勾几个等于白做。正确的做法是按场景或按功能模块切段一次分析一段。原因很直接文本分析出来的候选清单是给当前这一段建模用的段与段之间的词往往属于不同的限界上下文。你把下单流程和对账流程混在一起分析账户这个词会被合并成一个候选但在两个上下文里它可能完全是两个东西。我通常会这样切一个用户故事或一个用例场景算一段长度大概控制在两百到五百字。太短了上下文不足词性判断会失准太长了噪声爆炸人工复核成本陡增。如果一段文本里出现了明显的话题跳转比如前半段讲下单后半段讲退款那就果断拆开。拆段还有一个附带好处每一段的候选清单可以直接对应到一张图。做完一段就落地一次模型和文本保持同步后面回头查证的时候不会乱。2.2 项目词表与忽略词是识别噪声的第一道闸文本分析面板里通常会有忽略词Ignore Words之类的配置可以维护一张不要识别这些词的清单。这个东西看着不起眼实际上决定了候选列表的干净程度。我的做法是在项目启动时先攒一张基础忽略词表覆盖三类词。第一类是结构性虚词比如系统平台模块功能界面这类词——它们几乎在每个句子里都出现但永远不会成为有意义的类。第二类是项目管理词汇比如需求版本迭代评审。第三类是业务上的通用修饰词比如相关对应相应各个。这些词如果不排除它们会因为高频而排在候选列表最前面把你的注意力全占了。我曾经在一个项目里忘了配忽略词结果候选列表前十名里八个是系统信息数据这种词真正重要的业务实体被压在二十名开外。反过来说还有一类词需要放进强制保留或者项目术语表就是那些拼写特殊、容易被切错的专有名词。比如业务里的某个特定单据名称、某个内部叫法如果不提前登记工具很可能把它拆成两个无意义的词或者干脆识别成动词。提示忽略词表不是一次配完就完事的。每做完一轮分析把误识别的词顺手加进去两三个迭代下来这张表就非常贴合你的项目了后面新人的分析质量也会跟着上来。2.3 中文文本的分词和切分策略这一节说说中文的情况因为这是绕不开的现实问题。以我手上用的版本为例文本分析对英文的处理明显更稳词性标注和短语切分都比较准中文段落跑下来常见的现象是长名词被拆开、动词短语识别不出来、整句被当成一个候选。原因不难理解英文靠空格分词词性标注的训练语料也成熟中文要依赖分词算法而业务文本里的专有名词恰恰是分词器最不擅长的部分。这不是某个工具的问题是这类功能共同的边界。我摸索出来的应对办法有几条。第一条是尽量在文本里给专有名词加上明确的边界标记比如统一用书名号或者引号把关键实体括起来很多工具会把这类标记当成分词提示。第二条是把长句拆成短句每个短句只表达一个动作或者一个对象主谓宾齐全这样即使分词有误人工复核也快。第三条是术语表前置把核心实体名先登记进去让分词器有依据。如果项目允许还有一个更省事的方案把核心场景用英文重写一遍再分析中文版留着做评审材料。这种做法在双语团队里挺常见缺点是维护两份文本。要不要这么干看你的项目对建模精度的要求。不管用哪种办法中文文本的候选清单我建议默认按高噪声对待复核的时候宁可多花时间也不要直接信。3. 跑一次完整分析从粘贴文本到候选落地3.1 操作链路的完整拆解把流程拆开讲方便你第一次操作时心里有数。不同版本在菜单位置和按钮措辞上会有差异按功能名去找就行。第一步是打开文本分析面板。这个入口一般在工具栏或者菜单里的建模辅助工具分组下。打开后通常是一个分栏界面左边或者上边是文本输入区右边或者下边是候选结果区。第二步是粘贴文本。这里我建议直接把预处理好的那一段贴进去不要带多余的标题、编号、项目符号纯文字最干净。如果原文里有表格把表格内容转成一句一句的陈述句再贴否则行列结构会被打乱。第三步是配置分析选项。常见的选项包括分析语言、是否启用忽略词表、是否只识别特定类型的候选。如果有分析语言的选项务必选对选错了分词结果会完全变形。第四步是执行分析。点下按钮之后工具会对文本做标注并生成候选列表。这一步通常很快几百字几乎瞬间出结果。第五步是复核与筛选。候选列表里每一条前面有勾选框还有一个高亮按钮可以把该词在原文里定位出来。这一步是整个流程里最耗时的也是最能体现经验的地方。第六步是落地。勾选完之后通常有一个生成模型的按钮可以把选中的类候选生成到当前类图上或者把用例候选生成到用例图上。第七步是清理。落地之后回到图上把自动生成的位置重新排布把命名改成符合项目规范的写法。整个链路走一遍一段三百字的文本熟练之后大概十分钟能出第一版图。这个速度是纯手工做不到的。3.2 候选列表的三轮筛法复核这件事如果没有章法很容易变成看着顺眼就勾最后出来的模型质量全靠运气。我一般分三轮走。第一轮做粗筛只看两件事这个词在业务里有没有独立身份以及它是不是被切错了。判断标准很简单——如果我能用一句话描述它的职责并且这个职责不会和别的候选重叠就留下。大于一半的候选在这一轮就能定下来。第二轮做归并专门处理近义词和上下位词。订单和订单信息要不要合并客户和客户档案是不是一回事这一轮要逐个拍板。拍板的时候不要凭感觉去原文里把两个词出现的句子都调出来对照看它们在语境里是否可替换。可替换的合并不可替换的保留。第三轮做类型修正。工具给出的分类只是建议经常需要改。比如某个词被识别成类候选但它在原文里明显是个状态值比如待支付已完成那它应该作为枚举或者属性而不是类。再比如某个动作被识别成用例但它其实是系统内部的自动行为不该出现在用例图上。下面这张表是我常用的类型判定参考对着它过一遍能省不少犹豫原文里的词工具常见分类我实际的处理订单、合同、发票类候选保留为类待审核、已发货类候选名词化转为状态枚举不入类图提交订单、发起退款用例候选保留为用例注意补参与者校验、计算用例候选动词若为系统内部逻辑剔除运营人员、管理员参与者候选保留注意角色合并系统参与者候选剔除除非有外部系统交互3.3 候选落地成模型元素之后还要做什么勾选生成只是把词变成了图上的方框离一张能用的图还差几步。这几步如果省掉图会看起来很热闹但没法用。第一件事是命名规范化。工具生成的名字直接取自原文往往是口语化的还带着信息相关处理这类尾巴。要在落地后统一改成项目约定的命名风格。这件事不是强迫症命名直接决定了后面代码生成、接口设计的一致性前期省事后期加倍还。第二件事是补关系。文本分析只给你孤立的元素给不了关系。类之间的关联、聚合、组合用例之间的包含、扩展都得手工补。补关系的时候回头去读原文里那些被跳过的句子——那些句子往往正是描述关系的比如一个订单包含多个商品明细这种句子对文本分析来说是低价值的因为它的主体词已经被提取过了但对补关系来说是高价值的。第三件事是标记来源。我习惯在每个自动生成的元素上挂一段注释写上它来自哪一段文本的哪个词。这个习惯在项目后期价值极大特别是需求变更频繁的项目某个类要不要删、改了会不会影响别处一查注释就清楚了。第四件事是分层。一口气生成的类会全堆在同一层需要按职责拆到不同包里。这一步建议晚一点做等候选基本稳定了再动否则反复挪包很浪费时间。4. 决定候选质量的那几个变量4.1 文本本身的规范程度这一条的重要性超过其他所有变量加起来。同样一个工具喂规范文本和喂口语文本出来的候选质量能差出一倍以上。什么算规范主语明确动作有明确主语实体名前后一致不要一会儿叫会员一会儿叫用户避免大段的名词堆砌避免一句里套三个从句。达到这个标准的文本候选清单里七八成是可以直接用的。现实里大部分需求文档达不到这个标准。我的做法不是去要求业务方重写文档而是在分析前自己过一遍做一次轻量的改写。改写的重点是补主语、拆长句、统一术语。这个改写过程大概花十分钟能省下后面半小时的复核时间非常划算。顺便说一个副作用改写的过程其实也是一次理解的过程。很多时候改到一半你自己就发现需求里有个逻辑说不通的地方提前暴露问题总比建模到一半才发现好。4.2 忽略词表的覆盖度前面提过忽略词表这里补充一个细节这张表要分层维护。项目级有一张通用的覆盖系统模块这类跨项目通用的噪声词业务域级有一张覆盖这个领域特有的高频虚词。两层叠加使用。维护节奏上我建议每轮分析结束花两分钟把新发现的噪声词补进去。这件事的复利效应很高——一个十人的团队如果每个人都有维护习惯一个月下来能省掉的复核时间相当可观。另外提醒一句忽略词表的粒度要控制好。加得太宽会把有效词也挡掉比如把信息整体加进去那商品信息物流信息这种本来有意义的复合词也会受影响。我的经验是只有在确认某个词单独出现时永远没有建模价值的情况下才把它加进忽略清单。4.3 语义边界的清晰度同一个词在不同上下文里指代不同东西这是文本分析最容易出错的地方也是最难靠配置解决的地方。举个典型情况一段文本讲审批前半段说的是发起审批的动作后半段说的是审批单据这个对象。工具会把两次出现的审批合并成一个候选无论归到哪一类都是错的——正确答案是两个类一个是用例一个是实体。处理这类问题没有取巧办法只能靠高亮回溯逐条核对。但有个提高效率的技巧优先核对高频候选。出现次数多的词往往语义被复用得最多出错概率也最高。低频词反而可以快速扫过。还有一个判断技巧如果一个候选词在原文里出现时前面跟着的动词不一样比如提交审批和查看审批那它大概率是个对象如果前面跟的是同一个动词的变体那它大概率是个动作。4.4 复核节奏的把控这一条听起来虚实际上很影响最终成果。我试过两种极端一种是分析完立刻一口气复核完另一种是分析完放一放隔天再复核。第一种的问题是会疲劳复核到后半段注意力下降判断质量明显下滑。第二种的问题是有延迟成本隔天回来要重新进入上下文。我现在的做法是分段复核每分析完一段先做第一轮粗筛快速勾掉明显不行的然后切到下一段。等三四段都做完粗筛再回头统一做归并和类型修正。这样既避免了长时间连续判断的疲劳又保证了归并时有足够的全局视野。5. 我在实际项目里踩过的几个坑5.1 把描述性文字原样倒进去候选全是水词最早一次踩坑是把一份产品经理写的功能描述原封不动贴进去。那份文档写得很产品满篇是用户可以方便快捷地完成操作系统会智能地推荐相关内容。分析出来的候选里用户系统内容排在前三智能方便相关也被当成候选冒了出来。问题出在形容词和副词上。这类词在文本里高频出现对建模毫无价值但工具不知道照单全收。规避办法就是我前面说的预处理——分析前花十分钟把描述性、评价性的句子删掉或者改写成陈述句。用户可以方便快捷地完成下单改写成用户提交订单候选立刻就干净了。这件事没有技术含量纯粹是愿不愿意花这十分钟的问题。5.2 全盘接受候选模型变成垃圾场第二个坑是偷懒想着反正工具都识别出来了全勾上生成后面再删。结果生成出来一张四十多个类的图关系一条没有命名五花八门删也不知道从哪删起最后整张图废弃重画比手工建还费时间。这个坑的教训很明确自动生成的元素必须经过人工确认才能进模型。宁可只留十个确认过的也不要留四十个待定的。图这个东西元素一多就失去沟通价值而沟通价值恰恰是画图的主要目的。我后来的做法是给候选设一个默认拒绝的态度——凡是我不确定要不要的先不勾。等整个模块的图基本成型了再回头看看缺不缺东西。这个顺序反过来了但效果好很多因为有了上下文之后判断更准。5.3 忽略词表配得太狠把有效信息挡在门外有一段时间我为了追求候选列表的干净把忽略词表塞得特别满结果发现某些本该出现的实体压根没被识别出来。排查了半天才想起来那个词在前一轮被我一并划进了忽略清单。这件事提醒我忽略词表和候选清单一样需要复核。我的补救办法是定期清空重建一次——把忽略词表复制一份出来逐条问自己这个词在任何语境下都不可能成为模型元素吗答不上来的就移出去。听起来麻烦但一个季度做一次成本可以接受。5.4 把一次分析的结果当成最终模型最后一个坑也是最隐蔽的分析完、图也生成好了看起来挺完整就直接拿去评审。评审的时候被问这个类和那个类为什么没有关系才意识到文本分析根本没给关系而我自己也没补。这个坑的本质是把元素齐了误当成模型齐了。一张类图的价值八成在关系上只有类没有关系等于一堆散落的词卡。现在的习惯是生成元素之后强制自己走一遍关系补全流程先把所有一对多、多对多的业务规则从原文里找出来逐条连线再检查有没有明显的聚合关系最后给每个类至少挂一个属性哪怕先写个占位。走完这三步图才算能拿去讨论。回头看在文本分析这个功能上花的时间最值回票价的其实不是那个一键生成的按钮而是它逼着我把需求文本逐句读了一遍。以前靠脑子读读完以为懂了其实跳过了一堆含糊的表述现在被候选清单逼着逐词确认那些含糊的地方一个都藏不住。工具本身谈不上多智能但它把一件本该做但一直被跳过的事变得不那么痛苦了这就够了。真要说有什么建议就是别指望一次跑出完美结果。把它当成第一遍粗读的加速器跑完立刻动手改改的过程中对需求的理解才是真正沉淀下来的东西。
第一次把一段两千字的需求描述粘进文本分析面板、点下分析按钮的时候我盯着右边跳出来的一堆候选词有点发懵——大部分确实是我写进文档里的名词但有一半根本不该成为类。后来连着几个项目反复用下来才想明白这个功能最值钱的地方并不在于自动生成而在于它把一段混着业务口语和半正式术语的文字强行拆成一张带类型标签的候选清单逼着你去回答这个词到底是实体、是动作还是只是个修饰语。这件事人工做起来极其枯燥工具做起来又快又一致但判断题还得你自己做。这篇内容围绕 Visual Paradigm 里的文本分析Textual Analysis功能展开讲清楚它是怎么把自然语言需求转成 UML 候选元素的、操作链路长什么样、什么样的文本喂进去效果最好、以及哪些地方最容易翻车。适合两类人看一类是刚接手需求、准备画第一版领域模型或用例图的同学另一类是已经画了几年图、但一直在靠脑子硬啃需求文档、还没系统用过这个功能的老手。不需要你熟到什么程度知道类图和用例图长什么样就能跟上。1. 文本分析在需求建模里到底在解决什么问题1.1 从一段业务描述到一张候选清单的转化过程日常拿到手的原始需求绝大多数是这个样子一段话里混着角色、动作、业务对象、约束条件句子还经常缺主语。比如运营人员在后台创建促销活动系统根据活动规则自动计算折扣活动结束后需要归档历史记录。人读完能理解但你要从这句话里抽出类、抽用例、抽参与者就得在脑子里做一次拆解。文本分析干的就是这次拆解的机械化版本。它的底层逻辑可以拆成三步先对文本做分词和词性标注把句子切成一个一个词并判断词性再按预设的规则把不同词性的词归到不同类型下面——名词性成分归到类候选动词性成分结合宾语归到用例候选指人或指系统的名词归到参与者候选最后按出现频次和上下文给你排个序形成一张可勾选的列表。用生活化的说法这就像你请了个实习生帮你把一份会议纪要里的人名要做的事要用的东西分开抄在三张纸上。实习生不懂你的业务抄得可能不准但他抄得快、不漏项而且抄完你一眼就能看出哪条抄错了改起来比你从头自己分拣省事得多。文本分析就是这个实习生它的价值建立在人工复核成本低于人工从头分拣成本这个前提上。这里有个容易被忽略的点候选清单里的每一类并不是平级的。类候选给的是静态结构用例候选给的是行为参与者候选给的是边界。这三样凑在一起恰好是一张用例图和一张初步类图的最小素材集。所以文本分析天然适合放在需求梳理的最开头而不是等到模型画了一半再回头补。1.2 名词-动词分析法到今天还没有被淘汰的原因有人会问现在都讲究领域驱动设计、事件风暴、用户故事地图了这种老派的名词-动词分析法是不是过时了。我的看法是方法论在演进但从语言里提取结构这件事没变。事件风暴贴便利贴本质上也是在把句子里的名词和动词拆出来分类只是把工具从软件换成了墙面和纸片。名词-动词法能活这么久原因很实际它不依赖任何前置资产。你不需要先有一份术语表不需要先跟业务方对齐分层架构甚至不需要团队里有领域专家坐镇。给它一段文字它就能吐出一张初稿。对于那种需求刚到手、什么模型都没有、连边界在哪都模糊的阶段这种从零启动的能力非常关键。另一个原因是它的产物可追溯。从候选清单里勾出来的每一个类都能对应回原文里的某句话某个词。这在评审时特别好用——业务方质疑这个类为什么要建你可以直接把原文那句高亮指给他看。相比之下凭经验拍脑袋建的类事后很难解释来源。当然它也有明确的短板。它处理不了隐含语义也处理不了跨句的指代关系。一句该对象在提交后进入待审状态里的该对象指代什么工具判断不出来只能靠人。所以我的习惯是把文本分析定位成初稿生成器而不是需求理解器。1.3 工具能替你做的那部分和不能替你做的那部分把边界划清楚用起来才不别扭。以下是我总结的能力对照按我实际用下来的感受整理环节工具能做的必须人来做的分词与词性判断英文文本基本可靠能识别名词、动词、形容词中文长句、专业术语、缩略语的判断需要人工兜底候选归类按名词/动词/指人名词自动分组判断某个名词到底是实体、值对象还是属性频次统计统计词出现次数辅助判断重要性判断出现多是否等于重要高亮回溯在原文中定位候选词的出处判断上下文语义是否被误读模型落地一键生成类、用例、参与者到图上决定继承关系、聚合关系、用例粒度冗余合并同词合并判断订单和订单信息是否应该合并这张表最关键的一行是最后一行。工具做的是词语级别的合并而模型需要的是概念级别的合并。一个项目里用户客户会员三个词工具会给你三个候选类但它们可能指同一个东西也可能确实要分开——这完全取决于业务语境工具无从判断。理解了这条边界你就不会对它抱有不切实际的期待也不会因为它偶尔犯蠢就彻底弃用。它是个筛子不是个厨师。2. 把文本伺候好进入分析之前的预处理2.1 按场景切段而不是把整篇文档一次性倒进去我见过最常见的用法失误就是把一份几十页的需求文档整篇粘贴进去点分析。结果就是候选列表里几百个词光滚动就要滑半天最后只能凭感觉瞎勾几个等于白做。正确的做法是按场景或按功能模块切段一次分析一段。原因很直接文本分析出来的候选清单是给当前这一段建模用的段与段之间的词往往属于不同的限界上下文。你把下单流程和对账流程混在一起分析账户这个词会被合并成一个候选但在两个上下文里它可能完全是两个东西。我通常会这样切一个用户故事或一个用例场景算一段长度大概控制在两百到五百字。太短了上下文不足词性判断会失准太长了噪声爆炸人工复核成本陡增。如果一段文本里出现了明显的话题跳转比如前半段讲下单后半段讲退款那就果断拆开。拆段还有一个附带好处每一段的候选清单可以直接对应到一张图。做完一段就落地一次模型和文本保持同步后面回头查证的时候不会乱。2.2 项目词表与忽略词是识别噪声的第一道闸文本分析面板里通常会有忽略词Ignore Words之类的配置可以维护一张不要识别这些词的清单。这个东西看着不起眼实际上决定了候选列表的干净程度。我的做法是在项目启动时先攒一张基础忽略词表覆盖三类词。第一类是结构性虚词比如系统平台模块功能界面这类词——它们几乎在每个句子里都出现但永远不会成为有意义的类。第二类是项目管理词汇比如需求版本迭代评审。第三类是业务上的通用修饰词比如相关对应相应各个。这些词如果不排除它们会因为高频而排在候选列表最前面把你的注意力全占了。我曾经在一个项目里忘了配忽略词结果候选列表前十名里八个是系统信息数据这种词真正重要的业务实体被压在二十名开外。反过来说还有一类词需要放进强制保留或者项目术语表就是那些拼写特殊、容易被切错的专有名词。比如业务里的某个特定单据名称、某个内部叫法如果不提前登记工具很可能把它拆成两个无意义的词或者干脆识别成动词。提示忽略词表不是一次配完就完事的。每做完一轮分析把误识别的词顺手加进去两三个迭代下来这张表就非常贴合你的项目了后面新人的分析质量也会跟着上来。2.3 中文文本的分词和切分策略这一节说说中文的情况因为这是绕不开的现实问题。以我手上用的版本为例文本分析对英文的处理明显更稳词性标注和短语切分都比较准中文段落跑下来常见的现象是长名词被拆开、动词短语识别不出来、整句被当成一个候选。原因不难理解英文靠空格分词词性标注的训练语料也成熟中文要依赖分词算法而业务文本里的专有名词恰恰是分词器最不擅长的部分。这不是某个工具的问题是这类功能共同的边界。我摸索出来的应对办法有几条。第一条是尽量在文本里给专有名词加上明确的边界标记比如统一用书名号或者引号把关键实体括起来很多工具会把这类标记当成分词提示。第二条是把长句拆成短句每个短句只表达一个动作或者一个对象主谓宾齐全这样即使分词有误人工复核也快。第三条是术语表前置把核心实体名先登记进去让分词器有依据。如果项目允许还有一个更省事的方案把核心场景用英文重写一遍再分析中文版留着做评审材料。这种做法在双语团队里挺常见缺点是维护两份文本。要不要这么干看你的项目对建模精度的要求。不管用哪种办法中文文本的候选清单我建议默认按高噪声对待复核的时候宁可多花时间也不要直接信。3. 跑一次完整分析从粘贴文本到候选落地3.1 操作链路的完整拆解把流程拆开讲方便你第一次操作时心里有数。不同版本在菜单位置和按钮措辞上会有差异按功能名去找就行。第一步是打开文本分析面板。这个入口一般在工具栏或者菜单里的建模辅助工具分组下。打开后通常是一个分栏界面左边或者上边是文本输入区右边或者下边是候选结果区。第二步是粘贴文本。这里我建议直接把预处理好的那一段贴进去不要带多余的标题、编号、项目符号纯文字最干净。如果原文里有表格把表格内容转成一句一句的陈述句再贴否则行列结构会被打乱。第三步是配置分析选项。常见的选项包括分析语言、是否启用忽略词表、是否只识别特定类型的候选。如果有分析语言的选项务必选对选错了分词结果会完全变形。第四步是执行分析。点下按钮之后工具会对文本做标注并生成候选列表。这一步通常很快几百字几乎瞬间出结果。第五步是复核与筛选。候选列表里每一条前面有勾选框还有一个高亮按钮可以把该词在原文里定位出来。这一步是整个流程里最耗时的也是最能体现经验的地方。第六步是落地。勾选完之后通常有一个生成模型的按钮可以把选中的类候选生成到当前类图上或者把用例候选生成到用例图上。第七步是清理。落地之后回到图上把自动生成的位置重新排布把命名改成符合项目规范的写法。整个链路走一遍一段三百字的文本熟练之后大概十分钟能出第一版图。这个速度是纯手工做不到的。3.2 候选列表的三轮筛法复核这件事如果没有章法很容易变成看着顺眼就勾最后出来的模型质量全靠运气。我一般分三轮走。第一轮做粗筛只看两件事这个词在业务里有没有独立身份以及它是不是被切错了。判断标准很简单——如果我能用一句话描述它的职责并且这个职责不会和别的候选重叠就留下。大于一半的候选在这一轮就能定下来。第二轮做归并专门处理近义词和上下位词。订单和订单信息要不要合并客户和客户档案是不是一回事这一轮要逐个拍板。拍板的时候不要凭感觉去原文里把两个词出现的句子都调出来对照看它们在语境里是否可替换。可替换的合并不可替换的保留。第三轮做类型修正。工具给出的分类只是建议经常需要改。比如某个词被识别成类候选但它在原文里明显是个状态值比如待支付已完成那它应该作为枚举或者属性而不是类。再比如某个动作被识别成用例但它其实是系统内部的自动行为不该出现在用例图上。下面这张表是我常用的类型判定参考对着它过一遍能省不少犹豫原文里的词工具常见分类我实际的处理订单、合同、发票类候选保留为类待审核、已发货类候选名词化转为状态枚举不入类图提交订单、发起退款用例候选保留为用例注意补参与者校验、计算用例候选动词若为系统内部逻辑剔除运营人员、管理员参与者候选保留注意角色合并系统参与者候选剔除除非有外部系统交互3.3 候选落地成模型元素之后还要做什么勾选生成只是把词变成了图上的方框离一张能用的图还差几步。这几步如果省掉图会看起来很热闹但没法用。第一件事是命名规范化。工具生成的名字直接取自原文往往是口语化的还带着信息相关处理这类尾巴。要在落地后统一改成项目约定的命名风格。这件事不是强迫症命名直接决定了后面代码生成、接口设计的一致性前期省事后期加倍还。第二件事是补关系。文本分析只给你孤立的元素给不了关系。类之间的关联、聚合、组合用例之间的包含、扩展都得手工补。补关系的时候回头去读原文里那些被跳过的句子——那些句子往往正是描述关系的比如一个订单包含多个商品明细这种句子对文本分析来说是低价值的因为它的主体词已经被提取过了但对补关系来说是高价值的。第三件事是标记来源。我习惯在每个自动生成的元素上挂一段注释写上它来自哪一段文本的哪个词。这个习惯在项目后期价值极大特别是需求变更频繁的项目某个类要不要删、改了会不会影响别处一查注释就清楚了。第四件事是分层。一口气生成的类会全堆在同一层需要按职责拆到不同包里。这一步建议晚一点做等候选基本稳定了再动否则反复挪包很浪费时间。4. 决定候选质量的那几个变量4.1 文本本身的规范程度这一条的重要性超过其他所有变量加起来。同样一个工具喂规范文本和喂口语文本出来的候选质量能差出一倍以上。什么算规范主语明确动作有明确主语实体名前后一致不要一会儿叫会员一会儿叫用户避免大段的名词堆砌避免一句里套三个从句。达到这个标准的文本候选清单里七八成是可以直接用的。现实里大部分需求文档达不到这个标准。我的做法不是去要求业务方重写文档而是在分析前自己过一遍做一次轻量的改写。改写的重点是补主语、拆长句、统一术语。这个改写过程大概花十分钟能省下后面半小时的复核时间非常划算。顺便说一个副作用改写的过程其实也是一次理解的过程。很多时候改到一半你自己就发现需求里有个逻辑说不通的地方提前暴露问题总比建模到一半才发现好。4.2 忽略词表的覆盖度前面提过忽略词表这里补充一个细节这张表要分层维护。项目级有一张通用的覆盖系统模块这类跨项目通用的噪声词业务域级有一张覆盖这个领域特有的高频虚词。两层叠加使用。维护节奏上我建议每轮分析结束花两分钟把新发现的噪声词补进去。这件事的复利效应很高——一个十人的团队如果每个人都有维护习惯一个月下来能省掉的复核时间相当可观。另外提醒一句忽略词表的粒度要控制好。加得太宽会把有效词也挡掉比如把信息整体加进去那商品信息物流信息这种本来有意义的复合词也会受影响。我的经验是只有在确认某个词单独出现时永远没有建模价值的情况下才把它加进忽略清单。4.3 语义边界的清晰度同一个词在不同上下文里指代不同东西这是文本分析最容易出错的地方也是最难靠配置解决的地方。举个典型情况一段文本讲审批前半段说的是发起审批的动作后半段说的是审批单据这个对象。工具会把两次出现的审批合并成一个候选无论归到哪一类都是错的——正确答案是两个类一个是用例一个是实体。处理这类问题没有取巧办法只能靠高亮回溯逐条核对。但有个提高效率的技巧优先核对高频候选。出现次数多的词往往语义被复用得最多出错概率也最高。低频词反而可以快速扫过。还有一个判断技巧如果一个候选词在原文里出现时前面跟着的动词不一样比如提交审批和查看审批那它大概率是个对象如果前面跟的是同一个动词的变体那它大概率是个动作。4.4 复核节奏的把控这一条听起来虚实际上很影响最终成果。我试过两种极端一种是分析完立刻一口气复核完另一种是分析完放一放隔天再复核。第一种的问题是会疲劳复核到后半段注意力下降判断质量明显下滑。第二种的问题是有延迟成本隔天回来要重新进入上下文。我现在的做法是分段复核每分析完一段先做第一轮粗筛快速勾掉明显不行的然后切到下一段。等三四段都做完粗筛再回头统一做归并和类型修正。这样既避免了长时间连续判断的疲劳又保证了归并时有足够的全局视野。5. 我在实际项目里踩过的几个坑5.1 把描述性文字原样倒进去候选全是水词最早一次踩坑是把一份产品经理写的功能描述原封不动贴进去。那份文档写得很产品满篇是用户可以方便快捷地完成操作系统会智能地推荐相关内容。分析出来的候选里用户系统内容排在前三智能方便相关也被当成候选冒了出来。问题出在形容词和副词上。这类词在文本里高频出现对建模毫无价值但工具不知道照单全收。规避办法就是我前面说的预处理——分析前花十分钟把描述性、评价性的句子删掉或者改写成陈述句。用户可以方便快捷地完成下单改写成用户提交订单候选立刻就干净了。这件事没有技术含量纯粹是愿不愿意花这十分钟的问题。5.2 全盘接受候选模型变成垃圾场第二个坑是偷懒想着反正工具都识别出来了全勾上生成后面再删。结果生成出来一张四十多个类的图关系一条没有命名五花八门删也不知道从哪删起最后整张图废弃重画比手工建还费时间。这个坑的教训很明确自动生成的元素必须经过人工确认才能进模型。宁可只留十个确认过的也不要留四十个待定的。图这个东西元素一多就失去沟通价值而沟通价值恰恰是画图的主要目的。我后来的做法是给候选设一个默认拒绝的态度——凡是我不确定要不要的先不勾。等整个模块的图基本成型了再回头看看缺不缺东西。这个顺序反过来了但效果好很多因为有了上下文之后判断更准。5.3 忽略词表配得太狠把有效信息挡在门外有一段时间我为了追求候选列表的干净把忽略词表塞得特别满结果发现某些本该出现的实体压根没被识别出来。排查了半天才想起来那个词在前一轮被我一并划进了忽略清单。这件事提醒我忽略词表和候选清单一样需要复核。我的补救办法是定期清空重建一次——把忽略词表复制一份出来逐条问自己这个词在任何语境下都不可能成为模型元素吗答不上来的就移出去。听起来麻烦但一个季度做一次成本可以接受。5.4 把一次分析的结果当成最终模型最后一个坑也是最隐蔽的分析完、图也生成好了看起来挺完整就直接拿去评审。评审的时候被问这个类和那个类为什么没有关系才意识到文本分析根本没给关系而我自己也没补。这个坑的本质是把元素齐了误当成模型齐了。一张类图的价值八成在关系上只有类没有关系等于一堆散落的词卡。现在的习惯是生成元素之后强制自己走一遍关系补全流程先把所有一对多、多对多的业务规则从原文里找出来逐条连线再检查有没有明显的聚合关系最后给每个类至少挂一个属性哪怕先写个占位。走完这三步图才算能拿去讨论。回头看在文本分析这个功能上花的时间最值回票价的其实不是那个一键生成的按钮而是它逼着我把需求文本逐句读了一遍。以前靠脑子读读完以为懂了其实跳过了一堆含糊的表述现在被候选清单逼着逐词确认那些含糊的地方一个都藏不住。工具本身谈不上多智能但它把一件本该做但一直被跳过的事变得不那么痛苦了这就够了。真要说有什么建议就是别指望一次跑出完美结果。把它当成第一遍粗读的加速器跑完立刻动手改改的过程中对需求的理解才是真正沉淀下来的东西。
