山东大学计算机科学与技术学院软件工程实验日志（更新中）

---

Author: "Inori_333"

Create Date: 2025-03-04

Update Date: 2025-04-21

2025软件工程实验日志（更新中）

目前已发布：

实验一 | 实验二 | 实验三 | 实验四 | 实验五 | 实验六 | 实验七 | 实验八 | 实验九

---

实验一 团队建立、阅读开源软件

1.队伍创建与分工

队伍最终确定由5人组成，小组成员之间进行了高效的沟通，并确定了各自的负责的部分内容。

2.代码复现与分析

写在前面：由于“小米便签”项目本身过于陈旧，以及伴随指导教程的落后性，对于今天的复现已经没有太大意义，因此从头开始摸索在更新版本的环境中复现方法。

2.1 环境配置与编译运行

2.1.1 Android Studio的下载与安装

访问Android Studio官网，下载最新稳定版本的 Android Studio 安装程序，下载完成后打开，开始安装。安装过程除路径可以自定义以外，其余全部跟随默认选项安装。在安装进行到倒数第二步时，默认会对 Android Studio 需要的SDK组件进行下载，但下载地址指向国际服务器，因此选择使用网络代理跳转IP，或修改DNS配置，或对本地环境变量进行修改，改源到国内镜像站（如阿里云镜像站、清华镜像站）。

安装成功后，打开 Android Studio。

2.2 代码复现与结构分析

访问“小米便签”开源地址，下载zip包或直接通过Git方式将项目源代码拉取至本地。拉取成功后，运行AS（Android Studio ,之后默认缩写为AS），选择“Open”，选择小米便签的根目录，点击打开。打开后，由于版本落后等问题，系统需要一定时间导入项目，之后会提示Gradle同步错误。

首先是无法验证gradle组件下载源的SSL证书，这是由于下载源链接会被重定向到  https://github.com/gradle/gradle-distributions/releases/download/v8.2.0/gradle-7.2-src.zip ，这个地址在 AS 环境下访问过于困难，报错如下：

Cannot connect to host api.soulter.top:443 ssl:True [SSLCertVerificationError: (1,  [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1010) )]

尝试将./app/wrapper/gradle-wrapper.properties中的下载源更改为国内镜像站，即图中的distributionUrl。

修改后再次尝试对Gradle进行同步，下载成功，但同步仍然失败，这一次返回错误：

Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve gradle:gradle:8.7.

经过查询发现仅更改distributionUrl无法切换下载源指向，此链接已经被写死在Gradle组件本身的源代码中：

private
fun createSourceRepository() = ivy {
    val repoName = repositoryNameFor(gradleVersion)
    name = "Gradle $repoName"
    setUrl("https://services.gradle.org/$repoName")
    metadataSources {
        artifact()
    }
    patternLayout {
        if (isSnapshot(gradleVersion)) {
            ivy("/dummy") // avoids a lookup that interferes with version listing
        }
        artifact("[module]-[revision](-[classifier])(.[ext])")
    }
}

要解决这个问题，可以直接为 Gradle 设置代理进行网络加速。但是这样会导致之前设置的 Maven 镜像链接也会经过代理。

选择另一种暴力的解决方案：绕过系统文件完整性检查。

从Gradle组件源代码中可以看到：

    private
    fun sourceRootsOf(gradleInstallation: File, sourceDistributionResolver: SourceDistributionProvider): Collection<File> =
        gradleInstallationSources(gradleInstallation) ?: downloadedSources(sourceDistributionResolver)
 
 
    private
    fun gradleInstallationSources(gradleInstallation: File) =
        File(gradleInstallation, "src").takeIf { it.exists() }?.let { subDirsOf(it) }

当 gradleInstallation 在 src 目录中存在的时候 AS 就不会继续下载 gradle-7.2-src.zip。这是因为这个值就是 project.gradle.gradleHomeDir。

于是直接把gradle-wrapper.properties里 distributionUrl 的 bin 改为 all，再向gradle-wrapper.properties中添加 distributionSha256Sum 属性 ，把 distributionSha256Sum 修改为gradle-7.2-bin.zip 对应的值。

修改完成后直接对项目进行 Build ，成功通过哈希校验绕开系统文件完整性检查，成功构筑项目，并打开小米便签。

3.问题思考与总结

3.1 案例分析一

下面这段求两数的平均值的代码在低年级可给满分，请思考它还有什么bug?

unsigned average(unsigned a, unsigned b){ return (a+b)/2; }

首先观察函数类型，类型为 unsigned ，也就是 unsigned int 类型的缩写，所以函数的返回值必须在 unsigned int 能够允许的有效值范围内。再观察传入参数，传入参数的类型为( unsigned , unsigned )，因此两个不同的传入参数也需要传入在 unsigned int 允许的有效值范围内的合法值；再看返回值，返回 (a+b) / 2，因为函数类型为 unsigned ，因此需要保证这个值的范围落在 unsigned 类型的区间内。

可以发现，这个函数存在出现数值溢出情况的bug，当a+b的值超出UINT_MAX常量时，程序无法处理溢出部分，因此在不同架构下可能会出现包括但不限于结果返回0（x86架构，average（0x80000000U, 0x80000000U）=0），结果回绕到较小的值等等。

3.1.1 你还自信自己编过的代码没bug、直接应用于社会没有风险吗？

我一直觉得自己写的代码有很多bug=w=，过去的竞赛、科研和开源社区经验也告诉我，bug这种东西是在所难免的。

3.1.2 你如何信任团队同伴（其他人）编写的代码？

1. 代码审查（Code Review）

• 强制审查流程：通过工具（如 GitHub PR、GitLab MR）要求所有代码必须经过至少一名其他成员的审查才能合并。

2. 编码规范与静态分析

• 统一规范：制定团队代码风格（如命名、注释、错误处理），并通过工具（Clang-Format、ESLint）自动化检查。

• 使用静态分析工具：使用工具（如 SonarQube、Coverity）自动检测潜在问题（内存泄漏、空指针解引用）。

3. 文档与注释

• 自解释代码：优先通过清晰的命名和结构减少注释，但对复杂逻辑需添加必要说明。

• 接口文档：对公共 API 或核心模块，通过文档（如 Swagger、Doxygen）明确输入输出和边界条件。

3.1.3 用什么途径能降低代码风险？

自动化测试

• 单元测试：对每个函数/类编写测试用例，覆盖正常逻辑和异常分支。

• 集成测试：验证模块间的交互，如微服务接口调用、数据库读写。

• 模糊测试（Fuzzing）：通过随机输入发现边界问题（如 AFL、libFuzzer）。

2. 持续集成（CI）

• 自动化流水线：每次提交代码时自动运行测试、静态分析和构建。

• 门禁策略：若测试覆盖率不足或静态分析报错，禁止代码合并。

3. 防御性编程

• 输入校验：对函数参数、用户输入、外部数据严格校验（如检查 NULL、范围限制）。

