系统架构设计-案例分析总结

2024年下半年系统架构设计师案例

题：效用树+可用性中ping/echo策略和心跳策略比较

第1题

阅读以下关于面向质量属性的软件架构设计的叙述，回答问题1和问题2。
【说明】
某公司拟开发一个基于大语言模型的智能系统，该系统将通过多个大语言模型来协作处理用户提交的任务请求，任务求解过程的状态数据将被记录在任务板中，各个大语言模型根据任务板上任务的实时求解状态，来确定它们当前是否需要被调用以进一步处理该任务，并在处理完成之后将任务的最新状态更新到任务板上。
基于该系统的开发任务，公司召开项目讨论会。会上，项目组介绍了系统需求，主要包括：
(a)系统可支持用户在任务板上查看任务的状态和结果，并允许用户多次调用大型语言模型以进一步优化处理结果。
(b)系统可支持任务数据的导入导出，数据导入导出在1分钟内完成
(©)在数据服务器发生故障时，系统应能够立刻切换到备份服务器，并保证数据同步，以确保系统的不间断的服务。
(d)在系统正常负荷情况下，用户在任务板上查询任务状态和结果的响应时间应在2秒内。
(e)系统应确保用户数据和操作记录的安全，防止未经授权的访问。
(f)系统需要支持多语言接口，并提供查询词自动补全和搜索关联功能。
(g)系统应支持扩容，以容纳更多的用户和任务。扩容需求的实现应在两名运维人员工作的情况下在5天内完成。
(h)系统部署在云服务器上。当云服务器出现故障时，系统应在1分钟内检测出故障，并在1小时之内恢复。
(i)系统支持根据用户任务类型调用相应的大语言模型对任务进行处理。
(j)用户可以在任务板上搜索历史任务和结果，搜索结果应在3秒内返回。
【问题1】(14分)
为了辅助架构师张工完成系统架构设计，首先需要对上述需求进行分析。请分析需求(a)-(g)，补充完善下表中(1)~(7)的空白处。

【问题2】(11分)
针对需求可用性需求(h)，张工提出可采用ping/echo策略完成故障检测，但李工认为从系统资源利用率的角度出发，采用心跳策略完成故障检测更优。
(1)请分别说明如何采用ping/echo策略和心跳策略来完成可用性的故障检测;
(2)请解释李工认为心跳策略更优的原因。

【问题1】
(1)性能
(2)性能
(3)安全性
(4)功能性
(5)可修改性
(6)功能性
(7)性能

【问题2】
(1)ping/echo故障检测：ping/echo通过发送ping请求报文给目标主机，并等待其回应来检测网络连通性。如果收到回应，则表明网络通路正常；如果未收到回应或超时，则可能表示网络存在问题或目标主机不可达。
心跳故障检测：心跳机制通过节点间定期发送心跳信号来检测各节点的状态。如果连续一段时间内未收到某个节点的心跳信号，则判定该节点出现故障或失联，并触发相应的故障恢复或切换操作。这种方式常用于分布式系统中，以确保系统的高可靠性和稳定性。
(2)资源消耗较少：心跳模式通常是由被监控组件主动、周期性地向监控组件发送简短的消息，以表明其正在正常运行。这种方式相比ping echo更为高效，因为ping echo需要监控组件定时向被监控组件发送请求，并等待回应，这增加了网络流量和处理器资源的消耗。另外心跳模式使用的是长连接，而pig使用的是短连接。
降低网络负载：由于心跳消息通常较短且发送频率相对较低（根据系统需求设定），因此它们对网络带宽的占用较少。相比之下，ping echoi可能需要更频繁地发送和接收消息，从而增加了网络的负载。
故障检测效率更快：心跳模式能够更快速地检测到故障或失联的节点。因为心跳消息是周期性发送的，所以一旦某个节点出现故障或无法发送心跳消息，监控组件就能立即察觉并采取相应的措施。而pig/echo虽然也能用于故障检测，但其响应时间和检测效率可能受到网络延迟和消息丢失等因素的影响。

