面向对象软件工程-题库

type

status

date

slug

summary

一、问答题（40分）

1. 什么是面向对象？有哪些基本概念？编写代码，举例说明其基本特征。

答案要点

定义：以对象为核心，通过封装、继承、多态组织代码的编程范式。

基本概念：

类（模板，如Animal类）与对象（实例，如Dog对象）。

封装（隐藏实现，如private属性+public方法）。

继承（复用代码，如Car extends Vehicle）。

多态（同一接口不同行为，如Animal.sound()调用Dog或Cat的实现）。

代码示例（Java）：

2. 什么是面向对象软件工程？

答案要点

核心：基于OOP的软件开发方法，强调模块化、复用性、可维护性。

特点：

通过抽象构建模型（如UML类图）。

遵循SOLID原则（如单一职责、开闭原则）。

迭代开发（如统一过程UP）。

3. 什么是统一过程？有哪些特点？

答案要点

定义：迭代式软件开发框架，用例驱动，强调架构设计。

特点：

用例驱动（需求通过用例定义）。

以架构为核心（早期明确系统结构）。

迭代增量开发（分阶段交付）。

4. 简述统一过程生命周期。

答案要点

初始阶段：确定核心用例和风险。

细化阶段：设计架构，验证关键需求。

构造阶段：迭代开发功能模块。

移交阶段：部署、测试和维护。

5. UML 有哪些部分构成，有哪几类图？

答案要点

构成：结构元素（类、对象）、行为元素（交互、状态）、关系（继承、依赖）。

分类：

结构图：类图、组件图。

行为图：用例图、活动图。

交互图：顺序图、协作图。

6. 简述迭代和增量过程。

答案要点

迭代：重复优化同一模块（如多次改进登录功能）。

增量：分阶段添加功能（如先实现基础支付，再扩展多种支付方式）。

核心区别：迭代改进已有功能，增量增加新功能。

7. 请说明用例如何驱动开发。

答案要点

需求阶段：用例图明确功能范围（如用户注册、订单管理）。

设计阶段：用例转化为类图和方法（如User类关联Order类）。

测试阶段：用例生成测试用例（如验证注册成功/失败分支）。

8. 什么是领域模型？如何建立领域模型？

答案要点

定义：领域模型是对业务领域核心概念及其关系的抽象表达，反映业务规则和逻辑。

建立步骤：

提取业务名词：从需求描述中识别关键实体（如“活动”“用户”等）。

抽象业务概念：将名词分类为实体、值对象等，明确属性和关系（如“活动参与记录”）。

使用UML建模：通过类图、用例图等描述模型结构。

验证通用语言：用领域术语重新描述需求，确保无歧义。

9. 什么是业务模型？如何建立业务模型？

答案要点

定义：业务模型是对业务流程、参与者、规则及资源的系统化描述，用于理解与优化业务。

建立步骤：

定义业务愿景：明确业务目标和核心问题。

识别涉众与角色：分析参与者（如用户、运营人员）及其需求。

绘制业务流程：使用BPMN或UML活动图描述流程（如“用户登录流程”）。

提炼业务规则：记录约束条件（如“登录次数限制”）。

10. 有哪些获取业务模型信息的技术？

答案要点

需求访谈：与业务专家沟通，提取核心需求。

用例分析：通过用例图明确功能边界（如“用户注册用例”）。

文档分析：研究现有业务文档、流程手册等。

事件风暴：通过头脑风暴梳理关键事件和实体。

原型设计：通过界面原型验证交互逻辑。

<ins/>

11. 系统中的“登录”用例没有登录次数的限制，现在登录重试的次数限制为3次，请修正该模型，以满足需求的变更。

答案要点

模型修正：

添加登录控制类：负责管理登录次数（如LoginController）。

引入计数器属性：在控制类中定义retryCount字段，初始值为0 。

定义验证逻辑：每次登录失败时retryCount++，达到3次后锁定账户。

UML表示：在类图中为登录用例添加控制类，关联用户实体和边界类（登录界面）。

12. 为什么需要分析工作流？

答案要点

核心原因：

理解业务逻辑：明确流程步骤与规则（如订单审批流程）。

优化效率：识别冗余步骤并改进（如合并审批环节）。

系统设计依据：确保软件功能与业务流程一致（如自动化工单流转）。

降低风险：提前发现流程漏洞（如权限分配不当）。

13. 什么是实体类、边界类和控制类？如何表示？