• 错误处理：明确错误码或异常传递路径，避免静默失败。

• 断言（Assert）：在关键逻辑中添加断言，如 assert(b != 0)。

3.1.4 如何做好软件产品的质量保证（QA，Quality Assurance）

1. 分层测试策略

• 测试金字塔：以大量单元测试为基础，辅以集成测试，当开发软件时，还需要少量端到端（E2E）测试。

• 回归测试：每次迭代后运行历史用例，防止功能回退。

2. 环境隔离与监控

• 多环境部署：通过代码版本管理软件创建多个不同分支，区分开发、测试、预发布和生产环境，避免代码直接部署到生产。

• 监控与日志：通过 Prometheus、ELK 等工具监控运行时异常（如内存泄漏、响应超时）。

3. 用户反馈闭环（开发软件时需要）

• 灰度发布：逐步向小部分用户开放新功能，收集反馈后再全量发布。

• Bug 跟踪：用 Jira、Redmine 等工具管理问题，确保每个缺陷有根因分析和修复验证。

3.2 案例分析二

double64 转 int16 溢出，这是很古老也是很传统的问题。64 位浮点数的范围远大于 16 位有符号整数。当浮点数值超过 32767 或低于 -32768 时，转换为 16 位整数就会溢出。这种情况下，转换结果会是未定义的行为，或者在某些编程语言中可能产生截断，但显然这里没有正确处理溢出。这个问题和刚才的案例一有异曲同工之处，都是很简单的bug，不同的是，这一次这个bug没有再以单独出现的形式让我们检查，而是被嵌入在了火箭生产与发射这样一个复杂的工业环境中，可以想象的是，箭载计算机的程序代码量会是比较庞大的，因此这样一个短小的bug很容易被忽略，尤其是该程序在先前版本的火箭上已经经过了测试，更加容易被认为是已经稳定的代码而不再进行修改。

从逻辑上来说，这是控制变量法的盲区，因为火箭的迭代无法单次控制一个变量进行测试，因此可能工程师不会想到发射速度会意外激活死代码的问题，但归根结底这还是测试和防御性编程缺失导致的。

• 首先，极端场景覆盖不足
  火箭发射过程中的高速状态需要复杂的模拟环境，而测试可能更关注“典型”场景：由于测试数据限制可能仅使用预估值或历史数据，未模拟超范围值（如速度超过32767）。由于环境模拟成本高精度模拟火箭加速阶段的极端条件可能成本高昂，导致测试覆盖不全。

• 其次，代码审查的盲区

  可以想象，对于这种古老而典型的问题，静态分析工具正常来说不会遗漏此类问题。审查流程缺陷可能导致代码审查可能更关注功能逻辑而非边界条件，尤其是对“看似无害”的类型转换操作。

实验二 团队建立、阅读开源软件 第二周

1.开源项目分析工作

参照小组提交的小米便签开源代码的泛读报告。

2.分析PPT中的案例内容

2.1 皮卡地里电视台广告售卖系统

用例图中的图元素代表的含义

用例图（Use Case Diagram）是一种UML（统一建模语言）图，主要用于描述系统的功能需求及其与用户（角色）之间的交互关系。其主要元素包括：

1. 参与者（Actor）

   代表外部用户或系统（人、硬件、其他软件等），它们与系统交互。 

   在用例图中通常用小人图标表示。

2. 用例（Use Case）

   代表系统提供的功能，即用户可以执行的操作。 

   在用例图中通常用椭圆形表示。

3. 系统（System）

   代表整个系统的边界，系统内包含所有的用例。 

   在用例图中通常用矩形框住所有用例。

4. 关系（Relationships） 

   关联（Association）：连接参与者和用例，表示交互。 

   泛化（Generalization）：表示父用例或父角色被子用例或子角色继承。 

   包含（<<include>>）：表示某个用例必然会调用另一个用例的功能。 

   扩展（<<extend>>）：表示某个用例可能在特定条件下扩展执行另一个用例。

构造型 <<include>> 和 <<extend>> 的含义

1. <<include>>（包含关系）

含义：表示一个用例必须执行另一个用例的功能。 

特点：

  主要用于功能复用。

  被包含的用例不能单独运行，必须被其他用例调用。

  例如，在广告售卖系统中，"创建广告活动" 可能会包含 "设定广告价格"，因为每个广告活动都必须设置价格。

示例

  "创建广告活动" <<include>> "设定广告价格"

2. <<extend>>（扩展关系）

含义：表示一个用例可能在某些条件下扩展执行另一个用例。 

特点：

  用于描述可选行为（非强制）。

  被扩展的用例可以独立运行，而扩展的部分是在特定条件下执行的。

  例如，在广告售卖系统中，"处理广告订单" 可能扩展"应用折扣"，但应用折扣并不是每个订单都必须执行的。

示例

  "处理广告订单" <<extend>> "应用折扣"

应用在皮卡地里电视台广告售卖系统的用例图分析

根据提供的内容，皮卡地里电视台的广告售卖系统涉及多个相关的业务，如广告代理、电视收视率、广告投放等，可能的用例关系如下：

用例1："广告代理提交广告" 

  可能包含 <<include>>："广告审核"

  可能包含 <<include>>："广告定价

用例2："广告播放" 

  可能扩展 <<extend>>："广告内容审核"（如果内容不合格）

用例3："广告收视率报告" 

  可能包含 <<include>>："计算平均收视率"

  可能扩展 <<extend>>："广告投放调整"（如果收视率低）

2.2 实时系统：分析导致failure原因

1.failure 的原因

火箭发射系统的设计师并没有遵循“假设软件存在异常”的原则，对于代码的检查不够到位，同时相关组织也没有相应的要求，就使得程序员对这方面的bug没有仔细排查。在数据转换过程中，一个64 位的浮点数被尝试转换成16 位的有符号整数，但很明显这样转换会导致有符号整数发生溢出等异常，从而使得其得到一个异常的速度，而火箭的检测系统发现这个异常数据后，就认为火箭已经偏离了航向，就导致整个系统发生了解体。

2.改进方案

在测试阶段需要给出更全面的测试集，像这样double 转成int 的情况一定要给出相应的测试样例，从而找到这个错误并将bug 改正。即测试的时候数据要尽可能种类齐全，double,float,char,int,short 等所有可能用到的数据都要给出样例，同时不同的数据大小也要给出相应的测试样例。也要考虑到数据溢出的情况，例如两个比较大的数据加起来超过int 了，可能就会导致异常，这时系统必须要采取相应的措施来梳理错误。测试的过程可以包括单元测试，集成测试，压力测试等，同时需要经过多名技术人员进行多层审查，设置备份系统和冗余机制，持续学习与改进。

3.使用华为云账号完成一个官方实验

3.1 选择要做的实验

选择本地部署Deepseek-1.5b。

3.2 购买ECS弹性云服务器

