前言 本文记录软件工程与UML考试复习资料.

总纲

题型与分值

  • 选择题 15*1 分 = 15 分
  • 判断题 10*1 分 = 10 分
  • 填空题 15*1 分 = 15 分
  • 简答题 6*5 分 = 30 分
  • 设计题 1*12 分 = 12 分
  • 综合题 1*18 分 = 18 分

SE1.1 程序及质量保证方法

一、程序的基本概念

程序（Program）：由程序设计语言所描述的、能为计算机所理解和处理的一组语句序列。

程序的组成模块：包(Package)、类(Class)、方法(Method)，每个模块实现特定功能。

高级语言源程序的转换过程：预处理 → 编译 → 汇编 → 链接

二、程序的两类利益相关者

视角关注点
用户角度正确性、高效性、可靠性、友好性
程序员角度可理解、易修改、可维护、可重用

三、程序质量保证方法

  1. 遵循编码风格：易读、简明、易改、无二义
  2. 采用程序设计方法学：
    • 语句设计：单入口单出口，少用goto，加强异常处理(Try-catch)，验证输入参数
    • 模块化设计：模块是逻辑上相对独立、具有良定义接口的编程单位
    • 高内聚度：模块内各要素紧密相关，仅实现单一功能；若多个要素关系不密切，需分解
    • 低耦合度：模块间关系应设计得非常松散；若多个模块关系密切，可合并
  3. 代码重用：重用函数、类和软构件（C函数库、MFC类库、Java SDK、ROS节点）；重用Github开源代码
  4. 结对编程：团队开发、合作开发、群体开发

四、个体开发的局限性

  • 个体知识和技能局限
  • 个体开发行为局限（总是会犯错）

五、关键概念速记

概念定义
模块逻辑上相对独立、具有良定义接口的编程单位
高内聚模块内各要素紧密相关，仅实现单一功能
低耦合模块间关系设计得非常松散
代码重用利用已有函数、类、软构件、开源代码

SE1.2 软件及其特点

一、软件的定义

软件 = 程序 + 文档 + 数据

  • 程序：可以运行的代码
  • 文档：记录软件开发活动和阶段性成果的阐述性资料（需求文档、设计文档、测试文档、用户手册）
  • 数据：程序的加工处理对象和结果

软件 ≠ 程序，开发软件 ≠ 编写程序

二、软件生命周期

从提出开发开始到最终灭亡所经历的时期：

需求分析(What) → 设计(How) → 编码实现 → 测试 → 部署运行 → 维护

三、软件分类

类型定义示例
应用软件面向特定应用领域的专用软件淘宝、12306、微信
系统软件管理计算机资源，为应用软件提供基础设施和服务OS、DBMS、编译软件、中间件
支撑软件辅助软件开发和运维SonarQube、VS、Eclipse

四、开源软件

  • 定义：源代码可自由获取和传播的计算机软件
  • 优势：成本更低、质量更高更安全、交付更快、功能更强大
  • 对比闭源软件：闭源代码不对用户开放（如Windows、Office）
  • 托管平台：Github（国际）、Gitee（国内）

五、关键概念速记

概念定义
软件程序 + 文档 + 数据
软件生命周期从提出开发到最终灭亡的完整时期
开源软件源代码可自由获取和传播的软件
系统软件管理计算机资源的基础设施软件
支撑软件辅助软件开发运维的工具

SE2 软件工程概述

一、软件危机

背景：1950s-1960s，从军方科学计算走向商业应用，需求量和复杂性增加，作坊式个体编程 → 大批量大规模开发 → 软件危机

表现：进度延迟、质量无法保证、成本超支、维护困难、失败风险大

软件工程诞生：1968年 NATO会议，提出软件工程概念

二、软件工程对软件开发的新认识

  • 软件是产品(Product)：面向用户，存在质量、成本、利润等特征
  • 软件开发是一项工程(Project)：存在约束，需要质量保证，进行组织管理
  • 需按工程化方法组织软件生产：
    • 分阶段分步骤来实施
    • 按计划开展开发活动
    • 进行各种形式质量保证
    • 采用行之有效的方法
    • 借助各种工具的支持

三、软件工程定义（IEEE 93）

将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程。

  • 系统化：提供完整全面的解决方法
  • 规范化：支持各类软件系统开发
  • 可量化：工作量、成本、进度、质量可量化

三、软件工程三要素

要素视角回答的问题典型成果
过程(Process)管理视角做什么、按什么步骤次序瀑布模型、增量模型、螺旋模型；敏捷开发、DevOps；配置管理、质量管理
方法学(Methodology)技术视角如何做结构化方法学、面向对象方法学、基于构件方法学
工具(Tool)辅助视角借助什么提效SonarQube、Eclipse、Visual Studio

CASE（计算机辅助软件工程）——工欲善其事必先利其器

四、软件开发的本质

软件开发 = 软件创作 + 软件生产

  • 软件创作：基于经验和技能，自由创新（设计、编码）
  • 软件生产：基于工程化手段，遵循约束规范

五、软件工程目标

在成本、进度约束下，开发出满足用户要求的足够好软件。

六、软件工程八大原则

原则核心思想
抽象和建模提取关注要素，忽略无关细节；用建模语言建立软件模型
模块化分解为若干模块，高内聚低耦合
软件重用利用已有软件资产，开发可重用资源
信息隐藏模块内部信息对外不可见，仅交换必要接口信息
关注点分离将不同关注点分离，分别处理再整合
分而治之分解复杂系统为子系统，逐个击破
双向追踪正向追踪变更影响，反向追踪变更来源
工具辅助借助CASE工具辅助开发维护

七、软件工程发展趋势

  • 抽象层次越来越高，重用粒度越来越大
  • 以文档为中心 → 以代码为中心
  • 从个体、团队 → 群体开发
  • 从还原论 → 演化论
  • 近十年趋势：移动互联网、软件定义一切、开源生态、DevOps、智能化

八、SWEBOK十大知识域

软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程建模与方法、软件质量

SE3.1 软件过程模型

一、基本概念

  • 软件过程：按照项目进度、成本和质量要求，遵循用户需求，开发和维护软件的一系列有序活动（技术活动 + 管理活动）
  • 软件过程模型：定义软件开发的具体活动以及活动间的逻辑关系

二、典型软件过程模型

模型指导思想关注点适合的软件管理难度
瀑布模型系统性指导与生命周期一致需求变动不大、明确易
原型模型原型为媒介导出需求需求获取、导出和确认需求难表述清楚易
增量模型快速交付和并行开发递增式完成功能需求变动不大、可预定义易
迭代模型多次迭代，每次仅部分需求分多次迭代开发需求变动大中
螺旋模型集成迭代+原型，引入风险分析风险管理、计划制定开发风险大、需求不确定难

三、各模型详解

瀑布模型：

  • 阶段：需求分析 → 概要设计 → 详细设计 → 编码实现 → 集成测试 → 确认测试
  • 不足：需求确定过于理想化，缺乏变通，难应对变化
  • 改进：带反馈和回溯的瀑布模型

增量模型：渐进式、增量式实现功能，快速交付，并行开发

迭代模型：每次迭代是一完整过程，小步快跑

原型模型：以原型作为交流载体，支持用户参与

螺旋模型：集成迭代和原型，引入风险分析，风险驱动

四、过程模型选择策略

场景推荐模型
互联网应用（需求不确定、快速变化）迭代模型
装备软件/银行核心系统（需求确定稳定、安全可靠性高）瀑布模型
初创公司移动应用（需求模糊、易变动）原型模型或迭代模型

五、传统过程模型的不足

以文档为中心的重型方法：大量时间写文档和评审，难应对需求变化，较长时间才能得到可运行软件

SE3.2 敏捷开发方法

一、核心思想

轻量级软件开发方法，以代码为中心，快速、轻巧、主动应对需求变化，持续及时交付可运行软件。

二、四大核心价值观

  1. 重视人和交互 > 工具和流程
  2. 重视可运行软件 > 详尽文档
  3. 重视客户合作 > 合同谈判
  4. 重视响应变化 > 遵循计划

三、敏捷准则要点

  • 尽早持续交付有价值的软件
  • 即使开发后期也欢迎需求变化
  • 不断交付可运行软件（几周到几个月）
  • 用户和开发人员最好每天一起工作
  • 面对面交谈是最有效的信息传递
  • 可运行软件是衡量进度的首要标准
  • 最好的架构、需求和设计出自自组织团队

四、极限编程（XP）

四条核心思想：交流、反馈、简单、勇气

五条指导原则：快速反馈、简单性假设、逐步更改、支持变化、高量工作

十二准则：计划游戏、隐喻、小型发布、简单设计、测试先行、重构、结对编程、代码集体拥有、持续集成、每周40小时、现场用户、编码标准

五、测试驱动开发（TDD）

红-绿-重构循环：

  1. 编写失败测试
  2. 编写代码使测试通过
  3. 重构优化设计

特点：根据测试编写代码，确保代码可测试，编码完成即完工

六、Scrum方法

核心流程：产品订单库(Backlog) → 冲刺订单库(SprintLog) → 冲刺(Sprint, 1-4周) → 交付

Sprint是核心活动，体现短期交付原则。

七、敏捷方法特点：小、简、快、变

SE3.3 群体化软件开发方法

一、定义

依托互联网平台吸引、汇聚、组织和管理大规模开发人员，通过竞争、合作、协商等方式，让大众参与软件开发的新颖方法。

二、大教堂与集市模型

模型方式特点
大教堂（闭源）封闭式建设成本高、周期长、品质优
集市（开源）开放式建设成本低、周期短，并行对等的扁平化开发

三、关键支撑技术

  1. 基于社区的群体化组织：

    • 核心开发人员（人数少）：主要贡献者，评审和合并外部代码
    • 外围开发人员（人数多）：自发贡献，提出需求、报告缺陷、提交代码
    • 社区特征：自由进出、遵循规定、自愿工作、开放分享

  2. 基于Issue的任务管理：

    • 流程：创建Issue（缺陷/需求）→ 讨论Issue → 指派Issue → 跟踪Issue
    • 特点：自主提出任务，自发完成任务

  3. 基于Git的分布式版本管理：

    • 工作区 → 暂存区 → 本地版本库 → 远程版本库
    • 分支：master分支（稳定发布）、develop分支（开发汇总）、开发者分支

  4. 基于Pull/Request(P/R)的分布式协同开发：

    • 流程：Fork → Clone → 本地修改 → Push → Pull-request → 代码审查 → 合并
    • 特点：简单、规范、透明

  5. 基于群智的知识分享：

    • 平台：Stack Overflow、CSDN
    • 流程：提问 → 回答和讨论 → 接受

SE3.4 Git介绍及使用

一、Git核心概念

  • 分布式版本控制系统：每个开发者拥有完整版本库副本
  • 核心区域：工作区 → 暂存区(Stage) → 本地版本库 → 远程版本库

二、基本操作

操作说明
clone克隆远程仓库到本地
add将工作区修改添加到暂存区
commit将暂存区内容提交到本地版本库
push将本地版本库推送到远程仓库
pull从远程仓库拉取最新代码
branch创建/管理分支
merge合并分支
checkout切换分支或恢复文件

三、分支管理

  • master分支：稳定发布版本，不直接修改
  • develop分支：开发汇总分支，各功能分支代码合并于此
  • 开发者分支：每个开发人员独立的功能分支

四、与群体化开发的关系

Git配合Pull/Request机制实现分布式协同开发：Fork → Clone → 本地修改 → Push → Pull-request → 代码审查 → 合并

SE4 软件需求分析基础

一、核心概念

  • 软件需求：用户对软件系统的期望和要求
  • 需求工程：系统化的需求获取、分析、规格说明和验证过程（需求获取→需求分析→需求规格说明→需求验证）
  • 利益相关方(Stakeholder)：用户、客户、开发者、维护者等所有与软件相关的人员或组织

二、需求分类

分类描述示例
功能性需求系统必须完成的功能登录、查询、下单
非功能性需求系统必须具备的质量属性性能、安全性、可靠性、可扩展性、可维护性
约束条件开发过程或产品必须遵守的限制技术平台、开发周期、法规

三、需求的质量要求

正确性、完整性、一致性、可验证性、可追踪性、无歧义性

四、需求分析的步骤

  1. 需求获取：收集系统需求信息
  2. 需求分析：理解、建模和细化需求
  3. 需求规格说明：形成需求文档
  4. 需求验证：评审确认需求的正确性

五、需求变更管理

  • 需求变更不可避免，需建立变更控制流程
  • 变更申请→变更评估→变更审批→变更实施→变更追踪

六、面向对象方法学核心概念

概念定义
对象(Object)包含属性和操作的实体
类(Class)具有相同属性和操作的一组对象的抽象
消息(Message)对象间通信的手段
继承(Inheritance)子类继承父类的属性和操作
多态(Polymorphism)同一操作在不同类中具有不同实现
聚合(Aggregation)整体-部分关系（弱关联）
组合(Composition)整体-部分关系（强关联，同生命周期）

