软件工程理论与实践刘小峰习题答案

软件工程理论与实践刘小峰习题答案第1章导论一、思考题1.不属于软件构成内容的是：考勤记录表。

软件构成主要指与软件开发、部署、运行直接相关的技术性制品。源码、构建脚本等均是软件生命周期的核心产出。考勤记录表属于人力资源管理范畴，用于记录员工出勤，与软件本身的功能、结构或交付物无直接关系，因此不属于软件构成内容。2.软件的其它显著特点及其影响：

特点包括高复杂性和易变性。高复杂性源于大量交互逻辑，要求开发中必须采用模块化、抽象等方法管理。易变性指需求、环境易变，导致软件需持续演化，这对项目管理、版本控制和维护提出了更高要求，增加了开发和管理的难度与成本。3.软件开发生产与飞机、运动鞋生产的区别：

生产上，软件是纯逻辑设计，无物理制造环节，复制成本近乎为零；后两者是物理实体，受原材料和生产线制约。使用上，软件不会物理磨损，但会因环境变化或需求变更而“老化”（过时）；飞机和运动鞋会因物理磨损而性能下降直至报废。4.软件更改为何会引入新问题：

软件各部分之间存在复杂的、不可见的逻辑耦合。修改一处可能产生“涟漪效应”，意外影响其他看似无关的模块。由于测试难以覆盖所有可能的执行路径和交互场景，这些隐含的缺陷就可能成为新的问题，导致“修复一个Bug，产生两个新Bug”的现象。5.许多通用软件最初都是定制软件，例如AdobePhotoshop，最初是苹果公司内部定制开发的；IBM的DB2数据库，早期也是为特定大型机系统定制的，后来才演变为通用产品。6.其它应用领域的软件类型：

除了书中类型，还有区块链软件（如比特币核心客户端）、边缘计算软件（在终端设备上处理数据的轻量级系统）、量子计算软件（用于控制和编程量子计算机），以及数字孪生软件（创建物理实体的虚拟映射进行仿真分析）。7.交互式事务处理应用的具体例子：网上银行转账：用户提交请求，系统即时处理并返回结果。电商平台下单：用户点击购买，系统实时检查库存、锁定商品、生成订单。机票预订系统：用户查询、选择航班并支付，系统实时更新座位信息。8.游戏开发中软件开发与艺术创作的关系：

是紧密协作、相互依存的伙伴关系。艺术家创作视觉、音频资源，程序员编写代码实现其展示和交互。程序员为艺术家提供工具和引擎，艺术家则通过资源赋予程序以生命和美感。双方需持续沟通，确保技术实现与艺术愿景的统一。9.银行业务中批处理软件的使用场景：

主要用于非实时、大批量的后台业务处理。例如：每日结束后的利息计算。生成并打印大批量的客户对账单。夜间进行的批量资金清算和结算。10.软件工程与计算机科学的区别和联系：

区别：计算机科学侧重于计算理论和基础（如算法、数据结构），是理论学科。软件工程侧重于系统化、规范化、可量化的方法进行软件的开发、部署和维护，是应用学科。

联系：软件工程以计算机科学的理论为基础，将其应用于解决实际、复杂的工程问题，并关注成本、进度和质量。11.非专业化软件开发的具体表现：

*

缺乏规范流程：无计划、无设计、无文档的“三无”开发。*

个人英雄主义：依赖个别高手，知识未团队化。*

忽视质量活动：缺少系统测试、代码审查。*

工具使用随意：无版本控制，手动部署。12.软件工程中各阶段工具的具体名称：

*

项目管理：Jira,MicrosoftProject*

设计建模：EnterpriseArchitect,Draw.io*

版本控制：Git,SVN*

持续集成：Jenkins,GitLabCI*

测试：Selenium,JUnit*

部署运维：Docker,Kubernetes13.保证软件质量需要规章制度的原因：

规章制度将良好的实践（如代码审查、测试流程）固化为强制性的、可重复的行为准则。它减少了个人随意性带来的质量波动，确保团队遵循统一标准，使过程可控、结果可预测。没有制度，依赖个人自觉，质量难以在长期和团队范围内保持稳定。14.不理解问题的其它表现：

除了立即开始编码，还包括：无法清晰描述问题边界和目标；提出的解决方案模糊或存在逻辑漏洞；忽视非功能性需求（如性能、安全）；频繁、大幅地变更需求或设计，而非渐进式细化。这些表现都说明对问题本质和范围缺乏深刻理解。15.事先计划可以低成本验证、提高质量和降低风险的原因：

计划阶段（如设计、建模）的修改成本远低于编码甚至上线后的修改成本。在纸上或模型中就能发现架构缺陷、逻辑错误和需求矛盾，此时修正代价极小。这相当于在蓝图阶段排除隐患，避免了后期昂贵的返工，从而系统性提高了最终产品的质量并降低了项目风险。16.编码结果检查的方法及不检查的后果：

方法：代码审查（同行检查逻辑）、单元测试（验证函数级正确性）、集成测试（检查模块间交互）、静态代码分析（工具扫描潜在缺陷）。

不检查的后果：缺陷会累积并流入后续阶段，导致后期修复成本指数级增长（“破窗效应”），软件质量低下，可靠性差，最终可能致使项目延期、超支甚至失败。二、项目题项目题1一、软件危机的内涵与历史回响“软件危机”的概念在1968年北约科学委员会的一次会议上被首次提出。当时，计算机硬件正遵循“摩尔定律”飞速发展，而软件开发却仍被视为一门“手工艺”，严重依赖个人英雄主义，导致了一系列触目惊心的问题：项目严重超支与延期：如OS/360操作系统开发，耗时数千人年，严重超出预算和计划，成为弗雷德里克·布鲁克斯在《人月神话》中剖析的经典案例。软件质量低劣：软件充满了错误（Bug），不可靠，极易崩溃，甚至引发严重事故。产品不符合用户期望：开发出的软件与用户的真实需求南辕北辙，用户满意度极低。代码难以维护和演化：软件缺乏良好的结构和文档，宛如“意大利面条式代码”，使得修复错误和添加新功能举步维艰，维护成本高昂。项目管理失控：缺乏可视化的进度和有效的风险管理，项目成功率极低。这些现象的核心，是软件固有的复杂性、不可见性与易变性与落后的开发管理模式之间的巨大鸿沟。二、软件危机的深层原因剖析软件危机的产生是多重因素叠加的结果，可以归结为技术、管理和认知三个层面。1.技术层面：本质的复杂性逻辑结构的复杂性：软件是纯粹的逻辑构造体，其复杂度随着代码行数和交互路径的增加呈指数级增长，远超任何人脑能完全掌控的范畴。不可见性与抽象性：软件没有物理形态，其结构和行为必须通过抽象的模型（如UML图）来表征，这导致了沟通和理解的巨大困难。2.管理层面：过程的盲目性不切实际的估算：基于不完整信息和乐观假设进行估算（“规划谬误”），忽略了对未知工作的考量，导致预算和时间表从一开始就存在缺陷。低效的沟通与协作：在大型团队中，信息在传递过程中失真、丢失，导致开发方向偏离。缺乏透明的进度跟踪机制，使得问题在后期才暴露。3.认知与需求层面：永恒的挑战需求的不确定性与易变性：用户往往在看到具体软件之前无法精确描述自己的需求（“我看到了才知道我想要什么”）。同时，业务环境和市场也在不断变化，导致需求在整个开发周期中持续漂移。人固有的局限性：开发人员存在认知偏差，对技术难度过度自信，测试时倾向于证实而非证伪自己的代码。知识在团队中分布不均，形成“知识孤岛”。三、现代软件工程的应对之道：降低危机概率的实践体系经过数十年的探索，软件行业已经形成了一套相对成熟的理论与实践体系，极大地降低了软件危机爆发的概率和影响。这些方法相互交织，共同构成了现代软件开发的基石。1.过程与方法论的革命：从预测到适应敏捷开发与Scrum/XP：这是应对需求不确定性的核心武器。通过短周期的迭代、持续的用户反馈和拥抱变化，敏捷将开发从一个“预测性”活动转变为“适应性”活动。Scrum提供了轻量级的项目管理框架，而极限编程（XP）的实践如测试驱动开发（TDD）、持续集成（CI）