(1) 故障检测策略
ping/echo 策略：
方法：监控节点每 5 秒向云服务器发送 ping 请求（ICMP Echo Request），连续 3 次无回应（约 15 秒）判定故障，触发切换或通知。
特点：简单易实现，但频繁 ping 占用网络和服务器资源，易受网络抖动误判，仅验证网络可达性。
心跳策略：
方法：云服务器每 5 秒主动向监控节点发送心跳包（含服务状态，如 LLM API），连续 3 次未收到（约 15 秒）判定故障，触发切换或通知。
特点：服务器主动发送，资源占用低，可携带服务状态，抗网络抖动，适合复杂系统。
(2) 心跳策略更优的原因
低资源占用：心跳由服务器单向发送，监控节点被动接收，请求量随节点数线性增长（N 台服务器 N 次心跳）；ping/echo 需双向请求，流量高（多节点互 ping 呈平方增长）。
高准确性：心跳包可包含服务状态（如 LLM API 是否正常），检测更精准；ping 仅验证网络，无法确认服务状态。
低误判率：心跳使用 TCP/UDP，抗网络抖动；ping 易受 ICMP 阻挡或延迟误判。
扩展性：心跳适合大规模系统（如 1000 台服务器）；ping 请求随节点增加导致网络拥塞。
电商背景：心跳支持高并发（5000 用户）、高可用性（99.9%），确保任务板无中断，满足 15 秒检测要求。

【架构-31】各架构风格对比

2022年下半年系统架构设计师案例

题：效用树+面向对象与解释器风格比较

第1题

试题一是必答题
阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。
【说明】
某电子商务公司拟升级其会员与促销管理系统，向用户提供个性化服务，提高用户的粘性。在项目立项之初，公司领导层一致认为本次升级的主要目标是提升会员管理方式的灵活性，由于当前用户规模不大，业务也相对简单，系统性能方面不做过多考虑。新系统除了保持现有的四级固定会员制度外，还需要根据用户的消费金额、偏好、重复性等相关特征动态调整商品的折扣力度，并支持在特定的活动周期内主动筛选与活动主题高度相关的用户集合，提供个性化的打折促销活动。
//
在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：
//
(a)管理员能够在页面上灵活设置折扣力度规测和促销活动逻辑，设置后即可生效；
(b)系统应该具备完整的安全防护措施，支持对恶意攻击行为进行检测与报警；
( c) 在正常负载情况下，系统应在0.3秒内对用户的界面操作请求进行响应：
(d)用户名是系统唯一标识，要求以字母开头，由数字和字母组合而成，长度不少于6个字符：
(e)在正常负载情况下，用户支付商品费用后在3秒内确认订单支付信息；
(f)系统主站点电力中断后，应在5秒内将请求重定向到备用站点：
(g)系统支持横向存储扩展，要求在2人天内完成所有的扩展与测试工作：
(h)系统宕机后，需要在10秒内感知错误，并自动启动热备份系统：
(i)系统需要内置接口函数，支持开发团队进行功能调试与系统诊断：
(j)系统需要为所有的用户操作行为进行详细记录，便于后期查阅与审计：
(k)支持对系统的外观进行调整和配置，调整工作需要在4人天内完成。
//
在对系统需求、质量属性描述和架构特性进行分析的基础上，系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对系统架构进行评估。
【问题1】(12分)
在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并选择题干描述的(a)-(k)填入(3)~(6)空白处，完成该系统的效用树。
//
【问题2】(13分)
针对该系统的功能，李工建议采用面向对象的架构风格，将折扣力度计算和用户筛选分别封装为独立对象，通过对象调用实现对应的功能；王工则建议采用解释器(interpreters)架构风格，将折扣力度计算和用户筛选条件封装为独立的规则，通过解释规测实现对应的功能。请针对系统的主要功能，从折扣规测的可修改性、个性化折扣定义灵活性和系统性能三个方面对这两种架构风格进行比较与分析，并指出该系统更适合采用哪种架构风格。

我的答案：
问题1：
（1）安全性
（2）可修改性
（3)e
（4）j
（5）h
（6）k