七、UML建模语言

多视点建模——从不同角度描述系统的结构和行为。

八、需求分析的输出：软件需求规格说明书

SE5 获取软件需求

一、获取需求的方法

方法描述
访谈(Interview)直接与用户交流
问卷(Questionnaire)大规模收集信息
观摩(Observation)观察用户工作流程
原型(Prototyping)快速构建原型，以原型为媒介导出需求
群体化方法利用社区力量

二、用例图核心要素

  • 执行者(Actor)：系统外部的用户或其他系统
  • 用例(Use Case)：系统提供的功能
  • 包含关系(include)：用例A必然调用用例B
  • 扩展关系(extend)：用例A可选地在特定条件下扩展用例B
  • 继承关系：执行者之间或用例之间的泛化

三、需求确认与可行性分析

验证需求的正确性、完整性，进行可行性分析：

  • 技术可行性：现有技术能否实现需求
  • 经济可行性：开发成本和预期收益是否合理
  • 操作可行性：用户能否接受和使用系统

SE6 分析软件需求

一、分析软件需求的任务

  1. 细化用例，建立需求模型
  2. 分析用例交互（顺序图/通信图）
  3. 识别分析类（边界类、控制类、实体类）
  4. 建立分析类图和状态模型
  5. 需求优先级分析（MoSCoW法）

MoSCoW优先级法：

  • Must have（必须有的）：核心功能，没有则系统不可用
  • Should have（应该有的）：重要功能，短期可暂缺
  • Could have（可以有的）：锦上添花，有则更好
  • Won't have（不需要的）：本次不开发，以后考虑

二、UML图用于需求分析

图类型用途
顺序图描述对象间消息传递的时间顺序
通信图描述对象间消息传递的结构关系
类图（分析层次）边界类(<>)、控制类(<>)、实体类(<>)
状态图描述对象的状态变迁

三、软件需求规格说明书内容

引言、系统概述、功能需求、非功能需求、用例模型、分析模型等

SE7 软件设计基础

一、软件设计定义

针对软件需求，综合考虑各种制约因素，探究软件实现的解决方案。

  • 设计回答"如何做"(How)，是需求和实现间的桥梁
  • 设计的好坏直接决定最终产品质量

二、设计过程（从高到低抽象层次）

  1. 软件体系结构设计：全局宏观视角，高层抽象，模块为"黑盒子"
  2. 用户界面设计：软件对外展示和人机交互
  3. 软件详细设计：细化精化，包括数据设计、接口设计、类设计、算法设计

三、软件设计元素

元素定义
设计类最基本的设计单元
软构件可分离、可独立部署执行、可单独重用（如.dll、.jar）
子系统完成特定功能的一组模块集合

四、软件设计原则

  1. 抽象与逐步求精：抽象层次从体系结构→类→算法递进
  2. 模块化、高内聚度、低耦合度：
    • 内聚度（从低到高）：偶然性→逻辑性→时间性→过程性→通讯性→顺序性→功能性
    • 耦合度（从低到高）：非直接→数据→控制→特征→外部→公共→内容
  3. 信息隐藏：模块内部对外不可见，仅暴露接口
  4. 多视点和关注点分离
  5. 软件重用
  6. 迭代设计
  7. 可追踪性

五、面向对象设计优势

  • 从分析到设计使用相同概念，自然过渡
  • 多种形式和粗粒度的软件重用
  • 系统地支持所有设计阶段工作
  • 支持扩展和变更（接口、抽象类、继承、实现等机制）

SE8 软件体系结构设计

一、软件体系结构(SA)定义

从高层抽象角度刻画组成软件系统的设计元素及它们之间的逻辑关联。

二、三个核心设计元素

元素定义
构件(Component)物理模块，可分离、可替换、可配置、可复用
连接件(Connector)构件间的连接和交互关系
约束(Constraint)构件组合时应满足的条件

三、构件特性与接口

  • 特性：可分离（独立部署）、可替换（同接口可互换）、可配置（通过配置修改行为）、可复用
  • 接口类型：供给接口（对外提供）、需求接口（请求其他构件帮助所需）
  • 端口(Port)：绑定接口

四、软件体系结构的四视图

视图关注内容UML图
逻辑视图要素及关系包图、构件图
运行视图运行时进程/线程划分、并发同步—
开发视图代码组织及目录结构—
物理视图软构件部署及连接部署图

五、三类UML图

  • 包图：刻画包间的构成和依赖关系，包是一组逻辑关联的UML模型元素
  • 构件图：描述构件及构件间的构成和依赖关系
  • 部署图：描述软件系统可执行工件在运行环境中的分布情况（描述性：逻辑层面 / 实例性：物理层面）

六、设计模式的三个层次

体系结构风格 → 构件设计模式 → 实现设计模式

七、常用体系结构风格

风格描述适用场景
分层风格每层为其紧邻上层提供服务，使用紧邻下层服务；松耦合、可替换、可复用、标准化大部分应用软件
管道与过滤器数据流处理，过滤器以管道连接编译器、Web服务（数据驱动分级处理）
黑板风格黑板（状态数据）+知识源（求解）+控制器（调度）AI推理
MVC风格Model（业务逻辑）+View（界面）+Controller（调度）单机软件、Web应用
SOA风格服务提供方/请求方/注册中心松耦合云平台软件系统
消息总线风格统一消息总线连接各构件异构构件间消息通信密集型系统

八、MVC交互流程

用户动作 → Controller(控制器) → Model(模型) → View(视图) → 用户

九、体系结构设计过程

  1. 设计初步体系结构（辨识关键需求 → 选择合适风格 → 初创架构）
  2. 重用开源软件及已有软件资产
  3. 精化体系结构（确定基础设施 → 确立子系统/构件/类 → 接口协作）

SE9 用户界面设计

一、用户界面设计定义

设计软件对外展示以及与用户进行交互的界面，关注软件如何与用户进行交互。

  • 输出：告诉给用户的信息（显示内容）
  • 输入：需要用户提供的信息（操作入口）

用户界面是用户与软件系统的"接触面"，直接影响用户体验和系统可用性。

二、用户界面设计原则

原则说明
用户友好性界面直观，操作简便，符合用户习惯
一致性保持界面风格、术语、操作方式统一
反馈性对用户操作给出即时反馈（如加载提示、错误提示）
容错性提供撤销/恢复功能，防止误操作造成严重后果
简洁性信息布局清晰，避免界面混乱和信息过载
可访问性考虑不同用户群体（如色盲、老年人）的使用需求

三、用户界面设计过程

  1. 用户分析：理解用户特征、使用场景和操作习惯
  2. 任务分析：分析用户需要完成的操作任务
  3. 界面原型设计：绘制线框图和交互原型
  4. 界面实现：编写前端代码实现界面
  5. 可用性评估：通过用户测试检验界面质量

四、设计关注的质量要素

直观、友好、易于操作、易于理解、响应迅速

五、相关UML表示

可用交互图（顺序图、通信图）来表示用户界面元素与系统其他设计元素之间的交互协作。

SE10 软件详细设计

一、详细设计定义

对体系结构设计和用户界面设计成果进行细化和精化，获得高质量、面向实现的设计模型。

二、详细设计的核心活动

活动内容
用例设计给出用例的具体实现方案（顺序图+类图）
类设计明确类的内部实现细节（属性、方法、关系、状态图、活动图）
数据设计设计持久数据及其结构和操作
子系统/构件设计细化粗粒度设计元素的内部结构

三、分析类与设计元素的对应关系

  • 一个分析类职责由一个设计元素操作完整实现
  • 一个分析类职责由多个设计元素多项操作实现（细化分解）
  • 一个分析类职责由多个设计元素协同完成

四、类设计过程

  1. 确定可见范围（public/protected/private，尽量缩小可见范围）
  2. 精化类间关系（继承 > 组合 > 聚合 > 关联 > 依赖）
  3. 构造状态图和活动图
  4. 精化属性和方法
  5. 评审和优化

五、数据设计（对象-关系映射）

  • 类 → 表格、对象 → 记录、属性 → 字段
  • 1:1 / 1:n 映射：外键
  • n:m 映射：交叉表（中间表）
  • 继承关系映射（两种方式）：
    1. 全部字段引入一张表（冗余但快）
    2. 仅引入关键字外键（节省空间）

六、消息传递的四种方式

  1. 引用全局对象（依赖关系）
  2. 通过参数传递（依赖关系）
  3. 引用局部对象（依赖关系）
  4. 通过类成员变量（聚合/组合关系）

七、设计评审内容

规范性、简练性、正确性、可实施性、可追踪性、一致性、高质量

SE11 软件实现基础

一、软件实现定义

根据软件设计模型，编写程序代码，并对代码进行测试，发现和纠正缺陷，部署到目标计算机运行。

  • 兼具创作和生产属性

二、实现过程

编码 → 单元测试 → 调试 → 集成测试 → 确认测试 → 系统测试

三、实现原则

基于设计编码（切忌"拍脑袋"写程序），质量保证贯穿全过程

四、程序设计语言类别

类别特点代表语言
机器语言"0""1"组成，执行效率高但繁琐—
汇编语言助记符代替机器码，速度快但可读性差—
结构化语言过程/函数为基本单元，三类控制结构C、Fortran、Pascal
面向对象语言类为基本模块单元Java、C++
描述性语言描述需要解决什么问题Prolog、Lisp

五、语言选择依据

  • 软件应用领域
  • 与遗留系统交互需求
  • 软件特殊功能需求
  • 目标平台（J2EE→Java，ROS→C/C++/Python）
  • 程序员经验

六、程序员能力要求

自我学习能力、独立解决问题能力、良好编程习惯、质量意识、测试能力、阅读他人代码、善用CASE工具、团队合作

SE12 编写代码

一、编写代码的五大原则

  1. 易读，一看就懂
    • 理解代码语义和内涵
    • 望文生义的符号命名
    • 合理缩进和括号
    • 关键语句、方法加注释
  2. 简明，降低复杂度
    • 不用 goto 语句
    • 减少嵌套层数
    • 选择简单算法
    • 一个类一个文件，统一命名规则
  3. 易改，便于维护
    • 对可能修改的代码进行抽象、参数化、封装
    • 以便修改时不波及无关代码
  4. 无二义，不产生歧义
    • 代码逻辑清晰，不让人产生误解
  5. 尽可能地开展软件重用和编写可重用代码

二、异常处理

  • 编写异常定义和处理代码（try-catch）
  • 防止异常导致程序终止或崩溃
  • 支持故障检测、恢复和修复
  • 确保程序在严重错误时仍可运行或快速恢复

三、编码与设计的关系

  • 基于设计编码，切忌"拍脑袋"写程序
  • 设计不足时，程序员需补充设计
  • 发现设计问题应反馈修正

SE14 软件部署

一、基本概念

  • 软件运行环境：软件运行所依赖的上下文，包括OS、第三方软件、中间件/开发框架
  • 软件间关系：
    • 纵向层次性：依赖基础软件系统
    • 横向相关性：需与其他软件系统交互
  • 运行环境变化：大中小型机 → PC → 局域网 → 互联网 → 无处不在计算

二、软件部署定义

将目标软件系统进行收集、打包、安装、配置和发布到运行环境的过程。

两方面工作：

  1. 安装配置运行环境
  2. 安装配置软件系统

三、部署三原则

最小化、相关性、适应性

四、部署方式

方式描述示例
单机部署各要素集中部署在单一设备小米便签、扫雷游戏
分布式部署分散在多个设备淘宝、Google、12306

分布式的具体形式：C/S部署、客户端-应用服务器-数据库服务器部署、互联网部署

五、部署方法

  1. 基于操作系统部署（直接运行在OS之上）
  2. 基于软件开发框架部署
  3. 基于软件中间件部署
  4. 基于容器和镜像部署（Docker）

六、容器部署（Docker）

  • 特点：视图隔离、资源可限制、独立文件系统的进程集合
  • 镜像：包含应用代码 + 所有依赖
  • 与宿主机关系：共享内核
  • 部署流程：选定基础镜像 → 编写Dockerfile → 创建软件镜像 → 创建并运行容器

七、相关CASE工具

Fat jar（Java打包）、Installer Projects（Windows安装包）、Jenkins（持续集成部署）

SE15 软件维护与演化

一、软件维护定义

软件在交付使用后，由于应用需求和环境变化以及自身问题，对软件系统进行改造和调整的过程。

二、四种维护形式

类型描述示例
纠正性维护纠正软件中的缺陷和错误修bug
适应性维护适应新的运行环境和平台Windows→Linux迁移
完善性维护增加新功能、修改已有功能功能迭代
预防性维护改善可靠性和可维护性，为未来改进奠定基础代码重构

三、维护特点

  • 同步性：维护需与软件使用同步进行
  • 周期长：软件会服役十几年甚至几十年
  • 费用高：维护成本高达总成本 80% 以上，维护费用是开发费用的 3 倍以上
    • 1970s: 35-40%，1980s: 60%，1990s: 75%，如今更高
  • 难度大：50%-90% 时间用于理解程序，尤其是文档缺失时

