文章目录开头引入核心知识点铺垫知识点1功能树——需求分析的功能清单知识点2功能分解≠结构分解——区分问题域和解决方案知识点3从功能组到功能模块——高内聚、松耦合的核心原理知识点4功能树的获得与评审——确保需求完整准确实战场景串联场景背景第一步获得功能树第二步评审功能树第三步从功能组到功能模块划分第四步验证模块划分结果总结收尾通用应用逻辑可落地的交付物开头引入功能模块划分是架构师的核心技能和基本职责——通过将系统分解为功能模块实现模块内高内聚、模块间松耦合让大型系统变得可管理。正如Hassan Gomaa所说“要成功管理大型软件系统的固有复杂性必须提供一种将系统分解为子系统的方法…分解并仔细定义子系统之间的接口后每个子系统可以独立设计。”(本质上是控制复杂度)本文通过功能树方法和酒店管理系统实战案例帮你掌握从需求到设计的模块划分方法。核心知识点铺垫知识点1功能树——需求分析的功能清单通俗理解功能树像一张功能清单树把系统要做什么功能按照功能类别→功能组→功能项的层次结构组织起来让你一目了然地看到系统的所有功能。核心作用功能树是需求分析的框架工具帮助分析师逐层选择和确定系统必须拥有的功能Function和特性Feature是需求分析阶段的产出物。核心要点的3个要点要点1功能树的本质本质功能树是功能分解结构描述的是问题域系统要解决什么问题属于需求分析层。它回答的是系统要做什么而不是系统怎么做。**为什么需要功能树**因为大型系统的功能往往很多如果不组织成树状结构需求分析会变得混乱。功能树通过层次化的方式让分析师能够系统化地梳理功能避免遗漏。深层原理功能树体现了分而治之的思想——将复杂的系统功能分解为多个层次每个层次关注不同粒度的功能从而降低需求分析的复杂度。要点2功能树 vs 功能模块结构图功能树是功能分解结构描述问题域属于需求分析层是架构师从上游需求分析师获得的。功能模块结构图是结构分解结果描述解决方案属于设计层是架构师自己设计的。**为什么必须区分**因为软件架构设计的难点在于架起从现实世界问题域到计算机世界解决方案的桥梁。需求分析阶段关注问题是什么功能树架构设计阶段关注怎么解决功能模块结构图。如果混淆两者会导致用需求分析的思维做架构设计无法正确划分模块。要点3功能树的结构层次结构功能树按照功能类别→功能组→功能项的层次组织形成树状结构。**为什么是树状结构**因为功能之间存在隶属关系和支撑关系——上层功能是下层的概括下层功能是上层的细化。树状结构能够清晰地表达这种层次关系。实际例子呼叫中心系统的功能树顶层是自动服务、“人工服务”、“其他功能等功能类别每个类别下又有功能组如自动语音服务”功能组下又有功能项如最新公告、“用户自助管理”。功能树示例呼叫中心系统呼叫中心系统 ├── 自动服务 │ ├── 自动语音服务 │ │ ├── 最新公告 │ │ ├── 用户自助管理 │ │ └── 用户留言 │ ├── 自动传真服务 │ │ └── 发送传真服务 │ │ ├── 在线传真 │ │ └── 离线传真 │ └── 接受传真服务 ├── 人工服务 │ ├── 被动服务 │ │ ├── 技术咨询 │ │ ├── 服务与产品购买 │ │ └── 投诉建议 │ └── 主动服务 │ ├── 电话营销 │ └── 满意度调查 └── 其他功能 ├── 系统管理 └── 知识管理知识点2功能分解≠结构分解——区分问题域和解决方案通俗理解功能分解像列购物清单要买什么结构分解像规划购物路线怎么去买。两者完全不同但很多人容易混淆。核心作用理解功能分解和结构分解的区别是正确进行模块划分的前提。功能分解关注做什么问题域结构分解关注怎么做解决方案。核心要点的3个要点要点1本质区别功能分解将系统功能按照业务逻辑进行分解形成功能树。它描述的是问题域——系统要解决什么问题要提供什么功能。结构分解将系统结构按照技术实现进行分解形成功能模块结构图。它描述的是解决方案——系统怎么实现这些功能有哪些模块。为什么必须区分因为软件架构设计是从问题域到解决方案的桥梁。需求分析阶段功能分解关注问题是什么架构设计阶段结构分解关注怎么解决。如果混淆两者会导致用需求分析的思维做架构设计无法正确划分模块。要点2为什么容易混淆表面相似功能树和功能模块结构图都是树状结构都涉及分解容易让人以为是一回事。深层原因很多人没有理解问题域和解决方案的区别认为功能就是模块导致直接用功能树作为模块划分的依据。实际危害如果直接用功能树划分模块会导致模块划分todo待实践体会不合理——模块之间耦合度高模块内聚度低无法实现高内聚、松耦合的目标。问题域 vs 解决方案示意图需求 ↓ 问题领域功能树功能分解 ↓ 软件架构转换桥梁 ↓ 解决方案功能模块结构图结构分解 ↓ 软件系统关键区别功能树问题域描述系统要做什么是功能分解结构功能模块结构图解决方案描述系统怎么做是结构分解结果要点3如何正确理解功能树功能分解描述系统要做什么是需求分析的产出物架构师从上游获得。功能模块结构图结构分解描述系统怎么做是架构设计的产出物架构师自己设计。转换过程从功能树到功能模块结构图需要架构师进行设计转换——分析功能之间的实现关系将业务上紧密相关的功能组映射到功能模块实现高内聚、松耦合。知识点3从功能组到功能模块——高内聚、松耦合的核心原理通俗理解像把相关的工具放在同一个工具箱——业务上紧密相关的功能实现时往往涉及相同的类和数据应该放在同一个模块中。核心作用将功能组映射到功能模块是实现模块内高内聚、模块间松耦合的核心方法。通过分析功能的实现关系将业务上紧密相关的功能组划分到同一个功能模块。核心要点的3个要点要点1核心原理原理业务上紧密相关的一组功能实现时往往涉及相似的类、相似的数据结构。因此将功能组映射到功能模块可以实现模块内的高内聚功能相关、实现相关、模块间的松耦合不同模块的实现相对独立。为什么这样设计因为功能的实现不是由单个类完成的而是由多个相互协作的软件元素一起完成的。如果业务上紧密相关的功能涉及相同的软件元素将它们放在同一个模块中可以让这些元素共享减少重复代码提高内聚度。深层原因软件设计的核心目标是高内聚、松耦合。高内聚意味着模块内的元素紧密相关松耦合意味着模块间的依赖关系简单。通过将功能组映射到功能模块可以实现这个目标。要点2映射关系功能组功能树中业务上紧密相关的功能集合如办理预定、“办理入住”、办理退房都是酒店前台服务相关的功能。功能模块架构设计中实现这些功能的模块如宾客服务模块。映射逻辑分析功能的实现关系如果一组功能涉及相同的类、相似的数据结构就将它们映射到同一个功能模块。为什么这样映射因为这样可以实现代码复用相同的类可以被多个功能共享、降低耦合不同模块的实现相对独立、便于分工一个模块可以分配给一个开发小组。要点3通用模块的分离通用模块一些公共服务如错误报告、日志记录、安全验证同时支持多组功能的实现不属于任何单一功能模块。为什么需要分离因为这些公共服务是多个功能模块都需要的基础设施如果放在某个功能模块中会导致其他模块依赖这个模块增加耦合度。如何分离将这些公共服务独立模块化放入对应的通用模块或通用机制中让所有功能模块都可以使用但不依赖特定的功能模块。功能模块划分示意图酒店管理系统 ├── 功能模块4个 │ ├── 资产管理模块 │ ├── 宾客服务模块 │ ├── 人员考核模块 │ └── 系统维护模块 └── 通用模块1个 └── 角色与权限管理框架从功能组到功能模块的映射功能树问题域 功能模块结构图解决方案 ───────────────── ────────────────────── 宾客服务功能组 → 宾客服务模块 ├── 办理预定 ├── Reservation UI ├── 办理入住 ├── Checkin UI └── 办理退房 ├── Checkout UI ├── ServiceManager ├── PayManager ├── Reservation └── Room知识点4功能树的获得与评审——确保需求完整准确通俗理解功能树像需求清单需要从各种渠道收集然后检查是否完整、是否准确。核心作用获得功能树是模块划分的第一步评审功能树是确保需求完整准确的关键。只有获得准确完整的功能树才能正确划分功能模块。核心要点的3个要点要点1如何获得功能树三种方式获取文档、沟通交流、分析产品。获取文档《软件需求规格说明书SRS》是最可能出现功能树的地方因为SRS会系统化地描述功能其章-节-小节结构往往就体现了功能树。更上游的文档如《愿景文档》《方案建议书》也可能包含功能树。沟通交流与业务人员、需求分析师沟通收集功能信息然后自己组织成功能树。分析产品分析本公司或竞争对手的产品包括文档、市场材料、UI界面提炼功能树。**为什么需要多种方式**因为功能树可能出现在不同的地方单一渠道可能不完整。通过多种方式收集可以确保功能树的完整性。要点2如何识别真正的功能树功能树 vs 页面流转图功能树是功能分解结构描述系统要做什么页面流转图是页面跳转关系描述用户怎么操作。页面流转图不能作为功能树因为它描述的是交互流程不是功能分解。判断标准功能树的上层节点是更高层次的功能组下层节点是子功能上下层节点之间是隶属关系和支撑关系。页面流转图描述的是页面跳转关系不是功能分解关系。**为什么必须区分**因为如果用页面流转图作为功能树会导致模块划分错误——按照页面跳转关系划分模块无法实现高内聚、松耦合。功能树 vs 页面流转图对比❌ 页面流转图不是功能树系统登录 ├── 数据编辑 │ ├── 第一个 │ ├── 前一个 │ ├── 下一个 │ └── 添加/编辑/删除 ├── 数据查询 │ ├── 搜索 │ └── 全部 └── 系统维护 ├── 系统数据转换 └── 修改系统密码说明这是页面跳转关系不是功能分解✅ 功能树真正的功能树设备管理系统 ├── 设备管理功能组 │ ├── 录入设备记录功能项 │ ├── 维护设备记录功能项 │ └── 维护维修记录功能项 ├── 系统管理功能组 │ ├── 组织结构管理功能项 │ └── 设备类别管理功能项 └── 设备统计查询功能组 ├── 维修统计查询功能项 └── 调拨统计查询功能项说明这是功能分解结构描述系统要做什么要点3如何评审功能树两个标准用户导向、全面覆盖。用户导向功能树应该反映用户价值从用户视角组织功能而不是从技术视角。如果功能树从技术视角组织如金额计算、“按键处理”说明没有理解用户需求。全面覆盖功能树应该全面覆盖系统功能不能遗漏重要功能。如果功能树遗漏了关键功能如故障报警、“现金箱控制”说明需求分析不完整。**为什么需要评审**因为功能树是模块划分的基础如果功能树不准确、不完整后续的模块划分就会出错。评审功能树可以及早发现需求问题避免设计阶段的返工。差的功能树示例自动售货机管理系统自动售货机管理系统 ├── 金额计算 │ ├── 金额累加 │ ├── 清除现有金额 │ └── 计算退币金额 └── 按键处理 ├── 按键按下处理 └── 点亮可售货等待问题❌ 从技术视角组织“金额计算”、“按键处理”不是用户视角❌ 遗漏重要功能故障报警、现金箱控制、加载人员功能等❌ 无法指导模块划分哪些功能应该放在哪个模块好的功能树应该✅ 从用户视角组织如售货服务、“设备管理”、“故障处理”✅ 全面覆盖系统功能不遗漏关键功能✅ 能够指导模块划分实战场景串联场景背景项目某酒店开发酒店管理系统需要支持前台办理预定、办理入住、办理退房经理进行人员考核管理员进行系统维护等功能。需求文档提供了用例图显示了不同角色的功能需求前台办理预定、办理入住、收取押金、办理退房经理人员考核相关功能管理员系统维护相关功能问题如何将这些功能需求转换为功能模块划分如何实现高内聚、松耦合第一步获得功能树目标从需求文档中获得功能树明确系统要提供哪些功能。核心操作要点要点1从用例图提取功能分析用例图识别所有功能项前台功能办理预定、办理入住、收取押金、办理退房、经理功能人员考核、管理员功能系统维护。**为什么从用例图提取**因为用例图描述了系统要提供的功能是功能树的重要来源。要点2组织成功能树结构按照功能类别→功能组→功能项的层次组织功能。对于酒店管理系统可以组织为宾客服务功能类别预定服务功能组办理预定功能项入住服务功能组办理入住、收取押金功能项退房服务功能组办理退房功能项人员考核功能类别人员考核相关功能功能组系统维护功能类别系统维护相关功能功能组资产管理功能类别资产管理相关功能功能组要点3补充通用功能识别所有角色都需要的基础功能登录、退出、修改密码。这些功能不属于任何单一功能类别应该作为通用功能处理。为什么这么设计从用例图提取因为用例图是需求分析的标准产出物描述了系统要提供的功能是功能树的重要来源。组织成树状结构因为功能之间存在层次关系树状结构能够清晰地表达这种关系便于后续的模块划分。补充通用功能因为有些功能是多个角色都需要的基础功能如果不单独识别会导致后续模块划分时不知道如何处理。第二步评审功能树目标确保功能树用户导向、全面覆盖为模块划分提供准确的基础。核心操作要点要点1检查用户导向检查功能树是否从用户视角组织功能而不是从技术视角。好的功能树从业务视角组织如宾客服务、“人员考核”用户能够理解。差的功能树从技术视角组织如金额计算、“按键处理”用户无法理解。**为什么必须用户导向**因为功能树是需求分析的产出物应该反映用户价值。如果从技术视角组织说明没有理解用户需求后续的模块划分也会出错。要点2检查全面覆盖检查功能树是否覆盖了所有重要功能没有遗漏。对于酒店管理系统需要检查是否遗漏了故障报警、现金箱控制等关键功能是否遗漏了加载人员的功能是否遗漏了资产管理相关功能**为什么必须全面覆盖**因为功能树是模块划分的基础如果遗漏了重要功能后续的模块划分就会不完整导致系统功能缺失。要点3区分功能树和页面流转图确保获得的是功能树功能分解结构而不是页面流转图页面跳转关系。功能树描述系统要做什么按照功能类别组织。页面流转图描述用户怎么操作按照页面跳转关系组织。**为什么必须区分**因为页面流转图不能作为功能树用它划分模块会导致模块划分错误。为什么这么设计检查用户导向因为功能树应该反映用户价值从用户视角组织功能。如果从技术视角组织说明需求分析有问题。检查全面覆盖因为功能树是模块划分的基础如果遗漏了重要功能后续的模块划分就会不完整。区分功能树和页面流转图因为两者描述的内容不同混淆会导致模块划分错误。第三步从功能组到功能模块划分目标将功能树中的功能组映射到功能模块实现高内聚、松耦合。核心操作要点要点1分析功能的实现关系分析每个功能的实现涉及哪些类、哪些数据结构。对于酒店管理系统“办理预定”、“办理入住”、办理退房这三个功能都涉及Room房间和Reservation预定等类。PayManager支付管理和PrepayManager预付费管理职责相近、实现相似都调用Finance Proxy。CheckinManager入住管理和CheckoutManager退房管理也以类似方式处理房间Room状态。**为什么分析实现关系**因为功能的实现不是由单个类完成的而是由多个相互协作的软件元素一起完成的。如果业务上紧密相关的功能涉及相同的软件元素应该将它们放在同一个模块中。要点2将功能组映射到功能模块将业务上紧密相关的功能组映射到同一个功能模块。对于酒店管理系统“办理预定”、“办理入住”、办理退房这些功能都涉及房间管理和预定管理可以共享ServiceManager、PayManager、Reservation等程序实现因此映射到宾客服务功能模块。人员考核相关功能映射到人员考核功能模块。系统维护相关功能映射到系统维护功能模块。资产管理相关功能映射到资产管理功能模块。**为什么这样映射**因为这样可以实现模块内的高内聚功能相关、实现相关、模块间的松耦合不同模块的实现相对独立还便于将这组功能分配给一个程序小组负责开发。要点3分离通用模块识别所有功能模块都需要的基础服务将它们独立为通用模块。对于酒店管理系统“登录”、“退出”、修改密码这些功能是所有角色都需要的基础功能应该独立为角色与权限管理通用模块。错误报告、日志记录、安全验证等公共服务也应该独立为通用模块或通用机制。**为什么需要分离**因为这些公共服务是多个功能模块都需要的基础设施如果放在某个功能模块中会导致其他模块依赖这个模块增加耦合度。独立为通用模块让所有功能模块都可以使用但不依赖特定的功能模块。为什么这么设计分析实现关系因为功能的实现涉及多个软件元素只有分析实现关系才能知道哪些功能应该放在同一个模块中。将功能组映射到功能模块因为业务上紧密相关的功能实现时往往涉及相同的软件元素将它们放在同一个模块中可以实现高内聚、松耦合。分离通用模块因为通用服务是多个功能模块都需要的基础设施独立为通用模块可以降低耦合度提高复用性。第四步验证模块划分结果目标验证模块划分是否实现了高内聚、松耦合的目标。核心操作要点要点1检查模块内聚度检查每个功能模块内的功能是否业务相关、实现相关。对于宾客服务模块检查办理预定、“办理入住”、办理退房这些功能是否涉及相同的类如Room、Reservation是否可以共享实现如ServiceManager、PayManager。**为什么检查内聚度**因为高内聚意味着模块内的元素紧密相关如果模块内的功能不相关说明模块划分不合理。要点2检查模块耦合度检查不同功能模块之间的依赖关系是否简单。对于酒店管理系统检查宾客服务模块是否依赖人员考核模块如果依赖说明耦合度高需要调整。**为什么检查耦合度**因为松耦合意味着模块间的依赖关系简单如果模块之间相互依赖说明模块划分不合理。要点3检查通用模块检查通用模块是否被所有功能模块使用但不依赖特定的功能模块。对于角色与权限管理通用模块检查是否所有功能模块都可以使用但不依赖特定的功能模块。**为什么检查通用模块**因为通用模块应该被所有功能模块使用但不应该依赖特定的功能模块否则会增加耦合度。为什么这么设计检查内聚度因为高内聚是模块划分的目标如果模块内的功能不相关说明模块划分不合理。检查耦合度因为松耦合是模块划分的目标如果模块之间相互依赖说明模块划分不合理。检查通用模块因为通用模块应该降低耦合度如果通用模块依赖特定的功能模块说明设计不合理。总结收尾通用应用逻辑功能模块划分的通用逻辑可以总结为“获得功能树→评审功能树→分析实现关系→映射功能模块→分离通用模块→验证划分结果”。通俗比喻就像整理工具箱——先列出所有工具获得功能树检查工具是否齐全评审功能树分析哪些工具经常一起用分析实现关系把相关的工具放在同一个工具箱映射功能模块把通用工具单独放分离通用模块最后检查工具箱是否整理好了验证划分结果。可落地的交付物功能模块划分检查清单功能树获得从需求文档SRS、愿景文档、方案建议书中提取功能树与业务人员、需求分析师沟通补充功能树分析产品本公司或竞争对手提炼功能树确保功能树是功能分解结构不是页面流转图功能树评审检查功能树是否用户导向从用户视角组织功能检查功能树是否全面覆盖没有遗漏重要功能区分功能树和页面流转图模块划分分析功能的实现关系涉及哪些类、哪些数据结构将业务上紧密相关的功能组映射到功能模块分离通用模块所有功能模块都需要的基础服务验证结果检查模块内聚度模块内的功能是否业务相关、实现相关检查模块耦合度模块间的依赖关系是否简单检查通用模块是否被所有功能模块使用但不依赖特定的功能模块最简操作模板功能模块划分三步走 1. 获得功能树从需求文档、沟通交流、分析产品中获得功能树 2. 评审功能树检查用户导向、全面覆盖区分功能树和页面流转图 3. 划分功能模块分析实现关系→映射功能模块→分离通用模块→验证划分结果记住模块划分是架构师的核心技能和基本职责。通过功能树方法从需求分析的功能分解转换为架构设计的结构分解实现高内聚、松耦合的目标让大型系统变得可管理。