本书的原著为：《Design Patterns for Embedded Systems in C ——An Embedded Software Engineering Toolkit 》，讲解的是嵌入式系统设计模式，是一本不可多得的好书。

本系列描述我对书中内容的理解。本文章描述原书第 2 章的内容。

作为嵌入式软件开发人员，现在让我们把注意力转向一个基本问题，即：我们如何完成一个复杂设计。

作者是 IBM 公司 Harmony 流程的作者。Harmony 流程 是一种通用系统开发流程，在强调实时和嵌入式软件开发方面的同时，还包括生成通用软件和系统的步骤。 Harmony 流程已有效地应用于 1-3 人的小型项目以及由数百名团队成员组成的大型团队。 Harmony 是一种高度可扩展的“中等重量级”流程，在重量级流程和轻量级所谓的“敏捷方法”（例如极限编程 (XP)）之间取得平衡，同时结合了两者的各个方面。它是一种敏捷的、基于模型的软件开发方法，强调软件在整个开发、测试驱动开发和设计模式的使用过程中持续履行 Harmony 流程。

作者认为，遵循 Harmony 流程，有助于完成一个复杂的设计。

要理解这一章内容有点困难，因为这章内容是讲 方法论 的，涉及到很多名词，比较抽象。更重要的原因是我们看到的这章内容，实际上在作者另一本名为《Real Time UML Workshop for Embedded Systems》的书中，用了整本书来讲解。我们看到的是被压缩的内容，理解起来很困难就不奇怪了。

首先什么是 方法论 ？作者给出的解释是：方法论由语言和步骤组成。语言指定需要关注的元素(通常是类、函数)极其关系;步骤用来告诉开发人员使用语言的哪些部分、如何使用以及何时使用。Harmony 流程 是一种方法论，它使用 UML 极其变体作为语言。Harmony 流程还指定了一组各部分密切协调的工作流来指导开发人员，以便他们能够充分利用 UML 来开发健壮、有能力且安全的系统。

然后什么是 流程 ？在 Harmony 中，流程 是一种规范，规定了一组有序的 活动，由一组协作的工作人员执行，并且产出所需的项目成果。在这个定义中，活动 是工作人员在履行职责时所做的任务。

好的流程可以提供一种有效的指南，能够以最低成本开发高可靠性系统。坏的流程要么完全没有指定工作流，要么浪费开发人员的时间做错误的事情，比如生成厚厚的文档。

一个流程通常分为几个 阶段 ，可以认为流程是最大规模的 活动 。每个阶段都指定了一个或多个 工作流。每个工作流都是一组有序的活动(由工作人员执行的简单任务)以及产出构成。工作流 详细说明员工必须完成哪些活动？何时完成？如何完成？以及产出是什么？表示工作流的常见方法是使用 UML 活动图(活动图是九种 UML 图中的一种，描述业务实现用例的工作流程)，本书也是如此。

Harmony 流程侧重于三个时间尺度：宏周期、微周期和纳周期。较小的项目更多地关注微周期和纳周期，但随着项目规模的扩大，更多的注意力应转移到宏周期层面，以组织和协调整个开发过程。

1. 宏周期：侧重于项目的总体时间表和主要里程碑。项目管理、决策者需要关注，以月计。
2. 微周期：专注于开发单个经过验证的模块或原型。开发团队关注，以周计。
3. 纳周期：专注于软件的持续执行、调试和单元测试。个人关注，以分钟或小时计。

首先，设计是只有在我们从软件分析阶段获得了正确运行的软件之后才会发生的事情。其次，设计的重点是优化这个正确运行的软件。后一点很重要，因为这就是设计模式——本书的主题所做的。设计模式不是为了让软件正确工作；它们是为了让软件以最佳方式工作。

这也是现代敏捷开发提倡的做法，先跑起来，再寻求跑快。

Harmony 流程使用三个级别的设计：

1. 架构设计：着眼于整体优化系统，细分为五个关键视图：并发和资源视图、分布视图、安全性和可靠性视图、部署视图和子系统和组件架构视图。
2. 机制设计：这是一种设计方法论。在协作层面上优化，关注系统内部各组成部分之间的相互作用和因果关系。一组简单元素相互作用形成系统的各个功能。简单元素一般是指类、函数、变量等。
3. 详细设计：关注类、函数、变量等，是开发人员最常见的关注级别，通常对整体性能影响最小。

架构设计

我们所说的 系统架构 是指从系统角度识别影响大部分或全部系统的战略设计决策。 系统的观点是“高于”软件、电子或机械工程。 因此，系统架构重点关注子系统集的规范(子系统是由系统分解而来)、这些子系统的需求和功能的分配，以及这些子系统之间的接口。 在系统架构活动结束时，系统模型的一部分被移交给子系统团队，然后将每个子系统分解为工程学科，并开始更详细的分析和设计工作。

在 Harmony 流程中，我们将 架构 定义为一组战略设计决策，指定系统中的元素如何组织和交互。 我们定义中的关键术语是战略和设计。 在 Harmony 流程中，设计 就是优化。 分析模型主要由系统的功能需求驱动——系统需要做什么才能正确。 设计是由服务质量要求（这些功能必须实现的程度）以及统称为“设计标准”的其他优化特征驱动的。分析模型可以用几乎无限种不同的方式进行优化，以实现不同的优化目标。 例如，可以以最坏情况性能为代价来优化内存使用，或者可以以开发时间为代价来优化可重用性。

Harmony 流程中的另一个关键术语是 战略。 战略是与策略相关的、具有长远规划和目标的决策或行动。我通过战略，所有系统元素都必须与架构决策保持一致。 由于架构设计决策是在总体或总体级别上优化系统的尝试，因此此类决策是战略性的。