答案要点

实体类（Entity Class）：

定义：表示业务数据（如User、Order），与数据库表对应。
表示：UML类图中用普通类表示，标注属性（username、balance）。

边界类（Boundary Class）：

定义：系统与外界交互的接口（如登录界面、API）。
表示：UML中用构造型<<boundary>>标记。

控制类（Control Class）：

定义：处理业务逻辑（如LoginController），管理流程。
表示：UML中用构造型<<control>>标记。

示例：

登录场景：

边界类：LoginPage（界面）
控制类：LoginController（验证逻辑）
实体类：User（存储用户信息）

14. 如何抽取实体类？

答案要点

方法：

用例驱动：从需求文档或用例描述中提取名词或名词短语（如“用户”“订单”）作为候选实体类。

筛选原则：

保留与业务核心数据相关的名词（如“账户”而非“用户界面”）。

排除系统外部参与者（如“管理员”不作为实体类）。

合并同义词（如“客户”与“用户”统一为“用户”）。

验证：实体类需对应业务中的持久化数据（如数据库表），且具有唯一标识（如UserID）。

15. 如何寻找边界对象？

答案要点

方法：

识别交互点：系统与外部（用户、第三方系统）的接口（如登录界面、API端点）。

用例分析：每个用例对应至少一个边界类（如“注册界面”对应“用户注册”用例）。

类型：包括用户界面（UI）、硬件接口、外部系统适配器等。

16. 如何寻找控制类？

答案要点

方法：

流程驱动：识别用例中协调多个对象交互的逻辑（如“支付流程控制类”）。

职责分配：将不属于实体或边界类的业务逻辑（如数据校验、事务管理）分配给控制类。

合并原则：复杂流程可合并多个控制类（如“订单管理”统一处理创建、支付、取消）。

17. 什么是构架？

答案要点

定义：软件系统的高层次结构，描述组件划分、交互规则及技术选型。

核心要素：

分层（如用户接口层、领域层）。
组件（如微服务、模块）。
技术约束（如数据库选型、通信协议）。

18. 为什么需要构架？

答案要点

关键作用：

管理复杂性：分解系统为可理解的模块，降低开发难度。

支持演进：通过分层和接口隔离变化（如替换数据库不影响业务逻辑）。

促进协作：明确团队分工（如前端与后端分离）。

保障非功能性需求：性能、安全性等通过架构设计实现。

19. 如何描述构架？

答案要点

描述方法：

视图模型：

逻辑视图：组件关系（如类图）。

开发视图：代码模块划分（如Maven模块）。

物理视图：部署结构（如服务器拓扑）。

分层架构：如DDD的四层架构（用户接口层→应用层→领域层→基础设施层）。

技术文档：架构图+文字说明关键设计决策（如选择微服务的原因）。

20. 简述分析模型和设计模型的区别。

答案要点

分析模型：

目标：描述系统“做什么”，关注业务逻辑和理想化设计。
内容：用例图、实体类、初步交互流程。
抽象层级：不涉及技术细节（如数据库类型）。

设计模型：

目标：描述系统“如何做”，关注实现细节。
内容：详细类图（含方法）、数据库表结构、接口定义。
技术约束：包含非功能性需求（如性能优化、事务控制）。

<ins/>

21. 简述设计在软件生命周期中的作用。

答案要点

核心作用：

指导开发：设计模型是编码的直接依据（如类图→Java类）。

降低风险：通过架构设计提前规避技术难点（如分布式事务）。

保证质量：遵循设计原则（如SOLID）提高代码可维护性。

支持迭代：模块化设计允许分阶段交付（如MVP→功能扩展）。

22. 什么是设计模式？有什么好处？

答案要点

定义：设计模式是针对软件设计中常见问题的可重用解决方案模板，提供标准化代码结构和交互方式（如单例模式、工厂模式等）。

核心好处：

可重用性：减少重复代码，提升开发效率（如工厂模式封装对象创建逻辑）。

架构指导：明确模块职责与交互规则（如分层架构通过策略模式实现算法替换）。

经验传承：基于专家经验规避潜在设计缺陷（如避免单例模式的线程安全问题）。

代码透明：统一设计风格，降低团队协作成本（如遵循观察者模式的事件处理逻辑）。

23. 如何进行分析模型的评审？

答案要点

评审目标：验证分析模型是否完整覆盖需求，逻辑一致且符合设计原则（如SOLID原则）。