和结对编程，则从工程实践上保障了每次迭代的质量。DevOps与持续交付：打破了开发（Dev）与运维（Ops）之间的壁垒，通过高度自动化（CI/CD流水线）实现软件的快速、频繁、可靠地发布。这极大地缩短了反馈循环，使得问题能尽早被发现和修复，降低了发布风险。2.工程实践的精进：构筑质量的防线版本控制（Git）：已成为软件开发的标准配置，不仅管理代码版本，更是团队协作和追溯历史的基石。自动化测试金字塔：从底层的单元测试（快速、大量）、到集成测试（验证模块间交互）、再到顶层的端到端测试（模拟用户行为），构成了一个稳健的质量保障体系。自动化确保了回归的可靠性。代码审查与静态分析：通过同行评审（如PullRequest）和自动化工具（如SonarQube）来捕捉潜在缺陷、保证代码规范、传播知识，是提升代码质量的有效手段。3.管理与协作的进化：可视化与赋能精益与看板方法：通过可视化工作流（看板）、限制在制品（WIP）数量，聚焦于流动效率，识别并消除瓶颈，使过程更加透明和可预测。用户故事与产品待办列表：用“作为[角色]，我想要[完成某事]，以便[实现某个价值]”的格式来描述需求，将焦点从冰冷的“功能”转移到为用户创造“价值”上。跨职能团队：组建包含产品经理、设计师、开发、测试、运维等角色的完整团队，减少交接等待，提升决策和交付效率。项目题21.项目管理与协作工具这类工具用于规划项目进度、分配任务、跟踪工作项和管理团队协作。关键功能特性：任务/工作项管理：创建、分配、排序和跟踪任务（如用户故事、缺陷）。迭代与版本规划：支持敏捷开发的冲刺规划和发布规划。可视化工作流：通过看板或Scrum板可视化任务状态。进度跟踪与报告：生成燃尽图、累积流图等图表，量化工作进度。协作功能：集成文档、评论、@提及等功能。主要工具介绍：Jira：介绍：由Atlassian开发，是业界最流行的敏捷项目管理工具之一。特性：高度可定制的工作流、问题类型和字段；强大的搜索（JQL）和报告功能；与Confluence、Bitbucket等Atlassian全家桶产品无缝集成；支持Scrum、看板等多种敏捷方法论。Trello：介绍：基于看板方法的轻量级、可视化的协作工具。特性：极其直观的“卡片-列表-看板”模型；适合小型团队或简单项目；通过“Power-Ups”可以扩展功能（如日历、投票、自动化）；学习成本低，上手快。2.需求分析与设计工具用于创建、可视化、管理和分析软件需求与系统设计模型。关键功能特性：建模支持：支持UML（统一建模语言）、BPMN（业务流程模型与符号）等标准建模语言。需求管理：建立需求池，跟踪需求状态，管理需求变更和追踪关系。原型设计：快速创建交互式用户界面原型。数据库建模：可视化地设计数据库概念模型、逻辑模型和物理模型。主要工具介绍：EnterpriseArchitect：介绍：一款功能全面的基于UML的视觉建模和设计工具。特性：支持从需求分析到系统设计、测试和维护的全生命周期；提供丰富的模型类型（架构、软件、业务过程）；支持代码工程（正向/逆向生成代码）；强大的文档生成能力。Figma：介绍：一款基于浏览器的协作式UI/UX设计工具，已成为行业标准。特性：实时协作，多名设计师可同时编辑同一文件；强大的组件和样式库，支持设计系统管理；无缝的原型交互设计功能；丰富的插件生态系统。3.设计与开发工具这是开发人员编写、构建和调试代码的核心环境。关键功能特性：代码编辑与智能感知：语法高亮、代码自动补全、参数提示。集成调试器：设置断点、单步执行、检查变量。版本控制集成：与Git等版本控制系统深度集成。插件生态系统：通过插件支持各种语言、框架和功能扩展。主要工具介绍：VisualStudioCode：介绍：微软开发的免费、开源、轻量级但功能强大的源代码编辑器。特性：启动速度快，资源占用低；拥有极其庞大的扩展市场，几乎支持所有编程语言；内置终端、Git操作和调试支持；可通过设置和快捷键高度自定义。IntelliJIDEA：介绍：JetBrains公司推出的强大的Java集成开发环境。特性：以其“智能”著称，提供远超普通补全的代码洞察和重构能力；开箱即用，对Java、Spring等生态支持极佳；同时通过插件支持其他语言（如Python,SQL,JavaScript）。4.版本控制与代码仓库工具用于管理源代码的版本历史，支持团队并行开发和代码备份。关键功能特性：版本记录：记录每一次代码变更的内容、作者和时间。分支与合并：支持创建分支进行特性开发或Bug修复，并能将更改合并回主线。协作与代码审查：通过PullRequest或MergeRequest机制进行代码审查。备份与恢复：完整保存项目历史，可回退到任意历史版本。主要工具介绍：Git：介绍：一个开源的分布式版本控制系统，是现代软件开发的基石。特性：分布式，每个开发者都拥有完整的代码仓库历史，支持离线工作；分支模型轻量高效，鼓励频繁创建和合并分支；性能优异，处理大型项目速度快。GitHub/GitLab：介绍：两者都是基于Git的代码托管平台，提供了远超版本控制本身的协作功能。特性：GitHub：全球最大的开源社区，以其强大的PullRequest和社交化编码功能闻名。提供Actions实现CI/CD。GitLab：提供一体化的DevOps平台，内置了从项目管理、代码仓库到CI/CD、监控的全套功能，尤其适合企业内私有部署。5.构建与持续集成/持续部署工具用于自动化地编译、测试、打包和部署软件。关键功能特性：自动化构建：自动从版本库拉取代码，执行编译、打包等任务。自动化测试：触发并运行自动化测试套件。持续集成：频繁地将代码集成到主干，并立即进行验证。持续部署/交付：自动化地将通过验证的软件部署到测试或生产环境。主要工具介绍：Jenkins：介绍：一款开源的、功能极其强大的自动化服务器，是CI/CD领域的先驱。特性：高度可扩展，拥有超过1800个插件支持几乎所有工具链；支持通过“PipelineasCode”使用Groovy脚本定义复杂的构建流水线；可以分布式部署，跨平台运行。GitLabCI/CD：介绍：GitLab平台内置的持续集成/部署工具。特性：与GitLab代码仓库无缝集成，配置简单；使用项目根目录的.gitlab-ci.yml文件定义流水线，版本化管理；提供集成的制品仓库和环境管理功能。6.测试工具用于自动化执行各种测试，以确保软件质量。关键功能特性：单元测试：对软件中的最小可测试单元（如函数、类）进行测试。集成/API测试：测试模块间接口或API的正确性。端到端测试：模拟真实用户操作，测试整个应用流程。性能/负载测试：测试系统在高负载下的性能表现。主要工具介绍：Selenium：介绍：用于Web应用程序自动化测试的便携式框架。特性：支持多种浏览器和操作系统；允许用多种编程语言（Java,Python,C#等）编写测试脚本；通过SeleniumGrid实现分布式测试。Postman：介绍：一个用于API开发和测试的协作平台。特性：提供友好的图形界面用于构建、发送HTTP/API请求；支持自动化测试脚本（JavaScript）和参数化；可以生成API文档，并与团队共享集合。7.部署与运维工具用于将软件部署到服务器，并管理其运行状态。关键功能特性：容器化：将应用及其依赖打包成一个标准化的、轻量级的、可移植的容器镜像。编排与调度：自动化地部署、管理、扩展和修复容器化应用。基础设施即代码：使用代码和配置文件来管理和配置计算、网络、存储资源。主要工具介绍：Docker：介绍：是应用最为广泛的容器化平台。特性：实现了“一次构建，处处运行”，消除了环境差异问题；容器启动秒级，资源利用率高；Docker镜像通过Dockerfile定义，易于版本化和共享。Kubernetes：介绍：源于Google的开源容器编排系统，已成为云原生时代的“操作系统”。特性：提供服务发现与负载均衡、自动部署和回滚、自我修复（重启失败的容器）、水平扩缩容和密钥与配置管理等核心功能，管理大规模分布式容器应用。8.监控与可观测性工具用于收集、分析和可视化软件系统在生产环境中的运行数据。关键功特性：指标监控：收集并可视化CPU、内存、请求量、延迟等时间序列数据。日志聚合：集中收集、存储和搜索来自所有服务的日志。链路追踪：追踪一个请求穿过多个分布式服务的完整路径，用于性能分析和故障定位。主要工具介绍：Prometheus+Grafana：介绍：这是一个经典的组合。Prometheus负责收集和存储指标数据，Grafana负责数据的可视化。特性：Prometheus采用拉取模型，具有强大的多维数据模型和查询语言（PromQL）。Grafana拥有丰富的仪表盘和图表类型，可以对接多种数据源。ELK/ElasticStack：介绍：由Elasticsearch,Logstash,Kibana三部分组成的技术栈，主要用于日志处理。特性：Logstash负责日志的收集、解析和转发；Elasticsearch是一个分布式搜索和分析引擎，负责存储和索引数据；Kibana则为Elasticsearch提供可视化的Web界面。软件过程思考题1.软件过程工程组人员的素质和能力

