EagleBear2002 的博客

软件模式

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. 适配器提供客户类需要的接口，适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用。也就是说：当客户类调用适配器的方法时，在适配器类的内部将调用适配者类的方法，而这个过程对客户类是透明的，客户类并不直接访问适配者类。因此，适配器可以使由于接口不兼容而不能交互的类可以一起工作。这就是适配器模式的模式动机。

模式定义

外观模式

模式动机

引入外观角色之后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。外观模式

模式定义

防御式编程 Defensive Programming

可用、正确和优秀的代码

1. 编写大多数情况下都能用（可用）的代码很容易：但是提供意外输入会崩溃。
2. 正确的代码绝不会崩溃
   1. 但所有可能输入集合很大，难以测试
   2. 并非所有正确的代码都是优秀的代码：可能逻辑难以理解，并且几乎无法维护。
3. 优秀的代码是健壮的、高效的、当然也是正确的：即便面对不常见输入，产品级代码也不会崩溃和产生错误的结果。

编程中的常见设想

1. 这个函数"绝不会"被那样调用：传递给我的参数总是有效的
2. 这段代码肯定会"一直"正常运行：它绝对不会产生错误
3. 如果我把这个变量标记为"仅限内部使用"，就没有人会尝试访问这个变量
4. 进行防御式编程时，不应该做任何设想！

Note: this is a simplified and generalized description of a real system

Introduction

The Call Center Customer Care System has been developed by Andersen Consulting for a large US telecommunication company. The primary function of the system is to support interactions with the customers that request new services (ex: new phone lines), changes in the configuration of the existing services (ex: phone number changes, long-distance company changes, or relocation), or report problems.

The phone company has over 19Mil customers. Considering how often, on average, a customer changes his/her service configuration, the system has to support up to 400 company representatives simultaneously at near 7X24 availability level. However, these representatives are not the only means by which a customer can request a change or report problems. For example, there exists a phone service (Quick Service) by which customers can communicate with the system. This is discussed in more detail later.

呼叫中心客户服务系统是由 Andersen Consulting 为美国一家大型电信公司开发的。系统的主要功能是支持与请求新服务（例如：新电话线）、现有服务配置更改（例如：电话号码更改、长途公司更改或搬迁）的客户的交互，或报告问题。

这家电话公司拥有超过 1900 万客户。考虑到客户平均多久更改一次他/她的服务配置，系统必须同时支持多达 400 名公司代表，且可用性水平接近 7X24。但是，这些代表并不是客户可以请求更改或报告问题的唯一方式。例如，存在一种电话服务（Quick Service），客户可以通过它与系统进行通信。稍后将对此进行更详细的讨论。