EagleBear2002 的博客

约束求解问题

给定一组约束，求：

• 这组约束是否可满足
• （可选）如果可满足，给出一组赋值
• （可选）如果不可满足，给出一个较小的矛盾集 unsatisfiable core

总的来说是不可判定的问题，但存在很多可判定的子问题：

如：

摘要

由于线程交错的数量很大，分析多线程程序是困难的。偏序关系可用于建模和分析多线程程序。然而，目前尚无专用的决策过程用于解决偏序约束。在本文中，我们提出了一种新颖的有序一致性理论，用于在顺序一致性下验证多线程程序，并详细阐述了其理论求解器。该求解器实现了增量一致性检查、最小冲突子句生成和专用理论传播，以提高 SMT 求解的效率。我们在可信赖的基准测试上进行了大量实验，结果显示我们的方法显著提升了性能。

作者：清华大学软件学院 贺飞、Zhihang Sun、Hongyu Fan

Introduction

现在的计算系统中普遍使用共享内存多线程程序。并发程序的交错数量使得其在实践中很难进行验证。因此，开发技术来缓解并发程序验证中的执行爆炸问题是非常有意义的。

Working together

使用模式的最佳方式之一是让他们走出家门，这样他们就可以与其他模式互动。 你使用模式越多，你就会越多地看到它们一起出现在你的设计中。对于在设计中协同工作的一组模式，可以应用于许多问题，我们有一个特殊的名称：复合模式（Compound Pattern）。没错，我们现在说的是模式的模式！

• 模式经常一起使用，并结合在同一个设计解决方案中。
• 复合模式将两个或多个模式组合成解决重复出现或一般问题的解决方案。

Duck reunion

1. 实现 Quackable 接口
2. a Goose class：需要被 simulation 使用，使用适配器模式
3. 使用 adapter
4. 统计鸭叫的次数（要求不能修改原有的代码）：装饰器模式（不改变原本代码，而增加功能，装饰者接口与被装饰者接口一致）
   1. 装饰者两个缺点：设计上的缺点（注意）
   2. 想要封装的更好：工厂模式，抽象工厂（所有的行为要么都被观测，要么不被观察）
      1. 抽象工厂
      2. 抽象产品
   3. Counting Duck Factory
      1. 产品都是装饰者鸭
   4. 三个模式的联用
   5. 不同的鸭群要分开管理，想要在一群鸭子上执行操作：组合模式，只是监听（中介者模式），实现对组合的整体操作，结合迭代器模式
5. 实时跟踪每一个鸭子的叫的行为：观察者模式

软件模式

1. 软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件生存期的每一个阶段都存在着一些被认同的模式。
2. 软件模式可以认为是对软件开发这一特定“问题”的“解法”的某种统一表示，软件模式等于一定条件下的出现的问题以及解法。软件模式的基础结构由 4 个部分构成：问题描述、前提条件（环境或约束条件）、解法和效果。
3. 要能讲清为什么使用某个模式

3. 软件模式与具体的应用领域无关，在模式发现过程中需要遵循大三律（Rule of Three），即只有经过三个以上不同类型（或不同领域）的系统的校验，一个解决方案才能从候选模式升格为模式。

设计模式的定义

Outline

1. Software Architecture
2. Quality Attributes
3. Architecture Patterns
4. Designing Software Architecture
5. Documenting Software Architecture
6. Evaluating Software Architecture
7. Describing Architecture
8. Microservice Architecture *

Software Architecture in General

1. What is software architecture?
   • Structure, Elements, Relationships, Design
2. What does a software architect do?
   • Liaison, Software engineering Tech, knowledge, Risk mgmt
3. Where do architectures come from?
   • NFRs, ASRs, Quality Requirements; Stakeholders, Organizations, Technical Environments...
4. Architecture (4+1)Views
   • Logical view, Process view, Physical view, Development view + Use case scenarios...
5. Architectural activities and process
6. Software architecture knowledge areas

Architecture Process

表驱动法

1. 表驱动法是一种编程模式（scheme）：从表里面查找信息而不使用逻辑语句（if 和 case）
2. 表驱动法适用于复杂的逻辑
3. 表驱动法的另一个好处是可以将复杂逻辑从代码中独立出来，以便于单独维护

表驱动示例

1. Java 示例：使用复杂的逻辑对字符分类

1
2
3
4
5
6
7
8
9
10
11
12

if ((('a' <= inputChar) && (inputChar <= 'z')) ||
        (('A' <= inputChar) && (inputChar <= 'Z'))) {
    charType = CharacterType.Letter;
} else if ((inputChar == ' ') || (inputChar == ',') ||
        (inputChar == '.') || (inputChar == '!') ||
        (inputChar == '(') || (inputChar == ')') ||
        (inputChar == ':') || (inputChar == ';') ||
        (inputChar == '?') || (inputChar == '-')) {
    charType = CharacterType.Punctuation;
} else if (('0' <= inputChar) && (inputChar <= '9')) {
    charType = CharacterType.Digit;
}