四、软件演化 vs 软件维护

维度软件演化软件维护
功能增强粒度粗粒度细粒度
应对变化方式主动被动
持续性是间隔性
版本变化是不一定

五、Lehman软件演化八法则

  1. 持续变化法则：不持续修改会越来越不实用
  2. 增加复杂性法则：除非采取措施降低复杂性，否则越来越复杂
  3. 自我调节法则：演化过程自我可调节
  4. 组织稳定性守恒法则：新版本平均额外工作量相同
  5. 熟悉度守恒法则：平均增量增长相同
  6. 功能持续增长法则：功能必须持续增加，否则用户满意度降低
  7. 质量衰减法则：代码变更导致质量逐渐下降
  8. 反馈系统法则：多回路活动和多层次反馈

六、软件逻辑老化

  • 定义：维护演化中出现的用户满意度降低、质量下降、变更成本上升的现象（逻辑层面非物理层面）
  • 现象：质量下降、变更成本增加、用户满意度降低
  • 原因：
    • 缺乏变更（外部环境变化而未响应）
    • 负面变更（引入新缺陷、破坏结构）
  • 表现：设计僵化、设计脆弱、模块紧耦合、晦涩设计

七、解决逻辑老化的方法

方法描述
代码重组不改变功能，重新组织代码，提高可维护性
逆向工程从低抽象层次产生高抽象层次制品（代码→设计→需求）
设计重构通过分析代码获得设计文档（逆向工程的具体形式）
再工程逆向工程 + 正向工程，实现更高质量软件系统

八、软件维护过程

分析维护申请 → 研读代码文档 → 规划方案 → 修改设计 → 更改代码 → 测试交付 → 评估分析

九、维护成本公式

M = P + K × e^(c-d)

  • c = 复杂度
  • d = 熟悉程度

十、维护需要解决的问题

  • 人员问题：缺乏成就感、不重视、流动大
  • 制品问题：无文档、代码可读性差、文档与代码不一致、版本混乱
  • 副作用问题：代码副作用、数据副作用、文档模型副作用

十一、软件可维护性

在开发时就考虑维护问题，软件被理解、改正、调整和改进的程度。

  • 影响因素：开发方法、文档齐全、标准化、易于扩展、结构清晰、标准语言
  • 各阶段复审：需求 → 设计 → 编码 → 测试 → 维护完成时

SE16 软件项目管理

一、基本概念

  • 项目：为创建唯一产品或提供唯一服务而进行的努力，存在约束、实施活动、提供产品和服务
  • 项目特点：目标性、进度性、约束性、多方性、独立性、不确定性
  • 软件项目管理：对软件项目涉及的过程、人员、产品、成本和进度等要素进行度量、分析、规划、组织和控制的过程

二、三类管理对象

对象关注
过程(How)过程定义、软件度量、项目计划、项目跟踪、风险管理
人员(Who)团队建设、激励机制
产品(What)质量保证、配置管理、需求管理、风险控制

三、软件度量基本概念

术语定义
度量(Metrics)对产品、过程或资源简单属性的定量描述（如代码行数）
测量(Measure)复杂属性的定量描述，用于事后（如可靠性）
估算(Estimation)复杂属性的定量描述，用于事前（如成本）

四、度量对象属性

属性类型特征示例
内部属性（易测量）与产品直接相关代码长度、功能、重用性、耦合内聚度
外部属性（难测量）与环境相关可靠性、可理解性、质量、可维护性

五、面向规模的度量

用代码行数(KLOC)表示规模：

  • 生产率 PM = L/E
  • 每千行成本 CKL = S/L
  • 文档代码比 Dl = Pd/L
  • 代码出错率 EQRl = Ne/L

六、CoCoMo模型

  • E = a × (kLOC)^b（工作量估算）
  • D = c × E^d（时间估算）
  • 三种软件类型：组织型、半独立型、嵌入型

七、项目计划

对活动、人员安排、任务划分、进度、资源分配的预先规划。

依据：开发过程、工作任务、历史数据/估算模型、约束限制

八、软件开发工作量分布

  • 分析和设计：40-50%
  • 测试和调试：30-40%
  • 编码实现：10-20%

九、软件项目成功影响因素

项目范围、进度计划、客户满意度、开发成本

选择题

大家根据课件里面的内容以及课件上的习题来复习。如果时间有够的话，课件完整过一遍，如果时间不够的话，那就把课件上面的练习题看一下。课件上面的练习题如果会做了，那么考试的选择题和判断题是没有问题的，尽管没有原题。

课件原题如下

SE1.1 程序及质量保证方法

1.【2022计算机统考408】 将高级语言源程序转换为可执行目标文件的主要过程是（ ）。

  • A 预处理 → 编译 → 汇编 → 链接
  • B 预处理 → 汇编 → 编译 → 链接
  • C 预处理 → 编译 → 链接 → 汇编
  • D 预处理 → 汇编 → 链接 → 编译
正确答案：A

解析
预处理：处理源代码中的预处理指令，如#include（文件包含）、#define（宏定义）等。
编译：将预处理后的源代码翻译成汇编语言代码，输出是汇编语言文件。
汇编：将汇编语言代码翻译成机器指令，生成可重定位目标文件。
链接：将一个或多个目标文件以及所需的库文件合并在一起，解析外部引用，生成一个可执行目标文件 （如Windows下的.exe文件）。
  1. 关于模块化设计中的“高内聚、低耦合”原则，下列说法正确的是（ ）。
  • A 高内聚是指模块间接口尽可能简单
  • B 低耦合是指模块内部元素联系紧密
  • C 高内聚有利于模块的复用和维护
  • D 低耦合会导致系统性能下降
答案：C
解析： 高内聚指模块内部元素关联紧密，功能单一，有利于复用和维护；低耦合指模块间依赖关系弱，接口简单，有利于系统扩展和修改。A、B选项混淆了概念，D选项错误，低耦合通常有利于系统维护和扩展，不一定导致性能下降。

SE1.2 软件及其特点

  1. 软件生命周期中，主要任务是“确定软件必须做什么”的阶段是（ ）。
  • A 软件设计
  • B 编码实现
  • C 需求分析
  • D 运行维护
答案：C
解析： 本题考查软件生命周期各阶段的核心任务。课件中的生命周期图清晰地标明了“What：软件需求是什么”的阶段，即需求分析。该阶段的核心任务是准确理解用户的需要，定义系统的功能、性能和约束，解决“做什么”的问题。
  1. 下列软件中，属于系统软件的是（）。 I. MySQL数据库管理系统 II. 微信 III. 华为OpenHarmony操作系统 IV. Eclipse IDE
  • A I、II
  • B I、III
  • C II、IV
  • D III、IV
答案：B 

解析： 
I. MySQL：是数据库管理系统（DBMS），是典型的系统软件。
II. 微信：是面向特定领域（社交）的应用软件。
III. OpenHarmony：是操作系统，是系统软件的核心。
IV. Eclipse：是辅助软件开发的工具，属于支撑软件。

SE2 软件工程概述

  1. 以下关于软件工程三要素的描述中，错误的是（）。
  • A “过程”要素定义了工作的步骤和次序，从管理的视角指导“做什么”和“何时做”
  • B “方法”要素提供了技术手段，从技术的视角解决“如何做”的问题
  • C “工具”要素为过程和方法提供自动化的支持，旨在替代开发人员的手工劳动
  • D 过程、方法和工具三者相互独立，又相互联系，共同构成软件工程的学科框架
答案：C
解析： 本题考查对三要素内涵及其关系的深入理解。
A和B选项准确描述了“过程”和“方法”要素的核心思想。
C选项是错误的。工具的目的是“辅助”或“支持”开发过程，提高效率和质量，而不是“替代”开发人员的智慧和创造性劳动。课件中强调工具是“辅助软件开发”、“提高效率”、“简化任务”。
D选项正确描述了三者之间辩证统一的关系。
  1. “在绘制软件架构图时，我们只关心组件之间的交互关系，而不关心每个组件内部是用什么编程语言实现的。” 这句话描述的是（ ）原则的应用。
  • A 分而治之
  • B 抽象
  • C 模块化
  • D 信息隐藏
答案：B

解析：
抽象的核心思想是忽略与当前目标无关的细节，只关注与当前目标相关的方面。在架构设计层面，关心的是组件和交互，而忽略语言实现细节，这正是“抽象”原则的典型体现。

其他原则：
A. 分而治之：强调分解复杂问题，与“忽略细节”的侧重点不同。
C. 模块化：是抽象的结果之一，但题干强调的是“思考过程”（忽略什么，关心什么），这是抽象的本质。
D. 信息隐藏：是一种具体的设计技术，是实现抽象的一种手段，但题干描述更偏向于概念层面的“抽象”。
  1. 某个需求变更导致需要修改数据库表结构时，开发人员需要评估这一修改会影响哪些业务逻辑模块、哪些界面显示单元，以及是否需要同步修改相关的API文档。这一做法最直接地体现了（ ）原则。
  • A 软件重用
  • B 双向追踪
  • C 工具辅助
  • D 抽象和建模
答案：B
解析：
双向追踪原则强调追踪软件制品之间的关联关系。当某一制品（如数据模型）发生变化时，需要进行正向追踪（会影响哪些其他制品），以评估变更影响范围，确保一致性。题干描述的场景正是这一原则的典型应用。

A. 软件重用：强调使用已有组件，与题意无关。
C. 工具辅助：虽然可以使用工具来辅助实现追踪，但题干强调的是“做法”背后的“原则”，而非工具本身。
D. 抽象和建模：是创建这些制品的基础，但题干焦点不在“创建”而在“变更与追踪”。

SE3.1 软件过程模型

  1. 瀑布模型最突出的缺点之一是（ ）。
  • A 开发活动之间缺乏明确的顺序关系
  • B 难以应对软件开发过程中需求的变化
  • C 无法生成高质量的软件文档
  • D 需要开发人员具备很高的编程技能
答案：B
解析： 本题考查对瀑布模型本质缺点的理解。

瀑布模型要求每一阶段的活动必须在前一阶段活动完成后才能开始，阶段间具有严格的顺序性和依赖性。这种线性顺序模型假设需求在早期就能被完全、精确地定义，且不会发生变化。然而，现实中的软件需求往往具有易变、多变的特点，一旦后期需求发生变化，在瀑布模型下进行修改将非常困难且代价高昂，这正是其最受诟病的缺点。

A、C、D选项的描述均不是瀑布模型的主要缺点。
  1. 与瀑布模型相比，增量模型和迭代模型共同的优点是（ ）。
  • A 完全避免了编写详细设计文档的需要
  • B 在开发早期就能得到部分可运行的软件功能
  • C 彻底消除了软件开发中的所有风险
  • D 保证第一次增量或迭代就能交付最终产品
答案：B
解析： 本题考查对增量/迭代模型核心价值的理解。无论是增量模型的“分块实现”还是迭代模型的“循环求精”，它们都打破了瀑布模型的线性顺序，通过将系统功能分批次地分析、设计、实现和测试，使得在项目早期就能让用户看到或用到部分成果。这有助于尽早获得反馈，降低项目风险。

A选项错误，它们仍需要设计，只是文档的侧重点和形式可能不同；C选项过于绝对，风险只能被降低而非消除；D选项错误，增量/迭代模型正是通过多次交付来逐步完成整个产品。
  1. 与增量模型相比，迭代模型更强调（ ）。
  • A 每个增量都必须是一个功能完整、可交付的产品子集。
  • B 每次迭代都可能对之前迭代所完成的功能进行重构和深化。
  • C 必须首先完成所有需求的概要设计。
  • D 增量的划分必须严格按照功能模块进行。
答案：B
解析： 本题考察增量与迭代的微妙区别。这是软件工程中的经典辨析点。
增量开发：侧重于分块构建，每个增量增加一块新的、完整的功能，通常假设需求架构稳定。
迭代开发：侧重于循环求精，每次迭代都走过一个完整的开发周期，不仅可能增加新功能，更重要的可能在于对已有功能的重新理解、修改甚至重构，从而使系统整体认知和质量逐步深化。

因此，B选项是迭代模型更强调的特点。A选项是增量模型的特点。C和D选项不是两者的本质区别。
  1. 关于瀑布模型与原型模型的主要区别，以下描述最准确的是（ ）。
  • A 瀑布模型不编写代码，而原型模型需要编写代码。
  • B 瀑布模型适用于大型项目，而原型模型只适用于小型项目。
  • C 瀑布模型假设需求在早期即可固定，而原型模型承认需求的模糊性和易变性，并通过快速反馈来澄清需求。
  • D 瀑布模型的管理成本更低，而原型模型的管理成本更高。
