在设计嵌入式系统之前，我们需要知道我们在设计什么。在这种情况下，术语“要求”和“规范”以多种方式使用-有些人将它们用作同义词，而另一些人将它们用作不同的阶段。它们在这里用来表示设计过程中相关但截然不同的步骤。

需求 是对客户需求的非正式描述，你而规格 则是可用于创建体系结构的系统的更详细，精确和一致的描述。但是，要求和规范都针对系统的外部行为，而不是其内部结构。

创建需求文档的总体目标是客户与设计人员之间的有效沟通。设计师应该知道他们期望为客户设计什么；客户，无论是事先知道的还是由营销代表的，都应该了解他们会得到什么。

我们有两种类型的需求：功能需求和非功能需求。功能需求说明了系统必须执行的操作，例如计算FFT。非功能性需求可以是许多其他属性，包括物理尺寸，成本，功耗，设计时间，可靠性等。一组好的要求应该满足几个测试：

正确性： 需求不应错误地描述客户的需求。正确性的一部分是避免过度需求-需求不应添加不必要的条件。

明确性： 需求文档应清晰且仅具有一种简单的语言解释。

完整性： 应包括所有要求。

可验证性： 应该有一种经济有效的方法来确保最终产品中的每个要求都得到满足。例如，如果没有就吸引力的定义达成一致，就很难验证系统软件包“有吸引力”的要求。

一致性： 一个要求不应与另一个要求相矛盾。

可修改性： 应该对需求文档进行结构化，以便可以对其进行修改以满足不断变化的需求，而又不会失去一致性，可验证性等。

可追溯性： 每个需求应通过以下方式可追溯：

1）我们应该能够从需求追溯到知道为什么每个需求存在的原因。

2）我们还应该能够追溯需求之前创建的文档（例如，市场备忘录），以了解它们与最终需求的关系。

3）我们应该能够向前了解如何在实施中满足每个要求。

4）我们还应该能够从实现中追溯，以了解他们打算满足哪些要求。

您如何确定需求？如果该产品是一系列产品的延续，那么许多要求都是众所周知的。但是，即使是最适度的升级，与客户交谈也是很有价值的。在大型公司中，营销或销售部门可能会执行大部分询问客户需求的工作，但是数量惊人的公司却让设计师直接与客户对话。

直接的客户联系为设计人员提供了客户所说的未经过滤的样本。它还有助于建立与客户的同理心，这通常会在更干净，更易于使用的客户界面中得到回报。与客户交谈还可能包括进行调查，组织焦点小组或要求选定的客户测试模型或原型。

开发更正式的系统规范

嵌入式开发工程师可以使用许多先进的技术来制定正式的系统规范。它们分为两大类：（1） 嵌入式开发工程师熟悉的面向控制的规范语言，例如SDL语言，状态图和AND / OR表；和（2） 的高级系统规范的方法，如那些在安全关键系统设计中使用。

通信行业开发了一种用于指定通信协议，电话系统等的状态机规范语言，即用于在UML中指定控件的SDL语言。

如在示出的下面的图9.6，SDL规格包括状态，动作，和状态之间既有条件和无条件转移。由于状态之间的转换是由内部和外部事件引起的，所以SDL是面向事件的状态机模型。

图9.6：SDL规范语言

可以使用其他技术来消除混乱并阐明基于状态的规范的重要结构。该状态图 是用于基于状态的说明书中一个众所周知的技术，该技术引入了一些重要的概念。

Statechart表示法使用事件驱动模型。状态图允许将状态分组在一起以显示通用功能。有两个基本分组：OR和AND。下面的图9.7 通过比较传统的状态转换图和通过OR状态描述的Statechart来显示OR状态的示例。

图9.7：Statecharts中的OR状态。

状态机指定当它们接收到输入i2时，它们会从s1，s2 或s3中的任何一个进入状态s4 。Statechart通过在s1，s2 和s3周围绘制OR状态来表示这种共性（OR状态 的名称在该状态顶部的小框中给出）。

出OR状态的单个过渡S123 指定对机器进入状态S4 ，当它接收到I2 的输入，而在包含在任何状态S123 .the或状态仍然允许其成员状态之间有趣的过渡。进入s123的方式有多种 （通过s1或s2），或者 在OR状态内的状态之间可能存在转换（例如从s1 到s3 或s2 到s3）.OR状态只是用于指定一些与这些状态有关的转换。

下面的图9.8 显示了用Statechart表示法指定的AND状态与传统状态机模型中的等效状态相比的示例。在传统模型中，状态之间存在许多转换。在该状态集群中也有一个入口点，在该集群之外有一个出口过渡点。