因为华为云官方提供的免费实验方法太过复杂，选择了直接自费购买ECS弹性云服务器。

购买参数：

服务器地区：华北-北京四
服务器规格：通用计算增强型|c7.xlarge.4|4vCPUs|16GB|linux 
服务器系统：Ubuntu 22.04
服务器VPC：默认
子网：默认创建
安全组规则：默认保护
虚拟盘挂载：100GB
网络带宽：100MB/S

3.3 项目部署与运行

3.3.1 部署ollama

检查ollama服务是否成功启动

3.3.2 拉取Deepseek-R1-Lite-Preview-1.5b

3.3.3 本地运行Deepseek-1.5b

尝试进行对话：

实验3 软件过程和生命周期建模

1. 软件过程的质量决定软件质量，过程模型也了决定开发工作的方式。

  请小组分工协作，对当前流行的软件开发敏捷过程模型进行调研，完成以下工作并汇总成报告：

   （a）查询“敏捷宣言”四原则及背景故事。对于敏捷方法，写出你的观点？

   （b）查询scrum.org官网，找到Scrum指南。研讨Scrum过程工作模型,其核心表达的思想是什么？

   （c）Scrum中有哪些主要概念(如：Backlog...等）？

   （d）Scrum中的meeting中，daily meeting的内容是什么？

   （e）研讨Scrum过程工作模型, 能展示工作状态并促进项目推进的工具、措施是什么？你的小组如何实施？

   （f）什么是DevOps？ 什么是CI/CD？什么是软工中的SAFe？

  相关内容已经写入小组报告，此处不再赘述。

2. 阅读以下资料

-国家博物馆收藏的健康码源代码----

 视频 https://weibo.com/tv/show/1034:4544057972817960

 http://www.yidianzixun.com/article/V_0Dbkox5Q/amp  健康码是怎样诞生的

https://www.bilibili.com/read/cv11986327/  被国家博物馆收藏的“健康码”源码

https://www.thehour.cn/news/421002.html  健康码开发背后鲜为人知的故事

https://segmentfault.com/a/1190000022870400  「粤省事」的诞生

从健康码的研发过程，你看到、感受到了什么? 它开发的过程模型是？

健康码的开发周期？从研发到推出，几天?

他们的工作时间表是怎样的？

每天几时收集需求，几时开始开发？迭代周期是？

所展示的代码特点是什么？是什么语言？风格特点与你以往写的代码有什么不同？（能实现功能的软件和符合架构规范的软件对比，有什么不同？）

   一、从健康码的研发过程中看到、感受到的

- 技术的力量与价值：健康码的诞生展现了技术在应对突发公共卫生事件中的强大力量。通过数字化手段，能够快速地对人员的健康状况进行标识和管理，极大地提高了疫情防控的效率和精准度，让技术的价值得到了充分的体现，也为社会的正常运转提供了有力的支撑。

- 团队协作与拼搏：健康码的研发过程离不开各个团队的紧密协作和辛勤付出。从产品需求的确定，到开发、测试、客服等各个环节，都需要不同专业背景的人共同参与。各个团队成员们加班加点，争分夺秒地推进项目进度，体现了高度的责任感和使命感，正是这种团队精神和拼搏态度，使得健康码能够迅速上线并不断完善。

- 创新与责任感：在疫情的特殊背景下，健康码是一种创新的解决方案。研发团队敢于尝试新技术、新方法，以满足疫情防控的迫切需求。同时，他们也深知自己所承担的责任，因为健康码的准确性和可靠性直接关系到疫情防控的效果和人们的生活，所以他们在研发过程中始终保持严谨的态度，不断优化和完善系统。

- 数字化转型的加速：健康码的成功应用也反映了疫情加速了社会的数字化转型。人们的生活方式、政府的治理模式等都在这一过程中发生了深刻的变化，越来越多的领域开始借助数字化手段来提高效率和应对挑战，为未来的发展提供了新的思路和方向。

 二、健康码的开发过程模型

健康码的开发过程模型可以概括为应急式敏捷开发模型。这种模型具有以下特点：

- 快速响应需求：在疫情爆发的紧急情况下，健康码的开发团队需要迅速响应政府和社会的需求，以最短的时间推出可用的产品。因此，在开发初期，团队会尽快明确核心功能和基本需求，然后立即投入开发，确保产品能够快速上线投入使用。

- 迭代式开发：由于疫情防控形势和政策可能会不断变化，用户对健康码的功能需求也会随之调整。开发团队采用迭代式开发方式，根据反馈和实际情况，对产品进行持续的优化和升级。例如，针对用户提出的显示时间字体过小、隐私保护等问题，团队及时进行调整和改进，以更好地满足用户需求。

- 跨部门协作：健康码的开发涉及到多个部门和领域的协同工作，包括政府部门、互联网企业、医疗机构等。各团队之间需要保持紧密的沟通和合作，共同推进项目的进展。这种跨部门协作的模式有助于整合各方资源，充分发挥各自的优势，提高开发效率和质量。

- 以用户为中心：在整个开发过程中，始终将用户的需求和体验放在首位。通过收集用户的反馈和意见，不断优化产品的功能和界面，使健康码更加便捷、易用，能够更好地服务于疫情防控和人们的日常生活。

 三、健康码的开发周期

从研发到推出，健康码的开发周期非常短。以杭州余杭区为例，2020年2月9日率先在支付宝推出健康码，在短短几天内完成了从需求提出到产品上线的全过程。这种快速的开发周期充分体现了应急式敏捷开发的特点，也反映了开发团队在面对紧急任务时的高效执行力和强大的技术实力。

 四、健康码的工作时间表

- 需求收集时间：健康码团队每天上午12点开始接收来自投诉复核组的新反馈的需求。这些需求可能来自用户在使用过程中遇到的问题，或者是政府部门根据疫情防控形势提出的新的要求。

- 开发时间：下午4点左右，需求收集完毕后，开发团队开始根据新的需求进行代码的编写和功能的开发。开发人员需要在有限的时间内完成任务，确保系统的更新和优化能够及时上线。

- 测试时间：晚上12点前，开发工作结束后，测试团队会对新版本的健康码进行全面的测试，检查是否存在漏洞、兼容性问题等，确保系统的稳定性和可靠性。

- 上线时间：次日凌晨3点左右，经过测试的新版健康码会正式上线，更新到各个使用场景中，为用户提供最新的服务。这样可以尽量减少对用户正常使用的影响，因为凌晨时段使用健康码的人相对较少。

 五、健康码的迭代周期

健康码的迭代周期较为频繁，通常会根据疫情防控的需要和用户的反馈进行快速迭代。在疫情初期，健康码可能每天都会进行一次迭代更新，以及时适应不断变化的形势和需求。随着疫情的逐渐稳定和系统的逐步完善，迭代周期可能会适当延长，但仍会保持较高的更新频率，以确保健康码能够持续有效地服务于疫情防控工作。

 六、所展示的代码特点

- 语言：展示的代码是用Java语言编写的。

- 风格特点：

    - 规范的注释：代码中有清晰的注释，包括作者信息、创建时间、接口的功能描述以及参数说明等。这样的注释有助于其他开发者快速理解代码的用途和实现逻辑，便于团队协作和后续的维护工作。

    - 清晰的接口定义：通过`@RestController`、`@PostMapping`等注解，明确地定义了健康码创建的接口及其请求方式。这种清晰的接口设计使得系统的功能模块化，便于扩展和调用。

    - 简洁的代码结构：代码结构相对简洁，将核心的业务逻辑通过方法的形式进行封装，如`create`方法中对健康码创建的处理。虽然目前方法内部的具体实现细节（`//TODO`）尚未完成，但从整体结构上可以看出其遵循了良好的编程规范和设计模式，为后续的功能实现和优化提供了良好的基础。

    - 安全性考虑：从代码中的`@Encrypted`和`@Permission`注解可以看出，在开发过程中已经考虑到了数据的安全性和用户的权限管理。这体现了在设计之初就注重系统的安全性和合规性，以保障用户信息的安全和系统的稳定运行。

 七、与以往写的代码不同之处

- 架构规范性：与以往可能更注重实现功能的代码不同，健康码的代码在架构设计上更加规范。它采用了符合企业级应用的分层架构和设计模式，如使用`RestController`来处理HTTP请求，将业务逻辑与表现层分离。这种规范的架构有助于提高系统的可维护性、可扩展性和可测试性，使得在面对复杂的需求变化和高并发访问时，系统能够更加稳定和高效地运行。

- 安全性重视程度：在以往的代码中，可能对安全性方面的考虑相对较少，而健康码的代码通过注解等方式明确地加入了加密和权限控制的功能。这反映了在开发涉及用户敏感信息和关键业务系统的代码时，对安全性的高度重视是必不可少的，以防止数据泄露和非法访问等问题的发生。

- 团队协作性：健康码的代码编写需要考虑到团队协作的效率和代码的可读性。因此，会更加严格地遵循统一的编码规范和风格，方便团队成员之间的代码审查和交接工作。相比之下，个人编写的代码可能在风格上会更加随意一些，主要以能够实现功能为主，而较少考虑团队协作过程中的一些规范要求。

3. 参考Scrum简介，整理出其中的开发过程模型图、关键概念。

Scrum开发过程模型图

Scrum开发过程是一个迭代、增量的过程模型，主要由一系列的Sprint（迭代）组成，每个Sprint包含以下几个关键事件：

1. Sprint：通常为期2-4周的开发周期。
2. Sprint Planning（迭代计划会议）：在每个Sprint开始时举行，团队成员共同明确Sprint目标与Sprint Backlog，讨论团队的接受力、开发速度、技术水平和商业条件等因素，提前确定好Sprint交付日期，增量迭代开发任务，产品版本迭代内容等。
3. Daily Scrum（每日晨会）：在Sprint周期内，每天定时定点举行，会议维持在15分钟左右。团队成员交流昨日进度、今日安排、所遇困难，快速梳理任务面板上的工作内容，所遇困难在会后点对点进行讨论解决。
4. Sprint Review（迭代回顾会议）：在Sprint结束时举行，主要有两个部分的内容，一是做Sprint交付版本与计划版本的验收，二是总结和完善后续Sprint的开发建设。
5. Sprint Retrospective（迭代回顾会议）：在Sprint结束时举行，团队成员共同回顾本次Sprint中的经验和教训，提出改进措施，为下一个Sprint做准备。

Scrum关键概念

三个基本角色

1. 产品主管（PO, Product Owner）：产品负责人，清楚地知道产品的愿景，需要对产品待办列表的梳理，优化，优先级排序等负责。决定团队每个冲刺要完成哪些任务。对于团队非常重要，决定Why和What。一般可以对应为现有的产品经理和BA（Business Analyst）的角色，业务需求分析师。
2. Scrum教练（Scrum Master）：Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍。
3. 团队成员（Scrum Team）：5-9人，可以认为是开发团队，但是一个跨职能的团队，能够交付一个端到端的真正对客户有价值的产品。

三种会议（五种事件）

1. Sprint Planning Meeting（迭代计划会议）：明确目标，细化任务。
2. Daily Scrum Meeting（每日晨会）：每日站会，定点、定时、人齐、会短、高效。发言内容围绕昨日进度、今日安排、所遇困难三个方面快速梳理任务面板上的工作内容，所遇困难在会后点对点进行讨论解决。
3. Sprint Review Meeting（迭代回顾会议）：Sprint评审回顾会议主要有两个部分的内容，一是做Sprint交付版本与计划版本的验收，二是总结和完善后续Sprint的开发建设。
4. Sprint Retrospective Meeting（迭代回顾会议）：团队成员共同回顾本次Sprint中的经验和教训，提出改进措施，为下一个Sprint做准备。

三项工件

1. Product Backlog：产品待办列表，是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。产品待办列表源自于Scrum方法。在Scrum中，产品主管（Product Owner）收集来自于各方的需要、期望、诉求等等到产品待办列表中，给定优先级；当冲刺（Sprint）计划会议上，团队从产品待办列表中挑选其中事项组成冲刺待办列表。常见的待办事项表达形式是用户故事。
2. Sprint Backlog：每个迭代的功能开发列表，PO会根据团队的能力并按照产品待办列表中的优先级来选取每个冲刺要做的事情。团队可以专注在每个迭代冲刺要走的事情上而不被打断。
3. Burndown Chart（燃尽图）：在每个迭代显示剩余工作时间和任务完成情况。

4. 小组协作继续进行开源项目的分析工作

   继续进行开源项目的分析工作，参照小米便签开源代码的泛读报告（模板）.doc ，丰富开源软件分析报告。

我负责分析的是小米便签的ui包和widget包相关内容。

本周完成了对我负责的所有的代码注释工作，下图展示几个标注示例，inori_333是标注人标记符，表示此处注释由我创建，ui包代码主要是用户交互层的构建。Widget包主要是窗口的框架。

相关注释后代码已上传至Gitee。

实验四 CASE工具、团队组织管理、工作量估算

1. CASE（Computer-Aided Software Engineering,计算机辅助软件工程）工具调研及应用

搜索CASE工具，例：（不限）

Microsoft Visio

Microsoft Project

Product Studio

Visual SourceSafe

TFS

Sybase PowerDesigner

PlantUML

参考两款开源软件:

https://staruml.io/StarUML

https://github.com/staruml

http://www.sonarqube.org  SonarQube 

https://github.com/SonarSource/sonarqube

EA（Enterprise Architect）

https://sparxsystems.cn/products/ea/ 

https://sparxsystems.com/

任务：

（1）小组分工选择几种工具软件，写出它们的用途、技术特点。

（2）练习项目跟踪进展工具的使用

    选用适合的CASE工具，如用甘特图记录跟踪项目进展。

    研究Scrum简介中的燃尽图（BrunDown Chart）。

以下是几种常见的CASE（Computer-Aided Software Engineering）工具及其主要功能和适用场景的简要介绍：

 1. Microsoft Visio

- 类型：图表绘制工具 

- 用途：  

  - 用于创建流程图、UML图、网络拓扑图、数据库模型图等。 

  - 支持软件设计中的可视化建模，如用例图、类图、时序图等。 

- 特点： 

  - 拖拽式操作，模板丰富，与其他Microsoft工具（如Office）集成度高。 

  - 适合非技术用户快速绘制技术图表。 

 2. Microsoft Project

- 类型：项目管理工具 

- 用途： 

  - 用于项目计划、任务分配、进度跟踪和资源管理。 

  - 支持甘特图、关键路径分析、成本预算等功能。 

- 特点： 

  - 适合瀑布模型等传统项目管理，但对敏捷开发支持较弱（需配合Azure DevOps等工具）。 

 3. Product Studio（已停用） 

- 类型：缺陷跟踪与需求管理工具 

- 用途： 

  - 曾是微软内部用于需求管理和缺陷跟踪的工具，后逐步被Azure DevOps（原TFS）替代。 

  - 支持需求收集、任务分配和问题追踪。  

 4. Visual SourceSafe (VSS) 

- 类型：版本控制工具（已淘汰） 

- 用途： 

  - 早期用于源代码版本管理，支持文件检出/检入、版本历史记录。 

- 缺点： 

  - 单文件锁机制导致协作效率低，易出现数据损坏，已被Git/TFS取代。 

 5. Team Foundation Server (TFS) / Azure DevOps 

- 类型：一体化ALM工具 

- 用途： 

  - 提供版本控制（支持TFVC和Git）、敏捷项目管理（看板、Scrum）、持续集成/交付（CI/CD）、测试管理等功能。 

- 特点： 

  - 覆盖软件开发生命周期（SDLC）全流程，适合中大型团队。 

 6. Sybase PowerDesigner 

- 类型：企业建模与数据架构工具 

- 用途： 

  - 数据建模：支持概念模型、逻辑模型和物理数据库设计。 

  - 业务流程建模（BPMN）、UML建模等。 

- 特点： 

  - 强于数据库逆向工程和正向代码生成，适合数据治理和复杂系统设计。 

 工具对比与适用场景：

另外，我注意到，现代开发中，Azure DevOps、PowerDesigner等工具仍广泛使用，而VSS、Product Studio等已被更先进的替代品淘汰。

2. 活动图练习：

参考所给的资料，算出计划安排中的关键路径CP。针对课本练习题2、3(p98)的软件开发项目活动图，画出每活动中的关键路径。将活动图的每一条活动路径，标出最早开始时间、最晚开始时间，时间差，整个项目工期和关键路径。思考关键路径能有多条吗？还有比关键路径更长的路径吗？

3. 继续团队协作继续进行开源项目的分析工作

   （a）分工协作，根据自己的项目完善泛读报告。

实验五 项目组织管理、工作量估算、风险管理

1. 研讨人员特性，工作风格，组织结构。

  （1）分析小组的成员各自贴近课本所指的哪种风格？针对用户的工作风格，应如何沟通？

  （2）结合课本主程序员负责制小组、忘我方法两种组织结构和课本补充材料3-2，讨论结构化与创造性的关系。

  （3）分工调研国内与国外软件开发团队的管理方式对比（如打卡制，KPI等）。

讨论：

    从个人角度，你最喜欢的工作方式、工作环境条件、管理方式是什么？

    从团队项目管理的角度，你认为最有效的项目组工作管理方式是什么？

（1）个人理想工作模式

• 工作方式：混合异步协作（核心时段集中编码+自由时间异步沟通）。
• 环境条件：双屏工作站+独立静音舱+协作白板区（参考Zoom办公室设计）。
• 管理方式：目标驱动型自主管理（如Basecamp的"6周冲刺周期"）。

（2）高效团队管理实践

• 推荐模式：改良版Scrum框架：
  1. 角色分工：Product Owner（需求把控）+ Scrum Master（流程优化）+ 跨职能团队。
  2. 迭代机制：双周冲刺包含3天技术债清理窗口。
  3. 工具链：Jira需求池 + Figma协作设计 + GitLab CI/CD流水线。
  4. 决策机制：ADR（架构决策记录）文档化 + 异议优先听证原则。
• 关键成功因素：
  • 可视化进度：燃尽图与风险矩阵看板
  • 心理安全：无惩罚的retrospective会议
  • 技术卓越：持续重构与自动化测试覆盖率要求

2. 练习工作量估算 COCOMOII模型：

   研究课本3.7（P94)皮卡地里电视广告销售系统按COCOMOII的工作量模型计算阶段1的例子（结合P79-80表），根据以下数据：

 数据表数目都<4,

 预约屏幕（视图总数目<4）、 刊例价格表(ratecard)屏幕（视图总数目>8）、时段可用性屏幕（视 图总数目>8），销售报表（总数目>8）。开发人员经验和能力认为是一般，CASE成熟度和能力是低， 计算阶段1的工作量估算值？