答案：C
解析： 本题考察对两种模型根本区别的理解。瀑布模型是文档驱动和计划驱动的，其基石是“需求早期确定”；而原型模型是反馈驱动的，其出发点正是承认“需求难导出、不易确定”，需要通过原型作为沟通媒介来逐步明确需求。这是两者最本质的差异。
A选项错误，两者都涉及编码（原型也要实现）；B选项错误，模型选择主要基于项目特征（如需求明确性）而非单纯的项目规模；D选项不是本质区别，且不一定成立。
  1. 螺旋模型区别于其他过程模型的一个最显著特征是（ ）。
  • A 包含了编码和测试活动
  • B 活动是按阶段顺序进行的
  • C 明确地将风险分析作为每个循环的核心环节
  • D 支持用户界面的快速原型开发
答案：C
解析： 本题考查对螺旋模型独特性的把握。螺旋模型结合了迭代开发和原型方法的优点，但其最根本的特征是风险驱动。它在每个迭代循环中都明确设置了“风险分析”这一关键任务，通过识别、分析和应对项目风险（如技术风险、需求风险）来决定项目是否继续、如何继续。这是它与其他模型（如单纯的迭代模型或原型模型）最本质的区别。

A、B选项是许多模型共有的，D选项是原型模型的典型特征。
  1. 某团队承接一个银行核心交易系统的升级项目。该系统需求明确、稳定，对可靠性、安全性要求极高，且受到严格的行业法规约束。在这种情况下，最适合采用的软件过程模型是（ ）。
  • A 原型模型
  • B 迭代模型
  • C 瀑布模型
  • D 敏捷开发模型
答案：C
解析： 本题考查根据项目特征选择模型的能力。题干中的关键词“需求明确、稳定”、“可靠性、安全性要求极高”、“严格法规约束”都指向了需求变更成本极高、需要严格流程和控制的项目类型。瀑布模型因其文档齐全、阶段清晰、过程可控的特点，非常适合这类对质量保证和过程追溯有严苛要求的项目。

原型和迭代模型更适用于需求不明确的探索性项目，敏捷模型则强调响应变化，可能与严格的法规约束存在冲突。

7.一个项目旨在为一家初创公司开发一款新的移动应用，该应用的核心功能概念新颖，但详细需求在项目开始时非常模糊，且预计在市场测试后会有较大变动。为该项目选择以下哪种过程模型最为合适？（ ）

  • A 瀑布模型
  • B 增量模型
  • C 原型模型或迭代模型
  • D 任何模型都可以，没有区别
答案：C
解析： 本题考查根据项目特点选择合适过程模型的能力。题干描述的项目具有需求不明确、易变动的典型特征。
A. 瀑布模型：要求需求明确且稳定，完全不适用。
B. 增量模型：前提是总体需求清晰，只是分块实现，但本题是总体需求都不清。
C. 原型模型或迭代模型：原型模型非常适合通过快速构建原型来澄清和细化需求；迭代模型允许通过一系列迭代循环来逐步明确和实现需求，都能很好地应对需求不确定性。因此C是最佳选择。
D. 显然错误。

SE3.2 敏捷开发方法

  1. 以下哪一项（ ）最准确地体现了敏捷开发方法的核心价值观，并以此区别于传统的“以文档为中心”的重型方法？
  • A 强调在项目初期制定详尽且不可更改的计划。
  • B 将可运行的软件视为衡量进展的主要指标。
  • C 要求所有沟通都必须有正式的书面记录以备追溯。
  • D 认为严格的流程和工具是项目成功的保证。
答案：B
解析： 本题考查对敏捷核心价值观的把握。敏捷宣言的首要原则就是“个体和互动高于流程和工具”、“可工作的软件高于详尽的文档”。选项B直接对应“可工作的软件”这一核心价值观，是敏捷方法区别于传统重型方法（强调文档、计划、流程）的最显著标志。

A、C、D选项描述的都是传统重型方法的典型特征，与敏捷思想背道而驰。
  1. 在极限编程的实践中，“结对编程”这一技术最主要的目标是（ ）。
  • A 将开发团队的人员数量减少一半以节省成本。
  • B 通过实时的代码审查和知识共享，持续提升代码质量并促进团队学习。
  • C 让一名资深程序员完全主导编码，另一名初级程序员仅负责观察和学习。
  • D 为了在单位时间内编写出两倍数量的代码。
答案：B
解析： 本题考查对特定敏捷实践目的的理解。结对编程的核心价值不在于提高瞬时编码速度或节省成本，而在于通过持续的、实时的协作来改善代码设计、减少缺陷（相当于实时代码评审）、并在团队成员间无缝传递知识和技术，从而在长期内提高整体代码质量和团队能力。

A和D是对结对编程经济效益的常见误解。C描述了一种不平等的、非协作的状态，不符合结对编程倡导的平等、协作精神。
  1. 测试驱动开发的核心工作流程是（ ）。
  • A 编写大量代码 -> 然后设计测试用例来验证这些代码 -> 运行测试。
  • B 先编写程序代码实现功能 -> 再编写测试代码以确保功能正确 -> 最后重构。
  • C 先为一个小功能编写一个失败的测试 -> 编写最简单的代码使测试通过 -> 重构代码以优化设计。
  • D 由专门的测试团队在开发完成后独立设计并执行所有测试。
答案：C
解析： 本题考查对TDD经典“红-绿-重构”循环的准确记忆。TDD的本质是通过测试来驱动设计和开发。其标准流程严格遵循：1. 红：编写一个必定会失败的测试（定义需求）；2. 绿：用最简单的方式编写代码，只求让测试通过（满足需求）；3. 重构：在测试保护下，优化代码结构，消除重复，提升设计质量。A和B选项颠倒了编码与测试的顺序，是传统开发方式。D选项描述的是独立的测试活动，与TDD无关。
  1. Scrum方法中的“Sprint”活动（冲刺）最直接地体现了以下哪项敏捷原则？（ ）
  • A 可持续的开发节奏。
  • B 欢迎需求变化，即使是在开发后期。
  • C 定期反思如何能提高效能，并据以调整自身行为。
  • D 以简短的时间周期（如几周）持续地交付可工作的软件。
答案：D
解析： 本题考查将具体实践与敏捷原则关联的能力。Scrum的核心实践“Sprint”是一个固定时长（通常1-4周）的迭代，其目标就是在每个Sprint结束时产生一个潜在可发布的、增量式的产品功能。这直接、具体地体现了敏捷宣言中“经常地交付可工作的软件，交付的间隔可以从几星期到几个月，倾向于采取更短的时间周期”这一原则。

A（可持续节奏）和C（定期反思）也是Scrum的原则，但“Sprint”活动本身最直接体现的是“短期交付”。B原则更多由产品待办列表的更新机制来体现。
  1. 与传统瀑布模型相比，敏捷开发方法更适用于以下哪种类型的项目？（ ）
  • A 需求在项目初期就被完整、清晰地定义，且在整个开发周期内预期不会发生变化。
  • B 项目受到严格的外部法规约束，需要产生大量审计追踪文档。
  • C 项目目标探索性强，需求模糊且可能在开发过程中频繁变化，需要快速响应用户反馈。
  • D 开发团队规模庞大且地理位置分散，主要依靠文档进行异步沟通。
答案：C
解析： 本题考查根据项目特征选择开发方法的能力。敏捷方法诞生的初衷就是为了应对需求不确定、易变化的环境。其迭代、增量、强调客户协作和响应变化的特点，非常适合选项C所描述的场景。而A选项描述的场景正是瀑布模型的理想适用情况。B和D选项描述的环境（强文档要求、大型分布式团队）会给纯敏捷实践带来挑战，通常需要混合方法或重型方法。

SE3.3 群体化软件开发方法

  1. 在典型的开源软件社区中，关于“核心开发人员”与“外围开发人员”的职责，以下说法正确的是（ ）。
  • A 核心开发人员负责提出大部分新功能需求和Bug报告。
  • B 外围开发人员拥有直接将代码合并到主分支（master）的权限。
  • C 核心开发人员主要负责评审外围开发人员提交的代码，并决定是否将其合并到主仓库。
  • D 外围开发人员的任务是强制指派的，必须完成
答案：C

解析： 本题考查对开源社区角色分工的理解。核心开发人员是项目的守护者，负责评审代码、管理合并；而外围开发人员是广泛的贡献者，自发地提出Issue、提交代码。

A选项描述的任务更多由外围人员完成；B选项错误，直接合并主分支通常是核心人员的权限；D选项错误，群体化开发强调“自愿”而非“强制指派”。

SE3.4 Git介绍及使用

无选择题

SE4 软件需求分析基础

  1. 在“空巢老人看护系统”中，“系统应能检测老人是否摔倒”和“对机器人的控制应在2秒内响应”分别属于（ ）。
  • A 都是功能性需求
  • B 都是质量需求
  • C 前者是功能性需求，后者是质量需求
  • D 前者是质量需求，后者是功能性需求
答案：C，本题考查对软件需求基本分类的准确理解。

功能性需求 指系统“做什么”，即系统必须执行的功能或行为。“检测老人是否摔倒”描述了系统需要具备的一项具体功能，属于功能性需求。

质量需求（或称非功能性需求）指系统“做到什么程度”，是系统在运行时可被观察到的行为表现。“2秒内响应”是对系统性能的要求，属于质量需求。
因此，C选项正确。
  1. 软件需求具有“多源性”的特点。这一特点最直接可能导致以下哪个问题？（ ）
  • A 用户对软件的期望和要求会经常性地发生变化。
  • B 不同的利益相关方提出的需求可能存在冲突和不一致。
  • C 需求隐晦地存在于利益相关方的潜意识中，难以表达。
  • D 需求的内涵与软件所在领域的专业知识强相关。

答案：B，解析： 本题考查对需求特性所引发问题的理解。

多源性 指需求来源于多个不同的利益相关方（如用户、客户、开发者等）。由于不同角色的立场、目标和背景知识不同，他们提出的需求自然可能存在冲突和不一致。这正是“多源性”带来的直接挑战。

A选项对应的是“易变性”；C选项对应的是“隐晦性”；D选项对应的是“领域知识的相关性”。
  1. 以下哪一项是评价软件需求质量的核心要求，意味着“需求描述应该是清晰和准确的，不会让人产生不同的理解”？（ ）
  • A 完整 (Complete)
  • B 一致 (Consistent)
  • C 无二义 (Unambiguous)
  • D 可验证 (Verifiable)
答案：C，本题考查对需求质量属性的识记与区分。

无二义性 直接要求需求的表述必须清晰、准确，避免模糊和歧义，确保所有阅读者都能得到唯一、一致的理解。

A选项“完整”强调没有遗漏；B选项“一致”强调需求间不冲突；D选项“可验证”强调需求能否通过测试等方式被检验。
  1. 在面向对象需求分析中，“多态”（Polymorphism）机制允许（ ）。
  • A 子类继承父类的所有属性和操作。
  • B 一个对象由多个其他对象作为其组成部分。
  • C 一个子类拥有多个父类。
  • D 相同名称的操作在不同的类中可以有不同的具体实现。
答案：D， 本题考查对面向对象核心概念“多态”的精准把握。

多态 的核心是“同一接口，多种实现”。它允许在继承层次结构中，父类定义的同一个操作（或方法）在子类中有不同的具体实现。当消息发送给对象时，系统能自动选择正确的实现。

A选项描述的是“继承”的基本特性；B选项描述的是“聚合/组合”关系；C选项描述的是“多重继承”。
  1. UML（统一建模语言）在需求工程阶段的主要作用是（ ）。
  • A 直接生成可执行的程序代码。
  • B 作为项目管理和进度跟踪的工具。
  • C 对软件系统进行可视化建模，以支持不同人员之间的交流和对需求的理解。
  • D 替代自然语言，成为编写软件需求文档的唯一形式。
答案：C，本题考查对UML在需求工程中核心价值的理解。

UML是一种图形化建模语言，其首要目的是为了可视化地描述系统，从而促进开发人员、客户、用户等不同角色之间的沟通和交流，共同理解需求。这是它在需求分析阶段最重要的作用。

A选项是部分CASE工具可能具备的高级功能，并非UML的核心目的；B选项不是UML的主要功能；D选项错误，UML模型通常与自然语言描述相辅相成，而非替代关系。

SE5 获取软件需求

  1. 某团队开发一个“智能校园食堂”系统。在需求收集阶段，收到了以下诉求：
  • ① 学生代表提出，希望能通过手机APP实时查看每个窗口的排队人数。
  • ② 食堂经理要求，系统必须能自动生成每日的菜品销售报表，以优化采购。
  • ③ 学校后勤处规定，系统必须使用学校统一身份认证系统进行登录。
  • ④ 投资方建议，未来可以加入根据学生健康数据推荐菜品的功能。
  • ⑤ 一名开发人员认为，应该采用最新的微服务架构，以便后期维护。

根据课件中关于“软件利益相关方”和“合法软件需求”的论述，上述诉求中最应该被优先考虑并纳入初步需求范围的是？

A ①、②、③ B ①、②、⑤ C ②、③、④ D ③、④、⑤