问题2：
折扣规则的可修改性方面：面向对象的架构风格，当折扣规则修改时，需要修改对应对象的方法，然后重新调用；而解释器风格，修改对应的规则即可，通过解释规则实现功能；解释器风格可修改性更强。
个性化折扣定义灵活性方面：面向对象的架构风格，需要将折扣定义须在类中个性化折扣的方法，然后重新调用；
而解释器风格，可预先自定义定多种折扣，更加方便灵活；
系统性能方面：面向对象的架构风格，经过创建类对象，然后调用方法，性能开销大；而解释器风格，利用解释引擎解释规则实现对应功能，针对特定的规则来实现，性能开销小；
综上，该系统更适用解释器风格

参考解析1：
【问题1】本题主要考查考生对软件架构评估、软件质量属性以及架构评估中相关概念的理解与掌握。考生应该在熟记基础概念的基础上结合实际问题灵活掌握并应用这些概念。在解答本题时，首先需要对题干中的所有软件需求描述进行分析与梳理，区分并找出其中的需求分析、软件质量属性描述，或者可能的风险、权衡点或敏感点描述。

具体列举如下：
(a)管理员能够在页面上灵活设置折扣力度规侧和促销活动逻辑，设置后即可生效，对应易用性属性。
(b)系统应该具备完整的安全防护措施，支持对恶意攻击行为进行检测与报警，对应安全性属性。
©在正常负载情况下，系统应在0.3秒内对用户的界面操作请求进行响应；对应性能属性。
(d)用户名是系统唯一标识，要求以字母开头，由数字和字母组合而成，长度不少于6个字符，对应系统的设计约束。
(e)在正常负载情况下，用户支付商品费用后在3秒内确认订单支付信息，对应性能属性。
(f)系统主站点电力中断后，应在5秒内将请求重定向到备用站点，对应可用性属性
(g)系统支持横向存储扩展，要求在2人天内完成所有的扩展与测试工作，对应可修改性属性。
(h)系统宕机后，雲要在10秒内感知错误，并自动启动热备份系统，对应可用性属性
(i)系统需要内置接口函数，支持开发团队进行功能调试与系统诊断，对应可测试性属性。
(j)系统需要为所有的用户操作行为进行详细记录，便于后期查阅与审计，对应安全性属性。
(k)支持对系统的外观进行调整和配置，调整工作需要在4人天内完成，对应可修改性属性。

【问题2】在解答本题时，需要从可修改性、灵活性和系统性能三个方面进行综合考虑。
从可修改性来看，解释器风格折扣规则是独立的语法规测，由解释器可对变化的规则进行解析，修改更容易。而面向对象相对固定，有变化需要修改具体的类。
从灵活性来看，解释器可以根据用户灵活解释执行规则，优于面向对象。
从系统性能来看，面向对象优于解释器。综合三个方面来看，解释器的优势更大，所以该系统更适合采用解释器风格。

解释器可修改性:
面向对象风格通过编写新的规则实现代码，并通过应用重启或热加载添加规则，可修改性稍差;解释器风格通过编写新的规则文件，并通过导入资源文件或外部配置添加规则，可修改性较好。
灵活性:
面向对象风格通过策略模式定义规则对象，规则以程序逻辑实现，灵活性较差，解释器风格可灵活定义规则计算表达式，灵活性更好。
性能:
面向对象风格以编译后代码运算规则，性能好;而虚拟机风格需要加载规则，解析规则，规则运算,再得出结果，性能较差。
从项目关注点来看，系统性能不做过多考虑，则王工建议的解释器风格较为合适;
||
v

