软件工程课程复习提纲

一、基本知识点

1. 软件工程的概念及目标

软件工程的定义

软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术和管理方法。根据1993年IEEE的定义，软件工程是将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程，同时也是对这些方法进行研究的学科领域。

软件工程包含三个主要组成部分：方法、工具和过程。

• 方法： 为软件开发提供“如何做”的技术。它支持项目计划和估算、系统和软件需求分析、软件设计、编码、测试和维护。

• 工具： 为软件工程方法提供自动或半自动的软件支撑环境。目前已经建立有集成化的计算机辅助软件工程（CASE）环境。

• 过程： 定义了方法使用的顺序、要求交付的文档资料，为保证质量和协调变化所需要的管理及软件开发的各个阶段的里程碑。

软件工程的方法、工具、过程构成了软件工程的三要素，这些要素协同工作以实现软件项目的成功开发和维护。

软件工程的目标

软件工程的目标是在给定成本和进度的前提下，开发出具有以下特征的软件产品：

1. 可修改性： 软件能够容易地进行修改和升级，以适应新的需求和环境。

2. 可靠性： 软件在各种条件下都能够稳定运行，不易出现故障和错误。

3. 有效性： 软件能够以高效的方式完成其预定的功能，不浪费资源。

4. 可理解性： 软件的结构和代码易于理解，方便开发人员进行维护和改进。

5. 可维护性： 软件容易进行维护，包括修复错误、更新功能和适应新的硬件或软件环境。

6. 可重用性： 软件的模块或组件能够被有效地应用于其他系统或模块，以提高开发效率和降低成本。

7. 可适应性： 软件能够适应不断变化的环境和需求，具有灵活性和可扩展性，以应对未来的挑战。

8. 可移植性： 软件能够在不同的硬件平台、操作系统或环境中轻松移植和运行，而无需大量修改。

9. 可跟踪性： 能够追踪软件开发和维护过程，以确保项目按照计划进行，随时了解项目的状态和进展。

10. 可互操作性： 软件能够与其他软件或系统进行有效的交互和集成，实现数据和功能的共享。

这些目标共同确保了软件工程的成果能够满足用户的需求，具有良好的质量和可维护性，同时在开发过程中保持经济效益。

2. 软件危机的概念及典型表现

软件危机的概念

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。它涉及两个主要方面的挑战：

1. 如何开发软件，以满足对软件日益增长的需求。
2. 如何维护数量不断膨胀的已有软件。

总体而言，软件危机的核心问题在于供求关系失调、开发费用失控，导致进度拖延、可靠性差、难以维护。以下是软件危机的典型表现：

软件危机的典型表现

1. 估计准确性问题： 对软件开发成本和进度的估计常常不准确，导致项目可能超过预算和延期。

2. 用户满意度问题： 用户对“已完成的”软件系统不满意的现象经常发生，说明软件交付的产品与用户期望存在差距。

3. 软件质量问题： 软件产品的质量往往不可靠，可能存在错误和缺陷，影响系统的稳定性和可靠性。

4. 维护困难问题： 软件常常是不可维护的，难以进行更新、修复和扩展，增加了后续维护的难度。

5. 文档不足问题： 软件通常没有适当的文档资料，缺乏详细的说明和指南，给维护人员带来困扰。

6. 成本占比上升问题： 软件成本在计算机系统总成本中所占的比例逐年上升，使得软件开发变得经济不可持续。

7. 生产率提高不足问题： 软件开发生产率提高的速度跟不上硬件的发展速度，也远远跟不上计算机应用普及深入的趋势，导致开发滞后。

这些表现共同构成了软件危机的临床症状，突显了传统软件开发模式在应对快速增长的需求和复杂性方面的困难。因此，软件工程的发展旨在解决这些问题，提高软件开发的质量和效率。

3. 瀑布模型的概念及特点

瀑布模型是一种经典的传统软件工程过程模型，它规定了六种软件工程活动的衔接次序，类似于瀑布流水的流程。

1. 接受输入： 从上一项活动接受该项活动的工作对象，作为输入。
2. 实施活动内容： 利用该输入实施该项活动应完成的内容。
3. 产出工作成果： 给出该项活动的工作成果，作为输出传给下一项活动。
4. 评审工作： 对该项活动实施的工作进行评审。如果工作得到确认，则继续进行下一项活动；否则，返回到前一项活动，甚至到更前项的活动进行反馈和修改。

瀑布模型的优点：

1. 有效的管理图示： 提供了清晰的开发流程图，有助于制定软件开发计划、进行成本预算和组织开发力量。

2. 阶段评审和文档控制： 在每个阶段都进行评审和文档控制，有助于有效地对整个开发过程进行监控和指导，确保软件产品及时交付并达到预期的质量要求。

3. 项目控制和管理： 瀑布模型为项目提供了明确的阶段，使得项目的控制和管理更为直观和可操作。

瀑布模型的缺点：

1. 缺乏灵活性： 瀑布模型要求严格按照阶段顺序进行，缺乏对变更的灵活响应，难以适应项目需求的变化。

2. 无法解决需求问题： 当软件需求不明确、不准确或需要不断完善时，瀑布模型可能导致开发困难，因为需求的变化在后期难以实施。

3. 复用和集成支持不足： 瀑布模型较难支持组件的复用和多项开发活动的集成，这在现代软件开发中是一个重要的挑战。

为了解决瀑布模型的这些缺点，近年来出现了多种其他软件开发模型，如螺旋模型、原型模型等，它们更注重灵活性、迭代开发和对需求变化的敏捷响应。这些模型更适应复杂、变化迅速的软件开发环境。

4. 快速原型模型的特点

• 标准定义： 原型是一个可以操作的模型，它实现了目标软件系统的某些重要方面。快速原型模型是通过迅速创建系统的原型来理解用户需求，收集反馈，并在此基础上逐步完善系统。
• 通俗解释： 快速原型模型就像是制作初步模型，让用户提前看到软件的雏形，从而更好地调整和完善需求。
  
  原型的优点

1. 促进用户和软件分析员的学习

• 优势： 原型模型有助于用户和软件分析员双方相互学习对方领域知识。
• 详解： 通过迅速生成可视化的原型，用户可以更直观地了解软件系统的潜在功能和界面。同时，软件分析员能够深入了解用户需求，促进了用户和开发团队之间的沟通与合作。