1. 计算未调整的对象点（UOP）：数据表、屏幕、报表的数量乘以各自的复杂度权值。

数据表数目<4，所以每个数据表复杂度简单，权值1。假设数据表数量为3，则数据表部分对象点=3×1=3。

预约屏幕视图数目<4 → 简单，权值1 →1点。

刊例价格表屏幕和时段可用性屏幕视图数目>8 → 困难，权值3 → 各3点 → 共6点。

销售报表总数目>8 → 困难，权值3 →3点。

UOP总和=3 +1+6+3=13。

2. 确定重用率，假设无重用，所以调整后的对象点（NOP）=13。

3. 确定生产率率（PROD）。根据开发人员经验和能力一般，CASE工具成熟度和能力低，查找对应的生产率。例如，根据课本中的表3.8（可能在P79-80），可能生产率分为不同等级：

例如，表3.8可能显示，当开发人员能力一般，CASE工具成熟度低时，PROD可能是某个数值，比如4对象点/PM。或者，根据经验，生产率可能在4到15之间，具体取决于环境。

例如，在课本的例子中，比如P94的例子，可能使用了PROD=4，因此工作量=UOP/PROD=13/4=3.25PM。

因此，最终的工作量估算值为3.25人月，即3.25 PM。

3. 风险管理

   针对课本P99，ch3 习题11，分析在你的开源项目分析任务中可能存在的风险。并分栏列出风险名称、风险暴露、风险控制方案（风险管理）。