折扣规则的可修改性：
面向对象风格：折扣规则和用户筛选逻辑封装在对象中（如 DiscountCalculator 类）。修改规则需更改代码、重新编译、测试、部署，通常需要开发人员介入，修改成本高，可修改性较低。
解释器风格：规则定义为脚本文件（如 JSON 或 DSL），管理员通过界面上传或修改规则，系统动态解析并立即生效，无需重启，修改成本低，可修改性高。
优势：解释器更优，满足管理员灵活设置规则的需求（(a)）。
个性化折扣定义灵活性：
面向对象风格：通过对象方法（如策略模式或继承）实现规则，新增个性化规则（如基于生日折扣）需开发新代码，灵活性受限，难以支持管理员定义复杂逻辑。
解释器风格：支持复杂规则脚本，管理员可定义动态条件（如“消费 > 1000 且偏好电子产品，折扣 20%”），灵活性高，满足个性化促销需求。
优势：解释器更优，支持任意规则组合。
系统性能：
面向对象风格：通过编译后的代码直接执行规则，执行效率高，响应时间短（如微秒级），适合高负载场景。
解释器风格：需加载和解析规则脚本，执行开销较大（如毫秒级），性能稍低，但可通过缓存解析结果优化，满足 0.3 秒响应和 3 秒支付确认的要求。
优势：面向对象性能更优，但解释器性能足够。
结论：

题目强调灵活性为主要目标（管理员动态设置规则，个性化促销），性能要求不高（小规模用户，0.3 秒和 3 秒宽松）。解释器风格在可修改性和灵活性上显著优于面向对象，支持动态规则调整，满足核心需求。尽管性能稍低，但足以应对当前规模。因此，王工建议的解释器架构风格更适合

第2题

阅读以下关于软件系统设计与建模的叙述，在答题纸上回答问题1至问题3。
【说明】
煤炭生产是国民经济发展的主要领域之一，其煤矿的安全非常重要。某能源企业拟开发一套煤矿建设项目安全预警系统，以保护煤矿建设项目从业人员生命安全。本系统的主要功能包括如下(a)～(h)所述。
(a)项目信息维护
(b)影响因素录入
©关联事故录入
(d)安全评价得分
(e)项目指标预警分析
(f)项目指标填报
(g)项目指标审核
(h)项目指标确认


【问题3】(7分)
在结构化分析和设计过程中，数据流图和数据字典是常用的技术手段，请用200字以内的文字简要说明它们在软件需求分析和设计阶段的作用。

我的回答：
问题1：
（1）f
（2）g
（3）h
（4）d
（5）b
（6）e
数据平衡原则：
1）父图和子图间的数据平衡：父图中出现的数据流，应该在子流中也要出现；
2）子图中的数据平衡：加工有输入和输出，加工描述了输入数据经过变化得到了输出数据；

问题2：
（1）项目管理员
（2）项目经理
（3）项目指标
（4）安全评价
（5）影响因素
（6）项目指标预警

问题3：
数据字典：数据字典描述并标识了数据流图中各个元素的作用，功能以及名称。在需求分析阶段，用于完善数据流图以及相关图的建立，在设计阶段，对软件设计的各个元素信息进行参考；
数据流图：数据流图由外部实体、加工、存储、数据流组成，描述了外部实体与数据流的交互，反映了软件系统的功能性需求，在设计阶段，用于指导软件系统设计；