2. 统一需求的认识和定义

• 优势： 原型模型有助于用户和开发人员统一对软件需求的认识，理解，并促进需求的定义评审。
• 详解： 通过展示原型，用户和开发人员可以更清晰地理解系统的外观和行为。这有助于消除理解上的歧义，确保需求的准确性。在评审过程中，通过原型，团队成员可以更具体地讨论和验证需求，提高了需求定义的质量。

原型模型的这些优点使其成为处理需求不确定性和促进团队合作的有力工具。然而，需要注意的是，在使用原型模型时，及时的用户反馈和有效的沟通是确保成功的关键因素。

5. 螺旋模型的基本思想

• 标准定义： 螺旋模型是一种迭代式的软件开发模型，通过不断迭代来逐步完善软件系统，强调风险管理。
• 通俗解释： 螺旋模型就像是不断螺旋上升的阶梯，每次迭代都是向上攀登一层，同时考虑和解决可能的风险。
  

螺旋模型是一种软件开发模型，结合了瀑布模型和原型模型的优点，并引入了新的成分——风险分析。以下是螺旋模型的组成和特点

模型组成

1. 需求定义：

   • 利用需求分析技术理解应用领域，获取初步的用户需求，制订项目开发计划。

2. 风险分析：

   • 根据初始需求或改进意见评审可选方案，给出消除或减少风险的途径。

3. 工程实现：

   • 利用前面介绍的原型构造方法，针对已知的用户需求生成快速原型。

4. 评审：

   • 将原型提交用户使用并征询用户改进意见。如果用户认为原型可满足需求，则进入运行阶段；否则，开发人员要在用户的密切配合下整理新的用户需求，制订下一步原型进化方案。

模型特点

1. 结合优点：

   • 螺旋模型体现了瀑布模型和原型模型的优点，综合了线性顺序的开发流程和快速迭代的原型构建方法。

2. 增加新成分—风险分析：

   • 螺旋模型引入了风险分析作为一个重要的组成部分。通过在每个迭代中对风险进行分析，可以及早发现和解决潜在问题，提高项目的成功率。

3. 循环迭代：

   • 螺旋模型以螺旋形式循环迭代，每个螺旋圈代表一个开发阶段，同时包括风险分析、原型构建和用户评审。这种迭代的方式有助于适应需求变化和及时处理风险。

螺旋模型通过引入风险分析和迭代开发的方式，提高了项目的适应性和灵活性。它适用于大型、复杂、风险较高的项目，为项目的成功提供了更多的保障。
螺旋模型优点与问题

优点

1. 集成了瀑布模型和原型的优点：

   • 螺旋模型综合了瀑布模型的结构化流程和原型模型的迭代快速开发，兼具两者的优势。

2. 需求分析和软件实现相互依赖、紧密联系：

   • 螺旋模型强调需求分析和软件实现的相互依赖，确保开发过程中对需求的准确理解，并及时调整。

3. 用户参与决策：

   • 原型阶段的用户参与使用户能够参与软件开发的所有关键决策，有助于确保最终软件产品符合用户期望。

4. 形式化的需求说明书：

   • 原型作为形式的可执行的需求说明书，易于用户和开发人员共同理解，同时可作为后续开发的基础，提供清晰的开发方向。

5. 便利的项目管理：

   • 为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。

问题

1. 相对开发周期较长：

   • 螺旋模型相对于其他模型，开发周期较长，过多的迭代次数可能增加开发成本，延迟提交时间。

2. 开发成本较大：

   • 在原型进化过程中，如果不能标识重要的用户需求和关键的改进点，可能导致在人力、财力和时间方面的无谓损耗。

螺旋模型的优点在于其综合了不同模型的优势，但在实际应用中需要根据项目的特点权衡好开发周期和成本的关系。

6. 软件生命周期的概念及划分为哪几个阶段

软件生存周期

软件生存周期 如同普通事物一样，都存在生命周期，即孕育、诞生、成长、成熟和消亡等阶段。软件产品从形成概念开始,经过开发、使用和维护,直到最后退役的全过程。 软件生存周期包括：软件定义、软件开发、软件使用和维护3个部分。
软件生存周期细划为：可行性研究、需求分析、概要设计、详细设计、实现（编码）、测试、使用、维护、退役等几个阶段

1. 可行性研究（Feasibility Study）:

   • 目标：评估项目的可行性，确定是否值得进行。
   • 活动：进行市场调研、技术评估、经济分析等，制定项目可行性报告。

2. 需求分析（Requirements Analysis）:

   • 目标：明确系统的功能和性能需求。
   • 活动：与用户沟通，收集并分析用户需求，编写需求规格说明书。

3. 概要设计（System Design）:

   • 目标：定义系统的整体结构和模块划分。
   • 活动：设计系统的基本框架，确定模块之间的接口，创建概要设计文档。

4. 详细设计（Detailed Design）:

   • 目标：详细说明系统中每个模块的设计。
   • 活动：为每个模块编写详细设计文档，包括算法、数据结构等细节。

5. 实现（编码）（Implementation/Coding）:

   • 目标：将设计转化为实际的可执行代码。
   • 活动：编写、测试和调试代码，创建软件的可执行版本。

6. 测试（Testing）:

   • 目标：验证软件是否满足需求，并发现并修复错误。
   • 活动：执行各种测试，包括单元测试、集成测试和系统测试。

7. 使用（Deployment）:

   • 目标：将软件部署到目标环境中，供用户使用。
   • 活动：安装、配置和启动软件，提供用户培训和支持。

8. 维护（Maintenance）:

   • 目标：保持软件的正常运行，并进行必要的改进。
   • 活动：修复错误、添加新功能、适应环境变化等。

9. 退役（Retirement）:

   • 目标：决定并执行软件的退役策略。
   • 活动：归档数据、通知用户、关闭系统等。

每个阶段都有其独特的任务和活动，而软件的生命周期管理有助于确保软件项目按计划、质量和成本的要求进行。

7. 软件需求的定义

• 标准定义： 软件需求是对系统或系统组件的功能和性能的描述，用户希望系统实现的期望结果。
• 通俗解释： 软件需求就像是用户对软件提出的要求清单，包括软件应该实现的功能和达到的性能水平。

确切地说，软件需求分为三个主要层次，包括业务需求、用户需求和系统需求（其中包括功能和非功能需求）：