什么是软件架构（体系结构）？

1. 很多人都试图给“架构”下定义，而这些定义相互之间却很难统一
2. 架构是一系列重要决策的集合，包括：软件的组织、构成系统的结构要素及其接口的选择、元素在协作中表现的行为
3. 软件架构即一系列重要的设计决策，这些决策上的失误可能最终导致软件系统项目的失败
4. 软件系统的架构将系统定义为计算组件（Components）及组件之间的交互：连接（Connector）和约束（Constraints）
5. 软件架构是一组具有特定形式的架构元素，包括:负责完成数据加工的处理元素（Processing Elements）、作为被加工信息的数据元素（Data Elements）、及用于将不同部分组合在一起的连接元素（Connecting Elements）。
6. 软件架构包括系统组件、连接件和约束的集合，反映不同涉众需求的集合、以及原理（Rationale）的集合。
7. 软件架构是以组件、组件相互间的关系、组件与环境之间的关系所描述的软件系统的基本组织结构，以及指导其设计与演化的原理（Principle）。
8. 软件架构是系统的单一或多重结构，它们由软件元素、这些元素的外部可见属性，以及元素之间的关系组成。

软件架构的演化

单体架构

1. 单体（Monolithic）应用的全部功能被集成在一起作为一个单一的单元。
2. 单体架构更多地作为应用的部署架构，即只要它部署在同一台（虚拟）机器上，运行于同一进程中，而无论应用内部如何模块化，服务化或者分层。

Architecture Process

Why to evaluate architecture?

1. 大型项目经常延迟交付和超出预算 Large projects often delivered late and over-budget
   1. 由于设计失败而无法及时交付 Don't function as promised due to design failures
   2. 商业组件不能按照预期运行 COTS components don't work as expected
2. 项目后期需要大量的返工 Considerable rework often required late in project
   1. 团队成员没有讨论这个问题 Team members not communicated the issues?
   2. 团队成员中缺少可以尽早发现问题的专家 Team members lacking expertise to detect problems early?
   3. 有代价 Costly
3. 架构评估有助于缓解这些问题 Architecture evaluations help alleviate these problems
   1. 彻底评估商业组件的稳定性 Thoroughly assess COTS component suitability
   2. 在问题变的需要一定代价去修复前识别发现问题 Identify problems before they become costly to fix
   3. 通知管理层，以方便他们做出更好的决策 Inform management so they can make better decisions
4. 在问题修复代价还比较低时尽早定位问题 Locate problems early when they are cheap to fix
   1. 设计缺陷 Design faults
   2. 没有考虑到的商业组件行为 Unexpected COTS components behavior
   3. 商业组件对整体系统架构不匹配 Mismatch of COTS components to overall architecture
5. 传播架构/设计最佳实践 Disseminate architecture/design best practices
   1. 评估者是可以发现最佳时间的专家 Reviewers are experts, can capture best practices
   2. 评估者拥有不同项目的广阔视野 Reviewers have broad perspective across many projects
6. 提供更好的技术和项目信息给管理层 Provide management with better technical and project information
7. 确定培训可以对常见问题领域产生广泛影响的领域 Identify areas where training could provide broad impact on commonly recurring problem areas
8. 改善与商业组件供应商的互动 Improve interactions with COTS component suppliers

When to evaluate an architecture?

桥接模式

模式动机

1. 设想如果要绘制矩形、圆形、椭圆、正方形，我们至少需要 4 个形状类，但是如果绘制的图形需要具有不同的颜色，如红色、绿色、蓝色等，此时至少有如下两种设计方案：
   1. 第一种设计方案是为每一种形状都提供一套各种颜色的版本。
   2. 第二种设计方案是根据实际需要对形状和颜色进行组合。

方案 1	方案 2

1. 对于有两个变化维度（即两个变化的原因）的系统，采用方案二来进行设计系统中类的个数更少，且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。

适配器模式

模式动机

1. 在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配器模式。
2. 通常情况下，客户端可以通过目标类的接口访问它所提供的服务。有时，现有的类可以满足客户类的功能需要，但是它所提供的接口不一定是客户类所期望的，这可能是因为现有类中方法名与目标类中定义的方法名不一致等原因所导致的。
3. 在这种情况下，现有的接口需要转化为客户类期望的接口，这样保证了对现有类的重用。如果不进行这样的转化，客户类就不能利用现有类所提供的功能，适配器模式可以完成这样的转化。
4. 在适配器模式中可以定义一个包装类，包装不兼容接口的对象，这个包装类指的就是适配器（Adapter），它所包装的对象就是适配者（Adaptee），即被适配的类。
5. 适配器提供客户类需要的接口，适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用。也就是说：当客户类调用适配器的方法时，在适配器类的内部将调用适配者类的方法，而这个过程对客户类是透明的，客户类并不直接访问适配者类。因此，适配器可以使由于接口不兼容而不能交互的类可以一起工作。这就是适配器模式的模式动机。

模式定义