答案：A
解析：①和②直接来自核心利益相关方（学生和食堂经理），解决了明确的业务问题（减少排队时间、优化运营），符合“有意义、有价值”的需求标准。
③是来自重要利益相关方（学校后勤处）的约束性要求，必须遵守。④（投资方建议）属于未来规划，在初步需求阶段优先级不高。⑤（开发人员技术选型）属于解决方案的设计决策，而非源自业务问题或外部利益相关方的“需求”本身。课件强调“并非软件利益相关方提出的每项期望和要求都是软件需求”，需求工程师需要鉴别真正有价值的需求。
  1. 为一个大型医院开发新的“门诊流程优化系统”，目标是减少患者无效移动和等待时间。需求工程师小张发现，现有的门诊流程涉及分诊台、医生、药房、收费处等多个角色，且流程复杂，有些隐性规则甚至医护人员自己也难以清晰描述。此时，为了最有效地获取原始、准确的一手需求，小张应该首选哪种需求获取方法？
  • A 设计详细的调查问卷，发放给所有医护人员。
  • B 分别访谈医院的院长和各科室主任。
  • C 直接构造一个可运行的系统原型，请医护人员试用。
  • D 花费数天时间在现场观摩各个岗位的实际工作流程。
答案：D
解析：课件中“现场观摩”方法适用于了解“业务过程、步骤和输出”及“业务工作流程及细节”。在该情境中，流程复杂且存在难以言表的隐性知识，现场观摩能够最直接、客观地捕获到实际操作中的细节和问题，这是其他方法无法替代的。

A（调查问卷）难以捕捉复杂的、动态的流程细节。
B（访谈领导）无法获取一线操作人员的真实情况。
C（软件原型）在需求很不明确时盲目构建，效率低下且可能误导方向。
  1. 在“智慧城市交通信号灯协调系统”的需求文档中，列出了以下要求：
  • R1：系统应能根据实时车流量，动态调整信号灯的红绿灯时长。
  • R2：在路口网络通信中断的情况下，单个路口的信号灯控制器应能依靠本地逻辑维持基本运行至少48小时。
  • R3：系统后台管理界面的响应时间应在3秒以内。
  • R4：信号灯控制算法的源代码必须用C语言编写，以便部署到现有的硬件设备上。

根据课件对非功能性需求的分类，上述要求中属于质量要求的是？

A.R1,R2 B.R2,R3 C.R3,R4 D.R1,R4

答案：B
解析：
质量要求：关注软件运行的品质。
R2（通信中断后维持运行）体现了可靠性。
R3（响应时间）体现了性能。

其他分类：
R1（动态调整时长）是系统的核心功能性需求，描述了系统“做什么”。
R4（必须用C语言）是约束性要求，是对开发过程的技术限制。
  1. 在“在线考试系统”的用例建模中，需求工程师识别出以下行为：“参加考试”用例必须包括“用户身份验证”这一步骤；同时，“参加考试”过程中，如果考生遇到系统崩溃等异常情况，可以触发“申请异常重考”的流程。根据UML用例图关系，以下建模方案最合理的是？
  • A “参加考试”用例包含“用户身份验证”用例，“申请异常重考”用例扩展“参加考试”用例。
  • B “参加考试”用例包含“用户身份验证”和“申请异常重考”两个用例。
  • C “申请异常重考”用例包含“参加考试”用例，“参加考试”用例包含“用户身份验证”用例。
  • D “参加考试”用例扩展“用户身份验证”用例，并包含“申请异常重考”用例。
答案：A
解析：包含关系：用于表示一个用例（参加考试）必须执行另一个用例（用户身份验证）的功能。身份验证是参加考试不可或缺的子功能。
扩展关系：用于表示一个用例（申请异常重考）在特定条件（系统崩溃）下，可以选择性地扩展另一个用例（参加考试）的行为。异常重考不是每次参加考试都会发生的，是对主流程的扩展。

课件中明确指出了包含和扩展的区别：包含是子功能，必须执行；扩展是附加动作，在特定点插入。
  1. 在某项目的初步需求文档中，对“商品搜索”功能有如下描述：“用户应能方便地搜索到他们想要的商品。”在需求评审会上，大家指出了该描述的诸多问题。根据课件内容，以下哪一项不属于该描述存在的典型缺陷？
  • A 不具体：没有说明“方便地”具体指什么，比如是支持关键词、分类过滤还是模糊搜索。
  • B 不准确：没有界定“商品”的范围，是否包括下架商品或待审核商品。
  • C 技术不可行：以目前的技术，无法实现商品搜索功能。
  • D 有二义性：不同人员对“想要的商品”可能有不同理解，比如是基于历史记录推荐还是用户主动搜索。
答案：C
解析：课件在“自然语言描述的不足”中明确指出了“不具体”、“不准确”、“有二义”是该描述方式的典型问题。选项A、B、D准确地对应了这些缺陷。

选项C“技术不可行”属于“可行性分析”范畴。单从这句描述本身，无法得出技术不可行的结论。该描述的核心问题在于其质量（模糊、不明确），而非可行性。

6.一个创业团队计划开发一款“AR实景翻译眼镜”，用户戴上后能看到真实世界中外语标识的实时翻译。在立项前的可行性分析中，团队评估了以下因素：

  • ① 现有的AR显示和图像识别技术能否支持长时间、高精度的实时翻译。
  • ② 产品的目标售价能否被主流消费者接受，预计市场份额有多少。
  • ③ 开发这样一款硬件集成度高的产品，团队现有的资金能否支撑到量产。
  • ④ 该产品是否会涉及侵犯个人隐私（如持续摄像）等法律风险。

以上评估因素，分别主要对应了可行性分析中的哪几个方面？

  • A ①技术可行性 ②商业可行性 ③成本可行性 ④社会可行性
  • B ①技术可行性 ②成本可行性 ③进度可行性 ④商业可行性
  • C ①设备可行性 ②商业可行性 ③成本可行性 ④技术可行性
  • D ①社会可行性 ②商业可行性 ③进度可行性 ④成本可行性
答案：A
解析：
① 询问“技术是否支持”，属于技术可行性。
② 询问“市场接受度和份额”，属于商业可行性。
③ 询问“资金是否足够”，属于成本可行性。
④ 询问“法律和隐私风险”，属于社会可行性（课件中提及需评估是否“违背社会道德、文化伦理、法律法规”）。
  1. 软件需求工程是一个系统的过程。关于该过程，以下描述正确的是？
  • A 一旦通过“软件原型”获取并确认了需求，后续就完全不能更改，以保证开发进度。
  • B “用例图”作为一种可视化建模工具，既能描述系统的功能性需求，也能详细规定性能指标等非功能性需求。
  • C “确认和验证初步软件需求”活动包括评审需求的完整性、一致性、可行性等，以确保需求基础的质量。
  • D 软件需求全部都应来自于最终用户，开发团队不应加入任何自己的想法，以免偏离用户真实意图。
答案：C
解析：
C正确：课件第5部分详细说明了评审初步软件需求的多个方面，包括中肯性、完整性、一致性、必要性、溯源性、准确性、正确性等，其核心目的就是确保需求基础的质量，这是需求工程中的关键环节。
A错误：需求在整个生命周期中都可能发生变化，原型本身就是为了应对需求不确定性而采用的方法。需求需要管理，而非冻结。
B错误：用例图主要用于描述系统的功能边界和功能性需求。对于非功能性需求（如性能指标），通常需要用自然语言、补充规约或在用例中附加说明来描述。
D错误：课件在1.1节明确指出，“许多软件系统的需求来自软件工程师”，特别是在找不到实际用户或进行技术创新时。开发团队可以充当利益相关方，提出有价值的创意。

SE6 分析软件需求

  1. 某项目团队拿到了一份由客户提供的初步需求列表，内容较为模糊，存在诸如“系统应该用户友好”等描述。团队接下来需要开展软件需求分析工作。以下关于该阶段任务的描述中，不正确的是？
  • A 需要将“用户友好”这类模糊需求具体化为可验证的指标，如“新手用户能在10分钟内完成首次登录和基本设置”。
  • B 需要分析不同需求之间的依赖关系，例如“生成报表”功能依赖于“数据查询”功能。
  • C 需要根据用户价值和业务目标，确定哪些需求应在首次迭代中优先实现。
  • D 需要完成所有核心模块的详细算法设计，以确保后续开发工作有据可依。
答案：D

解析：软件需求分析的核心是“做什么”（What），而不是“怎么做”（How）。选项A是需求精化的典型活动；选项B是分析需求间关系；选项C是确定优先级。而选项D中的“详细算法设计”属于系统设计阶段的任务，超出了需求分析的范围。
  1. 在为一个“智能家居控制系统”进行需求建模时，开发团队需要从不同视角描述系统。现在需要描述“用户通过手机App下达指令后，系统内部各个组件（如网关、设备控制器、具体设备）之间是如何协作来完成‘打开卧室灯光’这个功能的”。在这种情况下，最应该使用以下哪种UML图？
  • A 用例图 (Use Case Diagram)
  • B 类图 (Class Diagram)
  • C 顺序图 (Sequence Diagram)
  • D 状态图 (State Diagram)

答案：C

解析：题目描述的核心是“对象间的交互序列”和“时间顺序”，这正是顺序图的典型应用场景。用例图用于描述系统与外部执行者的功能交互（是什么功能）；类图用于描述系统的静态结构（有哪些类）；状态图用于描述单个对象的状态变迁（对象如何变化）。
  1. 在绘制一个“在线书店系统”的分析类图时，以下关于类间关系的描述，正确的是？
  • A Order（订单）类和OrderLineItem（订单项）类之间应是聚合关系，因为订单项可以脱离订单独立存在。
  • B Customer（顾客）类和Address（地址）类之间应是组合关系，因为一个顾客可以有多个地址（如家庭地址、办公地址），并且当顾客账户注销时，这些地址信息通常需要保留以供物流分析。
  • C PaymentProcessor（支付处理器）类和CreditCardPayment（信用卡支付）类之间应是继承关系，因为信用卡支付是支付的一种具体方式。
  • D ShoppingCart（购物车）类需要使用Product（产品）类的信息来添加商品，因此它们之间最好用依赖关系表示。
答案：D

解析：选项A错误，订单项不能脱离订单存在，应是更强的组合关系。选项B错误，顾客和地址是“拥有”关系，但地址的生命周期不依赖于顾客，应是聚合关系。选项C错误，支付处理器是一个控制类，它“使用”具体的支付方式，更可能是依赖或关联关系，而非继承。继承是“is-a”关系。选项D正确，一个类临时使用另一个类的服务，用依赖关系表示是合适的。
  1. 你正在负责一个“在线文档协作编辑系统”的第一个版本开发。团队收集了众多需求，现在需要确定优先级。根据MoSCoW优先级排序法，以下哪一项需求最有可能被归类为“MUST have”（必须有）？
  • A 支持文档实时预览（用户在编辑Markdown时能同步看到渲染后的效果）。
  • B 支持超过100人同时在线编辑同一篇文档。
  • C 允许用户创建文档并输入文本内容。
  • D 集成AI助手，能够根据用户指令自动生成和修改文档内容。

答案：C

解析：MoSCoW方法中，M代表“必须有”，是项目的底线需求，如果缺少则产品不可用。选项C“创建文档并输入文本”是一个文档协作系统最核心、最基本的功能。选项A和B是重要的体验和性能需求，但在第一个版本中可能属于“SHOULD have”。选项D是增强功能，属于“COULD have”或“WISH”。
  1. 在分析“用户登录”用例时，有以下分析类：LoginScreen（登录界面，负责接收用户输入）、LoginController（登录控制器，负责协调登录流程）、User（用户，代表系统用户信息）、AuthenticationService（认证服务，负责验证密码）。在绘制的顺序图中，LoginScreen对象向LoginController对象发送了一条消息login(username, password)。根据分析类建模的原则，以下哪项是最合理的后续步骤？
  • A 在AuthenticationService类中定义一个login操作，其职责是“协调登录流程”。
  • B 在User类中定义一个login操作，其职责是“用户执行登录行为”。
  • C 在LoginScreen类中定义一个login操作，其职责是“显示登录界面”。
  • D 在LoginController类中定义一个login操作，其职责是“验证用户凭证并返回登录结果”。


答案：D 
解析：对象接收的消息与其承担的职责一一对应。LoginController接收了login消息，意味着它应承担处理登录请求的职责。它的职责是协调，即可能委托AuthenticationService去执行具体的密码验证，但自身负责控制这个流程。选项B和C将职责放错了对象；选项D的职责描述“协调登录流程”本应是LoginController的，而AuthenticationService的职责应是“执行密码验证”。
  1. 作为需求工程师，你正在撰写《软件需求规格说明书》。以下哪一项内容，不属于该文档中“功能性需求描述”部分的典型内容？
  • A 系统所有的用例图及其简要说明。
  • B 针对关键用例绘制的顺序图，描述系统内的对象交互。
  • C 系统的分析类图，展示核心的实体类、控制类和边界类及其关系。
  • D 数据库表结构的详细设计，包括每个字段的数据类型和索引设计。