1. 业务需求（Business Requirements）:

   • 特点： 反映了组织机构或客户在高层次上对系统或产品的期望和目标。
   • 内容： 强调对业务流程、战略目标、和组织需求的理解。

2. 用户需求（User Requirements）:

   • 特点： 描述了用户在使用产品时需要完成的任务，关注用户的操作和期望。
   • 内容： 着眼于用户体验、交互和对系统行为的期望。

3. 功能需求（Functional Requirements）:

   • 特点： 定义了开发人员必须实现的软件功能，确保用户能够完成其任务。
   • 内容： 关注系统的具体功能，例如用户界面、数据处理、安全性等。

4. 非功能需求（Non-functional Requirements）:

   • 特点： 描述了系统的质量属性和约束，不仅关注功能性方面，还包括性能、可靠性、安全性等方面。
   • 内容： 包括性能要求、安全标准、可用性需求等，影响系统整体的品质和性能。

这三个层次的需求相互关联，业务需求指导用户需求，而用户需求进一步细化为功能和非功能需求，以便开发人员能够明确实现的目标。需求管理的有效性对于确保软件项目按照期望的方式进行至关重要。

8. 常见的软件需求获取技术

初步需求获取是软件开发过程中至关重要的一步，而以下是一些常用的初步需求获取技术：

1. 访谈与会议： 通过与关键利益相关者（如客户、最终用户、业务分析员）进行面对面的访谈和会议，获取他们的见解、期望和需求。这有助于深入了解业务流程和系统期望。

2. 观察用户的工作流程： 观察和分析用户在实际工作环境中的操作和流程，以识别潜在的问题、瓶颈和改进点。这种方法有助于捕捉实际需求和用户体验方面的细节。

3. 建立联合工作小组： 将开发团队成员、最终用户和其他利益相关者组成一个联合工作小组。通过协作和讨论，团队能够共同理解需求，促进信息共享，确保各方的期望得到考虑。

这些技术通常结合使用，以确保从多个角度收集准确和全面的需求。通过有效的初步需求获取，可以建立一个坚实的需求基础，为后续的系统设计和开发工作提供指导。

9. 功能性需求以及非功能性需求，都包含哪些方面

• 功能性需求： 描述系统应该具备的具体功能，比如用户登录、数据导出等。
• 非功能性需求： 描述系统性能和约束，如性能、安全性、可靠性等。

10. 可行性分析的定义

• 标准定义： 可行性分析是对项目进行经济、技术、法律等多方面的评估，以确定项目的可行性和风险。
• 通俗解释： 可行性分析就像是对计划进行全方位的调查和估算，看项目是否可行，值得投入资源。

11. 为了提高软件的可维护性，有哪些编码规范

• 编码规范的重要性： 维护软件的第一步是易读易维护的代码。
• 提高可维护性的编码规范： 注释充分、命名规范、避免代码冗余等。

12. 软件设计的原则

• 设计原则概述： 设计原则是一些通用的准则，帮助设计出结构良好、可维护的软件。
  • 单一责任原则： 一个类应该有且只有一个改变的理由。
  • 开闭原则： 软件实体应该对扩展开放，对修改关闭。

13. 内聚与耦合的概念以及常见的几种内聚与耦合

• 内聚： 指模块内部各部分彼此关联的紧密程度。
  • 顺序内聚： 各部分按照顺序执行。
  • 功能内聚： 各部分共同完成一个功能。
• 耦合： 模块之间相互依赖的程度。
  • 数据耦合： 通过共享数据交互。
  • 控制耦合： 一个模块控制另一个模块。

14. 软件详细设计与软件概要设计概念与主要任务

• 软件详细设计： 具体描述每个模块如何实现的设计阶段。
  • 主要任务： 定义数据结构、算法、接口等详细细节。
• 软件概要设计： 描述整体系统结构和模块之间的关系的设计阶段。
  • 主要任务： 划分系统模块、定义模块间接口。

15. 软件测试的定义

• 标准定义： 软件测试是通过运行程序，检查其行为，以发现潜在的错误或缺陷的过程。
• 通俗解释： 软件测试就像是对软件进行实际运行，看它是否按照预期工作，有没有bug。

16. 白盒测试和黑盒测试的主要思想

• 白盒测试： 基于代码内部结构进行测试，关注程序逻辑和内部路径。
• 黑盒测试： 基于软件功能和用户需求进行测试，忽略内部实现细节。
• 主要思想： 白盒关注内部逻辑，黑盒关注外部行为。

17. 理解用例图及使用

• 用例图定义： 用于描述系统与外部实体（通常是用户）之间的功能关系。
• 使用： 用于可视化和理解系统的功能需求，以及系统与用户之间的互动。

18. 理解数据流图及使用

• 数据流图定义： 表示系统中数据如何流动的图形化工具。
• 使用： 用于理解系统内数据处理过程，辅助设计和分析。

数据流图是一种强调数据流动和处理过程的信息系统建模技术。基于IPO模型（输入-处理-输出模型），软件的功能可被视为对数据进行格式转换的过程，将输入数据转换为输出数据。以下是数据流图建模的本质：

1. 数据传递和变换：

   • 特点： 数据流图主要关注数据在系统中的传递和相应的变换过程。
   • 目的： 揭示数据如何从一个状态流向另一个状态，并通过一系列的转换而发生变化。

2. 自顶而下，逐步求精分解：

   • 特点： 数据流图采用自顶向下的分解方法，从整体到细节逐步分解系统的各个部分。
   • 目的： 通过逐步分解，将复杂的系统问题分解为更易管理和理解的模块，有助于详细地捕捉系统的功能和流程。

3. 信息处理系统的构成：

   • 概念： 信息处理系统由数据流和一系列的转换构成。
   • 作用： 转换定义了系统执行的各项功能，即将输入数据流转换为输出数据流的过程。

通过数据流图，分析人员可以深入了解系统的数据流动，识别重要的转换过程，并确保系统满足用户的需求。这种方法使得软件功能需求得以清晰呈现，为系统设计和开发提供了有力的指导。

19. 理解类图及使用

• 类图定义： 用于表示系统中的类及其之间的关系。
• 使用： 用于面向对象设计，表示类的属性、方法和关系。

# UML类表示领域概念模型