评审步骤：

检查模型与需求对齐：比对用例图、类图与需求文档的一致性。

验证逻辑正确性：通过流程图或活动图确认业务流程无冲突（如状态转换是否合理）。

评估扩展性：检查模型是否支持未来需求变更（如通过策略模式实现算法扩展）。

24. 如何执行单元测试？

答案要点

步骤：

编写测试用例：覆盖所有独立路径、逻辑分支及边界条件（如循环边界、异常输入）。

执行测试：使用框架（如JUnit）运行测试，记录实际结果与预期差异。

动态跟踪：结合白盒测试技术（如路径覆盖）确保代码覆盖率达标。

策略：优先采用独立测试策略，通过桩模块/驱动模块隔离被测单元。

25. 如何选择编程语言？

答案要点

关键因素：

项目需求：

性能要求高 → C++/Rust。
快速开发 → Python/JavaScript。

团队熟悉度：选择团队主流语言以降低学习成本。

生态支持：如AI领域优先Python（TensorFlow/PyTorch）。

26. 如何养成良好的编程实践？

答案要点

核心习惯：

规划先行：写代码前用注释或伪代码规划逻辑框架。

代码规范：命名清晰（如calculateTotalPrice()）、缩进统一、注释不低于20% 。

性能优化：减少冗余计算（如预计算循环边界）、使用池化技术（连接池）。

持续学习：掌握设计模式（推荐《大话设计模式》）和代码重构技巧。

27. 有哪几种集成方式，各有什么特点？

答案要点

非增量测试：一次性集成所有模块，优点是速度快，缺点是问题定位困难（如汽车组装后发动机故障难排查）。

增量测试：

自顶向下：优先测试主控模块，需桩模块模拟下层（适合核心逻辑优先验证）。
自底向上：先测底层模块，需驱动模块模拟调用（适合基础功能稳定性验证）。
混合策略：结合两者优势，分阶段集成复杂系统。

28. 有哪些黑盒测试技术、白盒单元测试技术？

答案要点

黑盒测试技术：

等价类划分：输入域分类（如有效/无效邮箱格式）。

边界值分析：测试输入边界（如数值范围的最小/最大值）。

场景法：模拟用户操作路径（如电商下单流程）。

白盒测试技术：

路径覆盖：确保代码所有执行路径被测试。

条件覆盖：验证逻辑判断的真/假分支。

29. 什么是代码走查和审查？

答案要点

代码走查：通过人工模拟程序执行（如带入测试数据逐步跟踪代码），验证逻辑正确性（如检查循环边界）。

代码审查：

形式：审查小组检查代码是否符合设计文档（如类图、接口规范）。
重点：命名规范、异常处理、性能优化（如内存泄漏排查）。

区别：走查侧重动态逻辑验证，审查侧重静态设计一致性。

30. 何时重写而不是调试代码制品？

答案要点

技术债务过高：

当代码臃肿、维护成本激增，且调试难以解决核心结构性问题时（如代码耦合度过高、频繁出现不可预测的Bug）。

核心需求变更：

产品需要大规模架构调整（如从单体架构转向微服务），原有代码无法通过局部修改适配新需求。

外部技术驱动：

技术环境重大升级（如操作系统版本迭代、框架不兼容），需重新设计以支持新特性（例如iOS 7发布迫使应用全面重构）。

效率瓶颈：

现有代码导致开发速度显著下降，工程师因复杂逻辑或过时技术难以高效迭代。

<ins/>

31. 什么是软件复用？

答案要点

定义：软件复用指在构建新系统时，重复使用已有的软件制品（如代码、设计、测试用例、文档等），以提高开发效率、降低成本并提升质量。

范围：

产品复用：直接复用代码、构件或模块。
过程复用：复用设计方法、测试流程或管理经验。

32. 软件复用有哪几个层次？

答案要点

代码级复用：

通过公共函数、类库直接复用代码片段（如标准函数库）。

构件级复用：

封装功能模块（如日志组件、支付SDK），通过API提供黑盒或白盒复用。

模块级复用：

复用业务功能模块（如用户管理、订单系统），需关注模块的可扩展性。

架构级复用：

复用成熟的系统架构（如微服务架构、分层架构），支持快速搭建同类系统。

领域级复用：

针对特定领域（如医疗、金融），复用领域模型、通用业务流程和框架。

扩展分类：