答案：D

解析：《软件需求规格说明书》主要描述“系统需要做什么”，即需求。选项A、B、C都是通过不同视角（用例、交互、结构）来描述功能性需求的常用模型。而选项D“数据库表结构设计”属于“系统怎么做”的范畴，是系统架构设计和数据库设计阶段的输出物，不应出现在需求规格说明书中。
  1. 在软件需求评审会上，评审专家正在对照检查清单对需求制品进行审查。以下哪位专家提出的问题，属于在检查需求的“一致性”？
  • A 王工指出：“在‘权限管理’模块的需求中，只提到了管理员可以删除用户，但没有说明普通用户是否可以删除自己的账户。”
  • B 李工发现：“在用例‘UC-101提交订单’中，描述的业务规则是‘订单金额必须大于0’，但在数据约束中却写成了‘订单金额必须大于等于0’。”
  • C 张工提问：“需求‘FR-205系统应在200ms内响应用户查询’的提出依据是什么？是来自用户的明确要求，还是我们的性能基准测试？”
  • D 赵工质疑：“这个‘消息推送’功能，在之前与市场部沟通时并未被提及，它是否确实是用户期望的功能？”
答案：B

解析：需求一致性是指需求之间、或需求自身不同部分的描述不应存在矛盾。选项B中，同一需求在不同地方出现了逻辑矛盾（大于0 vs 大于等于0），是典型的不一致问题。选项A属于完整性问题（有遗漏）。选项C属于可追踪性问题（需求来源不明）。选项D属于多余性或正确性问题（需求是否真实存在）。

SE7 软件设计基础

  1. 软件设计阶段的主要任务是（ ）？
  • A 编写出可以运行的程序代码
  • B 与用户沟通，明确软件要做什么
  • C 探究如何实现软件需求的解决方案
  • D 制定项目计划和分配团队成员任务

答案：C

解析：根据课件，软件设计是“针对软件需求，综合考虑各种制约因素，探究软件实现的解决方案”。它回答的是“如何做”的问题，是连接“做什么”（需求）和“做出来”（实现）的桥梁。
  1. 以下哪一项( )是高质量软件设计应具备的特性？
  • A 模块内部逻辑错综复杂，以体现技术深度
  • B 设计模型中的模块功能简明，关系直观
  • C 为了追求性能，可以将所有数据设置为全局可访问
  • D 只需满足当前需求，无需考虑未来的任何变更
答案：B

解析：课件中明确指出，高质量设计的“简单性”要求“模型中的模块的功能或职责尽可能简明易懂，模块间的关系简单直观”。选项A、C、D的描述都与高质量设计的原则（如简单性、信息隐藏、可修改性）相悖。
  1. 正确的软件设计过程通常应该是( )？
  • A 先进行详细的算法设计，然后再考虑系统的整体结构
  • B 直接从需求编写代码，在设计过程中逐步重构出结构
  • C 先进行体系结构设计，再进行用户界面和详细设计
  • D 体系结构设计、用户界面设计和详细设计可以同时无序进行
答案：C

解析：课件中阐述了软件设计是一个循序渐进的过程，应从最高抽象层次的体系结构设计开始，然后进行用户界面设计，最后是细化和精化的详细设计。这个顺序确保了从宏观到微观的合理规划。
  1. 如果一个模块只负责完成“计算员工当月工资”这一项单一任务，那么这个模块的内聚类型属于？
  • A 偶然性内聚
  • B 逻辑性内聚
  • C 过程性内聚
  • D 功能性内聚
答案：D

解析：课件中对“功能性内聚”的定义是“模块内各成分是一整体，完成单个功能”。题目中的模块只做“计算工资”这一件事，所有成分都为了这个单一功能服务，因此属于最高内聚度的功能性内聚。
  1. 在面向对象编程中，将类的属性定义为private（私有），然后通过公有的get和set方法来访问和修改它们，这主要体现了哪一项设计原则？
  • A 模块化原则
  • B 信息隐藏原则
  • C 抽象原则
  • D 软件重用原则
答案：B

解析：信息隐藏原则要求模块应该设计得使其所含的信息（如数据、实现细节）对那些不需要这些信息的模块不可访问。将属性设为private，就隐藏了其内部表示细节，只通过公共接口与外界交互，是信息隐藏最直接的体现。
  1. 面向对象设计方法学的一个核心优势是，它使用相同的一组概念（如类、对象）来进行需求分析和软件设计，这带来了什么好处？
  • A 使得编程代码的运行速度更快
  • B 实现了从分析到设计的自然过渡，降低了理解的复杂性
  • C 完全消除了软件项目中的需求变更
  • D 确保设计出来的软件没有任何缺陷

答案：B

解析：课件在“面向对象软件设计的优势”中明确指出，其优势之一是“高层抽象和自然过渡”，即“采用相同的一组抽象和概念来进行描述和分析，基于模型的精化手段来实现软件设计，极大简化了软件设计工作”。这减少了不同阶段模型转换的鸿沟，使过程更流畅自然。

SE8 软件体系结构设计

  1. 关于软件体系结构中的“构件”（Component），以下哪项描述是不正确的？
  • A 构件是可独立部署的物理模块，如.dll或.jar文件。
  • B 构件的实现与接口分离，使得具有相同接口的构件可以相互替换。
  • C 构件通过“端口”来绑定一组供给接口或需求接口，以与外部交互。
  • D 构件通常是细粒度的，以实现最大程度的代码复用。
答案： D
解析： 课件中明确提到“构件应该是粗粒度的，而非细粒度的”。粗粒度意味着构件封装了相对完整的功能，作为一个独立的单元被部署和复用，这是构件与简单类或函数库的关键区别。其他选项均是课件中强调的构件的核心特征。
  1. 在分层体系结构风格中，一个核心的设计约束是什么？
  • A 任何一层都可以直接与其它任意层进行通信，以提高效率。
  • B 每一层只能为其紧邻上层提供服务，并且只能使用其紧邻下层提供的服务。
  • C 所有层次都必须部署在同一个物理节点上。
  • D 用户界面层必须包含核心的业务逻辑处理功能。

答案： B
解析： 课件在“分层体系结构模式的约束”中明确指出“每层为其紧邻上层提供服务，使用紧邻下层所提供的服务”。这种约束是保证层次间松耦合和可替换性的关键。选项A和D都违反了分层的基本原则。
  1. 在MVC体系结构风格中，当用户在前端界面执行了一个操作（如点击按钮），正确的交互流程是？
  • A 视图 -> 模型 -> 控制器
  • B 控制器 -> 模型 -> 视图
  • C 模型 -> 视图 -> 控制器
  • D 视图 -> 控制器 -> 模型

答案： D
解析： 根据课件对MVC约束的描述：视图接受界面动作，传递给控制器；控制器调用模型的业务逻辑功能；模型处理后将结果回送控制器，并可能通知视图更新；控制器再选择或创建视图。因此，正确的发起流程是视图将动作传给控制器，再由控制器去驱动模型。
  1. 下列哪种软件体系结构风格最适用于处理以数据流为主要特征的应用，并且允许通过独立更新处理步骤来实现系统进化？
  • A 分层风格
  • B 管道与过滤器风格
  • C 黑板风格
  • D 面向服务架构风格

答案： B
解析： 课件在管道与过滤器风格的特点中明确指出，它“自然地解决具有数据流特征的软件需求”并且“可独立地更新、升级过滤器来实现软件系统的扩展和进化”。SOA风格关注的是服务的松耦合与集成，而非线性的数据流处理。
  1. 软件体系结构设计与详细设计的主要区别在于，体系结构设计更关注什么？
  • A 类的方法的具体实现算法。
  • B 软件系统的全局性、基础性技术问题与宏观结构。
  • C 用户界面的像素级布局和交互细节。
  • D 数据库表中每个字段的具体数据类型。

答案： B
解析： 课件2.1节指出，软件体系结构设计的特点是“针对软件系统全局性、基础性技术问题给出技术解决方案”，具有“宏观、全局、层次、战略、多视点、关键性”等特点。而详细设计则是在体系结构框架下，对局部设计要素（如类、方法）的细化。选项A、C、D均属于详细设计的范畴。
  1. 在精化软件体系结构、确定子系统时，评估和改进子系统的一个重要原则是“正交性”，这里的“正交性”主要指什么？
  • A 所有子系统都必须采用相同的编程语言实现。
  • B 不同子系统间的职责应尽可能独立，不应重叠或重复。
  • C 子系统的接口数量须尽可能多，以提供全面的功能。
  • D 子系统必须部署在正交分布的计算机网络节点上。
答案： B
解析： 课件在“评估和改进所确立的子系统”部分明确指出：“不同子系统间的职责是正交的，不应具有相同或相似职责”。正交性在此处是借用了数学上的概念，意味着职责的独立和无重叠，这是实现高内聚、低耦合设计的关键。

SE9 用户界面设计

  1. 在设计一个电商网站的“商品详情”界面时，以下哪个选项通常被认为是动态元素？
  • A 显示商品分类的导航菜单（静态结构）
  • B 用于输入购买数量的文本框
  • C 实时显示该商品库存数量的文本标签
  • D “加入购物车”按钮
解析：根据课件，动态元素与软件运行状态和业务逻辑相关，其内容会发生变化。商品库存数量会根据实际销售和入库情况动态变化，因此显示它的文本标签是动态元素。A是静态元素，B是用户输入元素，D是用户命令元素。

SE10 软件详细设计

无选择题

SE11 软件实现基础

无选择题

SE12 编写代码

  1. 将UML设计类图中的类间组合关系（Composition）转换为程序代码时，程序员需要特别关注的是（ ）。
  • A 仅需使用接口声明，无需实现关联
  • B 需要确保整体类对部分类具有生命周期的管理责任，整体消亡时部分也应被销毁
  • C 使用全局变量来维护对象间的引用
  • D 将组合关系转换为继承关系
答案：B
解析： 本题考查对组合关系编码实现的理解。组合关系（Composition）是整体-部分关系中最强的一种，其核心语义是部分的生命周期由整体管理——整体对象创建时部分对象随之创建，整体对象销毁时部分对象也应被销毁。因此编码时需要体现这种生命周期依赖。A选项（仅接口）过于简单；C选项（全局变量）破坏了封装性；D选项（转换为继承）错误，组合与继承是两种不同的关系。
  1. 在开发中，程序员从Stack Overflow上获取一段用于连接MySQL数据库的代码片段并整合到自己的项目中。这种做法主要体现了以下哪项软件工程原则？（ ）
  • A 信息隐藏
  • B 分而治之
  • C 软件重用
  • D 模块化
答案：C
解析： 本题考查对代码片段重用本质的认识。从技术问答社区获取已有的代码片段并直接使用，正是软件重用原则的具体实践。重用经过验证的代码片段可以提高开发效率、降低出错风险。A（信息隐藏）强调隐藏内部实现；B（分而治之）强调分解复杂问题；D（模块化）强调模块划分。它们虽与重用相关，但题目描述的核心行为是“重用已有代码”。
  1. 某程序在运行时会偶尔出现“除零错误”导致程序崩溃，用户无法获得计算结果。根据课件中的定义，这个“除零错误”属于（ ）。
  • A 软件缺陷
  • B 程序错误
  • C 软件失效
  • D 设计缺陷
答案：B
解析： 本题考查对三个核心概念的精准区分。课件明确定义：
软件缺陷：存在于源代码或文档中的不正确的描述（根本原因）。
程序错误：缺陷代码在运行时所产生的不正确或不期望的运行状态（内在表现）。
软件失效：错误导致程序无法提供所需功能或行为（外在表现）。

题干中的“除零异常”是运行过程中发生的错误状态，因此属于程序错误。A（缺陷）是导致该错误的根本原因（如代码中未检查除数是否为0）；C（失效）是错误导致的结果（用户无法获得结果）；D（设计缺陷）是缺陷的一种类型。
  1. 在缺陷管理系统中，一个缺陷被开发人员认领并开始着手修复时，其状态应变为（ ）。
  • A New
  • B Assigned
  • C Fixed
  • D Closed
答案：B
解析： 本题考查对缺陷生命周期状态的掌握。课件中给出了缺陷状态的完整定义：
New：确认存在但尚未分配处理人员
Assigned：已安排人员负责修复（对应题干“被开发人员认领并开始着手修复”）
Fixed：缺陷已经修复完成
Closed：缺陷处理完毕并关闭
  1. 当程序员定位到程序中的某个缺陷后，接下来正确的调试步骤应该是（ ）。
  • A 立即修改代码并重新编译，跳过中间步骤
  • B 分析缺陷产生的原因，确定修复方案，然后修改代码并验证修复效果
  • C 直接向缺陷管理系统提交关闭请求
  • D 忽略该缺陷，先完成其他功能编码