图9.8：状态图中的AND状态

在Statechart中，AND状态sab 分解为两个部分sa 和sb。 当机器进入“与”状态时，它同时驻留在 组件sa的状态s1 和 组件sb的状态s3中。我们可以认为系统的状态是多维的。当它进入sab时，要了解机器的完整状态，需要检查sa 和sb。

传统状态机中的状态名称揭示了它们与AND状态组件的关系。因此，状态s1-3 对应于状态图机器，其sa 分量在s1中 ，而sb 分量在s3中，依此类推。 只有在传统规范中，我们处于状态s2-4 并接收输入r时，我们才能退出此状态集群以进入状态s5。

在AND状态，这对应于SA 在状态S2，SB 处于状态S4，且机器接收，而在此组合状态的R输入。尽管传统模型和Statechart模型描述了相同的行为，但是每个组件只有两个状态，并且这些状态之间的关系要简单得多。

另一种状态机格式，AND / OR表 ，可用于描述状态之间的相似关系。下面的图9.9中显示了一个示例AND / OR表及其描述的布尔表达式。

图9.9：AND / OR表

AND / OR表中的行在表达式中标有基本变量。每列对应于表达式中的AND项。例如，AND项（cond2 而不是cond3）在第二列中用T 表示cond2，F 表示cond3，而破折号（忽略）表示cond1。这与以下事实相对应：cond2 必须为T，cond3 F 为AND项为真。

我们使用该表来评估系统中是否存在给定条件。将变量的当前状态与表元素进行比较。如果所有当前变量值均与该列中给出的要求相对应，则该列的值为true。

如果任一列的计算结果为true，则表的表达式的计算结果为true，就像我们期望的AND / OR表达式一样。此表示法与Statecharts之间最重要的区别在于，表中明确表示了“不在乎”，发现这对识别规范表中的问题有很大帮助。

更高级的规范

高级规范方法的优秀示例是为设计用于飞机的安全关键系统而开发的。这种规范的典型代表是为飞机的防撞系统TCAS II（交通警报和防撞系统）开发的规范。

为确保此系统的正确性和安全性而开发的规范技术也可以用于许多应用程序中，尤其是在其中许多复杂性进入控制结构的系统中。

根据各种信息，飞机中的TCAS单元会跟踪附近其他飞机的位置。如果TCAS判定可能发生空中相撞，它会使用音频命令来建议逃避行动-例如，预先录制的声音可能会警告“下降！下降！” 如果TCAS认为上方的飞机构成威胁，并且下方有回旋的余地。

TCAS实时做出复杂的决策，并且显然对安全至关重要。一方面，它必须检测到尽可能多的潜在碰撞事件（在其传感器等范围内）。另一方面，它必须生成尽可能少的错误警报，因为它建议的极端操作本身可能具有危险。

我不会在这里介绍整个规范，而足以提供其风味。TCAS II规范是用RSML语言编写的。它使用状态图表示法的修改版本来指定状态，其中状态的输入和输出是明确的。下图说明了该符号。

他们还使用转换总线来显示所有（或几乎所有）状态之间都存在转换的状态集。在以下示例中，存在从a，b，c或d到任何其他状态的转换：

CAS的顶级描述如下所示：

此图指定系统具有“关闭”和“打开”状态。在开机状态下，系统可能处于待机或完全运行模式。在“完全运行”模式下，按照AND状态的规定，三个组件并行运行：本机飞机子系统，一个最多可跟踪其他30架飞机的子系统以及一个最多可跟踪15个模式S的子系统提供雷达信息的地面站。下面显示的是“本机与”状态的规范。

同样，本机的行为是多个子行为的AND组成。Effective-SL和Alt-SL状态是控制系统灵敏度级别（SL）的两种方式，每种状态代表不同的灵敏度级别。

根据与地面的距离和其他因素，需要不同的灵敏度。Alt-Layer状态将垂直空域划分为多个层，该状态跟踪当前层。禁止爬升和禁止下降状态分别用于有选择地禁止爬升（在高海拔地区可能很困难）或下降（在地面附近显然很危险）。

同样，“抑制上升”和“抑制下降”状态可以抑制高速率的上升和下降。由于咨询状态非常复杂，因此此处不显示其详细信息。

将规格和需求转化为设计

到目前为止，我们已经讨论了许多用于制定特定决策的技术。现在，在本节中，我们研究如何掌握整个系统的体系结构。在CRC卡 的方法是众所周知的和有用的方式来帮助分析系统的结构。

它特别适合面向对象的设计，因为它鼓励数据和功能的封装。首字母缩写词CRC表示该方法论试图识别的以下三个主要项目：

