Architectural Design

1. 了解为什么软件的架构设计很重要。
2. 了解在架构设计过程中必须做出的关于软件架构的决定。
3. 我们已经了解了架构模式的概念，这是组织软件架构的良好尝试方式，可以在系统设计中重复使用。
4. 了解如何在交易处理和语言处理系统中使用特定应用的架构模式。

关注了解一个软件系统应该如何组织，并设计系统的整体结构。

• 它是设计工程和需求工程之间的关键环节，因为它确定了系统中的主要结构部件以及它们之间的关系。
• 输出是一个架构模型，描述了系统是如何被组织成一组通信组件的。

敏捷方法和架构设计: 敏捷开发过程的早期阶段应着重于设计整体的系统架构，因为重构系统架构通常很昂贵。

需求工程和架构设计: 在实践中，需求工程和架构设计这两个过程之间有很大的重叠。

Advantages of Explicit Arch

• Stakeholder communication: 架构是对系统的高层次介绍，可作为一系列不同利益相关者讨论的重点。
• System analysis: 架构设计决定对系统是否能满足关键要求有深远的影响。
• Large-scale reuse: 大规模的再利用

Architectural Representations

• 软件架构通常使用简单的框图进行非正式的建模。
  • 框中的方框表示组件的分解，箭头表示数据和控制流
• Two contradictory「相互矛盾」 views
  • 它们缺乏语义，也就是说，它们不显示 关系的类型 或 组件的外部可见属性。
  • 它们对与利益相关者的沟通和项目规划非常有用。

Use of Architectural Models

• 作为促进讨论系统设计的一种方式
  • 系统的高层架构视图对于与系统利益相关者的沟通和项目规划非常有用，因为它不会被细节所干扰。
  • 利益相关者可以与之联系起来，理解系统的抽象观点。然后，他们可以把系统作为一个整体来讨论，而不会被细节所迷惑。
  • 架构模型确定了要开发的关键组件，这样管理人员就可以开始分配人员来规划这些系统的开发。
• 作为记录已设计好的架构的一种方式
  • 这里的目的是产生一个完整的系统模型，显示系统中的不同组件、它们的接口和它们的连接。

Architectural Design Decisions

一些共同的决定跨越了所有的设计过程，这些决定影响着系统的非功能特性。

• 是否有一个通用的应用架构，可以作为正在设计的系统的模板？
• 系统将如何在硬件核心或处理器之间分布？
• 可以使用哪些架构模式或风格？
  • 用来构建系统的基本方法是什么？
  • 系统中的结构部件将如何被分解成子部件？
  • 将采用什么策略来控制系统中各部件的运行？
• 什么样的架构组织最适合于交付系统的非功能需求？
• 应如何记录系统的架构？

eg. Architecture and NF Requirements

• Performance: 将关键操作本地化，尽量减少通信。使用大型而非细粒度的组件。
• Security: 使用分层架构，关键资产在内层。
• Safety: 将安全关键功能定位在少量的子系统中，以减少安全验证的成本和问题。
• Availability: 包括冗余的组件和容错机制。
• Maintainability: 使用细粒度的、独立的组件，可以很容易地进行更换。

其中一些选择之间存在着潜在的冲突!

Architectural Views

在设计和记录一个系统的架构时，哪些观点或视角是有用的？

• 每个架构模型只显示系统的一个视图或角度。
• 它可能显示一个系统如何被分解成模块，运行时进程如何互动，或者系统组件在网络上的不同分布方式。
• 对于设计和文档来说，你通常需要展示软件架构的多种观点。

应该使用什么符号来描述架构模型？非正式的模型和符号，例如UML，仍将是记录系统架构的最常用方式。

View Models of Software Architecture

• 4+1模型：四个基本的架构视图，通过共同的用例或场景联系起来。
  • A logical view，将系统中的关键抽象显示为对象或对象类。
  • A process view，这表明在运行时，系统是如何由相互作用的进程组成的。
  • A development view，它显示了软件是如何分解开发的。
  • A physical view, 它显示了系统硬件和软件组件如何分布在系统的处理器上。
• 另一个模型建议也添加概念视图的概念

Architectural Pattern

模式：一种呈现、共享和重用软件系统知识的方式。

• 架构模式是对良好设计实践的风格化描述，它已经在不同的系统和环境中得到了尝试和检验。
• 模式应包括关于何时适合和何时不适合使用的信息。
• 可以使用叙述性描述和图表的混合方式来描述模式。

Architectural patterns

• CS
• MVC
• Layered pattern
• Pipe and Filter pattern
• The Repository pattern

Layered Architecture

系统功能被组织成不同的层，每一层只依赖于紧靠其下一层提供的设施和服务。

• 支持不同层的子系统的增量开发。
• 当一个层的接口改变时，只有相邻的层受到影响。
• 然而，以这种方式构建系统往往是人为的
• 通用分层架构