水平复用：跨领域通用功能（如日志模块、工具类）。

垂直复用：同一领域内紧密集成的功能（如电商平台的购物车与支付模块）。

33. 软件复用面临哪些困难？

答案要点

技术障碍：

异构技术栈：不同系统采用不同语言或框架（如Java与.NET），导致代码无法直接复用。

耦合度高：模块与原有系统强耦合（如数据层依赖），需解耦改造才能复用。

业务差异：

相同功能在不同业务场景需定制化调整（如健康档案模块在基层医院与三甲医院的差异）。

管理与协作问题：

发现成本：缺乏统一组件库，难以找到可复用资源。

维护冲突：复用后组件修改导致与原版本分化，长期维护成本增加。

抽象与设计难度：

设计通用组件需平衡灵活性与复杂性，过度抽象可能降低易用性。

解决方向：

建立企业级组件库和标准化接口。

采用领域驱动设计（DDD）降低业务差异影响。

二、建模作图题（36分）

1.“雇员”参与者不能“设置雇员”、“设置收费代码”或“导出工时记录”用例。在正常的情况下，“雇员”参与者必须触发“记录工时”用例，“管理员”参与者“设置雇员”、“设置收费代码”以及“导出工时记录”用例。“管理员”也必须记录自己的工时，而且，管理员用户需要为生物或请假的雇员登记工时，需要将工时记录数据导入到支付系统。

2.银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址（或电话号码）、身份证号码、存款类型、存款日期、到期日期、利率及密码（可选）等信息，并打印出存单给储户；如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并打印出利息清单给储户。请用用例图描绘本系统的功能。

3.画出求职招聘网需求的总用例图，提示：求职者和招聘者都是“用户”参与者，每个用户使用系统的前置条件是“登录系统”。所有用户共性用例都具有“修改密码”的功能。注意使用参与者之间的泛化关系，再分别考虑每个参与者应该完成的工作职责。其中求职者可以完成“发布求职意向”、“投递简历”、“更新个人信息”、“搜索招聘信息”、“下载简历模板”、“查看个人信箱”“修改密码”；招聘者可以完成“发布招聘信息”、“浏览所传简历”、“回复求职者”、“搜索应聘信息”、“更新企业信息”、“查看企业邮箱”、“修改密码”。管理员可以“管理新用户”、“管理招聘用户”、“修改密码”。

4.下面是关于“Login”用例的事件描述，请根据描述画出活动图。

# 正常事件流：

管理员或雇员的姓名和密码是有效的。

1) 管理员或雇员输入姓名和密码。

2) 验证用户是管理员还是雇员，用户在登录的时候并没有选择身份，而是由系统根据用户名确定的。登录后，显示欢迎信息。

# 可选事件流：

第一次登录。

1) 管理员或雇员输入姓名和密码。

2) 验证用户是管理员还是雇员，用户在登录的时候并没有选择身份，而是由系统根据用户名确定的。

3) 系统提示用户更改密码。

4) 在这一入口点包含“修改密码”用例。

# 可选事件流：

无效的验证信息。

1) 管理员或雇员输入姓名和密码。

2) 系统通知用户，输入的登录信息不正确。

3) 系统在日志中记录登录失败。

4) 用户登录3次无效，将锁定账户，需要管理员解锁后才能再次登录。

5.“设置雇员”的用例

# 正常事件流：

管理员增加一个雇员。

1) 管理员按名字查看所有的雇员列表。

2) 管理员增加一个雇员，填写名字、电子邮件地址、密码等。

3) 新雇员出现在视图中，可以开始登记工时。

# 可选事件流：

雇员已经存在。

1) 管理员按名字查看所有的雇员列表。

2) 管理员增加一个雇员，填写名字、电子邮件地址、密码等。

3) 管理员被告知该雇员已经存在。已有的数据不做任何改变。

# 异常事件流：

由于系统或通信错误，系统无法增加雇员。

1) 管理员按名字查看所有的雇员列表。

2) 管理员增加一个雇员，填写名字、电子邮件地址、密码等。由于系统或通信错误，系统无法完成该操作。

3) 系统将错误及其详细信息通知管理员，视图回到前一个状态。

4) 如果可能，在日志中记录该错误。

<ins/>

6.“导出工时记录”的用例

# 正常事件流：

管理员导出数据。

1) 管理员选择一段日期。

2) 管理员选择部分或所有的客户。

3) 管理员选择部分或所有的雇员。

