EagleBear2002 的博客

摘要

$$ \def\Var{\mathsf{Var}} \def\IG{\mathsf{IG}} \def\T{\mathcal{T}} \def\S{\mathcal{S}} $$

摘要

在在线事务处理（OLTP）系统中，可序列化是事务执行的一个关键属性；如果没有它，由于并发活动，可能会违反数据的完整性约束。可以通过使用严格的两阶段锁定（S2PL）等可序列化并发控制机制来保证可序列化，而不考虑应用程序逻辑。然而，这种机制导致的并发性降低通常过于严重，因此数据库管理系统（DBMS）为数据库管理员（DBA）提供了使用不同并发控制机制的机会，前提是这样做是安全的。然而，此前几乎没有理论可以指导 DBA 判断何时是安全的！

在本文中，我们讨论了如何为一组事务分配适当的隔离级别（从而使用特定的并发控制机制），同时确保每次执行都是冲突可序列化的。当每个事务可以选择使用 S2PL 或快照隔离（SI）时，我们精确地描述了可接受的分配，并提供了一个简单的基于图的算法来确定最弱的可接受分配。

本文涉及的类别和主题描述包括：数据库管理系统中的事务处理。关键词包括：并发控制、可序列化、异常、一致性、快照隔离、两阶段锁定。

$$ \def\wr{\mathsf{\textcolor{teal}{wr}}} \def\ww{\mathsf{\textcolor{red}{ww}}} \def\rw{\mathsf{\textcolor{blue}{rw}}} \def\mixing{mixing} \def\Vset{\mathrm{Vset}} \def\MSG{\mathrm{MSG}} $$

摘要

当前的商业数据库允许应用程序开发人员为了性能而牺牲一致性。然而，现有的弱一致性级别的定义要么不够精确，要么不允许使用诸如乐观锁等高效的实现技术。排除这些技术尤其不幸，因为商业数据库支持乐观机制。此外，乐观锁很可能成为未来地理分布和移动系统中首选的实现技术。

本论文首次提出了现有 ANSI 隔离级别的独立于实现的规范，以及在商业系统中广泛使用的若干级别的规范，例如，游标稳定性、快照隔离。它还以独立于实现的方式为基于谓词的操作指定了各种保证。定义了两个新级别，为应用程序编写者提供有用的一致性保证；一个是确保一致读取的最弱级别，而另一个则捕获了悲观实现所提供的某些有用的一致性属性。我们使用基于图的方法以简单直观的方式定义不同的隔离级别。

论文描述了在分布式客户端-服务器环境中支持不同弱一致性级别的新实现技术。这些机制基于乐观锁，并利用多部分时间戳。提出了一种新技术，允许多部分时间戳随着系统中客户端和服务器数量的增加而良好扩展；该技术利用松散同步的时钟来从多部分时间戳中移除旧信息。

摘要

本文根据复习课录音和大模型总结了软件安全的期末考点。题目来自教材课后习题，仅提供简单题和阅读报告题，不提供实验题和复杂的阅读报告题。

如无特殊标注，本文的题目答案来源为 PPT 或教材。使用大模型生成的回答会有明确标注。

考试题型：只靠概念题，10 道简答；每章一道，来自书后概念习题（除去 3，9，10，11 章）。

本文参考了 南京大学软件学院-2023-软件安全（研究生）期末复习参考 - 知乎。

摘要

本文总结了软件工程管理的期末考点。考虑到本课程为半开卷考试，本文只用有限的篇幅展示最重要的部分，读者自由复制打印。

点击链接下载：2024Fall-软件工程管理 v5 衬线字体带习题.docx。

课程概念梳理：

$$ \text{敏捷} \left{\begin{matrix} \text{Scrum 框架} \ \text{XP 实践}\left{\begin{matrix} \text{简单设计} \ \text{（频繁）重构} \ \text{持续集成} \ \text{测试驱动开发} \ \text{结对编程} \ \end{matrix}\right. \end{matrix}\right. $$

摘要

开发周期

XP 的心跳——开发周期

这是程序员实现一个工程任务（最小的调度单位）并与系统其余部分集成的地方。

开发周期 (1)

摘要

课程目的

• 阅读、思考软件工程历史中的经典书籍、论文，了解软件工程思想的来龙去脉。
• 学习最新的软件工程管理方法论、实践、工具。
• 知其然，知其所以然。
• 学会自主的思考软件开发，自主判断
  • 需要广泛、深刻的知识学习；批判性思维习惯
  • “记忆”、“分析”这些相对低水平的认知
  • “综合”、“判断”和“运用”等深层次的学习

软件工程和其它相关学科关系

摘要

定义

看板方法，由 David Anderson 创立，它脱胎于大野耐一所创立的丰田生产方式（TPS），以及埃利亚胡·高德拉特（Eli Gol-dratt）的约束理论（TOC），并结合统计质量控制（SQC）、排队论（QT）、工业工程（IE）、软件成熟度模型（CMMI）等多个领域的知识，在软件开发社区中获得了极高的关注度，并迅速传播开来。

历史

大卫·J.安德森（David J. Anderson）

摘要

项目成功？

为什么敏捷与精益出现在软件开发行业？

• 软件开发本质属性：复杂性、一致性、可变性、不可见性。
• 敏捷与精益本质上是帮助我们处理软件开发的复杂性、可变性。
• 敏捷的本质，是承认软件开发的复杂性。而且承认，这种复杂性，达到了这样一种程度：“无法通过足够充分的前期准备，而消除后续的风险。甚至于，前期准备得越是充分，后续的风险越大。”
• 敏捷软件开发是当前应对模糊需求、快速变化需求的最佳方式。

敏捷软件开发很流行

摘要

敏捷思想存在很久

敏捷运动源自 1990 年代一些与软件开发过程打交道的人士的工作，他们发现需要寻找软件开发过程的新途径。其实，这些途径中的大部分思想并不是新的，许多人认为，很长一段时间以来的成功软件都是依据这些思想来建造的。但这些思想却被压抑了，没有受到足够的重视，特别是在那些从事软件开发过程的人士中。有一些根本性的原则是所有敏捷方法的共同之处，这些原则与那些传统软件工程方法的前提假设是截然相反的。

从无、到繁重、再到敏捷

多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改”（code and fix）。设计过程充斥着短期的、即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。