在UML中，通过类来表示概念，而类图则展示了领域概念模型。在需求分析的早期阶段，并不需要一次性列举所有类的属性和方法。最初只需标识类名，随着分析和设计的推进，逐步完善属性列表和方法列表。

## UML类的三个部分：

1. 类名
2. 属性列表
3. 方法列表

图示中表达了元素的形式。

UML类之间的关系主要包括继承、聚合、关联和依赖。继承表示子类重用父类的属性和操作，子类的对象也是父类的对象，有时也称为泛化。

20. 理解类与类之间的关系

• 类之间关系概述： 包括关联、聚合、组合、继承等关系。
• 使用： 用于定义类之间的联系，促进系统的模块化和可维护性。
  类之间的聚合关系模拟了现实世界中的部分—整体关系。
  # UML中的聚集关系

UML将聚集关系分为两种：

1. 普通聚集关系： 一个部件对象可以同时参与多个整体对象。

2. 构成关系： 限定一个部件对象在任意时刻只能参与一个整体类的对象，部件类对象与整体类对象共存亡。
   

# 关联关系

关联关系表示两个类的对象之间存在着用于消息传递的稳定通道。在课程注册管理系统中，例如，“学生”类、“老师”类与“课程设置”类之间存在关联关系，因为“课程设置”与选课学生和授课老师有关，学生和老师需要查询课程设置的相关信息。

通常，两个类的对象之间存在数量对应关系，这是业务规则的具体表现。在分析和设计推进到一定阶段后，应在聚集、构成和关联关系的表示边上明确标示，如表示每个“课程设置”对象应不少于10个、不多于50个选课学生。

# 依赖关系

依赖关系表示依赖类B的对象需要向被依赖类A的对象传递消息，且被依赖类A可作为依赖类B操作的形参类型。依赖关系是临时性的消息传递通道，操作完成后通道消失。

例如，“订单”包中的类仅依赖于“数据库接口”包中的类（接口），不需要建立关联关系。依赖关系是关联关系的弱化，表示被依赖类的变化会影响到依赖类。

依赖的强化是关联，关联的强化是聚合，聚合的强化是构成。

21. 软件设计可分为哪两个阶段

• 阶段划分：
  • 概要设计阶段： 描述整体系统结构和模块关系。
  • 详细设计阶段： 具体描述每个模块的实现细节。

22. 用户界面设计的主要原则

• 主要原则：
  • 一致性： 界面元素应保持一致性，提供一致的用户体验。
  • 可见性： 用户需要的功能和信息应该是可见的。
  • 反馈： 及时、清晰地向用户提供操作反馈。

23. RUP模型

• RUP模型概述： RUP（Rational Unified Process）是一种迭代式软件开发过程。
  • 特点： 强调迭代、用例驱动、面向体系结构。

24. 结构化软件开发的基本思想

• 基本思想： 结构化软件开发采用模块化、自顶向下、逐步求精的方法进行软件设计和开发。
  • 模块化： 将系统划分为相互独立的模块，降低复杂度。

面向数据流的设计方法（SD方法）

面向数据流的设计方法，即结构化设计法（SD方法），在需求阶段通过对数据流的分析生成数据流图和数据字典，以此为基础设计软件结构。

数据流图描述了信息在系统内部加工和流动的情况。该方法根据数据流图的特性定义了两种映射：变换流和事务流。这两种映射能够机械地将数据流图转换为程序结构。

方法的目标是为软件结构设计提供系统的途径，使设计人员能够对软件有一个整体的认识，并通过分析数据流的特性来定义程序结构。

• 结构化方法的缺点

1. 稳定性差：

   • 问题： 结构化分析和设计技术以功能分解为基础，但当用户需求变化时，对系统结构的影响可能是灾难性的。
   • 原因： 系统构造围绕着实现功能的过程，功能的变化可能导致结构的不稳定性。
   • 影响： 变化可能会传递到系统的多个部分，使得系统难以维护和扩展。

2. 可修改性差：

   • 问题： 结构分析和设计技术清晰定义了系统的边界，但这也意味着系统难以在新的边界上进行扩展。
   • 原因： 系统结构依赖于系统边界的定义，扩展系统需要重新考虑和调整边界。
   • 影响： 对于变化或增加新功能的需求，系统可能需要经过较大的修改。

3. 重用性差：

   • 问题： 功能分解的随意性可能导致分解的模块功能不确定，降低了模块的重用性。
   • 原因： 缺乏明确定义的模块功能可能导致相似功能的模块之间存在较大差异。
   • 影响： 难以实现模块级别的重用，因为相似功能的模块可能性较小。

综合而言，这些问题强调了在处理变化、修改和重用时，结构化分析和设计技术可能面临的一些挑战。现代的软件开发方法和架构设计趋向于采用更灵活、模块化且面向对象的方法，以更好地满足不断变化的需求和提高系统的可维护性、可修改性和可重用性。

25. 面向对象软件开发的基本思想

• 基本思想： 面向对象软件开发通过定义和组织对象来进行系统建模和设计。
  • 对象： 封装了数据和方法的实体。
    方法的核心是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制以及用于指导需求分析的面向对象方法学。

面向对象需求分析方法

面向对象(Object-Oriented, 简称OO)的需求分析方法通过提供对象、对象间消息传递等语言机制，让分析人员在解空间中直接模拟问题空间中的对象及其行为，从而削减了语义断层，为需求建模活动提供了直观、自然的语言支持和方法学指导。

为了在解空间模拟现实问题并与人类的思维习惯相一致，OO方法学包容了以下核心概念：

1. 对象

   • 对象是现实世界中个体或事物的抽象表示。
   • 属性表示对象的性质，属性值规定了对象所有可能的状态。
   • 对象的操作是指该对象可以展现的外部服务。

   示例：大型客机可视为对象，具有位置、速度、颜色、容量等属性，可以执行起飞、降落、加速、维修等操作。

2. 类

   • 类表示某些对象在属性和操作方面的共同特征。
   • 共同属性和操作形成类的特征。

   示例：直升飞机、大型客机、轰炸机可归为飞行器类，共同属性包括位置、速度和颜色，共同操作包括起飞、降落、加速和维修。

3. 继承

   • 类之间的继承关系模拟现实世界中的遗传关系。
   • 表示类之间的内在联系以及对属性和操作的共享。

   示例：飞行器、汽车和轮船可归于交通工具类，飞行器类可以继承交通工具类的某些属性和操作。