4) 管理员选择目标文件。

5) 数据以XML格式导出到文件中，过程结束后通知管理员。

# 异常事件流：

由于系统错误，无法导出数据。

1) 管理员选择一段日期。

2) 管理员选择部分或所有的客户。

3) 管理员选择部分或所有的雇员。

4) 管理员选择目标文件。

5) 系统无法导出数据，管理员得到有关错误的通知。

6) 如果可能，在日志中记录该错误。

7.下面是关于“CreateChargeCode”用例的事件描述，请根据描述画出活动图。

# 正常事件流：

增加一个收费代码到已有的项目中。

1) 针对一个选定的项目，管理员查看已有的收费项目代码。收费代码是按客户和项目组织的活动。

2) 管理员从通用的活动列表中选择一个活动，或输入一个新活动来为选定的项目创建一个新的收费代码。

3) 这个代码出现，雇员才可以使用。

# 可选事件流：

管理员增加一个新的客户和项目。

1) 管理员查看所有已有客户。

2) 管理员输入新客户的名字。

3) 管理员选择这个新客户，并为新的项目输入名称和描述信息。

4) 在管理员增加这个收费代码之前，雇员无法对这个项目进行记账。

# 可选事件流：

数据重复，输入的收费代码在指定层次上已经存在。

1) 管理员查看已有的收费代码。收费代码是按客户和项目组织的活动。

2) 管理员试图为已有的项目增加一个收费代码。在这个项目中该代码已经存在。一旦无重复的公共活动列表创建完成，这种情况将很少发生。

3) 系统通知管理员该代码已存在。已有的数据不做任何改变。

# 异常事件流：

由于系统或通信错误，系统无法保存数据。

1) 对于一个选定的项目，管理员查看已有的收费代码。收费代码是按客户和项目组织的活动。

2) 管理员从适用的活动列表中选择一个活动，或输入一个新活动来为选定的项目创建一个新的收费代码。

3) 系统无法保存新的收费代码。

4) 系统将错误及其详细信息通知用户。

5) 如果可能，在日志中记录错误。

8.电梯问题的逻辑原理是满足以下约束条件，在m层楼之间移动n部电梯。

1) 每部电梯内有m个按钮，每个按钮对应一个楼层。当有人按下按钮时，按钮变亮并指示电梯到相应的楼层；当电梯到达相应的楼层时，按钮变暗。

2) 除了一楼和顶楼外，每层楼有两个按钮，一个向上，一个向下。按钮按下时变亮；当电梯到达楼层并往请求方向移动的时候，按钮变暗。

3) 当电梯没有请求时，停留在当前楼层，电梯门关闭。

9.RecordTimeUI和RecordTimeAdministrativeUI对象使用RecordTimeWorkflow对象，后者又使用了User对象以及TimeCard对象。RecordTimeUI对象保存对RecordTimeWorkflow对象的引用，用它来更新条目（Entry），所以这是一个关联关系。RecordTimeWorkflow对象保存对User对象的引用，在RecordTimeWorkflow对象提交一个旧的TimeCard并使用新的TimeCard来替换时要使用到User对象，所以这是一个关联关系。RecordTimeWorkflow对象保存对TimeCard对象的引用。在RecordTimeWorkflow对象为TimeCard对象设置条目的时候要用到TimeCard对象，所以这是一个关联关系。TimeCard包含多个条目（Entry）。

10.根据下面的描述，画出类图。某公司销售多种物品，物品具有特征、类别等详细说明；物品存放到几个仓库中；客户可以同时下订单购买一种或多种物品。

<ins/>

11.创建一个类图。下面给出创建类图所需的信息。

• 学生（student）可以是在校生（undergraduate）或者毕业生（graduate）。

• 在校生可以是助教（tutor）。

• 一名助教指导一名学生。

• 教师和教授属于不同级别的教员。

• 一名教师助理可以协助一名教师和一名教授，一名教师只能有一名教师助理，一名教授可以有5名教师助理。

• 教师助理是毕业生。

12.在一个“客户服务系统”中，需要管理的用户包括客户人员、维护人员、部门领导，都具有用户ID、姓名、性别、年龄、联系电话、部门、职位、密码、登录名。其中，维护人员具有三个操作，即接受派工任务、填写维护报告、查询派工任务；部门领导具有五个操作，即安排派工任务、修改派工任务、删除派工任务、查询派工任务、处理投诉；客户人员具有四个操作，增加客户、删除客户、修改客户和查找客户。这三个类可以抽象出一个单独的抽象系统用户类，它们可以从系统用户类来继承。