无论设计工作的范围如何，设计在很大程度上都是通过 设计模式 的应用来进行的。无论如何，设计模式都不是灵丹妙药；它们只是优秀设计师已经做过的事情的整理。 设计模式是重复出现的问题的通解。 最优秀的设计师会使用以前经过验证的设计解决方案。 设计模式方法以可重用的方式捕获这些解决方案，从而促进它们重新应用于其他问题。

机制设计

机制设计 在协作层面优化模型。 协作 是一组类和对象，它们一起工作以实现更大规模的行为，例如用例的实现。 由于典型的系统具有一到几十个用例），因此机制设计的设计决策范围比架构设计小一个数量级。 如果有 25 个用例协作，则必须应用机制设计 25 次，每个用例一次。 根据特定协作的特定需求，它将使用不同的设计模式，因为上下文可能不同，而且设计标准也可能不同。

协作是一组类和对象一起工作以实现更大范围的目的。 在面向对象编程中，一个对象通常具有特定的职责和行为。这些职责和行为可以通过类（Class）来表示。在更复杂的设计中，一个类可能不只代表一种角色或职责，而是可以扮演多种角色。协作是根据扮演命名角色的特定类来指定的，这些角色相互作用以产生更大规模的行为和功能。 设计优化问题的解决方案通常可以在不同的特定环境中推广和重用。 这种可重用的设计解决方案称为设计模式。 从抽象意义上讲，角色定义了模式的形式参数。 当与实际参数（来自分析协作的类）绑定时，该模式被称为实例化。 机制 是一种模式，其范围仅限于少数类（即，它没有架构范围），但通常适用于许多情况。 因此，机制设计是 Harmony 流程中的术语，指的是应用机制来产生设计级协作。

Harmony 设计过程非常注重模式。 下图显示了 Harmony 流程的机制设计工作流程。 要理解工作流程，重要的是要记住 Harmony 流程中建议的生命周期是螺旋形的； 螺旋生命周期将最终产品创建为一系列功能逐渐增强的版本，称为迭代原型。通常，在任何给定的螺旋中仅实现一个或少量用例。 随着更多螺旋的完成，原型变得越来越完整和强大，直到最终项目完成并将原型运送给客户。

正如建筑设计一样，明确指定设计标准以便选择适当的设计模式非常重要。 这些标准按重要性顺序排列。 此排名很重要，因为许多设计标准会相互冲突，并且设计模式的正确应用要求你以牺牲最不重要的设计标准为代价来优化最重要的设计标准。

常见的设计优化标准有：性能、可预测性、吞吐量、稳定性、安全性、可重用、可维护、可移植、可扩展。

确定重要的设计标准。这是经常被忽略的步骤。要记住，每当系统的某些方面得到优化时，其它一些方面总是会被牺牲。

这与 Gerald M. Weinberg 在《咨询的奥秘》中讲的那个故事很像：“给我们以最低的成本解决”、“在最短的时间内搞定”…，那么，“你愿意牺牲什么呢？”提升一方面，就要牺牲另一方面！

在项目刚开始的时候，有一些基础工作不能忽略：设定明确的目标和优先级、预先思考设计上和开发上的问题并设法预防、建立测试计划、设定质量标准。这是《微软研发致胜策略》一书中的原话。

详细设计

详细设计 在更低的抽象层次上优化系统。 详细设计应用惯用语来优化各个类的功能。详细设计的范围大约比机制设计小一个数量级。 虽然这听起来令人畏惧，因为典型系统中的类数量巨大，但实践表明，设计良好的系统中的大多数类都非常简单，几乎不需要优化。 通常有一小部分类（约 3% ~ 5%）需要特别努力。 正是针对这些“特殊需求”的类，我们在细节设计上投入了大部分的精力。

详细设计在类级别优化系统，因此主要关注类特征——属性、操作、状态、活动和端口。 协作涉及 10 到 100 个类（可能更多），但真正需要特别关注的只有少数类。 这些类在数据结构或行为方面更复杂，或者具有高优化要求的控制。

这里的 端口 的含义是：在面向对象编程中，特别是在UML（统一建模语言）中，“port”（端口）是一个与类相关的概念。它描述了类与外部环境的交互点，通常用于定义一组特定的服务或行为。

如何阅读本书中的设计模式

为了提高模式的可用性，本书的所有模式都以相同的方式组织，格式如下：

• 摘要
  简要描述该模式的应用场景，这是对问题、解决方案和结果的概述。
• 问题
  陈述问题的背景，陈述模式能解决什么问题。
• 模式结构
  这里提供模式的结构 UML 图，显示模式的重要元素，以及模式元素之间的关系。
• 结果
  描述使用该模式时所做的权衡。
• 实现策略和源代码
  讨论实现该模式的问题，围绕不同的计算平台或不同的编程语言来讨论。
• 例子
  每个模式都会有例子，说明如何应用该模式。包括UML 、 源代码等。

本章给出了一个模式例子： 观察者模式 。正是这个例子，让我入坑了这本书。全书描述的设计模式总共只有 4 类，分别是：

1. 访问硬件的设计模式 (Design Patterns for Accessing Hardware)
2. 嵌入式并发和资源管理的设计模式 (Design Patterns for Embedding Concurrency and Resource Management)
3. 状态机设计模式 (Design Patterns for State Machines)
4. 安全和可靠性模式 (Safety and Reliability Patterns)

对于嵌入式开发者来说，理解这些模式，以及这些模式背后的含义，并将它们运用到项目中去，一定会收获很多的。

---

读后有收获，资助博主养娃 - 千金难买知识，但可以买好多奶粉 (〃‘▽’〃)