1. 数据同步风险

从 GTaskManager.java 文件中可以看出，应用支持与 Google Tasks 同步数据，但存在以下风险：

网络连接失败时未提供完善的重试机制，如在 initGTaskList() 方法中

同步过程中的异常处理不充分，仅记录日志却没有恢复策略

数据冲突解决机制缺乏，当本地和远程数据同时更改时可能导致数据混乱

2. 数据安全风险

应用使用 SQLiteDatabase 存储用户笔记数据，但存在安全隐患：

NotesDatabaseHelper.java 中未见数据库加密措施，敏感笔记内容可能被未授权访问

备份功能将数据存储在外部存储（BackupUtils.java），增加了数据泄露风险

代码中缺少对输入数据的安全过滤，可能存在SQL注入风险

3. 异常处理不完善

代码中多处异常处理不够健壮：

在 Task.java 中的 setMetaInfo() 方法捕获 JSONException 后仅设置 mMetaInfo = null，没有合理的错误恢复机制

TaskList.java 中的异常处理仅记录日志并打印堆栈，不提供后续处理

网络相关操作的异常处理不足，如在远程同步失败后没有本地缓存机制

4. 资源管理风险

项目中存在资源未正确释放的风险：

getNoteWidgetInfo() 方法返回Cursor对象但调用处可能未关闭它