应具备扎实的软件工程知识、过程建模与改进能力、出色的沟通协调能力以及分析和解决问题的能力。他们需要理解组织目标，能够推动变革，并具备严谨和系统化的思维，以有效定义、维护和改进组织级的软件过程。2.软件过程作为机构能力的体现

稳定、定义的软件过程意味着机构能够系统化、可预测地管理开发，而非依赖个人英雄主义。它体现了组织的知识积累、项目管理成熟度和质量控制能力，是交付高质量软件、控制成本与进度的基础，直接决定了其承接复杂项目的能力。3.图2.2将分析建模和设计建模合并在一个高层活动中，将实现和验证合并在构建中，没有显式包括软件进化，但显式包括软件部署活动。4.软件生命周期中的其他沟通

还包括：团队内部日常沟通（同步进度、解决技术问题）、与项目经理的汇报沟通（确保项目可控）、与测试/运维人员的协作沟通（保证质量与可部署性）。目的是确保信息流畅、协调一致、风险早暴露、项目顺利推进。5.基本方法步骤与框架活动的对应

“问题定义”对应“沟通”，“需求分析/规划”对应“策划”与部分“建模”，“构建实现”对应“构建”（编码与测试），“部署维护”对应“部署”与“进化”。框架活动是基本步骤在工程实践中的具体和扩展。6.建模需要多角度的原因

因为复杂系统单一视角无法展现全貌。多角度建模（如功能、结构、行为视角）能分离关注点，降低复杂度，确保对系统不同方面（数据、控制流、交互等）的全面理解与验证，避免设计盲点，满足不同干系人的关注需求。7.软件部署后的反馈情形

包括：程序错误（Bug）报告、性能瓶颈反馈、易用性改进建议、新功能需求、安全漏洞报告、以及用户使用数据和行为的分析。这些反馈是软件进化和持续改进的直接输入。8.支撑活动是可有可无吗？为什么？

不是。支撑活动（如项目管理、质量保证、配置管理、风险管理）是框架活动顺利实施的保障。缺乏它们会导致项目失控、质量低下、版本混乱、风险累积，最终即使编码完成，项目也可能因管理或质量失败。9.计划驱动过程利于大型分布式团队的原因

因其预先定义了清晰的流程、接口、标准和里程碑，为所有子团队提供了统一的工作框架和协调依据。这减少了沟通开销和误解，确保了不同地点团队产出物的兼容性与集成性，使大规模协作成为可能。10.计划驱动过程可运行软件晚交付的风险

风险在于：用户需求可能已发生变化，导致最终产品不适用；市场机会可能已丧失；在开发后期才发现重大缺陷，修复成本极高；项目投资长期无法获得回报。本质上是对不确定性的适应能力差。11.敏捷过程管理大型分布式团队的挑战

敏捷依赖频繁、紧密的面对面沟通和协作。大型分布式团队存在时空隔阂、文化差异和沟通障碍，使得构建高信任度、自组织的团队变得困难，信息流动不畅，从而削弱了敏捷核心的优势。12.飞机飞行控制系统的开发过程选择