【问题1】
(1) f
(2) g
(3) h
(4) d
(5) b
(6) e
分层细化的数据平衡原则：
1、子图与父图之间的平衡：
（1）父图与子图之间平衡是指任何一张DFD子图边界上的输入输出数据流必须与其父图对应加工的输入/输出数据流保持一致。
(2）如果父图中某个加工的一条数据流对应于子图中的几条数据流，而子图中组成这些数据流的数据项全体正好等于父图中的这条数据流，那么它们仍然是平衡的。
2、子图内部：加工的输入和输出需要平衡。每个加工必须有输入数据流和输出数据流，反映此加工的数据来源和加工变换结果。

【问题2】
（1）项目管理员
(2）项目经理
（3）项目指标数据
（4）～（6）指标参数、项目信息、事故及影响因素参数

【问题3】
（1）在软件需求分析阶段：
数据流图主要用于建立软件的功能模型，以图形化方式呈现业务数据的流动和处理过程**。
数据字典是关于数据的信息集合，用于对数据流图中每个组成部分加以定义和说明。
(2）在软件设计阶段：
数据流图为模块划分与模块之间接口设计提供依据，数据流图主要用于经过一系列设计转换后，产生由模块图表示的软件设计模型；详细设计阶段数据流图可进行模块内部的数据流设计。
数据字典用于描述系统中各类数据，为数据库概要设计、逻辑设计提供支持。

2021年下半年系统架构设计师案例

题：效用树+管道过滤器风格，隐式调用风格与解释器风格比较

第1题

阅读以下关于软件架构设计与评估的叙述，回答问题1和问题2。
【说明】
某公司拟开发一套机器学习应用开发平台，支持用户使用浏览器在线进行基于机器学习的智能应用开发活动。
该平台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程，采用自助方式进行智能应用设计、实现与部署，并可以开发新算法组件加入平台中。在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：
(a)平台用户分为算法工程师、软件工程师和管理员等三种角色，不同角色的功能界面有所不同；
(b)平台应该具备数据库保护措施，能够预防核心数据库被非授权用户访问；
(©)平台支持分布式部署，当主站点断电后，应在20秒内将请求重定向到备用站点；
(d)平台支持初学者和高级用户两种界面操作模式，用户可以根据自己的情况灵活选择合适的模式；
(e)平台主站点宕机后，需要在15秒内发现错误并启用备用系统；
(f)在正常负载情况下，机器学习流程从提交到开始执行，时间间隔不大于5秒：
(g)平台支持硬件扩容与升级，能够在3人天内完成所有部署与测试工作；
(h)平台需要对用户的所有操作过程进行详细记录，便于审计工作：
(i)平台部署后，针对界面风格的修改需要在3人天内完成；
(j)在正常负载情况下，平台应在0.5秒内对用户的界面操作请求进行响应；
(k)平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致：
(l)平台提供机器学习算法的远程调试功能，支持算法工程师进行远程调试。
在对平台需求、质量属性描述和架构特性进行分析的基础上，公司的架构师给出了三种候选的架构设计方案，公司目前正在组织相关专家对平台架构进行评估。
【问题1】(9分)
在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并从题干中的(a)-(l)中选择合适的质量属性描述，填入(3)-(6)空白处，完成该平台的效用树。

【问题2】(16分)
针对该系统的功能，赵工建议采用解释器(interpreter)架构风格，李工建议采用管道过滤器(pipe-and-fter)的架构风格，王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景，从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析，并指出该平台更适合采用哪种架构风格。

我的回答：
问题1：
(a) 功能性需求
(b) 安全性
© 可用性
(d) 功能性需求
(e) 可用性
(f) 性能
(g) 可修改性
(h) 安全性
(i) 可修改性
(j) 性能
(k) 功能性需求
(l) 可测试性

（1）性能 （2）可修改性 （3）（e) （4）（j) （5）（h) (6) (i)

问题2：
从机器学习流程定义的灵活性来看：
管道过滤器风格通过管道连接各个过滤器，顺序执行各个过滤器，来进行流程定义，流程定义依赖于前一个过滤器，定义方式不够灵活；隐式调用风格通过事件触发来进行相应的流程定义，依赖于特定事件的触发，定义方式也不够灵活；而解释器风格通过动态定义解释规则来确定流程的定义，方便用户自定义，以及增添改查，灵活性最强；
从学习算法的可扩展性来看：
管道过滤器风格支持多个过滤器并行执行算法组件从而执行多个学习算法，但此多个算法组件均依赖于前一个组件，算法组件扩展时需要与前一个组件相关，其扩展性受限；隐式调用风格通过事件触发，可以将该事件广播给多个组件使用，组件通过订阅这个事件来进行算法的执行。解释器风格通过用户自定义添加运行规则，方便算法组建的添加，可扩展性较好；
综上，考虑到该系统对灵活性和可扩展性的要求，该平台更适合用解释器风格。

【问题1】
(1)性能
(2)可修改性
(3)(e)可用性
(4)(j)性能
(5)(h)安全性
(6)(i)可修改性
【问题2】
本题系统中有多个应用场景提到了系统分角色有不同的操作流程与界面，以及在修改扩充系统时，需要能够在限定时间内快速完成任务。基于这样的情况，我们从两方面进行分析：