13.Employee请求EmployeeLoginUI边界对象显示登录表单（displayLoginForm）， Employee输入用户名和密码后提交给系统（submitNameAndPassword）。 EmployeeLoginUI对象要求LoginWorkflow控制对象对登录进行验证（validateLogin）。要想满足这个请求，LoginWorkflow对象要求UserLocator对象找到对应的User对象（findByName）。一旦LoginWorkflow对象得到了正确的 User对象，就要求后者对密码进行验证（validateLogin）。一旦LoginWorkflow 对象收到响应，就将验证结果回传给EmployeeLoginUI对象。如果 EmployeeLoginUI对象收到响应为验证通过，就显示欢迎信息，整个流程结束。

14.根据下面的叙述，绘制一幅关于顾客从自动售货机中购买物品的顺序图。

(1) 顾客（User）先向自动售货机的前端（Front）投币；

(2) 售货机的识别器（Register）识别钱币；

(3) 售货机前端（Front）根据 Register 的识别结果产生商品列表；

(4) 顾客选择商品；

(5) 识别器控制的出货器（Dispenser）将所选商品送至前端（Front）

15.“RecordTime”用例的正常事件流开始于参与者请求当前的条目。RecordTimeUI对象调用RecordTimeWorkflow对象的getEntries()方法，该方法拥有指向User对象的引用。有了User对象，RecordTimeWorkflow对象向它要求当前的TimeCard对象。接下来RecordTimeWorkflow对象就能够向TimeCard对象要求其所有的条目，并将它们返回给RecordTimeUI。在Employee参与者完成对工时条目的更新后，RecordTimeUI对象使用RecordTimeWorkflow对象上的updateEntries()方法将更新传播到整个系统，最后RecordTimeWorkflow对象调用指向TimeCard对象引用上的setEntries()方法。

16.当派工单的状态在某一事件或某个条件满足时，就在这五个状态中进行转换。分配、作废、完成等是状态转换所发生的事件。根据各种状态以及转换规则，创建派工单完整的状态图。

17.在图书馆中，购入的书在半个月内为新书，以后为旧书。书无论新旧，都可以向外借阅。针对上述要求建立状态图。

18.火车票售票系统中火车票的状态可以有待售、预约或已售出 3 种不同的状态，用户可以购买待售火车票，也可以预约，但是，预约后两天内没有购买自动进入待售状态。

19.在客户服务系统中，将客户业务的功能单独的作为一个包，在该包中嵌套两个子包，分别是客户咨询管理和派工管理。细化包图，在客服咨询管理中嵌套三个子包，分别是咨询、投诉、保修；派工管理中嵌套两个子包，维护安排和回访安排。

20.基于SSH框架的系统中，action包依赖service包，service包依赖dao包，它们都依赖model包。

<ins/>

21.主要存在两个包，分别为财务子系统和数据库子系统。数据库子系统又包括数据库操作、数据库接口以及Oracle接口和Sybase接口包四个包。财务子系统依赖于数据库子系统，数据库操作依赖于数据库接口。Oracle接口和Sybase接口都是数据库接口。

三、分析设计题（不考）

假设要为某医院开发一个电话挂号的软件管理系统，其需求陈述如下：

当病人打电话挂号时，接线员将查阅挂号登记表，如果病人申请的就诊时间与医生的接诊时间冲突，则接线员建议一个就诊时间以安排病人尽早得到就诊。如果病人同意建议的就诊时间，接线员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗后，护士将标记相应的挂号就诊已经完成，如果必要的话会安排病人下一次复诊时间。

系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和挂号信息。接线员可以取消挂号，可以打印出前三天已挂号但尚未就诊的病人清单。系统可以从病人记录中获知病人的电话号码。接线员还可以打印出所有医生的每天和每周的工作安排。

请使用面向对象方法对该系统进行分析、设计，建立该系统的（1）用例模型；（2）对象模型；（3）状态图；（4）功能模型。 1. 建立用例

在这个阶段，通过用例来捕获用户的需求。用例图从用户角度描述系统的功能，它必须包含用户关心的所有关键功能。用户通常就是用例图中的执行者。为了画出系统的用例图，首先应该找出系统的用户，然后根据用户对系统功能的需求确定用例。