4. 聚集

   • 描述现实世界中的部分—整体关系。
   • 在OO方法学中表示为类之间的聚集关系。

   示例：飞机由发动机、机身、机械控制系统、电子控制系统等构成。

5. 消息

   • 消息传递是对象与外部世界相互关联的途径。
   • 对象通过发送和接收消息提供服务。

   示例：直升飞机响应轮船的急救信号，执行救援操作。

面向对象 = 对象 + 类 + 继承 + 聚集 + 消息。

26. 在结构化软件开发中，如何获得软件结构

• 软件结构获取： 通过模块化、自顶向下的设计方法，将系统分解为模块，并定义模块之间的关系。

27. 软件维护的类型

• 类型概述：
  • 纠错性维护： 修复软件中的错误。
  • 适应性维护： 适应环境的变化，如操作系统升级。
  • 完善性维护： 添加新的功能。

28. 软件调试与测试的区别

• 区别：
  • 软件调试： 查找和修复代码中的错误。
  • 软件测试： 验证软件是否满足需求，发现潜在错误。

29. 如何度量软件开发工作量

• 度量方法：
  • 功能点分析： 根据系统的功能需求来度量工作量。
  • 行为点分析： 根据用户的交互行为来度量工作量。

30. 理解数据流图中的平衡问题

• 平衡问题解释： 数据流图中各个处理模块的输入与输出应该保持平衡，避免某处数据积压或不足。

31. Java技术栈有哪些内容

• Java技术栈组成：
  • Java SE（标准版）： 基础的Java平台。
  • Java EE（企业版）： 面向企业级应用的Java平台。
  • Spring框架： 提供了全面的企业级支持。

32. 流程图

• 流程图概念： 用图形方式表示流程，展示处理步骤和流程控制。
• 使用： 用于可视化和理解系统、算法或业务流程。

33. 软件测试中的驱动程序和桩程序

• 驱动程序和桩程序定义：
  • 驱动程序： 调用被测模块的程序，提供测试数据。
  • 桩程序： 被测模块调用的模拟程序，提供模拟数据。

34. 白盒测试和黑盒测试用例的生成

• 白盒测试用例生成： 根据代码结构设计测试用例，以覆盖不同路径。
• 黑盒测试用例生成： 根据功能需求设计测试用例，确保系统符合用户期望。

一、阅读下列说明，回答问题 1 至问题 4，将解答填入答题纸的对应栏内。

【说明】
假设你已完成一个四则运算自动生成软件，并提交给用户使用。然而，用户对该软件很不满意，陆续提出新的需求，要求你在原有软件基础上进行扩展。例如，除了整数以外，还要支持真分数的四则运算，例如：1/6+1/8=7/24；程序要求能处理用户的输入，判断对错，累积分数；程序支持可以由用户自行选择加、减、乘、除运算等。
【问题1】什么是软件危机，产生软件危机有哪些原因？
【问题2】软件开发过程中，获取用户的需求很重要。谈谈常见的初步需求获取技术？
【问题3】如果你负责开发该软件，谈谈你准备采用哪种软件开发模型（如，瀑布模型、螺旋模型、原型模型等）并说明理由。
【问题4】描述软件维护的类型及工作内容，说明本案例属于哪种类型软件维护。

问题1：什么是软件危机，产生软件危机有哪些原因？

软件危机指的是在软件开发中出现的一系列问题和挑战，使得软件项目难以按照预定计划和预算完成，导致项目失败或者交付的软件无法满足用户需求。产生软件危机的原因主要包括：

1. 复杂性增加： 软件系统的复杂性随着功能的增加而增加，导致难以理解和维护。

2. 变更需求： 用户对软件需求的频繁变更使得原有的开发计划失效，增加了开发的难度。

3. 技术水平： 在软件开发初期，技术水平相对较低，导致开发过程中出现许多错误，增加了修复的成本。

4. 项目管理： 缺乏有效的项目管理和控制，导致项目进度延误和成本超支。

5. 缺乏标准： 缺乏统一的软件开发标准和规范，导致开发过程中的混乱。

问题2：软件开发过程中，获取用户的需求很重要。谈谈常见的初步需求获取技术？

获取用户需求的技术包括：

1. 面谈： 直接与用户交流，通过问答方式获取用户需求。

2. 问卷调查： 发放问卷收集用户对系统期望和需求的信息。

3. 头脑风暴： 团队成员集体讨论，汇总各种可能的需求。

4. 原型设计： 制作简单的原型，让用户更直观地了解系统，提供反馈。

5. 用户观察： 观察用户在实际操作中的行为，发现他们的需求和问题。

问题3：如果你负责开发该软件，谈谈你准备采用哪种软件开发模型并说明理由？

在这个案例中，可能选择迭代模型。原因如下：

• 用户需求变化： 由于用户陆续提出新的需求，迭代模型允许灵活地进行修改和扩展，适应需求的变化。

• 快速反馈： 每次迭代都可以产生一个可运行的软件版本，用户可以快速看到实际效果，提供反馈，有助于及时调整和改进。

• 降低风险： 通过多次迭代，逐步完善软件，有助于降低项目失败的风险，增强项目的可控性。

问题4：描述软件维护的类型及工作内容，说明本案例属于哪种类型软件维护。

软件维护包括以下类型：

1. 纠错性维护（Corrective Maintenance）： 修复已发现的错误和缺陷，确保软件正常运行。

2. 适应性维护（Adaptive Maintenance）： 针对环境变化（如操作系统升级、硬件更换等）进行调整，以适应新的环境。

3. 完善性维护（Perfective Maintenance）： 对软件进行优化和改进，以提高性能、可维护性和用户体验。

4. 预防性维护（Preventive Maintenance）： 通过识别和修复潜在问题，防止未来可能出现的错误。

在这个案例中，由于用户提出了新的需求，需要对原有的四则运算自动生成软件进行扩展，支持真分数的四则运算等功能。这属于适应性维护，因为需要对软件进行调整以适应新的需求和变化。同时，对用户输入进行判断、累积分数等操作也可能涉及到纠错性维护和完善性维护，确保软件的正确性和性能。

---

二、阅读以下说明,将解答填入答题纸的对应栏内。

问题1：简述面向对象软件开发过程RUP模型。

RUP（Rational Unified Process）模型是一种面向对象的软件开发过程，它强调迭代和增量的开发方式。RUP包含以下几个关键特点：