应采用计划驱动过程。因为该系统对可靠性、安全性和可预测性要求极高，需求明确且稳定。需要严格的计划、详尽的文档、全面的验证和认证，这些是计划驱动的强项，而敏捷的变更包容性在此领域风险过大。13.敏捷项目合同谈判的建议

建议采用“时间与材料”合同或固定价格但固定范围可变（如按迭代调整优先级）的灵活合同。合同应侧重于定义合作原则、验收标准和高层目标，而非僵化的固定需求清单，以为需求变化留出空间。14.增量过程相较于瀑布模型降低风险的原因

增量过程能更早地交付部分功能并获得反馈，使团队能尽早发现需求理解错误、技术可行性等问题。它将“全盘失败”的风险分散到各个增量中，即使某个增量有问题，也不至于导致整个项目失败。15.软件开发与维护中的潜在风险

包括：需求不断变化或蔓延、技术选型失误、估算过于乐观、核心人员流失、预算削减、进度压力导致质量牺牲、第三方依赖问题、以及部署后出现的安全漏洞和性能问题。16.统一过程与增量过程的共同点

两者都是迭代和增量式的。它们都将软件开发组织为一系列较小的、可管理的循环（迭代），每个循环都产生一个可执行的软件增量，通过逐步集成和扩展，最终形成完整的系统。17.测试工作流在UP四个阶段的分布(0-5)初始阶段：1

-侧重于测试计划的制定，实际测试活动很少。细化阶段：3

-核心架构元素的测试是重点，确保架构稳定。构建阶段：5

-大部分测试工作在此阶段进行，包括特性测试和迭代集成测试。移交阶段：4

-侧重于用户验收测试、问题修复和最终产品验证。项目题项目题1（一）过程活动定义与分解框架活动（核心工程活动）框架活动构成了项目开发的骨干生命周期，按顺序执行，每个阶段产生明确的输出，作为下一阶段的输入。需求分析与规格说明需求理解与澄清：

与指导老师（作为用户代理）沟通，澄清初始需求中的模糊点。需求细化与结构化：

将用户需求转化为详细的功能需求、非功能需求（如性能、界面）和约束。编写软件需求规格说明书（SRS）：

形成结构化文档，作为后续所有活动的基准。系统设计与建模架构设计：

确定系统高层结构、技术栈、模块划分及接口。详细设计：

对每个模块进行详细设计，包括数据库设计、接口设计、算法设计等。使用UML等工具进行建模。编写设计文档（SDD）：

记录所有设计决策。实现与单元测试编码：

根据设计文档，编写高质量的、可读的源代码。单元测试：

开发者对自己编写的每个模块进行测试，确保其功能正确。代码审查：

在团队项目中，进行同伴代码审查，保证代码质量。集成与系统测试集成计划执行：

按设计好的策略（如增量式）将模块逐步集成为完整的系统。系统测试：

对集成后的完整系统进行全面的功能测试、性能测试等，验证其是否满足SRS的要求。部署与交付成果打包：

准备可运行的软件、安装脚本或部署指南。报告撰写：

编写课程设计报告，总结整个项目过程、展示成果并进行反思。最终交付与演示：

向指导老师提交所有工作产品并进行成果演示。支撑活动（保障性活动）这些活动贯穿整个项目生命周期，为框架活动的顺利进行提供保障。项目管理：

包括任务分解（WBS）、进度计划制定（甘特图）、风险识别与监控。这是课程项目成功的核心支撑。配置管理：

使用Git等工具进行版本控制，管理源代码、文档的变更。质量保证（QA）：

通过流程检查（如文档评审）

和产品检查（如测试）

来确保工作产品质量。度量与跟踪：

定期（如每周）收集实际进度，与计划对比，并向指导老师汇报，以便及时调整。（二）框架活动与支撑活动的关系框架活动与支撑活动是“骨”与“筋”的关系，相互交织，共同构成一个有机整体。项目管理是总纲：在需求分析开始前，项目管理活动就启动，制定出覆盖所有框架活动的总体计划。在每一个框架活动阶段，项目管理负责跟踪该阶段任务的完成情况，确保项目按计划推进。配置管理是基础设施：从实现阶段开始变得至关重要，但设计文档等也应纳入版本管理。它支撑着所有框架活动中产生的工作产品的版本一致性和可追溯性。质量保证是守护者：它与每个框架活动并行。例如，在需求分析后对SRS进行评审，在系统设计后对SDD进行评审，在实现后进行代码审查和测试。QA活动确保每个阶段输出的正确性，防止缺陷流入下一阶段。度量与跟踪是神经中枢：它依赖于各框架活动的输出（如完成的文档、代码模块）来收集数据，为项目管理提供决策依据，并成为向指导老师汇报的基础。（三）活动详细描述活动名称前置条件后置条件主要完成人输出工作产品质量保证方法1.需求分析与规格说明收到老师的初始需求文档《软件需求规格说明书（SRS）》通过评审并被基线化全体学生《软件需求规格说明书（SRS）》正式评审：由团队内部交叉审查，并提交给指导老师审批。确保需求清晰、无二义、可测试。2.系统设计与建模SRS已基线化《系统设计文档（SDD）》通过评审并被基线化全体学生（架构由技术骨干主导）《系统设计文档（SDD）》、UML模型图设计评审：团队和指导老师共同审查设计文档，评估其合理性、可行性及对需求的覆盖度。3.实现与单元测试SDD已基线化所有代码已完成并通过单元测试，并提交至版本库全体学生（按模块分配）源代码、单元测试用例及报告代码审查：团队成员相互审查代码。自动化单元测试：要求单元测试覆盖率达到预定标准（如80%）。4.集成与系统测试所有模块实现完毕并通过单元测试系统测试通过，所有严重缺陷已修复全体学生（测试由专人协调）集成后的可运行软件、《系统测试报告》、缺陷日志测试用例评审：确保测试用例覆盖所有需求。严格的缺陷管理流程：跟踪每一个缺陷直至关闭。5.部署与交付系统测试通过，软件达到稳定状态所有交付物已提交给老师全体学生最终可交付软件包、《课程设计报告》、演示视频/PPT交付清单检查：对照要求清单逐一核对交付物是否完整。报告评审：指导老师审阅报告的逻辑性和完整性。支撑：项目管理项目启动项目结束项目经理（可由学生轮流担任）《项目计划》（含WBS和甘特图）、《周报》、《风险清单》定期周会与周报：向指导老师同步进度，暴露问题。计划与实际对比：及时发现偏差并采取纠正措施。支撑：配置管理第一个工作产品（如SRS初稿）产生项目结束全体学生配置管理库（如Git仓库）基线化管理：对SRS、SDD等关键文档建立基线，禁止随意修改。提交规范检查：确保代码和文档的提交信息规范。支撑：质量保证项目启动项目结束全体学生（QA活动人人有责）《评审记录》、《审计报告》过程审计：检查项目活动是否按既定流程执行。工作产品评审：参与所有关键工作产品的正式评审。第3章敏捷开发思考题1.

