通用软件模型
原则 - COSMIC 通用软件模型
a) 软件块跨越边界与功能用户交互、并与边界内的持久存储介质进行交互。
b) 被度量软件块的 FUR 能够被映射到唯一的一组功能处理。
c) 每个功能处理由一系列子处理组成
d) 一个子处理可以是一个数据移动或者是一个数据运算。
e) 有四类数据移动：输入，输出，写和读。
输入从功能用户移动一个数据组到功能处理。
输出从功能处理中移出一个数据组到功能用户。
写从功能处理移动一个数据组到持久存储介质。
读从持久存储介质移动一个数据组到功能处理。
f) 一个数据移动仅移动单个数据组
g) 一个数据组描述一个单一的兴趣对象，它由唯一的一组数据属性集组成。
h) 每个功能处理都是通过触发输入数据移动来启动的。触发输入移动的数据组由功能
用户响应触发事件生成
i) 一个功能处理包括至少一个输入数据移动，以及一个写或输出数据移动，即一个功
能处理应该包含至少两个数据移动。一个功能处理中数据移动的数量没有上限。
j) 作为对度量目的的一种近似处理，数据运算子处理不单独度量。任何数据运算的功
能被假定已经计算在相关的数据移动内了。

重要提示：上述原则中的所有 COSMIC 关键词（除了“持久存储介质”）都应该以“类型”结尾。例如，“子处理”实际上应该写为“子处理类型”，“输入”应写作“输入类型”。所有的 FSM 方法都是为了识别功能或数据的类型，而非实例。

关键关系：事件/功能用户/功能处理
原则 b)和 h)告诉我们，软件的任务是响应在其功能用户的世界中发生的事件。功能用户通知软件事件发生，并发送事件相关的数据。作为对该事件的响应，软件必须为功能用户做些有用的事情。我们将这种“有用的事情”称为功能处理。 所有软件的 FUR 都可以用功能处理来表示。存在于功能用户世界中的事件与软件的功能处理之间的关系如图所示。（边界是正在度量的软件与其功能用户之间的接口。）

这个图通常的解释是，事件引发功能用户生成消息（数据组），该消息由“触发输入”移动到其功能处理中，从而启动功能处理。（请注意，当人类功能用户决定对现有数据进行查询时，才真正生成该事件，然后生成消息。）
事件就是“发生的事情”。触发事件要么已经发生，要么没有发生；在待度量软件的 FUR 中，它不能被再拆分。

案例：一场足球比赛。三个不同的软件程序的 FUR 可能对比赛中发生的事件有完全不同的视图。 应用程序 A 允许记者在报纸上刊登足球比赛的结果。FUR 识别的唯一事件是“比赛结束”。 应用程序 B 是一个“现场直播”系统，它允许记者通过网络向应用程序的在线用户发送在比赛期间记者 认为重要的事件的评论，如开球、进球、犯规、受伤等。FUR 识别的唯一事件是“记者向应用程序 B 输入比赛时发生的任何事件的评论” 应用程序 C 允许对球员的表现进行实时监控。每个球员都携带一个 GPS 定位装置和一个心率监控 器，以非常短的时间间隔定期传送数据。 FUR 识别的唯一事件是时钟的“节拍”，它负责将每个球员 在每个“节拍”时刻所处的位置和心率数据传输到应用程序 C。 （请记住，对于以上这些 FUR，我们实际上应该记录“事件类型”。这三个 FUR，每一个都只识别了一 个事件类型，但这三个事件类型又完全不同。但就事件实例而言 ，App A 预计每场比赛只发生一 次，App B 预计每场比赛可能发生几十次，而 App C 则可能每场比赛发生成千上万次。）

请注意，图中没有说明各种概念之间关系的程度（或“基数”）。例如，一个事件可能被相同或不同的软件块的多个功能用户检测到。 （例如地震可被多个传感器检测到）；一个软件块功能用户也可以感知到多种类型的事件（例如，人类与软件的交互）。

适用于图中关系基数的唯一一条规则是（这是一个非常重要的规则）：“任何触发待度量软件块的触发输入可能只启动该软件的一个功能处理”。

FUR 和功能处理的结构
原则 b)、c)和 d)描述了 FUR 的理论结构，也就是它分解为功能处理和子处理的结构，如 图所示

[“鱼尾”符号表示两个相邻概念之间的推导关系。原则 i)表明一个功能处理可以有 2 个（最少）至 n 个数
据移动。 ]
正确识别功能处理是映射阶段最重要的步骤。所以必须完全理解它的定义。