答案：B
解析： 本题考查对标准调试流程的理解。调试的本质是找到原因、定位位置、修复缺陷。定位到缺陷后，应先分析原因（为什么会出错），然后确定修复方案（如何修改），接着实施修改并验证（测试确认修复有效）。A选项跳过分析步骤可能导致引入新错误；C选项关闭缺陷应在缺陷确认修复并测试通过后进行；D选项忽略缺陷不符合质量要求。

SE14 软件部署

  1. 根据课件的定义，软件部署是指将目标软件系统进行收集、打包、安装、配置和发布到运行环境的过程。以下选项中，不属于软件部署主要工作内容的是（ ）。
  • A 安装和配置运行环境
  • B 编写软件源代码
  • C 安装和配置软件系统
  • D 打包软件要素
答案：B

解析： 本题考查对软件部署工作边界的理解。课件明确将软件部署分为两方面：安装和配置运行环境、安装和配置软件系统。具体工作包括收集、打包、安装、配置和发布。
编写软件源代码属于软件开发阶段（编码）的工作，不属于部署阶段，因此B选项正确。
  1. 以下软件中，最适合采用单机部署方式的是（ ）。
  • A 淘宝电商平台
  • B 谷歌搜索引擎
  • C 扫雷游戏软件
  • D 12306火车票订票系统
答案：C
解析： 本题考查对单机部署与分布式部署适用场景的判断。单机部署将软件各要素集中部署到单个计算设备上，适用于功能单一、无需网络通信、不依赖多台设备协同的软件。课件中列举的典型示例包括小米便签、扫雷游戏等。A（淘宝）、B（谷歌搜索）、D（12306）都是大规模、高并发、需要多台服务器协同的分布式系统，不适合单机部署。
  1. 关于容器部署，以下说法正确的是（ ）。
  • A 容器镜像只打包应用程序代码，不包括运行依赖
  • B 容器与宿主机共享同一个操作系统内核
  • C 容器部署需要为每个应用单独安装完整的操作系统
  • D 容器镜像无法实现多个实例的创建
答案：B
解析： 本题考查对容器部署核心特征的理解。课件指出，容器是一个视图隔离、资源可限制、具有独立文件系统的进程集合，它与宿主机共享操作系统内核，但拥有独立的文件系统。
A错误，容器镜像打包的不仅是代码，还包括所有依赖文件；
C错误，容器不需要单独安装完整操作系统；
D错误，一个容器镜像可以构建多个容器实例。

SE15 软件维护与演化

  1. 某银行系统原来运行在Windows Server上，现需要迁移到Linux平台，为此对系统中的文件路径处理和系统调用代码进行了修改。这种维护活动属于（ ）。
  • A 纠正性维护
  • B 适应性维护
  • C 完善性维护
  • D 预防性维护
答案：B
解析： 本题考查对四种维护类型的区分。课件明确定义：适应性维护是指“对软件进行改造以便适应新的运行环境和平台”。题干中软件从Windows迁移到Linux，属于运行环境变化，因此是适应性维护。A（纠正性维护）针对缺陷修复；C（完善性维护）针对增加新功能；D（预防性维护）针对改善可维护性。
  1. Lehman提出的软件演化法则中，“除非系统持续不断地被修改以满足用户的需求，否则系统将变得越来越不实用”描述的是（ ）。
  • A 持续变化法则
  • B 增加复杂性法则
  • C 质量衰减法则
  • D 功能持续增长法则
答案：A
解析： 本题考察对软件演化法则核心内容的掌握。课件明确指出持续变化法则的含义是：“除非系统持续不断地被修改以满足用户的需求，否则系统将变得越来越不实用”。B（增加复杂性法则）强调复杂性会上升；C（质量衰减法则）强调质量随变更下降；D（功能持续增长法则）强调功能必须持续增加。
  1. 软件在维护和演化过程中出现的“用户满意度降低、质量逐渐下降、变更成本不断上升”的现象被称为（ ）。
  • A 软件退化
  • B 软件逻辑老化
  • C 软件腐蚀
  • D 软件衰退
答案：B
解析： 本题考查对“软件逻辑老化”概念的准确识记。课件中直接给出定义：软件在维护和演化的过程中出现的“用户满意度降低、质量逐渐下降、变更成本不断上升”的现象称为软件逻辑老化。A、C、D虽然有相似含义，但不是课件使用的标准术语。
  1. 在软件维护过程中，通过分析程序代码，产生与之对应的设计模型和文档，这种技术被称为（ ）。
  • A 代码重组
  • B 设计重构
  • C 逆向工程
  • D 再工程
答案：C
解析： 本题考察对软件维护技术的区分。课件定义逆向工程为“基于低抽象层次软件制品，通过对其实施理解和分析，产生高抽象层次的软件制品”，即从代码产生设计文档。A（代码重组）是在不改变功能的前提下重新组织代码；B（设计重构）是产生设计文档，但课件中将其归为逆向工程的一种具体形式；D（再工程）包括逆向工程和正向工程，范围更广。最直接匹配题干的是C。

SE16 软件项目管理

无选择题

判断题

大家根据课件里面的内容以及课件上的习题来复习。如果时间有够的话，课件完整过一遍，如果时间不够的话，那就把课件上面的练习题看一下。课件上面的练习题如果会做了，那么考试的选择题和判断题是没有问题的，尽管没有原题。

填空题

涉及多个交叉学科的知识，主要是考研408和工程上一些常见知识，但是考得也不难，有些题目还贴心设计成选填，就是有几个选择，让你选填一个，大家也不要有畏难的心理。重点看一下以下内容:

  • (1) C语言编程基础核心：理解int、char等基本数据类型在内存中的存储大小和取值范围；执行scanf()这个过程发生了什么。

  • (2) 计算机组成原理核心：掌握计算机存储层次结构；能够计算CPU性能指标，如MIPS（每秒百万条指令）的计算；理解I/O子系统和主机的交互方式。

  • (3) 操作系统核心：理解进程虚拟地址空间（码段、数据段、堆段、栈段）；掌握虚拟内存管理机制；理解高级语言与系统调用的关系。

  • (4) 计算机网络：理解域名到IP地址解析的过程；能够根据IP地址和子网掩码计算网络地址；理解HTTP协议基本工作原理，掌握常见状态码含义；理解端口号的作用；理解从地址栏输入网址，点击enter到获取网页，这一过程发生的事情。

  • (5) 数据库系统核心：理解关系型数据库中表的物理存储方式；掌握事务的ACID特性；懂得为一个系统设计表来存储信息。

  • (6) Java Web开发与系统架构核心：理解MVC架构中各组件职责，即控制器接收请求、模型处理业务、视图展示结果；掌握系统分层设计思想；能够为典型应用系统选择合适的技术栈并明确各部分职责。

1.存储大小和取值范围

数据类型存储大小有符号取值范围无符号取值范围
char1 字节（8 位）-128 ～ 1270 ～ 255
short2 字节（16 位）-32768 ～ 327670 ～ 65535
int4 字节（32 位）-2147483648 ～ 21474836470 ～ 4294967295
long8 字节（64 位）-2⁶³ ～ 2⁶³-10 ～ 2⁶⁴-1
long long8 字节（64 位）-2⁶³ ～ 2⁶³-10 ～ 2⁶⁴-1

2.scanf()发生了什么

scanf() 用于从标准输入（键盘）读取数据并存入变量。 执行过程：

  1. 程序调用 scanf() 并根据格式字符串（如 %d）确定读取的数据类型；
  2. 等待用户输入，输入内容先进入输入缓冲区；
  3. 用户按回车后，scanf() 从缓冲区读取字符；
  4. 按格式要求将字符转换为对应数据类型；
  5. 通过变量地址（如 &a）将转换后的数据写入内存；
  6. 返回成功读取并赋值的数据项个数。

例如输入 123 后，scanf() 将字符串 "123" 转换为整数 123，并存入变量 a 所在的内存空间。

int a;
scanf("%d", &a);

3.计算机存储层次结构

计算机存储层次结构从上到下依次为：

寄存器 → Cache（高速缓存）→ 主存（RAM）→ 辅存（SSD/HDD）→ 光盘、磁带等长期存储

特点：越靠上：速度越快、容量越小、成本越高；越靠下：速度越慢、容量越大、成本越低。CPU 访问数据时遵循由上到下的顺序，优先访问高速存储器，未命中时再访问下一级存储器。

4.CPU性能指标的计算

MIPS（Million Instructions Per Second）表示 CPU 每秒执行的百万条指令数。

MIPS = 指令数 ÷ (执行时间 × 10^6)
MIPS = 时钟频率 ÷ (CPI × 10^6)

CPI：平均每条指令所需时钟周期数 / 时钟频率：CPU 主频

例： CPU 性能为 1000 MIPS

主频 = 2GHz
CPI = 2
MIPS = 2×10^9 ÷ (2×10^6)
     = 1000

5.进程虚拟地址空间

进程虚拟地址空间是操作系统为每个进程分配的一块独立的虚拟内存空间，用于存放程序代码、数据和运行时信息。

高地址
┌─────────┐
│   栈段   │ ← 局部变量、函数调用
├─────────┤
│         │
│   堆段   │ ← 动态申请内存（malloc）
│         │
├─────────┤
│ 数据段   │ ← 全局变量、静态变量
├─────────┤
│ 码段     │ ← 程序机器指令
└─────────┘
低地址
  • 码段（Text Segment）：存放程序代码，通常只读。
  • 数据段（Data Segment）：存放全局变量和静态变量。
  • 堆段（Heap）：用于动态内存分配，由程序员申请和释放。
  • 栈段（Stack）：存放局部变量、函数参数和返回地址，由系统自动管理。

6.掌握虚拟内存管理机制

虚拟内存管理机制是操作系统利用页表将虚拟地址映射到物理地址，实现内存扩展和进程隔离。

CPU -> 虚拟地址 -> MMU -> 页表 -> 物理地址 -> RAM
  • 虚拟地址：程序使用的地址
  • 物理地址：内存中的实际地址
  • 页表：记录虚拟页与物理页的映射关系
  • MMU（内存管理单元）：负责地址转换

若页面不在内存中，则触发缺页中断（Page Fault），操作系统将数据从磁盘调入内存后继续执行。

7.理解高级语言与系统调用

高级语言不能直接访问硬件，需要通过系统调用请求操作系统提供服务。

高级语言程序 -> 库函数 -> 系统调用 -> 操作系统内核 -> 硬件
printf() -> write()
fopen()  -> open()
malloc() -> brk()/mmap()

系统调用是用户程序进入内核的接口，库函数通常是对系统调用的封装。

8.域名到IP地址解析的过程

域名解析是将域名转换为 IP 地址的过程，由 DNS（域名系统）完成。

浏览器
  -> 本地DNS缓存
  -> 操作系统缓存
  -> 本地DNS服务器
  -> 根DNS服务器
  -> 顶级域DNS服务器
  -> 权威DNS服务器
  -> 返回IP地址
  -> 访问目标服务器

例如：

www.example.com
    ↓
93.184.216.34

DNS 采用分层查询机制，最终从权威 DNS 服务器获取域名对应的 IP 地址。

9.根据IP地址和子网掩码计算网络地址

网络地址 = IP 地址与子网掩码按位与（AND）运算。

例：

IP地址    ：192.168.1.100
子网掩码  ：255.255.255.0
192.168.1.100
AND
255.255.255.0
=
192.168.1.0

10.HTTP协议与常见状态码

HTTP（HyperText Transfer Protocol，超文本传输协议）是一种应用层协议，采用请求—响应模式进行通信。

客户端 -> HTTP请求 -> 服务器
客户端 <- HTTP响应 <- 服务器

常见状态码：

200 OK                 请求成功
301 Moved Permanently  永久重定向
302 Found              临时重定向
403 Forbidden          无权限访问
404 Not Found          资源不存在
500 Internal Server Error 服务器内部错误
502 Bad Gateway        网关错误
503 Service Unavailable 服务不可用

状态码第一位含义：

1xx 信息响应
2xx 成功
3xx 重定向
4xx 客户端错误
5xx 服务器错误

11.理解端口号的作用

端口号（Port）用于标识主机中的具体网络服务或应用程序，同一主机可以通过不同端口同时提供多个网络服务。

IP地址 -> 定位主机
端口号 -> 定位服务

常见端口：

20/21  FTP
22     SSH
25     SMTP
53     DNS
80     HTTP
443    HTTPS
3306   MySQL

12.从输入网址到获取网页

输入URL
  -> DNS解析域名获取IP
  -> 建立TCP连接（三次握手）
  -> 建立TLS连接（HTTPS）
  -> 发送HTTP请求
  -> 服务器处理请求
  -> 返回HTTP响应
  -> 浏览器解析HTML
  -> 请求CSS/JS/图片等资源
  -> 渲染页面
  -> 显示网页

13.关系型数据库中表的物理存储方式

关系型数据库中的表最终以文件形式存储在磁盘上，数据按行或页组织。数据库通常以页（Page）为单位进行数据读取和写入，页中存放多条记录。

数据库
  -> 表
  -> 数据页(Page)
  -> 行(Record)

例如：

用户表(User)

ID   Name
1    Tom
2    Alice
3    Bob