解释器：机器学习流程定义的灵活性高，学习算法的可扩展性强。因为解释器风格可以通过自定义流程规则及配套流程解释引擎开发，做到用户层面的流程完全定义，而不需要修改代码，所以无论是修改已有的业务流程，还是要扩展不同的角色，创建新角色的流程都非常便利。解释器按照输入输出格式将学习算法封装为组件，通过解释器机制动态增加或删除算法组件，并支持动态调用，学习算法的可扩展性强。

管道过滤器：机器学习流程定义的灵活性低，学习算法的可扩展性弱。因为管道过滤器是把数据处理职能做成过滤器，把数据传递做成管道，此时如果流程不发生变化，是可以通过这种方式实现的，但一旦流程变化，或是扩展功能，需要对过滤器进行修改调整，或是流程在程序层面重建，此时必须修改代码完成任务。管道过滤器按照输入输出格式将学习算法封装为组件，如果需要增加或删除组件，需要停止平台并进行重新部署，学习算法的可扩展性弱。

隐式调用：机器学习流程定义的灵活性一般，学习算法的可扩展性一般。隐式调用强调的是通过间接方式进行调用，如采用事件机制，要完成某个动作时先触发事件，事件与相关动作关联，以提升灵活度，本题中可把角色执行业务的流程用事件触发。这种做法比管道过滤器强，但弱于完全自定义的解释器。隐式调用按照输入输出格式将学习算法封装为处理函数，支持动态增加和删除函数，学习算法的可扩展性一般。

经过综合比较与分析，可以看出该系统更适合使用解释器风格。
系统架构设计师考试题库重点案例：软件架构设计与评估

第2题

阅以下关于软件系统设计与建模的叙述，回答问题1至问题3。
【说明】
某医院拟委托软件公司开发一套预约挂号管理系统，以便为患者提供更好的就医体验，为医院提供更加科学的预约管理。本系统的主要功能描述如下：(a)注册登录，(b)信息浏览，©账号管理，(d)预约挂号，（e）查询与取消预约，(f)号源管理，(g)报告查询，(h)预约管理，(i)报表管理和(j)信用管理等。
【问题1】(6分)
若采用面向对象方法对预约挂号管理系统进行分析，得到如图21所示的用例图。请将合适的参与者名称填入图21中的(1)和(2)处.使用题干给出的功能描术(a)-(j),完善用例(3)~(12)的名称