敏捷宣言的四条核心是价值观的权衡：“个体与互动”高于流程与工具，强调人的能动性；“可工作的软件”高于详尽的文档，强调以交付价值为中心；“客户合作”高于合同谈判，致力于建立共赢伙伴关系；“响应变化”高于遵循计划，承认不确定性并保持灵活性。这些不是否定后者，而是强调前者的优先性。2.极限编程通过其具体实践系统性拥抱变化。短周期迭代和持续计划允许需求频繁调整；结对编程与集体代码所有制使代码能被任何人修改且质量可控；强大的自动化测试套件为变化提供安全网，防止回归错误；持续集成确保变化被快速集成和验证。因此，XP不仅态度上欢迎变化，更在技术上降低了变化的成本与风险。3.这得益于敏捷的技术实践和迭代方式。持续的代码重构保持代码结构清晰，易于修改；全面的自动化测试套件（如单元测试）能快速捕获变更引入的错误，降低修复成本；短迭代周期意味着系统尚未积累大量依赖于旧设计的“技术债”。因此，即使晚期变更，其影响范围也相对可控，成本不会像传统瀑布模型那样呈指数级增长。4.我将侧重考察候选人的“软技能”和态度：沟通协作能力（乐于分享和帮助）、成长心态（开放接受反馈并持续学习）、责任感（对团队目标和产品质量负责）和自组织能力（能主动认领任务并解决问题）。技术能力是基础，但上述特质对于构建一个高效、抗压的敏捷团队更为关键。5.区别：客户代表业务价值与需求，开发人员负责技术实现。优点是直接协作减少信息失真。问题是思维差异可能导致误解（如客户认为“简单”修改）。建议：设立专职的“产品负责人”角色作为沟通桥梁；邀请开发人员直接参与用户故事讨论；使用原型和频繁演示来对齐期望，建立共同语言。6.

即时通讯工具（如Slack/Teams）：用于快速、异步的简短问答和信息共享。视频会议：适用于分布式团队的日常站会或评审，保留部分非语言线索。协作平台（如Jira/Trello）：将沟通语境化，任务状态、评论和更新与具体工作项关联，实现透明和可追溯的沟通。7.流水线文化（如需求、开发、测试严格分离）会导致：部门墙和信息孤岛，沟通成本高昂；批量传递工作项，而非持续流动，造成等待和延迟；责任分散，无人对最终可交付的软件价值负责；团队成员技能单一，无法形成跨职能团队，严重阻碍了敏捷追求的自组织、快速交付和持续反馈。8.

问题：初期人力成本感觉高；长期配对可能疲劳；性格或技能不匹配可能引发摩擦。克服方法：定期轮换配对，避免知识孤岛并促进知识共享；强调结对是协作而非监督；为团队成员提供结对技巧培训；通过实际数据（如缺陷率下降、代码质量提升）来证明其长期价值，统一团队认知。9.好处：卡片物理尺寸限制迫使需求描述保持简洁（3C原则）；便于在迭代计划会上进行实物排序和分组；增强了需求的可见性和触觉，促进团队讨论。管理：使用故事地图进行视觉化整体规划；利用看板（物理或电子）管理其状态（待办、进行中、完成）；定期与产品负责人一起梳理和更新卡片内容。10.交互场景（或验收标准）应详细到足以作为测试依据，但避免过早规定具体UI实现。它应聚焦于“做什么”和“为什么”，而非“怎么做”。细节应在团队与产品负责人的对话中逐步澄清和细化。过度详细会僵化思维，而过于简略则会导致误解，关键在于找到能明确界定“完成”标准的平衡点。11.

此做法（如计划扑克）的核心好处是知识共享和风险暴露。不同经验的开发者从各自视角提出见解，能更全面地识别潜在复杂性和依赖，从而得出更可靠的估算。讨论过程本身加深了全员对任务的理解，建立了对估算结果的共同承诺，提升了计划的准确性和团队的责任感。12.

重构是实现并维持“简单设计”的关键手段。简单设计意味着不做过度预设（YAGNI原则）。随着需求增加，代码会变复杂，此时通过重构持续改进代码结构，消除重复、提高可读性和扩展性，从而使其始终符合当前需求下的最简单可用状态。没有重构，设计会逐渐腐化，简单设计无从谈起。13.主要挑战在于沟通与协作：时区差异导致实时协作窗口狭窄；文化语言差异可能引起误解；缺乏面对面交流削弱了非正式沟通和团队凝聚力。这可能导致信息同步延迟、反馈周期变长、建立信任更困难。需要更强依赖工具、规范化流程并有意安排重叠工作时间来弥补。14.

Scrum中，客户代表（产品负责人）是团队核心角色，全程参与，主要负责管理产品待办列表、定义需求优先级并在Sprint评审中验收成果。XP中，客户（现场客户）更深入地融入团队，不仅定义需求，还共同制定验收测试、频繁提供反馈，参与度更高，更侧重于实时、详细的业务决策。项目题项目题1用户故事：广告充值主要场景：广告客户成功充值前置条件：

广告客户已成功登录广告系统。步骤1：

用户进入“财务中心”或“账户余额”页面，系统清晰展示当前账户余额。步骤2：

用户点击“充值”按钮，系统跳转至充值页面。步骤3：

用户选择充值金额。系统提供预设金额选项（如500元、1000元、5000元），也允许用户手动输入自定义金额。步骤4：

用户选择支付方式（例如：企业网银支付、支付宝、微信支付、银联在线等）。步骤5：

用户点击“确认充值并支付”，系统根据选择的支付方式，跳转至对应的第三方支付网关，或生成收款二维码。步骤6：

用户在支付网关或扫码完成支付。步骤7：

支付成功后，第三方支付系统异步通知广告系统充值结果。步骤8：

广告系统在验证通知真实性并确认款项到账后，自动实时更新用户账户余额。步骤9：

系统向用户显示“充值成功”的提示消息，并更新页面上的账户余额。同时，系统会向用户注册的邮箱或手机发送一封充值成功的通知凭证。异常情形与处理方式异常情形：支付过程中断或失败描述：

用户在跳转至支付网关后，因网络问题、关闭页面或账户余额不足等原因导致支付未完成。处理方式：

系统应保持充值订单为“待支付”状态，并允许用户在“订单管理”页面找到该笔未完成订单，继续支付或取消它。同时，在用户返回广告系统时，通过醒目的提示告知用户有未完成的订单。异常情形：支付成功但系统余额未更新描述：

用户已扣款，但由于第三方支付通知延迟或系统处理故障，广告系统账户余额未实时增加。处理方式：

系统需设有对账机制，定期与支付渠道核对异常订单。对于用户端，应提供明确的客服联系渠道（如在线客服、电话）。用户可通过提交支付成功的截图或交易号，由人工客服进行核实并手动入账。同时，系统界面上应提示“如遇余额未及时到账，请耐心等待或联系客服”。异常情形：充值金额输入错误描述：