物理存储：

磁盘文件
  -> 数据页1
      -> 记录1
      -> 记录2
  -> 数据页2
      -> 记录3

14.事务的ACID特性

  • A（Atomicity，原子性） ：事务中的操作要么全部成功，要么全部失败。
  • C（Consistency，一致性） ：事务执行前后，数据保持一致状态。
  • I（Isolation，隔离性） ：多个事务之间互不干扰。
  • D（Durability，持久性） ：事务提交后，数据永久保存。

15.为系统设计表

根据业务对象抽取实体，为每个实体设计数据表，并通过主键、外键建立关联关系。

需求分析
  -> 抽取实体
  -> 设计数据表
  -> 确定字段
  -> 设置主键/外键
  -> 建立表关系

例如学生选课系统：

Student(id, name, age)
Course(id, name)
Select(student_id, course_id)

其中：

Student 1 --- N Select N --- 1 Course

一个学生可选多门课程，一门课程也可被多个学生选择。

16.MVC架构中各组件职责

MVC（Model-View-Controller）将业务逻辑、界面显示和请求处理分离。

用户 -> Controller -> Model
用户 <- View <- Controller
Model      ：业务逻辑和数据
View       ：页面显示
Controller ：接收请求、调用 Model、返回 View

例如：

登录请求 -> LoginController -> UserService -> login.jsp

17.系统分层设计思想

系统分层设计是将系统按职责划分为多个层次，每层只负责自己的功能，并通过接口与相邻层通信。

表现层(UI) -> 业务逻辑层(Service) -> 数据访问层(DAO) -> 数据库(DB)

例如：

用户登录
  -> LoginController
  -> UserService
  -> UserDAO
  -> MySQL

各层职责明确，上层调用下层，下层不直接调用上层。

18.选择合适的技术栈

根据系统规模、性能需求和开发成本选择技术栈，并明确各组件职责。

前端(Vue/React)
  -> 后端(Spring Boot)
  -> 数据库(MySQL)
  -> 缓存(Redis)
前端(Vue/React)：页面展示、用户交互
后端(Spring Boot)：业务逻辑、接口处理
数据库(MySQL)：数据存储
缓存(Redis)：热点数据缓存

例如电商系统：

浏览器
  -> Vue
  -> Spring Boot
  -> Redis
  -> MySQL

简答题

考察课程的核心主干知识以及实践要点，希望大家能够对软件开发过程有个整体的认识。此外，问答题还考察大家的言语理解能力和书面表达能力，也就是会给你一段材料，然后让你根据材料来回答问题。问答题除开放题外，所考察的内容没有超出这份复习要点。

题目一

分层体系结构是软件设计中常用的架构模式，它将系统按抽象级别组织成多个层次。

  • 请举例说明计算机学科中哪些知识体现了这种分层思想？（3分）
计算机网络模型：OSI七层参考模型和TCP/IP四层模型是网络通信领域最经典的分层架构，每一层都建立在下一层的基础上，并为上一层提供特定的网络服务。
(物理层/数据链路层/网络层/传输层/会话层/表示层/应用层)  (网络接口层/网络层/传输层/应用层)
文件系统: 应用程序->文件API->文件系统->块设备->磁盘,开发者不需要关心：扇区位置/inode布局/SSD磨损均衡等.
现代计算机系统通常自底向上划分为硬件物理层、操作系统内核层、系统调用接口层以及最顶部的应用程序层。
企业级软件应用架构：典型的软件系统会被划分为用户界面层（表示层）、业务逻辑层（处理层）以及基础服务层（数据访问与底层服务层）
  • 解释层和层之间是如何交互的？（1分）？
严格的单向依赖：在分层体系结构模式的约束中，每层仅为其紧邻的上层提供服务，并只能使用其紧邻下层所提供的服务.
请求与反馈机制：上层向下层发出明确的服务请求，下层在完成计算或处理后，为上层反馈服务结果.
事件驱动与通知：下层可以向上层提供底层的事件信息，上层在接收到下层的通知后做出相应的业务处理.
  • 分析分层架构的存在的不足？（1分）
性能损耗：由于分层架构严格限制了跨层调用，客户的请求和底层的数据必须自上而下或自下而上逐级穿透多个层次。这种逐层传递和数据转换会带来额外的处理开销和网络/进程间通信延迟，可能影响系统的整体运行性能.
过度设计与开发繁琐：对于一些极其简单的业务需求（如仅仅是从数据库读取一个字段并显示），强制的严格分层会导致代码冗余，开发者必须在每一层都编写“透传”代码，增加了初始开发的复杂度和工作量.
级联修改（Cascading Changes）：虽然分层实现了层内的高内聚和层间的松耦合，但如果遇到需要增加一个贯穿全局的新特性（例如增加一种全新的业务数据类型），往往需要从用户界面层到数据层逐层修改接口和逻辑.

题目二

在电商网站中，用户在搜索框输入关键词“计算机书籍”，并点击搜索后，系统会返回结果列表。

  • 请详细分析此过程中，网站前端、后端和数据库服务器各自做了什么工作？（5分）
1.网站前端（用户界面层/表示层）
捕获输入与校验：获取用户在搜索框中输入的关键词“计算机书籍”，并进行基本的前端逻辑校验（例如过滤特殊字符、检查是否为空）。
发起网络请求：将用户输入的关键词封装成 HTTP/HTTPS 请求（通常为带有查询参数的 GET 请求，如 ?keyword=计算机书籍&page=1），通过异步请求技术（如 AJAX、Fetch 或 Axios）发送给后端服务器。
状态反馈：在等待后端响应的期间，向用户展示“加载中（Loading）”的视觉反馈，安抚用户等待情绪。
数据解析与界面渲染：接收到后端返回的结构化数据（通常为 JSON 格式）后，前端引擎解析这些数据，并将其动态渲染、拼装到搜索结果列表页面的 DOM 结构中（展示书名、封面、价格、销量等信息）。
2.网站后端（业务逻辑层/控制层）
接收与解析请求：后端的网关或控制器（Controller）接收前端发来的 HTTP 请求，解析提取出查询关键词“计算机书籍”以及其他参数（如页码、排序方式）。
安全与业务处理：进行安全过滤（防止 SQL 注入或 XSS 攻击）和限流控制。在大型电商中，此时还会对关键词进行“分词处理”或“同义词扩展”。
缓存与服务调度：优先查询高速缓存（如 Redis），查看是否有“计算机书籍”的现成缓存结果。若缓存未命中，则向底层的数据访问层下达查询指令。
数据组装与响应：接收底层数据库或搜索引擎（如 Elasticsearch）返回的原始商品数据，进行业务加工（如计算折扣价、过滤已下架商品、分页处理），将最终结果封装成 JSON 格式的 HTTP 响应，发回给前端。
3.数据库服务器（基础服务层/数据层）
接收查询指令：接收后端应用通过数据库连接池发来的查询语句（如 SQL 语句）。
执行检索：数据库存储引擎根据预设的索引（如 B+ 树索引或专门的全文检索倒排索引），在商品信息表（Products）中快速查找匹配“计算机书籍”（或其分词）的记录。
返回结果集：将检索到的符合条件的商品数据记录集合（Result Set）进行打包，通过网络通道原路返回给调用它的后端应用程序。

题目三

AI通过海量数据训练，学习统计规律，能根据输入预测并生成最可能的文本序列，其本质是基于概率的模式匹配，而非真正的理解和思考。随着算力的不断突破和模型的不断优化，AI已在诸多领域展现出强大的信息处理和生成能力，深刻改变着我们的学习与工作方式。

然而，技术的便利也伴随着挑战。若缺乏专业知识，使用者容易被AI生成的、看似正确但可能包含错误或片面的回复所误导。更值得警惕的是，若习惯于不经思考地依赖AI获取答案，长期以往将弱化深入学习与独立思考的意愿和能力。因此，在AI时代，我们更需审慎平衡工具使用与自身知识和能力体系的构建——正如即便拥有强大的计算器，我们也仍需掌握运算的原理，只有如此，方能真正地驾驭工具。

那么，如何正确使用AI？核心在于 “以我为主，AI为辅” 。以教师利用AI辅助出题为例，教师在出题前已对考查内容、难度与题型有了全局、深入的把握。AI在此过程中扮演“军师”或“得力干将”的角色，协助构思、优化表述或帮助检查。而教师作为“主帅”，必须对AI的产出进行严格审视、修改和把关，绝不能将AI给出的答复直接用于试卷。AI不为结果负责，负责的始终是使用者本身。有效的AI使用往往需要使用者与AI进行多轮对话，根据AI反馈不断调整提问，通过多次迭代优化与交叉验证，才能获得准确满意的答复。

此外，AI不仅可以用于学习和工作，作为这个时代先进的生产力工具，AI在图像识别、语音识别、日常问题解答等领域同样表现优秀，生活中有任何的疑惑都可以尝试与AI对话。

1.结合AI使用经验和日常学习，请你谈谈应如何处理好“AI工具使用”与“坚持掌握扎实专业基础知识”两者间的关系？（5分）

  • AI是提高学习效率的重要工具，但不能代替专业基础知识的学习。两者应当相辅相成，而不是相互替代。
  • 首先，扎实的专业基础知识是正确使用AI的前提。只有掌握了相关知识，才能判断AI回答是否准确，避免被错误信息误导。其次，AI可以作为学习助手，帮助查阅资料、解释概念、总结知识和辅助练习，提高学习效率。再次，在学习过程中应坚持独立思考，先尝试自己分析和解决问题，再借助AI进行验证和补充。最后，要把AI作为辅助工具而不是依赖对象，不断巩固专业知识和实践能力，形成自身的知识体系和思维能力。
  • 因此，应坚持“基础知识为本，AI工具为辅”，在掌握专业知识的基础上合理利用AI提升学习效果。

2.结合以上材料和AI使用经验，请你谈谈应该如何正确使用AI？（5分）

  • 正确使用AI应坚持“以我为主，AI为辅”的原则。
  • 首先，要明确AI只是辅助工具，其生成内容并不一定完全正确，使用时应保持批判性思维，对结果进行核实和判断。其次，要学会提出清晰、具体的问题，并根据AI的回答不断调整提问方式，通过多轮交流获得更准确的结果。再次，对于学习、工作等重要场景，不能直接照搬AI的答案，而应结合自身知识进行分析、修改和完善。最后，要充分发挥AI在信息检索、知识学习、内容创作和日常生活中的辅助作用，提高效率，但始终保持独立思考和自主学习能力。
  • 只有合理利用AI并承担最终责任，才能真正发挥AI的价值，成为驾驭工具的人而不是依赖工具的人。

设计题

主要考查用例图和类图

讲解视频

例题

为促进混合式教学，学校计划开发“学在至诚”线上教学系统，各个用户角色的功能需求如下，请根据要求作答。

- 学生角色：注册与登录账户；浏览平台已发布的课程；观看所选课程的教学视频；查看与下载课程相关课件；完成课程配套的在线练习与测试等.
- 教师角色：注册与登录账户（需管理员审核）；创建新课程；为课程上传教学视频和课件资料；发布课程练习与在线测试；查看选修其课程学生的学习记录；录入并发布学生的课程成绩等.
- 管理员角色（系统管理后台）：管理所有用户（学生、教师）账户；审核教师创建的课程信息与上传的教学资源；维护网站前端页面与公告等.
  • (1) 识别系统中的主要执行者，并绘制系统的用例图。图中需清晰体现执行者、用例以及它们之间的关联关系。
  • (2) 识别系统中的核心类，确定每个类的主要属性与方法，并绘制类图。图中需体现类名、属性、方法以及类之间的关系（如继承、关联、聚合等）。

答案1 答案2

综合题

主要考察团队作业相关知识和技术。

  • 对于要实现的系统，大家要懂得将系统划分成多个不同的用户角色，并确定各个用户角色应该有的功能。
  • 要懂得系统功能是通过不同用户角色之间的交互来完成的。比如说美团外卖，用户通过手机点单，商家接单，骑手派送，最终完成外卖功能。
  • 要懂得对一个特定的系统，数据库表怎么设计，需要设计几张表，哪几张表，各张表包含哪些字段，怎么创建表。
  • 要懂得通过哪些技术将这个系统实现出来，并且各个技术所负责的功能是什么。

补充

内聚度（低→高）偶然性 → 逻辑性 → 时间性 → 过程性 → 通讯性 → 顺序性 → 功能性

耦合度（低→高）非直接 → 数据 → 控制 → 特征 → 外部 → 公共 → 内容

分类图名用途
用例用例图描述执行者与系统功能交互
结构类图类的静态结构：属性、方法、关系
结构对象图某时刻对象实例及关系快照
结构包图包间构成与依赖，系统高层结构
结构构件图构件及其接口、依赖关系
部署部署图工件在物理节点上的分布
行为顺序图对象间消息传递的时间顺序
行为通信图对象间消息传递的结构关系
行为状态图单个对象的状态变迁
行为活动图操作序列、决策点、并发同步