简介这份UML试题合集面向正在学习统一建模语言、准备课程考试或面试复习的计算机专业学生与软件开发者围绕用例图、顺序图、协作图等核心图形组织知识点与练习帮助读者理清静态建模与动态建模的区别与联系。压缩包内为1个doc文档约62KB内容以问答与选择题形式呈现涵盖交互图两种类型的差别与优缺点、高内聚度的含义、对象间可见性、领域模型的概念类查找方法、统一过程四阶段及核心工作流、增量开发与用况描述方式等高频考点。文档还配有标准建模语言五类图的归纳和若干典型选择题便于自测与对照答案查漏补缺。目前已有11274人学习下载适合需要系统梳理UML知识框架、快速过一遍重点题型的读者使用。1. 从一张“外卖小票”说起UML 用例图和顺序图到底是什么你有没有拿过外卖小票上面印着“下单—支付—商家接单—骑手取餐—送达”这一串动作。如果要把一个软件系统也印成这么一张小票告诉别人“这个系统到底能干什么、每一步谁跟谁说话”那画出来的东西基本就是 UML 里的用例图和顺序图。UML 全称统一建模语言通俗地说它是一套“画软件蓝图”的通用图形符号。它不写代码而是用图把系统长什么样、怎么动讲清楚。用例图回答“系统对外提供哪些功能、谁来用”顺序图回答“一次具体操作里对象之间按什么时间顺序传消息”。搞懂这两个你就拿到了读懂大多数软件设计文档的钥匙也是 uml 用例图 顺序图 协作图 这类考题反复考察的核心。2. 用例图先搞清楚“谁要用系统做什么”2.1 用例图到底画的是什么用例图是 UML 里最像“功能清单”的一张图。它由三样东西组成参与者画成小人、用例画成椭圆、以及它们之间的连线。参与者不一定是人也可以是另一个系统用例不是函数而是一段“对用户有价值的完整业务过程”。打个比方去医院看病。挂号窗口、医生、药房是参与者挂号、问诊、取药是用例。你不会在挂号单上写“数据库查询语句怎么写”用例图也一样——它只定义系统必须做什么不描述系统内部怎么工作。原文里那句“用况不描述系统内部如何工作而是定义系统的责任”说的就是这个边界。这里有个容易翻车的点很多人把用例画成一个个按钮。按钮是界面细节用例是业务目标。“登录”可以是用例“点击蓝色登录按钮”不是。判断标准很简单这个动作完成后参与者有没有获得一个可感知的结果。2.2 为什么需要用例图需求阶段的“后悔药”软件项目最贵的错误不是代码写错而是做了一堆用户根本不要的功能。用例图存在的意义就是在写第一行代码之前把“范围”钉死。原文提到统一过程UP的初始阶段要“编制简要的愿景文档、确定范围、粗略评估成本”。用例图就是确定范围最直观的工具图上一共几个椭圆项目大概多大一目了然。它还天然适合跟非技术角色沟通——产品经理、业务方都能看懂小人连椭圆不需要懂类继承。用例之间还有两种常考关系包含include和扩展extend。包含是“每次都要做”比如“创建订单”和“更新订单”都要“检查用户账号”检查账号就是被包含的公共步骤扩展是“特定条件下才做”比如“下单”在库存不足时才触发“通知补货”。这两个关系搞混是选择题的高频失分点。2.3 用例描述有三种写法别一上来就写满原文说用况一般有 Brief、Casual、Fully Dressed 三种描述方式。通俗理解Brief 就是一句话“用户可以下单”Casual 是几段话的随意描述Fully Dressed 是正式模板包含前置条件、主流程、异常流程、后置条件。不是每个用例都值得写满模板。核心业务、金额相关、跨多个部门的用例才用 Fully Dressed辅助功能用 Brief 就够了。血泪经验是给每个用例都套完整模板文档会膨胀到没人看最后变成“写了但没人读”的摆设。提示用例图只画参与者和用例的关系不要把顺序图里的消息箭头塞进来两张图各管各的。3. 顺序图与协作图同一场戏的两种拍法3.1 顺序图按时间轴排队的“剧本”顺序图也叫序列图的布局很特别横向是参与交互的对象纵向是时间从上往下走。每个对象下面有一条虚线叫生命线对象活跃时上面叠一个窄条叫激活期对象之间横向的箭头就是消息。用生活类比一场电话客服的通话记录。客户、客服、工单系统三个对象并排时间往下走——“客户发起咨询”箭头指向客服“客服查询工单”箭头指向系统“系统返回结果”箭头指回来。谁先谁后一眼看清。原文点出顺序图的核心特征强调交互的时间顺序能清晰表示消息之间的顺序和时间关系代价是需要较多的水平方向空间。对象一多图就横向撑爆这是它天生的短板。顺序图里还有两个常考概念同步消息实心箭头发送方等待返回和异步消息开放箭头发完就走。画错箭头类型等于把“打电话等回复”画成了“发短信不等回复”语义完全变了。3.2 协作图按“谁挨着谁”摆位的“关系网”协作图现在 UML 2 里更多叫通信图不按时间轴排而是按空间组织对象像社交网络里的节点一样摆开连线表示它们之间的关联消息挂在连线上用编号表示先后顺序。原文说得很准协作图强调交互的语境和参与交互的对象的整体组织按照空间组织布图。它除了展示对象之间的关联还显示对象之间的消息传递。在增加对象时比较容易分支也比较少但消息一多编号就乱成一团难以表示消息之间的顺序。打个比方顺序图是“通话记录”协作图是“组织架构图上贴便签”。前者看流程后者看结构。原文提到在建模工具里协作图常常可以在顺序图基础上按键自动生成说明两者描述的是同一份交互只是视角不同。3.3 两者怎么选一张对比表说清对比维度顺序图协作图布局依据时间顺序纵向推进空间组织对象关联强项消息先后、时间关系清晰对象整体组织、语境清楚弱项对象多时横向占空间大消息多时顺序难表达增删对象相对麻烦比较容易分支表达直观分支较少时更简洁典型用途讲清一次操作的流程讲清对象之间的结构关系选择逻辑不玄学要跟人解释“这一步之后才做那一步”用顺序图要解释“这几个模块是怎么咬合在一起的”用协作图。两者不是替代关系而是同一交互的两张面孔。4. 常见误区这五个概念最容易张冠李戴4.1 误区一把顺序图和协作图当成两种不同的交互易混点以为它们描述的是不同的东西。为什么混名字不同、画法不同看起来像两类图。怎么区分原文明确说“与顺序图一样协作图也展示对象之间的交互关系”两者都是交互图描述的是同一份交互只是顺序图重时间、协作图重空间。考题里问“交互图有哪两种”答案就是这两个。4.2 误区二把用例图和顺序图都当成“动态视图”易混点以为画了箭头就是动态。为什么混用例图里也有连线顺序图里也有对象。怎么区分原文的填空题给得很清楚——类图给出系统的静态设计视图用例图对系统的行为进行组织和建模顺序图和协作图才是描述系统动态视图的交互图。用例图管“有什么功能”顺序图管“功能怎么一步步执行”。4.3 误区三把高内聚理解成“一个类什么都干”易混点以为职责越多越能干。为什么混“内聚”字面像“聚在一起”。怎么区分原文说高内聚度是对一个类中各个职责之间相关程度和集中程度的度量包含两层意思——不要给一个类分派太多职责不相关的职责不要分派给同一个类。一个类把订单、库存、支付全包了那不叫高内聚叫“上帝类”是低内聚的典型。4.4 误区四把领域模型当成软件类的模型易混点看到“类”就以为是代码里的 class。为什么混都叫“类”。怎么区分原文的填空题答案是——领域模型是一组表示真实世界的概念类不是软件部件的模型。领域模型里的“订单”“客户”是业务概念还没有方法、没有数据库字段它是启发设计软件对象的素材不是设计本身。4.5 误区五把初始阶段和细化阶段的活儿干串了易混点以为需求在初始阶段就定完。为什么混两个阶段都在项目早期。怎么区分原文的题很直接——定义大多数的需求和范围是在细化阶段完成的不在初始阶段。初始阶段只做简要愿景、业务案例、确定范围、粗略评估成本细化阶段才细化愿景、迭代实现核心架构、解决高风险问题、定义大多数需求和范围。5. 什么时候用、什么时候别用一个虚拟项目的取舍假设某高校实验室要做一个“设备预约系统”需求方说不清要什么只说要“能约、能提醒、能统计”。这时候如果直接开画顺序图就是典型的用错工具——顺序图假设你已经知道有哪些对象、按什么顺序交互而此刻连功能边界都没定。正确的顺序是先用例图圈范围。参与者有学生、管理员、提醒服务用例有“预约设备”“取消预约”“发送提醒”“生成统计”。图一画完需求方立刻发现“统计”到底统计什么没想清楚这就是用例图提前暴露问题的价值。范围定了再挑最核心的“预约设备”画顺序图学生→预约界面→预约服务→设备库存时间轴一拉谁先校验、谁后扣减清清楚楚。至于对象之间的整体组织关系用协作图补一张方便新加入的开发者快速看懂模块咬合。什么时候别用三种情况。第一需求还在“要不要做”的层面画交互图是浪费先写一句话愿景。第二纯数据结构或算法模块没有对象交互顺序图画出来只有两个对象来回传不如直接写注释。第三团队里没人维护图画完就锁进文件夹——图的价值在于被读、被改静态的图不如没有因为它会误导后来者以为系统还是那样。我自己的习惯是每接一个说不清需求的项目先强制走一遍“用例图圈范围→挑核心用例画顺序图→协作图补结构”这三步哪怕每步只花半小时。翻车最惨的一次是跳过用例图直接画顺序图画到第七个对象时发现有两个功能根本不该存在整张图推倒重来。从那以后我每次动手画图前都强制先问一句“这张图回答的是范围问题还是流程问题”答不上来就不画。这份 UML 试题大集合把用例图、顺序图、协作图、领域模型、统一过程这些高频考点串在了一起题目带答案适合拿来对着自查概念边界。希望帮到你。本文还有配套的精品资源点击获取