用户手动输入了非法的充值金额（如负数、金额为0、金额过大超过系统单笔限额等）。处理方式：

在前端进行实时校验，当金额不合法时，立即提示用户并禁用“确认充值”按钮。提示信息应具体，如“充值金额必须大于0且单笔不超过50万元”。异常情形：支付渠道不可用描述：

用户选择的某个支付方式临时出现故障或正在维护。处理方式：

系统在加载充值页面时，应实时检测各支付渠道的可用性。对于不可用的渠道，将其置灰或隐藏，并提示“暂不可用，请选择其他方式”。同时，推荐可用的替代支付方式。异常情形：账户或活动异常描述：

用户的广告账户因涉嫌违规操作而被冻结，或当前有正在进行的审计活动，禁止充值。处理方式：

当用户点击充值时，系统应先校验账户状态。若状态异常，则阻止进入充值流程，并清晰提示用户“您的账户目前处于冻结状态，无法进行充值。请联系客户经理或客服了解详情”，并引导其解决问题。项目题21.重复代码坏味道描述：相同的代码结构出现在多个地方。

问题：修改逻辑时需要修改多处，极易出错且维护成本高。

重构方法：提取方法/函数，将重复代码合并为一处。//重构前voidprintUserInfo(Useru){System.out.println("Name:"+);System.out.println("Age:"+u.age);//...其他打印}voidprintAdminInfo(Admina){System.out.println("Name:"+);System.out.println("Age:"+a.age);//...其他打印}//重构后voidprintBaseInfo(Stringname,intage){System.out.println("Name:"+name);System.out.println("Age:"+age);}2.过长函数坏味道描述：一个函数或方法代码过长（如超过50行）。

问题：难以理解和测试，通常承担了过多职责。

重构方法：提取方法/函数，根据逻辑段落将长函数拆分为多个小函数，并使用有意义的名称。//重构前voidprocessOrder(Orderorder){//验证订单...(20行)//计算价格...(15行)//更新库存...(10行)//发送通知...(5行)}//重构后voidprocessOrder(Orderorder){validateOrder(order);calculatePrice(order);updateInventory(order);sendNotification(order);}3.过大的类坏味道描述：一个类拥有过多字段、方法或代码行。

问题：类的职责不单一，难以理解和维护。

重构方法：提取类，将相关的字段和方法拆分到新的类中。//重构前classCustomer{privateStringname;privateStringaddress;//...订单相关字段和方法publicvoidaddOrder(){...}publicvoidcalculateOrderTotal(){...}//...地址相关字段和方法publicvoidvalidateAddress(){...}publicvoidformatAddress(){...}}//重构后classCustomer{privateStringname;privateAddressaddress;//提取出的新类privateList<Order>orders;//订单集合}classAddress{...}//处理地址逻辑classOrder{...}//处理订单逻辑4.过长参数列坏味道描述：函数参数列表过长（如超过5个）。

问题：难以理解和使用，容易传错参数。

重构方法：引入参数对象，将相关参数封装成一个对象。//重构前voidcreateUser(StringfirstName,StringlastName,Stringemail,Stringphone,Stringstreet,Stringcity,StringzipCode){...}//重构后voidcreateUser(UserDatauserData,Addressaddress){...}//使用UserData和Address对象封装参数5.发散式变化坏味道描述：一个类因为不同的原因，在不同的方向上经常被修改。

问题：类不稳定，违反了单一职责原则。

重构方法：提取类，将不同变化原因的逻辑拆分到不同的类中。//重构前classReport{//因为报表格式变化而修改此方法publicStringgenerateHtml(){...}//因为计算逻辑变化而修改此方法publicdoublecalculateTotal(){...}}//重构后classReport{privateReportFormatterformatter;//负责格式变化privateCalculatorcalculator;//负责计算变化}6.霰弹式修改坏味道描述：当发生一种变化时，需要在多个类中做许多小修改。

问题：变化分散在各处，寻找和修改所有地方非常困难。

重构方法：搬移函数和内联类，将需要修改的代码集中到一个地方。//重构前：每当支付方式增加，PaymentProcessor、OrderService、EmailService都需要修改classPaymentProcessor{if(type=="CreditCard"){...}elseif(type=="PayPal"){...}//新增Alipay需要修改这里}classOrderService{if(type=="CreditCard"){...}elseif(type=="PayPal"){...}//也需要修改这里}//重构后：使用多态将行为集中interfacePaymentMethod{voidprocess();}classCreditCardimplementsPaymentMethod{...}classPayPalimplementsPaymentMethod{...}classAlipayimplementsPaymentMethod{...}//新增时只需新建一个类//其他类只需调用paymentMcess()7.数据泥团坏味道描述：总是成群出现的数据项（如字段、参数），在不同的地方被一起传递。

问题：这些数据应该被组织在一起，分散处理导致代码冗余。

重构方法：提取类和引入参数对象。//重构前classCustomer{privateStringname;privateStringbillingStreet;privateStringbillingCity;privateStringshippingStreet;privateStringshippingCity;}//多个方法都同时接收(street,city)参数//重构后classCustomer{privateStringname;privateAddressbillingAddress;privateAddressshippingAddress;}classAddress{privateStringstreet;privateStringcity;}8.基本类型偏执坏味道描述：过度使用基本类型（如int,string）来表示领域概念。

问题：缺乏抽象，容易让无效值泛滥，业务逻辑分散。

