EagleBear2002 的博客

桥接模式

模式动机

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），客户可以通过它与系统进行通信。稍后将对此进行更详细的讨论。

Architecturally Significant Requirements

1. 架构攸关的需求（ASR）是对体系结构产生深远影响的要求-如果没有这样的要求，体系结构可能会发生巨大的变化。An Architecturally Significant Requirement (ASR) is a requirement that will have a profound effect on the architecture - the architecture might well be dramatically different in the absence of such a requirement.
2. QA 需求越困难和重要，就越有可能显着影响体系结构，从而成为 ASR。The more difficult and important the QA requirement, the more likely it is to significantly affect the architecture, and hence to be an ASR.
3. 如何系统地识别将影响 ASR 和其他因素？How to systematically identify the ASRs and other factors that will shape the architecture?
   1. 从需求文档中收集 ASR Gathering ASRs from requirements documents
   2. 通过采访涉众来收集 ASR Gathering ASRs by interviewing stakeholders
   3. 通过了解业务目标来收集 ASR Gathering ASRs by understanding the business goals
   4. 在项目树中管理 ASR Capturing ASRs in a utility tree

Gathering ASRs from Requirements Documents

1. 无论是使用“MoSCoW”样式指定需求还是作为“用户故事”的集合来指定需求，这些都不能帮助您确定质量属性。Whether requirements are specified using the "MoSCoW" style or as a collection of "user stories", neither of these is much help in nailing down quality attributes.
2. MoSCoW 样式：https://blog.csdn.net/cheny_com/article/details/6358456，使用四个级别来定义一个需求的优先级程度
3. 需求文档通常会以两种方式使架构师失败：Requirements documents often fail an architect in two ways:
   1. 需求规范中的大多数内容都不会影响体系结构。Most of what is in a requirements specification does not affect the achitecture.
      1. 系统应模块化 The system shall be modular
      2. 系统应显示出高易用性 The system shall exhibit high usability
      3. 系统应满足用户的性能期望 The system shall meet users' performance expectations
   2. 对架构师有用的大部分内容甚至都没有出现在最佳需求文档中 Much of what is useful to an architect is not in even the best requirements document.
      1. 在收购环境中，需求文档代表的是收购方的利益，而不是开发商的利益。In an acquisition context, the requirements document represents the interests of the acquirer, not that of the developer.
4. 如果某项要求影响了关键体系结构设计决策的制定，那么根据定义，它就是 ASR。If a requirement affects the making of a critical architectural design decision, it is by definition an ASR.

Gathering ASRs by Interviewing Stakeholders

Document Architecture

Why to document software architecture?

1. 这是记录软件架构的几个很好的理由，例如：There are several good reasons for documenting software architecture such as:
   1. 交流和社交化架构设计决策 Communicating and socialising architecture design decisions
   2. 帮助理解和评估架构设计决策 Helping understand and assess architecture design decisions
   3. 刷新设计师对某些决策的记忆 Refreshing designers' memories about certain decisions
   4. 培训架构设计人员 Training people in designing architecture
   5. 支持地理位置分散的团队 Supporting geographically ditributed teams
2. 体系结构文档用于以下活动：Architecture documentation is used for several activities:
   1. 架构设计分析 Architecture design analysis.
   2. 工作分解和分配 Work breakdown and assignment.
   3. 部署后维护 Post-deployment maintenance.
3. 软件体系结构文档提供了维护和修改决策的框架 Software architecture documentation provides a framework for maintenance and modification decisions.

Challenges in documenting architecture

1. 没有普遍接受的记录软件架构的标准或方法。No universally accepted standard or method of documenting software architecture.
2. 记录大型系统的架构可能是一项耗时且重要的任务。 Documenting architecture of large-scale system can be time consuming and non-trivial task.
3. 对用于记录架构的视图的数量和性质没有达成共识 - 资源密集型活动。No consensus on the number and nature of views used to document architecture-resource intensive activity.
4. 迫在眉睫的最后期限和不断发展的架构性质不利于架构文档的流通。Looming deadlines and evolving nature of architecture are detrimental to the currency of architecture documentation.
5. 缺乏全面的符号和工具。Absence of a comprehensive notation and tooling.

Architectural Pattern

1. 架构模式是一组架构设计决策，适用于重复出现的设计问题，并进行了参数化处理以解决出现该问题的不同软件开发环境。An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.
2. 体系结构模式与 DSSA 相似，但适用于较低级别，范围更窄。Architectural patterns are similar to I SSAs but applied at a lower level" and within a much narrower scope.
3. 课本 227 页

Domain-Specific Software Architecture

1. 领域特定的软件体系结构（DSSA）是软件组件的组合 Domain-Specific Software Architectures (DSSA) is an assemblage of sottware components
   1. 专用于特定类型的任务（域） specialized for a particular type of task (domain) generalized for effective use across that domain, and
   2. 普遍适用于该领域的有效使用 composed in a standardized structure (topology)
   3. 有效构建成功应用程序的标准化结构（拓扑）组成 effective for building successful applications.
2. DSSA 是最大限度地重用知识和进行先期开发并因此开发新的体系结构设计的卓越手段。DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design.

Course Logistics

Why Study Software Design & Architecture?

1. 软件（IT）系统无处不在 Software(IT) systems are everywhere
2. 每个软件密集型（组成的）系统都有一个软件设计和体系结构 Every software intensive system has a software design and architecture
3. 软件设计和体系结构是实践，教育和研究中越来越重要的领域 Software design and architecture are an increasingly important area of practice, education, and research
4. 专业：软件架构师 As a profession: Software Architect
5. 作为研究领域 As a research area
   1. 最初于 1960 年左右开始 Originally started around 1960
   2. 自 1990 年以来备受关注 Attracting major attention since 1990
6. 本课程是关于 This course is about
   1. 软件设计和体系结构的概念，原理，方法和模式 Concepts, principles, methods, and patterns of software design and architecture
   2. 软件设计和体系结构的最新实践 State-of-the-art practices of software design and architecture

Learning Objectives

1. 理解软件设计和体系结构的概念和原理 Understand concepts and principles of software design and architecture
2. 通过考虑需求或通过反向体系结构来创建软件体系结构 Create software architecture by taking requirements or through reverse architecting
3. 在创建软件体系结构和设计的时候应用设计模式、风格、中间件技术和框架 Apply tactics, patterns, styles, middleware technologies and frameworks in creating software architecture and design
4. 系统地分析软件设计和评估软件体系结构 Analyze software design and evaluate software architecture systematically
5. 理解艺术式的设计是如何应用到软件设计与体系结构中的 Understand state-of the-art methods applied in software design and architecture
6. 理解软件设计与软件体系结构之间的关系，以及其他软件工程的领域话题 Understand relationships between software design and software architecture, and other software engineering topic areas

Software Architecture

软件架构是结构和系统结构，包含了软件元素、这些组件的外部可视化属性以及他们之间的关系。Software Architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of these components, and the relationship among them.（In practice 书中的定义）

单独的盒式模型不是架构，但是是一个开始的点 Box-and-line drawings alone are not architecture, but a starting point.

架构包含了组件的行为 Architecture includes behaviour of components.

Role of Architecture