数据库操作过程中可能在异常情况下未释放资源

文件操作（如备份功能）中缺少明确的资源关闭代码

5. UI响应风险

从代码结构看，存在UI线程阻塞的风险：

GTaskManager 的同步操作可能在主线程执行，长时间网络操作会导致应用无响应

缺少加载状态指示，用户可能误以为应用崩溃

部分UI元素如 NoteEditText 处理大量数据时可能导致性能问题

6. 测试覆盖不足

项目的测试代码非常有限：

仅包含 ExampleUnitTest 和 ExampleInstrumentedTest 两个基本测试文件

缺少对关键功能如同步、数据备份的单元测试

没有自动化UI测试，难以保证用户界面的稳定性

风险暴露通常是指风险发生的可能性与其影响程度的乘积，用于衡量风险的严重程度。常见的风险缓解技术有：

代码审查与自动化测试，及时发现并修复问题

持续集成和持续部署，减少集成风险

原型和快速迭代，尽早验证可行性

风险记录和定期评审，动态掌控风险状况

4. 继续团队协作继续进行开源项目的分析工作

   （a）分工协作，根据自己的项目完善泛读报告。

   （b）记录跟踪团队项目推进的工作进度。

实验六

1. 参照课程网站“教学资料”中“GB-T-5687计算软件文档编制规范、案例”，

 （1）对照课本P87 项目计划内容（15项），对比SDP(软件开发计划)，查找有什么不同？

<1>SDP要求购书项目必须有一个明确的交付期限，需要在某个时间点之前完成。而书上给的项目计划虽然也要求对事件要有规划，但并不是需要一个确定的交付时间。

<2>从内容上讲，SDP要求对功能模块进行详细划分，同时划分出详细的角色分配表，例如任务负责人是谁，用户模块接口谁负责，前台系统，后台系统分别由谁实现。课本上给出的项目计划写的是项目团队组织结构，并没有说对项目的各个功能进行详细的划分。

<3>从宏观上看，课本上给出的项目规划更加注重对于具体技术的实现，例如怎么进行数据管理，怎么进行资源管理，而SDP注重的是对管理流程的细化，且管理莫实相对灵活，更加注重对于软件开发进度的规划，而课本上的更多是理想性的规划，而不是具体到某个开发环境或者开发进度上。

<4>SDP更加注重开发阶段，以技术实现为主，而课本上的是管理和技术的结合，更加全面。

（2）研究资料中的SRS，SRS软件需求规格说明书多个实例.zip《GB-T-9385-2008 计算机软件需求规格说明规范.pdf》和 国际《需求规格说明书(Volere版)》相比，有什么不同？

<1>使用范围：前者由我们国家发布，主要适用于国内政务系统以及央国企，后者是国际制定的，更适用于国际的软件规格的标准，适合一些商业系统。

<2>前者更侧重对系统行为的描述，因为它主要是应用于国内的企业，而后则会按业务价值排序，更适合私有企业使用

<3>前者没有明确的需求优先级，而后者采用的是动态优先级

<4>前者的模板资源可从国家标准平台购买，且适合于高校，国企或者政务系统，而后者由于是国际通用的，所以说一般可以从网站上免费获得。

<5>前者的标准规划更加严格，更加注重保护数据的隐私性和使用者的权利，而后者更加开放，更加注重使用者和开发者的自由性。

4. 继续团队协作继续进行开源项目的工作，非功能性需求（质量需求）

   （a）参照“小米便签维护需求与设计方案”，对项目进行维护，完成某些质量需求。

质量需求已完成，添加了密码功能

   （b）分工协作，补充项目泛读报告中的UML图；记录工作进度。

UML图已经补充

实验7 开源软件项目质量分析及报告总结

1. 了解 统一建模语言UML，写出自己的学习收获

 https://www.omg.org/spec/UML/
 https://www.omg.org/spec/UML/2.5.1/PDF
 https://baijiahao.baidu.com/s?id=1700899956563526148  浅谈UML中常用的9种图
 

UML（Unified Modeling Language）作为面向对象软件开发的标准化建模语言，通过图形化工具帮助开发者从不同视角分析、设计和实现复杂系统。以下是我的学习总结：通过用例图、活动图等，从用户视角描述功能需求，促进团队对系统目标的一致性理解。类图、包图等静态图定义系统的静态架构，而时序图、状态图等动态图描述行为逻辑，支持分层设计与模块化开发。统一的符号规范减少了开发人员、客户和测试团队之间的沟通成本。通过继承、聚合、组合等关系，精确描述类与对象之间的交互，强化面向对象设计原则。

UML中常用的9种图及其应用场景

1. 用例图（Use Case Diagram）

• 用途：描述系统功能需求及参与者（Actor）与用例（Use Case）的交互关系，适用于需求分析阶段。
• 核心元素：
  • 参与者：外部实体（如用户、其他系统）。
  • 用例：系统功能单元（如“登录”“支付”）。
  • 关系：包含（<<include>>）、扩展（<<extend>>）、泛化（继承）。

2. 类图（Class Diagram）

• 用途：定义系统中的类、接口及其关系（如继承、聚合），是面向对象设计的核心工具。
• 关系强弱排序：泛化 > 组合 > 聚合 > 关联 > 依赖。

3. 时序图（Sequence Diagram）

• 用途：展示对象间消息传递的时间顺序，强调交互的时序性，常用于详细设计阶段。
• 元素：对象生命线、激活条（控制焦点）、同步/异步消息（实心箭头/普通箭头）。

4. 协作图（Collaboration Diagram）

• 用途：与时序图等价，但更关注对象间的组织结构而非时间顺序，可通过消息序号推断时序。
• 元素：对象、链接、带序号的消息。

5. 状态图（Statechart Diagram）

