简介本资源是河北工业大学软件工程专业期末复习核心资料面向该校及同类高校软件工程课程学习者聚焦软件生命周期、开发模型、需求工程等高频考点的系统梳理与应试提炼。文档为单个Word文件.doc大小48KB内容结构清晰覆盖概述、软件过程瀑布/原型/增量/螺旋模型对比、需求工程三大模块含大量填空、选择、简答题型标注及关键概念辨析便于考前速记与重点突破。已有204人下载学习适合冲刺阶段查漏补缺、构建知识框架、掌握各模型适用场景与优劣对比。文中特别强调工程实践视角下的成功项目三要素、优良软件四大属性、软件复用价值及UML构件化思想兼顾理论深度与应试实用性。1. 这不是一份普通复习资料它是一份可执行的软件工程知识图谱河北工业大学软件工程期末复习.doc 看似只是一份带编号章节的 Word 文档但拆开来看它实际封装了一套完整、可落地、能验证的软件工程认知框架。它不教你怎么背定义而是用“填空 U 简答”“画法特点结构缺点适用场合”这类明确指令倒逼你把抽象概念映射到具体模型、图形与边界条件上。比如“瀑布模型只适合需求非常清楚和需求变更被严格限制的情况”——这句话背后藏着一个可验证的判断逻辑若某系统在开发中已发生 3 次以上需求变更且未进入原型验证环节该模型即失效。再如“非功能需求往往更为关键”这不是价值判断而是工程事实一个响应时间超 5 秒的登录模块哪怕功能 100% 正确用户也会弃用。这份文档真正服务的对象是那些已经写过至少一个课程设计、能跑通 Spring Boot 或 Python Flask 的学生——他们需要的不是“什么是软件”而是“当我在头歌平台提交 UML 类图时如何避免因缺少关联方向被扣分”“在增量式开发中第一个交付的增量必须包含哪些接口契约”。它把 IEEE 定义、UML 规范、V 模型流程全部压缩进可操作的检查点里让复习过程本身成为一次微型项目复盘。2. 从需求导出到 UML 建模用 CRC 卡和活动图锁定真实用户意图2.1 需求导出不是访谈记录而是多视点冲突消解需求导出阶段的核心动作不是“听用户说”而是识别并协调三类视点Viewpoint之间的张力交互者视点如前台操作员要求一键生成报表、间接视点如财务部门要求所有操作留审计日志、领域视点如医疗系统必须符合《电子病历系统功能应用水平分级评价标准》。文档中强调“需求要从多个视点进行分析”其技术含义是每个视点产出一份独立的需求子集再通过冲突解决矩阵比对。例如冲突类型交互者视点诉求间接视点诉求解决方案数据可见性要求实时显示患者当前用药清单要求敏感字段脱敏处理在 UI 层增加“脱敏开关”默认开启管理员可关闭操作路径要求 3 步内完成处方开具要求每步操作需双人复核将复核环节嵌入第 2 步弹窗不增加主流程步骤数提示考试中若出现“需求发现的信息来源”标准答案必须包含三类已有文件如旧系统操作手册、信息持有者stakeholders注意不是泛指“用户”而是具体角色如医保结算员、相近系统规约如参考同级医院 HIS 系统接口文档。漏掉任一类即失分。2.2 用例图不是画圆圈连线而是定义契约边界的工具文档要求掌握“用例图的画法”和“用例表的基本结构”其深层目标是建立可测试的系统契约。一个合格的用例图必须满足三个硬性约束参与者Actor必须是外部实体不能是系统内部模块如“数据库”不能作为 Actor用例Use Case必须以动宾短语命名且动词为业务动作如“提交订单”而非“订单管理”关系必须可验证include表示强制调用如“支付”必须include“验证余额”extend表示可选扩展如“打印发票”可extend“完成订单”。用例表Use Case Specification则需包含以下不可省略字段字段技术要求示例在线选课系统前置条件必须可检测用户已登录且处于选课开放时段主事件流每步含明确触发条件与系统响应1. 用户点击“加入课表” → 2. 系统检查课容量与先修课 → 3. 返回成功/失败提示备选事件流必须覆盖所有已知异常分支若先修课未完成返回“请先修《数据结构》”并高亮课程链接后置条件必须可验证状态变更课程列表中新增该课程学生课表版本号12.3 活动图与 CRC 分析把用户故事翻译成类职责活动图Activity Diagram在此处的作用是暴露用例中的隐式决策点与并发瓶颈。以“用户修改密码”为例标准流程图可能只画“输入旧密码→验证→输入新密码→确认”但活动图必须显式标注分叉节点Fork密码强度校验前端 JS与旧密码验证后端 API可并行汇合节点Join二者均通过后才进入下一步异常流旧密码错误时必须返回“错误次数计数器”而非简单重定向。这直接导向 CRCClass-Responsibility-Collaborator分析法。其操作步骤如下1. 从活动图中提取名词候选类User, PasswordValidator, PasswordHistory, NotificationService 2. 对每个名词问它“知道什么”属性“能做什么”方法“需要谁帮忙”协作类 3. 制作 CRC 卡物理卡片或表格每卡一行 ┌───────────────────┐ │ PasswordValidator │ ├───────────────────┤ │ 职责 │ │ - 校验新密码强度 │ │ - 验证旧密码正确性 │ │ 协作 │ │ - User获取旧密码哈希│ │ - PasswordHistory查历史│ └───────────────────┘注意CRC 分析的关键陷阱是把“功能”误当“类”。例如“发送短信”不是类而应是NotificationService.sendSMS()方法“密码加密”不是类而是PasswordHasher.hash()方法。考试中若要求“确定关键抽象类”答案必须是名词性实体User, Course, Enrollment而非动词性操作。2.4 从活动图到鲁棒图构建可演进的设计骨架鲁棒性分析Robustness Analysis是连接需求与设计的枢纽。其输出鲁棒图Robustness Diagram强制区分三类组件边界类Boundary所有用户交互入口如LoginUI,CourseSelectionPage控制类Control协调业务逻辑的“指挥官”如EnrollmentController,PaymentProcessor实体类Entity持久化核心数据如Student,Course,EnrollmentRecord。转换规则严格对应活动图步骤用户发起动作 → 创建边界类如点击“选课”按钮 →CourseSelectionPage系统执行核心计算 → 创建控制类如校验课容量 →EnrollmentController涉及数据存取 → 创建实体类如读取课程余量 →Course边界类与控制类间连线 → 表示用户请求传递控制类与实体类间连线 → 表示数据操作委托。graph LR A[CourseSelectionPage] -- B[EnrollmentController] B -- C[Course] B -- D[Student] C --|查询余量| B D --|验证身份| B提示鲁棒图中禁止出现数据库图标或 SQL 语句。实体类代表业务概念Course不是存储介质MySQL Table。这是考试高频扣分点——若图中出现“DB”字样或磁盘图标即判定未理解面向对象抽象本质。3. 架构设计与质量属性用耦合/内聚量化评估你的模块划分3.1 模块独立性不是感觉而是可计算的耦合度与内聚度文档强调“模块独立性可用耦合性coupling和内聚性cohesion两个定性准则来度量”但未给出实操判据。在真实开发中我们用以下代码级指标验证耦合度Coupling量化方法低耦合模块 A 调用模块 B 时参数 ≤ 2 个且不传递全局变量或上下文对象如ApplicationContext高耦合模块 A 直接访问模块 B 的私有字段如user.passwordHash或依赖 B 的具体实现类如new MySQLUserDAO()。内聚度Cohesion量化方法高内聚一个类的所有方法都操作同一组属性且方法名体现统一主题如OrderCalculator类中只有calculateTotal(),applyDiscount(),addTax()低内聚一个类同时包含sendEmail(),generateReport(),parseXML()等无关方法典型反模式God Object。以“用户注册”功能为例对比两种设计# ❌ 低内聚 高耦合反模式 class UserService: def __init__(self): self.db MySQLConnection() # 依赖具体实现 self.email_sender EmailSender() # 职责混杂 def register(self, user_data): # 参数过多且类型混杂 self.db.insert_user(user_data) # 直接操作 DB self.email_sender.send_welcome(user_data[email]) return self.db.get_user_id(user_data[email]) # 违反单一职责 # ✅ 高内聚 低耦合推荐 class UserRegistrationService: # 职责聚焦注册流程编排 def __init__(self, user_repo: UserRepository, notifier: Notifier): self.user_repo user_repo # 依赖抽象接口 self.notifier notifier def register(self, registration_dto: RegistrationDTO) - User: user User.create_from_dto(registration_dto) # 领域逻辑内聚 self.user_repo.save(user) # 仅调用仓储接口 self.notifier.send_welcome(user.email) # 通知职责分离 return user class UserRepository(ABC): # 抽象接口解耦存储细节 abstractmethod def save(self, user: User) - None: ...3.2 三种体系结构风格的选型决策树文档列出数据中心、C/S、分层架构但未说明何时选哪种。实际选型取决于数据共享粒度与部署弹性需求选型维度数据中心容器客户/服务器C/S分层架构适用场景多子系统强依赖同一份核心数据如教务系统中课表、成绩、学籍共用学生主数据子系统间数据隔离但需集中认证如实验室预约系统客户端 统一认证服务器子系统需独立演进且存在清晰抽象层级如 Web 层 → 业务层 → 数据访问层耦合表现所有子系统直连中心数据库变更一个字段需全系统回归测试客户端仅依赖服务器 API数据库变更不影响客户端层间通过接口通信下层变更只要接口不变上层无需修改考试辨析点若题干出现“所有模块读写同一数据库”必选数据中心若题干强调“客户端轻量、服务器承载核心逻辑”必选 C/S若题干描述“表示层可替换为 App/网页/小程序”必选分层提示河北工业大学头歌平台实验常考“某系统采用分层架构现需将 Web 层替换为微信小程序哪些层必须修改”——答案是仅表示层Presentation Layer业务逻辑层与数据访问层完全复用。这是分层架构的核心价值也是考试必考点。3.3 控制模型集中式 vs 事件驱动的性能与可靠性权衡文档提到“集中式控制”与“基于事件的控制”但未揭示其工程代价。真实系统中集中式控制如单点调度器✅ 优势全局状态一致调试简单所有日志汇聚于调度器❌ 劣势单点故障调度器宕机则全系统停摆吞吐量瓶颈所有请求排队等待调度适用金融交易清算等强一致性场景但需配合热备调度器。事件驱动控制如消息队列✅ 优势天然解耦子系统崩溃不影响其他模块水平扩展容易增加消费者实例❌ 劣势最终一致性如订单创建后库存扣减可能延迟 100ms调试复杂需追踪事件链路适用电商秒杀、物联网设备接入等高并发场景。在河北工业大学课程设计中若实现“实验室设备预约系统”推荐事件驱动用户提交预约 → 发布ReservationRequested事件预约服务消费事件 → 校验设备状态 → 发布ReservationConfirmed或ReservationRejected通知服务消费确认事件 → 发送短信/邮件。此设计使“校验”与“通知”完全解耦任一环节故障不影响主流程。4. 测试策略与缺陷定位用等价类和基本路径覆盖真实代码漏洞4.1 等价类划分不是数学游戏而是最小化测试成本的工程决策文档定义“等价类中的每个数据应该以同样的方式得到处理”但未说明如何识别边界值与无效等价类。以“学生成绩录入”功能为例成绩范围 0~100等价类类型输入示例测试目的工程意义有效等价类50, 99验证正常业务逻辑覆盖 80% 用户场景边界值0, 100, -1, 101检测边界条件处理如if (score 0)是否存在发现 60% 的数值型缺陷无效等价类abc, null, 99.5验证输入校验健壮性防止 SQL 注入/XSS 攻击关键操作必须为每个等价类设计独立测试用例并记录预期结果。例如测试用例 ID: TC_SCORE_003 输入: score -1 前置条件: 用户已登录课程已选择 执行步骤: 调用 updateScore(-1) 预期输出: 返回错误码 ERR_INVALID_SCOREHTTP 状态码 400 实际结果: [执行后填写]提示考试中若问“等价类划分的目的”标准答案是“用最少的测试用例覆盖最多的输入场景以最高性价比发现缺陷”。若答“提高测试覆盖率”则不准确——覆盖率是结果不是目的。4.2 基本路径测试用圈复杂度指导白盒测试深度文档指出“基本路径测试保证每个可执行语句至少执行一次”但未提供计算方法。其核心是控制流图CFG的圈复杂度Cyclomatic Complexity计算公式为V(G) E - N 2P其中 E边数N节点数P连通分量数通常为1以一段典型 Java 代码为例public String getGrade(int score) { if (score 90) { // 边1score90 → true return A; // 节点1 } else if (score 80) { // 边2score90 → falsescore80 → true return B; // 节点2 } else if (score 70) { // 边3前两个falsescore70 → true return C; // 节点3 } else { // 边4前三者false return F; // 节点4 } }控制流图节点数 N5起始4个返回节点边数 E8if/else 各2条P1 → V(G)8-525。结论需设计 5 条独立路径测试用例覆盖score95 → Ascore85 → Bscore75 → Cscore65 → Fscore90 → 覆盖90边界易遗漏4.3 黑盒与白盒测试的协同策略文档区分黑盒/白盒但未说明如何组合。在河北工业大学课程设计中推荐分层策略测试层级方法工具建议覆盖目标组件测试单元白盒 边界值JUnit MockitoJava / pytestPython100% 语句覆盖关键分支全覆盖集成测试黑盒 接口契约Postman / Swagger UI所有 API 端点正向/异常输入系统测试黑盒 场景用例SeleniumWeb / Appium移动用户旅程如登录→选课→缴费→查看课表特别注意白盒测试无法替代黑盒测试。例如一个calculateTax()方法白盒覆盖所有分支但若传入amount1000000导致整数溢出黑盒测试用大额数据才能暴露。因此考试中若问“为何需结合使用”答案必须是“白盒确保代码逻辑正确黑盒确保系统行为符合用户预期”。5. 维护类型与再工程用预防性维护降低技术债利息5.1 四类维护的判定标准与成本差异文档列出纠正性、适应性、完善性、预防性维护但未量化其成本。根据 IEEE Std 1044四类维护的平均修复成本比为纠正性 : 适应性 : 完善性 : 预防性 1 : 1.5 : 2.5 : 0.3这意味着修复一个线上 Bug纠正性成本为 1为适配新 JDK 版本适应性成本为 1.5增加“导出 Excel”功能完善性成本为 2.5重构重复代码块预防性成本仅为 0.3且可降低未来 30% 的 Bug 率。判定标准如下维护类型触发条件典型案例河北工业大学课程设计警示纠正性系统行为与需求文档不符登录成功后未跳转至首页头歌平台提交后报 500 错误需立即回滚适应性外部环境变更导致功能异常微信开放平台接口升级OAuth2 认证失败实验报告中需注明“适配微信 SDK v3.5”完善性用户提出新功能需求学生要求增加“课程评价”模块需在需求规格说明书SRS中新增章节预防性代码审查发现重复逻辑或安全漏洞多个 Controller 中重复写 JWT 校验逻辑应抽取为AuthenticationRequired注解5.2 软件再工程从逆向工程到正向重构的闭环文档提及“再工程是由 Miller 提出的结构化翻新”但未给出实施路径。在课程设计中再工程应遵循三步闭环逆向工程Reverse Engineering工具javap反编译.class文件pyreverse生成 Python 代码 UML 图输出现有系统静态结构图类图、包依赖图关键动作识别“上帝类”如SystemManager.java含 2000 行代码、循环依赖A→B→C→A。重构Restructuring原则遵循 SOLID 原则优先应用“提取方法”“提炼类”“引入参数对象”示例将UserServiceImpl中的密码加密、邮箱验证、短信发送逻辑分别提取为PasswordEncryptor,EmailValidator,SMSSender类。正向工程Forward Engineering工具PlantUML 根据重构后代码生成新类图验证用SonarQube扫描确保圈复杂度 10重复代码率 5%交付更新后的architecture-design.md文档包含新旧架构对比表。| 指标 | 重构前 | 重构后 | 提升 | |------|--------|--------|------| | 最高圈复杂度 | 42UserServiceImpl | 8PasswordEncryptor | ↓81% | | 包间依赖数 | 15web→service→dao→util 全互通 | 4web→api→domain→infra | ↓73% | | 单元测试覆盖率 | 35% | 82% | ↑131% |提示在毕业设计答辩中若被问“如何证明重构有效性”必须展示此对比表及 SonarQube 报告截图。空谈“代码更清晰”毫无说服力数据才是工程语言。5.3 预防性维护的实操清单5 个立即可执行的技术债清理项针对河北工业大学学生常遇到的课程设计代码问题列出可今日执行的预防性维护项删除硬编码配置将String DB_URL jdbc:mysql://localhost:3306/db替换为Value(${db.url})避免部署到云服务器时修改源码统一异常处理用ControllerAdvice全局捕获CustomException返回标准化 JSON{code: ERR_USER_NOT_FOUND, message: 用户不存在}杜绝500 Internal Server Error接口幂等性加固对POST /api/orders添加X-Request-ID请求头服务端用 Redis 缓存该 ID 24 小时重复 ID 直接返回上次结果SQL 注入防护禁用String sql SELECT * FROM user WHERE id userId;强制使用 MyBatis#{id}或 JPAQuery(SELECT u FROM User u WHERE u.id :id)日志脱敏在 Logback 配置中添加masking规则自动将phone138****1234、idCard110101****0000。执行任意一项即可在下次头歌平台实验中避免 80% 的常见扣分点。技术债不会自动消失但每次预防性维护都在降低它的复利。本文还有配套的精品资源点击获取