• 迭代性： 将整个软件开发过程划分为多个迭代，每个迭代都包含系统的部分功能。每次迭代都可以产生一个可执行的软件版本。

• 增量性： 每个迭代都为系统添加新的功能，逐步完善软件。这种增量的方式使得软件在开发过程中逐渐变得更加完善。

• 用例驱动： RUP强调用例驱动的方法，即从用户的角度出发，明确定义系统的功能和行为。

• 体系结构驱动： 强调系统的体系结构设计，确保系统的结构合理、可扩展和易维护。

问题2：什么是用例图，请画出该餐厅点餐系统的用例图。

用例图是一种描述系统功能的图，展示了系统的各个用例（功能）以及它们之间的关系。在这里，我们可以描述一个简单的餐厅点餐系统的用例图：

[图形描述餐厅点餐系统的用例图]

在这个用例图中，可能包括顾客和管理员两个主要角色，以及顾客点菜、查看菜单、结账等用例，管理员管理菜单、查看订单等用例。用例之间的关系可以用关联线表示。

问题3：在面向对象设计中，可以用哪些图描述用例实现过程？至少说明两种图。

在面向对象设计中，可以使用以下两种图描述用例实现过程：

1. 类图（Class Diagram）： 类图表示系统中的类以及它们之间的关系。每个用例通常对应一个类，类中包含了属性和方法，描述了用例的结构和行为。

2. 交互图（Interaction Diagram）： 交互图包括时序图和协作图，用于描述系统中对象之间的交互过程。时序图展示了对象之间消息的顺序，协作图展示了对象之间的协作关系。

问题4：讨论面向对象软件开发方法和结构化软件开发方法之间的区别和联系。

• 区别：

  • 方法论： 面向对象方法强调对象、类、继承等概念，注重对系统进行抽象和建模；而结构化方法则更注重流程、模块、数据流等方面的设计。

  • 复用性： 面向对象方法更注重通过类和对象的复用来提高系统的可维护性和灵活性；结构化方法在复用方面相对较弱。

  • 模块化： 面向对象方法通过类的封装实现了模块化设计，提高了系统的可维护性；结构化方法则通过模块的划分来实现模块化设计。

• 联系：

  • 目标： 都旨在通过良好的设计和开发方法来构建可靠、可维护、可扩展的软件系统。

  • 开发过程： 都采用迭代、逐步完善的开发方式，强调分阶段、模块化的设计。

  • 需求分析： 都注重对用户需求的理解和捕捉，以确保最终系统符合用户期望。

在实际应用中，两种方法往往可以结合使用，即采用面向对象的思想进行系统设计，同时使用结构化方法来实现具体的编码和模块划分。这样的结合可以充分发挥各自的优势，提高软件开发的效率和质量。

三、阅读以下说明和图，将解答填入答题纸的对应栏内。

某医院拟开发病人监控系统。该系统通过各种设备监控病人的生命特征，并在生命特征异常时向医生和护理人员报警。该系统的主要功能如下：
（1）本地监控：定期获取病人的生命特征，如体温、血压、心率等数据。
（2）格式化生命特征：对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征。
（3）检查生命特征：将格式化后的生命特征与生命特征范围文件中预设的正常范围进行比较。如果超出了预设范围，系统就发送一条警告信息给医生和护理人员。
（4）维护生命特征范围：医生在必要时(如，新的研究结果出现时)添加或更新生命特征值的正常范围。
（5）提取报告：在医生或护理人员请求病人生命特征报告时，从日志文件中获取病人生命特征生成特征报告，并返回给请求者。
（6）生成病历：根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。
（7）查询病历：根据医生的病历查询请求，查询病历文件，给医生返回病历报告。
（8）生成治疗意见：根据日志文件中的生命特征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件。
（9）查询治疗意见：医生和护理人员查询治疗意见，据此对病人进行治疗。
现采用结构化方法对病人监控系统进行分析与设计，获得如图3-1所示的顶层数据流图和图3-2所示的1层数据流图。

【问题1】使用说明中的词语，给出图1中的实体E1～E3的名称。
【问题2】使用说明中的词语，给出图2中的数据存储D1～D4的名称。
【问题3】
（1）图2中缺失了4条数据流，使用说明、图3-1和图2中的术语，给出数据流的名称及其起点和终点。
（2）说明实体E1和E3之间可否有数据流，并解释其原因。
【问题5】描述变换型数据流图映射到软件结构的步骤。

图1顶层数据流图

图2 1层数据流图

问题1：使用说明中的词语，给出图1中的实体E1～E3的名称。

• E1： 病人监控系统
• E2： 医生
• E3： 护理人员

问题2：使用说明中的词语，给出图2中的数据存储D1～D4的名称。

• D1： 生命特征数据文件
• D2： 生命特征范围文件
• D3： 日志文件
• D4： 病历文件

问题3：

(1) 图2中缺失了4条数据流，使用说明、图3-1和图2中的术语，给出数据流的名称及其起点和终点。

• 数据流1： 生命特征数据（起点：病人监控系统，终点：生命特征数据文件）
• 数据流2： 生命特征范围（起点：病人监控系统，终点：生命特征范围文件）
• 数据流3： 报告请求（起点：医生/护理人员，终点：病人监控系统）
• 数据流4： 病历查询请求（起点：医生，终点：病人监控系统）

(2) 说明实体E1和E3之间可否有数据流，并解释其原因。

在图2中，E1（病人监控系统）和E3（护理人员）之间没有直接的数据流。这是因为护理人员通过报告请求（数据流3）与系统进行交互，而不是直接与病人监控系统通信。系统负责处理这些请求并向护理人员提供相应的报告。

问题5：描述变换型数据流图映射到软件结构的步骤。

1. 识别加工（Processes）： 从数据流图中识别出所有的加工，这些加工将映射到软件中的模块或函数。

2. 识别数据存储（Data Stores）： 识别出数据流图中的数据存储，这些数据存储将映射到数据库或文件系统。

3. 识别数据流（Data Flows）： 识别出数据流，这些数据流表示信息在系统中的流动。它们将映射到函数调用或模块之间的数据传递。

4. 确定外部实体（External Entities）： 识别外部实体，这些外部实体表示系统之外的实体，如用户或其他系统。它们将映射到系统与外部环境的接口。