重构方法：用对象取代基本类型或用类取代类型码。//重构前doublecalculatePrice(doublequantity,doubleunitPrice,Stringcurrency){//需要到处验证currency是否为"USD","EUR"等有效值}//重构后classMoney{privatedoubleamount;privateCurrencycurrency;//Currency是一个类，封装了货币单位和汇率逻辑}doublecalculatePrice(Quantityquantity,MoneyunitPrice){//业务逻辑更清晰，有效性由类保证}项目题3以JAVA语言为例：第一步：编写第一个测试importorg.junit.jupiter.api.Test;importstaticorg.junit.jupiter.api.Assertions.*;publicclassIP4ValidatorTest{privatefinalIP4Validatorvalidator=newIP4Validator();@TestpublicvoidshouldReturnFalseForNullString(){assertFalse(validator.isValidIP4(null));}}第二步：实现最小代码使测试通过publicclassIP4Validator{publicbooleanisValidIP4(Stringip){if(ip==null){returnfalse;}returnfalse;//最小实现}}第三步：添加更多测试并逐步实现测试类继续完善：importorg.junit.jupiter.api.Test;importorg.junit.jupiter.params.ParameterizedTest;importvider.ValueSource;importstaticorg.junit.jupiter.api.Assertions.*;publicclassIP4ValidatorTest{privatefinalIP4Validatorvalidator=newIP4Validator();@TestpublicvoidshouldReturnFalseForNullString(){assertFalse(validator.isValidIP4(null));}@TestpublicvoidshouldReturnFalseForEmptyString(){assertFalse(validator.isValidIP4(""));}@ParameterizedTest@ValueSource(strings={"","","","55",""})publicvoidshouldReturnTrueForValidIP4Addresses(Stringip){assertTrue(validator.isValidIP4(ip));}@ParameterizedTest@ValueSource(strings={"56",//数字超过255"25",//第一个数字超过255"192.168.1",//只有3段".1",//有5段"192.168.1.",//以点结尾".",//以点开头"192.168.01.1",//有前导零"a",//包含字母"192.168.1.1",//包含空格"192.168.1.-1",//包含负数"30"//数字太大})publicvoidshouldReturnFalseForInvalidIP4Addresses(Stringip){assertFalse(validator.isValidIP4(ip));}@TestpublicvoidshouldReturnFalseForStringWithSpaces(){assertFalse(validator.isValidIP4(""));assertFalse(validator.isValidIP4("192.168.1.1"));}}实现类逐步完善：publicclassIP4Validator{publicbooleanisValidIP4(Stringip){//检查空值if(ip==null||ip.isEmpty()){returnfalse;}//检查是否包含空格if(ip.contains("")){returnfalse;}//按点号分割String[]parts=ip.split("\\.");//检查段数if(parts.length!=4){returnfalse;}//检查每段for(Stringpart:parts){//检查空段if(part.isEmpty()){returnfalse;}//检查前导零（除非就是"0"）if(part.length()>1&&part.startsWith("0")){returnfalse;}try{intnum=Integer.parseInt(part);//检查数字范围if(num<0||num>255){returnfalse;}}catch(NumberFormatExceptione){//包含非数字字符returnfalse;}}returntrue;}}第四步：重构优化经过测试通过后，我们可以重构代码使其更清晰：publicclassIP4Validator{publicbooleanisValidIP4(Stringip){if(!isBasicFormatValid(ip)){returnfalse;}String[]parts=ip.split("\\.");returnareAllPartsValid(parts);}privatebooleanisBasicFormatValid(Stringip){returnip!=null&&!ip.isEmpty()&&!ip.contains("")&&ip.split("\\.").length==4;}privatebooleanareAllPartsValid(String[]parts){for(Stringpart:parts){if(!isPartValid(part)){returnfalse;}}returntrue;}privatebooleanisPartValid(Stringpart){if(part.isEmpty()||hasLeadingZero(part)){returnfalse;}try{intnum=Integer.parseInt(part);returnnum>=0&&num<=255;}catch(NumberFormatExceptione){returnfalse;}}privatebooleanhasLeadingZero(Stringpart){returnpart.length()>1&&part.startsWith("0");}}第五步：添加边界情况测试@TestpublicvoidshouldHandleEdgeCases(){//边界值测试assertTrue(validator.isValidIP4(""));assertTrue(validator.isValidIP4("55"));assertFalse(validator.isValidIP4("56"));assertFalse(validator.isValidIP4("-"));}@TestpublicvoidshouldRejectOctalFormat(){//拒绝八进制格式（前导零）assertFalse(validator.isValidIP4("192.168.01.1"));assertFalse(validator.isValidIP4("0"));}第4章需求工程思考题用户需求虽抽象，但能明确系统目标与价值，为后续系统需求提供方向和依据，确保开发不偏离用户真实意图。UR3“快速生成课表”可描述为系统需求：系统应在用户提交课程信息后5秒内自动生成并显示无冲突的课表，支持手动调整并保存。SR2“系统及时响应”存在模糊：“及时”未量化。可补充：95%的查询请求响应时间小于2秒，峰值并发50用户时响应时间不超过5秒。非功能性需求“高并发”需要软件功能支持：如通过负载均衡模块动态分配请求，连接池管理数据库链接，确保系统在万人同时在线时稳定运行。分层架构还支持可维护性（各层独立修改）、可扩展性（新增功能不影响现有结构）、可复用性（通用层可跨项目使用）。安全性需求可测试描述：用户密码需加密存储，连续5次登录失败锁定账户30分钟，传输数据使用TLS1.2以上协议加密。唯一标识需求便于跟踪管理，建立需求与设计、测试的追溯链，避免遗漏或混淆，提升团队协作效率和版本控制准确性。“界面良好”应具体为：新手用户无需培训即可在3分钟内完成登录操作，满意度调查中易用性评分达4.5/5以上。“为建模而建模”指过度追求模型完美而忽视实际价值。建议以解决问题为导向，优先建立最小可行模型再迭代优化。双方均推卸责任。开发方应主动挖掘需求，客户需积极配合澄清，建立协作机制如定期评审会共同明确需求。分析模型描述“做什么”（如用例图），设计模型定义“怎么做”（如类图）。前者是后者的基础，后者实现前者的约束。教务员（期望自动排课）、教师（期望便捷录入成绩）、学生（期望实时查课表）、财务员（期望对接收费系统）。客户是学校（出资方，关注成本功能），业务人员是教务员（实际使用者，关注操作效率），两者需求需协调平衡。课程对象：课程编号(字符串)、学分(整型)、学时(整型)；学生对象：学号(字符串)、姓名(字符串)、班级(字符串)。教务处（管理效率）、教师（教学便利）、学生（使用体验）、财务处（数据对接）、IT部（系统维护）、校领导（决策支持）。客户侧重成本与宏观效益（如降低人力成本），最终用户关注操作细节（如减少点击步骤），立场不同导致需求冲突。通过现场观察、深度访谈、原型演示等方式收集外部用户需求，建立用户代表委员会参与需求评审，确保视角全面。导致范围蔓延、工期延误、成本超支，产生低质量产品，引发客户纠纷，损害团队信誉，甚至造成项目完全失败。项目题项目题1（1）数据分析建模数据流图顶层图：外部实体：项目经理、翻译人员、校对人员、审批管理员。过程：企业翻译平台系统。数据流：项目经理流入“创建的项目信息”；系统向翻译人员提供“待办任务”和“辅助翻译建议”；翻译人员提交“翻译结果”；校对人员提交“校对意见/结果”；审批管理员提交“审批结果”。0层图：P1：项目管理：接收项目经理的指令，创建和维护项目与文件数据。输出“项目文件”到数据存储D1。P2：任务分配：根据项目文件，为翻译和校对人员生成“翻译任务”和“校对任务”。输出任务数据到D2和D3。P3：机器翻译：接收来自P1或P2的“源文本”，调用外部MT引擎，返回“机器翻译结果”到D4。P4：辅助翻译：接收翻译人员的“翻译请求”，查询D5和D6，返回“翻译记忆/术语建议”。P5：翻译与修改：翻译人员处理任务，更新“翻译内容”到D4。P6：校对与打回：校对人员处理任务，提交“校对内容”或“打回指令”到D4和D2。P7：审批归档：审批管理员处理任务，将最终“审批结果”更新至D1，并将最终译文存入D5。ER图识别出的核心数据实体及其关系如下：实体：Project：属性有项目ID、名称、描述、源语言、目标语言、创建时间、状态。SourceFile：属性有文件ID、项目ID、文件名、路径、字数、格式。User：属性有用户ID、姓名、角色。TranslationTask：属性有任务ID、文件ID、翻译员ID、状态、创建时间、截止时间。ReviewTask：属性有任务ID、文件ID、校对员ID、状态、创建时间、截止时间。ApprovalTask：属性有任务ID、文件ID、管理员ID、状态。TranslationUnit：属性有单元ID、文件ID、源文本、译文文本、状态、版本号。TranslationMemory：属性有TMID、源文本、目标文本、项目ID。Terminology：属性有术语ID、源术语、目标术语、领域。关系：Project