类 定义数据和功能的逻辑分组。

职责 描述班级的工作。

协作者 是与给定类一起工作的其他类。

CRC卡之所以得名，是因为该方法是通过人们在索引卡上书写来实践的。（在美国，索引卡的标准尺寸为3英寸乘5英寸，因此这些卡通常称为3 x 5卡。）示例卡如下图9.10所示。

图9.10：CRC卡的布局。

它有空间写下班级名称，职责和合作者以及其他信息。CRC卡方法的本质是让人们在这些卡上书写，谈论它们并更新卡，直到他们对结果满意为止。

这项技术似乎是设计计算机系统的原始方法。但是，它具有几个重要的优点。首先，非计算机人员很容易创建CRC卡。

在系统设计中，获得领域专家（例如，用于汽车电子的汽车设计人员或用于PDA设计的人为因素专家）的建议非常重要。

首先，CRC卡方法非常非正式，不会吓到非计算机专家，并且可以让您捕获他们的输入。其次，它通过鼓励他们一起工作并分析场景来帮助计算机专家。

与CRC卡一起使用的演练过程在确定设计范围和确定对系统哪些部分了解不足方面非常有用。这种非正式的技术对于基于工具的设计和编码很有价值。如果您仍然需要使用工具来帮助您练习CRC方法，可以使用可自动创建CRC卡的软件工程工具。

在研究方法之前，让我们更详细地回顾一下CRC概念。我们熟悉类-它们封装了功能。类可以表示真实世界的对象，也可以描述仅为了帮助体系结构而创建的对象。一个类既具有内部状态又具有功能接口。功能接口描述了类的功能。

责任集是描述该功能接口的非正式方法。职责提供类的接口，而不是其内部实现。但是，与用编程语言描述课程不同，可以用英语（或您喜欢的语言）非正式地描述职责。一个类的协作者只是与之交谈的类，即，使用其功能或调用其以帮助其完成工作的类。

当面向对象的程序员查看CRC卡时，类术语有点误导。在该方法中，实际上使用类的方式更像是OO编程语言中的对象-CRC卡类用于表示系统中的实际角色。但是，在面向对象的设计中，CRC卡类别很容易转换为类别定义。

CRC卡分析由一组人员执行。可以自己使用它，但是该方法的很多好处来自与他人讨论开发类。

在开始该过程之前，应使用图9.10中所示的基本格式创建大量CRC卡。在小组中工作时，您将在这些卡片上书写；您可能会丢弃其中许多内容，并随着系统的发展将其重写。

CRC卡方法是非正式的，但是在使用它来分析系统时，应遵循以下步骤：

1.制定一个初步的班级清单： 写下班级名称，并写下一些有关其作用的文字。类可以表示现实世界的对象或建筑的对象。识别类所属的类别（例如，在实际对象的名称旁边放一个星号）会很有帮助。

每个人都可以负责处理系统的一部分，但是团队成员应在此过程中进行交谈，以确保不会遗漏任何类，并且不会创建重复的类。

2.编写职责和合作者的初始列表： 职责列表有助于更详细地描述班级的工作。协作者列表应基于类之间的明显关系构建。责任和协作者将在以后的阶段中得到完善。

3.创建一些使用场景： 这些场景描述了系统的功能。场景可能始于某种形式的外部刺激，这是识别相关现实对象的重要原因之一。

4.遍历场景： 这是方法论的核心。在演练期间，团队中的每个人代表一个或多个课程。场景应该通过行动来模拟：人们可以喊出他们的班级正在做什么，要求其他班级执行操作，等等。

例如，四处走动以显示数据的传输，可以帮助您可视化系统的操作。在演练期间，到目前为止创建的所有信息都将用于更新和完善，包括类，其职责和协作者以及使用场景。

在此过程中，可以创建，销毁或修改类。您可能还会在方案本身中发现许多漏洞。

5.完善班级，职责和合作者： 其中一些将在演练过程中完成，但在场景之后进行第二遍是个好主意。更长的视角将帮助您对CRC进行更全面的更改牌。

6.添加类关系： 完善CRC卡后，子类和超类关系应变得更清晰，并可以添加到卡中。

拥有CRC卡后，您需要以某种方式使用它们来帮助推动实施。在某些情况下，最好将CRC卡用作实现者的直接来源材料。如果您可以让设计人员参与CRC卡流程，那就尤其如此。

在其他情况下，您可能想用UML或另一种语言对CRC卡分析过程中捕获的信息进行更正式的描述，然后将该正式描述用作系统实现者的设计文档。