• 用途：描述对象在其生命周期中的状态变化（如订单状态从“待支付”到“已完成”），适用于有复杂状态迁移的系统。
• 元素：状态、转移（触发事件/监护条件/动作）、初始/终止状态、子状态（顺序/并发）。

6. 活动图（Activity Diagram）

• 用途：类似流程图，但支持并发与泳道（Swimlane），描述业务流程或操作步骤。
• 元素：起始点、活动节点、分岔/汇合（并发控制）、对象流。

7. 组件图（Component Diagram）

• 用途：展示系统的物理模块（如DLL、微服务）及其依赖关系，支持基于组件的开发（CBD）。
• 关键概念：组件通过接口提供服务，可独立替换和部署。

8. 部署图（Deployment Diagram）

• 用途：描述系统在物理硬件（如服务器、网络节点）上的部署结构，适用于分布式系统设计。
• 元素：节点（Node）、构件（Artifact）、连接线。

9. 对象图（Object Diagram）

• 用途：类图的实例化快照，展示特定时刻对象间的静态关系，用于调试或场景验证。

2. 继续团队协作继续进行开源项目的质量分析及总结工作

   （a）分工协作，利用SonarQube工具或人工方式对维护的开源项目进行质量分析；
       参照《质量分析报告模板》，每人至少写出开源项目中的5处以上较严重的问题、分析及解决方案，并附上截图。

利用SonarQube分析出的较为严重的问题：
Security Hotspot1：

权限没有合适的保护，导出的 Android 组件可供其他应用程序使用。这可能会允许访问本应保持私密的功能。一旦 Android 组件被导出，攻击者便可利用该组件发起恶意操作，甚至可能访问其他未导出的组件。

解决方案：

Security Hotspot2：

Make sure that using this pseudorandom number generator is safe here.

  确保在此使用此伪随机数生成器是安全的。PRNG 是一种生成近似真随机数序列的算法。虽然它们适用于模拟或建模等应用，但并不适用于安全敏感环境，因为如果内部状态已知，其输出结果即可预测。使用非加密 PRNG 会导致以下漏洞：

• CVE-2013-6386
• CVE-2006-3419
• CVE-2008-4102

解决方案：（三选一）

·  使用加密安全伪随机数生成器（CSPRNG）如“java.security.SecureRandom”代替非加密 PRNG。

生成的随机值仅使用一次。

生成的随机值不应公开。如果必须存储，确保数据库或文件的安全。

Security Hotspot3：

"usesCleartextTraffic" is implicitly enabled for older Android versions. Make sure allowing clear-text traffic is safe here.

旧版 Android 系统已隐式启用“usesCleartextTraffic”。请确保此处允许明文流量是安全的。诸如 ftp 、 telnet 或 http 类的明文协议缺乏对传输数据的加密，也无法建立经过身份验证的连接。这意味着，能够嗅探网络流量的攻击者可以读取、修改或破坏传输的内容。

解决方案：

确保应用程序数据通过安全、经过身份验证和加密的协议（例如 TLS 或 SSH）进行传输。常见的选择：

使用 ssh 作为 telnet 的替代。

使用 sftp 、 scp 或 ftps 代替 ftp 。

使用 https 而不是 http 。  

使用 SSL/TLS 上的 SMTP 或带有 STARTTLS SMTP 而不是明文 SMTP。

Security Hotspot4：

Move constants defined in this interfaces to another class or enum.

将此接口中定义的常量移动到另一个类或枚举。当接口仅由常量定义组成而没有其他成员时，此规则会引发问题。仅由常量定义组成的接口是一种糟糕的做法。接口的目的是提供 API，而不是实现细节。也就是说，它们应该首先提供函数，然后仅提供常量来辅助这些函数，例如，作为可能的参数。

解决方案：

用枚举或具有私有构造函数的最终类替换该接口。

（枚举）

（移动到特定的现有类）

使用 final 类并带有私有构造函数。与接口不同，final 类既不能被继承，也不能被实例化。

Security Hotspot5：

Use static access with "net.micode.notes.data.Notes$DataColumns" for "MIME_TYPE".使用“net.micode.notes.data.Notes$DataColumns”对“MIME_TYPE”进行静态访问。

解决方案：

使用“net.micode.notes.data.Notes$DataColumns”对“MIME_TYPE”进行静态访问。

   （b）形成开源项目维护前后的2个质量报告，进行对比,展示改进之处。

见小组报告。

3. 个人开源项目工作总结报告: 总结自己的开源项目工作，补充项目泛读报告中的UML图；工作进度。将项目所建的各种文档分类打包，每个人将自己对项目的共享工作写一份总结成果文档，汇总交给组长。