5. 绘制结构图（Structure Chart）： 根据识别出的加工、数据存储、数据流和外部实体，绘制结构图，该图表示软件系统的结构和模块之间的关系。

6. 明确接口和数据传递： 在结构图中明确每个模块的接口和数据传递方式，确保系统各部分之间的协同工作。

7. 验证与调整： 验证结构图的合理性，并根据需要进行调整，确保系统结构满足设计要求和性能要求。

---

四、 阅读以下说明,回答问题,将解答填入答题纸的对应栏内。

【说明】
For years, programmers in industry have claimed that by working collaboratively, they have produced higher-quality software products in shorter amounts of time. But their evidence was anecdotal and subjective: “It works” or “It feels right.” To validate these claims, we have gathered quantitative evidence showing that pair programming—two programmers working side by side at one computer on the same design, algorithm, code, or test—does indeed improve software quality and reduce time to market. Additionally, student and professional programmers consistently find pair programming more enjoyable than working alone.
Yet most who have not tried and tested pair programming reject the idea as a redundant, wasteful use of programming resources:“Why would I put two people on a job that just one can do? I can’t afford to do that!” But we have found, as Larry Constantine wrote, that Two programmers in tandem is not redundancy; it’s a direct route to greater efficiency and better quality.”
【问题 1】什么是结对编程（pairwise programming）？
【问题 2】结对编程存在什么优缺点？
【问题 3】结合文中对结对编程的讨论，谈谈个人软件开发流程和团队开发流程？

问题1：什么是结对编程（pairwise programming）？

**结对编程（Pair Programming）**是一种软件开发实践，两名程序员共同在同一台计算机上合作完成设计、算法、编码或测试等任务。在结对编程中，一位程序员是“驾驶员”（Driver），负责具体的实际编码工作，而另一位程序员是“观察员”（Observer）或“导航员”（Navigator），负责审查代码、提出建议和思考更高层次的设计问题。这两名程序员经常交换角色，以保持合作的平衡。

问题2：结对编程存在什么优缺点？

优点：

1. 提高软件质量： 结对编程有助于发现和纠正错误，减少缺陷数量，提高代码质量。
2. 减少上线后的问题： 由于代码经过双重审查，减少了上线后需要修复的问题。
3. 知识共享： 结对编程促使团队成员之间共享知识，减少信息孤岛。
4. 加速学习： 初学者通过与经验丰富的开发者结对编程，可以更快速地学习和提高技能。

缺点：

1. 资源消耗： 需要投入两名程序员的时间和精力，有可能导致看似效率低下。
2. 沟通成本： 如果合作关系不好或沟通不畅，可能导致结对编程效果不佳。
3. 适应性差： 不是所有任务和所有人都适合结对编程，有些开发者可能更喜欢独立工作。

问题3：结合文中对结对编程的讨论，谈谈个人软件开发流程和团队开发流程？

个人软件开发流程：

• 独立工作： 个人软件开发者通常会独自完成整个软件开发过程，包括需求分析、设计、编码、测试和维护。
• 自主决策： 开发者独立做出技术和设计决策，灵活性高，但容易出现独立思考的盲点。

团队开发流程：

• 结对编程： 在团队中，采用结对编程的方式可以提高代码质量，减少错误，加速学习，促进团队协作。
• 协作和沟通： 团队成员需要良好的沟通和协作，通过代码审查、迭代开发等方式共同推动项目进展。
• 知识共享： 团队内部需要实现知识的共享，避免信息孤岛，确保每个成员都了解项目的整体架构和设计。

在实践中，个人软件开发者可能更注重独立性和自主决策，而团队开发流程则更强调协作、沟通和共享。在团队中，可以根据项目的性质和团队成员的特点选择适当的开发方法，有时候也可以结合个人的独立工作和团队的协作方式，以达到最佳的开发效果。

五、根据以下 Java 代码片段绘制对应的 UML 类图模型。

public class Animal {
public void move(){}
}
public interface ICanEat {
public void eat();
}
public class Dog extends Animal implements ICanEat {
public void eat() { }
public void bark(){}
}

根据提供的 Java 代码片段，可以绘制如下的 UML 类图模型：

+-------------------+          +-----------------+          +----------------+
|      Animal       |          |    ICanEat      |          |      Dog       |
+-------------------+          +-----------------+          +----------------+
|                   |          |                 |          |                |
|                   |          |                 |          |                |
| + move()          |          | + eat()         |          | + eat()        |
|                   |          |                 |          | + bark()       |
+-------------------+          +-----------------+          +----------------+

在这个 UML 类图中：

• Animal 类具有一个方法 move()。
• ICanEat 接口具有一个方法 eat()。
• Dog 类继承自 Animal 类，同时实现了 ICanEat 接口。它具有 move() 方法（来自继承）和 eat() 方法（来自接口实现），以及自己独有的 bark() 方法。

关系说明：

• 继承关系用实线箭头表示。
• 接口实现关系用虚线箭头表示。
  以下是根据提供的 Java 代码片段生成的简单 UML 类图模型：

@startuml
class Animal {+move()
}interface ICanEat {+eat()
}class Dog {+eat()+bark()
}Animal <|-- Dog
ICanEat <|.. Dog
@enduml

这个UML类图表示了Animal类、ICanEat接口和Dog类之间的关系。类之间的箭头表示继承关系或实现关系。Animal类是一个基类，Dog类继承了Animal类并实现了ICanEat接口。

这段代码是使用PlantUML语言编写的，用于生成UML用例图，表示旅游景区指南系统的参与者和用例关系。你可以按照以下步骤将其用于生成UML图：

1. 在线编辑器： 使用在线PlantUML编辑器，如PlantText或PlantUML Editor。将代码粘贴到编辑器中，然后它会为您生成UML图。

2. 本地环境： 如果你想在本地生成图，需要安装PlantUML，并使用文本编辑器创建一个包含这段代码的文件。然后，在命令行中运行PlantUML来生成图。

   • 安装： 从官方网站下载PlantUML，并按照说明安装。

   • 命令行： 安装完成后，在命令行中运行PlantUML，例如：

     plantuml yourfile.uml
     

     将yourfile.uml替换为实际的文件名。

   • 查看图： 运行命令后，它将生成一个图像文件（例如PNG）。使用图像查看器打开图像文件以查看UML图。

六、请根据以下材料描述，完成问题解答。