包含

多个

SourceFile

(1:N)。SourceFile

被分配

给一个

TranslationTask

(1:1)和一个

ReviewTask

(1:1)。SourceFile

由

多个

TranslationUnit

组成(1:N)。User

被分配

多个

TranslationTask

/

ReviewTask

/

ApprovalTask

(1:N)。TranslationUnit

的译文文本

可被存入

TranslationMemory

(1:N，但非全部)。（2）场景分析建模用例图

核心用例包括：创建翻译项目、分配任务、执行机器翻译、进行初译、使用辅助翻译、提交校对、打回修改、批准项目、管理术语库。用例详细描述（以“进行初译”为例）用例名称进行初译参与者翻译人员简要说明翻译人员对待翻译的文件进行人工翻译，并可利用机器翻译结果和辅助翻译功能。前置条件翻译人员已成功登录系统，并且有被分配的、状态为“待翻译”的任务。主事件流1.翻译人员从工作台选择一条翻译任务。2.系统显示源文件内容，并可选显示机器翻译的预翻译结果。3.翻译人员在译文区域进行翻译。4.翻译人员输入时，系统自动从翻译记忆库和术语库中匹配并提示相似句段和标准术语。5.翻译人员可采纳提示，也可自行修改。6.翻译完成后，点击“提交”，系统将任务状态更新为“待校对”。其他事件流A1：保存草稿：在主事件流第3-5步，用户可点击“保存草稿”，系统保存进度，任务状态仍为“待翻译”。

A2：请求机器翻译：若文件未预翻译，用户可点击“请求机器翻译”，系统执行并填充结果。异常事件流系统连接翻译记忆库失败，给出提示，但翻译工作可继续进行。后置条件翻译任务的状态变为“待校对”，或保持“待翻译”但内容已保存。（3）类分析建模从场景中识别出的核心类及其关系如下：User

(抽象类)：属性：-userId:String,-name:String,-email:String。操作：+login()。Translator，

Reviewer，

Manager

继承自

User。Project：属性：-projectId:String,-name,-sourceLang,-targetLang,-status。操作：+createProject(),+updateStatus()。ProjectFile：属性：-fileId:String,-fileName,-filePath,-wordCount。操作：+getContent()。Task

(抽象类)：属性：-taskId:String,-status,-dueDate。操作：+assignUser()。TranslationTask，

ReviewTask，

ApprovalTask

继承自

Task。TranslationUnit：属性：-unitId:String,-sourceText:String,-targetText:String,-status。操作：+updateTranslation()。TMEngine：属性：操作：+searchTM(),+addToTM()。MTEngine：属性：操作：+translate()。关系：Project

与

ProjectFile：组合

关系(1-*)。Project

与

Task：关联

关系(1-*)。Task

与

User：关联

关系(*-1)。TranslationTask

与

TranslationUnit：关联

关系(1-*)。TMEngine

与

TranslationUnit：依赖

关系。（4）行为建模顺序图（以“翻译-校对-打回”场景为例）翻译人员

->

系统UI：选择待处理的翻译任务。系统UI

->

TranslationController：请求任务详情。TranslationController

->

TranslationTask：获取任务和文件信息。TranslationController

->

TMEngine：查询翻译记忆和术语。TranslationController

->

MTEngine：【可选】请求机器翻译。MTEngine/TMEngine

-->

TranslationController：返回结果。TranslationController

-->

系统UI：显示源文、译文区和辅助信息。翻译人员

->

系统UI：编辑译文并点击“提交”。系统UI

->

TranslationController：提交最终译文。TranslationController

->

TranslationTask

/

TranslationUnit：更新状态和内容。TranslationController

->

ReviewTask：创建或激活校对任务。（校对和打回流程类似，角色变为校对人员，操作包括提交修改或触发打回指令，使TranslationTask状态回退）。状态图（对TranslationUnit）状态：

初始状态

->

待翻译

->

翻译中

->

待校对

->

待审批

->

已完成。转移：从

待翻译

到

翻译中：翻译人员开始编辑。从

翻译中

到

待校对：翻译人员提交。从

待校对

到

翻译中：校对人员打回。从

待校对

到

待审批：校对人员提交。从

待审批

到

已完成：管理员批准。从

待审批

到

待校对：管理员打回。第5章软件设计思考题抽象在软件设计中广泛运用，如接口定义隐藏实现细节，数据结构封装数据操作，设计模式提供通用解决方案，架构模式定义系统高层结构，API设计提供简化访问方式等。软件架构作为系统蓝图，定义了组件关系、交互方式和约束条件。它支撑质量属性（性能、安全），指导开发团队分工，促进技术决策，降低维护成本，并确保系统演进的一致性。早期架构设计可识别关键技术风险，验证需求可行性，建立开发共识，规划迭代路线。避免后期因架构问题导致大规模返工，降低项目失败概率并控制开发成本。需求阶段架构可验证需求技术可行性，识别约束条件。但需注意避免过早技术绑定，保持架构描述抽象，聚焦于需求实现路径而非具体技术细节。层按职责分离（表现/业务/数据）。跨层访问常在性能优化时出现，但会破坏封装，增加耦合，降低可测试性，使系统维护复杂化。管道是连接过滤器的通道，负责数据传输而不修改内容。它解耦过滤器实现，支持数据流重组，构成可重用的处理流水线。客户端协议包括通信格式（JSON/XML）、传输机制（HTTP/TCP）、序列化方式、状态管理、错误处理、安全认证及会话控制等要素。典型C/S应用：数据库系统（Oracle）、Web服务（Apache）、邮件系统（SMTP/POP3）、文件传输（FTP）、远程登录（SSH）等。在C语言中通过函数指针表实现接口；C++用抽象基类；Java/C#通过interface关键字；Go使用隐式接口；Python通过鸭子类型实现多态。文件保存功能：普通用户偏好一键保存，程序员需要手动选择编码格式，设计师期望自动版本管理。同一功能因用户场景产生不同交互需求。全局变量无法控制实例化时机，存在线程安全问题，不支持延迟加载。单例模式通过静态方法封装实例，提供可控的访问点，确保唯一性。使用继承需创建：FileOutput->BufferedFileOutput->CompressedBufferedFileOutput等组合类。会导致类爆炸（n个特性需要2^n个类），难以动态组合功能。项目题项