定义- 功能处理
a) 体现了被度量软件的功能用户需求基本组成部分的一组数据移动，这些数据移动在该
FUR 中是唯一的，并能独立于该 FUR 的其他功能处理进行定义。
b) 一个功能处理可能只有一个触发输入。每个功能处理在接受到由其触发输入数据移动
所移动的一个数据组后，开始进行处理。
c) 一个功能处理的数据移动的集合是响应触发输入的所有可能的功能性需求所需要的集
合。
注 1：实现时，一个功能处理实例，在收到一个触发输入实例移动的数据组实例时，才开
始执行处理。
注 2：除了触发输入外，一个功能处理的 FUR 可能需要一个或多个其他的输入。
注 3：如果功能用户发送了包含错误的数据组，例如，由于传感器失灵，或者人输入的命
令存在错误，通常是由功能处理来判断事件是否确实发生、和/或输入的数据是否有效、
以及如何响应。

数据运算的统计
COSMIC 方法没有刻意度量数据运算，因为目前还没有被普遍接受的度量数据运算的方法，因此它可以与数据移动的度量相结合，生成有意义的功能规模。因此，我们引用原则 j)，假设每个数据移动都可以承担与之相关联的数据运算，如图部分所示。事实证明，这个假设对于所有实践中的度量目的是合理的，正如设计该方法的初衷：用于项目性能度量和估算，并且在该方法的常用领域都行得通。如果出现这样的合并假设无法充分代表数据运算的场景时，COSMIC 度量方法支持对方法的本地化扩展，以克服其局限性。

四种类型的数据移动
原则 e)如图所示。

输入和输出分别将数据从功能用户移入或移出软件。
读和写分别将数据从持久存储介质移出或移入软件。

持久存储介质
持久存储介质(如上图所示)是通用软件模型的一个抽象概念。在模型中，如果需要存储数据或检索存储的数据，软件的任何层都可以访问该存储介质。 当一个功能处理写入了一些数据到持久存储介质后，该“持久数据”就可以被其他功能处理所用，或者被写入它的功能处理的另一个实例所用。从这个概念可以推断，如果您正在度量一个必须存储数据或检索存储数据的应用程序，则不必考虑底层软件或硬件如何从物理层面处理这些数据。只需分析通过写和读需要存储或检索数据的 FUR。如果在度量策略阶段已经把物理硬件设备定义为软件的功能用户，那么只需要把持久存储介质看作物理磁盘或内存来考虑。而功能用户总是通过输入和输出与要度量的软件进行交互。

一个数据移动移动了单一数据组，描述了单个兴趣对象
那么，我们如何区分两个不同的输入数据移动，以及区分输出、读和写呢？
兴趣对象是待度量软件必须为之处理或存储数据的“事物”(物理或概念上的)。数据移动会移动由一个或多个数据属性(在其他 FSM 方法中称为“数据元素类型”)组成的单个数据组。数据组中的所有属性都描述同一个兴趣对象。
根据度量目的，不需要识别数据属性。提到它们的唯一原因是，有时通过检查数据属性有助于区分不同的数据组及兴趣对象。
图中用两个例子展示了这三个概念之间的关系。

为了帮助您理解这些概念：
• 如果您熟悉在业务应用领域通常使用的数据分析方法，那么在实体关系分析中找到的实体类型，以及在关系数据分析中找到的第三范式的主体都是兴趣对象。 但这些分析方法通常只适用于存储(或“持久”)数据组结构。对于 COSMIC 度量来说需要应用这些分析方法来区分兴趣对象，从而区分功能处理的输入和输出中的数据移动。同时，任何一个输入或输出移动一个瞬态数据组时，也都是兴趣对象。
• 兴趣对象与 UML 分析中的对象类是一对一的关系，尽管它们是不同的概念。
• 在实时软件领域，通常不需要考虑兴趣对象。如图的实时案例，传感器可以看作是发送关于自身数据的功能用户，即功能用户扮演兴趣对象的角色，因此它将在度量策略阶段的早期被识别出来。（除非这样做有助于度量过程，否则做这种区分是没有意义的。）

映射阶段
如果软件的可获取制品达到功能处理颗粒度级别，我们便可以通过 COSMIC 模型推导出 FUR。这个过程的步骤（记住我们一直说的是类型）如下：
• 识别软件必须响应的功能用户世界中的独立事件，即“触发事件”。
• 识别这些触发事件是由哪些功能用户响应的，后者会生成一个由触发输入移动的数据组。
• 为每个触发输入识别一个功能处理。
• 在每个功能处理中，识别响应该触发输入的、满足 FUR 所需的所有其他数据移动，包括输入、输出、读和写。
对于最后一步，需要识别每次数据移动所移动的数据组和所描述的兴趣对象。