(问题2】(10分)
预约人员（患者）登录系统后发起预约挂号请求，进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息，
在数据库中调用医生列表，并调取医生出诊时段表，将医生出诊时段反馈到预约界面，并显示给预约人员；预约人员选择医
生及就诊时间后确认预约，系统反馈预约结果，并向用户显示是否预约成功。
采用面向对象方法对预约挂号过程进行分析，得到如图2-2所示的顺序图，使用题干中给出的描述，完善图2-2中对象(1)，及消息(2)~(4)的名称，请简要说明在描述对象之间的动态交互关系时，协作图与顺序图存在哪些区别。

【问题3】(9分)
采用面向对象方法开发软件，通常需要建立对象模型、动态模型和功能模型，请分别介绍这3种模型，并详细说明它们之间的关联关系，针对上术模型，说明哪些模型可用于软件的需求分析？

我的回答：
问题1：
（1）患者
（2）预约挂号管理系统
（3）c
（4）a
（5）b
（6）d
（7）e
（8）g
（9）f
（10）h
（11）i
（12）j

问题2：
（1）预约人员
（2）发起预约挂号请求
（3）显示医生可预约时间段
（4）显示是否预约成功

协作图与顺序图的区别：

交互方式不同：顺序图是描述了对象之间顺序的交互关系，协作图则描述了对象间交互协作关系，交互关系不是顺序的，不强调时间上的顺序
消息格式不一样：顺序图有返回消息，调用消息等，而协作图没有返回消息等

问题3：
对象模型：描述了对象之间的静态关系，如类图反映了一组类与接口的关系，对象图是类图的静态快照，描述了对象与对象间的静态关系
动态模型：描述了对象之间的动态交互关系，如顺序图是描述了对象之间顺序的交互关系，协作图则描述了对象间交互协作关系，交互关系不是顺序的，不强调时间上的顺序，定时图，则描述了各个对象交互时的特定时间节点。
功能模型：描述了用户设计类或对象时所需实现的功能，如用例图描述了用例与参与者间的关系，用例就是一个功能，反应了开发软件所需的功能

关联联系：采用面向对象方法开发软件时，首先建立功能模型，将实际场景功能，转换为功能模型，让开发者明确软件具体功能，然后根据功能模型来实现动态模型，反映描述了对象之间的动态交互关系，最后将抽象的功能模型以及动态模型转换为对象模型，从而设计程序中所需要的类和对象

功能模型可用于需求分析

【问题1】
该问考查UL中的用例图填充，首先根据题意可以分析出患者这个参与者。而另一个参与者题目没有明示，然而
从号源管理、预约管理等用例来看，定性为“医院管理员”较为合适，医院管理员是一个系统中比较常见的角色，起
系统管理职能。
然后通过用例的名称来分析判断哪些用例归属于患者哪些归属于医院管理员，按这个罗辑很容易分析出：
患者：(a)注册登录(b)信息浏览©账号管理(d)预约挂号(e)查询与取消预约(g)报告查询
医院管理员：(a)注册登录(f)号源管理(h)预约管理()报表管理()信用管理
从而根据图中参与者对应的用例数给参与者和用例定位到具体的空中。
【问题2】
该问考查UML中的顺序图，本问比较容易，紧扣题目描述来组织内容即可，从题干中“预约人员（患者）登录系统后发起预约挂号请求，进入预约界面”的信息可知(1)应为预约人员（患者），(2)为预约挂号请求；从题干中“将医生出诊时段反馈到预约界面，并显示给预约人员”的信息可知(3)应为显示医生可预约时段；从题干中“系统反馈预约结果，并向用户显示是否预约成功”的信息可知(4)应为显示预约是否成功。序列图（顺序图）是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
协作图，和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系或对象间组织结构，则选择协作图。
【问题3】
该问考查了一个较为早期提出的面向对象模型一OMT。
OMT方法的OOA模型包括对象模型、动态模型和功能模型
对象模型表示静态的，结构化的“数据”性质，它是对模拟客观世界实体的对象及对象间的关系映射，描述了系统的静态及结构。通常用类图表示。对象模型描述系统中对象的静态结构、对象之间的关系、对象的属性、对象的操作。对象模型表示静态的、结构上的、系统的“数据”特征。对象模型为动态模型和功能模型提供了基本的框架。对象模型用包含对象和类的对象图来表示。

动态模型表示瞬间的，行为化的系统控制性质，它规定了对象模型中的对象合法化变化序列。通常用状态图表示。动态模型描述与时间和操作顺序有关的系统特征一激发事件、事件序列、确定事件先后关系的状态以及事件和状态的组织。动态模型表示瞬间的、行为上的、系统的“控制”特征。动态模型用状态图来表示，每张状态图显示了系统中一个类的所有对象所允许的状态和事件的顺序。

功能模型表示变化的系统的功能性质，它指明了系统应该做什么，因此直接地反映了用户对目标系统的需求，通常用数据流图表示。功能模型描述与值变换有关的系统特征一功能、映射、约束和函数依赖。

对象模型用于描述系统数据结构；动态模型用于描述系统控制结构；功能模型用于描述系统功能。
这3种模型都涉及数据、控制和操作等共同的概念，但侧重，点不同，从不同侧面反映了系统的实质性内容，综合起来全面地反映了对目标系统的需求。
功能模型指明了系统应该“做什么”；动态模型明确规定了什么时候做；对象模型则定义了做事情的实体。
对象模型、动态模型和功能模型均可用于软件的需求分析。

软考高项UML的14种图详解
软考高级《系统架构设计师》UML图的总结与真题解析
05 对象建模技术OMT