4. 小组准备项目汇总的资料(包括）：（下周提交）

 开源项目泛读报告；
 开源项目质量分析报告；
 项目工作跟踪记录（每周进度：甘特图；git项目协作工作，开放平台网址或项目打包等）;
 各类过程跟踪报告（代码分析、标注文档）；
 维护需求与设计结果（新增代码文档等）;
 个人开源项目工作总结报告；
 附加其他工作资料...

实验八 需求建模技术及开源项目总结

1. 练习各种建模技术

（1）用CASE工具画出课本P115图4-7 图书馆借出事务的消息时序图MSC。

     参考P118 图4-11，在图4-7中补充lost场景的消息时序

（2）用CASE工具画出课本P117图4-9 Publication类的UML状态图。

     分析它为什么比图4-10简洁、清晰?

子状态机被认为是并发运转的，因为一个publication实例可能在任何时刻接收并响应
任何一个子状态机感兴趣的事件，或者两个子状态机同时都感兴趣的事件。一般情况下，并发的子状态机用于建模单独的、不相关的子行为，使得更容易理解和考虑每一个子行为。

（3）用CASE工具画出课本P120图4-12 描述借书的Petri网

     Borrow是可激活的变迁吗？如果触发Return变迁，令牌Mark将如何变化？

Borrow 是一个可激活的变迁，因为它的输入库所包含的条件满足（即输入库中有令牌）。当触发 Borrow 变迁时，令牌会从输入库 Validate Loan Request 移动到输出库 OnLoan。

如果触发 Return 变迁，令牌的变化如下：

Return 的输入库 OnLoan 中的令牌会被移除。

令牌会移动到 Validate Return Request，即 Return 的输出库。

实验9 软件体系结构设计

1. 小组分工、协作：

  网上搜索最新的软件体系结构，每人选1个关注的专题学习，阐述其技术特点。思考：软件架构在软件设计中的作用、地位？

如：C/S（MVC、存算分离）、PeerToPeer（区块链）、微服务、典型的管道过滤器风格等，

参考资料：

  《An Introduction to Software Architecture》 （3. Common Architecture Styles）

    结构之美(beautiful Architecture spinellis)

    Software Architecture in Practice ，3rd Edition

Documenting Software Architectures ，2nd，Paul Clements       Main Page - Software Architecture Documentation (SAD) - Confluence

专题选择：微服务架构的技术特点

微服务架构是近年来最受关注的软件体系结构之一，尤其在云计算和分布式系统领域被广泛应用。其核心思想是将单一应用拆分为多个独立、松耦合的小型服务，每个服务专注于特定业务功能，并通过轻量级协议（如HTTP/REST或消息队列）进行通信。我将从技术特点、优势与挑战等方面展开分析。

一、微服务架构的技术特点

1. 服务独立性与自治性
   每个微服务独立开发、部署和扩展，拥有专属的数据存储和业务逻辑。例如，电商系统可拆分为订单服务、用户服务、支付服务等，各自使用不同的数据库（如MySQL、MongoDB），避免传统单体架构的数据库耦合问题。
2. 轻量级通信机制
   微服务间通过API网关或事件驱动模式（如Kafka）进行通信，支持同步（REST）和异步（消息队列）交互。这种设计降低了服务间的依赖，提高了系统的容错能力。
3. 去中心化治理与技术多样性
   不同服务可采用不同的编程语言、框架或技术栈。例如，高性能计算模块可能用Go语言，而数据分析模块使用Python。这种灵活性使团队能根据需求选择最优技术方案。
4. 动态扩展与弹性设计
   通过容器化（如Docker）和编排工具（如Kubernetes），微服务可根据负载动态伸缩。例如，在“双十一”促销期间，订单服务可单独横向扩展以应对流量高峰。
5. 持续交付与DevOps集成
   微服务支持独立流水线部署，结合CI/CD工具（如Jenkins），实现高频次更新而不影响整体系统。例如，Netflix通过微服务架构实现每日数千次部署。

二、微服务架构的优缺点分析

1. 优势
   • 高可维护性：模块化设计使代码修改局限于单个服务，降低维护成本。
   • 故障隔离：单个服务故障不会导致系统整体崩溃，如支付服务异常不影响用户浏览商品7。
   • 技术选型灵活：团队可根据服务特性选择最适合的技术栈。
2. 挑战
   • 分布式系统复杂性：需处理服务发现、负载均衡、分布式事务（如Saga模式）等问题。
   • 运维成本高：监控、日志聚合（如ELK）和链路追踪（如Zipkin）需额外工具支持。
   • 数据一致性难题：跨服务事务需通过最终一致性方案解决，如事件溯源（Event Sourcing）。

软件架构在软件设计中的作用与地位

软件架构是软件系统的骨架，决定了系统的技术路线、质量属性及演化能力。其核心作用体现在以下方面：

1. 指导系统的高层次设计
   架构定义了组件划分、交互模式及技术选型。例如，分层架构（如MVC）通过分离表示层与业务逻辑层，提升代码可读性。
2. 平衡功能与非功能需求
   架构设计需权衡性能、安全性、可扩展性等非功能属性。例如，金融系统采用微服务架构实现高可用性，同时通过API网关强化安全控制。
3. 促进模块化与复用
   通过组件化设计（如插件架构），减少重复代码。例如，Android系统通过分层架构实现硬件抽象层（HAL）的复用。
4. 支持系统演化与适应性
   良好的架构预留扩展接口，例如预留API支持未来集成AI功能，避免大规模重构。
5. 降低开发与维护成本
   清晰的架构文档（如UML图）帮助团队理解系统，减少沟通成本。例如，阿里通过中台架构复用通用服务（如用户认证），缩短新业务开发周期。

2.将以下故障树转换为割集树，求出最小割集。

故障树的顶事件为 `T`，其逻辑关系如下：

- `T = A1 OR A2`

- `A1 = X1 AND X2 AND B1`

- `B1 = X1 OR X3`

- `A2 = X4 AND B2`

- `B2 = C OR X6`

- `C = X4 AND X5`

根据故障树的逻辑关系，逐步展开顶事件 `T` 的表达式：

 (1) 展开 `A1` 和 `A2`：

```

T = (X1 AND X2 AND B1) OR (X4 AND B2)

```

 (2) 展开 `B1`：

```

B1 = X1 OR X3

```

代入 `T`：

```

T = (X1 AND X2 AND (X1 OR X3)) OR (X4 AND B2)

```

 (3) 简化 `X1 AND (X1 OR X3)`：

```

X1 AND (X1 OR X3) = X1

```

因此：

```

T = (X1 AND X2) OR (X4 AND B2)

```

 (4) 展开 `B2`：

```

B2 = C OR X6

```

代入 `T`：

```

T = (X1 AND X2) OR (X4 AND (C OR X6))

```

 (5) 展开 `C`：

```

C = X4 AND X5

```

代入 `T`：

```

T = (X1 AND X2) OR (X4 AND ((X4 AND X5) OR X6))

```

(6) 简化 `X4 AND (X4 AND X5)`：

```

X4 AND (X4 AND X5) = X4 AND X5

```

因此：

```

T = (X1 AND X2) OR (X4 AND (X4 AND X5 OR X6))

```

(7) 分配律展开 `X4 AND (X4 AND X5 OR X6)`：

```

X4 AND (X4 AND X5 OR X6) = (X4 AND X5) OR (X4 AND X6)

```

代入 `T`：

```

T = (X1 AND X2) OR (X4 AND X5) OR (X4 AND X6)

```

割集树是通过将顶事件的逻辑表达式转换为割集的形式得到的。根据上面的表达式：

```

T = (X1 AND X2) OR (X4 AND X5) OR (X4 AND X6)

```

割集为：

- `{X1, X2}`

- `{X4, X5}`

- `{X4, X6}`

最小割集是割集中无法再进一步简化的集合。在这里，所有割集已经是最小的，因此最小割集为：

```

{X1, X2}, {X4, X5}, {X4, X6}

```

最小割集为：

```

{X1, X2}, {X4, X5}, {X4, X6}

```

3. 体系结构风格案例 KWIC 设计

 （1）参考课本5.7.4及参考资料， 针对KWIC的多种体系结构风格案例，小组分工、协作进行设计。

   （a）要求给出KWIC案例的共享数据的主程序/子程序风格设计；

   （b）要求给出KWIC案例的抽象数据类型ADT 风格设计；

   （c）要求给出KWIC案例的PipeLine风格设计；

   （d）要求给出KWIC案例的发布/订阅（隐含调用）风格设计；

 参考资料：参阅课本和网上资料，研究体系结构风格。

   An Introduction to Software Architecture （4.1. Case Study 1: Key Word in Context）

   On-the-Criteria-To-Be-Used-in-Decomposing-Systems-into-Modules

   http://www.cs.cmu.edu/~ModProb/KWIC.html  CMU（卡耐基梅隆大学）Solution 4: Dataflow（PipeLine）

（2）总结各设计方案在不同质量属性上的优缺点，

    参考课本表5-2，表5-3，对已做的四种体系结构风格的设计进行对比：

    评测不同设计方案的质量属性，如：性能，易修改性。

见小组报告。