从对系统的需求陈述可知，接线员负责处理病人挂号事务，为此他需要访问挂号登记表和病人记录，接线员也可以取消挂号。此外，接线员还可以根据挂号登记表打印出关于所有医生的每天和每周的工作安排，医生将按照工作安排接诊病人；在病人就诊后，护士将标记相应的挂号诊治已完成，必要时还将安排病人下次复诊，即护士也可以更新挂号登记表的内容；系统能够按照病人姓名和日期查询预约信息，虽然这项查询功能需求没有指明执行者，但是这并不意味着没有执行者也可以有用例，一个用例必须与至少一个执行者相关联，可以认定“查询预约”这个用例的执行者可以是医院的护士和接线员。

综上所述，系统中的执行者有接线员、医生和护士；用例有打印工作安排、取消挂号、更新挂号、查询挂号、完成挂号、访问病人记录和访问挂号登记表等。

2. 建立类图

类是面向对象的开发方法的基础，可以说 UML 的基本任务就要识别系统所必需的类，并分析类之间的联系，并以此为基础，建立系统的其它模型。建立类图的第一步工作是确定有哪些类。

从对牙科诊所问题的陈述中，可以按“名词识别法”找出下列名词作为类的候选者：

医院，接线员，医生，护士，软件系统，挂号，病人，挂号登记表，就诊时间，挂号时间，约定时间，系统，名字，记录的病人数据，病历号，姓名，日期，挂号信息，病人清单，病人记录，电话号码，每天工作安排，每周工作安排。

由于通过名词识别法找到的候选者中有许多并不是问题域中真正有意义的类，因此必须对这些候选者进行严格的筛选，从中删去不正确的或不必要的，只保留确实应该记录其信息或需要其提供服务的那些类。

根据需求陈述，电话挂号管理系统的主要功能是管理病人的挂号情况，并不关心医院内每名工作人员的分工，因此，医生、护士和接待员都不是问题域中的类；“软件系统”和“系统”是同义词，指的是将要开发的软件产品，不是问题域中的类；“就诊时间”、“挂号时间”和“约定时间”在本问题陈述中的含义相同，指的都是挂号时约定的就诊时间，它们包括日期和时间两部分，但是，它们是挂号登记表包含的属性，不能作为问题域中的类；“名字”和“姓名”是同义词，应该作为病人和挂号登记表的属性；“记录的病人数据”实际上就是“病人记录”，可以统一使用“病人记录”作为类名；“病历号”和“电话号码”是病人记录的属性，不是独立的对象；从需求陈述可知，“病人清单”是已挂号但尚未就诊的病人名单，应该包含病人姓名、约定的就诊时间等内容，它和“挂号信息”包含的内容基本相同，可以只保留“病人清单”作为问题域中的类。

确定类之后，接下来分析确定问题域中类彼此之间的关系。“每天工作安排”和“每周工作安排”有许多共同点，可以从它们泛化出一个父类“工作安排”。此外，问题域的类之间还有下述关联关系：医院可以接诊多名病人；一位病人人有一份病人记录；一位病人可能预约多次也可能一次也没预约；医院在一段时间内将打印出多份病人清单；医院已经建立了多份挂号登记表；挂号登记表中记录了多位病人的挂号记录；根据挂号登记表在不同时间可以制定出不同的工作安排。

通过上述分析，可以画出图 2 所示的医院电话挂号管理系统的类图。

3. 建立状态图

如果需要深入理解类，可以画状态图来详细描述类的状态变化情况。实际工作中，并不需要为每个类都画状态图，只对所关心的某些类的行为进行描述即可。牙科诊所管理系统的主要功能是实现病人预约，根据需求陈述可以画出医院电话挂号管理系统状态图（图3）。图中把除了完成病人预约之外的事务笼统地称为日常事务。

4. 建立功能模型

功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据注图组成。从需求陈述可知，当进行电话挂号时病人提供姓名、希望的就诊日期等数据，系统查询挂号登记表，以确定一个有效的就诊日期，此外，系统还将查询病人记录以获得病历号等病人数据。护士在每次就诊后，应该更新挂号登记表，以标记相应的电话挂号已经完成，必要时将约定下次复诊时间。接线员可以根据病人姓名和日期查询预约信息，也可以取消预约。此外，系统可以打印出每天和每周的工作安排给医生。

根据上述的系统功能，可以画出图4所示的医院电话挂号管理系统的数据流图。