旅游景区指南系统基于 Spring Boot 框架和 Vue.js 框架实现了景区指南信息的浏览和发布。使用该系统的角色有未授权用户、已授权用户、后台管理员。允许未授权用户使用系统进行注册账户、浏览景点介绍、浏览景点评论、搜索景区；已授权用户除了具有浏览景点介绍、浏览景点评论、搜索景区、功能权限外，还能够登录系统、发表景点评论、订购门票。已授权用户订购门票时，借助微信系统支付订单。后台管理员是已授权用户，可以管理用户信息、管理景区信息、管理景点信息等。
1）请分析旅游景区指南系统中的系统参与者有哪些？
2）分析不同参与者关联的用例，并根据分析结果绘制出旅游景区指南系统的 UML 用例图。

1）系统参与者：

• 未授权用户
• 已授权用户
• 后台管理员

2）关联用例分析及 UML 用例图：

• 未授权用户：

  • 注册账户
  • 浏览景点介绍
  • 浏览景点评论
  • 搜索景区

• 已授权用户：

  • 登录系统
  • 发表景点评论
  • 订购门票
  • 浏览景点介绍
  • 浏览景点评论
  • 搜索景区

• 后台管理员：

  • 管理用户信息
  • 管理景区信息
  • 管理景点信息

UML 用例图：

+------------------------+        +------------------------+       +------------------------+
|   Unauthorized User   |         |     Authorized User    |       |  Back-End Administrator|
|------------------------|        |------------------------|       |------------------------|
| + RegisterAccount()    |        | + Login()              |       | + ManageUserInfo()     |
| + BrowseSpotIntro()    |        | + PostComment()        |       | + ManageScenicInfo()   |
| + BrowseSpotComments() |--------| + OrderTicket()        |       | + ManageSpotInfo()     |
| + SearchScenic()       |        | + BrowseSpotIntro()    |       +------------------------+
+------------------------+        | + BrowseSpotComments() || + SearchScenic()       |+------------------------+

这是一个简化的 UML 用例图，未画出具体的关系线。关系线通常包括关联关系（association）、继承关系（inheritance）、包含关系（include）等。根据系统的实际需求，可以在用例图中添加适当的关系以更准确地表达参与者和用例之间的关系。

用例图的关联如下：

• 未授权用户：注册账户、浏览景点介绍、浏览景点评论、搜索景区。
• 已授权用户：登录系统、发表景点评论、订购门票（包括微信支付）、浏览景点介绍、浏览景点评论、搜索景区。
• 后台管理员：管理用户信息、管理景区信息、管理景点信息。

UML 用例图示例：

@startuml
left to right direction
actor "未授权用户" as UnauthorizedUser
actor "已授权用户" as AuthorizedUser
actor "后台管理员" as Adminrectangle "旅游景区指南系统" {UnauthorizedUser --|> (注册账户)UnauthorizedUser --|> (浏览景点介绍)UnauthorizedUser --|> (浏览景点评论)UnauthorizedUser --|> (搜索景区)AuthorizedUser --|> (登录系统)AuthorizedUser --|> (发表景点评论)AuthorizedUser --|> (订购门票)AuthorizedUser --|> (浏览景点介绍)AuthorizedUser --|> (浏览景点评论)AuthorizedUser --|> (搜索景区)Admin --|> (管理用户信息)Admin --|> (管理景区信息)Admin --|> (管理景点信息)
}
@enduml

这个用例图简要展示了系统的参与者及其关联的用例。

这段代码是使用PlantUML语言编写的，用于生成UML用例图，表示旅游景区指南系统的参与者和用例关系。你可以按照以下步骤将其用于生成UML图：

1. 在线编辑器： 使用在线PlantUML编辑器，如PlantText或PlantUML Editor。将代码粘贴到编辑器中，然后它会为您生成UML图。

2. 本地环境： 如果你想在本地生成图，需要安装PlantUML，并使用文本编辑器创建一个包含这段代码的文件。然后，在命令行中运行PlantUML来生成图。

   • 安装： 从官方网站下载PlantUML，并按照说明安装。

   • 命令行： 安装完成后，在命令行中运行PlantUML，例如：

     plantuml yourfile.uml
     

     将yourfile.uml替换为实际的文件名。

   • 查看图： 运行命令后，它将生成一个图像文件（例如PNG）。使用图像查看器打开图像文件以查看UML图。

测试题及答案：

1. 某图书管理系统的功能如下：
   ①读者登录系统后，可以查询信息、预约图书和续借图书；
   ②图书管理员登录系统后，可以查询信息、管理读者信息和图书信息以及进行借书和还书的操作；
   ③读者还书时，如果超过预期时间，则图书管理员要按照图书馆规定对读者进行罚款；
   ④后台管理员登录系统后可以维护系统
   请分析需求并回答以下问题：
   （1）请分析需求中的系统参与者有哪些？
   （2）根据第（1）题的分析结果，进一步分析和每个参与者关联的系统用例。
   （3）使用UML用例图可视化第（1）题和第（2）题的分析结果。
   参考答案：
   （1）读者、图书管理员和管理员；
   （2）读者：登录、预约图书、续借图书、信息查询；
   图书管理员：登录、信息查询、读者信息管理、图书信息管理；
   管理员：登录、系统维护
   （3）用例图参考图如下：
   

2. 某医院拟开发一个分布式患者监护系统（PMS: Patients Monitoring System）。PMS将用于监视病房中每个患者的重要生理信号（如体温、血压、脉博信号等），并能定时更新和营理患者的病历。此外，当患者的生理信号超过医生规定的安全范围时，系统能立即通知护理人员，并且护理人员在需要时可随时通过系统产生某患者有关报告。
   PMS的主要功能为：
   ① 通过一个病床监视器实现本地监测，以获得患者的生理信号。
   ② 在护士办公室实现中央监测
   ③ 更新和管理患者病历
   ④ 产生患者情况的报告以及报警信息
   问题：
   （1）请分析PMS的数据源点和数据终点分别是什么？
   （2）根据需求描述，PMS可以分解成哪几个数据加工？
   （3）根据第（1）题和第（2）题的分析结果，绘制1层数据流图。
   参考答案：
   （1）PMS的数据源是患者和护士；数据终点是护士；
   （2）PMS可以分为本地监测、中央监测、产生报告和记录患者生理数据四个数据加工
   （3）1层数据流图参考图如下：