• Description:

  • 将系统组织成若干层，每层都有相关的功能。
  • 一个层为它上面的层提供服务，所以最底层的层代表了整个系统可能使用的核心服务。

• When used:

  • 当在现有系统之上建立新的设施时；
  • 当开发工作分散在几个团队中，每个团队负责一层功能时；
  • 当有多级安全的要求时。

• Advantages:

  • 允许替换整个层，只要接口保持不变。

    可以在每一层提供冗余设施（如认证）以增加系统的可靠性。

• Disadvantages:

  • 在实践中，在各层之间提供一个干净的分离往往是困难的，一个高层可能不得不直接与低层互动，而不是通过紧随其后的层。
  • 性能可能是一个问题，因为在每一层处理服务请求时，需要对它进行多层次的解释。

Repository Architecture

子系统之间的数据交换可以通过两种方式进行

• 共享数据被保存在一个中央数据库或存储库中，所有子系统都可以访问。
• 每个子系统都维护自己的数据库，并将数据明确地传递给其他子系统。

围绕资源库组织工具是共享大量数据的一种有效方式。

• Description: 一个系统中的所有数据都在一个中央存储库中管理，所有系统组件都可以访问。组件不直接互动，只通过存储库。
• When used: 当你的系统中产生了大量的信息需要长期保存时，你应该使用这种模式。你也可以在数据驱动的系统中使用它，在这个系统中，将数据纳入资源库会触发一个动作或工具。
• Advantages:
  • 组件可以是独立的，它们不需要知道其他组件的存在。
  • 一个组件所做的改变可以传播到所有组件。
  • 所有的数据可以被一致地管理（例如，在同一时间进行备份），因为它们都在一个地方。
• Disadvantages:
  • 资源库是一个单点故障，所以资源库的问题会影响整个系统。
  • 通过资源库组织所有的通信，可能会有低效率。
  • 将资源库分布在几台电脑上可能很困难。

Client-Server Architecture

一个分布式系统模型，显示数据和处理是如何分布在一系列组件中的。

• 一组独立的服务器，提供特定服务，如打印、数据管理等。
• 一组调用这些服务的客户端。
• 允许客户端访问服务器的网络。
• 可以在一台计算机上实现。

A client–server architecture for a film library

MVC Pattern

• Description
  • 将演示和交互与系统数据分开。
  • 系统被结构化为三个逻辑组件，它们之间相互作用。
    • 模型组件管理着系统数据和对该数据的相关操作。
    • 视图组件定义并管理数据如何呈现给用户。
    • 控制器组件管理用户的交互（例如，按键、鼠标点击等）并将这些交互传递给视图和模型。
• When used
  • 当有多种方式来查看和交互数据时使用。
  • 也用于未来对数据的交互和展示的要求未知时。
• Advantages
  • 允许数据独立于其表示而改变，反之亦然。
  • 支持以不同方式呈现相同数据，并在所有方式中显示对一种表示所做的更改。
• Disadvantages
  • 当数据模型和交互很简单时，可能涉及额外的代码和代码的复杂性。

Pipe and Filter Architecture

一个系统运行时组织的模型，其中功能转换处理输入并产生输出

提示

这个名字来自于最初的 Unix 系统，在该系统中可以使用 "Pipe"来连接进程。之所以使用过滤器一词，是因为转换从其输入数据流中 "过滤 "出它可以处理的数据。

支付系统中使用的管道和过滤器结构的一个例子.

最适合于批处理系统和用户互动有限的嵌入式系统，但不太适合于互动系统。

• Description
  • 系统中的数据处理是这样组织的
  • 每个处理组件（过滤器）都是离散的，并进行一种类型的数据转换。
  • 数据从一个组件流向另一个组件进行处理（如在管道中）。
• When used: 常用于数据处理应用（包括基于批处理和事务处理），在这些应用中，输入在不同的阶段被处理以产生相关的输出。
• Advantages
  • 易于理解并支持转换重用。
  • 工作流风格与许多业务流程的结构相匹配。
  • 通过增加转换来进化是直接的。
  • 可以作为一个顺序的或并发的系统来实施。
• Disadvantages
  • 数据传输的格式必须在通信的转换之间达成一致。
  • 每个转换必须解析其输入，并将其输出解读为商定的形式。
  • 这增加了系统的开销，并可能意味着不可能重复使用不兼容的数据结构的功能转换。

Key Point

• 软件架构是对一个软件系统如何组织的描述。
• 架构设计的决定包括对应用类型、系统的分布、要使用的架构风格的决定。
• 架构可以从几个不同的角度或视图来记录，如概念视图、逻辑视图、流程视图和开发视图。「Architectures may be documented from several different perspectives or views such as a conceptual view, a logical view, a process view, and a development view.」
• 架构模式是重用通用系统架构知识的一种手段。它们描述了架构，解释了何时可以使用它，并描述了它的优点和缺点。